COMPRESSED BINARY PATCHING OVER WIRELESS NETWORK

Abstract

A method of modifying a binary image on a device includes receiving data of at least a portion of a binary patch file over a network, the binary patch file being representative of a difference between a first binary image stored on the device and a second binary image. The method further includes decompressing at least a portion of the data of the portion of the binary patch file to obtain decompressed data, modifying at least a portion of the first binary image stored on the device based at least in part on the decompressed data, and transmitting a request to receive data of a further portion of the binary patch file.

Description

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of and priority to U.S. Provisional Patent Application No. 62/286,005, filed Jan. 22, 2016, which is incorporated herein by reference in its entirety.

FIELD

The present application concerns systems and methods of performing software and firmware updates on devices over a bandwidth-constrained network.

BACKGROUND

It can be beneficial to perform updates to software or firmware instructions operating on devices connected to a radio frequency network to, for example, provide new features or fix bugs. However, bandwidth constraints on a network, such as a low-energy wireless network, and/or hardware constraints on a device, such as limited available memory, can complicate transmission and application of updates. Such constraints can result in a relatively long period of time required to transmit and apply an update to existing binary on the device, during which period the device may be inoperable. Additionally, such long update periods can result in increased energy usage by the device. This can unnecessarily limit the life of, for example, devices without rechargeable or replaceable batteries, or devices, such as remote sensing devices, that cannot be easily retrieved for recharging or battery replacement. Accordingly, improvements to systems and methods of performing software and/or firmware updates are desirable.

SUMMARY

Certain embodiments of the disclosure are directed to systems and methods of performing software and/or firmware updates to a binary image on a device over a wireless network. In a representative embodiment, a method of modifying a binary image on a device comprises receiving data of at least a portion of a binary patch file over a network, the binary patch file being representative of a difference between a first binary image stored on the device and a second binary image. The method further comprises decompressing at least a portion of the data of the portion of the binary patch file to obtain decompressed data, modifying at least a portion of the first binary image stored on the device based at least in part on the decompressed data, and transmitting a request to receive data of a further portion of the binary patch file.

Another representative embodiment includes one or more non-transitory computer-readable storage media storing computer-executable instructions for causing a computer to perform a method, the method comprising receiving data of at least a portion of a binary patch file over a network, the binary patch file being representative of a difference between a first binary image stored on the device and a second binary image. The method further comprises decompressing at least a portion of the data of the portion of the binary patch file to obtain decompressed data, modifying at least a portion of the first binary image stored on the device based at least in part on the decompressed data, and transmitting a request to receive data of a further portion of the binary patch file.

In another representative embodiment, a system comprises a transceiver, non-volatile storage memory including a first binary image stored thereon, and a controller in electrical communication with the transceiver and with the non-volatile storage memory. The controller is operable to store data of at least a portion of a binary patch file received by the transceiver in volatile memory, the binary patch file being representative of a difference between the first binary image stored on the non-volatile memory and a second binary image. The controller is further operable to decompress at least a portion of the data of the portion of the binary patch file to obtain decompressed data, modify at least a portion of the first binary image based at least in part on the decompressed data, and transmit control signals to cause the transceiver to transmit a request to receive data of a further portion of the binary patch file.

The foregoing and other objects, features, and advantages of the disclosed technology will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic illustration of a representative embodiment of a system including a remote device in communication with a host computer system over a network.

FIG. 2 is a schematic illustration of a representative embodiment of a remote device.

FIG. 3 is a process flow diagram illustrating a representative method of modifying a binary image on a device.

FIG. 4 is a process flow diagram illustrating another representative method of modifying a binary image on a device.

FIG. 5 is a schematic block diagram of a representative computing environment.

DETAILED DESCRIPTION

FIG. 1 illustrates a representative system including a host computer system 102 in communication with a remote device 104 over a wireless network 106. The host computer system 102 can include a binary image database 108 having a binary image 136 stored thereon, a binary patch creation tool 110, a compression tool 112, an encryption tool 114, and a binary patch file division tool 115. In the illustrated embodiment, the remote device 104 can include a computing device such as a microcontroller 116, and a power source, such as a battery 150. In the illustrated embodiment, the microcontroller 116 can be in communication with one or more sensors located on the remote device such as sensors 118A-118C, and can process signals received from the sensors to, for example, control operation of a system in which the remote device is incorporated, and/or transmit data of the sensor signals to an end-use or terminal device (e.g., a smartphone, tablet computer, laptop, etc.) for display to a user. For example, in some embodiments the microcontroller 116, along with a variety of other components such as the sensors 118A-118C and/or a transceiver 120, can be arranged on a printed circuit board (PCB) or configured as a system on a chip (SOC) for use with the remote device 104.

With reference to FIG. 2, the microcontroller 116 can include a decryption tool 122, a decompression tool 124, and a binary patching tool 126. The microcontroller 116 can also include a volatile memory 128, and can be in communication with a non-volatile memory 130 (FIG. 1). The non-volatile memory 130 can include a binary image 132 comprising machine-readable instructions (e.g., firmware or software) for operating any of various components located on the remote device 104 (e.g., the sensors 118A-118C).

Returning to FIG. 1, the remote device 104 can also include a transceiver module 120 to allow transmission and receipt of data between the host system 102 and the remote device over the wireless network 106. In some embodiments, the wireless network 106 can be a relatively low-power wireless network, such as a local or personal area network (e.g., Bluetooth® Low Energy, Bluetooth® Smart, Thread, etc.), a low-power wide area network such as LoRa™, any of various networks operating according to the IEEE 802.15.4 standard for low-rate wireless networks, or any other suitable wireless network protocol. The foregoing wireless networks and other equivalent networks are termed herein “low-energy” or “low-power” wireless networks. Such low-power wireless networks are often designed for relatively low data transmission rates over relatively short distances, which can promote increased battery life for devices such as the remote device 104. However, although the following discussion proceeds with reference to relatively low-energy wireless networks, it should be understood that the systems and techniques described herein are not limited to such networks, but are applicable to devices operating over any suitable wireless network, regardless of power level or data bandwidth.

In certain examples, it can be desirable to update the binary image 132 operating on the remote device to, for example, fix bugs, add additional features or capabilities, or otherwise improve functionality of the remote device and/or its component systems. A representative method of updating a binary image is given below with reference to FIGS. 1 and 2, and the process flow diagram illustrated in FIG. 3.

Referring to FIG. 1, the binary patch creation tool 110 can compare the binary image 136 (a “first” binary image) with a second binary image 138, which can include changes or updates to the first binary image 136 (e.g., a firmware update). In certain examples, the first binary image 136 can be substantially the same as the binary image 132 stored on the remote device 104. The binary patch creation tool 110 can identify differences between the first and second binary images 136, 138, and output a binary patch file 134 containing information of the differences between the first and second binary images (e.g., a firmware patch file). In some embodiments, the binary patch creation tool 110 can also perform a cyclic redundancy check (“CRC”) (e.g., 32-bit CRC) on the first binary image 136 and the second binary image 138 to validate that the first binary image 136 is stored in the non-volatile memory 130 on the remote device 104 (e.g., as the binary image 132) prior to applying the binary patch 134, and that the binary image 132 as modified by the binary patch 134 matches the second binary image 138. In other words, the CRC process can validate whether the binary stored in the non-volatile memory 130 after application of the binary patch 134 to the binary image 132 matches the second binary image 138.

The binary patch 134 can be provided to the compression tool 112, which can compress the binary patch file to a suitable size for transmission to the remote device. The compressed binary patch file 134 can then be provided to the encryption tool 114, which can encrypt the compressed binary patch file before transmission of the file to the remote device 104 over the wireless network. In some embodiments, the encryption step can be optional, as desired. The binary patch file 134 can then be provided to the division tool 115.

Transmission of the binary patch file 134 to the remote device 104 can proceed in a piecemeal fashion in which a portion of the binary patch file (e.g., as determined by the division tool 115) is transmitted to the remote device, applied to the binary image on the remote device and, upon occurrence of a condition (e.g., full utilization of a specified memory), the remote device can request another portion of the binary patch file. An exemplary process flow diagram is presented in FIG. 3 illustrating the method by which the existing binary (e.g., binary image 132) on the remote device can be modified according to the binary patch file 134.

With reference to FIG. 3, after the binary patch file 134 has been compressed and (optionally) encrypted, the host system 102 can transmit initialization data 140 (FIG. 1) to the remote device 104 at block 202 instructing the remote device to prepare to receive the binary patch file 134. Upon receipt of the initialization data 140, the binary patching tool 126 can perform a CRC on the binary image 132. In some embodiments, the remote device 104 can transmit a request to the host system 102 requesting the first portion of data of the binary patch file (e.g., pending successful conclusion of the CRC of the binary image 132). Alternatively, transmission of the initial data file can proceed with or without prompting from the remote device.

Meanwhile, the division tool 115 of the host system can determine a portion 142 (e.g., 20 bytes, 200 bytes, etc.) of the binary patch file 134 to be transmitted to the remote device 104. The host system 102 can then transmit the portion 142 of the binary patch file 134, which can be received by the remote device 104 at block 204. In some embodiments, the division tool 115 (or another component of the host system) can specify an order in which portions of the binary patch file 134 should be transmitted to the remote device. This can allow information such as control data to be provided to the binary patching tool 126 in a specified order. However, in other embodiments, portions of the binary patch file 134 can be transmitted in any order, such as in a random order.

At block 206, if the received portion 142 of the binary patch file is encrypted, the data can be decrypted by the decryption tool 122 at block 208. Next, at block 210, the portion 142 can be at least partially decompressed by the decompression tool 124 and provided to the binary patching tool 126.

Meanwhile, a portion 144 of the binary image 132 corresponding to the portion 142 of the binary patch file 134 can be copied to the volatile memory 128, or a portion of the volatile memory designated as buffer memory. At block 212, the binary patching tool 126 can apply the decompressed data of the portion 142 of the binary patch file to the portion 144 of the binary image 132 contained in the volatile memory 128. At block 214, if the volatile memory 128 (e.g., the non-volatile storage buffer of block 214) is not yet fully utilized, decompression of the portion 142 is not yet complete (block 218), and more data is available by further decompressing the portion 142 (block 220), then the process returns to block 210. This can continue until the volatile memory 128 is full, or the portion 142 of the binary patch file is fully decompressed, and the portion 144 of the binary image 132 in the volatile memory has been modified to a selected extent (e.g., as far as possible) with the decompressed binary. If either of these conditions are true, the modified portion 144 of the binary image 132 can be written to the non-volatile memory 130, and the volatile memory 128 can be cleared.

When the portion 142 has been fully decompressed and/or the portion 144 of the binary image 132 has been modified to a selected extent based on the decompressed data of the portion 142, the remote device can transmit a request 146 to the host system at block 222 for another portion of the binary patch file 134. The host system can transmit another portion of the binary patch file 134 to the remote device, and the process can continue as above until the entirety of the binary patch file has been transmitted to the remote device and applied to the binary image 132. At this point, application of the patch 134 to the binary image 132 can be verified at block 224 by, for example, performing a CRC on the binary image 132 as modified by the binary patch file. If this CRC matches the CRC performed on the second binary image 138, then the patching process is concluded.

The binary patching processes and systems described herein can offer significant advantages over known patching techniques, particularly with respect to memory and/or power-constrained devices operating over low-power networks where data rates are relatively low. For example, for an exemplary remote device having 1024 bytes of RAM available for patching processes and running a firmware image requiring about 26 KB of memory, a 2 KB patch file can be compressed to about 292 bytes, and transferred to the remote device in portions of about 20 bytes in the manner described above, allowing the update process to be completed in about 1.8 seconds. By contrast, in a typical patching technique in which the entirety of the new firmware image is transmitted to a device, transfer of the 26 KB firmware image can require about one minute or longer. Because transfer time correlates strongly with power usage by the remote device, performing a binary update according to the techniques described herein requires only about 7% of the power required to transfer the full firmware image.

Although only a single remote device is illustrated in FIG. 1, it should be understood that the host system 102 can be in communication with a plurality of devices such as device 104, and can perform the methods described herein with such devices separately or concurrently. It should also be understood that the systems and methods described herein can be useful for transmitting any kind of software or firmware program or program update to a device. Further, in practice, the systems shown herein, such as the system 102, can vary in complexity, with different functionality, components of differing complexity, and the like. Although a single instance is shown, a large number of instances, some sharing data, databases, configuration information, and the like, can be supported. Also, the system 102 can comprise a variety of other functionality not shown to address synchronization, security, load balancing, multi-tenancy, redundancy, and the like.

Although various components of the systems herein are shown as a single component, in practice, the boundaries between components can be changed. For example, the functionality of any of the software tools described herein may be combined or subsumed with any of the other tools or functionalities described. Additionally, functionality can be implemented across one or more machines, virtual or physical.

The system 102, any of the other systems described herein, and subsets of such systems can be implemented in conjunction with any of the hardware components described herein, such as the described computing systems (e.g., processing units, memory, and the like). In any of the examples herein, the inputs, outputs, binary images, databases, and the like can be stored in one or more computer-readable storage media or computer-readable storage devices. The technologies described herein can be generic to the specifics of operating systems or hardware and can be applied in any variety of environments to take advantage of the described features.

FIG. 4 is a process flow diagram illustrating another representative method of modifying or updating a binary image on a device. At block 302, data of at least a portion of a binary patch file can be received over a network. The binary patch file can be representative of a difference between a first binary image stored on the device and a second binary image.

At block 304, at least a portion of the data of the portion of the binary patch file can be decompressed to obtain decompressed data.

At block 306, at least a portion of the first binary image stored on the device can be modified based at least in part on the decompressed data.

At block 308, a request to receive data of a further portion of the binary patch file can be transmitted.

Representative Computing Environment

FIG. 5 depicts a generalized example of a suitable computing environment 400 in which software and control algorithms for the described innovations may be implemented. For example, the host system 102 and/or the remote device 104 may include, or may be implemented on, one or more of the features described with respect to FIG. 5. The computing environment 400 is not intended to suggest any limitation as to scope of use or functionality, as the innovations may be implemented in diverse general-purpose or special-purpose computing systems. For example, the computing environment 400 can be any of a variety of computing devices (e.g., desktop computer, laptop computer, server computer, tablet computer, gaming system, mobile device, programmable automation controller, etc.).

With reference to FIG. 5, the computing environment 400 includes one or more processing units 410, 415 and memory 420, 425 (e.g., for storing data indicative of stage vibration). In FIG. 5, this basic configuration 430 is included within a dashed line. The processing units 410, 415 execute computer-executable instructions. A processing unit can be a general-purpose central processing unit (CPU), a processor in an application-specific integrated circuit (ASIC) or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. For example, FIG. 5 shows a central processing unit 410 as well as a graphics processing unit or co-processing unit 415. The tangible memory 420, 425 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing unit(s). The memory 420, 425 stores software 480 implementing one or more innovations described herein, in the form of computer-executable instructions suitable for execution by the processing unit(s).

A computing system may have additional features. For example, in some embodiments, the computing environment 400 includes storage 440, one or more input devices 450, one or more output devices 460, and one or more communication connections 470. An interconnection mechanism (not shown) such as a bus, controller, or network, interconnects the components of the computing environment 400. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment 400, and coordinates activities of the components of the computing environment 400.

The tangible storage 440 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium that can be used to store information in a non-transitory way and can be accessed within the computing environment 400. The storage 440 stores instructions for the software 480 implementing one or more innovations described herein (e.g., a binary patch file).

The input device(s) 450 may be, for example: a touch input device, such as a keyboard, mouse, pen, or trackball; a voice input device; a scanning device; any of various sensors; another device that provides input to the computing environment 400; or combinations thereof. For video encoding, the input device(s) 450 may be a camera, video card, TV tuner card, or similar device that accepts video input in analog or digital form, or a CD-ROM or CD-RW that reads video samples into the computing environment 400. The output device(s) 460 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment 400.

The communication connection(s) 470 enable communication over a communication medium to another computing entity. The communication medium conveys information, such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can use an electrical, optical, RF, or other carrier.

Any of the disclosed methods can be implemented as computer-executable instructions stored on one or more computer-readable storage media (e.g., one or more optical media discs, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as flash memory or hard drives)) and executed on a computer (e.g., any commercially available computer, including smart phones, other mobile devices that include computing hardware, or programmable automation controllers). The term computer-readable storage media does not include communication connections, such as signals and carrier waves. Any of the computer-executable instructions for implementing the disclosed techniques as well as any data created and used during implementation of the disclosed embodiments can be stored on one or more computer-readable storage media. The computer-executable instructions can be part of, for example, a dedicated software application or a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a client-server network (such as a cloud computing network, or other such network) using one or more network computers.

For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C, C++, Java, Perl, JavaScript, Adobe Flash, or any other suitable programming language. Likewise, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure.

It should also be well understood that any functionality described herein can be performed, at least in part, by one or more hardware logic components, instead of software. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

Furthermore, any of the software-based embodiments (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.

General Considerations

For purposes of this description, certain aspects, advantages, and novel features of the embodiments of this disclosure are described herein. The disclosed methods, apparatus, and systems should not be construed as being limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and sub-combinations with one another. The methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.

Although the operations of some of the disclosed embodiments are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, for the sake of simplicity, the attached figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods. Additionally, the description sometimes uses terms like “provide” or “achieve” to describe the disclosed methods. These terms are high-level abstractions of the actual operations that are performed. The actual operations that correspond to these terms may vary depending on the particular implementation and are readily discernible by one of ordinary skill in the art.

As used in this application and in the claims, the singular forms “a,” “an,” and “the” include the plural forms unless the context clearly dictates otherwise. Additionally, the term “includes” means “comprises.” Further, the terms “coupled” and “associated” generally mean electrically, electromagnetically, and/or physically (e.g., mechanically or chemically) coupled or linked and does not exclude the presence of intermediate elements between the coupled or associated items absent specific contrary language.

In some examples, values, procedures, or apparatus may be referred to as “lowest,” “best,” “minimum,” or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many alternatives can be made, and such selections need not be better, smaller, or otherwise preferable to other selections.

In view of the many possible embodiments to which the principles of the disclosed technology may be applied, it should be recognized that the illustrated embodiments are only preferred examples and should not be taken as limiting the scope of the disclosure. Rather, the scope of the disclosure is defined by the following claims.

Claims

1. A method of modifying a binary image on a device, comprising:

over a network, receiving data of at least a portion of a binary patch file, the binary patch file being representative of a difference between a first binary image stored on the device and a second binary image;

decompressing at least a portion of the data of the portion of the binary patch file to obtain decompressed data;

modifying at least a portion of the first binary image stored on the device based at least in part on the decompressed data; and

transmitting a request to receive data of a further portion of the binary patch file.

2. The method of claim 1, wherein the modifying further comprises:

copying the portion of the first binary image to volatile memory; and

storing a modified portion of the first binary image in non-volatile memory when a constraint on the volatile memory is met.

3. The method of claim 2, further comprising storing the modified portion of the first binary image in the non-volatile memory when the volatile memory is full.

4. The method of claim 2, further comprising storing the modified portion of the first binary image in the non-volatile memory when the data of the portion of the binary patch file is fully decompressed.

5. The method of claim 2, further comprising clearing the volatile memory after the modified portion of the first binary image is stored in the non-volatile memory.

6. The method of claim 1, further comprising decrypting the data of the portion of the binary patch file.

7. The method of claim 1, wherein the network is a low-energy wireless network.

8. The method of claim 1, further comprising repeating the receiving, decompressing, modifying, and transmitting until the entirety of the binary patch file has been received and the first binary image has been modified based on the binary patch file.

9. The method of claim 8, further comprising performing a cyclic redundancy check on the first binary image as modified by the binary patch file.

10. The method of claim 1, wherein the first binary image is a firmware image, and the binary patch file is a firmware update.

11. One or more non-transitory computer-readable storage media storing computer-executable instructions for causing a computer to perform a method of modifying a binary image on a device, the method comprising:

over a network, receiving data of at least a portion of a binary patch file, the binary patch file being representative of a difference between a first binary image stored on the device and a second binary image;

decompressing at least a portion of the data of the portion of the binary patch file to obtain decompressed data;

modifying at least a portion of the first binary image stored on the device based at least in part on the decompressed data; and

transmitting a request to receive data of a further portion of the binary patch file.

12. The computer-readable storage media of claim 11, wherein the modifying further comprises:

copying the portion of the first binary image to volatile memory; and

storing a modified portion of the first binary image in non-volatile memory when a constraint on the volatile memory is met.

13. The computer-readable storage media of claim 12, wherein the method further comprises storing the modified portion of the first binary image in the non-volatile memory when the volatile memory is full.

14. The computer-readable storage media of claim 12, wherein the method further comprises storing the modified portion of the first binary image in the non-volatile memory when the data of the portion of the binary patch file is fully decompressed.

15. The computer-readable storage media of claim 12, wherein the method further comprises clearing the volatile memory after the modified portion of the first binary image is stored in the non-volatile memory.

16. The computer-readable storage media of claim 11, wherein the method further comprises repeating the receiving, decompressing, modifying, and transmitting until the entirety of the binary patch file has been received and the first binary image has been modified based on the binary patch file.

17. The computer-readable storage media of claim 16, wherein the method further comprises performing a cyclic redundancy check on the first binary image as modified by the binary patch file.

18. A system, comprising:

a transceiver;

non-volatile storage memory including a first binary image stored thereon; and

a controller in electrical communication with the transceiver and with the non-volatile storage memory, the controller being operable to: in volatile memory, store data of at least a portion of a binary patch file received by the transceiver, the binary patch file being representative of a difference between the first binary image stored in the non-volatile memory and a second binary image; decompress at least a portion of the data of the portion of the binary patch file to obtain decompressed data; modify at least a portion of the first binary image based at least in part on the decompressed data; and transmit control signals to cause the transceiver to transmit a request to receive data of a further portion of the binary patch file.

19. The system of claim 18, wherein the controller is further operable to:

copy the portion of the first binary image to be modified to the volatile memory; and

store a modified portion of the first binary image in the non-volatile memory when the volatile memory is full.

20. The system of claim 18, wherein the controller is further operable to repeat the storing, decompressing, modifying, and transmitting until the entirety of the binary patch file has been received and the first binary image has been modified based on the binary patch file.