US20050063242A1 - Embedded software update methods and systems for digital devices - Google Patents
Embedded software update methods and systems for digital devices Download PDFInfo
- Publication number
- US20050063242A1 US20050063242A1 US10/986,258 US98625804A US2005063242A1 US 20050063242 A1 US20050063242 A1 US 20050063242A1 US 98625804 A US98625804 A US 98625804A US 2005063242 A1 US2005063242 A1 US 2005063242A1
- Authority
- US
- United States
- Prior art keywords
- patch
- flash
- software
- digital device
- update
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
Definitions
- the present invention is related to digital electronics products with embedded software operating systems, and more particularly related to methods of updating, correcting, modifying or upgrading the embedded software in such digital devices before or after the products have been released to market.
- a software update system for digital devices is best understood from a system architecture perspective. Reference is to FIG. 1 , where a simplified conventional microprocessor system is illustrated.
- a microprocessor system in a typical digital device may comprise a Central Processing Unit (“CPU”) 100 , Random Access Memory (“RAM”) 110 , Flash/ROM memory 120 , and some peripheral devices 130 .
- a software program resides in Flash/ROM memory 120 , and is read by CPU 100 during execution. Flash is a type of constantly-powered nonvolatile memory that can be erased and reprogrammed in units of memory called blocks.
- the term “ROM” stands for “Read Only Memory”.
- a Digital Signal Processor (“DSP”) system in a conventional digital device may comprise a DSP core 200 , RAM 210 , Flash/ROM memory 220 , and some peripheral devices 230 , as shown in FIG. 2 .
- a software program resides in Flash/ROM memory 220 , and is read by DSP core 200 during execution.
- a typical digital device e.g. a digital cellular phone, normally contains a microprocessor system, and may also contain a DSP system.
- a typical software update system can be configured or adapted to reside in the embedded software of the microprocessor system and/or the DSP system of a digital device.
- FIG. 3 A simplified drawing of a conventional software architecture of a software update system in a digital device is illustrated in FIG. 3 .
- the patch receiving module 300 is for receiving software patch data. It may include mechanism for data receiving either from wired link or wireless link, mechanism for data error detection and/or mechanism for data security check. After the patch receiving module 300 correctly receives patch data, it will pass the patch data to the patch programming module 310 .
- the patch programming module 310 is for writing patch data into the patch database 320 and/or some program code areas. It may include program for writing data into Flash, NVM, EEPROM memory, and/or other types of memory.
- the patch database 320 is a memory area in Flash memory and/or other types of memory, which is for containing patch data.
- the present invention is directed to a method of updating embedded software using software patches. This approach can separately update one or multiple parts of the embedded software without changing program code of the other parts. Such updates can be transmitted to the target digital devices through wireless or wired transmission.
- a method and apparatus of updating an embedded software operative in a digital device by a software patch comprises preparing said embedded software, which comprises designating at least one Flash block of a Flash memory in said digital device as Flash update block for software update programming, designating at least one area in RAM memory in said digital device as RAM update buffer for Flash programming, preparing Flash erasing function and Flash writing function, designating a memory area in said digital device as patch area, loading said embedded software into said digital device.
- the method then comprises generating a software patch, adapted to provide a predetermined function, transmitting said software patch to said digital device through a communications link, receiving said software patch by said digital device, updating at least one Flash block of said embedded software in the unit of Flash block with said software patch.
- embedded software herein is the software program written in C/C++/Java/Assembler, or other software programming languages, as well as any executable machine code of CPU/Microprocessor or DSP (“Digital Signal Processor”), for operating the digital devices.
- software patch herein is a block of software update data for updating the embedded software in the digital devices.
- the embedded software in a digital device is typically stored in ROM/Flash memory, and the present invention is directed to updating the embedded software stored in Flash memory.
- the software update system of the present invention can be configured or adapted to reside in the embedded software of the microprocessor system and/or the DSP system of a digital device.
- the software update system in accordance with one embodiment of the present invention when it is implemented in a digital device, may be structured to comprise a software module 300 for patch receiving, a software module 310 for patch programming and a patch database 320 , as illustrated by FIG. 3 .
- a typical Flash memory chip is composed by multiple Flash banks, Bank-1, Bank-2, . . . Bank-N, and each bank can be further separated into multiple Flash blocks.
- Bank-1 can be separated into Block-1, Block-2, . . . , Block-M.
- Flash “partition” can also be used to represent a Flash “bank”, in this application, only the term Flash “bank” is used to represent the meaning.
- the embedded software in a digital device is typically programmed into K banks of the Flash memory, Bank-1, Bank-2, . . . , Bank-K, where K is the total number of the Flash banks that the embedded software occupied, and K is less or equal to N, where N is the total number of banks allocated.
- Flash memory chip such as the Intel 28F320W30 Flash memory chip
- only one Flash bank at a time can be in the state of active programming or erasing. While writing or programming data into an area in a Flash bank, for example Flash Bank-A, it is not permissible to read any data stored in that Flash Bank-A, though some values of Flash registers can be read or using some addresses in the Flash Bank-A. However, when writing data into the Flash Bank-A, it is permissible to read data stored in any other Flash banks different from Bank-A. When erasing operation is performed on a Flash bank, each Flash block in the Flash bank can be separately erased.
- Flash memory has a feature that each data bit of the memory can only be changed from state “1” to state “0” during Flash programming or data writing.
- a data bit in Flash memory cannot be changed separately from state “0” to state “1”. It depends on Flash erasing, for example, erasing a Flash block, to reset all the data bits in the Flash block to state “1”. Therefore when a part of the program code in Flash memory needs to be updated, it is not possible, nor permissible, to directly over-write the original program code with the new updated program code, without erasing the corresponding Flash block.
- Flash bank As the unit to update embedded software have been developed by those in the art. They use the Flash bank as the basic unit, because it is possible to read data from a Flash bank and simultaneously write data into another Flash bank. They use an entire Flash bank as a “buffer” to temporarily store the updated software during software updating process. During software updating, and the embedded software is updated in the unit of Flash bank.
- Flash bank as a “buffer” is not an efficient way for utilizing Flash memory, because a Flash bank can have several mega bits, which is quite a big area.
- one entire Flash bank may not be available as a buffer just for software update purpose. Even if the bank may be available, updating an entire bank has proved to be an extremely wasteful and inefficient way of updating what may be a minor code revision.
- the present invention is directed to the use of a Flash block, which is much smaller than a Flash bank, as the “buffer” for software update, and the embedded software is updated in the unit of a Flash block, instead of the unit of a Flash bank.
- a Flash block which is much smaller than a Flash bank
- the embedded software is updated in the unit of a Flash block, instead of the unit of a Flash bank.
- Another advantage of this methodology is that, because it becomes possible to make software update in the unit of a Flash block, software updating can be performed in a more precise and efficient way than the conventional method based on the unit of a Flash bank. Thus, the software update programming can be completed in a shorter period of time.
- this invention is directed to a methodology to make software update directly at the original Flash area, without the need of preparing a big blank Flash bank for containing the entire new version of the embedded software.
- the embedded software is updated in the unit of Flash block, and the updated program code is still allocated at the original Flash blocks. Therefore, a software update system in accordance with the present invention will greatly save the Flash memory usage for software update.
- Flash programming functions such as data writing function and flash erasing function are stored in Flash memory, for example, in a Flash bank, Bank-K.
- the Flash programming functions refer to a “Flash-Writing-Function” and a “Flash-Erasing-Function”.
- the Flash-Writing-Function is a function to write or program data into Flash memory.
- the Flash-Erasing-Function is a function to erase a block of Flash memory.
- Flash programming functions i.e. the Flash-Writing-Function and the Flash-Erasing-Function, are copied into RAM memory, and then run in the RAM memory.
- Flash programming functions are running in RAM memory, and it becomes possible to perform Flash data writing and Flash block erasing operations on Bank-K, for updating the embedded software located in the Bank-K, thus avoiding the otherwise prohibited simultaneous data reading and writing operations on the Bank-K during Flash programming.
- Some existing program compilers can also support putting software functions into RAM memory and running those functions in RAM memory, by setting some configuration parameters for software compilation (including module linking). In this case, copying the Flash programming functions into RAM memory can be done by the compilers. If a software compiler does not support this function, some software functions can be created for achieving the similar actions, and added into the embedded software.
- Flash programming functions can be put into a Flash bank separated from the Flash banks containing the embedded software that may need to be updated, instead of being put into RAM memory.
- This Flash bank is thus used for the purpose of Flash programming for the other Flash banks. This method can be used as a replacement of the above method of using RAM memory.
- RAM-Update-Buffer The size of RAM-Update-Buffer can be decided based on how large the space in RAM memory in the digital device can be used for software updating.
- the program code when performing Flash programming with the RAM-Update-Buffer, for example, in the same Flash bank, copying some program code from Block-A to Block-B, the program code will be first copied into the RAM-Update-Buffer from Block-A, and then be programmed into Block-B by reading the data from the RAM-Update-Buffer. In this way, the otherwise prohibited simultaneous reading and writing operations on the same Flash bank can be avoided. If the RAM-Update-Buffer is no big enough to contain the whole program code that need to be copied, the program code that needs to be copied can be separated into multiple parts to ensure each part can fit into the RAM-Update-Buffer. In this case, Flash programming is performed for each part of the program code, by first copying the code into the RAM-Update-Buffer from Block-A, and then writing the code into Block-B by reading the code from the RAM-Update-Buffer.
- copying data from a Flash block, Block-A, into another Flash block, Block-B can be performed in the following steps.
- Step1 Check the length of the data to be copied from the Block-A with the size of the RAM-Update-Buffer, and copy the amount of the data in the Block-A that can fit into the RAM-Update-Buffer into the RAM-Update-Buffer.
- Step2 Run the flash programming functions in the RAM memory to read the data from the RAM-Update-Buffer and write the data into the Block-B.
- Step3 If there is still data left in the Block-A that need to be copied into the Block-B, go back to Step1 for further copying, until all the data is copied into the Block-B.
- a corresponding software patch can be generated to contain the information of update code for updating the part of the embedded software.
- the software patch can be sent to the digital device via a communication link, either a wired link or a wireless link.
- the digital device After correctly receiving the software patch by the patch receiving module 300 in FIG. 3 , the digital device passes the patch data to the patch programming module 310 .
- the patch programming module 310 is for writing patch data into the patch database 320 and/or the program code area of the part that needs to be updated.
- this invention uses a Flash block as a “buffer” for software update, and performs software update in the unit of Flash block.
- the following preparation should preferably be performed.
- Flash block is named as “Block-A”
- the update programming can be performed with the following steps. Note that these steps are only for exemplary purpose to show the inventions details, implementation details may vary based on the situation of the embedded software and the digital device. FIG. 6 also shows the exemplary programming steps for illustration purposes.
- Update-Buffer-Block Erase the Update-Buffer-Block by running the Flash-Erasing-Function in the RAM memory, so that all the data bits in the Update-Buffer-Block are in state “1”.
- Copy the updated program code into the Update-Area of the Update-Buffer-Block If the updated program code is stored in an area of Flash memory beforehand, the process of copying the updated program code into the Update-Area of the Update-Buffer-Block may follow the process of “copying data from Block-A to Block-B” previously described in Section 3.5, if necessary, other methods of copying data from one FLASH block to another FLASH block.
- Copy the content in the Update-Buffer-Block into Block-A may follow the process of “copying data from Block-A to Block-B” previously described in Section 3.5, if necessary, other methods of copying data from one FLASH block to another FLASH block can be used.
- the program code in Block-A that needs to be updated can be replaced with the new program code, while the other code in the Block-A remains unchanged and also the program code in other Flash blocks remain unchanged.
- Step 3 can be skipped if a step of copying the updated program code directly into the corresponding Update-Area of the Block-A is added after the above Step 5.
- the Update-Area of the Update-Buffer-Block in the above Step 5 is “empty,” i.e. filled with hexadecimal “0 ⁇ FF”, when the entire block is copied back to the Block-A.
- the program update code then overwrites the now-empty Update-Area in the Block-A, thus effecting a Block update.
- Update-Programming In order to ensure that the Update-Programming can be performed successfully, it may be necessary to ensure that there will be no task switching happening during the process of the Update-Programming in the Real Time Operation System of the digital device. This can preferably be achieved by setting the task or thread for the Update-Programming in the Real Time Operation System to the highest priority, and disabling the interrupt functions of CPU/DSP during the Update-Programming.
- Flash Block Updating methodology described above can be done without having to pre-process or prepare any insertion or jump checkpoints into the code during initial programming. Also, the existing code in the digital device does not need to be altered to accommodate the Updating methodology, thus making it quite compatible with the goal of providing software updates to any electronic or digital devices already out in the field.
- a software patch or program code of update can be programmed into an update code area or patch area in Flash memory.
- the CPU/DSP execution can be directed to the place of the updated program code in the update code area, or patch area, and uses the updated program code for execution, instead of using the original part of program for execution.
- a jumping instruction can be allocated for jumping to the patch area.
- the software modification on the original code area can be performed with the update method described in Section 3.6, based on the Flash block update on the corresponding Flash blocks.
- the CPU/DSP execution can be redirected to the update code area, where the software patch or program code of update has been received and programmed.
- FIG. 8 shows another embodiment of the software update methodology, where some updated program code (Update Program Code Part 1) can be directly put into the program code area of the part that needs to be updated, while other updated program code (Update Program Code Part 2) can be put into the Update Code Area.
- Update Program Code Area can be used to contain the program code portion that cannot fit into the original location in the program code area.
- the patch programming on the original code area can be performed with the method described in Section 3.6, based on the Flash block update.
- FIG. 9 shows yet another embodiment of the update methodology, where the updated program code can be directly put into the program code area of the part that needs to be updated. This can be used in the case when the size of the updated program code is not bigger than the size of the part of the original program code that needs to be updated.
- a jump or skip instruction is added so that CPU execution can jump over or skip the portion of the original code that is now obsolete.
- the patch programming on the original code area can be performed with the method described in Section 3.6, based on the Flash block update.
- Update-Programming-Checking-Routine For achieving error recovery from power loss, a software routine, named “Update-Programming-Checking-Routine”, can be put at or close to the bootstrap code (program execution start point), so that when the embedded software starts to run from power-on or system reset, it will execute the Update-Programming-Checking-Routine. Though this routine is always executed from power-on or system reset, it only becomes effective after the cell phone or digital device is powered back on, after certain interruption.
- the Update-Programming-Checking-Routine checks whether there are any patch programming tasks that have not been completed for software update. If there are such incomplete tasks, patch programming for software update will be executed to complete the tasks. Then, the execution is back to the original program for system power-on.
- the digital device can write the new program code into Flash memory for buffering, so that even if there is a power loss during software update process, the received program code will not be lost.
- This area can be named as “Patch-Data-Buffer”.
- Some flag parameters can be used as the status indication of update-programming, which can be named as “Patch-Programming-Flag”.
- the Patch-Programming-Flags can be saved in an area of Flash memory. For example, a Patch-Programming-Flag composed by 5 bits, or n bits, can be reserved in an area of Flash memory to indicate the status of the 5 steps, or n steps, of the patch programming discussed in the above Section 3.6.
- All the bits of the flag are all in state “1” at first.
- one corresponding bit of the flag will be changed from “1” to “0”.
- patch programming can be restarted by the Update-Programming-Checking-Routine. For example, if the power loss happened before Step 4, patch programming can be re-started from Step 1. And if the power loss happened after Step 4, patch programming can be re-started from Step 4 of Section 3.6.
- the Flash area for the Patch-Data-Buffer and the Flash area for the Patch-Programming-Flags can be erased so that the next patch can reuse the same areas.
- the method of Section 3.6 for updating a Flash block can be used to update every bit in these areas to “1”. As discussed in Section 3.6, the update can be carried out in the unit of Flash block, and the bit values of the areas in the corresponding Flash blocks can be changed back to state of“1”.
- a software patch is the replacement of a piece of the original program code.
- the program source code can be compiled into an object file.
- the object file includes the information of an executable command code, though some parameters, such as the offsets of function calls, need to be updated by the linker of the compiler.
- a “map” file of the executable embedded software can be generated by the linker software.
- the map file may include information of variables and function addresses.
- a methodology of patch generation is introduced.
- a software patch can be composed by new program code and its corresponding location or memory address information in the embedded software of the digital device.
- the information in the object files of the new program code and the map files of both the original executable embedded software and the updated executable embedded software can be used for generating a software patch.
- the information of the corresponding executable CPU instruction code from the new object file generated based on the new version of the function can be extracted and used as the updated program code in a patch for updating the function.
- the information of the function addresses can be used in the patch as the address information related to place that the patch code need to be written on.
- Some software tools can also be developed for the automatic patch generation based on the information from the object file and the map file.
- patch server it should be appreciated by those skilled in the art that it may be a system that can dispatch or transmit a software patch to one or more digital devices in the field, preferably through existing communication infrastructure or channels, such as a wireless link, or a wired connection.
- the patch server may have any level of automation for its operation.
- a digital device Upon transmission, a digital device receives patch data with its Patch Receiving Module 300 shown in FIG. 3 . During or after the patch data transmission, the digital device may send signals (or messages) to the patch server for acknowledgment.
- SMS Short Message Service
- SMS messages can be sent to cellular phones based on GSM, GPRS, WCDMA, CDMA or other wireless and wired technologies. Both point-to-point SMS messages and broadcast SMS messages can be used for patch transmission. Sometimes, broadcast SMS messages are also called with some other names, such as cell broadcast SMS messages.
- some fields of the SMS messages can be set to some values, for example, some “reserved values”, so that the digital devices that have not installed the patch system can simply discard the SMS messages, and only the digital devices that have the patch system installed will process the SMS messages for software update.
- the “Coding Group” can be set to one of the reserved values, so that the digital device without having patch system will simple discard the SMS messages without displaying the SMS message content to users because the digital devices cannot process the reserved “Coding Group”. But for those digital devices that have the patch system installed can process the SMS messages for software update based on a predetermined protocol.
- the digital device needs to send a message to patch server to inquire available patches or reporting patching status of the digital device.
- the identification number of patch server such as a phone number or platform number can be pre-installed into the digital device, so that the digital device can use the server number to send the necessary messages to the patch server.
- the patch server needs to use the identification number of the digital device, such as a phone number to send update notice to the digital device.
- the identification number and other related information of the digital device can be registered on the patch server for this purpose. Many methods of the registration can be considered.
- the digital device information can be registered by the digital device user on a web site by entering the information of the digital device and the corresponding identification number; or the digital device user can send a message to the patch server including the product information and the product identification number.
- patch data can be processed with information of CRC (Cyclic Redundancy Codes), checksum or other schemes as can readily be implemented by those skilled in the art.
- CRC Cyclic Redundancy Codes
- checksum Checksum
- the patch server shall re-send the patch data to the digital device.
- patch retransmission can be based on a timer-based mechanism: The patch server has a timer for patch retransmission. After the patch server sends out a patch to a digital device, it will start the timer. If the patch server does not receive any corresponding reply message (e.g., patching status report) from the digital device when the timer times out, the patch server will re-send the patch data packets to the digital device.
- reply message e.g., patching status report
- the patch server may stop the retransmission for a while. It should be appreciated by those skilled in the art that other ways of timing the transmission and re-transmission of patches can readily be implemented in connection with the teaching of the present invention.
- Patch Status Report which is sent from a digital device to a patch server and contains the current patch status information of the digital device. If the digital device receives a patch without error, it will send Patch Status Report via a reverse SMS message to the patch server at the time:
- patch data Before patch data is transmitted to a digital device, it can be encrypted for security protection. And after receiving the encrypted patch data, the digital device decrypts the patch data before using it. This is important to the cases such as using SMS message for patch data transmission, because SMS messages may be sent from any people to any cellular phones.
- This invention discloses some methods for patch encryption.
- the patch data Before patch data is transmitted to a digital device, the patch data can be encrypt with one or multiple encryption algorithms, such as Triple-DES etc. These encryption algorithms normally need encryption keys for encryption calculation.
- the encryption keys can be generated based on a highly complicated and secured software function, and can be named as “Encryption-Key-Generation-Function”. Only the patch generator, such as in a patch server, and the digital device have the Encryption-Key-Generation-Function. When this function is put into the digital device, it can be put into a safe place in the digital device, such as SIM card of cellular phones for further protection.
- Encryption-Key-Generation-Function it is not possible to correctly generate encryption keys, and patch data cannot be encrypted correctly.
- encryption becomes more secure, because encryption keys are not unchangeable and saved in a digital device, instead, the encryption keys can be dynamically generated by an algorithm and can be changeable.
- the Encryption-Key-Generation-Function can have multiple input parameters, which can be named as “Secret-Data”.
- the Secret-Data can be some predetermined parameters.
- the Secret-Data can also be some dynamically generated parameters.
- the Secret-Data can be generated based on patch identifier information of a specific patch. Because the patch identifier is different from one patch to another patch, the Secret-Data of patch identifier is also different, and thus the generated encryption keys from Encryption-Key-Generation-Function are different from one patch to another patch. And in this case, the patch identifier information can be acknowledged between patch generator and the digital device for patch encryption and patch decryption. Some other information such as date and time information can also be used as an element for dynamically generating the Secret-Data, so that the encryption keys generated by the Encryption-Key-Generation-Function becomes time-sensitive.
- some Secret-Data can also be generated dynamically by digital device and sent to the patch generator for patch encryption.
- a big random number can be generated in a digital device and sent to patch generator when the digital device inquires whether there are patches available for software update, and the patch generator can use this number for encrypting patch for this digital device.
- the encryption process may have the following steps.
- Step 1 A digital device generates a Secret-Data.
- Step 2 The generated Secret-Data is sent from the digital device to a patch generator.
- Step 3 The Secret-Data is used for encrypting a patch in the patch generator.
- Step 4 The encrypted patch from Step 3 is sent to the digital device.
- Step 5 The digital device uses the Secret-Data generated in Step 1 to decrypt the received patch.
- Patch data is preferably separated into several patch data packets, and one patch data packet can be carried by one message.
- one patch data packet may be carried by one SMS message.
- some characters in a patch SMS message can be set to some predefined special characters or numbers by the patch server before patch delivery.
- a patch data packet can be separated into packet overhead field and payload data field. It should be appreciated by those skilled in the art that other ways of design packet overhead for transmitting patch data packets can readily be implemented in connection with the teaching of the present invention.
- the payload data in the patch data packet may contain the whole or one part of patch data.
- the digital device can restore the new program code by using the information of the original program code and the difference information between the new code and the original code.
- FIG. 14 describes a system for collecting and reporting information about software errors.
- Useful information related to software errors can be collected and recorded into the error database 1430 .
- some software traces can be inserted into the program so that the software developer can detect how the software is running by looking at the trace output. Especially, some traces can be inserted for software error cases, so that when software problems happen, the corresponding traces can be output for software debugging purposes. The information about those errors traces can be sent to the error database 1430 for further processing.
- the CPU/DSP in the digital device may reset. For example, when CPU/DSP is instructed to read data from a memory address where actually there is no memory there, an internal error will happen to cause CPU reset. Any useful information related to a reset can be retrieved and recorded. For example,
- the information of software errors can be saved in the error database 1430 , which is an area of Non-Volatile memory.
- the information of error traces can be saved into error database when error traces is produced.
- the information of system reset can be saved into error database right before the system reset, or for some cases after the system reset.
- the data saved in the error database can be retrieved for further processing 1440 .
- the data can be analyzed and summarized, so that it becomes easier for the software developer to understand.
- the data can be compressed to remove redundancy and un-important part before being transferred to an outside server or database.
- the compressed data can be transferred 1450 to an outside server or a database, and later on, the software developer can use the data to find the software errors and make the corresponding corrections.
- the compressed data can be put into SMS messages for transmission.
- the data can be further encrypted before transmission; and at receiver side, the received data will be decrypted.
- Flash A type of constantly-powered nonvolatile memory that can be erased and reprogrammed in units of memory called blocks.
- MCU Micro Processor Unit.
- RAM Random Access Memory
- ROM Read-Only Memory
- SMS Short Message Service.
Abstract
A method and apparatus of updating an embedded software operative in a digital device by a software patch comprises first preparing said embedded software. The method also comprises designating at least one Flash block of a Flash memory in said digital device as Flash update block for software update programming, designating at least one area in RAM memory in said digital device as RAM update buffer for Flash programming, preparing Flash erasing function and Flash writing function, designating a memory area in said digital device as patch area, loading said embedded software into said digital device. The method then comprises generating a software patch, adapted to provide a predetermined function, transmitting said software patch to said digital device through a communications link, receiving said software patch by said digital device, updating at least one Flash block of said embedded software in the unit of Flash block said software patch.
Description
- The present application is a continuation of a prior patent application, Ser. No. 10/876,503, filed Jun. 24, 2004, which is a continuation of application, Ser. No. 10/195,199, filed on Jul. 15, 2002, now U.S. Pat. No. 6,760,908, claiming priority from provisional applications, Application No. 60/305,704, entitled “Embedded Software Patch System”, filed on Jul. 16, 2001, and No. 60/354,915, entitled “Embedded Software Patch System”, filed Feb. 8, 2002. The prior applications are hereby incorporated into this application by reference as if fully set forth herein.
- The present invention is related to digital electronics products with embedded software operating systems, and more particularly related to methods of updating, correcting, modifying or upgrading the embedded software in such digital devices before or after the products have been released to market.
- For the digital devices, such as cellular phones, PDAs and set-top boxes, their digital technology is based on large-scale embedded software system. Despite improvement in various stages of digital device development and manufacturing, after a digital device has been released to the field, manufactures will sometimes go through improvement, enhancement or upgrades, which may require a change in the embedded software.
- Software update systems for embedded software have been in use by industry. However, they have not provided an efficient way for updating embedded software with small amount of update data. They also have failed to teach how to transmit such software update data to the digital devices. For example, U.S. Pat. No. 5,699,275, to Beasley, teaches the use of “rewrite” to update embedded software in a digital device that uses Flash/ROM memory. Nowadays, as the size of embedded software in digital devices gets bigger and bigger, “rewrite” is both time-consuming and costly and hence not an efficient method for a real commercial system.
- A software update system for digital devices is best understood from a system architecture perspective. Reference is to
FIG. 1 , where a simplified conventional microprocessor system is illustrated. A microprocessor system in a typical digital device may comprise a Central Processing Unit (“CPU”) 100, Random Access Memory (“RAM”) 110, Flash/ROM memory 120, and someperipheral devices 130. A software program resides in Flash/ROM memory 120, and is read byCPU 100 during execution. Flash is a type of constantly-powered nonvolatile memory that can be erased and reprogrammed in units of memory called blocks. The term “ROM” stands for “Read Only Memory”. - Similar to the microprocessor system of
FIG. 1 , a Digital Signal Processor (“DSP”) system in a conventional digital device may comprise aDSP core 200,RAM 210, Flash/ROM memory 220, and someperipheral devices 230, as shown inFIG. 2 . A software program resides in Flash/ROM memory 220, and is read by DSPcore 200 during execution. - As is well understood, a typical digital device, e.g. a digital cellular phone, normally contains a microprocessor system, and may also contain a DSP system. A typical software update system can be configured or adapted to reside in the embedded software of the microprocessor system and/or the DSP system of a digital device. A simplified drawing of a conventional software architecture of a software update system in a digital device is illustrated in
FIG. 3 . - Referring to
FIG. 3 , the patch receivingmodule 300 is for receiving software patch data. It may include mechanism for data receiving either from wired link or wireless link, mechanism for data error detection and/or mechanism for data security check. After the patch receivingmodule 300 correctly receives patch data, it will pass the patch data to thepatch programming module 310. Thepatch programming module 310 is for writing patch data into thepatch database 320 and/or some program code areas. It may include program for writing data into Flash, NVM, EEPROM memory, and/or other types of memory. Thepatch database 320 is a memory area in Flash memory and/or other types of memory, which is for containing patch data. - It would be desirable to have an effective patch update system for the embedded software in digital devices.
- The present invention is directed to a method of updating embedded software using software patches. This approach can separately update one or multiple parts of the embedded software without changing program code of the other parts. Such updates can be transmitted to the target digital devices through wireless or wired transmission.
- In accordance with one embodiment of the present invention, a method and apparatus of updating an embedded software operative in a digital device by a software patch is disclosed. The method comprises preparing said embedded software, which comprises designating at least one Flash block of a Flash memory in said digital device as Flash update block for software update programming, designating at least one area in RAM memory in said digital device as RAM update buffer for Flash programming, preparing Flash erasing function and Flash writing function, designating a memory area in said digital device as patch area, loading said embedded software into said digital device. The method then comprises generating a software patch, adapted to provide a predetermined function, transmitting said software patch to said digital device through a communications link, receiving said software patch by said digital device, updating at least one Flash block of said embedded software in the unit of Flash block with said software patch.
- 1. A method and system of updating one or multiple software functions of embedded software without changing software code in the other functions is disclosed. In the following detailed description, numerous specific details are set forth to provide a full understanding of the present invention. It will be obvious, however, to one ordinarily skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and techniques have not been shown in detail so as to avoid unnecessarily obscuring the present invention. Additionally, headings are used throughout the description as a matter of convenience and for ease of references only. It should note that what is meant by “embedded software” herein is the software program written in C/C++/Java/Assembler, or other software programming languages, as well as any executable machine code of CPU/Microprocessor or DSP (“Digital Signal Processor”), for operating the digital devices. It should also be noted that what is meant by “software patch” herein is a block of software update data for updating the embedded software in the digital devices.
- 2. Composition of Software Update System
- The embedded software in a digital device is typically stored in ROM/Flash memory, and the present invention is directed to updating the embedded software stored in Flash memory. The software update system of the present invention can be configured or adapted to reside in the embedded software of the microprocessor system and/or the DSP system of a digital device. The software update system in accordance with one embodiment of the present invention, when it is implemented in a digital device, may be structured to comprise a
software module 300 for patch receiving, asoftware module 310 for patch programming and apatch database 320, as illustrated byFIG. 3 . - 3. Software Update Methods
- 3.1 Flash Memory Composition
- The software update methodology of the present invention will now be described first with references to a basic Flash memory composition and operation. As shown in
FIG. 4 , a typical Flash memory chip is composed by multiple Flash banks, Bank-1, Bank-2, . . . Bank-N, and each bank can be further separated into multiple Flash blocks. For example, Bank-1 can be separated into Block-1, Block-2, . . . , Block-M. Though some other terms, such as Flash “partition”, can also be used to represent a Flash “bank”, in this application, only the term Flash “bank” is used to represent the meaning. - The embedded software in a digital device is typically programmed into K banks of the Flash memory, Bank-1, Bank-2, . . . , Bank-K, where K is the total number of the Flash banks that the embedded software occupied, and K is less or equal to N, where N is the total number of banks allocated.
- In a typical Flash memory chip, such as the Intel 28F320W30 Flash memory chip, only one Flash bank at a time can be in the state of active programming or erasing. While writing or programming data into an area in a Flash bank, for example Flash Bank-A, it is not permissible to read any data stored in that Flash Bank-A, though some values of Flash registers can be read or using some addresses in the Flash Bank-A. However, when writing data into the Flash Bank-A, it is permissible to read data stored in any other Flash banks different from Bank-A. When erasing operation is performed on a Flash bank, each Flash block in the Flash bank can be separately erased.
- Flash memory has a feature that each data bit of the memory can only be changed from state “1” to state “0” during Flash programming or data writing. A data bit in Flash memory cannot be changed separately from state “0” to state “1”. It depends on Flash erasing, for example, erasing a Flash block, to reset all the data bits in the Flash block to state “1”. Therefore when a part of the program code in Flash memory needs to be updated, it is not possible, nor permissible, to directly over-write the original program code with the new updated program code, without erasing the corresponding Flash block.
- 3.2 Using Flash Block as the Unit for Software Update
- Due to the above limitations of conventional Flash memory operation, some methods of utilizing instead the Flash bank as the unit to update embedded software have been developed by those in the art. They use the Flash bank as the basic unit, because it is possible to read data from a Flash bank and simultaneously write data into another Flash bank. They use an entire Flash bank as a “buffer” to temporarily store the updated software during software updating process. During software updating, and the embedded software is updated in the unit of Flash bank.
- However, using a Flash bank as a “buffer” is not an efficient way for utilizing Flash memory, because a Flash bank can have several mega bits, which is quite a big area. In some digital devices, one entire Flash bank may not be available as a buffer just for software update purpose. Even if the bank may be available, updating an entire bank has proved to be an extremely wasteful and inefficient way of updating what may be a minor code revision.
- As will be described, the present invention is directed to the use of a Flash block, which is much smaller than a Flash bank, as the “buffer” for software update, and the embedded software is updated in the unit of a Flash block, instead of the unit of a Flash bank. With this methodology, only one Flash block will be enough as the buffer for the purpose of software update programming, which is much smaller than one Flash bank. Another advantage of this methodology is that, because it becomes possible to make software update in the unit of a Flash block, software updating can be performed in a more precise and efficient way than the conventional method based on the unit of a Flash bank. Thus, the software update programming can be completed in a shorter period of time.
- 3.3 Updating Software Directly in Original Flash Area
- When the original embedded software is located in a first Flash bank, the aforementioned Beasley's U.S. Pat. No. 5,699,275 disclosed a method of writing new program into a second Flash bank and using the second Flash bank for execution after a system reset. However, as discussed before, it is not an efficient way of using Flash memory by allocating a big blank Flash bank for containing the entire new version of the embedded software while the original is running in another Flash bank. And this problem, as well as its limitation, will be more exacerbated when the embedded software becomes big, occupying multiple Flash banks.
- In order to efficiently use Flash memory, this invention is directed to a methodology to make software update directly at the original Flash area, without the need of preparing a big blank Flash bank for containing the entire new version of the embedded software. In accordance with this method, the embedded software is updated in the unit of Flash block, and the updated program code is still allocated at the original Flash blocks. Therefore, a software update system in accordance with the present invention will greatly save the Flash memory usage for software update.
- The details of performing software update in the unit of Flash block are disclosed in the following sections.
- 3.4 Putting Flash Programming Functions Into RAM Memory
- Flash programming functions, such as data writing function and flash erasing function are stored in Flash memory, for example, in a Flash bank, Bank-K. Here more specifically, the Flash programming functions refer to a “Flash-Writing-Function” and a “Flash-Erasing-Function”. The Flash-Writing-Function is a function to write or program data into Flash memory. The Flash-Erasing-Function is a function to erase a block of Flash memory.
- Let us look at an example that during software update, it is necessary to update some program code in the flash Bank-K. If the Flash programming functions stored in the Bank-K are also running on the Bank-K, the CPU/DSP needs to read program instructions of the Flash programming functions from Bank-K for execution, while performing Flash programming of software-update actions, such as data writing or flash erasing, on the same Bank-K for updating some program code in the Bank-K. However, as previously discussed, it is not possible to perform reading and writing operation simultaneously on the same Flash bank. In accordance with the present invention, Flash programming functions, i.e. the Flash-Writing-Function and the Flash-Erasing-Function, are copied into RAM memory, and then run in the RAM memory. When the Flash programming functions are running in RAM memory, and it becomes possible to perform Flash data writing and Flash block erasing operations on Bank-K, for updating the embedded software located in the Bank-K, thus avoiding the otherwise prohibited simultaneous data reading and writing operations on the Bank-K during Flash programming.
- Some existing program compilers can also support putting software functions into RAM memory and running those functions in RAM memory, by setting some configuration parameters for software compilation (including module linking). In this case, copying the Flash programming functions into RAM memory can be done by the compilers. If a software compiler does not support this function, some software functions can be created for achieving the similar actions, and added into the embedded software.
- Note that if a digital device has enough Flash memory space, but very limited RAM memory space, the Flash programming functions can be put into a Flash bank separated from the Flash banks containing the embedded software that may need to be updated, instead of being put into RAM memory. This Flash bank is thus used for the purpose of Flash programming for the other Flash banks. This method can be used as a replacement of the above method of using RAM memory.
- 3.5 Using a Buffer in RAM Memory
- During software update, sometimes it may be desirable to copy some program code from one block, Block-A, of a Flash bank to another block, Block-B, in the same Flash bank. However, as previously discussed, it is not possible to perform reading and writing operation simultaneously on the same Flash bank. To overcome this problem, a memory area located in RAM memory is utilized for buffering data during Flash programming. The buffer in RAM memory can be named as “RAM-Update-Buffer”. The size of RAM-Update-Buffer can be decided based on how large the space in RAM memory in the digital device can be used for software updating.
- As shown in
FIG. 5 , when performing Flash programming with the RAM-Update-Buffer, for example, in the same Flash bank, copying some program code from Block-A to Block-B, the program code will be first copied into the RAM-Update-Buffer from Block-A, and then be programmed into Block-B by reading the data from the RAM-Update-Buffer. In this way, the otherwise prohibited simultaneous reading and writing operations on the same Flash bank can be avoided. If the RAM-Update-Buffer is no big enough to contain the whole program code that need to be copied, the program code that needs to be copied can be separated into multiple parts to ensure each part can fit into the RAM-Update-Buffer. In this case, Flash programming is performed for each part of the program code, by first copying the code into the RAM-Update-Buffer from Block-A, and then writing the code into Block-B by reading the code from the RAM-Update-Buffer. - As a summary, copying data from a Flash block, Block-A, into another Flash block, Block-B, can be performed in the following steps.
- Copying Data From Block-A to Block-B:
- Step1: Check the length of the data to be copied from the Block-A with the size of the RAM-Update-Buffer, and copy the amount of the data in the Block-A that can fit into the RAM-Update-Buffer into the RAM-Update-Buffer.
- Step2: Run the flash programming functions in the RAM memory to read the data from the RAM-Update-Buffer and write the data into the Block-B.
- Step3: If there is still data left in the Block-A that need to be copied into the Block-B, go back to Step1 for further copying, until all the data is copied into the Block-B.
- 3.6 Updating a Flash Block
- When some part of the embedded software in a digital device needs to be updated, a corresponding software patch can be generated to contain the information of update code for updating the part of the embedded software. The software patch can be sent to the digital device via a communication link, either a wired link or a wireless link.
- After correctly receiving the software patch by the
patch receiving module 300 inFIG. 3 , the digital device passes the patch data to thepatch programming module 310. Thepatch programming module 310 is for writing patch data into thepatch database 320 and/or the program code area of the part that needs to be updated. - As discussed on the above Section 3.1 to Section 3.5, this invention uses a Flash block as a “buffer” for software update, and performs software update in the unit of Flash block. In order to support the software update, the following preparation should preferably be performed.
- Pre-Process Preparation:
- (1) Reserve one Flash block as a buffer for update-programming purpose, as discussed in Section 3.2. This block can be named as “Update-Buffer-Block”. If the sizes of Flash blocks are not identical, one or multiple Flash blocks shall be reserved to ensure having enough buffer space for buffering the data of the biggest Flash block. Here for convenience, the term of “Update-Buffer-Block” is still used for the cases that multiple Flash blocks are used for data buffering, because they can be treated as a single buffer. The buffer erasing operation should be performed for each block when necessary.
- (2) Reserve a RAM-Update-Buffer in RAM memory, as discussed in Section 3.5. The size of the RAM-Update-Buffer is assumed to be T bytes.
- (3) Placing the Flash programming functions, i.e., the Flash-Writing-Function and the Flash-Erasing-Function, into RAM memory for running, as discussed in Section 3.4.
- If the program code of in a Flash bank, more specifically in a Flash block of the bank, needs to be updated, here the Flash block is named as “Block-A”, the update programming can be performed with the following steps. Note that these steps are only for exemplary purpose to show the inventions details, implementation details may vary based on the situation of the embedded software and the digital device.
FIG. 6 also shows the exemplary programming steps for illustration purposes. - Flash Block Updating Process for Updating Flash Block-A:
- Step 1:
- Erase the Update-Buffer-Block by running the Flash-Erasing-Function in the RAM memory, so that all the data bits in the Update-Buffer-Block are in state “1”.
- Step 2:
- Copy the program code of the Block-A into the Update-Buffer-Block, except the part of the program code to be updated. That means, the corresponding code area in the Update-Buffer-Block for the part of the program code to be updated, which can be named as “Update-Area”, should not be written with the original program code of Block-A. The process of copying data from the Block-A into the Update-Buffer-Block is previously described by the process of “copying data from Block-A to Block-B” in Section 3.5. If necessary, other methods of copying data from one FLASH block to another FLASH block can be used.
- Step 3:
- Copy the updated program code into the Update-Area of the Update-Buffer-Block. If the updated program code is stored in an area of Flash memory beforehand, the process of copying the updated program code into the Update-Area of the Update-Buffer-Block may follow the process of “copying data from Block-A to Block-B” previously described in Section 3.5, if necessary, other methods of copying data from one FLASH block to another FLASH block.
- Step 4:
- Erase Block-A by running the Flash-Erasing-Function in RAM memory.
- Step 5:
- Copy the content in the Update-Buffer-Block into Block-A. The process of copying data from the Update-Buffer-Block into the Block-A may follow the process of “copying data from Block-A to Block-B” previously described in Section 3.5, if necessary, other methods of copying data from one FLASH block to another FLASH block can be used.
- With the above exemplary steps, the program code in Block-A that needs to be updated can be replaced with the new program code, while the other code in the Block-A remains unchanged and also the program code in other Flash blocks remain unchanged. Note that the
above Step 3 can be skipped if a step of copying the updated program code directly into the corresponding Update-Area of the Block-A is added after theabove Step 5. In this case, the Update-Area of the Update-Buffer-Block in theabove Step 5 is “empty,” i.e. filled with hexadecimal “0×FF”, when the entire block is copied back to the Block-A. The program update code then overwrites the now-empty Update-Area in the Block-A, thus effecting a Block update. - If there are multiple Flash blocks in the digital device that need to be updated, the above Update-Programming steps can be carried out for each of the blocks.
- In order to ensure that the Update-Programming can be performed successfully, it may be necessary to ensure that there will be no task switching happening during the process of the Update-Programming in the Real Time Operation System of the digital device. This can preferably be achieved by setting the task or thread for the Update-Programming in the Real Time Operation System to the highest priority, and disabling the interrupt functions of CPU/DSP during the Update-Programming.
- As can be appreciated, the Flash Block Updating methodology described above can be done without having to pre-process or prepare any insertion or jump checkpoints into the code during initial programming. Also, the existing code in the digital device does not need to be altered to accommodate the Updating methodology, thus making it quite compatible with the goal of providing software updates to any electronic or digital devices already out in the field.
- 3.7 Software Update Methodology
- Several software update methods are disclosed in this section, in accordance with the previously described “Method of updating Flash block” in section 3.6.
- One embodiment of the software update is now described with reference to
FIG. 7 . Here, after a software patch or program code of update has been received, it can be programmed into an update code area or patch area in Flash memory. When CPU/DSP execution is running to the part of program that needs to be updated, the CPU/DSP execution can be directed to the place of the updated program code in the update code area, or patch area, and uses the updated program code for execution, instead of using the original part of program for execution. To redirect the CPU/DSP execution, at the beginning of the program part to be updated, a jumping instruction can be allocated for jumping to the patch area. The software modification on the original code area, such as allocating a jumping instruction over the original code, can be performed with the update method described in Section 3.6, based on the Flash block update on the corresponding Flash blocks. As such, by allocating a jumping instruction at the beginning of the program to be updated using the aforementioned Flash block update methodology, the CPU/DSP execution can be redirected to the update code area, where the software patch or program code of update has been received and programmed. -
FIG. 8 shows another embodiment of the software update methodology, where some updated program code (Update Program Code Part 1) can be directly put into the program code area of the part that needs to be updated, while other updated program code (Update Program Code Part 2) can be put into the Update Code Area. When the size of the updated program code is bigger than the size of the part of the original program code that needs to be updated, Update Code Area can be used to contain the program code portion that cannot fit into the original location in the program code area. The patch programming on the original code area can be performed with the method described in Section 3.6, based on the Flash block update. -
FIG. 9 shows yet another embodiment of the update methodology, where the updated program code can be directly put into the program code area of the part that needs to be updated. This can be used in the case when the size of the updated program code is not bigger than the size of the part of the original program code that needs to be updated. At the end of such update program, a jump or skip instruction is added so that CPU execution can jump over or skip the portion of the original code that is now obsolete. The patch programming on the original code area can be performed with the method described in Section 3.6, based on the Flash block update. - 4. Methods of Error Recovery During Software Update
- During the process of updating software, errors or interrupts, such as electricity power loss, could happen. For example, when a cellular phone, or a digital device, is performing software update using the method introduced in
Section 3, and during theStep 5 of Section 3.6, there is a power loss, e.g. exhausted battery. As a result of the power loss, the program code in the Update-Buffer-Block cannot be correctly copied into Block-A. When the cell phone is turned back on, after re-charging or replacing the battery, a CPU/DSP execution error will happen at Block-A, because there is no correct program code there. In accordance with another aspect of the invention, a methodology of error recovery for patch programming is introduced, which is shown inFIG. 10 . - As shown in
FIG. 10 , for achieving error recovery from power loss, a software routine, named “Update-Programming-Checking-Routine”, can be put at or close to the bootstrap code (program execution start point), so that when the embedded software starts to run from power-on or system reset, it will execute the Update-Programming-Checking-Routine. Though this routine is always executed from power-on or system reset, it only becomes effective after the cell phone or digital device is powered back on, after certain interruption. The Update-Programming-Checking-Routine checks whether there are any patch programming tasks that have not been completed for software update. If there are such incomplete tasks, patch programming for software update will be executed to complete the tasks. Then, the execution is back to the original program for system power-on. - In order to prevent data loss, after correctly receiving a software patch or a piece of new program code for software update, the digital device can write the new program code into Flash memory for buffering, so that even if there is a power loss during software update process, the received program code will not be lost. This area can be named as “Patch-Data-Buffer”. Some flag parameters can be used as the status indication of update-programming, which can be named as “Patch-Programming-Flag”. The Patch-Programming-Flags can be saved in an area of Flash memory. For example, a Patch-Programming-Flag composed by 5 bits, or n bits, can be reserved in an area of Flash memory to indicate the status of the 5 steps, or n steps, of the patch programming discussed in the above Section 3.6. All the bits of the flag are all in state “1” at first. When one step of the 5 steps is completed, one corresponding bit of the flag will be changed from “1” to “0”. After returning from a power loss occurring at one of the 5 steps, patch programming can be restarted by the Update-Programming-Checking-Routine. For example, if the power loss happened before
Step 4, patch programming can be re-started fromStep 1. And if the power loss happened afterStep 4, patch programming can be re-started fromStep 4 of Section 3.6. - After the update programming for a patch has been completed, the Flash area for the Patch-Data-Buffer and the Flash area for the Patch-Programming-Flags can be erased so that the next patch can reuse the same areas. In order to erase these areas, that is to set all the bits in the areas back to the state of ‘1’, the method of Section 3.6 for updating a Flash block can be used to update every bit in these areas to “1”. As discussed in Section 3.6, the update can be carried out in the unit of Flash block, and the bit values of the areas in the corresponding Flash blocks can be changed back to state of“1”.
- 5. Methods of Patch Code Generation
- As is well understood by those skilled in the art, a software patch is the replacement of a piece of the original program code. When a programmer finishes the changes on the program source code, the program source code can be compiled into an object file. The object file includes the information of an executable command code, though some parameters, such as the offsets of function calls, need to be updated by the linker of the compiler. After linking stage of the software compilation, a “map” file of the executable embedded software can be generated by the linker software. The map file may include information of variables and function addresses.
- In accordance with yet another aspect of the invention, a methodology of patch generation is introduced. A software patch can be composed by new program code and its corresponding location or memory address information in the embedded software of the digital device. The information in the object files of the new program code and the map files of both the original executable embedded software and the updated executable embedded software can be used for generating a software patch. For example, for updating an original software function with a new version of the function, the information of the corresponding executable CPU instruction code from the new object file generated based on the new version of the function, can be extracted and used as the updated program code in a patch for updating the function. Furthermore, in the map file of the original executable embedded software, the information of the function addresses can be used in the patch as the address information related to place that the patch code need to be written on.
- Some software tools can also be developed for the automatic patch generation based on the information from the object file and the map file.
- 6. Patch Transmission and Patch Receiving
- 6.1 Patch Data Transmission.
- First, we describe how the software patch may be transmitted from a patch server (to be described below) to digital devices. By “patch server,” it should be appreciated by those skilled in the art that it may be a system that can dispatch or transmit a software patch to one or more digital devices in the field, preferably through existing communication infrastructure or channels, such as a wireless link, or a wired connection. The patch server may have any level of automation for its operation. Upon transmission, a digital device receives patch data with its
Patch Receiving Module 300 shown inFIG. 3 . During or after the patch data transmission, the digital device may send signals (or messages) to the patch server for acknowledgment. - For transmitting patch data to digital cellular phones, SMS (Short Message Service) messages can be used for this purpose. SMS messages can be sent to cellular phones based on GSM, GPRS, WCDMA, CDMA or other wireless and wired technologies. Both point-to-point SMS messages and broadcast SMS messages can be used for patch transmission. Sometimes, broadcast SMS messages are also called with some other names, such as cell broadcast SMS messages. When broadcast SMS messages are used for patch transmission, some fields of the SMS messages can be set to some values, for example, some “reserved values”, so that the digital devices that have not installed the patch system can simply discard the SMS messages, and only the digital devices that have the patch system installed will process the SMS messages for software update. For example, in the SMS message defined in the GSM standard, there is a field named “Coding Group” that may have some “reserved” values not being used. In the SMS messages used for carrying patch data, the “Coding Group” can be set to one of the reserved values, so that the digital device without having patch system will simple discard the SMS messages without displaying the SMS message content to users because the digital devices cannot process the reserved “Coding Group”. But for those digital devices that have the patch system installed can process the SMS messages for software update based on a predetermined protocol.
- Sometimes, the digital device needs to send a message to patch server to inquire available patches or reporting patching status of the digital device. The identification number of patch server, such as a phone number or platform number can be pre-installed into the digital device, so that the digital device can use the server number to send the necessary messages to the patch server.
- Sometimes, the patch server needs to use the identification number of the digital device, such as a phone number to send update notice to the digital device. The identification number and other related information of the digital device can be registered on the patch server for this purpose. Many methods of the registration can be considered. For example the digital device information can be registered by the digital device user on a web site by entering the information of the digital device and the corresponding identification number; or the digital device user can send a message to the patch server including the product information and the product identification number.
- For error detection, before patch transmission, patch data can be processed with information of CRC (Cyclic Redundancy Codes), checksum or other schemes as can readily be implemented by those skilled in the art. After the digital device receives a patch, the patch data is checked with CRC process to detect transmission errors.
- In the event that a digital device cannot correctly receive patch data, the patch server shall re-send the patch data to the digital device. For example, patch retransmission can be based on a timer-based mechanism: The patch server has a timer for patch retransmission. After the patch server sends out a patch to a digital device, it will start the timer. If the patch server does not receive any corresponding reply message (e.g., patching status report) from the digital device when the timer times out, the patch server will re-send the patch data packets to the digital device. In some special cases where a patch server does not receive any reply messages from the digital device after the patch server has performed patch re-transmission for a predetermined number of times, the patch server may stop the retransmission for a while. It should be appreciated by those skilled in the art that other ways of timing the transmission and re-transmission of patches can readily be implemented in connection with the teaching of the present invention.
- In the previous example of using SMS messages, there is one patch signaling message named Patch Status Report, which is sent from a digital device to a patch server and contains the current patch status information of the digital device. If the digital device receives a patch without error, it will send Patch Status Report via a reverse SMS message to the patch server at the time:
-
- (a) when the digital device finds out that the received patch had been already programmed successfully, or
- (b) when the digital device successfully finishes the patch programming.
- 6.2 Patch Data Encryption.
- Before patch data is transmitted to a digital device, it can be encrypted for security protection. And after receiving the encrypted patch data, the digital device decrypts the patch data before using it. This is important to the cases such as using SMS message for patch data transmission, because SMS messages may be sent from any people to any cellular phones. This invention discloses some methods for patch encryption.
- 6.2.1 Dynamically Generating Encryption Keys With a Predetermined Algorithm
- Before patch data is transmitted to a digital device, the patch data can be encrypt with one or multiple encryption algorithms, such as Triple-DES etc. These encryption algorithms normally need encryption keys for encryption calculation. For security protection, the encryption keys can be generated based on a highly complicated and secured software function, and can be named as “Encryption-Key-Generation-Function”. Only the patch generator, such as in a patch server, and the digital device have the Encryption-Key-Generation-Function. When this function is put into the digital device, it can be put into a safe place in the digital device, such as SIM card of cellular phones for further protection. Without understanding the Encryption-Key-Generation-Function, it is not possible to correctly generate encryption keys, and patch data cannot be encrypted correctly. With this method, encryption becomes more secure, because encryption keys are not unchangeable and saved in a digital device, instead, the encryption keys can be dynamically generated by an algorithm and can be changeable.
- 6.2.2 Secret-Data for Encryption
- As shown in
FIG. 11 , the Encryption-Key-Generation-Function can have multiple input parameters, which can be named as “Secret-Data”. The Secret-Data can be some predetermined parameters. The Secret-Data can also be some dynamically generated parameters. For example, the Secret-Data can be generated based on patch identifier information of a specific patch. Because the patch identifier is different from one patch to another patch, the Secret-Data of patch identifier is also different, and thus the generated encryption keys from Encryption-Key-Generation-Function are different from one patch to another patch. And in this case, the patch identifier information can be acknowledged between patch generator and the digital device for patch encryption and patch decryption. Some other information such as date and time information can also be used as an element for dynamically generating the Secret-Data, so that the encryption keys generated by the Encryption-Key-Generation-Function becomes time-sensitive. - 6.2.3 Secret-Data for Encryption Transmitted From Digital Device
- As shown in
FIG. 12 , some Secret-Data can also be generated dynamically by digital device and sent to the patch generator for patch encryption. For example, a big random number can be generated in a digital device and sent to patch generator when the digital device inquires whether there are patches available for software update, and the patch generator can use this number for encrypting patch for this digital device. The encryption process may have the following steps. - Step 1: A digital device generates a Secret-Data.
- Step 2: The generated Secret-Data is sent from the digital device to a patch generator.
- Step 3: The Secret-Data is used for encrypting a patch in the patch generator.
- Step 4: The encrypted patch from
Step 3 is sent to the digital device. - Step 5: The digital device uses the Secret-Data generated in
Step 1 to decrypt the received patch. - 6.3 Patch Data Composition.
- With reference to
FIG. 13 , the composition of patch data is now further described. Patch data is preferably separated into several patch data packets, and one patch data packet can be carried by one message. - In the exemplary use of SMS messages, one patch data packet may be carried by one SMS message. In order to identify a patch SMS message from other regular SMS messages, some characters in a patch SMS message can be set to some predefined special characters or numbers by the patch server before patch delivery.
- The relation between patch data and patch data packets is shown in
FIG. 13 . A patch data packet can be separated into packet overhead field and payload data field. It should be appreciated by those skilled in the art that other ways of design packet overhead for transmitting patch data packets can readily be implemented in connection with the teaching of the present invention. - The payload data in the patch data packet may contain the whole or one part of patch data.
- If some part in the new program code used for updating is similar or identical to some part in the original program code, some instruction of using the original code can be put into the patch, instead of the new code itself. In general, when a piece of program needs to be updated, only the information of the difference between the new code and the original code should be put into patch. In this way, the duplicated information of program code can be removed from a patch, in order to reduce the patch size. After receiving such a patch, the digital device can restore the new program code by using the information of the original program code and the difference information between the new code and the original code.
- 7. Collecting and Reporting Software Error Information in Digital Devices
- It is preferable to collect information about the software errors existing in the embedded software of a digital device and report the information to software developer, so that the software developer can create the corresponding software patches to fix the errors in the digital device, or modify the corresponding software program to remove the errors from future digital devices. Here some methods are disclosed for collecting and reporting the information about the software errors.
FIG. 14 describes a system for collecting and reporting information about software errors. - Collecting Information About Software Errors in a Digital Device
- Useful information related to software errors can be collected and recorded into the
error database 1430. Here two types of information—software error traces and system reset information are used 1410 to show how to collect and record the information. - When a software developer creates a software program, some software traces can be inserted into the program so that the software developer can detect how the software is running by looking at the trace output. Especially, some traces can be inserted for software error cases, so that when software problems happen, the corresponding traces can be output for software debugging purposes. The information about those errors traces can be sent to the
error database 1430 for further processing. - When some fatal software errors happen and cannot be recovered, the CPU/DSP in the digital device may reset. For example, when CPU/DSP is instructed to read data from a memory address where actually there is no memory there, an internal error will happen to cause CPU reset. Any useful information related to a reset can be retrieved and recorded. For example,
-
- Call stack information: information of procedures, programs, and methods that are executing right before reset.
- Reset type: the information about why reset is performed.
- Time stamp: time information when error or reset occurs
- Saving Error Information
- The information of software errors, such as error traces and reset information can be saved in the
error database 1430, which is an area of Non-Volatile memory. The information of error traces can be saved into error database when error traces is produced. The information of system reset can be saved into error database right before the system reset, or for some cases after the system reset. - Error Information Processing
- When it is necessary to analyze the error information, the data saved in the error database can be retrieved for
further processing 1440. For example, the data can be analyzed and summarized, so that it becomes easier for the software developer to understand. The data can be compressed to remove redundancy and un-important part before being transferred to an outside server or database. - Error Information Transmission
- After the above processing step, the compressed data can be transferred 1450 to an outside server or a database, and later on, the software developer can use the data to find the software errors and make the corresponding corrections. For example, for a typical digital cellular phone, the compressed data can be put into SMS messages for transmission. To enhance security, the data can be further encrypted before transmission; and at receiver side, the received data will be decrypted.
- Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the scope of the present invention. Accordingly, the invention should only be limited by the claims included below.
- Glossary of Abbreviations
- ASCII. American Standards Committee for Information Interchange
- CPU. Central Processing Unit.
- DSP. Digital Signal Processor
- Flash. A type of constantly-powered nonvolatile memory that can be erased and reprogrammed in units of memory called blocks.
- MCU. Micro Processor Unit.
- PDA. Personal Digital Assistant
- RAM. Random Access Memory.
- ROM. Read-Only Memory.
- SMS. Short Message Service.
Claims (35)
1. A method of updating an embedded software operative in a digital device by a software patch, comprising:
preparing said embedded software comprising:
designating at least one Flash block of a Flash memory in said digital device as Flash update block for software update programming;
designating at least one area in RAM memory in said digital device as RAM update buffer for Flash programming;
preparing Flash erasing function and Flash writing function;
designating a memory area in said digital device as patch area;
loading said embedded software into said digital device;
generating a software patch, adapted to provide a predetermined function;
transmitting said software patch to said digital device through a communications link;
receiving said software patch by said digital device;
updating at least one Flash block of said embedded software in the unit of Flash block with said software patch.
2. The method of claim 1 , wherein said updating at least one Flash block comprises at least one of the following:
allocating a jump instruction at the beginning of the program part of the embedded software to be updated, for jumping to said patch area when running a new update code in said patch area;
overwriting some part of the program part of the embedded software to be updated with a new update code, and allocating, at the end of the part, a jumping instruction for jumping to said patch area when running the new update code in said patch area;
overwriting the program part of the embedded software to be updated with the new update code.
3. The method of claim 1 , wherein said step of preparing Flash erasing function and Flash writing function further comprises:
putting at least one function of said Flash erasing function and said Flash writing function into RAM memory.
4. The method of claim 3 , wherein said step of putting Flash programming functions into RAM memory comprises at least one of the following:
using a software function for copying said Flash programming functions into RAM memory, and
using a software compiler for allocating said Flash programming functions into RAM memory
5. The method of claim 3 , wherein said Flash function is run in one of the following ways:
a) in said RAM memory;
b) in at least one software interrupt handler routine;
c) in highest priority task of software operation system of said embedded software.
6. The method of claim 1 , wherein said updating further comprises:
erasing said Flash update block;
copying data from said Flash block into said Flash update block, except the part to be updated;
writing update data into the part to be updated in said Flash update block;
erasing said Flash block;
copying data from said Flash update block into said Flash block;
7. The method of claim 1 , wherein said updating at least one Flash block further comprises:
erasing said Flash update block;
copying data in from Flash block into said Flash update block, except the part to be updated;
erasing said Flash block;
copying data from said Flash update block into said Flash block;
writing update data into the part to be updated in said Flash block;
8. The method of claim 6 , wherein said copying data from a first Flash block to a second Flash block comprises:
checking whether said data can fit into said RAM update buffer, and if not, separating said data into multiple parts to ensure each part of said data can fit into said RAM update buffer;
for each part, performing the steps of:
reading said data from said first Flash block and writing said data into said RAM update buffer;
reading said data from said RAM update buffer and writing said data into said second Flash block.
9. The method of claim 7 , wherein said copying data from a first Flash block to a second Flash block comprises:
checking whether said data can fit into said RAM update buffer, and if not, separating said data into multiple parts to ensure each part of said data can fit into said RAM update buffer;
for each part, performing the steps of:
reading said data from said first Flash block and writing said data into said RAM update buffer;
reading said data from said RAM update buffer and writing said data into said second Flash block.
10. The method of claim 1 , wherein said preparing said embedded software further comprises:
allocating at least one update programming checking routine at or close to the bootstrap code (program execution start point), to check whether there are any patch programming tasks that have not been completed for software update, and
if yes, executing patch programming for software update to complete the tasks;
returning execution to the original program for system power-on.
11. The method of claim 10 , further comprising:
using at least one bit of Flash memory as patch programming flag to indicate patch programming status.
12. The method of claim 1 , wherein said step of generating a software patch further comprises:
using at least one of the following information to generate said software patch:
Object file of the new program code;
Software function and variable map file generated by software compiler.
13. The method of claim 1 , wherein said step of transmitting said software patch further comprises:
using at least one SMS message to carry data of said software patch.
14. The method of claim 1 , wherein said step of preparing said embedded software further comprises:
pre-installing identification information of patch server into said digital device.
15. The method of claim 1 , further comprising:
registering an identification number and other related information of the digital device on the patch server, using at least one of the following methods:
registering the digital device information by the digital device user on a web site by entering the information of the digital device and the corresponding identification number;
sending by the digital device user of a message to the patch server including the product information and the product identification number.
16. The method of claim 1 , further comprising:
said digital device sending at least one message to the patch server for at least one of the following:
for reporting patching status;
for inquiring available patch information.
17. The method of claim 1 , wherein said step of generating a software patch further comprises:
adding at lest one of the following data to said software patch for data error detection:
CRC (“Cyclic Redundancy Codes”) data;
Checksum data.
18. The method of claim 1 , wherein said step of generating a software patch further comprises: encrypting said software patch before patch transmission.
19. The method of claim 18 , further comprising:
encrypting said software patch using at least one of the following information:
identification information of said software patch;
identification information of said digital device;
time information;
dynamically generated secret data.
20. The method of claim 18 , further comprising the following steps:
said digital device generating secret-data and sending said secret-data to a patch generator;
said patch generator receiving said secret-data to encrypt said software patch using said secret-data;
said patch generator sending encrypted software patch generated to said digital device;
said digital device receiving said encrypted software patch and uses said secret-data generated to decrypt said received encrypted software patch.
21. The method of claim 1 , wherein said step of generating a software patch further comprises:
putting the information of the difference between the new code and the original code into said software patch to reduce transmission amount.
22. A method of updating an embedded software operative in a digital device by using a software patch, comprising:
designating at least one Flash block of a FLASH memory in said digital device as Flash update block for software update programming;
designating at least one area in a RAM memory in said digital device as RAM update buffer for Flash programming;
designating a patch area in said digital device;
preparing said embedded software;
preparing said software patch;
loading said embedded software into said digital device;
preparing said software patch for transmission to said digital device through a communication link.
23. The method of claim 22 , further comprising:
encrypting said software patch prior to transmission, with an encryption key generation function.
24. A method of updating an embedded software operative in a digital device, comprising:
receiving a software patch by said digital device through a communications link;
updating at least one predetermined Flash block of a FLASH memory of said digital device containing said embedded software, in the unit of Flash block with said software patch, by at least one of the following:
a) allocating, at the beginning of the program part to be updated, a jumping instruction for jumping to said patch area for running the new code in said patch area;
b) overwriting some part of the program part to be updated with the new update code, and at the end of the part, allocating a jumping instruction for jumping to said patch area for running the new code in said patch area;
c) overwriting the program part to be updated with the new update code.
25. The method of claim 24 , wherein said software patch is encrypted and has an encryption key generation function, which is placed in a predetermined safe place for safekeeping.
26. A method of updating an embedded software operative in a digital device, comprising:
receiving a software patch by said digital device through a communication link;
designating a first Flash block in said Flash memory;
designating a second Flash block (“Update Buffer Block”) in a Flash memory of said digital device;
copying good code that does not need to be updated from said first Flash block to a first predetermined location of said Update Buffer Block;
writing said software patch (“Program Update Code”) to a second predetermined location of said Update Buffer Block;
erasing said first Flash block;
copying said entire Update Buffer Block to said first Flash block, wherein said first Flash block is now updated.
27. A method of updating an embedded software operative in a digital device, comprising:
receiving a software patch by said digital device through a communication link;
designating a first Flash block in said Flash memory;
designating a second Flash block (“Update Buffer Block”) in said Flash memory of said digital device;
copying good code from a first Flash block to a first predetermined location of said Update Buffer Block;
erasing said first Flash block;
copying said entire Update Buffer Block to said first Flash block;
writing said software patch (“Program Update Code”) to a predetermined location of said first Flash block, wherein said first Flash block is now updated with the Program Update Code.
28. A method of updating an embedded software operative in a digital device, said method comprising:
providing a Flash memory in said digital device;
storing said embedded software as program code in said Flash memory (“Program Code Area”);
designating a patch area within said Flash memory;
receiving a software patch by said digital device through a communication link;
programming said software patch into said patch area as update program code;
inserting a jump instruction to a location in said Program Code Area, which is the beginning of a portion of said program code to be updated, said jump instruction causing execution of said program code to be jumped to said update program code.
29. A method of updating an embedded software operative in a digital device, said method comprising:
providing a Flash memory in said digital device;
storing said embedded software in said Flash memory (“Program Code Area”);
designating a patch area within said Flash memory;
receiving a software patch by said digital device through a communication link;
programming a first portion of said software patch as a first portion of updated program code into said Program Code Area;
programming at least a second portion of said software patch into said patch area as a second portion of updated program code;
inserting a jump instruction to a location in said Program Code Area, which is the end of said first portion of said updated program code, said jump instruction causing execution to jump to said second portion of said updated program code after execution of said first portion of said updated program code.
30. A method of updating an embedded software operative in a digital device, said method comprising:
providing a Flash memory in said digital device;
storing said embedded software in said Flash memory (“Program Code Area”);
designating a patch area within said Flash memory;
receiving a software patch by said digital device through a communication link;
programming said software patch as updated program code into said Program Code Area;
if said updated program code can be fully contained in said Program Code Area, inserting a jump instruction to the end of said updated program code, said jump instruction causing execution to jump to the remaining of said Program Code Area after execution of said updated program code.
31. A method of managing software error information in a software program operative in a digital device, said method comprising:
allocating an area in non-volatile memory for use by an error database in said digital device;
inserting a plurality of software traces into said software program, said traces monitoring operating condition of said software program and outputting error information when encountering software errors;
transmitting said error information to said error database;
processing said error information in said error database;
retrieving said error information from said error database for analysis.
32. The method of claim 31 , wherein said retrieving said error information comprises transmitting said error information via SMS messages from said digital device.
33. The method of claim 31 , further comprising:
collecting reset information for system resets in said digital device;
transmitting said reset information to said error database;
processing said reset information in said error database;
retrieving said reset information from said error database for analysis.
34. The method of claim 33 , wherein said retrieving said reset information comprises transmitting said reset information via SMS messages from said digital device.
35. The method of claim 33 , wherein said reset information comprises at least one of the following:
call stack information;
reset type information;
time stamp.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/986,258 US20050063242A1 (en) | 2001-07-16 | 2004-11-09 | Embedded software update methods and systems for digital devices |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US30570401P | 2001-07-16 | 2001-07-16 | |
US35491502P | 2002-02-08 | 2002-02-08 | |
US10/195,199 US6760908B2 (en) | 2001-07-16 | 2002-07-15 | Embedded software update system |
US10/876,503 US20040237068A1 (en) | 2001-07-16 | 2004-06-24 | Embedded software update system |
US10/986,258 US20050063242A1 (en) | 2001-07-16 | 2004-11-09 | Embedded software update methods and systems for digital devices |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/876,503 Continuation US20040237068A1 (en) | 2001-07-16 | 2004-06-24 | Embedded software update system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050063242A1 true US20050063242A1 (en) | 2005-03-24 |
Family
ID=26974732
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/195,199 Expired - Fee Related US6760908B2 (en) | 2001-07-16 | 2002-07-15 | Embedded software update system |
US10/876,503 Abandoned US20040237068A1 (en) | 2001-07-16 | 2004-06-24 | Embedded software update system |
US10/986,258 Abandoned US20050063242A1 (en) | 2001-07-16 | 2004-11-09 | Embedded software update methods and systems for digital devices |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/195,199 Expired - Fee Related US6760908B2 (en) | 2001-07-16 | 2002-07-15 | Embedded software update system |
US10/876,503 Abandoned US20040237068A1 (en) | 2001-07-16 | 2004-06-24 | Embedded software update system |
Country Status (6)
Country | Link |
---|---|
US (3) | US6760908B2 (en) |
EP (1) | EP1410181A1 (en) |
JP (1) | JP2004536405A (en) |
KR (1) | KR20040022451A (en) |
CN (1) | CN1529847A (en) |
WO (1) | WO2003009136A1 (en) |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030142556A1 (en) * | 2002-01-29 | 2003-07-31 | Lohse Martin A. | Differential flash memory programming technique |
US20080196021A1 (en) * | 2007-02-08 | 2008-08-14 | Microsoft Corporation | Accessible Limited Distribution Release Software Change Catalog |
US20090019435A1 (en) * | 2007-07-12 | 2009-01-15 | Sauer-Danfoss Inc. | System and method for over the air programming |
WO2009051760A1 (en) * | 2007-10-17 | 2009-04-23 | Hewlett-Packard Development Company, L.P. | Mobile handset employing efficient backup and recovery of blocks during update |
US20090122906A1 (en) * | 2007-11-12 | 2009-05-14 | Motorola, Inc. | Method and apparatus for encoding a modulated signal in a communication system |
US20090305687A1 (en) * | 2005-11-30 | 2009-12-10 | Simone Baldan | Method and System for Updating Applications in Mobile Communications Terminals |
US7673297B1 (en) * | 2003-09-03 | 2010-03-02 | The Directv Group, Inc. | Automatic software update detection and flexible installer for set-top boxes |
CN101930375A (en) * | 2010-08-26 | 2010-12-29 | 深圳市共进电子有限公司 | Self-adaptive program data updating method of memory space in single user optical network unit |
US20110136427A1 (en) * | 2009-07-13 | 2011-06-09 | Al Qalqili Eyad Ali Mohammad | Method and system for transmitting and/or receiving advertisment and data contents on a mobile communication device with a display mechanisem |
US8526940B1 (en) | 2004-08-17 | 2013-09-03 | Palm, Inc. | Centralized rules repository for smart phone customer care |
US8578361B2 (en) | 2004-04-21 | 2013-11-05 | Palm, Inc. | Updating an electronic device with update agent code |
CN103645924A (en) * | 2013-12-27 | 2014-03-19 | 金三立视频科技(深圳)有限公司 | Method and device for managing program parameters of embedded device |
US8752044B2 (en) | 2006-07-27 | 2014-06-10 | Qualcomm Incorporated | User experience and dependency management in a mobile device |
US8893110B2 (en) | 2006-06-08 | 2014-11-18 | Qualcomm Incorporated | Device management in a network |
US9392017B2 (en) | 2010-04-22 | 2016-07-12 | The Trustees Of Columbia University In The City Of New York | Methods, systems, and media for inhibiting attacks on embedded devices |
US9921954B1 (en) * | 2012-08-27 | 2018-03-20 | Avago Technologies General Ip (Singapore) Pte. Ltd. | Method and system for split flash memory management between host and storage controller |
US10055251B1 (en) * | 2009-04-22 | 2018-08-21 | The Trustees Of Columbia University In The City Of New York | Methods, systems, and media for injecting code into embedded devices |
US20190073235A1 (en) * | 2016-04-21 | 2019-03-07 | Nec Corporation | Network system, patch file application method, and recording medium |
US10657262B1 (en) * | 2014-09-28 | 2020-05-19 | Red Balloon Security, Inc. | Method and apparatus for securing embedded device firmware |
US10887340B2 (en) | 2012-02-15 | 2021-01-05 | The Trustees Of Columbia University In The City Of New York | Methods, systems, and media for inhibiting attacks on embedded devices |
US11334605B2 (en) | 2015-06-04 | 2022-05-17 | Here Global B.V. | Incremental update of compressed navigational databases |
Families Citing this family (232)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8725656B1 (en) | 2000-05-18 | 2014-05-13 | United Parcel Service Of America, Inc. | Freight rate manager |
US8321356B2 (en) * | 2000-05-18 | 2012-11-27 | United Parcel Service Of America, Inc. | System and method for calculating real-time costing information |
US7409685B2 (en) | 2002-04-12 | 2008-08-05 | Hewlett-Packard Development Company, L.P. | Initialization and update of software and/or firmware in electronic devices |
US8479189B2 (en) | 2000-11-17 | 2013-07-02 | Hewlett-Packard Development Company, L.P. | Pattern detection preprocessor in an electronic device update generation system |
US20030140126A1 (en) * | 2001-03-30 | 2003-07-24 | Vitria Technology, Inc. | Method of deployment for concurrent execution of multiple versions of an integration model |
US7613716B2 (en) * | 2001-07-20 | 2009-11-03 | The Mathworks, Inc. | Partitioning for model-based design |
US7069546B2 (en) * | 2001-12-03 | 2006-06-27 | Corrigent Systems Ltd. | Generic framework for embedded software development |
US20030191823A1 (en) * | 2002-04-03 | 2003-10-09 | Aplion Networks, Inc. | System and method for providing customizable device capabilities to network equipment in a non-service affecting manner |
US20040015943A1 (en) * | 2002-07-17 | 2004-01-22 | Ying-Chou Chen | Embedded computer system equipped with an upgradeable software library |
US7784044B2 (en) * | 2002-12-02 | 2010-08-24 | Microsoft Corporation | Patching of in-use functions on a running computer system |
DE10260103A1 (en) * | 2002-12-19 | 2004-07-01 | Robert Bosch Gmbh | Method and device for changing software in a control unit and corresponding control unit |
US9092286B2 (en) * | 2002-12-20 | 2015-07-28 | Qualcomm Incorporated | System to automatically process components on a device |
WO2004066091A2 (en) * | 2003-01-21 | 2004-08-05 | Bitfone Corporation | Update system capable of updating software across multiple flash chips |
US6941453B2 (en) * | 2003-02-11 | 2005-09-06 | Bitfone Corporation | System and method for determining if a device needs to be updated and locating and invoking an update agent to update the firmware or software in the device |
US6886472B2 (en) * | 2003-02-20 | 2005-05-03 | General Electric Company | Method and system for autonomously resolving a failure |
JP2004312711A (en) * | 2003-03-25 | 2004-11-04 | Ricoh Co Ltd | Image forming apparatus and method for operating image forming apparatus by using remote application |
JP4523991B2 (en) * | 2003-03-25 | 2010-08-11 | 株式会社リコー | Terminal device, method, system, and program |
GB2403303B (en) * | 2003-06-23 | 2005-08-17 | Matsushita Electric Ind Co Ltd | Embedded device with software registry |
JP2005050073A (en) * | 2003-07-28 | 2005-02-24 | Matsushita Electric Ind Co Ltd | Data restoration method, and data recorder |
US7886287B1 (en) * | 2003-08-27 | 2011-02-08 | Avaya Inc. | Method and apparatus for hot updating of running processes |
KR101003888B1 (en) * | 2003-09-03 | 2010-12-30 | 휴렛-팩커드 디벨롭먼트 컴퍼니, 엘.피. | Tri-phase boot process in electronic devices |
US8555273B1 (en) | 2003-09-17 | 2013-10-08 | Palm. Inc. | Network for updating electronic devices |
US7624393B2 (en) * | 2003-09-18 | 2009-11-24 | International Business Machines Corporation | Computer application and methods for autonomic upgrade maintenance of computer hardware, operating systems and application software |
EP1680921A4 (en) * | 2003-11-04 | 2010-04-21 | Korea Electronics Telecomm | Apparatus and method for receiving data broadcasting service to support connection with mobile networks |
WO2005048604A1 (en) * | 2003-11-17 | 2005-05-26 | Samsung Electronics Co., Ltd. | Method for updating software of a target device using an extended identifier in digital broadcasting |
US7409538B2 (en) * | 2003-12-18 | 2008-08-05 | International Business Machines Corporation | Update in-use flash memory without external interfaces |
EP1569102B1 (en) | 2004-02-27 | 2010-04-28 | Telefonaktiebolaget LM Ericsson (publ) | Flash memory programming |
KR100620729B1 (en) * | 2004-03-31 | 2006-09-13 | 주식회사 팬택앤큐리텔 | Method for building software image |
US7600216B2 (en) * | 2004-04-22 | 2009-10-06 | Gteko, Ltd | Method for executing software applications using a portable memory device |
US20050251798A1 (en) * | 2004-05-05 | 2005-11-10 | News, Iq, Inc. | System and method for inventory control and management |
US8539469B2 (en) | 2004-05-11 | 2013-09-17 | Microsoft Corporation | Efficient patching |
US7559058B2 (en) * | 2004-05-11 | 2009-07-07 | Microsoft Corporation | Efficient patching |
EP1622009A1 (en) * | 2004-07-27 | 2006-02-01 | Texas Instruments Incorporated | JSM architecture and systems |
CN100370431C (en) * | 2004-08-16 | 2008-02-20 | 上海华为技术有限公司 | Method and system for monitoring embedded system on line |
US7373492B2 (en) * | 2004-08-30 | 2008-05-13 | Lehman Brothers Inc. | Boot disk management utility |
FR2875921B1 (en) * | 2004-09-27 | 2006-12-01 | Gemplus Sa | CAMERA FOR DOWNLOADING DATA IN PORTABLE COMMUNICATING OBJECTS |
US20060075401A1 (en) * | 2004-10-05 | 2006-04-06 | Microsoft Corporation | Patch installation control |
KR100784783B1 (en) * | 2004-12-07 | 2007-12-14 | 한국전자통신연구원 | System for support of embedded software development methodology with quantitative process management |
US8019725B1 (en) | 2004-12-15 | 2011-09-13 | Apple Inc. | Software update management |
US8347285B2 (en) * | 2004-12-16 | 2013-01-01 | Intel Corporation | Embedded agent for self-healing software |
CN100435108C (en) * | 2004-12-22 | 2008-11-19 | 迅杰科技股份有限公司 | Firmware repairing method for memory device |
US7426571B2 (en) * | 2005-01-06 | 2008-09-16 | Dell Products L.P. | Providing files to an information handling system using a remote access controller |
US7734574B2 (en) * | 2005-02-17 | 2010-06-08 | International Business Machines Corporation | Intelligent system health indicator |
US20060200656A1 (en) * | 2005-03-03 | 2006-09-07 | Cardinell Charles S | Apparatus and method to capture data from an embedded device |
US7606370B2 (en) * | 2005-04-05 | 2009-10-20 | Mcafee, Inc. | System, method and computer program product for updating security criteria in wireless networks |
US7757274B2 (en) | 2005-04-05 | 2010-07-13 | Mcafee, Inc. | Methods and systems for exchanging security information via peer-to-peer wireless networks |
US7761710B2 (en) * | 2005-04-05 | 2010-07-20 | Mcafee, Inc. | Captive portal system and method for use in peer-to-peer networks |
US7822972B2 (en) * | 2005-04-05 | 2010-10-26 | Mcafee, Inc. | Remotely configurable bridge system and method for use in secure wireless networks |
US20060248107A1 (en) * | 2005-04-11 | 2006-11-02 | Coronado Juan A | Apparatus system and method for updating software while preserving system state |
CN100521676C (en) | 2005-04-14 | 2009-07-29 | 华为技术有限公司 | Method and apparatus for realizing independent staging business software in set-top box |
US20060265692A1 (en) * | 2005-05-20 | 2006-11-23 | Mengjin Su | Method, apparatus, and computer program product for code patching |
US8399390B2 (en) | 2005-06-29 | 2013-03-19 | Exxonmobil Chemical Patents Inc. | HVI-PAO in industrial lubricant and grease compositions |
US7667874B2 (en) * | 2005-07-06 | 2010-02-23 | Xerox Corporation | Method and system for improving print quality |
WO2007011462A1 (en) | 2005-07-19 | 2007-01-25 | Exxonmobil Chemical Patents Inc. | Lubricants from mixed alpha-olefin feeds |
US8748361B2 (en) | 2005-07-19 | 2014-06-10 | Exxonmobil Chemical Patents Inc. | Polyalpha-olefin compositions and processes to produce the same |
EP1934727B1 (en) * | 2005-08-23 | 2019-01-16 | Red Bend Ltd. | Method and system for in-place updating content stored in a storage device |
US7577872B2 (en) * | 2005-08-26 | 2009-08-18 | Home Box Office | Dynamic system diagnosis |
US20070074187A1 (en) * | 2005-09-29 | 2007-03-29 | O'brien Thomas E | Method and apparatus for inserting code fixes into applications at runtime |
CN100416503C (en) * | 2005-11-04 | 2008-09-03 | 中兴通讯股份有限公司 | Method for updating version of software |
US20070132774A1 (en) * | 2005-12-01 | 2007-06-14 | Samsung Electronics Co., Ltd. | System and method for a patch minimization tool |
DE102005059319A1 (en) | 2005-12-09 | 2007-06-14 | Robert Bosch Gmbh | File device operating method, involves storing data, which is stored on segment, and providing data for data conditions, where portion of data is converted, and converted data is stored on another segment during operation of device |
DE602005025385D1 (en) * | 2005-12-20 | 2011-01-27 | Ericsson Telefon Ab L M | Creation of incremental program updates |
US7603113B2 (en) | 2005-12-31 | 2009-10-13 | Adobe Systems Incorporated | Using local codecs |
US7660558B2 (en) | 2005-12-31 | 2010-02-09 | Adobe Systems Incorporated | Interrupting and resuming a media player |
KR100717110B1 (en) * | 2006-02-21 | 2007-05-10 | 삼성전자주식회사 | Rom data patch circuit, embedded system including the same and method of patching rom data |
KR100746036B1 (en) | 2006-02-23 | 2007-08-06 | 삼성전자주식회사 | Apparatus and method for controlling flash memory |
US8299007B2 (en) | 2006-06-06 | 2012-10-30 | Exxonmobil Research And Engineering Company | Base stock lubricant blends |
US8535514B2 (en) | 2006-06-06 | 2013-09-17 | Exxonmobil Research And Engineering Company | High viscosity metallocene catalyst PAO novel base stock lubricant blends |
US8921290B2 (en) | 2006-06-06 | 2014-12-30 | Exxonmobil Research And Engineering Company | Gear oil compositions |
US8501675B2 (en) | 2006-06-06 | 2013-08-06 | Exxonmobil Research And Engineering Company | High viscosity novel base stock lubricant viscosity blends |
US8834705B2 (en) | 2006-06-06 | 2014-09-16 | Exxonmobil Research And Engineering Company | Gear oil compositions |
WO2008005581A2 (en) * | 2006-07-07 | 2008-01-10 | United Parcel Service Of America, Inc. | Compiled data for software applications |
US8112747B2 (en) * | 2006-11-27 | 2012-02-07 | Sap Ag | Integrated software support for a distributed business application with seamless backend communications |
US20130167024A1 (en) | 2006-12-05 | 2013-06-27 | Adobe Systems Incorporated | Embedded document within an application |
US8533820B2 (en) * | 2006-12-12 | 2013-09-10 | International Business Machines Corporation | Reserved write positions on install media |
FR2911023B1 (en) * | 2006-12-29 | 2009-04-17 | Radiotelephone Sfr | METHOD FOR SECURING A DATA STREAM |
DE102007003580A1 (en) * | 2007-01-24 | 2008-07-31 | Giesecke & Devrient Gmbh | Install a patch in a smart card module |
US7743339B1 (en) * | 2007-02-01 | 2010-06-22 | Adobe Systems Incorporated | Rendering text in a brew device |
ATE521035T1 (en) * | 2007-02-09 | 2011-09-15 | Ericsson Telefon Ab L M | GENERATION OF DELTA UPDATES FOR A PROCESSING APPARATUS |
US8589779B2 (en) * | 2007-03-08 | 2013-11-19 | Adobe Systems Incorporated | Event-sensitive content for mobile devices |
EP2165269A1 (en) * | 2007-05-24 | 2010-03-24 | Facebook Inc. | Personalized platform for accessing internet applications |
EP2051150B1 (en) * | 2007-10-16 | 2011-03-16 | Siemens Aktiengesellschaft | Method for automatic modification of a program |
US8213923B1 (en) * | 2007-11-02 | 2012-07-03 | Trend Micro Incorporated | Product update via voice call in mobile security |
ATE522861T1 (en) | 2007-12-13 | 2011-09-15 | Ericsson Telefon Ab L M | FIRMWARE UPDATE ON AN ELECTRONIC DEVICE |
US8839225B2 (en) | 2008-01-23 | 2014-09-16 | International Business Machines Corporation | Generating and applying patches to a computer program code concurrently with its execution |
WO2009097069A1 (en) | 2008-01-31 | 2009-08-06 | Exxonmobil Chemical Patents Inc. | Improved utilization of linear alpha olefins in the production of metallocene catalyzed poly-alpha olefins |
FR2928754B1 (en) * | 2008-03-13 | 2012-05-18 | Sagem Securite | INTEGRATED CIRCUIT BOARD HAVING AN ALTERNATIVE OPERATING PROGRAM AND CORRESPONDING MODIFICATION METHOD |
US8865959B2 (en) | 2008-03-18 | 2014-10-21 | Exxonmobil Chemical Patents Inc. | Process for synthetic lubricant production |
CN101977944A (en) | 2008-03-31 | 2011-02-16 | 埃克森美孚化学专利公司 | Production of shear-stable high viscosity pao |
US9058230B1 (en) * | 2008-05-27 | 2015-06-16 | Symantec Operating Corporation | Online expert system guided application installation |
WO2009156790A1 (en) * | 2008-06-23 | 2009-12-30 | Freescale Semiconductor, Inc. | Patching of a read-only memory |
US8394746B2 (en) | 2008-08-22 | 2013-03-12 | Exxonmobil Research And Engineering Company | Low sulfur and low metal additive formulations for high performance industrial oils |
US8930930B2 (en) * | 2008-09-04 | 2015-01-06 | International Business Machines Corporation | Updating a computer system |
US8312447B2 (en) * | 2008-09-25 | 2012-11-13 | Microsoft Corporation | Managing updates using compiler and linker information |
US8476205B2 (en) | 2008-10-03 | 2013-07-02 | Exxonmobil Research And Engineering Company | Chromium HVI-PAO bi-modal lubricant compositions |
KR101016916B1 (en) * | 2008-10-30 | 2011-02-22 | 한국항공우주산업 주식회사 | Method of Data Injection of Embedded System of Aircraft for Test and Flight Simulation |
US20100180104A1 (en) * | 2009-01-15 | 2010-07-15 | Via Technologies, Inc. | Apparatus and method for patching microcode in a microprocessor using private ram of the microprocessor |
US9104521B2 (en) * | 2009-03-16 | 2015-08-11 | Tyco Electronics Subsea Communications Llc | System and method for remote device application upgrades |
JP5310324B2 (en) * | 2009-07-07 | 2013-10-09 | 株式会社リコー | Information processing apparatus, information processing method, and program |
US8716201B2 (en) | 2009-10-02 | 2014-05-06 | Exxonmobil Research And Engineering Company | Alkylated naphtylene base stock lubricant formulations |
CA2782873C (en) | 2009-12-24 | 2016-06-28 | Exxonmobil Chemical Patents Inc. | Process for producing novel synthetic basestocks |
US8759267B2 (en) | 2010-02-01 | 2014-06-24 | Exxonmobil Research And Engineering Company | Method for improving the fuel efficiency of engine oil compositions for large low and medium speed engines by reducing the traction coefficient |
US8748362B2 (en) | 2010-02-01 | 2014-06-10 | Exxonmobile Research And Engineering Company | Method for improving the fuel efficiency of engine oil compositions for large low and medium speed gas engines by reducing the traction coefficient |
US8728999B2 (en) | 2010-02-01 | 2014-05-20 | Exxonmobil Research And Engineering Company | Method for improving the fuel efficiency of engine oil compositions for large low and medium speed engines by reducing the traction coefficient |
US8642523B2 (en) | 2010-02-01 | 2014-02-04 | Exxonmobil Research And Engineering Company | Method for improving the fuel efficiency of engine oil compositions for large low and medium speed engines by reducing the traction coefficient |
US8598103B2 (en) | 2010-02-01 | 2013-12-03 | Exxonmobil Research And Engineering Company | Method for improving the fuel efficiency of engine oil compositions for large low, medium and high speed engines by reducing the traction coefficient |
CN102156661B (en) * | 2010-02-11 | 2013-06-12 | 华为技术有限公司 | Method, device and system for online activating patches |
US9815915B2 (en) | 2010-09-03 | 2017-11-14 | Exxonmobil Chemical Patents Inc. | Production of liquid polyolefins |
CN101950254B (en) * | 2010-09-16 | 2014-07-30 | 新邮通信设备有限公司 | Software updating method and system thereof |
TW201246075A (en) * | 2011-05-06 | 2012-11-16 | Asmedia Technology Inc | Flash device and associated booting method |
DE102012103654A1 (en) | 2011-05-17 | 2012-11-22 | International Business Machines Corp. | Install and validate an application on a heavily used computer platform |
US9234150B2 (en) | 2011-10-10 | 2016-01-12 | Exxonmobil Research And Engineering Company | Low viscosity engine oil compositions |
JP5886099B2 (en) * | 2012-03-21 | 2016-03-16 | 日立オートモティブシステムズ株式会社 | Electronic control unit for automobile |
CN102707978A (en) * | 2012-05-18 | 2012-10-03 | 苏州万图明电子软件有限公司 | Update software of image device |
US9798557B2 (en) * | 2012-08-24 | 2017-10-24 | Ca, Inc. | Injection of updated classes for a java agent |
US9817656B2 (en) | 2012-08-24 | 2017-11-14 | Ca, Inc. | Hot rollback of updated agent |
CN102880494B (en) * | 2012-09-26 | 2016-02-10 | 浙江大学 | A kind of local code update method for microsatellite system and system thereof |
US8930932B2 (en) | 2012-10-09 | 2015-01-06 | Futurewei Technologies, Inc. | In-service software patch |
US10310863B1 (en) * | 2013-07-31 | 2019-06-04 | Red Hat, Inc. | Patching functions in use on a running computer system |
US9547581B2 (en) | 2013-10-01 | 2017-01-17 | Wipro Limited | Systems and methods for fixing software defects in a binary or executable file |
CN106484369B (en) * | 2013-10-24 | 2019-11-29 | 华为技术有限公司 | A kind of method and device of online patch activation |
US9736098B2 (en) * | 2014-02-07 | 2017-08-15 | Lenovo (Singapore) Pte. Ltd. | Email-based software delivery |
US9547489B2 (en) * | 2014-03-31 | 2017-01-17 | Qualcomm Incorporated | System and method for modifying a sequence of instructions in a read-only memory of a computing device |
EP2955629B1 (en) * | 2014-06-11 | 2021-10-27 | Home Control Singapore Pte. Ltd. | System for installing new firmware on a small-memory device |
US10282187B2 (en) | 2014-07-03 | 2019-05-07 | Oracle International Corporation | Efficient application patching in heterogeneous computing environments |
US9830193B1 (en) | 2014-09-30 | 2017-11-28 | Amazon Technologies, Inc. | Automatic management of low latency computational capacity |
US9146764B1 (en) | 2014-09-30 | 2015-09-29 | Amazon Technologies, Inc. | Processing event messages for user requests to execute program code |
US10048974B1 (en) | 2014-09-30 | 2018-08-14 | Amazon Technologies, Inc. | Message-based computation request scheduling |
US9600312B2 (en) | 2014-09-30 | 2017-03-21 | Amazon Technologies, Inc. | Threading as a service |
US9715402B2 (en) * | 2014-09-30 | 2017-07-25 | Amazon Technologies, Inc. | Dynamic code deployment and versioning |
US9323556B2 (en) | 2014-09-30 | 2016-04-26 | Amazon Technologies, Inc. | Programmatic event detection and message generation for requests to execute program code |
US9678773B1 (en) | 2014-09-30 | 2017-06-13 | Amazon Technologies, Inc. | Low latency computational capacity provisioning |
KR102261815B1 (en) * | 2014-10-30 | 2021-06-07 | 삼성전자주식회사 | Data storage device for reducing firmware update time, and data processing system including the same |
US9537788B2 (en) | 2014-12-05 | 2017-01-03 | Amazon Technologies, Inc. | Automatic determination of resource sizing |
US10101987B2 (en) | 2015-03-11 | 2018-10-16 | Echelon Corporation | Method and system of processing an image upgrade |
EP3040858A1 (en) * | 2014-12-31 | 2016-07-06 | Echelon Corporation | A method and system of processing an image update |
US9727725B2 (en) | 2015-02-04 | 2017-08-08 | Amazon Technologies, Inc. | Security protocols for low latency execution of program code |
US9588790B1 (en) | 2015-02-04 | 2017-03-07 | Amazon Technologies, Inc. | Stateful virtual compute system |
US9733967B2 (en) | 2015-02-04 | 2017-08-15 | Amazon Technologies, Inc. | Security protocols for low latency execution of program code |
US9886263B2 (en) | 2015-03-24 | 2018-02-06 | Oracle International Corporation | Techniques for efficient application configuration patching |
US9785476B2 (en) | 2015-04-08 | 2017-10-10 | Amazon Technologies, Inc. | Endpoint management system and virtual compute system |
US9930103B2 (en) | 2015-04-08 | 2018-03-27 | Amazon Technologies, Inc. | Endpoint management system providing an application programming interface proxy service |
US10009232B2 (en) | 2015-06-23 | 2018-06-26 | Dell Products, L.P. | Method and control system providing an interactive interface for device-level monitoring and servicing of distributed, large-scale information handling system (LIHS) |
US10754494B2 (en) | 2015-06-23 | 2020-08-25 | Dell Products, L.P. | Method and control system providing one-click commissioning and push updates to distributed, large-scale information handling system (LIHS) |
US10063629B2 (en) | 2015-06-23 | 2018-08-28 | Dell Products, L.P. | Floating set points to optimize power allocation and use in data center |
CN106354524B (en) | 2015-07-17 | 2021-01-01 | 恩智浦美国有限公司 | System and method for updating firmware in real time |
US9928108B1 (en) | 2015-09-29 | 2018-03-27 | Amazon Technologies, Inc. | Metaevent handling for on-demand code execution environments |
US10042660B2 (en) | 2015-09-30 | 2018-08-07 | Amazon Technologies, Inc. | Management of periodic requests for compute capacity |
US9830449B1 (en) | 2015-12-16 | 2017-11-28 | Amazon Technologies, Inc. | Execution locations for request-driven code |
US9830175B1 (en) | 2015-12-16 | 2017-11-28 | Amazon Technologies, Inc. | Predictive management of on-demand code execution |
US9811363B1 (en) | 2015-12-16 | 2017-11-07 | Amazon Technologies, Inc. | Predictive management of on-demand code execution |
US10754701B1 (en) | 2015-12-16 | 2020-08-25 | Amazon Technologies, Inc. | Executing user-defined code in response to determining that resources expected to be utilized comply with resource restrictions |
US10013267B1 (en) | 2015-12-16 | 2018-07-03 | Amazon Technologies, Inc. | Pre-triggers for code execution environments |
US9811434B1 (en) | 2015-12-16 | 2017-11-07 | Amazon Technologies, Inc. | Predictive management of on-demand code execution |
US9910713B2 (en) | 2015-12-21 | 2018-03-06 | Amazon Technologies, Inc. | Code execution request routing |
US10067801B1 (en) | 2015-12-21 | 2018-09-04 | Amazon Technologies, Inc. | Acquisition and maintenance of compute capacity |
US10002026B1 (en) | 2015-12-21 | 2018-06-19 | Amazon Technologies, Inc. | Acquisition and maintenance of dedicated, reserved, and variable compute capacity |
US10891145B2 (en) | 2016-03-30 | 2021-01-12 | Amazon Technologies, Inc. | Processing pre-existing data sets at an on demand code execution environment |
US11132213B1 (en) | 2016-03-30 | 2021-09-28 | Amazon Technologies, Inc. | Dependency-based process of pre-existing data sets at an on demand code execution environment |
US10108412B2 (en) | 2016-03-30 | 2018-10-23 | Square, Inc. | Blocking and non-blocking firmware update |
US10162672B2 (en) | 2016-03-30 | 2018-12-25 | Amazon Technologies, Inc. | Generating data streams from pre-existing data sets |
CN110110522B (en) * | 2016-05-24 | 2021-05-07 | 百度在线网络技术(北京)有限公司 | Kernel repairing method and device |
US9952896B2 (en) | 2016-06-28 | 2018-04-24 | Amazon Technologies, Inc. | Asynchronous task management in an on-demand network code execution environment |
US10282229B2 (en) | 2016-06-28 | 2019-05-07 | Amazon Technologies, Inc. | Asynchronous task management in an on-demand network code execution environment |
US10817869B2 (en) | 2016-06-29 | 2020-10-27 | Square, Inc. | Preliminary enablement of transaction processing circuitry |
US10102040B2 (en) | 2016-06-29 | 2018-10-16 | Amazon Technologies, Inc | Adjusting variable limit on concurrent code executions |
US11010765B2 (en) | 2016-06-29 | 2021-05-18 | Square, Inc. | Preliminary acquisition of payment information |
US10203990B2 (en) | 2016-06-30 | 2019-02-12 | Amazon Technologies, Inc. | On-demand network code execution with cross-account aliases |
US10277708B2 (en) | 2016-06-30 | 2019-04-30 | Amazon Technologies, Inc. | On-demand network code execution with cross-account aliases |
US10884787B1 (en) | 2016-09-23 | 2021-01-05 | Amazon Technologies, Inc. | Execution guarantees in an on-demand network code execution system |
US10061613B1 (en) | 2016-09-23 | 2018-08-28 | Amazon Technologies, Inc. | Idempotent task execution in on-demand network code execution systems |
US11119813B1 (en) | 2016-09-30 | 2021-09-14 | Amazon Technologies, Inc. | Mapreduce implementation using an on-demand network code execution system |
JP6751197B2 (en) | 2017-02-28 | 2020-09-02 | 日本電信電話株式会社 | COMMUNICATION PROCESSING DEVICE, INFORMATION PROCESSING DEVICE, AND COMMUNICATION PROCESSING DEVICE CONTROL METHOD |
US10402192B2 (en) | 2017-07-25 | 2019-09-03 | Aurora Labs Ltd. | Constructing software delta updates for vehicle ECU software and abnormality detection based on toolchain |
US10564946B1 (en) | 2017-12-13 | 2020-02-18 | Amazon Technologies, Inc. | Dependency handling in an on-demand network code execution system |
US10303492B1 (en) | 2017-12-13 | 2019-05-28 | Amazon Technologies, Inc. | Managing custom runtimes in an on-demand code execution system |
US10733085B1 (en) | 2018-02-05 | 2020-08-04 | Amazon Technologies, Inc. | Detecting impedance mismatches due to cross-service calls |
US10572375B1 (en) | 2018-02-05 | 2020-02-25 | Amazon Technologies, Inc. | Detecting parameter validity in code including cross-service calls |
US10353678B1 (en) | 2018-02-05 | 2019-07-16 | Amazon Technologies, Inc. | Detecting code characteristic alterations due to cross-service calls |
US10831898B1 (en) | 2018-02-05 | 2020-11-10 | Amazon Technologies, Inc. | Detecting privilege escalations in code including cross-service calls |
US10725752B1 (en) | 2018-02-13 | 2020-07-28 | Amazon Technologies, Inc. | Dependency handling in an on-demand network code execution system |
US10776091B1 (en) | 2018-02-26 | 2020-09-15 | Amazon Technologies, Inc. | Logging endpoint in an on-demand code execution system |
US10853115B2 (en) | 2018-06-25 | 2020-12-01 | Amazon Technologies, Inc. | Execution of auxiliary functions in an on-demand network code execution system |
CN108874438B (en) * | 2018-06-25 | 2021-09-21 | 南京中感微电子有限公司 | Patch generation method and device, electronic equipment and computer storage medium |
US10649749B1 (en) | 2018-06-26 | 2020-05-12 | Amazon Technologies, Inc. | Cross-environment application of tracing information for improved code execution |
US11146569B1 (en) | 2018-06-28 | 2021-10-12 | Amazon Technologies, Inc. | Escalation-resistant secure network services using request-scoped authentication information |
US10949237B2 (en) | 2018-06-29 | 2021-03-16 | Amazon Technologies, Inc. | Operating system customization in an on-demand network code execution system |
US11099870B1 (en) | 2018-07-25 | 2021-08-24 | Amazon Technologies, Inc. | Reducing execution times in an on-demand network code execution system using saved machine states |
US11243953B2 (en) | 2018-09-27 | 2022-02-08 | Amazon Technologies, Inc. | Mapreduce implementation in an on-demand network code execution system and stream data processing system |
US11099917B2 (en) | 2018-09-27 | 2021-08-24 | Amazon Technologies, Inc. | Efficient state maintenance for execution environments in an on-demand code execution system |
US11943093B1 (en) | 2018-11-20 | 2024-03-26 | Amazon Technologies, Inc. | Network connection recovery after virtual machine transition in an on-demand network code execution system |
US10884812B2 (en) | 2018-12-13 | 2021-01-05 | Amazon Technologies, Inc. | Performance-based hardware emulation in an on-demand network code execution system |
DE102018009835A1 (en) * | 2018-12-14 | 2020-06-18 | Giesecke+Devrient Mobile Security Gmbh | Incremental firmware update |
US10762196B2 (en) | 2018-12-21 | 2020-09-01 | Square, Inc. | Point of sale (POS) systems and methods with dynamic kernel selection |
US10990969B2 (en) | 2018-12-21 | 2021-04-27 | Square, Inc. | Point of sale (POS) systems and methods for dynamically processing payment data based on payment reader capability |
US11049095B2 (en) | 2018-12-21 | 2021-06-29 | Square, Inc. | Point of sale (POS) systems and methods with dynamic kernel selection |
US11010188B1 (en) | 2019-02-05 | 2021-05-18 | Amazon Technologies, Inc. | Simulated data object storage using on-demand computation of data objects |
US11861386B1 (en) | 2019-03-22 | 2024-01-02 | Amazon Technologies, Inc. | Application gateways in an on-demand network code execution system |
WO2020194000A1 (en) | 2019-03-28 | 2020-10-01 | Validata Holdings Limited | Method of detecting and removing defects |
US11119809B1 (en) | 2019-06-20 | 2021-09-14 | Amazon Technologies, Inc. | Virtualization-based transaction handling in an on-demand network code execution system |
CN110333890A (en) * | 2019-06-28 | 2019-10-15 | 南京兆伏电力科技有限公司 | The method that long-range programming solidifies FLASH data |
US11115404B2 (en) | 2019-06-28 | 2021-09-07 | Amazon Technologies, Inc. | Facilitating service connections in serverless code executions |
US11190609B2 (en) | 2019-06-28 | 2021-11-30 | Amazon Technologies, Inc. | Connection pooling for scalable network services |
US11159528B2 (en) | 2019-06-28 | 2021-10-26 | Amazon Technologies, Inc. | Authentication to network-services using hosted authentication information |
US11023416B2 (en) | 2019-09-27 | 2021-06-01 | Amazon Technologies, Inc. | Data access control system for object storage service based on owner-defined code |
US11263220B2 (en) | 2019-09-27 | 2022-03-01 | Amazon Technologies, Inc. | On-demand execution of object transformation code in output path of object storage service |
US11250007B1 (en) | 2019-09-27 | 2022-02-15 | Amazon Technologies, Inc. | On-demand execution of object combination code in output path of object storage service |
US11360948B2 (en) | 2019-09-27 | 2022-06-14 | Amazon Technologies, Inc. | Inserting owner-specified data processing pipelines into input/output path of object storage service |
US11416628B2 (en) | 2019-09-27 | 2022-08-16 | Amazon Technologies, Inc. | User-specific data manipulation system for object storage service based on user-submitted code |
US10996961B2 (en) | 2019-09-27 | 2021-05-04 | Amazon Technologies, Inc. | On-demand indexing of data in input path of object storage service |
US11055112B2 (en) | 2019-09-27 | 2021-07-06 | Amazon Technologies, Inc. | Inserting executions of owner-specified code into input/output path of object storage service |
US11023311B2 (en) | 2019-09-27 | 2021-06-01 | Amazon Technologies, Inc. | On-demand code execution in input path of data uploaded to storage service in multiple data portions |
US10908927B1 (en) | 2019-09-27 | 2021-02-02 | Amazon Technologies, Inc. | On-demand execution of object filter code in output path of object storage service |
US11106477B2 (en) | 2019-09-27 | 2021-08-31 | Amazon Technologies, Inc. | Execution of owner-specified code during input/output path to object storage service |
US11656892B1 (en) | 2019-09-27 | 2023-05-23 | Amazon Technologies, Inc. | Sequential execution of user-submitted code and native functions |
US11386230B2 (en) | 2019-09-27 | 2022-07-12 | Amazon Technologies, Inc. | On-demand code obfuscation of data in input path of object storage service |
US11550944B2 (en) | 2019-09-27 | 2023-01-10 | Amazon Technologies, Inc. | Code execution environment customization system for object storage service |
US11394761B1 (en) | 2019-09-27 | 2022-07-19 | Amazon Technologies, Inc. | Execution of user-submitted code on a stream of data |
US10997056B1 (en) * | 2019-10-09 | 2021-05-04 | Fujitsu Limited | Generation of explanatory and executable repair examples |
US11119826B2 (en) | 2019-11-27 | 2021-09-14 | Amazon Technologies, Inc. | Serverless call distribution to implement spillover while avoiding cold starts |
US10942795B1 (en) | 2019-11-27 | 2021-03-09 | Amazon Technologies, Inc. | Serverless call distribution to utilize reserved capacity without inhibiting scaling |
US11714682B1 (en) | 2020-03-03 | 2023-08-01 | Amazon Technologies, Inc. | Reclaiming computing resources in an on-demand code execution system |
US11188391B1 (en) | 2020-03-11 | 2021-11-30 | Amazon Technologies, Inc. | Allocating resources to on-demand code executions under scarcity conditions |
US11775640B1 (en) | 2020-03-30 | 2023-10-03 | Amazon Technologies, Inc. | Resource utilization-based malicious task detection in an on-demand code execution system |
US11669621B2 (en) * | 2020-06-16 | 2023-06-06 | Bank Of America Corporation | Custom patching automation with machine learning integration |
US11593270B1 (en) | 2020-11-25 | 2023-02-28 | Amazon Technologies, Inc. | Fast distributed caching using erasure coded object parts |
US11550713B1 (en) | 2020-11-25 | 2023-01-10 | Amazon Technologies, Inc. | Garbage collection in distributed systems using life cycled storage roots |
CN114860308A (en) * | 2021-02-04 | 2022-08-05 | 北京国基科技股份有限公司 | Embedded software reconstruction method and device |
US11388210B1 (en) | 2021-06-30 | 2022-07-12 | Amazon Technologies, Inc. | Streaming analytics using a serverless compute system |
CN113656059B (en) * | 2021-10-21 | 2022-02-08 | 北京联盛德微电子有限责任公司 | Embedded software system |
US11900106B2 (en) | 2022-03-02 | 2024-02-13 | International Business Machines Corporation | Personalized patch notes based on software usage |
CN115469901B (en) * | 2022-08-16 | 2023-05-12 | 哈尔滨理工大学 | Dual-core DSP detachable remote upgrading system and upgrading method |
Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5802549A (en) * | 1995-12-14 | 1998-09-01 | International Business Machines Corporation | Method and apparatus for patching pages of ROM |
US5933595A (en) * | 1996-06-20 | 1999-08-03 | Sharp Kabushiki Kaisha | Computer apparatus having electrically rewritable nonvolatile memory, and nonvolatile semiconductor memory |
US5963970A (en) * | 1996-12-20 | 1999-10-05 | Intel Corporation | Method and apparatus for tracking erase cycles utilizing active and inactive wear bar blocks having first and second count fields |
US5974312A (en) * | 1997-07-10 | 1999-10-26 | Ericsson Inc. | System and method for updating a memory in an electronic device via wireless data transfer |
US20010000816A1 (en) * | 1998-05-11 | 2001-05-03 | Baltar Robert L. | Volatile lock architecture for individual block locking on flash memory |
US6237091B1 (en) * | 1998-10-29 | 2001-05-22 | Hewlett-Packard Company | Method of updating firmware without affecting initialization information |
US6256232B1 (en) * | 2000-07-07 | 2001-07-03 | Institute For Information Industry | Data access method capable of reducing the number of erasing to flash memory and data patch and access device using the same |
US6266736B1 (en) * | 1997-01-31 | 2001-07-24 | Sony Corporation | Method and apparatus for efficient software updating |
US6357021B1 (en) * | 1999-04-14 | 2002-03-12 | Mitsumi Electric Co., Ltd. | Method and apparatus for updating firmware |
US6378069B1 (en) * | 1998-11-04 | 2002-04-23 | Nortel Networks Limited | Apparatus and methods for providing software updates to devices in a communication network |
US20020073304A1 (en) * | 2000-12-07 | 2002-06-13 | Marsh James L. | System and method for updating firmware |
US6507881B1 (en) * | 1999-06-10 | 2003-01-14 | Mediatek Inc. | Method and system for programming a peripheral flash memory via an IDE bus |
US6529416B2 (en) * | 2000-11-30 | 2003-03-04 | Bitmicro Networks, Inc. | Parallel erase operations in memory systems |
US20030079216A1 (en) * | 2001-10-18 | 2003-04-24 | International Business Machines Corporation | Apparatus and method of using a hybrid of fixed media data and network-based data to provide software changes |
US20030165076A1 (en) * | 2001-09-28 | 2003-09-04 | Gorobets Sergey Anatolievich | Method of writing data to non-volatile memory |
US6640334B1 (en) * | 1999-09-27 | 2003-10-28 | Nortel Networks Limited | Method and apparatus of remotely updating firmware of a communication device |
US6769059B1 (en) * | 1999-12-17 | 2004-07-27 | Intel Corporation | System for updating computer's existing video BIOS without updating the whole computer's system BIOS |
US6813571B2 (en) * | 2001-02-23 | 2004-11-02 | Power Measurement, Ltd. | Apparatus and method for seamlessly upgrading the firmware of an intelligent electronic device |
US20050097543A1 (en) * | 2003-10-30 | 2005-05-05 | Kabushiki Kaisha Toshiba | Electronic apparatus and embedded software updating method |
US6896486B2 (en) * | 2002-09-18 | 2005-05-24 | Mikuni Corporation | Water pump |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4954941A (en) * | 1988-08-31 | 1990-09-04 | Bell Communications Research, Inc. | Method and apparatus for program updating |
DE69034191T2 (en) * | 1989-04-13 | 2005-11-24 | Sandisk Corp., Sunnyvale | EEPROM system with multi-chip block erasure |
US5481713A (en) * | 1993-05-06 | 1996-01-02 | Apple Computer, Inc. | Method and apparatus for patching code residing on a read only memory device |
US5675803A (en) * | 1994-01-28 | 1997-10-07 | Sun Microsystems, Inc. | Method and apparatus for a fast debugger fix and continue operation |
US5666293A (en) | 1994-05-27 | 1997-09-09 | Bell Atlantic Network Services, Inc. | Downloading operating system software through a broadcast channel |
US5699275A (en) * | 1995-04-12 | 1997-12-16 | Highwaymaster Communications, Inc. | System and method for remote patching of operating code located in a mobile unit |
US5619698A (en) * | 1995-05-05 | 1997-04-08 | Apple Computer, Inc. | Method and apparatus for patching operating systems |
US5896566A (en) | 1995-07-28 | 1999-04-20 | Motorola, Inc. | Method for indicating availability of updated software to portable wireless communication units |
US5689825A (en) | 1995-07-28 | 1997-11-18 | Motorola, Inc. | Method and apparatus for downloading updated software to portable wireless communication units |
US5907708A (en) * | 1996-06-03 | 1999-05-25 | Sun Microsystems, Inc. | System and method for facilitating avoidance of an exception of a predetermined type in a digital computer system by providing fix-up code for an instruction in response to detection of an exception condition resulting from execution thereof |
US5848064A (en) | 1996-08-07 | 1998-12-08 | Telxon Corporation | Wireless software upgrades with version control |
JP3755204B2 (en) | 1996-09-20 | 2006-03-15 | カシオ計算機株式会社 | COMMUNICATION DEVICE, COMMUNICATION CONTROL METHOD, AND COMMUNICATION SYSTEM |
TW325551B (en) | 1997-01-04 | 1998-01-21 | Inventec Corp | Auto switching memory space method capable of judging if there is updated version stored in memory circuit to automatically select program stored in ROM or memory circuit as execution stating location |
US6049830A (en) | 1997-05-13 | 2000-04-11 | Sony Corporation | Peripheral software download of a broadcast receiver |
US5936667A (en) | 1997-05-13 | 1999-08-10 | Sony Corporation | System and method for testing and updating stored content of a remote transmitter for an entertainment system |
US6002941A (en) | 1997-12-17 | 1999-12-14 | Motorola, Inc. | Method and apparatus for implementing a service in a wireless communication system |
US6167567A (en) * | 1998-05-05 | 2000-12-26 | 3Com Corporation | Technique for automatically updating software stored on a client computer in a networked client-server environment |
US6330715B1 (en) | 1998-05-19 | 2001-12-11 | Nortel Networks Limited | Method and apparatus for managing software in a network system |
US6216175B1 (en) * | 1998-06-08 | 2001-04-10 | Microsoft Corporation | Method for upgrading copies of an original file with same update data after normalizing differences between copies created during respective original installations |
US6353926B1 (en) | 1998-07-15 | 2002-03-05 | Microsoft Corporation | Software update notification |
US6366898B2 (en) | 1998-09-21 | 2002-04-02 | Sun, Microsystems, Inc. | Method and apparatus for managing classfiles on devices without a file system |
US6202208B1 (en) | 1998-09-29 | 2001-03-13 | Nortel Networks Limited | Patching environment for modifying a Java virtual machine and method |
US6594822B1 (en) * | 1999-02-19 | 2003-07-15 | Nortel Networks Limited | Method and apparatus for creating a software patch by comparing object files |
US6434744B1 (en) * | 1999-03-03 | 2002-08-13 | Microsoft Corporation | System and method for patching an installed application program |
US6223291B1 (en) | 1999-03-26 | 2001-04-24 | Motorola, Inc. | Secure wireless electronic-commerce system with digital product certificates and digital license certificates |
US6321380B1 (en) * | 1999-06-29 | 2001-11-20 | International Business Machines Corporation | Method and apparatus for modifying instruction operations in a processor |
US6397385B1 (en) | 1999-07-16 | 2002-05-28 | Excel Switching Corporation | Method and apparatus for in service software upgrade for expandable telecommunications system |
US7032213B1 (en) * | 1999-09-01 | 2006-04-18 | Microsoft Corporation | Fixing incompatible applications using a light debugger |
US20020012329A1 (en) | 2000-06-02 | 2002-01-31 | Timothy Atkinson | Communications apparatus interface and method for discovery of remote devices |
US20020026474A1 (en) | 2000-08-28 | 2002-02-28 | Wang Lawrence C. | Thin client for wireless device using java interface |
GB2366693B (en) | 2000-08-31 | 2002-08-14 | F Secure Oyj | Software virus protection |
-
2002
- 2002-07-15 KR KR10-2004-7000597A patent/KR20040022451A/en not_active Application Discontinuation
- 2002-07-15 CN CNA028141911A patent/CN1529847A/en active Pending
- 2002-07-15 US US10/195,199 patent/US6760908B2/en not_active Expired - Fee Related
- 2002-07-15 EP EP02748162A patent/EP1410181A1/en not_active Withdrawn
- 2002-07-15 JP JP2003514412A patent/JP2004536405A/en active Pending
- 2002-07-15 WO PCT/US2002/022412 patent/WO2003009136A1/en not_active Application Discontinuation
-
2004
- 2004-06-24 US US10/876,503 patent/US20040237068A1/en not_active Abandoned
- 2004-11-09 US US10/986,258 patent/US20050063242A1/en not_active Abandoned
Patent Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5802549A (en) * | 1995-12-14 | 1998-09-01 | International Business Machines Corporation | Method and apparatus for patching pages of ROM |
US5933595A (en) * | 1996-06-20 | 1999-08-03 | Sharp Kabushiki Kaisha | Computer apparatus having electrically rewritable nonvolatile memory, and nonvolatile semiconductor memory |
US5963970A (en) * | 1996-12-20 | 1999-10-05 | Intel Corporation | Method and apparatus for tracking erase cycles utilizing active and inactive wear bar blocks having first and second count fields |
US6266736B1 (en) * | 1997-01-31 | 2001-07-24 | Sony Corporation | Method and apparatus for efficient software updating |
US5974312A (en) * | 1997-07-10 | 1999-10-26 | Ericsson Inc. | System and method for updating a memory in an electronic device via wireless data transfer |
US20010000816A1 (en) * | 1998-05-11 | 2001-05-03 | Baltar Robert L. | Volatile lock architecture for individual block locking on flash memory |
US6237091B1 (en) * | 1998-10-29 | 2001-05-22 | Hewlett-Packard Company | Method of updating firmware without affecting initialization information |
US6378069B1 (en) * | 1998-11-04 | 2002-04-23 | Nortel Networks Limited | Apparatus and methods for providing software updates to devices in a communication network |
US6357021B1 (en) * | 1999-04-14 | 2002-03-12 | Mitsumi Electric Co., Ltd. | Method and apparatus for updating firmware |
US6507881B1 (en) * | 1999-06-10 | 2003-01-14 | Mediatek Inc. | Method and system for programming a peripheral flash memory via an IDE bus |
US6640334B1 (en) * | 1999-09-27 | 2003-10-28 | Nortel Networks Limited | Method and apparatus of remotely updating firmware of a communication device |
US6769059B1 (en) * | 1999-12-17 | 2004-07-27 | Intel Corporation | System for updating computer's existing video BIOS without updating the whole computer's system BIOS |
US6256232B1 (en) * | 2000-07-07 | 2001-07-03 | Institute For Information Industry | Data access method capable of reducing the number of erasing to flash memory and data patch and access device using the same |
US6529416B2 (en) * | 2000-11-30 | 2003-03-04 | Bitmicro Networks, Inc. | Parallel erase operations in memory systems |
US20020073304A1 (en) * | 2000-12-07 | 2002-06-13 | Marsh James L. | System and method for updating firmware |
US6813571B2 (en) * | 2001-02-23 | 2004-11-02 | Power Measurement, Ltd. | Apparatus and method for seamlessly upgrading the firmware of an intelligent electronic device |
US20030165076A1 (en) * | 2001-09-28 | 2003-09-04 | Gorobets Sergey Anatolievich | Method of writing data to non-volatile memory |
US20030079216A1 (en) * | 2001-10-18 | 2003-04-24 | International Business Machines Corporation | Apparatus and method of using a hybrid of fixed media data and network-based data to provide software changes |
US6896486B2 (en) * | 2002-09-18 | 2005-05-24 | Mikuni Corporation | Water pump |
US20050097543A1 (en) * | 2003-10-30 | 2005-05-05 | Kabushiki Kaisha Toshiba | Electronic apparatus and embedded software updating method |
Cited By (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7920425B2 (en) | 2002-01-29 | 2011-04-05 | Agere Systems Inc. | Differential flash memory programming technique |
US7313030B2 (en) * | 2002-01-29 | 2007-12-25 | Agere Systems Inc. | Differential flash memory programming technique |
US20080068894A1 (en) * | 2002-01-29 | 2008-03-20 | Agere Systems Inc. | Differential flash memory programming technique |
US20030142556A1 (en) * | 2002-01-29 | 2003-07-31 | Lohse Martin A. | Differential flash memory programming technique |
US7593269B2 (en) | 2002-01-29 | 2009-09-22 | Agere Systems Inc. | Differential flash memory programming technique |
US20090296485A1 (en) * | 2002-01-29 | 2009-12-03 | Agere Systems Inc. | Differential flash memory programming technique |
US7673297B1 (en) * | 2003-09-03 | 2010-03-02 | The Directv Group, Inc. | Automatic software update detection and flexible installer for set-top boxes |
US8578361B2 (en) | 2004-04-21 | 2013-11-05 | Palm, Inc. | Updating an electronic device with update agent code |
US8526940B1 (en) | 2004-08-17 | 2013-09-03 | Palm, Inc. | Centralized rules repository for smart phone customer care |
US8588756B2 (en) * | 2005-11-30 | 2013-11-19 | Telecom Italia S.P.A. | Method and system for updating applications in mobile communications terminals |
US20090305687A1 (en) * | 2005-11-30 | 2009-12-10 | Simone Baldan | Method and System for Updating Applications in Mobile Communications Terminals |
US8893110B2 (en) | 2006-06-08 | 2014-11-18 | Qualcomm Incorporated | Device management in a network |
US9081638B2 (en) | 2006-07-27 | 2015-07-14 | Qualcomm Incorporated | User experience and dependency management in a mobile device |
US8752044B2 (en) | 2006-07-27 | 2014-06-10 | Qualcomm Incorporated | User experience and dependency management in a mobile device |
US20080196021A1 (en) * | 2007-02-08 | 2008-08-14 | Microsoft Corporation | Accessible Limited Distribution Release Software Change Catalog |
US8819668B2 (en) | 2007-02-08 | 2014-08-26 | Microsoft Corporation | Accessible limited distribution release software change catalog |
US20090019435A1 (en) * | 2007-07-12 | 2009-01-15 | Sauer-Danfoss Inc. | System and method for over the air programming |
DE112008002767B4 (en) * | 2007-10-17 | 2017-01-26 | Qualcomm Incorporated | Mobile handset that uses efficient block backup and retrieval during an update |
GB2468225A (en) * | 2007-10-17 | 2010-09-01 | Hewlett Packard Development Co | Mobile handset employing efficient backup and recovery of blocks during update |
GB2468225B (en) * | 2007-10-17 | 2012-04-25 | Hewlett Packard Development Co | Mobile handset using a parity block to recover a block corrupted during the update of non-volatile memory |
US7802129B2 (en) | 2007-10-17 | 2010-09-21 | Hewlett-Packard Development Company, L.P. | Mobile handset employing efficient backup and recovery of blocks during update |
US20090106580A1 (en) * | 2007-10-17 | 2009-04-23 | Marko Slyz | Mobile handset employing efficient backup and recovery of blocks during update |
WO2009051760A1 (en) * | 2007-10-17 | 2009-04-23 | Hewlett-Packard Development Company, L.P. | Mobile handset employing efficient backup and recovery of blocks during update |
US20090122906A1 (en) * | 2007-11-12 | 2009-05-14 | Motorola, Inc. | Method and apparatus for encoding a modulated signal in a communication system |
US8009757B2 (en) | 2007-11-12 | 2011-08-30 | Motorola Mobility, Inc. | Method and apparatus for encoding a modulated signal in a communication system |
US10055251B1 (en) * | 2009-04-22 | 2018-08-21 | The Trustees Of Columbia University In The City Of New York | Methods, systems, and media for injecting code into embedded devices |
US11288090B1 (en) | 2009-04-22 | 2022-03-29 | The Trustees Of Columbia University In The City Of New York | Methods, systems, and media for injecting code into embedded devices |
US8666305B2 (en) * | 2009-07-13 | 2014-03-04 | Eyad Ali Mohammad AL QALQILI | Method and system for transmitting and/or receiving advertisement and data contents on a mobile communication device with a display mechanism |
US20110136427A1 (en) * | 2009-07-13 | 2011-06-09 | Al Qalqili Eyad Ali Mohammad | Method and system for transmitting and/or receiving advertisment and data contents on a mobile communication device with a display mechanisem |
US10341378B2 (en) | 2010-04-22 | 2019-07-02 | The Trustees Of Columbia University In The City Of New York | Methods, systems, and media for inhibiting attacks on embedded devices |
US9392017B2 (en) | 2010-04-22 | 2016-07-12 | The Trustees Of Columbia University In The City Of New York | Methods, systems, and media for inhibiting attacks on embedded devices |
CN101930375A (en) * | 2010-08-26 | 2010-12-29 | 深圳市共进电子有限公司 | Self-adaptive program data updating method of memory space in single user optical network unit |
US10887340B2 (en) | 2012-02-15 | 2021-01-05 | The Trustees Of Columbia University In The City Of New York | Methods, systems, and media for inhibiting attacks on embedded devices |
US9921954B1 (en) * | 2012-08-27 | 2018-03-20 | Avago Technologies General Ip (Singapore) Pte. Ltd. | Method and system for split flash memory management between host and storage controller |
CN103645924A (en) * | 2013-12-27 | 2014-03-19 | 金三立视频科技(深圳)有限公司 | Method and device for managing program parameters of embedded device |
US10657262B1 (en) * | 2014-09-28 | 2020-05-19 | Red Balloon Security, Inc. | Method and apparatus for securing embedded device firmware |
US11361083B1 (en) | 2014-09-28 | 2022-06-14 | Red Balloon Security, Inc. | Method and apparatus for securing embedded device firmware |
US11334605B2 (en) | 2015-06-04 | 2022-05-17 | Here Global B.V. | Incremental update of compressed navigational databases |
US20190073235A1 (en) * | 2016-04-21 | 2019-03-07 | Nec Corporation | Network system, patch file application method, and recording medium |
Also Published As
Publication number | Publication date |
---|---|
KR20040022451A (en) | 2004-03-12 |
WO2003009136A1 (en) | 2003-01-30 |
JP2004536405A (en) | 2004-12-02 |
US20040237068A1 (en) | 2004-11-25 |
US20030084434A1 (en) | 2003-05-01 |
EP1410181A1 (en) | 2004-04-21 |
CN1529847A (en) | 2004-09-15 |
US6760908B2 (en) | 2004-07-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20050063242A1 (en) | Embedded software update methods and systems for digital devices | |
EP1519268B1 (en) | Communication terminal and communication network for partially updating software, software update method, and software creation device and method therefor | |
US20080196019A1 (en) | Method and Apparatus for Generating an Update Package | |
EP0968468B1 (en) | Computer memory organization and method therefor | |
US8200886B2 (en) | Efficient system and method for updating a memory device | |
US7055035B2 (en) | Method for generating a read only memory image | |
CN101557583B (en) | Remote-updating and version-switching method of repeater equipment embedded software | |
JP4891902B2 (en) | Electronic device, update server device, key update device | |
KR100584338B1 (en) | Method and system for updating software | |
US20080270677A1 (en) | Safe software revision for embedded systems | |
EP1403771A1 (en) | Non-volatile memory control method | |
CN101904105A (en) | Mobile handset employing efficient backup and recovery of blocks during update | |
JPWO2006075576A1 (en) | Secure device and IC card issuing system | |
JP2002099441A (en) | Communication terminal apparatus and its operating method | |
CN110232262A (en) | A kind of reinforcement means and system of Android application | |
Shafi et al. | No-reboot and zero-flash over-the-air programming for wireless sensor networks | |
EP1755039A1 (en) | Feedback linker for increased delta performance | |
US20170124339A1 (en) | Implementing method for javacard application function expansion | |
WO2005048075A2 (en) | Embedded software update methods and systems for digital devices | |
CN1758220A (en) | Method of updating software release | |
CN111610984B (en) | Android application packaging and distributing method and system based on plug-in and application terminal | |
CN114237654A (en) | OTA (over the air) upgrading method and system | |
CN100401814C (en) | Protection method of PHS mobile communication PIM card authentication data | |
KR20090103214A (en) | Method of partial upgrade of handheld terminal software with partial patch and handheld terminal performing the same | |
JP4655291B2 (en) | In-vehicle apparatus and application program maintenance method thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |