# US 10,481,901 B2 · System and method for performing firmware update by patching

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 10,481,901 B2
- Document ID: US10481901B2
- Status: Granted
- Kind: B2
- Application number: 15/495,312
- Filed: 2017-04-24
- Published: 2018-10-25
- Granted: 2019-11-19
- Earliest claimed: 2017-04-24
- Assignees: Amzetta Technologies, LLC
- Applicants: Amzetta Technologies, LLC
- Inventors: Yugender P. Subramanian; Balasubramanian Chandrasekaran; David Yoon; Manikandan Ganesan Malliga
- Web page: https://patentgrep.com/patent/US10481901B2

## CPC

- G06F 8/658: Incremental updates; Differential updates
- G06F 8/654: using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)

## Abstract

Systems and methods for performing firmware update on an embedded system by patching. In operation, a computing device may receive an image of replacement firmware, which is a different version of current firmware stored in a non-volatile memory of the embedded system. The computing device then determines the different portions of the replacement firmware from the current firmware by comparing the image of the replacement firmware to the current firmware, and retrieves the different portions from the image of the replacement firmware to form the fragments. In this case, the computing device may create a patch file by data of the fragments, and send the patch file to the embedded system, such that the embedded system may use the patch file to update the current firmware. The size of the patch file would be relatively smaller than the firmware image, thereby reducing update time and resources consumption.

## Claims

### Claim 1

A system, comprising:
a computing device, comprising a processor and a storage device storing computer executable code; and
an embedded system communicatively connected to the computing device, and comprising a non-volatile memory storing current firmware,
wherein the computer executable code, when executed at the processor, is configured to:
receive an image of replacement firmware, wherein the replacement firmware is a different version of the current firmware of the embedded system;
determine at least one different portion of the replacement firmware from the current firmware by comparing the image of the replacement firmware to the current firmware;
retrieve the at least one different portion from the image of the replacement firmware to form at least one fragment, wherein each of the at least one fragment corresponds to one of the at least one different portion retrieved from the image;
create a patch file by data of the at least one fragment;
transmit the patch file to the embedded system; and
configure the embedded system to:
copy corresponding portions of the current firmware from the non-volatile memory to a volatile memory;
replace the copy of the corresponding portions of the current firmware in the volatile memory with data of the at least one fragment;
erase the corresponding portions of the current firmware in the non-volatile memory; and
write the replaced copy of the corresponding portions of the current firmware in the volatile memory into the erased corresponding portions of the current firmware in the non-volatile memory.

### Claim 2 (depends on 1)

The system of claim 1, wherein the embedded system is an embedded controller or a system on a chip (SoC).

### Claim 3 (depends on 1)

The system of claim 1, wherein the patch file comprises:
a patch header;
a fragment header for each of the at least one fragment; and
the data of the at least one fragment.

### Claim 4 (depends on 3)

The system of claim 3, wherein the patch header comprises:
patch version information of the patch header;
new firmware version information of the replacement firmware;
old firmware version information of the current firmware;
product identification of the embedded system;
vendor identification of the embedded system;
a total size of the patch file;
a total number of the at least one fragment in the patch file; and
a patch checksum value for the patch file.

### Claim 5 (depends on 4)

The system of claim 4, wherein the embedded system is configured to:
determine whether the patch file is supported by checking the patch version information of the patch header;
determine whether the old firmware version information of the patch header matches version information of the current firmware;
perform an overall checksum verification using the patch checksum value for the patch file; and
verify the product identification and the vendor identification.

### Claim 6 (depends on 5)

The system of claim 5, wherein for each of the at least one fragment, the fragment header comprises:
fragment version information of the fragment header;
a fragment identification number of the fragment;
a start address of the fragment;
a size of the fragment; and
a fragment checksum value for the fragment.

### Claim 7 (depends on 6)

The system of claim 6, wherein the embedded system is configured to:
retrieve the fragment header of the fragment corresponding to the portion of the current firmware to be replaced;
determine whether the fragment is supported by checking the fragment version information of the fragment header;
perform a fragment checksum verification using the fragment checksum value for the fragment;
determine, among sector blocks of the non-volatile memory, at least one sector block to be replaced by the data of the fragment using the start address and the size of the fragment; and
update data of the at least one sector block using the data of the fragment.

### Claim 8 (depends on 7)

The system of claim 7, wherein the embedded system is configured to determine the at least one sector block to be replaced by the data of the fragment by:
determining a start sector block of the non-volatile memory using the start address of the fragment;
determining a block number of the fragment using the size of the fragment; and
determining the at least one sector block to be replaced by the block number and the start sector block.

### Claim 9 (depends on 7)

The system of claim 7, wherein the embedded system is configured to update data of the at least one sector block using the data of the fragment by:
copying the data of the at least one sector block from the non-volatile memory to a volatile memory;
replacing the copy of the data in the volatile memory using the data of the fragment;
erasing the at least one sector block in the non-volatile memory; and
writing the replaced copy of the data in the volatile memory into the erased at least one sector block in the non-volatile memory.

### Claim 10 (depends on 7)

The system of claim 7, wherein each of the sector blocks of the non-volatile memory comprises at least one sector.

### Claim 11

A method for performing firmware update on an embedded system by patching, comprising:
receiving, by a computing device, an image of replacement firmware, wherein the embedded system is communicatively connected to the computing device, and the replacement firmware is a different version of current firmware stored in a non-volatile memory of the embedded system;
determining, by the computing device, at least one different portion of the replacement firmware from the current firmware by comparing the image of the replacement firmware to the current firmware;
retrieving, by the computing device, the at least one different portion from the image of the replacement firmware to form at least one fragment, wherein each of the at least one fragment corresponds to one of the at least one different portion retrieved from the image;
creating, by the computing device, a patch file by data of the at least one fragment;
transmitting, by the computing device, the patch file to the embedded system; and
configuring, by the computing device, the embedded system to:
copy corresponding portions of the current firmware from the non-volatile memory to a volatile memory;
replace the copy of the corresponding portions of the current firmware in the volatile memory with data of the at least one fragment;
erase the corresponding portions of the current firmware in the non-volatile memory; and
write the replaced copy of the corresponding portions of the current firmware in the volatile memory into the erased corresponding portions of the current firmware in the non-volatile memory.

### Claim 12 (depends on 11)

The method of claim 11, wherein the patch file comprises:
a patch header;
a fragment header for each of the at least one fragment; and
the data of the at least one fragment.

### Claim 13 (depends on 12)

The method of claim 12, wherein the patch header comprises:
patch version information of the patch header;
new firmware version information of the replacement firmware;
old firmware version information of the current firmware;
product identification of the embedded system;
vendor identification of the embedded system;
a total size of the patch file;
a total number of the at least one fragment in the patch file; and
a patch checksum value for the patch file.

### Claim 14 (depends on 13)

The method of claim 13, wherein the embedded system is configured to:
determine whether the patch file is supported by checking the patch version information of the patch header;
determine whether the old firmware version information of the patch header matches version information of the current firmware;
perform an overall checksum verification using the patch checksum value for the patch file; and
verify the product identification and the vendor identification.

### Claim 15 (depends on 14)

The method of claim 14, wherein for each of the at least one fragment, the fragment header comprises:
fragment version information of the fragment header;
a fragment identification number of the fragment;
a start address of the fragment;
a size of the fragment; and
a fragment checksum value for the fragment.

### Claim 16 (depends on 15)

The method of claim 15, wherein the embedded system is configured to:
retrieve the fragment header of the fragment corresponding to the portion of the current firmware to be replaced;
determine whether the fragment is supported by checking the fragment version information of the fragment header;
perform a fragment checksum verification using the fragment checksum value for the fragment;
determine, among sector blocks of the non-volatile memory, at least one sector block to be replaced by the data of the fragment using the start address and the size of the fragment; and
update data of the at least one sector block using the data of the fragment.

### Claim 17 (depends on 16)

The method of claim 16, wherein:
the embedded system is configured to determine the at least one sector block to be replaced by the data of the fragment by:
determining a start sector block of the non-volatile memory using the start address of the fragment;
determining a block number of the fragment using the size of the fragment; and
determining the at least one sector block to be replaced by the block number and the start sector block;
the embedded system is configured to update data of the at least one sector block using the data of the fragment by:
copying the data of the at least one sector block from the non-volatile memory to a volatile memory;
replacing the copy of the data in the volatile memory using the data of the fragment;
erasing the at least one sector block in the non-volatile memory; and
writing the replaced copy of the data in the volatile memory into the erased at least one sector block in the non-volatile memory.

### Claim 18

A non-transitory computer readable medium storing computer executable code, wherein the computer executable code, when executed at a processor of a computing device, is configured to:
receive an image of replacement firmware, wherein the replacement firmware is a different version of current firmware stored in a non-volatile memory of an embedded system, and the embedded system is communicatively connected to the computing device;
determine at least one different portion of the replacement firmware from the current firmware by comparing the image of the replacement firmware to the current firmware;
retrieve the at least one different portion from the image of the replacement firmware to form at least one fragment, wherein each of the at least one fragment corresponds to one of the at least one different portion retrieved from the image;
create a patch file by data of the at least one fragment;
transmit the patch file to the embedded system; and
configure the embedded system to:
copy corresponding portions of the current firmware from the non-volatile memory to a volatile memory;
replace the copy of the corresponding portions of the current firmware in the volatile memory with data of the at least one fragment;
erase the corresponding portions of the current firmware in the non-volatile memory; and
write the replaced copy of the corresponding portions of the current firmware in the volatile memory into the erased corresponding portions of the current firmware in the non-volatile memory.

### Claim 19 (depends on 18)

The non-transitory computer readable medium of claim 18, wherein the patch file comprises:
a patch header, comprising:
patch version information of the patch header;
new firmware version information of the replacement firmware;
old firmware version information of the current firmware;
product identification of the embedded system;
vendor identification of the embedded system;
a total size of the patch file;
a total number of the at least one fragment in the patch file; and
a patch checksum value for the patch file;
a fragment header for each of the at least one fragment, the fragment header comprising:
fragment version information of the fragment header;
a fragment identification number of the fragment;
a start address of the fragment;
a size of the fragment; and
a fragment checksum value for the fragment; and
the data of the at least one fragment.

### Claim 20 (depends on 18)

The non-transitory computer readable medium of claim 18, wherein the computer executable code is configured to:
determine whether the patch file is supported by checking the patch version information of the patch header;
determine whether the old firmware version information of the patch header matches version information of the current firmware;
perform an overall checksum verification using the patch checksum value for the patch file;
verify the product identification and the vendor identification;
retrieve the fragment header of the fragment corresponding to the portion of the current firmware to be replaced;
determine whether the fragment is supported by checking the fragment version information of the fragment header;
perform a fragment checksum verification using the fragment checksum value for the fragment;
determine, among sector blocks of the non-volatile memory, at least one sector block to be replaced by the data of the fragment using the start address and the size of the fragment; and
update data of the at least one sector block using the data of the fragment.