US8561049B2 - Method and system for updating content stored in a storage device - Google Patents

Method and system for updating content stored in a storage device Download PDF

Info

Publication number
US8561049B2
US8561049B2 US11/508,337 US50833706A US8561049B2 US 8561049 B2 US8561049 B2 US 8561049B2 US 50833706 A US50833706 A US 50833706A US 8561049 B2 US8561049 B2 US 8561049B2
Authority
US
United States
Prior art keywords
content
update
original
block
updated
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.)
Active, expires
Application number
US11/508,337
Other languages
English (en)
Other versions
US20070050430A1 (en
Inventor
Sharon Peleg
Evyatar Meller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Red Bend Ltd
Original Assignee
Red Bend Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Red Bend Ltd filed Critical Red Bend Ltd
Priority to US11/508,337 priority Critical patent/US8561049B2/en
Publication of US20070050430A1 publication Critical patent/US20070050430A1/en
Assigned to PLENUS II (D.C.M.), LIMITED PARTNERSHIP, PLENUS II, LIMITED PARTNERSHIP reassignment PLENUS II (D.C.M.), LIMITED PARTNERSHIP LIEN (SEE DOCUMENT FOR DETAILS). Assignors: RED BEND LTD.
Assigned to RED BEND LTD. reassignment RED BEND LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MELLER, EVYATAR, PELEG, SHARON
Assigned to RED BEND LTD. reassignment RED BEND LTD. RELEASE OF LIENS Assignors: PLENUS II (D.C.M.), LIMITED PARTNERSHIP, PLENUS II, LIMITED PARTNERSHIP
Assigned to MUSTANG MEZZANINE FUND LP reassignment MUSTANG MEZZANINE FUND LP SECURITY AGREEMENT Assignors: RED BEND LTD.
Assigned to MUSTANG MEZZANINE FUND LP reassignment MUSTANG MEZZANINE FUND LP SECURITY AGREEMENT Assignors: RED BEND LTD.
Assigned to MUSTANG MEZZANINE FUND LP reassignment MUSTANG MEZZANINE FUND LP SECURITY AGREEMENT Assignors: RED BEND LTD.
Publication of US8561049B2 publication Critical patent/US8561049B2/en
Application granted granted Critical
Assigned to RED BEND LTD. reassignment RED BEND LTD. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: MUSTANG MEZZANINE LP
Active legal-status Critical Current
Adjusted expiration legal-status Critical

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
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • 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/658—Incremental updates; Differential updates

Definitions

  • This invention relates to a method and system for in-place updating content stored in a storage device. More specifically this method relates to in-place updating an original version of content to an updated version in a non volatile storage device that includes blocks.
  • the content is software, or a program (such as an executable file), it is sometimes required to fix a bug existing therein or introduce new features thereto.
  • the latter example is non-limiting and other types of content may also require updates, such as text, data stored in a database, etc.
  • the terms “old version” or “original version” refer to a version of content before update
  • the terms “new version” or “updated version” refer to a version that includes already updated content.
  • an original version includes “original content” while an updated version includes “updated content”.
  • updated content can be further updated.
  • the updated content of the first update turns to be original content of the second update while new updated content is generated by the second update, etc.
  • a process that updates original content yielding updated content is referred to as an “update process”.
  • the update process usually requires instructions, instructing it how to perform the update.
  • Such instructions provided for the update process constitute, together, an “update package”, wherein each instruction included therein constitutes an “update command”. That is, an update process obtains an update package as input, and operates in accordance therewith in order to update the original content to updated content.
  • an update process can obtain more than one update package allowing them, together, to update the content.
  • the update process can sometimes retrieve an update package (or a set of update commands) from a storage device or from a database, etc.
  • the update process can passively obtain the package, it can actively retrieve the package or sometimes it can activate a package embedded therein (e.g., a hard coded set of update commands).
  • One way to update an original version to an updated version is storing the updated version in the storage device in addition to the original version.
  • a computer program “prog.exe” is activated whenever a user presses a certain icon on the PC (Personal Computer) windows desktop.
  • prog.exe it is possible to store the updated version of this file in a different location than the present (original) version, and then reset the path associated with the icon so as to activate the updated version instead of the original version.
  • the original version can be deleted safely, releasing the space occupied thereby.
  • This latter update method requires that the complete updated version be provided to the update process, e.g., in the update package.
  • Such an update package can easily be huge in size, and if it is required to transmit it to the updated device via band-width limited communication channels, transmittance may become cumbersome and sometimes even impossible. Therefore, it is preferable that the size of the update package be reduced.
  • Another update method can simply overwrite original content with updated content.
  • This update method is risky and unreliable, because if the update process fails in the middle of updating, when part of the original version is already overwritten, while only part of the updated version is written to the storage device, it should be appreciated that the version stored on the storage device at the time of interruption is probably invalid or inoperable. In addition, the requirement to transmit the complete updated version is not yet solved with this method. Yet, it is noted that updating content by overwriting the original content with the updated content is commonly referred to in the art as “in-place update”. Hereinafter, unless specifically noted, the term “update” is used to describe “in-place update”.
  • An update package is by including in it information representing the differences between the original and updated content.
  • Such an update package is sometimes referred to also as a “difference”, a “difference result” or a “delta”.
  • the update process upon operating in accordance with a delta, applies it to the original content, thereby producing the updated content.
  • U.S. Pat. No. 6,546,552 (“Difference extraction between two versions of data-tables containing intra-references”, published 2003) discloses a method for generating a compact difference result between an old program and a new program.
  • Each program includes reference entries that contain references that refer to other entries in the program.
  • the old program is scanned and for each reference entry, the reference is replaced by a distinct label mark, whereby a modified old program is generated.
  • the new program is scanned and for each reference entry the reference is replaced by a distinct label mark, whereby a modified new program is generated.
  • the difference result is generated.
  • WO 2004/114130 (“Method and system for updating versions of content stored in a storage device”, published 2004) discloses a system and method for generating a compact update package between an old version of content and a new version of content.
  • the system of WO 2004/114130 includes a conversion element generator for generating a conversion element associated with the old version and new version. It also includes a modified version generator for generating a modified version, and an update package generator for generating the compact update package.
  • the compact update package includes the conversion element and a modified delta based on the modified version and the new version.
  • WO 2005/003963 (“Method and system for updating versions of content stored in a storage device”, published 2005) discloses a system and method for updating versions of content stored in a storage device.
  • the system of WO 2005/003963 includes an update module for obtaining a conversion element and a small delta. It also includes a converted old items generator for generating converted old items by applying the conversion element to items of an old version, a data entries generator for generating data entries based on the modified data entries and on the converted old item, and a new version generator for generating a new version of content by applying the commands and the data entries to the old version.
  • an update package is sometimes referred to as a delta, however, this is non-limiting, and as it appears from WO 2004/114130 and WO 2005/003963, the update package sometimes includes a delta therewith.
  • a storage device can be a volatile storage device (such as Random Access Memory, RAM) or a non-volatile storage device (such as a hard disk or flash memory).
  • RAM Random Access Memory
  • non-volatile storage device such as a hard disk or flash memory
  • flash memory devices for example, wherein it is required to completely delete the present content of a block, before new content (including updated content) can be written thereto, and hard disks where it is not obligatory to delete the complete sector before writing data thereto, but it is required to write the complete content of a block in one writing operation (e.g., it is impossible to write only x bytes when leaving the content stored in the z-x bytes unaffected; In order to leave the z-x bytes unaffected, it is required to store the content thereof in the volatile memory device and write them back into the block, together with the x bytes).
  • the update procedure may require many write operations to the storage device including blocks, and it is appreciated that in order to achieve an efficient update, the update should better be optimized. For example, if x equals, for example, two bytes, than these two bytes should better be updated together, instead of updating the first byte and then the second byte, writing these two bytes separately into the block.
  • U.S. Pat. No. 6,018,747 (“Method for generating and reconstructing in-place delta files”, published 2000) discloses a method, apparatus, and article of manufacture for generating, transmitting, replicating, and rebuilding in-place reconstructible software updates to a file from a source computer to a target computer.
  • U.S. Pat. No. 6,018,747 stores the first version of the file and the updates to the first version of the file in the memory of the source computer. The first version is also stored in the memory of the target computer. The updates are then transmitted from the memory of the source computer to the memory of the target computer. These updates are used at the target computer to build the second version of the file in-place.
  • U.S. Pat. No. 6,018,747 when a delta file attempts to read from a memory offset that has already been written, this will result in an incorrect reconstruction since the prior version data has been overwritten. This is termed a write before read conflict.
  • U.S. Pat. No. 6,018,747 teaches how to post-process a delta file in order to create a delta file, minimize the number of write before read conflicts, and then replace copy commands with add commands to eliminate conflicts.
  • a digraph is generated, for representing the write before read conflicts between copy commands.
  • a schedule is generated that eliminates write before read conflicts by converting this digraph into an acyclic digraph.
  • U.S. Pat. No. 6,018,747 uses the delta file in order to backup, or protect, content overwritten during write before read conflicts. Hence, the delta file is enlarged.
  • Another known problem in the art occurs when a process of updating an old version is interrupted before its normal termination, such as in a power failure. In such a case, there is a possibility that the content of the block which was updated during the interruption may become corrupted and contain unexpected content.
  • U.S. Pat. No. 6,832,373 (“System and method for updating and distributing information”, published 2004), for example, tries coping with the problem. It discloses devices, systems and methods for updating digital information sequences that are comprised by software, devices, and data. In addition, these digital information sequences may be stored and used in various forms, including, but not limited to files, memory locations, and/or embedded storage locations. Furthermore, the devices, systems, and methods described in U.S. Pat. No. 6,832,373 provide a developer skilled in the art with an ability to generate update information as needed and, additionally, allow users to proceed through a simplified update path, which is not error-prone, and according to U.S. Pat. No. 6,832,373's inventors, may be performed more quickly than through the use of technologies existing when U.S. Pat. No. 6,832,373 was filed.
  • U.S. Pat. No. 6,832,373 describes using an auxiliary backup block, while all block update operations are performed thereby using two phases ‘two-phase protocol’ or ‘two-phase commit’.
  • the update process in a first phase of updating a block, writes the updated content to the auxiliary backup block and verifies that the content is correctly stored.
  • the update process writes the updated content into its target block to form the updated content of the updated block.
  • Variations of the same method exist, such as copying the original content of the updated block into the auxiliary backup block in the first phase, and in the second phase updating the target block to store the updated content.
  • every backup operation backups the complete (original or updated) content of a block in the auxiliary backup block, and hence if the number of blocks updated by the update process is n, the total number of operations required for the update process (including update operations and write operations into the auxiliary backup block) can not be smaller than 2n. If there are blocks into which content is written in more than one write operation, the number of operations that the update process is required to perform will be even larger than 2n.
  • the present disclosure illustrates a method for in-place updating original content of an original version stored in a non-volatile storage device, to yield updated content of an updated version, wherein at least part of content of each one of n (n>1) blocks of the original version are modified in the updated version, the non-volatile storage device including blocks, the method comprising:
  • each block storage operation includes writing content to a block in the non-volatile storage device
  • the block storage operations include update block storage operations storing updated content of the updated version in the non-volatile storage device, the updated content is generated in accordance with at least the update package;
  • the present disclosure further illustrates a method for in-place updating original content of an original version stored in a non-volatile storage device, to yield updated content of an updated version, the non-volatile storage device including blocks, the method comprising:
  • each block storage operation includes writing content to a block in the non-volatile storage device
  • the block storage operations include at least one backup block storage operation, wherein each backup block storage operation includes storing protected content stored in one or more segments of one or more blocks of the non-volatile storage device in a non-volatile protection buffer;
  • the block storage operations also include update block storage operations storing updated content of the updated version in the non-volatile storage device, the updated content is generated in accordance with at least the update package;
  • in-place updating includes less backup block storage operations than update block storage operations.
  • the present disclosure further illustrates a method for updating original content of an original version stored in a storage device to yield updated content of an updated version, in accordance with an update package, the method comprising:
  • the segments are source segments of transforming update commands
  • the present disclosure still further illustrates a method for in-place updating original content of an original version stored in a non-volatile storage device, to yield updated content of an updated version, the non-volatile storage device including blocks and the original version occupies more than one block, the method comprising:
  • the non-volatile backup buffer including at least one block, wherein at least one block of the non-volatile backup buffer is used for protecting original content originated from more than one block in the original version;
  • the present disclosure illustrates a program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform a method for in-place updating original content of an original version stored in a non-volatile storage device, to yield updated content of an updated version, wherein at least part of content of each one of n (n>1) blocks of the original version are modified in the updated version, the non-volatile storage device including blocks, the method comprising:
  • each block storage operation includes writing content to a block in the non-volatile storage device
  • the block storage operations include update block storage operations storing updated content of the updated version in the non-volatile storage device, the updated content is generated in accordance with at least the update package;
  • the present disclosure illustrates a computer program product comprising a computer useable medium having computer readable program code embodied therein for in-place updating original content of an original version stored in a non-volatile storage device, to yield updated content of an updated version, wherein at least part of content of each one of n (n>1) blocks of the original version are modified in the updated version, the non-volatile storage device including blocks, the computer program product comprising:
  • each block storage operation includes writing content to a block in the non-volatile storage device
  • the block storage operations include update block storage operations storing updated content of the updated version in the non-volatile storage device, the updated content is generated in accordance with at least the update package;
  • the present disclosure illustrates a program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform a method for in-place updating original content of an original version stored in a non-volatile storage device, to yield updated content of an updated version, the non-volatile storage device including blocks, the method comprising:
  • each block storage operation includes writing content to a block in the non-volatile storage device
  • the block storage operations include at least one backup block storage operation, wherein each backup block storage operation includes storing protected content stored in one or more segments of one or more blocks of the non-volatile storage device in a non-volatile protection buffer;
  • the block storage operations also include update block storage operations storing updated content of the updated version in the non-volatile storage device, the updated content is generated in accordance with at least the update package;
  • the present disclosure still further illustrates a computer program product comprising a computer useable medium having computer readable program code embodied therein for in-place updating original content of an original version stored in a non-volatile storage device, to yield updated content of an updated version, the non-volatile storage device including blocks, the computer program product comprising:
  • each block storage operation includes writing content to a block in the non-volatile storage device
  • the block storage operations include at least one backup block storage operation, wherein each backup block storage operation includes storing protected content stored in one or more segments of one or more blocks of the non-volatile storage device in a non-volatile protection buffer;
  • the block storage operations also include update block storage operations storing updated content of the updated version in the non-volatile storage device, the updated content is generated in accordance with at least the update package;
  • in-place updating includes less backup block storage operations than update block storage operations.
  • the invention includes an apparatus for generating an update package, wherein the update package is configured to optimize an update sequence.
  • the optimization will achieve a protected content size which is smaller than any other protected content size achieved by other update sequence sequences.
  • the protected content size is smaller than the average protected content size achieved by other possible update sequences.
  • the protected content size is smaller than an arbitrary size of a protected content that depends on an arbitrary update sequence associated with the update package.
  • other variants are also applicable.
  • FIG. 1 is a schematic illustration of a system for updating versions in a cellular network, in accordance with one embodiment of the invention
  • FIG. 2A illustrates an example of an original and updated versions having corresponding segments
  • FIG. 2B illustrates how an ambiguous portion or a segment is formed when updating the original version of FIG. 2A to the updated version thereof;
  • FIG. 2C illustrates one way, known in the art, to solve the write-before-read conflict of FIG. 2B ;
  • FIG. 2D illustrates an alternative way, known in the art, to solve the write-before-read conflict of FIG. 2B ;
  • FIG. 3A illustrates other example of an original and updated versions having corresponding segments
  • FIG. 3B illustrates an update package adapted for updating the original version of FIG. 3A to the updated version thereof;
  • FIG. 3C illustrates updating the original version of FIG. 3A to the updated version thereof
  • FIG. 3D illustrates updating the original version of FIG. 3A to the updated version thereof
  • FIG. 4 is a flowchart illustrating generation of a conflict resolving update package
  • FIG. 5A is a schematic illustration of another example of an original version, and the updated version thereof;
  • FIG. 5B is a schematic illustration of a protection buffer used while updating the original version of FIG. 5A to the updated version thereof, in accordance with one embodiment of the invention
  • FIG. 5C is a schematic illustration of a protection buffer used while updating the original version of FIG. 5A to the updated version thereof, in accordance with another embodiment of the invention.
  • FIG. 6 is a flowchart illustrating in detail one embodiment for determining an update sequence
  • FIG. 7 is a flowchart illustrating generation of an update package, in accordance with one embodiment of the invention.
  • FIG. 8A and FIG. 8B illustrate together a flowchart depicting updating of an original version to an updated version thereof, in accordance with one embodiment of the invention
  • FIG. 9 illustrates an apparatus for generating an update package, in accordance with one embodiment of the invention.
  • FIG. 10 illustrates an apparatus for updating an original version of content to an updated version thereof, in accordance with another embodiment of the invention.
  • FIG. 1 is a schematic illustration of a system 101 for updating versions in a cellular network, in accordance with one embodiment of the invention.
  • Cellular telephones 102 that are coupled to or include storage devices 103 , execute programs that enable their operation. Programs are normally stored in files.
  • the version of the program currently executing on a cellular telephone is referred to, hereinafter, as an “old version” or as an “original version”.
  • memory devices such as the storage devices 103 , are sometimes referred to also as “memory devices” or “memory units”.
  • an update package is generated in an update package generator 104 , operating, for example, in a personal computer (PC) or in any other type of computer.
  • the update package is stored in an update server 105 and transmitted, via a transmitter 106 to the cellular telephones 102 .
  • system 101 illustrated in FIG. 1 is a non-limiting example and the invention is not limited to updating programs.
  • Many other types of content stored in storage devices require update, such as data stored in databases, files stored in the storage device etc. Therefore, hereinafter the term “content” will be used instead of “program”.
  • the invention is not limited to cellular networks and/or to cellular telephones 102 .
  • cellular telephones belong to a group referred to as embedded devices.
  • embedded devices such as Personal Digital Assistants (PDAs), set-top boxes and other consumer electronic devices that are coupled to storage devices for storing content, and sometimes it is required to update the content stored therein.
  • PDAs Personal Digital Assistants
  • the storage devices 103 can be, for example, hard-disk drives, Flash-memory devices, EPROMs (Erasable Programmable Read-Only Memory) and EEPROMs (Electrically EPROM) or any other storage device.
  • a PC or any other computer
  • files that include data required for its operation or for operation of programs executing therein (such as “info files” or “dot files” known for those versed in the art).
  • info files or “dot files” known for those versed in the art.
  • it is required to update this data for example, via communication lines, e.g., via the Internet or via any other communication means.
  • the term “updated devices” will be used hereinafter, and it should be noted that the term “updated device” can refer to any device that is coupled to a storage device and allows updating content stored therein.
  • update packages are generated, stored in the update server 105 and conveyed to the updated devices (such as the cellular telephones 102 ) and the storage devices coupled therewith.
  • the updated devices such as the cellular telephones 102
  • the update package is conveyed via the transmitter 106 .
  • an updated device When an updated device receives an update package, it can operate an update process in accordance with the update package, wherein the update process updates the original version for generating an updated version. It should be noted that the updated device can operate the update process immediately after receiving the update package. Alternatively it can store the update package in a non-volatile memory, such as in the storage device 103 , and operate the update process at some later time (such as the next time the updated device reboots).
  • a storage device can store content of more than one original and/or updated version. For example, it is appreciated that there can be several computer programs installed in a single hard disk.
  • a file is constituted of logically sequential content.
  • the character ‘2’ is logically consecutive to the character ‘1’
  • the character ‘3’ is logically consecutive to the character ‘2’, etc.
  • the stored file, or the content included therein can be fragmented, i.e., different portions of the file can be stored in different portions, or blocks, of the storage device.
  • a logically sequential content is not necessarily stored in a physically sequential manner in the storage device.
  • a logically sequential content is not necessarily stored in a physically sequential manner in the storage device and/or that the size of the logically sequential content can be larger than the size of a block, it should be appreciated that logically sequential content can be spread over several storage blocks.
  • one storage block can include content belonging to several logically sequential contents (such as several files).
  • the content “1234” can be stored in one physical block, while the content “56789” in this example can be stored in a different physical block that physically precedes the block where “1234” is stored (yet it is clear that logically the content “1234” precedes the content “56789”).
  • the logically sequential text “123456789” will be further considered as an original version.
  • this file it is possible to update this file to include an updated version, wherein the text stored in the updated version is “123756489”.
  • the characters ‘4’ and ‘7’ were switched, compared to their position in the original version.
  • the character ‘7’ in the updated version replaces the character ‘4’ that appears in the original version, while the character ‘4’ replaces the character ‘7’. It should thus be appreciated that in order to generate this updated version, it is possible, e.g., to divide the original version into several segments (each segment constitutes a “logical block”).
  • the first segment includes the content “123”, the second segment's content is “4”, the third segment includes “56”, the fourth includes “7” and the fifth includes “89”.
  • the first, third and fifth segments are left intact, while the content of the second and fourth segments are switched.
  • a segment includes logically sequential content.
  • segment “12” can yet reside on two different blocks, as long as the blocks are sequential (a first block sequentially preceding a second block) and as long as the character ‘1’ is stored in an area ending the first block while the character ‘2’ is stored in the area opening the second block.
  • an alternative embodiment can limit a segment to occupy physically sequential area in one physical block (unlike “one or more” in the previous example).
  • a segment can be further divided into two segments (one is “1” and the second is “2”).
  • moving a segment or leaving it intact are not the only behaviors, or transformations, that are allowed. For example, it is possible to delete a segment or to perform a calculation on the content stored therein.
  • “4” and “7” are still considered segments in the original version.
  • an “updated segment” When content of a segment in the updated version (an “updated segment”) corresponds to content of a segment in the original version (an “original segment”), these segments are considered as “corresponding segments” or “matched segments”.
  • Correspondence refers to any logical or arithmetic connection between the segments, wherein the updated segment can be a copy of the original segment, it can be a modified copy of the original segment (e.g., it is sometimes preferred to copy the content of a segment and then modify part or all of the copied content), it can include content received by computing the content of the updated segment based on content of the original segment, etc.
  • FIG. 2A illustrates a portion of a storage device wherein an original 2 A 01 and updated 2 A 02 versions have corresponding segments.
  • two segments 2 A 03 and 2 A 04 in the original version 2 A 01 correspond to segments 2 A 03 ′ and 2 A 04 ′, in the updated version 2 A 02 , respectively, and vice versa: the segments 2 A 03 ′ and 2 A 04 ′ correspond to segments 2 A 03 and 2 A 04 .
  • the content of the segment 2 A 03 is similar to the content of segment 2 A 03 ′ and the content of the segment 2 A 04 is similar to the content of segment 2 A 04 ′, although the segments 2 A 03 ′ and 2 A 04 ′ are positioned in the storage device differently (i.e., in different addresses) than the segments 2 A 03 and 2 A 04 .
  • the relative order is also changed. That is, segment 2 A 03 physically precedes segment 2 A 04 in the storage device, but segment 2 A 04 ′ physically precedes segment 2 A 03 ′.
  • FIG. 2B illustrates how an ambiguous portion of a segment is formed when updating the original version 2 A 01 of FIG. 2A to the updated version 2 A 02 thereof.
  • the content of segment 2 A 04 is moved before moving the content of segment 2 A 03 , thus generating an intermediate version 2 B 01 in the storage device. It is illustrated by the intermediate version 2 B 01 that part of segment 2 A 04 ′ overlaps part of segment 2 A 03 , still positioned in its original position. Therefore, content of segment 2 A 04 ′ overwrites part of segment 2 A 03 's content.
  • the overlapped original content of the segment's portion 2 B 02 being part of 2 A 03 , is lost.
  • This segment's portion ( 2 B 02 ) illustrates an “ambiguous portion”, caused by an overlap, and it represents a “conflict” between two segments.
  • a conflict such as the conflict illustrated in FIG. 2B is known in the art as “write-before-read conflict”.
  • a write-before-read conflict arises when an original segment or a portion thereof, still required by the update process for further updating segments (such as segment 2 A 03 whose original content is required for the generation of segment 2 A 03 's content), is being altered or lost before it is being used (in the example it is before copying the content of segment 2 A 03 for generating segment 2 A 03 ′).
  • the term “conflict” is used below to refer, in short, to the term “write-before-read conflict”.
  • segment 2 A 03 can be protected from conflict by copying it to its new position (that is, to segment 2 A 03 ′), before the content of segment 2 A 04 ′ overwrites it, as illustrated in the example of FIG. 2C .
  • An intermediate version 2 C 01 includes the original segment 2 A 04 and the updated segment 2 A 03 ′, and then the content of segment 2 A 04 can be safely moved to its new position (segment 2 A 04 ′) in the new version 2 A 02 .
  • FIGS. 2A , 2 B and 2 C provide an example of a copy-cycle for which a correct copy order can resolve conflicts.
  • the content of segment 2 A 03 is copied to a memory area 2 D 01 , named “backup buffer”, “backup storage” or “protection buffer”, turning the original content stored in the segment 2 A 03 into redundant content or released content, while the segment, or area, previously occupied by the released content is referred to as a “released area”, marked in the intermediate version 2 D 03 as 2 D 02 .
  • This allows copying the content of segment 2 A 04 to its new position 2 A 04 ′ that partially overlaps the released area 2 D 02 without overwriting the content of segment 2 A 03 , as illustrated by the intermediate version 2 D 04 .
  • the protection buffer is a storage area available to the update process, that is, this storage area does not include the area used for storing the original and/or updated content, not the storage area used for storing the update package.
  • FIG. 3A illustrates another example of an original version 3 A 01 and updated version 3 A 02 having corresponding segments 3 A 03 , 3 A 04 and 3 A 03 ′, 3 A 04 ′ respectively. Similar to FIG. 2A , the updated segment 3 A 04 ′ conflicts with original segment 3 A 03 , illustrated by the ambiguous portion 3 A 05 . However, unlike the example of FIG. 2A , here there is also a conflict between the updated segment 3 A 03 ′ and the original segment 3 A 04 , illustrated by the ambiguous portion 3 A 06 . Therefore, a person versed in the art will appreciate that the solution of FIG. 2C , that is, changing the copy order, is not applicable here. It is noted that the example of FIG. 3A allows no copy order that can avoid the illustrated write-before-read conflicts.
  • FIG. 3A provides an example of a copy-cycle for which a correct copy order for resolving conflicts does not exist. It should be appreciated that other copy-cycles may exist, where there are more then two segments involved (“multiple-copy-cycles”). Even in such multiple-copy-cycles there is sometimes no conflict-resolving copy order. For example, a copy-cycle of four segments (A, B, C and D) could be created in the following way: updated A conflicts with original B, updated B conflicts with original C, updated C conflicts with original D and updated D conflicts with original A. It is appreciated that this copy cycle allows no conflict-resolving copy order.
  • the update process updating the original version 3 A 01 to the updated version 3 A 02 can use a method similar to the one illustrated in FIG. 2D for resolving the conflicts. More specifically, it can use a protection buffer for storing copies of the original conflicting segments.
  • FIG. 3B illustrates an update package 3 B 01 adapted for updating the original version 3 A 01 of FIG. 3A to the updated version 3 A 02 thereof.
  • the update package 3 B 01 includes 3 B 02 , a portion that includes content similar to the content of original segment 3 A 03 , thus rendering the original content of segment 3 A 03 redundant.
  • the update process can safely copy the content of segment 3 A 04 to its updated position, the corresponding segment 3 A 04 ′, in accordance with the update command 3 B 03 .
  • the content of segment 3 A 04 becomes redundant too, thus allowing the update process to overwrite it with the content stored in 3 B 02 , which is a copy of the original content of segment 3 A 03 . This is done, according to the current example, in accordance with the insert command 3 B 04 of the update package 3 B 01 .
  • the size of the protected segment can be used as an optimization criterion. If the size of the original segment 3 A 04 is smaller than the size of the original segment 3 A 03 , then it may be desired to store a copy of segment 3 A 04 's content, instead of storing a copy of the content stored in 3 A 03 as illustrated in FIG. 3B . Furthermore, instead of storing a copy of content stored in at least one conflicting segment, it is possible to store a copy of content stored in at least one ambiguous portion. If the sizes of the ambiguous portions are used as an optimization criterion, then according to the example it is possible to try storing only these (one or more) ambiguous portions whose size is smaller.
  • FIG. 3C illustrates updating the original version 3 A 01 of FIG. 3A to the updated version 3 A 02 thereof. While generating an update package 3 C 01 , because the size of the ambiguous portion 3 A 06 is smaller then the size of the ambiguous portion 3 A 05 , a copy of the original content of this ambiguous portion 3 A 06 is inserted into the update package (see 3 C 02 ). It is noted that 3 C 02 protects the content of portion 3 A 06 , and hence it allows deleting (or modifying) the content thereof.
  • the update package 3 C 01 includes the following update commands:
  • the update command 3 C 03 instructs the update process to copy the original content of 3 A 03 to generate the updated content of segment 3 A 03 ′, overwriting portion 3 A 06 of segment 3 A 04 , yet, the original content of portion 3 A 06 is protected by 3 C 02 .
  • Segment 3 A 03 becomes now a released segment;
  • the update command 3 C 04 instructs the update process to copy the content of 3 A 04 to 3 A 04 ′ (it is noted that the content copied in accordance with this command includes also a portion of the content stored in segment 3 A 03 ′, that is, it includes a copy of the content that overwrote portion 3 A 06 as illustrated in the figure, represented by portion 3 C 08 ); and the update command 3 C 05 instructs the update process to insert the content stored in 3 C 02 (i.e., content similar to the original content of portion 3 A 06 ), into 3 C 08 , for restoring the content of 3 A 04 ′.
  • the insert command 3 C 05 is a “restoration update command” or shortly, a “restoration command” and in the figure it is represented as “restore” in order to emphasize this. Yet, it is noted that 3 C 05 could be an insert command (like 3 B 04 in FIG. 3B ).
  • this example assumes that the update is performed in accordance with a certain sequence (constituting an “update sequence”), wherein 3 A 03 is copied to 3 A 03 ′, then 3 A 04 is copied to 3 A 04 ′ and then 3 C 08 is restored.
  • the update sequence is influenced by the size of the ambiguous portion 3 A 06 , which is smaller than the size of the ambiguous portion 3 A 05 , and hence an update package including a copy thereof is smaller than an update package including a copy of 3 A 05 .
  • FIG. 3D illustrates yet another example for updating the original version 3 A 01 of FIG. 3A to the updated version 3 A 02 thereof.
  • content that needs to be protected from conflicts is stored in a protection buffer in the storage device.
  • an update command 3 D 02 is inserted thereto, instructing the update process to store a copy of the original content of the ambiguous portion 3 A 06 in a protection buffer 3 D 03 , protecting its content thereby.
  • the command 3 D 02 constitutes a “backup command”, a “protection update command”, or shortly, a “protection command”.
  • the update process needs to perform this command before overwriting portion 3 A 06 with content of the segment 3 A 03 ′.
  • the operation performed by the update process in accordance with a protection command is referred as a “protection operation”, “protect operation” or “backup operation” and it is noted that instead of using an explicit “protect” update command, a “copy” command could have been used.
  • the update process When operating in accordance with the update command 3 D 02 , the update process copies the content of portion 3 A 06 into the protection buffer 3 D 03 , thus generating a protected portion 3 D 04 .
  • the update process can safely operate in accordance with the update command 3 C 03 and copy the original content of 3 A 03 to the segment 3 A 03 ′, overwriting the content of the ambiguous portion 3 A 06 , whose original content is protected in the protection buffer 3 D 03 .
  • the version in the storage device becomes an intermediate version 3 D 05 .
  • the update process can operate in accordance with the update command 3 C 04 , and copy the content of segment 3 A 04 to its new position 3 A 04 ′′ in the intermediate version 3 D 06 .
  • the portion 3 A 06 includes content that was originally part of 3 A 03 .
  • the portion 3 C 08 a small portion of the original content of 3 A 03 is copied too, as illustrated by the portion 3 C 08 .
  • the size of the portion 3 C 08 is similar to that of the ambiguous portion 3 A 06 .
  • the update process is required to restore the content of 3 C 08 to be similar to the original content of segment 3 A 06 .
  • the update process operates in accordance with the update command 3 D 07 , thus copying the protected content of 3 D 04 to replace the content of the portion 3 C 08 , thus giving rise to the expected content of segment 3 A 04 ′.
  • 3 D 07 is another example of a restoration command yet a copy command could have been used instead.
  • segment B there may be another segment or portion thereof (“segment B”) whose update requires, e.g., to add the value stored in the original segment A to a number stored in the original segment B, wherein the result of the addition is stored in the updated segment B.
  • segment B Even though the position of the updated segment A (or the portion storing the number in it) is kept similar to the position of the original segment A, indeed its content is changed (the original 2 is replaced by 4).
  • the update process must avoid using the updated content of segment A. This can be done by storing the original content of segment A in the protection buffer (or in the update package), thus protecting the original content of segment A.
  • the updated segment A in this non-limiting example corresponds to the original segment A.
  • the updated segment B corresponds to both the original segment A and the original segment B.
  • both the update packages 3 C 01 and 3 D 01 of FIGS. 3C and 3D are referred to as conflict resolving update packages.
  • the update package 3 D 01 includes more update commands compared to the update package 3 C 01 , as it includes also the backup update command 3 D 01 .
  • Backup commands may backup large quantities of content, and therefore they may slow down the update process.
  • the embodiment of FIG. 3C does not require backup commands to be inserted into the update package 3 C 01 , and therefore they allow the update process to be faster.
  • the update package 3 C 01 is used for storing the protected data instead of the protection buffer 3 D 03 , and therefore, as long as the size of the protected data is larger than the size of the respective backup command, the update package 3 C 01 is larger in size than the update package 3 D 01 .
  • the update packages are conveyed to the updated devices, e.g., by transmitting them over communication lines, a larger update package may be a limitation.
  • FIG. 4 is a flowchart illustrating generation of a conflict resolving update package.
  • the flowchart corresponds to embodiments using a protection buffer for protecting content of conflicting segments.
  • an update package is obtained.
  • the update package can be generated by any way known in the art (see, for example, U.S. Pat. No. 6,546,552, WO 2004/114130, WO 2005/003963 and diff).
  • the update package can be generated during 401 in order to form a basis for the presently referenced flowchart (of FIG. 4 ), or it can be pre-generated and obtained by any available method (such as reading it from a storage device, receiving it from communication lines, via inter-process communication, etc.).
  • the update package is analyzed in order to identify segments-which form conflicting segments. This can be done by constructing a digraph and identifying cycles (or in other words, “copy-cycles”) therein, as described, e.g., by U.S. Pat. No. 6,018,747. It is noted that conflicting segments include ambiguous portions whose sizes can be similar or smaller than the size of their respective segments, thus leaving zero or more unambiguous portions in the segments.
  • a selected segment that includes an ambiguous portion is split into ambiguous and unambiguous portions, thus giving rise to two segments, one ambiguous and one unambiguous. It is noted that sometimes a segment includes more than two portions (more than one ambiguous and/or more than one unambiguous). For example, when the ambiguous portion is in the middle of the segment, there can be at least two unambiguous portions and one ambiguous portion. In such a case the segment would be split into more than two segments.
  • a new update command is generated for each of the unambiguous segments, and in 406 a protection command and a restoration command are generated for each ambiguous segment.
  • the original update command that generated the conflict is removed from the update package and in 408 the new update commands, as well as the protection commands are inserted into the update package, replacing the removed update commands.
  • the restoration commands are inserted into the update package, instead of the insertion commands inserted, for example, in accordance with U.S. Pat. No. 6,018,747.
  • FIG. 5A is a schematic illustration of another example of an original version 5 A 01 , and an updated version 5 A 02 thereof.
  • the updated version 5 A 02 occupies basically the same blocks in the storage device previously occupied by the original version 5 A 01 .
  • the original version 5 A 01 occupies at least three storage blocks, specifically referenced as 5 A 03 , 5 A 04 and 5 A 05 .
  • the updated version 5 A 02 occupies at least the same blocks.
  • 5 A 03 ′ denotes block 5 A 03 when updated content is stored therein
  • 5 A 04 ′ denotes block 5 A 04 when updated content is stored therein
  • 5 A 05 ′ denoted block 5 A 05 when updated content is stored therein.
  • the block 5 A 03 includes four segments: 5 A 06 , 5 A 07 , 5 A 08 and 5 A 09 ;
  • the block 5 A 04 includes six segments: 5 A 10 , 5 A 11 , 5 A 12 , 5 A 13 , 5 A 14 and 5 A 15 ; and the block 5 A 05 includes three segments: 5 A 16 , 5 A 17 and 5 A 18 .
  • segment 5 A 06 During update, the content stored in segment 5 A 06 is deleted and thus it has no corresponding segment in the updated version 5 A 02 .
  • Other deleted segments are 5 A 10 , 5 A 12 and 5 A 18 .
  • the content stored in segment 5 A 07 is moved (copied) to block 5 A 05 ′, thus generating segment 5 A 07 ′.
  • the content stored in segment 5 A 08 is left in block 5 A 03 ′, constituting segment 5 A 08 ′, but as segment 5 A 06 is deleted, the segment 5 A 08 ′ (or at least part thereof) now occupies addresses in the block that previously were occupied by the content of 5 A 06 , or in other words, it becomes the first segment in the block, which belongs to the updated version 5 A 02 .
  • segment 5 A 09 The content stored in segment 5 A 09 is copied from block 5 A 03 to block 5 A 04 ′, constituting segment 5 A 09 ′ therein. It is noted that the segments 5 A 07 ′, 5 A 08 ′ and 5 A 09 ′ are segments in the updated version that correspond to segments 5 A 07 , 5 A 08 and 5 A 09 , respectively.
  • segments 5 A 11 and 5 A 13 are copied to block 5 A 03 ′, generating the corresponding segments 5 A 11 ′ and 5 A 13 ′ therein, respectively. Yet, in the original version segment 5 A 11 precedes segment 5 A 13 , while in the updated version 5 A 02 their respective order changes and segment 5 A 13 ′ precedes segment 5 A 11 ′. In addition, content is inserted into three new segments ( 5 A 19 , 5 A 20 and 5 A 21 ) in block 5 A 03 ′, and it is noted that none of these new segments ( 5 A 19 , 5 A 20 and 5 A 21 ) correspond to segments in the original version.
  • segment 5 A 14 of block 5 A 04 is left in the same block 5 A 04 ′, giving rise to the corresponding segment 5 A 14 ′, and the content stored in segment 5 A 15 of the same block ( 5 A 04 ) is moved (copied) into block 5 A 05 ′, constituting segment 5 A 15 ′.
  • the segment 5 A 16 of block 5 A 05 corresponds to segment 5 A 16 ′ in block 5 A 05 ′.
  • the segment 5 A 16 ′ is the first segment in block 5 A 05 ′ being part of the updated version 5 A 02 .
  • the updated content of segment 5 A 16 ′ is not necessarily identical to original content stored in segment 5 A 16 , and in this case the size of the updated content of 5 A 16 ′ is larger than the size of the original content of 5 A 16 .
  • an update command can insert one or more zeros (O's) along the content of the updated segment.
  • Such a command could, for example, insert a hundred zeros after each original thousand bytes.
  • the update command allowing updating the content of 5 A 16 to the content of 5 A 16 ′ can be indicative of any other transforming operation, such as “convert lower case characters to lower case character” etc.
  • the segment 5 A 17 of block 5 A 05 corresponds to segment 5 A 17 ′ of block 5 A 05 ′, but their physical positions in the block are different.
  • protection buffer 5 A 25 available for the update process.
  • size of a protection buffer is not limited by the invention, in the present example of FIG. 5A the protection buffer size is two storage blocks wherein one storage block is referenced as 5 A 26 and the other as 5 A 27 . Yet, it is noted that this is a non limiting example, and the protection buffer can be of any size.
  • the invention is adapted to storage devices including blocks, wherein writing updated content into a block affects other content stored therein.
  • the update process updates block 5 A 05 ′, then block 5 A 04 ′ and then block 5 A 03 ′.
  • RAM Random Access Memory
  • RAM includes no blocks and hence, content written to the RAM does not affect other content written therein. For example, and there is no requirement to erase content stored in a block before writing any piece of content (e.g., a segment) thereto and similarly, there is no requirement to write the complete content of a block during one write operation.
  • there is no special importance to the order of the update commands relating to one updated block, as long as access efficiency is considered.
  • the update package includes the commands “insert 5 A 24 ”, then “copy 5 A 15 to 5 A 15 ′”, followed by “copy 5 A 17 to 5 A 17 ′”, “copy 5 A 07 to 5 A 07 ′”, and “update 5 A 16 to yield 5 A 16 ′”. Yet, as for access efficiency considerations, this is equivalent to “copy 5 A 17 to 5 A 17 ′”, followed by “update 5 A 16 to yield 5 A 16 ′”, “copy 5 A 15 to 5 A 15 ′”, “copy 5 A 07 to 5 A 07 ′” and “insert 5 A 24 ”.
  • segment 5 A 17 is copied into segment 5 A 17 ′ of the same block ( 5 A 05 ).
  • 5 A 17 ′ appears to precede 5 A 17 , i.e., the updated content of 5 A 17 ′ does not overwrite the original content of 5 A 17 .
  • the original content of 5 A 17 is implicitly protected by 5 A 17 ′, and this original content does not require explicit protection (e.g., in a protection buffer).
  • segment 5 A 15 is copied into segment 5 A 15 ′ of block 5 A 05 ′. This is done while updating block 5 A 05 ′, i.e., before updating blocks 5 A 04 ′ and 5 A 03 ′.
  • the original content of 5 A 15 has already been copied into 5 A 15 ′, which is in a block preceding 5 A 04 ′ in the update sequence. Therefore, in the example of FIG. 5A there is no need to explicitly protect the original content of 5 A 15 .
  • the example of FIG. 5A is non-limiting.
  • the update package allows the update process to update the original version 5 A 01 to the updated version 5 A 02 , while first executing update commands for updating block 5 A 05 ′, then update commands for updating block 5 A 04 ′ and then update commands for updating block 5 A 03 ′.
  • After updating block 5 A 05 ′ it is possible to update 5 A 03 ′ and finally block 5 A 04 ′.
  • n is the number of blocks that include modified data being part of the new version. All these n! update sequences give rise to the same updated version.
  • An “update sequence” or “update order” is the order in accordance with which blocks of the updated version are updated (or written).
  • an operating environment of an updated device can be pre-configured to allocate one or more areas in the storage device 103 that are used for backup and/or protection purposes of operations performed by any software executed by the device. Updating content is one example for such an operation. Such an area is the “protection buffer”. According to one embodiment described by way of example with reference to FIG. 3D , it is possible to protect original content of a segment by storing a copy thereof in a protection buffer 3 D 03 in the storage device 103 thus reducing the size of the update package, compared to a package storing content of protected segments therein.
  • content of more than one segment can be stored in the protection buffer. It is noted that if after storing portions the protection buffer includes unused area, it is possible to use this unused area for storing copies of content stored in additional segments requiring protection (or portions thereof). These additional protected segments can be stored in the current block or they can be stored in other blocks in the storage device. That is, it is possible to store segments or portions thereof in the protection buffer, instead of copying complete blocks thereto.
  • an ambiguous segment can be split into one or more ambiguous segments and one or more non-ambiguous segments.
  • the update commands are adapted to correspond to the split segments. Realizing this, it is noted that hereinafter, instead of speaking of an ambiguous segment and/or an ambiguous portion thereof, segments (and/or ambiguous segments) will be discussed.
  • FIG. 5B is a schematic illustration of a protection buffer 5 B 01 used while updating the original version of FIG. 5A to the updated version thereof, in accordance with one embodiment of the invention.
  • the size of the protection buffer 5 B 01 is two storage blocks, as is the case with the protection buffer 5 A 25 of FIG. 5A , however, this is non-limiting and the protection buffer can be of any applicable size. It is noted that when the update process begins operating, the protection buffer is empty, or in other words, the size of the unused area thereof is similar to the size of the protection buffer.
  • the selected update sequence is 5 A 05 ′, 5 A 04 ′ and then 5 A 03 ′.
  • the original content of segment 5 A 16 requires protection.
  • the size of segment 5 A 16 is smaller than the size of the protection buffer, and therefore the original content of segment 5 A 16 is copied thereto.
  • the segment 5 A 17 also requires protection. Because the size of segment 5 A 17 is smaller than the unused area of the protection buffer, the original content of segment 5 A 17 can also be copied thereto. Now, when all the segments of 5 A 05 that require protection are protected, the content stored in block 5 A 05 can be safely overwritten by the updated content of 5 A 05 ′ (that is, by the updated content of segments 5 A 16 ′, 5 A 07 ′, 5 A 17 ′, 5 A 15 ′ and 5 A 24 ). As already explained, copying original content into the protection buffer provides protection to ambiguous segments as and/or reliability of the update process.
  • the used area of the protection buffer 5 B 01 is a little larger than the size of one storage block. If the size of the protection buffer would have been only one storage block, thus, there would not have been enough unused area to store the copy of segment 5 A 08 therein. When the protection buffer does not have sufficient unused area for protecting all segments requiring protection, their content needs to be backed up in alternative storage areas, such as the update package itself as described in U.S. Pat. No. 6,018,747 or with reference to FIG. 3C .
  • FIG. 5C is a schematic illustration of a protection buffer 5 C 01 used while updating the original version of FIG. 5A to the updated version thereof, in accordance with another embodiment of the invention.
  • the update sequence is selected in order to reduce the number of protection operations or the area used by protected content.
  • the usage of the protection buffer 5 C 01 illustrates the protection operations required when the update sequence is 5 A 05 ′, 5 A 03 ′ and finally 5 A 04 ′.
  • the original content of segments 5 A 16 and 5 A 17 is copied into the protection buffer before overwriting them with the updated content of block 5 A 05 ′.
  • the segment 5 A 07 does not require protection.
  • the content of segments 5 A 08 and 5 A 09 that needs protection is copied into the unused area of the protection buffer 5 C 01 without copying the content of 5 A 07 .
  • the protection buffer 5 C 01 includes content of fewer segments compared to the protection buffer 5 B 01 (five segments in 5 C 01 , unlike six segments in 5 B 01 ). A person versed in the art would appreciate that this reduction in the number of protected portions results due to the implicit protection of three segments ( 5 A 11 , 5 A 13 and 5 A 15 ) achieved by updating block 5 A 03 ′ before block 5 A 04 ′.
  • the used area of the protection buffer 5 C 01 after protecting required original content of segments in all three blocks is smaller than the used area of the protection buffer 5 B 01 . Again, this is due to having larger segments implicitly protected by selecting the above-mentioned update sequence ( 5 A 05 ′, 5 A 03 ′ and then 5 A 04 ′).
  • the update sequence affects the time during which it is required to keep a copy of an original content of a segment in the protection buffer.
  • segment 5 A 09 is required for updating block 5 A 04 ′.
  • the update sequence determines that block 5 A 03 ′ should be updated before block 5 A 04 ′, then the original content of segment 5 A 09 should be copied into the protection buffer. It is possible (although not shown in the figure) that between updating blocks 5 A 03 ′ and 5 A 04 ′ other blocks (additional blocks that not illustrated) are updated, while 5 A 04 ′ is the last block updated in accordance with the update sequence.
  • Size of a segment is the number of bytes occupied by the segment. However, this is non-limiting and it is possible to measure the size of a segment by any other applicable measure, such as bits, words, etc.
  • every original block has a dependency value, denoted as DEP(block).
  • DEP(block) The original segments of a block B that correspond to updated segments in the updated version constitute “original corresponding segments”. Understanding that the segments in an old block that potentially require protection are original corresponding segments, the dependency value of a block is determined as the total size of all the original corresponding segments included therein. Initially the DEP value of a block is given by Equation 1.
  • B i is an i'th block in a storage device (it is noted that blocks mentioned herein are updated blocks, i.e., blocks whose original content is overwritten by updated content, while it is unnecessary to protect content stored in those blocks that are not updated);
  • FIG. 6 is a flowchart illustrating in detail one embodiment for determining an update sequence. It is noted that an update sequence determined by the illustrated embodiment is determined in order to reduce the area or space used by protected content. It should also be understood that being the order in accordance with which the updated blocks are updated in the storage device, an update sequence is always determined in connection with an update package (as it is the update package that determines the update sequence in accordance with which the update process operates).
  • a pre-prepared update package is analyzed in order to identify corresponding segments, e.g., by identifying original segments whose content is copied into segments of the updated version and/or updated segments whose content is calculated based on content of original segments etc. It is noted that non-corresponding segments included in the updated version (i.e., segments that have no correspondence with segments in the original version), such as new content that is inserted into the updated version without any correspondence to the original version, does not necessarily affect the update sequence. Alternatively, the corresponding segments can be pre-identified (see, for example, FIG. 7 ), in which case 601 can be skipped.
  • a pre-prepared update package is not a pre-requisite. If there is no pre-prepared update package, it is possible to generate one, for example, by utilizing a diff tool as is known in the art or by any other way such as by the methods described in U.S. Pat. No. 6,546,552, WO 2004/114130 or WO 2005/003963.
  • blocks will be listed in an “update sequence queue”, when the block whose dependency is lowest will be inserted thereto first (and therefore it will be the first to be retrieved).
  • an empty queue is initialized.
  • this embodiment is non-limiting and other data structures, such as a stack, can be used as well, as can be appreciated by those having skills in the art.
  • the first block to be updated in accordance with the update sequence i.e., the first block to be pushed into the update sequence queue, is the block whose DEP is lowest.
  • the block in the blocks list whose DEP value is the smallest is selected. It is noted that if there are several (more then one) blocks with the same smallest DEP value, then one of them is selected, e.g., according to the smallest i.
  • the selected block is denoted B j .
  • B j depends on other blocks. That is, there are possibly updated segments in B j (or more specifically, in the updated version of B j ) whose corresponding original segments are in other original blocks in the storage device. For each such other block B o that is listed in the blocks list, segments corresponding to segments in the updated version of B j are identified (it is possible to recognize the segments according to the start and end addresses of the other blocks listed in the blocks list) and their size is reduced from DEP(B o ).
  • each block B o listed in the blocks list is tested to see whether B j depends on it or not (i.e., whether the updated content stored in B j includes a segment whose corresponding source segment is in the old version of that block B o ). If B j depends on the tested block B o , in 611 the depending segments are identified and their total size is reduced from the dependency value (DEP) of the tested block B o . That is, if there are t updated segments in B j that correspond to old segments in B o ,
  • B o is a block in the blocks list (not yet in the update list) on which B j depends;
  • CS i is an updated segment in the new version of B j that corresponds to an old segment in B o .
  • the update sequence queue represents the determined update sequence.
  • the update package can be re-arranged to reflect the update sequence.
  • a representation of the update sequence can be, for example, by sorting and storing the update commands in the update package according to their target segments addresses, in accordance with the update sequence.
  • FIG. 7 is a flowchart illustrating generation of an update package, in accordance with one embodiment of the invention.
  • the generator has to predict the updated devices' behavior, including protection buffer usage, thus allowing to improve usage thereof, e.g., by determining the update sequence. Only upon predicting that the protection buffer is fully occupied (or unavailable), copy commands are replaced with insert commands, as done, for example, in U.S. Pat. No. 6,018,747.
  • an update package (constituting a first update package) is obtained by any method. It can be generated locally, or received from an external source, e.g., via a communication network, in an inter-process communication, by reading it from any kind of storage device, etc.
  • the update package (constituting a first update package) can be generated by any known method, such as in accordance with U.S. Pat. No. 6,546,552, WO 2004/114130 or WO 2005/003963 or by utilizing a known per se diff tool.
  • the first update package is analyzed in 702 in order to identify corresponding segments and an update sequence.
  • the update sequence can be determined, for example, in accordance with FIG. 6 described above. It is noted that before determining the update sequence it is possible to analyze the update package in order to identify corresponding segments therein. Alternatively, it is possible to identify corresponding segments when determining the update sequence (see for example, 601 in FIG. 6 ). In addition, in those cases when the update package is pre-organized in accordance with a preferred update sequence, or when it is associated, e.g., with information laying out a preferred update sequence (such as a list), 702 can be skipped.
  • An update package generated in accordance with this latter embodiment is adapted for updated devices that have free area larger or equal in size to the predetermined size. For example, it is possible to determine the required size of the protection buffer (such as the pre-determined size), e.g. in the update package generator, and store the required size in the update package. When an updated device receives the update package, or when the update process starts operating accordingly, the updated device can try to allocate a protection buffer, in accordance with the required size stored in the update package. If there is not enough free storage area in the device for allocating the protection buffer, it is possible to terminate the operation of the update process, thus avoiding, e.g., memory overflow.
  • update package server 105 It is even further possible to inform the update package server 105 about the situation, possibly including the updated size of the available storage area, thus allowing transmission or re-transmission of an update package better adapted to the updated device. It is noted that such an update package can be pre-prepared by the update-package generator 104 and be pre-stored in the update server as described below. Alternatively, the update server can instruct the update package generator 104 to generate an update package adapted to the available size etc.
  • a cursor is initiated in 704 to be indicative of the first update command in the update sequence. This cursor constitutes a “commands cursor”.
  • update commands are generally divided, according to the embodiment, into three main categories.
  • One category includes commands that are founded, or based on original content stored in segments of the original version, or in other words, such commands use original content in order to generate updated content.
  • These commands constitute “founded commands” or “transforming commands”.
  • a “copy command” belongs to the category of transforming commands.
  • a transforming command thus, has a “source segment” (the original segment on whose original content the command is based) and a “target segment” (the updated segment whose updated content is generated by the transforming update command).
  • the second category, of “incorporating commands”, includes update commands that incorporate into the updated version updated content that is not based on original content.
  • an “inset command” introduces content into the updated version; this content is not taken from the original version, but more likely from the update package or from any other source.
  • the third category is of “erasing commands”. An erasing command erases original content included in a segment of the original version, without yielding a corresponding segment thereof in the updated version.
  • An example of an erasing command is the “delete” update command.
  • copy commands are not the only transforming commands. Any command that has a source segment and a target segment is a transforming command. For example, one such transforming command can transform all lower case characters stored in the source segment to upper case. Another transforming command can multiply a number stored in the source segment by a certain value, etc.
  • the content affected by a transforming command constitutes “modified content”.
  • the block where the source segment resides (constituting a “source block”)
  • the block where the target segment resides (constituting a “target block”)
  • at least part of the content of the source block is modified in the target block. That is, it is possible that part of the source block is, e.g., deleted, and hence does not form part of the content stored in the updated block.
  • the source segment is marked as free. It is noted that instead of marking a source segment as free, alternative embodiments can delete the original content of the source segment or perform any other applicable operation, including not performing an operation at all.
  • the commands cursor is advanced to the next update command in accordance with the update sequence. To this end it is noted that during update package generation there is no need to update the original version to the updated version, and “simulation” thereof is sufficient. Thus, when operating in accordance with the flow chart of FIG. 7 , the update package generator (or any other processor generating the update package accordingly) does not have to operate in accordance with the update commands.
  • the protection buffer can be reused in order to increase its effectivity, as was already noted with reference to FIGS. 5A , 5 B and 5 C.
  • some embodiments can free the area used by this not-required content (e.g., by physically deleting the content or by marking it as free etc.) thus allowing the update process to re-use the free area for further backup operations required while updating.
  • Reusing the protection buffer effectively allows performing more protection operations and hence, the update package size can be reduced (less protected content needs to be stored therein).
  • the reuse is simulated during generation of the update package, hence allowing the generator to know when the protection buffer is full and when there is a free space therein.
  • FIG. 8A and FIG. 8B illustrating together a flowchart depicting updating an original version to an updated version thereof, in accordance with one embodiment of the invention.
  • the flowchart depicted in FIG. 8A and FIG. 8B is applicable, for example, in an update process operable in an updated device. It should be appreciated that the illustrated embodiment is adapted to operate in an updated device having a storage device including blocks.
  • an update process When an update process starts operating, in 801 it obtains, or accesses an update package stored in the storage device 103 , e.g., in volatile or non-volatile memory. It is appreciated that the updated device could have received the update package previously from the update server 105 . Alternatively, the update package was loaded to the storage device by any applicable means, such as by copying it from a portable memory device (e.g., a floppy or compact disc) or by receiving it from the Internet. It should be further appreciated that according to the embodiment, the accessed update package has a certain update sequence.
  • the update sequence can be determined simply by the order of the update commands in the update package, or is can be determined in accordance with additional information stored in association with the update package, such as a list determining the sequence for executing update commands, e.g., if different from the sequence in which the commands appear in the package.
  • the update sequence is adapted to reduce protection buffer usage in the updated device, or at least improves utilization of the protection buffer available therein.
  • the update package could have been generated and the update sequence could have been determined (e.g., in an update package generator) in accordance with the flowcharts of FIGS. 6 and 7 .
  • the update process checks in 802 that there is enough storage device available in the updated device for running the update process in accordance with the update package obtained in 801 . According to the embodiment, if the update package includes an indication of the required protection buffer size, this required protection buffer size is compared in 802 with the protection buffer size available in the updated device, terminating the update process if the available protection buffer size is not enough.
  • a pointer or a cursor is initiated in 803 to be indicative of the first update command in accordance with the update sequence.
  • This cursor constitutes a “commands cursor”.
  • the commands cursor will be further advanced in accordance with the update sequence.
  • a pointer to the protection buffer is initiated, constituting a “protection pointer”.
  • the protection pointer is indicative of the position in the protection buffer into which protected data should be written next.
  • the updated device can generate a copy of the protected content, e.g., in RAM (constituting a “RAM protection buffer”), and then, when the RAM copy is complete (i.e., it includes all the content that needs to be protected), write it into the “non-volatile protection buffer” (constituting also a “non-volatile backup buffer”) in the non-volatile storage device.
  • Writing the protected content stored in the RAM protection buffer into the non-volatile backup buffer is referred to as “backup block storage operation”.
  • the non-volatile storage device is a storage device including blocks (unlike RAM), this method is more efficient than writing content of every protected segment directly into the non-volatile protection buffer.
  • the protection pointer is indicative of the position in the RAM protection buffer into which protected data should be written next. It is noted though that hereinafter, unless specifically noted, the description will refer to “protection buffer” without distinguishing between the RAM and the non-volatile protection buffers.
  • RAM protection buffer is only one example of a “volatile protection buffer”.
  • the update process checks (in 806 ) if the commands cursor is indicative of a transforming update command. It should be appreciated that an update command that is not a transforming update command does not require protection, and therefore, in 807 the commands cursor can be advanced to the next update command. However, if in 806 the update process determines that the update command is a transforming command, it further checks in 808 if the block that includes the command's source segment precedes or is the same as the block that includes the target segment. Again, it should be understood that if the block that includes the target segment precedes the block that includes the command's source segment, no protection is required and the update process can advance (in 807 ) the commands cursor.
  • the update process copies the source segment to the protection buffer, i.e., to the protection pointer, and in 810 it advances the protection pointer by the size of the source segment.
  • the process described so far, with reference to 806 , 807 , 808 , 809 and 810 repeats (see 805 ), until the update process protects all the segments requiring protection. After this has been completed, the content requiring protection is protected in the protection buffer.
  • the number of protection operations used to protect the protected content in the protection buffer is referred to as p.
  • the protection buffer is a RAM protection buffer
  • its content should be stored in the non-volatile protection buffer before starting to update the original content of the original version, thus overwriting at least portions of the original content, thus providing also reliability to the update process in case the process is aborted and restored.
  • the storage in the non-volatile protection buffer can take place, e.g., further to 805 , and before moving to 811 .
  • the update process can start updating the original content originally stored in the storage device, thus generating the updated version.
  • original content previously protected in the protection buffer should be read therefrom, instead of reading it from the original version.
  • a new pointer constituting a “restoration pointer” is initialized in 811 , initially pointing to the beginning of the protection buffer.
  • the commands cursor is re-set to be indicative of the first update command in the update package.
  • the illustrated embodiment is adapted for storage devices including blocks, hence creating a copy of an updated block in RAM (or generally in a “volatile updated buffer”), and then, writing the whole block to the non-volatile storage device.
  • the operation of writing the content stored in the volatile updated buffer into a block in the non-volatile storage device is referred to as “update block storage operations”. Therefore, an additional cursor, constituting “blocks cursor” is initialized in 813 , to be indicative of the first updated block in accordance with the update sequence.
  • m represents the total number of block storage operations, which includes every operation storing content in a block in the non-volatile storage device.
  • the update process determines that the commands cursor is indicative of a transforming command, it further checks, in 816 , whether the block that includes the command's source segment precedes or is equal to the block that includes the target segment.
  • the update process did not protect the source segment of this update command in 808 and 809 , leaving the original content stored in the original segment instead of copying it into the protection buffer. Therefore in 817 the update process reads the source content from the update command's source segment, and in 815 the update process operate in accordance with the update command, thus generating a copy of the target segment in RAM.
  • the update process determines that the source segment's block precedes or is the same as the target segment's block, it should read the original content (or a copy thereof) from the protection buffer. Therefore, in 818 the update process reads the source content from the address indicated by the restoration pointer, in 819 the restoration pointer is advanced by the size of the source segment, thus pointing to the next protected segment, and in 815 the update process operates in accordance with the update command, thus generating a copy of the target segment in RAM.
  • the update process can copy and write the content stored in RAM into the updated block if in 815 it wrote the content of updated block's last target segment into RAM. Therefore, in 820 the update process checks whether the commands cursor is indicative of the last update command in the block indicated by the blocks cursor, and if so, the content of the updated block, currently stored in RAM, is copied and written in 821 into the updated block in the storage device, and in 822 the blocks cursor is advanced to the next updated block.
  • the commands cursor is advanced (see 823 ) without copying the RAM stored content and without advancing the blocks cursor. It is further noted that by advancing the commands cursor (in 823 ) beyond the last command in the updated block, it becomes indicative of the first update command in the next updated block. And thus, if the advanced commands cursor precedes the last update command in accordance with the update sequence, or is equal to (see 824 ), the update process can operate in accordance with this update command, thus generating updated content (see 814 , 815 , 816 etc.). Alternatively, if in 824 the update process determines that it moved past the last update command it can terminate, as the updated version is stored in the storage device.
  • FIG. 9 illustrates an apparatus 901 for generating an update package in accordance with one embodiment of the invention, such as the update package generator 104 .
  • the update package generator 104 includes an update package obtaining unit 902 .
  • the update package obtained by the update package access unit 902 can be any update package, including a simple delta generated by applying a known per se diff tool, or any other update package, generated in accordance with any method applicable to the case.
  • the update package obtaining unit can obtain a pre-prepared update package or generate an update package in accordance with any method known in the art.
  • An update sequence analyzer 903 is coupled to the update package access unit 902 .
  • the update sequence analyzer 903 receives an update package from the update package access unit 902 and determines an update sequence that improves protection buffer usage.
  • the update sequence can be determined, for example, in accordance with the method illustrated in FIG. 6 .
  • An update package builder 904 coupled to the update sequence analyzer 903 builds a new update package, in accordance with the update package received from the update package obtaining unit 902 and the update sequence determined in the update sequence analyzer 903 .
  • FIG. 7 illustrates an embodiment of a method that can be applied in the update package builder 904 .
  • the invention includes an apparatus 901 for generating an update package, wherein the update package is configured to optimize an update sequence.
  • the optimization will achieve a protected content size which is smallest than any other protected content size achieved by any other update sequence.
  • the protected content size is smaller than the average protected content size achieved by all possible update sequences.
  • the protected content size is smaller than an arbitrary size of a protected content that depends on an arbitrary update sequence associated with the update package.
  • other variants are also applicable.
  • FIG. 10 illustrates an apparatus 1001 for updating an original version of content to an updated version thereof, in accordance with another embodiment of the invention.
  • the apparatus 1001 includes a receiver 1002 that obtains an update package.
  • the update package can be obtained by receiving it from a communication network or it can be obtained by any alternative method.
  • the apparatus 1001 further includes an update module 1003 such as an update process that is adapted to update the original version currently stored in the updated device's storage device thus generating an updated version.
  • the update module 1003 can operate, for example, in accordance with the flowchart illustrated in FIG. 8 .
  • system may be a suitably programmed computer.
  • the invention contemplates a computer program being readable by a computer for executing the method of the invention.
  • the invention further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the method of the invention.
  • a system according to the invention can be hardware.
  • the system can compose hardware and software components.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
US11/508,337 2005-08-23 2006-08-23 Method and system for updating content stored in a storage device Active 2030-10-22 US8561049B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/508,337 US8561049B2 (en) 2005-08-23 2006-08-23 Method and system for updating content stored in a storage device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US71019105P 2005-08-23 2005-08-23
US11/508,337 US8561049B2 (en) 2005-08-23 2006-08-23 Method and system for updating content stored in a storage device

Publications (2)

Publication Number Publication Date
US20070050430A1 US20070050430A1 (en) 2007-03-01
US8561049B2 true US8561049B2 (en) 2013-10-15

Family

ID=37499251

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/508,337 Active 2030-10-22 US8561049B2 (en) 2005-08-23 2006-08-23 Method and system for updating content stored in a storage device

Country Status (3)

Country Link
US (1) US8561049B2 (fr)
EP (1) EP1934727B1 (fr)
WO (1) WO2007023497A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120166872A1 (en) * 2010-12-23 2012-06-28 Samsung Electronics Co., Ltd. Condensed fota backup
US20120331454A1 (en) * 2011-06-24 2012-12-27 International Business Machines Corporation Image Delta-Based Upgrade Of Complex Stack In Software Appliance
US20150309787A1 (en) * 2007-02-15 2015-10-29 Microsoft Technology Licensing, Llc Packaging Content Updates

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2329368B1 (fr) 2008-08-04 2019-10-02 Red Bend Ltd. Mise à jour de contenu sans utiliser de mini-système d'exploitation
US8176009B2 (en) 2008-08-04 2012-05-08 Red Bend Ltd. Performing a pre-update on a non volatile memory
EP2329367B1 (fr) 2008-08-04 2014-06-11 Red Bend Ltd. Exécution d'une mise à jour sur place d'un dispositif de stockage en fonctionnement
US20100293072A1 (en) * 2009-05-13 2010-11-18 David Murrant Preserving the Integrity of Segments of Audio Streams
US8413132B2 (en) 2010-09-13 2013-04-02 Samsung Electronics Co., Ltd. Techniques for resolving read-after-write (RAW) conflicts using backup area
JP5559001B2 (ja) * 2010-10-15 2014-07-23 株式会社日立ソリューションズ 組込プログラム更新方法、組込プログラム更新プログラム、電子機器、ネットワークシステム
KR102118161B1 (ko) * 2012-06-26 2020-06-03 레드 밴드 리미티드 장치 저장의 제자리 재조직을 위한 시스템들 및 방법들
US9588884B2 (en) * 2012-06-26 2017-03-07 Red Bend Ltd. Systems and methods for in-place reorganization of device storage
US9442944B2 (en) 2013-11-12 2016-09-13 Dropbox, Inc. Content item purging
JP6380320B2 (ja) * 2015-09-29 2018-08-29 京セラドキュメントソリューションズ株式会社 電子機器、情報処理方法及びプログラム
FR3084497B1 (fr) * 2018-07-25 2020-10-02 Orange Procede et dispositif de generation d'instructions destinees a un dispositif pour mettre a jour sur place un fichier de donnees

Citations (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4654819A (en) * 1982-12-09 1987-03-31 Sequoia Systems, Inc. Memory back-up system
US5414839A (en) * 1992-06-19 1995-05-09 Digital Equipment Corporation Hybrid lock escalation and de-escalation protocols
US5432922A (en) * 1993-08-23 1995-07-11 International Business Machines Corporation Digital storage system and method having alternating deferred updating of mirrored storage disks
US5717929A (en) * 1993-03-30 1998-02-10 Sanyo Electric Co., Ltd. Apparatus and method for program execution, and image reproduction apparatus with special effects utilizing such apparatus and method
US5748967A (en) * 1993-01-11 1998-05-05 Hitachi, Ltd. Program rewriting method and apparatus for multiprocessor system
US5806078A (en) * 1994-06-09 1998-09-08 Softool Corporation Version management system
US5832520A (en) * 1996-07-03 1998-11-03 Miller, Call, Plauck And Miller Automatic file differencing and updating system
US5845313A (en) * 1995-07-31 1998-12-01 Lexar Direct logical block addressing flash memory mass storage architecture
US5943675A (en) * 1996-09-25 1999-08-24 Allen-Bradley Company, Llc Change log historian system for memory shared by multiple workstations
US6018747A (en) 1997-11-26 2000-01-25 International Business Machines Corporation Method for generating and reconstructing in-place delta files
US6233730B1 (en) * 1998-12-16 2001-05-15 Emc Corporation Revision compatibility between programs
US6374250B2 (en) * 1997-02-03 2002-04-16 International Business Machines Corporation System and method for differential compression of data from a plurality of binary sources
US20020073411A1 (en) * 2000-12-08 2002-06-13 Kunihiko Tsunedomi Controller and application installing method
US6425125B1 (en) * 1999-03-30 2002-07-23 Microsoft Corporation System and method for upgrading client software
US6542906B2 (en) * 1998-08-17 2003-04-01 Connected Place Ltd. Method of and an apparatus for merging a sequence of delta files
US6546552B1 (en) 1998-08-19 2003-04-08 Red Bend Ltd. Difference extraction between two versions of data-tables containing intra-references
US20030084434A1 (en) * 2001-07-16 2003-05-01 Yuqing Ren Embedded software update system
US20030154471A1 (en) * 2002-02-13 2003-08-14 Power Measurement Ltd. Method for upgrading firmware in an electronic device
US6640334B1 (en) * 1999-09-27 2003-10-28 Nortel Networks Limited Method and apparatus of remotely updating firmware of a communication device
US6671757B1 (en) * 2000-01-26 2003-12-30 Fusionone, Inc. Data transfer and synchronization system
US20040031030A1 (en) * 2000-05-20 2004-02-12 Equipe Communications Corporation Signatures for facilitating hot upgrades of modular software components
US20040062130A1 (en) 2002-09-30 2004-04-01 Chiang Ying-Hsin Robert Updating electronic files using byte-level file differencing and updating algorithms
WO2004031961A1 (fr) 2002-09-30 2004-04-15 Insignia Solutions Plc Systeme efficace et procede de mise a jour d'un dispositif de memoire
US6775423B2 (en) * 2000-05-03 2004-08-10 Microsoft Corporation Systems and methods for incrementally updating an image in flash memory
US20040187104A1 (en) * 2003-03-18 2004-09-23 Shantanu Sardesai Operating system deployment methods and systems
US6832373B2 (en) 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
WO2004114130A2 (fr) 2003-06-23 2004-12-29 Red Bend Ltd. Procede et systeme pour la mise a jour de versions de contenu dans un dispositif de stockage
WO2005003963A2 (fr) 2003-07-07 2005-01-13 Red Bend Ltd. Procede et systeme de mise a jour de versions de contenu memorise dans une memoire
EP1510924A1 (fr) 2003-08-27 2005-03-02 ARM Limited Dispositif et méthode pour gérer des transactions avec écritures et lectures dans des mémoires EEPROM ou Flash
US6915513B2 (en) * 2001-11-29 2005-07-05 Hewlett-Packard Development Company, L.P. System and method for dynamically replacing code
US20050149922A1 (en) * 2004-01-06 2005-07-07 International Business Machines Corporation Dynamic software update system, method and program product
US6925467B2 (en) * 2002-05-13 2005-08-02 Innopath Software, Inc. Byte-level file differencing and updating algorithms
US20050183081A1 (en) * 2001-10-31 2005-08-18 Gemplus Installation of a compiled program, particularly in a chip card
US20050188368A1 (en) * 2004-02-20 2005-08-25 Kinney Michael D. Method and apparatus for reducing the storage overhead of portable executable (PE) images
US6938109B1 (en) * 1998-06-08 2005-08-30 Microsoft Corporation Method and system for updating software with smaller patch files
US20050216530A1 (en) * 2004-03-15 2005-09-29 Red Bend Ltd. Method and apparatus for updating a stored version of content stored in a storage device
US20050229032A1 (en) * 2004-02-19 2005-10-13 Takato Kusama Method for rearranging logical volume
US6970969B2 (en) * 2002-08-29 2005-11-29 Micron Technology, Inc. Multiple segment data object management
US20060004756A1 (en) * 2004-06-01 2006-01-05 Red Bend Ltd. Method and system for in-place updating content stored in a storage device
US7007049B2 (en) * 2002-11-18 2006-02-28 Innopath Software, Inc. Device memory management during electronic file updating
US20060080650A1 (en) * 2002-03-01 2006-04-13 Derek Winters Method and system for reducing storage requirements for program code in a communication device
US20070150524A1 (en) * 2003-11-19 2007-06-28 Johan Eker Uptating data in a mobile terminal
US20070226328A1 (en) * 2006-03-02 2007-09-27 Hitachi, Ltd. Storage management method and server
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

Patent Citations (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4654819A (en) * 1982-12-09 1987-03-31 Sequoia Systems, Inc. Memory back-up system
US5414839A (en) * 1992-06-19 1995-05-09 Digital Equipment Corporation Hybrid lock escalation and de-escalation protocols
US5748967A (en) * 1993-01-11 1998-05-05 Hitachi, Ltd. Program rewriting method and apparatus for multiprocessor system
US5717929A (en) * 1993-03-30 1998-02-10 Sanyo Electric Co., Ltd. Apparatus and method for program execution, and image reproduction apparatus with special effects utilizing such apparatus and method
US5432922A (en) * 1993-08-23 1995-07-11 International Business Machines Corporation Digital storage system and method having alternating deferred updating of mirrored storage disks
US5806078A (en) * 1994-06-09 1998-09-08 Softool Corporation Version management system
US5845313A (en) * 1995-07-31 1998-12-01 Lexar Direct logical block addressing flash memory mass storage architecture
US5832520A (en) * 1996-07-03 1998-11-03 Miller, Call, Plauck And Miller Automatic file differencing and updating system
US5943675A (en) * 1996-09-25 1999-08-24 Allen-Bradley Company, Llc Change log historian system for memory shared by multiple workstations
US6374250B2 (en) * 1997-02-03 2002-04-16 International Business Machines Corporation System and method for differential compression of data from a plurality of binary sources
US6018747A (en) 1997-11-26 2000-01-25 International Business Machines Corporation Method for generating and reconstructing in-place delta files
US6938109B1 (en) * 1998-06-08 2005-08-30 Microsoft Corporation Method and system for updating software with smaller patch files
US6542906B2 (en) * 1998-08-17 2003-04-01 Connected Place Ltd. Method of and an apparatus for merging a sequence of delta files
US6546552B1 (en) 1998-08-19 2003-04-08 Red Bend Ltd. Difference extraction between two versions of data-tables containing intra-references
US6233730B1 (en) * 1998-12-16 2001-05-15 Emc Corporation Revision compatibility between programs
US6425125B1 (en) * 1999-03-30 2002-07-23 Microsoft Corporation System and method for upgrading client software
US6640334B1 (en) * 1999-09-27 2003-10-28 Nortel Networks Limited Method and apparatus of remotely updating firmware of a communication device
US6671757B1 (en) * 2000-01-26 2003-12-30 Fusionone, Inc. Data transfer and synchronization system
US6775423B2 (en) * 2000-05-03 2004-08-10 Microsoft Corporation Systems and methods for incrementally updating an image in flash memory
US20040031030A1 (en) * 2000-05-20 2004-02-12 Equipe Communications Corporation Signatures for facilitating hot upgrades of modular software components
US6832373B2 (en) 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
US20020073411A1 (en) * 2000-12-08 2002-06-13 Kunihiko Tsunedomi Controller and application installing method
US20030084434A1 (en) * 2001-07-16 2003-05-01 Yuqing Ren Embedded software update system
US20050183081A1 (en) * 2001-10-31 2005-08-18 Gemplus Installation of a compiled program, particularly in a chip card
US6915513B2 (en) * 2001-11-29 2005-07-05 Hewlett-Packard Development Company, L.P. System and method for dynamically replacing code
US20030154471A1 (en) * 2002-02-13 2003-08-14 Power Measurement Ltd. Method for upgrading firmware in an electronic device
US20060080650A1 (en) * 2002-03-01 2006-04-13 Derek Winters Method and system for reducing storage requirements for program code in a communication device
US6925467B2 (en) * 2002-05-13 2005-08-02 Innopath Software, Inc. Byte-level file differencing and updating algorithms
US6970969B2 (en) * 2002-08-29 2005-11-29 Micron Technology, Inc. Multiple segment data object management
US20040062130A1 (en) 2002-09-30 2004-04-01 Chiang Ying-Hsin Robert Updating electronic files using byte-level file differencing and updating algorithms
WO2004031961A1 (fr) 2002-09-30 2004-04-15 Insignia Solutions Plc Systeme efficace et procede de mise a jour d'un dispositif de memoire
US20070192532A1 (en) * 2002-09-30 2007-08-16 Insignia Solutions Plc Efficient system and method for updating a memory device
US20040088473A1 (en) * 2002-09-30 2004-05-06 Ogle Andrew J. Efficient system and method for updating a memory device
US7779055B2 (en) * 2002-11-18 2010-08-17 Innopath Software, Inc. Device memory management during electronic file updating
US7007049B2 (en) * 2002-11-18 2006-02-28 Innopath Software, Inc. Device memory management during electronic file updating
US20040187104A1 (en) * 2003-03-18 2004-09-23 Shantanu Sardesai Operating system deployment methods and systems
WO2004114130A2 (fr) 2003-06-23 2004-12-29 Red Bend Ltd. Procede et systeme pour la mise a jour de versions de contenu dans un dispositif de stockage
WO2005003963A2 (fr) 2003-07-07 2005-01-13 Red Bend Ltd. Procede et systeme de mise a jour de versions de contenu memorise dans une memoire
EP1510924A1 (fr) 2003-08-27 2005-03-02 ARM Limited Dispositif et méthode pour gérer des transactions avec écritures et lectures dans des mémoires EEPROM ou Flash
US20070150524A1 (en) * 2003-11-19 2007-06-28 Johan Eker Uptating data in a mobile terminal
US20050149922A1 (en) * 2004-01-06 2005-07-07 International Business Machines Corporation Dynamic software update system, method and program product
US20050229032A1 (en) * 2004-02-19 2005-10-13 Takato Kusama Method for rearranging logical volume
US20050188368A1 (en) * 2004-02-20 2005-08-25 Kinney Michael D. Method and apparatus for reducing the storage overhead of portable executable (PE) images
US20050216530A1 (en) * 2004-03-15 2005-09-29 Red Bend Ltd. Method and apparatus for updating a stored version of content stored in a storage device
US20060004756A1 (en) * 2004-06-01 2006-01-05 Red Bend Ltd. Method and system for in-place updating content stored in a storage device
US20070226328A1 (en) * 2006-03-02 2007-09-27 Hitachi, Ltd. Storage management method and server
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

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"Mainframe Software Upgrade: Evolution, Not Revolution" Aberdeen Group , Feb. 2001 , , pp. 1-6. *
"Mainframe Software Upgrade: Evolution, Not Revolution" Aberdeen Group , Feb. 2001 , <http://sirius-software.com/articles/mfevolve.html>, pp. 1-6. *
Cahndrasekhar Boyapati et al. , "Lazy Modular Upgrades in Persistent Object Stores", ACM , 2003 , , pp. 1-15. *
Cahndrasekhar Boyapati et al. , "Lazy Modular Upgrades in Persistent Object Stores", ACM , 2003 , <http://delivery.acm.org/10.1145/950000/949341/p403-boyapati.pdf>, pp. 1-15. *
Eran Gal et al. , "Mapping Structures for Flash Memories:Techniques and Open Problems", IEEE , 2005 , , pp. 1-10. *
Eran Gal et al. , "Mapping Structures for Flash Memories:Techniques and Open Problems", IEEE , 2005 , <Mapping Structures for Flash Memories: Techniques and Open Problems>, pp. 1-10. *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150309787A1 (en) * 2007-02-15 2015-10-29 Microsoft Technology Licensing, Llc Packaging Content Updates
US9471301B2 (en) * 2007-02-15 2016-10-18 Microsoft Technology Licensing, Llc Packaging content updates
US20120166872A1 (en) * 2010-12-23 2012-06-28 Samsung Electronics Co., Ltd. Condensed fota backup
US8924777B2 (en) * 2010-12-23 2014-12-30 Samsung Electronics Co., Ltd. Condensed FOTA backup
US20120331454A1 (en) * 2011-06-24 2012-12-27 International Business Machines Corporation Image Delta-Based Upgrade Of Complex Stack In Software Appliance
US8997085B2 (en) * 2011-06-24 2015-03-31 International Business Machines Corporation Image delta-based upgrade of complex stack in software appliance

Also Published As

Publication number Publication date
US20070050430A1 (en) 2007-03-01
WO2007023497A1 (fr) 2007-03-01
EP1934727A1 (fr) 2008-06-25
EP1934727B1 (fr) 2019-01-16

Similar Documents

Publication Publication Date Title
US8561049B2 (en) Method and system for updating content stored in a storage device
US8418167B2 (en) Methods and systems for updating content including a compressed version
US8453138B2 (en) Method and apparatus for generating an update package
US7587433B2 (en) Method and system for in-place updating content stored in a storage device
US9043680B2 (en) Method and system for in-place updating content stored in a storage device
US7599970B2 (en) Method and apparatus for updating a stored version of content stored in a storage device
JP4901095B2 (ja) 不揮発性ストレージにカスタム・ソフトウェア・イメージ・アップデートを適用するフェイルセーフな方法
US20080172584A1 (en) Method and system for in-place updating content stored in a storage device
EP2329366B1 (fr) Exécution d&#39;une mise à jour préalable dans une mémoire non volatile
EP2329368B1 (fr) Mise à jour de contenu sans utiliser de mini-système d&#39;exploitation
US8578359B2 (en) Method and apparatus for reliable in-place update
US8689207B2 (en) Performing an in-place update of an operating storage device
JP2018077690A (ja) アプリケーションの実行環境の違いに依る互換性を考慮したインストール、及びファームアップ方法
US20220100496A1 (en) Tracking history of firmware program updates

Legal Events

Date Code Title Description
AS Assignment

Owner name: PLENUS II, LIMITED PARTNERSHIP,ISRAEL

Free format text: LIEN;ASSIGNOR:RED BEND LTD.;REEL/FRAME:018993/0161

Effective date: 20070312

Owner name: PLENUS II (D.C.M.), LIMITED PARTNERSHIP,ISRAEL

Free format text: LIEN;ASSIGNOR:RED BEND LTD.;REEL/FRAME:018993/0161

Effective date: 20070312

Owner name: PLENUS II, LIMITED PARTNERSHIP, ISRAEL

Free format text: LIEN;ASSIGNOR:RED BEND LTD.;REEL/FRAME:018993/0161

Effective date: 20070312

Owner name: PLENUS II (D.C.M.), LIMITED PARTNERSHIP, ISRAEL

Free format text: LIEN;ASSIGNOR:RED BEND LTD.;REEL/FRAME:018993/0161

Effective date: 20070312

AS Assignment

Owner name: RED BEND LTD., ISRAEL

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MELLER, EVYATAR;PELEG, SHARON;REEL/FRAME:019449/0791

Effective date: 20061026

AS Assignment

Owner name: MUSTANG MEZZANINE FUND LP, ISRAEL

Free format text: SECURITY AGREEMENT;ASSIGNOR:RED BEND LTD.;REEL/FRAME:022551/0826

Effective date: 20090407

Owner name: RED BEND LTD., ISRAEL

Free format text: RELEASE OF LIENS;ASSIGNORS:PLENUS II, LIMITED PARTNERSHIP;PLENUS II (D.C.M.), LIMITED PARTNERSHIP;REEL/FRAME:022552/0037

Effective date: 20090407

Owner name: MUSTANG MEZZANINE FUND LP,ISRAEL

Free format text: SECURITY AGREEMENT;ASSIGNOR:RED BEND LTD.;REEL/FRAME:022551/0826

Effective date: 20090407

Owner name: RED BEND LTD.,ISRAEL

Free format text: RELEASE OF LIENS;ASSIGNORS:PLENUS II, LIMITED PARTNERSHIP;PLENUS II (D.C.M.), LIMITED PARTNERSHIP;REEL/FRAME:022552/0037

Effective date: 20090407

AS Assignment

Owner name: MUSTANG MEZZANINE FUND LP, ISRAEL

Free format text: SECURITY AGREEMENT;ASSIGNOR:RED BEND LTD.;REEL/FRAME:025008/0297

Effective date: 20100916

AS Assignment

Owner name: MUSTANG MEZZANINE FUND LP, ISRAEL

Free format text: SECURITY AGREEMENT;ASSIGNOR:RED BEND LTD.;REEL/FRAME:028831/0963

Effective date: 20120725

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

AS Assignment

Owner name: RED BEND LTD., ISRAEL

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MUSTANG MEZZANINE LP;REEL/FRAME:035083/0471

Effective date: 20150226

FEPP Fee payment procedure

Free format text: PAT HOLDER NO LONGER CLAIMS SMALL ENTITY STATUS, ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: STOL); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8