EP2329366B1 - Exécution d'une mise à jour préalable dans une mémoire non volatile - Google Patents

Exécution d'une mise à jour préalable dans une mémoire non volatile Download PDF

Info

Publication number
EP2329366B1
EP2329366B1 EP09787502.5A EP09787502A EP2329366B1 EP 2329366 B1 EP2329366 B1 EP 2329366B1 EP 09787502 A EP09787502 A EP 09787502A EP 2329366 B1 EP2329366 B1 EP 2329366B1
Authority
EP
European Patent Office
Prior art keywords
content
update
updated
memory
place
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
Application number
EP09787502.5A
Other languages
German (de)
English (en)
Other versions
EP2329366A2 (fr
Inventor
Evyatar Meller
Sharon Peleg
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
Publication of EP2329366A2 publication Critical patent/EP2329366A2/fr
Application granted granted Critical
Publication of EP2329366B1 publication Critical patent/EP2329366B1/fr
Active legal-status Critical Current
Anticipated 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 updating content stored in a storage device. More specifically this invention relates to in-place updating an original version of content in a non- volatile storage to an updated version.
  • a process during which original content is updated yielding updated content is referred to as an "update process”.
  • the update process usually requires instructions on how to perform the update. Such instructions constitute together an “update package", wherein each instruction included therein constitutes an "update command". That is an update package is obtained as input, and during the update process, original content is updated to updated content in accordance therewith.
  • an update package (or a set of update commands) may be retrieved from a storage or from a database etc.
  • an embedded package 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 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 easily becomes huge in size, and if it is required to transmit it to the updatable 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 along with reducing the device's storage consumption.
  • Another update method which storage-wise is preferable to the latter method mentioned above, requires transmitting the complete updated version in the update package and simply overwriting original content with updated content.
  • This update method may turn out to be risky and non-reliable, because if the update process fails in the middle of operating, when part of the original version is already overwritten, while only part of the updated version is written to the storage, it is appreciated that the version stored in the storage at the time of interruption may be invalid or inoperable. In this case, provided that the update package is still accessible, the update process may be restarted from the beginning. 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", and the like.
  • One way for reducing the size of 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, hence producing the updated content.
  • Deltas may be produced using the known in the art differencing algorithms (such as "GNU diff") in a na ⁇ ve manner, though such deltas tend to be rather large.
  • U.S. Patent No. 6,546,552 (“Difference extraction between two versions of data-tables containing intra-references", published 2003), which is incorporated herein by reference in its entirety, 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.
  • WIPO Publication No. WO 2004/114130 (“Method and system for updating versions of content stored in a storage device", published 2004), which is incorporated herein by reference in its entirety, discloses another system and method for generating a compact update package between an old version of content and a new version of content.
  • the system of WIPO Publication No. 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.
  • WIPO Publication No. WO 2005/003963 (“Method and system for updating versions of content stored in a storage device", published 2005), which is incorporated herein by reference in its entirety, discloses a system and method for updating versions of content stored in a storage.
  • the system of WIPO Publication No. 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 may sometimes include a delta therewith, or as another example the update package may include the entire updated version.
  • a storage can include volatile memory, i.e., volatile storage (such as Random Access Memory RAM, etc.) and/or non-volatile memory, i.e., non-volatile storage (such as a hard disk, flash memory, EPROM (Erasable Programmable Read-Only Memory) and/or EEPROM (Electrically EPROM), etc).
  • volatile memory such as Random Access Memory RAM, etc.
  • non-volatile memory i.e., non-volatile storage (such as a hard disk, flash memory, EPROM (Erasable Programmable Read-Only Memory) and/or EEPROM (Electrically EPROM), etc).
  • flash memory 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 and write them back into the block, together with the x bytes).
  • the update procedure may require many write operations to the storage including blocks, and it is appreciated that if it is desirable 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. Patent No. 6,018,747 (“Method for generating and reconstructing in-place delta files", published 2000), which is incorporated herein by reference in its entirety, discloses a method, apparatus, and article of manufacture for generating, transmitting, replicating, and rebuilding in-place reconstruct software updates to a file from a source computer to a target computer.
  • U.S. Patent 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. Patent No. 6,018,747 when a delta file attempts to read from a memory offset that has already been overwritten, 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. Patent 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, thus converting a delta file to an equivalent but larger delta file.
  • 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.
  • Another known problem in the art is reliability of the update process, or fail safe update. This problem occurs, for example, when a process of updating an original 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 being updated during the interruption may become corrupted and contain unexpected content.
  • U.S. Patent No. 6,832,373 (“System and method for updating and distributing information", published 2004), which is incorporated herein by reference in its entirety, for example, tries to provide a fail safe update. 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. 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. Patent No. 6,832,373 's inventors, may be performed more quickly than through the use of technologies existing when U.S. Patent No. 6,832,373 was filed.
  • U.S. Patent No. 6,832,373 describes using a 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 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 target block (thereby overwriting the original content of the target block).
  • variations of the same method exist, such as copying the original content of the target block into the backup block in the first phase, and in the second phase in-place updating the target block to store the updated content.
  • the two phase commit (whether the backed up content is the original content or the updated content) can use only one additional backup block, yet, it is time consuming, since every write operation requires performing two operations (for the two phases) .
  • every backup operation backs up the complete (original or updated) content of a block in the backup block, and hence if the number of blocks whose content is 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 backup block) cannot be smaller than 2 n . If there are blocks in which content is stored in more than one write operation, the number of operations that the update process is required to perform will be even larger than 2 n .
  • WIPO Publication No. WO 2007/023497 protects before updating all the original content requiring protection, using a protection buffer (also known as a backup buffer) and the delta file.
  • a protection buffer also known as a backup buffer
  • U.S. Patent Publication No. 2006/0004756 tries to cope with this problem.
  • U.S. Patent Publication No. 2006/0004756 (Method and system for in-place updating content stored in a storage device", published 2006), which is incorporated herein by reference in its entirety, describes a method and system for updating a stored version of content stored in a storage using an update package.
  • the update package that includes update commands is adapted for updating an original version of content to an updated version.
  • the updating is carried out in accordance with an update sequence.
  • the method includes determining direction of the updating.
  • the method forward-updates the stored version to the updated version in accordance with the update sequence. If the direction is indicative of roll-back, the method generates a roll-back update sequence opposite to the update sequence and rolls-back the stored version to the original version in accordance with the roll-back update sequence.
  • US2007/0255764 A1 describes a method for performing an in-service upgrade of software associated with a network processor of a packet processing system.
  • the in-service upgrade is performed in three stages, a preparation stage, an update stage and a cleanup stage.
  • the preparation stage involves preparing for the upgrade.
  • the update stage is a limited set of writes performed to switch the hardware of the network processor to the new software, which is done such that the downtime is as low as possible.
  • the cleanup stage involves freeing and reclaiming memory.
  • Embodiments of the present invention provide a method of updating an original version of content to a new version of content, in a non-volatile memory storage device the method includes: providing a non-volatile content memory storage area arranged to accommodate a full version of content; providing an auxiliary memory area; performing, while at least part of the content memory storage area is not being updated, at least one pre-update operation corresponding to at least one in-place update operation applicable, in an in-place update, on the part of the content memory storage area; storing, while at least part of the content memory storage area is not being updated, at least one result of the performed at least one pre-update operation, on the auxiliary memory area; and performing an in-place update of the at least part of the content memory storage area utilizing the at least one result stored on the auxiliary memory area.
  • Embodiments of the present invention provide a system for updating an original version of content to a new version of content, in a non-volatile memory storage device, the system includes: a non-volatile content memory storage area arranged to accommodate a full version of content; an auxiliary memory area; a pre-update module; and an in-place update module, wherein the pre-update module is arranged to: perform while at least part of the content memory storage area is not being updated, at least one pre-update operation, wherein the at least one pre-update operation corresponds with at least one in-place update operation applicable on the content memory storage area; and store at least one result of the performed at least one pre-update operation, on the auxiliary memory area, and wherein the in-place update module is arranged to perform an in-place update of the content memory storage area utilizing the at least one result stored on the auxiliary memory area.
  • Embodiments of the present invention provide a program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for updating original content stored in a non-volatile memory associated with a device to yield updated content, comprising: performing a pre-update while the device is used in preparation of a subsequent in-place update, wherein the performing a pre-update includes: determining at least one preparation result and storing the at least one determined preparation result in an auxiliary memory whose content is not updated in-place; and performing an in-place update subsequent to the pre-update, wherein the performing an in-place update includes writing updated content in place of original content in the non-volatile memory.
  • Embodiments of the present invention provide a computer program comprising computer program code means for performing a method of the invention when the program is run on a computer. According to the present invention, there is yet further provided a computer program embodied on a computer readable medium.
  • Fig. 1 is a high level schematic illustration of a system 101 for updating content in a cellular network, in accordance with one embodiment of the invention.
  • Cellular telephones 102 associated with storages 107, execute programs that enable operation of the cellular telephones and/or updating of the cellular telephones.
  • Storages, such as storages 107, are sometimes referred to also as “memories” or “memory units”. Programs for a particular cellular telephone 102 are normally stored in files in associated storage 107.
  • a storage 107 associated with a particular cellular telephone 102 can include volatile memory, i.e., volatile storage, (such as Random Access Memory RAM, etc.) and/or non-volatile memory, i.e., non-volatile storage, (such as a hard disk, flash memory, EPROM (Erasable Programmable Read-Only Memory) and/or EEPROM (Electrically EPROM), etc.).
  • volatile memory i.e., volatile storage, (such as Random Access Memory RAM, etc.) and/or non-volatile memory, i.e., non-volatile storage, (such as a hard disk, flash memory, EPROM (Erasable Programmable Read-Only Memory) and/or EEPROM (Electrically EPROM), etc.
  • volatile memory i.e., volatile storage, (such as Random Access Memory RAM, etc.) and/or non-volatile memory, i.e., non-volatile storage, (such as a hard disk, flash memory, EPROM (
  • storage 107 associated with a particular cellular telephone 102 may be coupled to the cellular telephone and therefore detachable from the cellular telephone.
  • the coupled storage may be local and/or remote to the cellular telephone.
  • some or all of storage 107 associated with a cellular telephone 102 may be inside the cellular telephone. It is noted that for simplicity of illustration and description only one storage 107 is illustrated and described per cellular telephone 102, but the reader should understand that any particular associated storage 107 may comprise one or more divisible units.
  • the plurality of units may all be detachable from associated cellular telephone 102, may all be within associated cellular telephone 102 or may be divided between unit(s) which are detachable and unit(s) which are within associated cellular telephone 102.
  • the 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 storages require update, such as text, data stored in databases, files stored in the storages, etc. Therefore, hereinafter the term “content” will be used instead of "program”.
  • the version of the program currently executing on a cellular telephone or any other content currently applicable to the cellular telephone is referred to, hereinafter, as an "old version", “old content”, “original version” "original content”, or variations thereof.
  • an intermediate version can include both updated content and original content.
  • an intermediate version can include additionally or alternatively content which has been partially transformed on the way to becoming updated content.
  • 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.
  • the update server, or the update generator includes or has access to a non-volatile memory on which the update package can be stored.
  • 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 associated with storages for storing content, and sometimes it is required to update the content stored therein.
  • PDAs Personal Digital Assistants
  • set-top boxes and other consumer electronic devices that are associated with storages for storing content, and sometimes it is required to update the content stored therein.
  • 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.
  • updatable devices or “devices” will be used hereinafter, and it should be noted that the term “updatable device” or “device” as used herein can refer to any device that is associated with a storage 107 and allows updating content stored therein.
  • update packages are generated, stored in the update server 105 and conveyed to the updatable devices (such as the cellular telephones 102) and the storages 107 associated therewith.
  • the updatable devices such as the cellular telephones 102
  • the storages 107 associated therewith it is possible to convey an update package without storing it first in an update server 105.
  • the update package is conveyed via the transmitter 106.
  • a portable storage 107 such as a compact disk or disk-on-key thus allowing an updatable device (such as the telephones 102) to access the update package by reading it therefrom.
  • the updated version is generated through an update process which consists of two sub-processes, namely a "pre-update process” or “pre-update”, performed by a "pre-updater” in the updatable device, and an "in-place update process” or “in-place update” , performed by an "updater” in the updatable device.
  • the update package may be divided into instructions designated to be executed by the pre-updater and instructions to be executed by the updater.
  • the update package may in fact comprise two or more separate packages which are prepared and transmitted separately (for example separate packages for the pre-updater and updater).
  • the pre-updater performs a pre-update, by executing some or all of the instructions in the update package, in order or out of order.
  • the pre-updater may perform a pre-update which is not based or is only partially based on instructions provided in the update package.
  • the single form of update package will be used below and should be understood to connote both embodiments with a single update package and embodiments with a plurality of update packages.
  • storage 107 and/or the updatable device (such as cellular telephone 102) will be written without reference numerals.
  • the storage associated with an updatable device includes both volatile memory and non-volatile memory.
  • the storage includes a non-volatile memory which stores updatable content (i.e., content which may be updated in place), and original content in this non-volatile memory may be updated in-place by new content during an in-place update process.
  • the non-volatile memory which is used for storing the updatable content is termed herein below "updatable content memory".
  • updatable content memory not all of the content in the updatable content memory is necessarily changed during any particular in-place update and therefore in some cases, some of the content after the completion of an in-place update may be identical to some of the content prior to the in-place update.
  • the updatable content memory is organized in blocks.
  • the updatable content memory In some cases during the in-place update process, not only is the updatable content memory written to, but also volatile memory and/or other non-volatile memory included in the storage are written to.
  • the volatile memory to which is written during the in-place update process (and during the pre-update process) is not organized in blocks, for example RAM.
  • the (optional) non-volatile memory which may in some cases be written to during the in-place update process (but which is not updatable content memory) is termed herein below “backup buffer” or “backup memory”.
  • the backup buffer may be written to at other times in addition to or instead of during the in-place update process.
  • data stored within the backup buffer enables the in-place update process to be reliable.
  • An in-place update process is termed herein "reliable", provided that the in-place update process can be resumed even subsequent to an interruption which caused volatile memory to be erased and possibly a block in storage to be corrupted. It should be appreciated that the content of this block is sometimes corrupted during the interruption and sometimes not. Yet, because it is sometimes impossible to determine or to be certain whether the content thereof is corrupted or not, the content stored in this block is considered as undependable content.
  • auxiliary memory In addition to the memories previously described, part of the memory in the storage is termed herein below "auxiliary memory".
  • the auxiliary memory is memory which is not written to during the in-place update process, and the content of the auxiliary memory is not updated in-place.
  • the auxiliary memory can include for example volatile memory (e.g., RAM, etc.) and/or non volatile memory (e.g., flash, memory extension, mass storage device, disk on key etc.).
  • Auxiliary memory can be local and/or remote.
  • a computer which is associated with volatile and/or non-volatile memory and which is coupled by wired or wireless means to the updatable device can function as a remote auxiliary memory for the updatable device.
  • the updatable device can remotely access the memory associated with the computer through any appropriate standard or proprietary protocol.
  • auxiliary is used to distinguish this memory for the reader, but should not be construed to imply that the auxiliary memory is necessarily subsidiary or otherwise inferior in nature.
  • the original intention of the auxiliary memory and the reason for inclusion thereof in the storage may have been for the usage of the user of the updatable device.
  • the auxiliary memory may include for instance the user file system.
  • the auxiliary memory is not necessarily organized in blocks, but for simplicity of description in the description below the term "block” is used also with reference to the auxiliary memory and should be understood to mean a block sized area.
  • the pre-updater takes advantage of the existence of the auxiliary memory and writes to the auxiliary memory during the pre-update process. Since a full original version of original content remains stored in updatable content memory during the entire pre-update process, even if the pre-update process is not reliable, (i.e., can not be resumed after an interruption) the in-place update process is not jeopardized.
  • the updatable content memory includes a combination of the old content and the new content during the in-place update process.
  • the updatable device may or may not be operational (i.e., all operations unrelated to the update which use content in the updatable content memory may be allowable or not all operations unrelated to the update which use content in the updatable content memory may be allowable). If the updatable device is not operational during the in-place update process, then the fact that old and new content coexist during the in-place update process typically although not necessarily does not affect operation.
  • the duration of the in-place update process and thus the duration during which the updatable device is not operational be minimized. If the updatable device is operational during the in-place update process, then in order to provide consistent operation for the duration of the in-place update process the fact that old and new content coexist during the update process needs to be addressed. Moreover if the updatable device is operational during the in-place update process, it may be preferable in some cases that the duration of the in-place update process be minimized and/or any performance penalty incurred from running the in-place update process while the device is operational be potentially minimized.
  • the pre-update process mentioned above and described in more detail below provides an approach regardless of whether the in-place update is performed while the device is operational or not.
  • the pre-update process is executed while the device is operational, prior to and in preparation of the in-place update.
  • the subsequent in-place update may be performed while the updatable device is operational or while not operational, depending on the embodiment.
  • preparation results also termed "preparing results" or the like
  • the preparation results do not overwrite the original content in the updatable content memory.
  • Preparation results may include any results of the pre-update process, and assuming not erased may later be used by the in-place update process (and/or paging process discussed further below).
  • preparation results may include an intermediate version of content (for example an intermediate version of one or more blocks), an updated version of content (for example an updated version of one or more blocks of content ), data which when protected allows one or more characteristic(s) of the in-place update (for example allows the in-place update to be reliable and/or reversible), calculations result(s) (for example required for updating one or more blocks of content, or required for computing data for a backup buffer).
  • the pre-update process in some cases allows the in-place update process to be of decreased duration. Additionally or alternatively, in some cases where the in-place update runs while the device is operational and preparation results have not been erased, the pre-update potentially reduces the performance penalty incurred from running the in-place update process while the device is operational. It should be evident that the potential reduction in performance penalty might in some cases depend on the extent of operation during the in-place update process. For example, if the updatable device is idle during the in-place update process (for example because the user is not using the updatable device and no non-update applications are running), the performance penalty may in some cases be minimal and thus the potential reduction in the performance penalty might also be minimal. In contrast, if the user is heavily using the updatable device during the in-place update process, then the performance penalty due to simultaneous in-place update and operation is in some cases potentially larger and thus the potential reduction in the performance penalty might also be larger.
  • FIG. 2 is a high level schematic illustration of an apparatus 200 for updating content, according to an embodiment of the present invention.
  • an updatable device and associated storage thereof may comprise apparatus 200.
  • apparatus 200 includes a pre-updater 210, an updater 220, an updatable content memory 230, an auxiliary memory 240, a volatile memory 250 (e.g., RAM) written to during the update process, and a non-volatile backup buffer 260.
  • a backup buffer i.e., backup memory
  • backup memory 260 may be omitted, whereas in another embodiment backup memory 260 may be subdivided into separate units for separate storage functions.
  • the functionality described with reference to a particular module may be performed additionally or alternatively by one or more of the other modules.
  • pre-updater 210 and updater 220 may be made up of any combination of software, firmware and/or hardware capable of performing the functions described and defined herein, principally the pre-update process and in-place update process respectively.
  • pre-updater 210 is configured to perform a pre-update while the updatable device is operational
  • updater 220 is configured to perform an in-place update while the updatable device is not operational.
  • pre-updater 210 and update 220 may share sub-modules which perform certain common functions.
  • updatable content memory 230 includes file system 232, and/or firmware content memory 234.
  • File system 232 for example, is read/write memory.
  • auxiliary memory 240 is illustrated in Fig. 2 as being local, although as mentioned above, in some cases some or all of auxiliary memory 240 may be remote from pre-updater 210 and updater 220.
  • auxiliary memory 240 includes volatile memory (e.g., RAM) 242, non-volatile memory (e.g., flash) 244, and/or a non-volatile memory extension 246 (for example which may be external).
  • Backup memory 260 may be used in some cases to protect data for the in-place update process.
  • backup memory 260 may protect the update package (e.g., which includes a delta or is of any other type), data which would not be available in updatable content memory 230 when needed during the in-place update process (for example because of write before read conflicts), data which allows the in-place update to be reversible (i.e., rolled back), and/or data which will allow a continuation of the update process if there is an interruption which erases volatile memory.
  • the update package may be stored in file system 232, volatile memory 250 and/or in any appropriate volatile or non-volatile memory.
  • update package memory refers to the memory where the update package is stored, regardless of the type of memory.
  • updatable device and associated storage thereof are not necessarily limited to including apparatus 200 and may include other elements which are known in the art but are not illustrated and described herein since these other elements and do not add to the understanding of the invention.
  • Fig. 3 is a high level schematic flowchart illustrating a method 300 for updating content, according to an embodiment of the present invention.
  • there may be more, less and/or different stages than illustrated in Fig. 3 the stages may be performed in a different order, and/or stages shown as sequential (or in parallel) may be performed in parallel (or sequentially).
  • method 300 or a part thereof is executed by apparatus 200.
  • stage 302 it is decided whether or not the updatable device is ready to be updated, and if the updatable device is not ready, then execution of the remainder of method 300 is deferred.
  • the device may check in stage 302 that an update package which provides instructions for the current update process has been obtained (for example received/loaded) and stored in an update package memory which is accessible to updater 220 and preferably also to pre-updater 210.
  • the update package memory may be non-volatile or volatile but it should be evident that storing the update package in a non-volatile memory is more reliable than in a volatile memory, because the update package will then still be accessible in case there is an interruption which causes volatile memory to be erased. For simplicity's sake it is assumed that the update package is stored in a non-volatile update package memory in backup memory 260.
  • the updatable device may have received the update package previously from the update server 105 and stored the package in the update package memory.
  • the update package may have been loaded for example to the update package memory by any applicable means, such as by copying it from a portable (removable) memory device (e.g., a memory card or compact disc) or from a connected external memory device or by receiving it from the Internet.
  • a portable (removable) memory device e.g., a memory card or compact disc
  • updatable device may alternatively or additionally check in stage 302, that updatable device includes enough memory to run the update process in accordance with the update package.
  • the update package includes an indication of the size of any required non-volatile backup memory
  • this required backup memory size is compared with the buffer size available in backup memory 260 of the updatable device, deferring execution of the remainder of method 300 if the size of available backup buffer 260 is not enough.
  • pre-updater 210 determines a preparation result.
  • pre-updater 210 stores the determined preparation result in auxiliary memory 240.
  • the preparation result may include any result of the pre-update process including for example, an intermediate version of content (for example an intermediate version of a block of content), an updated version of content (for example an updated version of a block of content), data which when protected allows one or more characteristic(s) of the in-place update (for example allows the in-place update to be reliable and/or reversible), a calculations result (for example which is required for updating a block of content, or required for computing data for a backup buffer), in various embodiments.
  • the storing in stage 306 is illustrated in Fig. 3 as being performed after each determination iteration of stage 304 (for example separately for each preparation result associated with an instruction in the update package). However, in some cases, a particular storing stage 306 may be performed after stage 304 has been performed a plurality of times (for example only preparation results associated with a plurality of instructions in the update package have been determined).
  • auxiliary memory 240 includes content from the last pre-update which matches original content in updatable content memory 230
  • pre-updater 210 ignores any such content in auxiliary memory 240 when deciding where to store a preparation result, and does not attempt to overwrite content which matches original content in updatable content memory 230, if existent, with a corresponding preparation result. It is possible, however, that in some cases content in auxiliary memory 240 which matches original content in updatable content memory 230 may by chance be overwritten with a corresponding preparation result.
  • the content is read by pre-updater 210 from updatable content memory 230 rather than from auxiliary memory 240.
  • the original content may be read from either memory.
  • preparation results are not necessarily stored in auxiliary memory 240 (stage 306) in the same sequence that the preparation results were computed.
  • preparation results may be stored wherever there is available space in auxiliary memory 240, where the available space is not necessarily contiguous nor necessarily static during the pre-update process (i.e., in some cases, unrelated to the pre-update process, space in auxiliary memory 240 may be occupied or freed while the pre-update process is running).
  • pre-updater 210 decides whether or not pre-updater 210 should determine another preparation result.
  • the decision of stage 308 is dependent on the availability of space in auxiliary memory 240 that can be used to store preparation results.
  • the decision is influenced by stage 306 with pre-updater 210 calculating preparation results until there is no longer available space in auxiliary memory 240 to store the preparation results.
  • the available space in auxiliary memory 240 for storing preparation results may be less than the space required to store all of the updated blocks in auxiliary memory, for instance because the actual size of the available auxiliary memory is less or because a limitation is placed on how much of the auxiliary memory can be used by pre-updater 210.
  • the decision of stage 308 is dependent on whether or not pre-updater 210 has determined the maximum number of preparation results that can be determined in the pre-update process.
  • the decision is influenced by stage 304 with pre-updater 210 determining preparation results until there are no more remaining preparation results to be determined in the pre-update process.
  • the decision is influenced by a combination of stages 304 and 306, for example with pre-updater 210 determining preparation results until the earlier of the completion of the maximum number of preparation results that can be determined in the pre-update process or the depletion of available storage space in auxiliary memory 240.
  • the decision of stage 308 is partially dependent on whether or not the user has already expressed a readiness for the in-place update or has otherwise provided an indication which restricts the pre-update (for example a user defined maximum time duration for the pre-update).
  • an indication which restricts the pre-update for example a user defined maximum time duration for the pre-update.
  • pre-updater 210 should stop determining preparation results, then no more preparation results are determined ("no" to stage 308) even if available space has not been exhausted and even if additional preparation results could have potentially been determined in the pre-update process.
  • pre-updater 210 proceeds to follow the instructions of the update package, as though pre-updater 210 were updater 220, except that the updated blocks are stored in auxiliary memory 240 (rather than in updatable content memory 230) until there is no longer available space for storing updated blocks in auxiliary memory 240.
  • the preparation results include all of the updated blocks (if there is enough space), or a subset of the updated blocks which are comprised in an updated version of the content, the subset including completely updated block(s) and/or intermediate version(s) of block(s).
  • the extent of determining preparation results may be explicitly limited, or may be unlimited.
  • pre-updater 210 may be informed via the update package of the extent that preparation results should be determined, pre-updater 210 may determine the extent without consulting the update package (where the determination may or may not be based on prior knowledge), or pre-updater 210 may determine the extent partly from the update package and partly on its own (where for the latter the determination may or may not be based on prior knowledge). In one embodiment where instead there is no explicit limitation on the extent of determining preparation results, pre-updater 210 may perform all the tasks which are required for update, with pre-updater 210 writing the preparation results (in this embodiment comprising all of the updated blocks) to auxiliary memory 240 rather than to updatable content memory 230.
  • the number of updated blocks to be generated by pre-updater 210 may be limited.
  • the blocks which are updated by pre-updater 210 may be sequential or not necessarily sequential, depending on the embodiment.
  • the preparation results include a subset of the updated blocks which are comprised in an updated version of the content.
  • the number of updated blocks may be limited by limiting the number of instructions in the update package to be performed by pre-updater 210
  • the update package may in some cases designate the number of instructions (and optionally identify the instructions), for example indicating that pre-updater 210 perform only i out of the j instructions included in the update package for generating updated blocks of content, where i ⁇ j , and the i instructions relate to k out of the l updated blocks in the updated version ( k ⁇ l ).
  • the identity of the i instructions may in some cases be provided in the update package or may otherwise be known to pre-updater 210, for example the first i listed instructions, or the i instructions so marked in the update package. Still continuing with these cases, pre-updater 210 may know that during a pre-update, pre-updater 210 is limited to performing the first i listed instructions, relating to k blocks. In other cases of this embodiment instead of the update package identifying the i . instructions or the identity of the i . instructions being otherwise known to pre-updater 210, the selection of which i instructions to perform (and possibly the selection of the number of instructions to be performed) may be left to the discretion of pre-updater 210.
  • the selection may be random or based on criteria such as for example, the positions of the corresponding k updated blocks within the l blocks and/or the content of the corresponding k updated blocks.
  • the instructions selected may be sequential within the update package or not necessarily sequential.
  • pre-updater 210 may perform only part (i.e., a subset) of the instructions in the update package associated with each of a plurality of blocks to be updated or may perform only part (i.e., a subset) of the instructions in the update package associated with each of the blocks to be updated.
  • the update package may specify the number and/or which instructions to perform for certain block(s) or pre-updater 210 may know the number and/or which instructions to perform for certain block(s) during a pre-update.
  • pre-updater 210 may determine the number and/or select which instructions to perform for certain block(s).
  • the selection may be random or based on criteria such as the position and/or content of the instructions.
  • the instructions selected may be sequential within the update package or not necessarily sequential.
  • preparation results may include an intermediate version of one or more blocks and/or calculation results required for updating one or more blocks.
  • pre-updater may perform some or all of the "insert", “delete” and “copy” commands but not the "replace” commands, may perform the first s commands related to each block or to each of a subset of blocks, or may perform any subset of instructions.
  • pre-updater 210 may additionally or alternatively perform decompression of some or all of the original compressed blocks.
  • the update package may specify that decompression is desired, the number of blocks to decompress, and/or which blocks to decompress, or pre-updater 210 may know that decompression is desired, the number of blocks to decompress, and/or which blocks to decompress, during a pre-update.
  • pre-updater 210 may determine that decompression is desired, the number of blocks to decompress and/or which blocks to decompress, where the selection of the blocks to decompress may be random or based on criteria such as the position of the blocks within the original version and/or content of the blocks and/or where the blocks may be decompressed in the order that the blocks are located in updatable content memory 230 or out of order.
  • the update package may specify that decompression is desired or pre-updater 210 may otherwise know that decompression is desired.
  • preparations results include an intermediate version of one or more blocks, where the intermediate version includes one or more decompressed blocks.
  • pre-updater 210 may determine fully or partially data which when protected, allows one or more characteristic(s) of the in-place update.
  • pre-updater 210 is informed by the update package or otherwise knows that the in-place update should have certain characteristic(s) and therefore that certain data should be fully or partially determined during a pre-update. For instance, assume an embodiment where the in-place update process has the characteristic of being a reversible process as described in the aforementioned U.S. Publication No. 2006/004756 to Peleg et al , which is hereby incorporated by reference herein.
  • pre-updater 210 may determine and store in auxiliary memory 240 any original content which will be deleted in the in-place update process, so that if the in-place update process is rolled back, the deleted original content can be reinserted.
  • the in-place update process additionally or alternatively has the characteristic of being reliable as described in U.S. Application No. 11/997,134 to Meller et al , which is hereby incorporated by reference herein.
  • protected error recovery result(s) such as a XOR result(s)
  • pre-updater 210 can partially or fully calculate such error recovery result(s) and store such result(s) in auxiliary memory 240.
  • preparation results therefore include data which when protected allows one or more characteristic(s) of an in-place update, and/or include calculation results towards determining such data.
  • the determining of preparation results are completed at the earlier of the space limitation being reached, the extent limitation being reached, or the user expressing a readiness for the in-place update /otherwise providing an indication which restricts the pre-update.
  • Stages 302 through 308 are performed while the updatable device is operational (i.e., while all operations unrelated to the update which use content in the updatable content memory are allowable).
  • preparation results written to auxiliary memory 240 by pre-updater 210 are not protected from the user or non-update applications operating in the updatable device. Therefore in this embodiment, some or all of the preparation results may be erased prior to being used in the in-place update process.
  • preparation results may be written to volatile auxiliary memory 242, and therefore may be erased in case of an interruption which causes volatile memory to be erased or for certain platforms may be corrupted during the reset of stage 312.
  • preparation results written to auxiliary memory 240 by pre-updater 210 are protected from the user or non-update applications functioning in the updatable device.
  • preparation results are prevented from being erased prior to usage thereof in the in-place update process.
  • the in-place updating of content occurs while the updatable device is not operational (i.e., while not all operations unrelated to the update which use content in the updatable content memory are allowable). Therefore, assuming that the user has not previously expressed a readiness for the in-place update during the pre-update nor otherwise provided an indication which restricts the pre-update (see above), in stage 310, the updatable device determines whether the user is ready for the in-place update. For example in one embodiment, once it has been decided in stage 308 that no other preparation result should be determined, the user may be asked via a user interface of the updatable device whether or not the user is currently ready to update the updatable device.
  • the updatable device remains operational, resetting is deferred, and the updatable device may repeat the question at a later time. It is assumed in this embodiment that either the first time the user is asked or during a subsequent time that the user is asked, the user will agree to a device reset in order to update the device. However, in one embodiment it is possible that the user does not wish to update the device and wishes to retain original content, and that stage 312 is therefore deferred indefinitely.
  • stage 310 it is assumed that stage 310 is executed, because the user might not like the updatable device to stop being operational at an inconvenient time.
  • the updatable device may omit stage 310 and proceed directly to resetting stage 312 after a "no" in stage 308, with or without prior notice to the user that the device will reset.
  • stage 310 may be omitted and stage 312 directly performed.
  • the updatable device may determine when the device should be reset without first consulting the user, and the resetting may occur with or without prior notice to the user. Continuing with the example in some cases, the updatable device may reset during the next recharging of a non-empty battery of the updatable device, and not necessarily soon after a "no" to stage 308.
  • stage 312 the updatable device is reset and the in-place update process begins.
  • updater 220 copies certain preparation result(s) from auxiliary memory 240 to backup buffer 260, uses certain preparation result(s) to compute data for backup buffer 260, or computes data for backup buffer 260 not based on preparation results.
  • preparation result(s) comprising data which when protected allows one or more characteristic(s) of the in-place update may be copied to backup buffer 260.
  • preparation result(s) which comprise calculation result(s) may be used to compute data for storage in backup buffer 260, where this data when protected allows one or more characteristic(s) of the in-place update.
  • any type of preparation result(s) may be copied in stage 313 by updater 220 from auxiliary memory 240 to backup buffer 260 or used to compute data for storage in backup buffer 260 .
  • stage 313 may be omitted for any of a number of reasons. For example, stage 313 may be omitted because no relevant preparation result(s) are currently stored in auxiliary memory 260. As another example, stage 313 may be omitted because no backup buffer 260 exists. As another example, stage 313 may be omitted because the filling in of the backup buffer 260 occurs at a later stage of the in-place update.
  • preparation result(s) may be copied later in method 300, for example copying from auxiliary memory 240 to backup memory 260 data in an original block which allows rollback and/or other preparation result(s) relating to an original block immediately prior to overwriting the original block in stage 326.
  • data for backup memory 260 may be computed based on preparation result(s) or not based on preparation result(s) later in method 300 for example, immediately prior to overwriting an original corresponding block in stage 326.
  • updater 220 begins updating the first block to be updated.
  • the first block to be updated may be dynamically selected, or may be the first in an update sequence specified in the update package.
  • the update sequence specified in the update package may have been decided randomly, may have been based on the order of the block in updatable content memory 230, may have been selected in order to limit the potential number of write before read conflicts, or for any other reason.
  • U.S. Patent No. 6,018,747 to Bums et al. and U.S. Publication No. 20070050330 to Meller et al describe determination of update sequences in update packages, and are hereby incorporated by reference herein.
  • the dynamic selection may be random, may be based on the order of the block in updatable content memory, may be made in order to limit the potential number of write before read conflicts, or may be made for any other reason.
  • updater 220 determines if the updated version of the block exists in auxiliary memory 240 . If the updated version is in auxiliary memory. (yes to stage 316), then in stage 318, updater 220 reads the updated block from auxiliary memory 240, and in stage 326 writes the updated block to updatable content memory 230 in place of the original block. Stage 318 and 326 may therefore be considered together to constitute a copy action.
  • updater 220 determines if any other type(s) of preparation result(s) related to the block to be updated exists in auxiliary memory 240 . For example in stage 320, updater 220 may check if auxiliary memory 240 contains an intermediate version of the block, calculation result(s), and/or any other type(s) of preparation result(s) relating to the block (other than the updated version of the block which was previously checked for in stage 316). If related preparation result(s) (other than the updated version of the block) exists in auxiliary memory 240, then in stage 322, updater 220 reads the preparation result(s) from auxiliary memory 240.
  • updater 220 may or may not also need to read the original block from updatable content memory 230.
  • updater 220 determines in volatile memory 250 the updated version of the block based on the related preparation result(s), and possibly also based on the original block and/or data in backup buffer 260.
  • the updated version of the block is written in place to updatable content memory 230 .
  • stage 320 it is determined that there is no preparation result in auxiliary memory 240 corresponding to the block, either because pre-updater 210 did not store such a result, or because such a result was stored but later erased.
  • stage 325 is performed with updater 220 generating in volatile memory 250 the updated block without reading any preparation result in auxiliary memory 240.
  • updater 220 first reads the original block from updatable content memory 230 prior to generating the updated block.
  • the updated block may be generated using any suitable updating procedure, for example based on any of the original block and/or data in backup buffer 260.
  • the updated block may be generated as described in the aforementioned U.S. Patent No. 6,018,747 , U.S. Publication No. 20070050330 , U.S. Publication No. 2006/004756 , and/or U.S. Application No. 11/997,134 .
  • the updated block is written in place to updatable content memory 240.
  • the invention does not limit the procedure(s) for performing stage 326.
  • any suitable procedure(s) may be performed.
  • the aforementioned U.S. Patent No. 6,018,747 , U.S. Publication No. 20070050330 , U.S. Publication No. 2006/004756 , and U.S. Application No. 11/997,134 describe examples of various procedure(s).
  • data may be stored into non-volatile back-up memory 260.
  • Examples of what may be stored in backup memory 260 prior to the overwriting an original block include inter-alia: the original or updated block (at least until the updated block has been safely written to updatable content memory 230), any part of the original block which is needed for later updating of other block(s) (thereby preventing write before read conflicts), data which allows an updated block to be rolled back to original content, and/or data which will allow a continuation of the in-place update process if there is an interruption which erases volatile memory.
  • the storage in backup memory 260 may occur immediately prior to the overwriting of stage 326 of the original block (or of the first of a plurality of related original blocks) and/or may occur earlier in method 300, for example at stage 313 as discussed above.
  • non-volatile backup memory 260 may increase reliability in case of interruption, may allow reversibility of the in-place update process, and/or may prevent write before read conflicts, in other embodiments, other techniques may be used additionally or alternatively.
  • other techniques may include inter-alia: storing data in the update package which itself is stored in a (non-volatile) update package memory, protecting an updated block in non-volatile auxiliary memory 244/246 at least until safely written in updatable content memory 230 during the in-place update process, and/or protecting preparation result(s) in non-volatile auxiliary memory 244/246 at least until no longer needed in the in-place update process.
  • Examples of data which may be stored in the update package include inter-alia: add commands which were converted from copy commands, and data which will allow a continuation of the in-place update process if there is an interruption which erases volatile memory. It should be understood that storage in non-volatile backup memory and/or usage of the other described techniques in not required by all embodiments of the invention.
  • stage 328 a decision is made whether or not there are more blocks to be updated. If there is at least one other block to be updated (yes to stage 328), then another block is selected to be updated in stage 330. Each time, the next block may be dynamically selected or may be the next block in an update sequence specified in the update package. Stages 316 to 326 are iterated for each of the blocks to be updated.
  • the in-place update may be rolled back at any iteration of stage 328 instead of proceeding to update the next block to be updated, for example upon request of the user.
  • updater 220 rolls back the updated content starting with the last updated block, undoing each of the commands in the update package in the reverse order and overwriting the updated block with the original content.
  • Updater 220 then proceeds to roll back the updated content for the second to last updated block (in stage 330), continuing until all the updated blocks have been replaced with original content. For example the rollback can proceed as described in the aforementioned U.S. Publication No. 2006/0004756 .
  • updater 220 may in some cases use stored preparation result(s) comprising data which is required for the rollback, either reading such preparation result(s) from auxiliary memory 240 or from backup memory 260 (assuming such preparation result(s) were copied there from auxiliary memory 240 in stage 313 or at any stage of the in-place update), depending on the location thereof.
  • stage 322 update 220 may read the preparation result(s) from auxiliary memory 240, and in stage 324 updater 220 may determine in volatile memory 250 the original (rolled back) version of that block based on the preparation result(s) and possibly also based on the updated version of the block and/or data in backup buffer 260.
  • stage 325 updater 220 may determine the original (rolled back) version of that block based on the copied data in backup buffer 260 and possibly also based on the updated version of the block and/or other data in backup buffer 260.
  • stage 326 of this embodiment the updated block in updatable content memory 230 is overwritten by the original (rolled back) version of the block.
  • the rollback iterates for all updated blocks, until there are no more updated blocks to rollback to original content (i.e., until the answer is "no" in stage 328).
  • updater 220 may in some cases have determined and stored in backup memory 260 at least some of the data for the rollback on its own, for example at stage 313 or at any time prior to overwriting the corresponding original block.
  • updater 220 determines which preparation result(s) (updated block or otherwise) exist(s) in auxiliary memory 240 are now presented.
  • the update package fully specifies the extent of determining preparation results by pre-updater 210
  • the specifications (provided for pre-updater 210) are checked in stage 313, 316 or 320 by updater 220 in order to determine which preparation result(s) (updated block or otherwise) exist(s) in auxiliary memory 240.
  • both pre-updater 210 and updater 220 know the extent that pre-updater 210 should determine preparation results during the current pre-update.
  • auxiliary memory where preparation results are stored is non-volatile (or is volatile but no interruption) has occurred which erased volatile memory)
  • preparation results are protected, and the pre-update was not terminated in stage 308 due to the readiness of a user for the in-place update, due to any other user expressed indication which restricts the pre-update, or due to auxiliary memory space limitations
  • specification in the update package that pre-updater 210 perform a particular task or knowledge that pre-updater 210 should have performed a particular task during the current pre-update may provide a clear indication to updater 220 that a resulting preparation result is in auxiliary memory 240, whereas omission of such a specification or knowledge that pre-updater 210 should not have performed a particular task during the current pre-update may provide a clear indication that no such preparation result is in auxiliary memory 240 .
  • auxiliary memory is volatile and an interruption has occurred which erased volatile memory, preparation results are not protected, and/or the pre-update was terminated in stage 308 due to readiness of the user for the in-place update, due to any other user expressed indication which restricts the pre-update, or due to space limitations, then non-specification in the update package that pre-updater 210 perform a particular task or knowledge that pre-updater 210 should not have performed a particular task during the current pre-update may provide a clear indication that no resulting preparation result is in auxiliary memory 240.
  • pre-updater 210 performs a particular task or knowledge that pre-updater 210 should have performed a particular task during the current pre-update would not provide a clear indication (since the resulting preparation result may not have had a chance to be saved or may have been saved but since erased), and therefore updater 220 would need to find out whether the resulting preparation result is in auxiliary memory 240 or not.
  • updater 220 would also need to find out whether the resulting preparation result is in auxiliary memory 240 or not.
  • updater 220 is informed whether or not pre-updater 210 stored a resulting preparation result in auxiliary memory 240 by consulting in stage 313, 316 or 320 a "trace" which pre-updater 210 created.
  • the trace indicates which preparation results (updated blocks or otherwise) were determined and stored by pre-updater 210 in the current pre-update.
  • the trace can be created in the update package and accessed by updater 220 or can be created elsewhere and made accessible to updater 220. In one of these embodiments, the trace is created and/or made accessible to updater 220 only if knowledge or specification/non-specification in the update package is not sufficient for updater 220 to determine whether the resulting preparation result is or is not in auxiliary memory 240.
  • the trace is routinely created and made accessible to updater 220. If the auxiliary memory where preparation results are stored is non-volatile (or is volatile but no interruption has occurred which erased volatile memory) and preparation results are protected, then the listing or non-listing of a preparation result in the trace may provide a clear indication that a preparation result is (or is not) in auxiliary memory 240. If on the other hand, auxiliary memory is volatile and an interruption has occurred which erased volatile memory, and/or if preparation results are not protected, then non-listing in the trace may provide a clear indication that a preparation result is not in auxiliary memory 240. However in this case, listing in the trace would not provide a clear indication (since the resulting preparation result may have since been erased).
  • updater 220 determines whether a preparation result (updated block or otherwise) from the current pre-update is in auxiliary memory 240 in stage 313, 316 or 320 by checking with the memory management of auxiliary memory 240 and/or by checking signatures in auxiliary memory 240.
  • Updater 220 may check with the memory management and/or check signatures for example because knowledge of the tasks of pre-updater 210, checking specifications in the update package and/or checking the trace did not provide a clear indication, because knowledge, specifications in the update package and/or the trace do not exist, because checking with the memory management/checking signatures is more efficient, and/or for any other reason.
  • updater 220 is aware of which preparation result(s) exist(s) in auxiliary memory 240, based on any of the embodiments described above, if computation based on preparation result(s) of the backup buffer in stage 313 or of an updated or rolled back block in stage 324 is required, updater 220 can perform the computation. For example, if the update package specifies the extent of the pre-update, updater 220 knows the extent of the pre-update, or the trace indicates the extent of the pre-update, updater 220 may execute the required tasks to compute the backup buffer in stage 313 or an updated or rolled back block in stage 324. Depending on the embodiment, the update package may comprise instructions for performing the required tasks, or the required tasks may otherwise be known to updater 220.
  • any auxiliary memory 240 which was used to store preparation results and/or part or all of backup buffer 260 may be freed, for example by the memory management designating the space as available.
  • stage 350 may be fully or partially omitted, for example omitting the freeing of memory in auxiliary memory 240 if there was anyhow no protection of stored preparation result(s).
  • the updatable device becomes operational.
  • the updated version of content (or conversely the original version of content if a rollback occurred) in updatable content memory 230 may be used.
  • Method 300 then ends.
  • the period during which the in-place update process is taking place and the device is not operational is typically although not necessarily reduced due to the pre-update process, compared to a method which does not include a pre-update.
  • Fig. 4 is a high level schematic illustration of an apparatus 400 for updating content, according to another embodiment of the present invention.
  • an updatable device and associated storage thereof may comprise apparatus 400.
  • apparatus 400 includes a pre-updater 210, an updater 420, updatable content memory 230, auxiliary memory 240, volatile memory 250, backup buffer 260, and a rendering module 470.
  • backup buffer 260 may be omitted, whereas in another embodiment backup memory 260 may be subdivided into separate units for separate storage functions.
  • functionality described with reference to a particular module may be performed additionally or alternatively by one or more of the other modules.
  • Modules in apparatus 400 which are similar to modules described with reference to apparatus 200 are labeled with the same reference number and the reader is referred for more details on these modules to the description above with respect to Fig. 2 .
  • pre-updater 210 and updater 420 are configured to perform a pre-update and in-place update respectively while the updatable device is operational.
  • Updater 420 is labeled with a different number than updater 220 of Fig. 2 because updater 420 performs the in-place update while the updatable device is operational in contrast to updater 220.
  • updater 220 and updater 420 may or may not be identical.
  • Updater 420 may be made up of any combination of software, firmware and/or hardware capable of performing the functions described and defined herein, principally the in-place update process.
  • pre-updater 210 and updater 420 may share sub-modules which perform certain common functions.
  • Rendering module 470 may be made up of any combination of software, firmware and/or hardware capable of performing the functions described and defined herein.
  • rendering module 470 includes an on demand paging module 472 and a virtualization module 476.
  • Each of on-demand paging module 472 and virtualization module 476 may be made up of any combination of software, firmware and/or hardware capable of performing the functions described and defined herein.
  • virtualization module 476 may share sub-modules which perform certain common functions with pre-updater 210 and/or with updater 420.
  • rendering module 470 is included in the operating system, but this is not necessarily the case.
  • rendering module 470 may be included in another application, may be stand-alone, etc.
  • rendering module 470 may include less, more and/or different modules than illustrated in Fig. 4 .
  • the functionality described with reference to a particular module of rendering module 470 may be performed additionally or alternatively by one or more other modules.
  • some functionality ascribed to virtualization module 476 in the description below may be performed by paging module 472 in another embodiment, or vice versa.
  • on demand paging module 472 when an attempt is made to access a page by an application unrelated to the update process, or by a user, on demand paging module 472 provides the page to the application or to the user.
  • paging module 472 may provide the page by loading the page into volatile memory 250, by providing the address of the page, or by any other manner as is known in the art.
  • each page whose access is attempted is a block of content in updatable content memory 230.
  • the block whose use is attempted is termed herein below "requested block”.
  • the application (unrelated to the update process) or user which is attempting to access the requested block is termed herein below "requester".
  • virtualization module 476 supplies the requested block to paging module 472.
  • virtualization module 476 may supply an updated version of the block or the original version of the requested block to on-demand paging module 472.
  • Paging module 472 then provides the block supplied by virtualization module 476 to the requestor.
  • updatable device and associated storage thereof are not necessarily limited to including apparatus 400 and may include other elements which are known in the art but are not illustrated and described herein since these other elements and do not add to the understanding of the invention.
  • Fig. 5 is a high level flowchart illustrating a method 500 for updating content, according to an embodiment of the present invention.
  • there may be more, less and/or different stages than illustrated in Fig. 5 the stages may be performed in a different order, and/or stages shown as sequential (or in parallel) may be performed in parallel (or sequentially).
  • method 500 or a part thereof is executed by apparatus 400.
  • Stages in method 500 which are similar to stages described with reference to method 300 are labeled with the same reference number and the reader is referred for more details on these stages to the description above with respect to Fig. 3 .
  • stage 302 it is decided whether or not the updatable device is ready to be updated, and if the updatable device is not ready, then execution of the remainder of method 300 is deferred, as described above. Assuming that the updatable device is ready to be updated, pre-updater 210 performs stages 304 to 308 as described above. However, since method 500 is performed while the device is operational, in some embodiments, it may be less likely that the user would request that the in-place update process begin or otherwise provide an indication that the pre-update be restricted (for example by specifying a maximum time duration for the pre-update) than in method 300.
  • the user may request that the in-place update begin or otherwise indicate a restriction on the pre-update, and in these embodiments the decision in stage 308 of method 500 may in some cases be at least partly dependent on whether or not the user has already expressed a readiness for the in-place update, or otherwise indicated a restriction on the pre-update.
  • Method 500 is performed while the device is operational, and therefore once the pre-update process has been completed by pre-updater 210 (no to stage 308), the in-place update process performed by updater 420 may begin.
  • a rendering process is performed by rendering module 470.
  • each function in the rendering process is ascribed to a particular module in rendering module 470, in other embodiments a specific function ascribed to a particular module may be additionally or alternatively performed by a different module of rendering module 470.
  • some functions ascribed to virtualization module 476 in the description below may be performed by paging module 472 in other embodiments, or vice versa.
  • on-demand paging module 472 may work conventionally, reading any requested (original) block from updatable content memory 230 (without requiring the assistance of virtualization module 476) and providing the requested block to the requester.
  • virtualization module 476 may read any original requested block from updatable content memory 230, supply the requested block to on demand paging module 472, and on demand paging module 472 in turn may provide the supplied block to the requester.
  • updatable content memory 230 there is a combination of old content and new content in updatable content memory 230. Because the device is operational during the in-place update process of method 500, an operation unrelated to the update can use content from updatable content memory 230 (i.e., content can be requested by a requestor). It should be evident that it would be preferable that content provided by on-demand paging module 472 to the requester be consistent (i.e., all provided content either be updated content or original content, where in some cases the two may be identical), and therefore not necessarily in the format currently stored in updatable content memory 230 (which could result in some provided content being original content and some being updated content).
  • virtualization module 470 may need to update the content of requested blocks which have not yet been updated in updatable content memory 230 but are supposed to be updated in-place, or may need to reverse (i.e., roll back) the content of requested blocks which have already been updated in updatable content memory 230 back to the original content.
  • pre-updater 210 in auxiliary memory 240 can in some cases potentially reduce the workload of virtualization module 476 in updating or reversing content
  • the pre-update process can therefore in these cases potentially reduce the performance penalty incurred due to the simultaneous operation of virtualization module 476 and in-place updater 420.
  • not all possible preparation results which may be stored by pre-updater 210 in auxiliary memory 240 are necessarily useful for virtualization module 476 in updating or reversing content and therefore not all stored preparation results would necessarily reduce the workload of virtualization module 476 (nor the potential performance penalty).
  • preparation results which may in one embodiment not be used by a particular virtualization module 476 which updates content (rather than reverses content) includes data which allows the update process to be rolled back (i.e., reversed).
  • preparation results which may in one embodiment not be used by virtualization module 476 includes data which is backed up for reliability purposes or calculation results towards computing such data.
  • the duration of the in-place update process may in some cases be reduced. If the duration of the in-place update process is reduced, it follows that there is a reduction in the time duration during which there is a performance penalty due to simultaneous operation of in-place updater 420 and virtualization module 476 (and/or simultaneous operation of in-place updater 420 and any other non-update device module).
  • stages 313 to 330 are performed as described above, however by updater 420 rather than updater 220.
  • the updatable device determines if the user is ready for a reset of the device. If the user is ready, then the device is reset in stage 558 for the updated version of content, or for the original version of content if the in-place update process was rolled back. It is noted that when the device is reset in stage 558, the rendering process also terminates (yes to stage 586) as will be described below. If the user is not ready (no to stage 554), resetting is deferred. For example in one embodiment, the user may be told via the user interface of the updatable device that the device has been updated or rolled back to original content but that the device has to be reset, and permission is sought to reset the device.
  • the updatable device remains operational, resetting is deferred, and the updatable device may repeat the question at a later time. It is assumed that either the first time the user is asked or during a subsequent time that the user is asked, the user will agree to reset the device, especially considering the relatively short period during which the device is being reset and is non-operational.
  • stage 554 it is assumed that stage 554 is executed, because the user might not like the updatable device to stop being operational at an inconvenient time.
  • the updatable device may omit stage 554 and reset the device after a "no" to stage 328, with or without first notifying the user.
  • the updatable device may determine when the device should be reset without first consulting the user, and the reset can occur with or without prior notice to the user.
  • the updatable device may be reset for example during the next recharging of a non-empty battery of the updatable device.
  • any auxiliary memory 240 which was used to store preparation results and/or part or all of backup buffer 260 may be freed, for example by the memory management designating the space as available.
  • stage 556 may be partially or fully omitted, for example omitting the freeing of memory in auxiliary memory 240 if there was anyhow no protection of stored preparation result(s).
  • a rendering process is performed by rendering module 470, beginning with stage 564.
  • on demand paging module 472 determines whether or not a block has been requested. If no block has been requested (no to stage 564), on demand paging module 472 waits until a block will be requested. If a block has been requested (yes to stage 564) then in stage 566, virtualization module 476 determines whether the requested block in updatable content memory 230 includes original content or updated content. As mentioned above, in some cases, the content of a block in the updated version may be identical to the original content of that block in the original version.
  • virtualization module 476 has access to the update package (for example which may be stored in backup memory 260), and virtualization module 476 is aware of the last block updated or rolled back in updatable content memory 230 and whether or not the in-place update process has been rolled back.
  • virtualization module 476 can check a direction indicator as disclosed in U.S. Publication No. 2006/0004756 to determine whether or not the in-place update process has been rolled back.
  • the memory management can identify the last block that was updated or rolled back and virtualization module 476 can consult the memory management in stage 566 in order to determine the last block updated or rolled back.
  • virtualization module 476 can check the update sequence in the update package to find out whether or not the requested block is in the update sequence and therefore scheduled or not scheduled to be updated in the update process, and if scheduled to be updated whether the requested block is earlier or later in the update sequence than the last updated or rolled back block in updatable content memory 230. In this embodiment, virtualization module 476 thereby knows if the requested block has original content which does not need to be updated and will remain the same in the updated version (because the block is not in the update sequence), or if the requested block which is in the update sequence has original or updated content in updatable content memory 230.
  • any block later in the update sequence than the last updated or reversed block has original content and any block earlier in the updated sequence has updated content.
  • updater 420 selects blocks based on an update sequence specified in the update package or in another embodiment where updater 420 selects blocks dynamically
  • updated and/or original blocks in updatable content memory 230 may be signed by updater 420.
  • virtualization module 476 can distinguish between updated content blocks and original content blocks in updatable content memory 230 or between differently signed updated content blocks and original content blocks in updatable content memory 230.
  • updater 420 may keep a list of updated blocks with the list being accessible to virtualization module 476. Therefore, in these embodiments, virtualization module 476 can consult the list, aware that a requested block if on the list has been updated and if not on the list, has not been updated or has had content reversed back to original content.
  • virtualization module 476 can determine that a block which includes original content is not scheduled to be updated in the update process (and therefore will remain the same in the updated version) by verifying that the update package does not include any update commands regarding that block.
  • virtualization module 476 reads the requested block from updatable content memory 230.
  • virtualization module 476 supplies the requested block to on demand paging module 472, and on demand paging module 472 in turn provides the supplied block to the requester.
  • virtualization module 476 reads the original requested block from updatable content memory 230 in stage 568.
  • stage 584 virtualization module 476 then supplies the original block to on demand paging module 472, and on demand paging module 472 in turn provides the supplied block to the requester.
  • stages 566, 568, and 584 may instead be performed by paging module 472.
  • virtualization module 476 determines whether or not the updated block is in auxiliary memory 240. If the updated block is in auxiliary memory (yes to stage 572), then in stage 574 virtualization module 476 reads the updated block from auxiliary memory 240. In stage 584 virtualization module 476 supplies the updated block to on demand paging module 472, and on demand paging module 472 in turn provides the supplied block to the requester. In one embodiment, stages 566, 572, 574, and 584 may instead be performed by paging module 472.
  • virtualization module 476 determines if any other type(s) of preparation result(s) related to the block to be updated exists in auxiliary memory 240. For example, virtualization module 476 may check if auxiliary memory 240 contains an intermediate version of the block, calculation result(s), and/or any other type(s) of preparation result(s) related to the block (other than the updated version of the block which was previously checked for in stage 572).
  • virtualization module 476 reads the preparation result from auxiliary memory 240.
  • the update package includes a delta
  • virtualization module 476 may or may not also need to read the original block from updatable content memory 230.
  • virtualization module 476 determines in volatile memory 250 the updated block based on the related preparation result(s) and possibly also based on the original block and/or data in backup buffer 260.
  • virtualization module 476 supplies the updated block to on demand paging module 472, and on demand paging module 472 in turn provides the supplied block to the requester.
  • virtualization module 476 determines if preparation result(s) comprising data required for rolling back the block to original content exists in auxiliary memory 240. If rollback data exists in auxiliary memory 240, then in stage 578 virtualization module 476 reads the rollback data from auxiliary memory 240. In an embodiment where the update package includes a delta, then depending on the nature of the rollback data, virtualization module 476 may or may not also need to read the updated block from updatable content memory 230.
  • virtualization module 476 determines in volatile memory 250 the original version of the block based on the rollback data and possibly based also on the updated block and/or data in backup buffer 260. In stage 584, virtualization module 476 supplies the original block to on demand paging module 472, and on demand paging module 472 in turn provides the supplied block to the requester. In one embodiment, stages 566, 572, 576, 578, 580, and 584 may instead be performed by paging module 472.
  • both pre-updater 210 and virtualization module 476 know the extent that pre-updater 210 should determine preparation results during the current pre-update. If the auxiliary memory where preparation results are stored is non-volatile (or is volatile but no interruption has occurred which erased volatile memory), preparation results are protected, and the pre-update was not terminated in stage 308 due to the readiness of a user for the in-place update, due to any other user expressed indication which restricted the pre-update, or due to auxiliary memory space limitations, then specification in the update package that pre-updater 210 perform a particular task or knowledge that pre-updater 210 should have performed a particular task during the current pre-update may provide a clear indication to virtualization module 476 that a resulting preparation result is in auxiliary memory 240, whereas omission of such a specification or knowledge that pre-updater 210 should not have performed a particular task during the current pre-update may provide a clear indication that no such preparation result is in auxiliary memory
  • auxiliary memory is volatile and an interruption has occurred which erased volatile memory, preparation results are not protected, and/or the pre-update was terminated in stage 308 due to the readiness of the user for the in-place update, due to any other user expressed indication which restricted the pre-update, or due to space limitations, then non-specification in the update package or knowledge that pre-updater 210 should not have performed a particular task may provide a clear indication that a preparation result is not in auxiliary memory 240.
  • pre-updater 210 performs a particular task, or knowledge that pre-updater 210 should have performed a particular task during the current pre-update would not provide a clear indication (since the resulting preparation result may not have had a chance to be saved or may have been saved but since erased) and therefore virtualization module 476 would need to find out whether the resulting preparation result is in auxiliary memory 240 or not.
  • the update package does not fully specify the extent of determining preparation results for pre-updater 210 and pre-updater 210/ virtualization module 476 do not know the extent which pre-updater 210 is supposed to determine preparation results, for example with pre-updater 210 deciding on the extent of determining preparation results independently or partly based on specifications in the update package.
  • virtualization module 476 would also need to find out whether the resulting preparation result is in auxiliary memory 240 or not.
  • virtualization module 476 is informed whether or not pre-updater 210 stored a resulting preparation result in auxiliary memory 240 by consulting in stage 572 or 576 a "trace" which pre-updater 210 created.
  • the trace indicates which preparation results (updated blocks or otherwise) were determined and stored by pre-updater 210 in the current pre-update.
  • the trace can be created in the update package and accessed by virtualization module 476 or can be created elsewhere and made accessible to virtualization module 476. In one of these embodiments, the trace is created and/or made accessible to virtualization module 476 only if knowledge or specification/non-specification in the update package is not sufficient for virtualization module 476 to determine whether the resulting preparation result is or is not in auxiliary memory 240.
  • the trace is routinely created and made accessible to virtualization module 476. If the auxiliary memory where preparation results are stored is non-volatile (or is volatile but no interruption has occurred which erased volatile memory) and preparation results are protected, then the listing or non-listing of a preparation result in the trace may provide a clear indication that a preparation result is (or is not) in auxiliary memory 240 . If on the other hand, auxiliary memory is volatile and an interruption has occurred which erased volatile memory and/or if preparation results are not protected, then non-listing in the trace may provide a clear indication that a preparation result is not in auxiliary memory 240. However, in this case, listing in the trace would not provide a clear indication (since the resulting preparation result may have since been erased).
  • virtualization module 476 determines whether a preparation result (updated block or otherwise) from the current pre-update is in auxiliary memory 240 in stage 572 or 576 by checking with the memory management of auxiliary memory 240 and/or by checking signatures in auxiliary memory 240. Virtualization module 476 may check with the memory management and/or check signatures for example because knowledge of the tasks of pre-updater 210, checking specifications in the update package and/or checking the trace did not provide a clear indication, because knowledge, specifications in the update package and/or the trace do not exist, because checking with the memory management/checking signatures is more efficient, and/or for any other reason.
  • virtualization module 476 is aware of which preparation result(s) exist(s) in auxiliary memory 240, based on any of the embodiments described above, if computation based on preparation result(s) of an updated block or rolled back block is required, virtualization module 476 can perform the computation. For example, if the update package specifies the extent of the pre-update, virtualization module 476 knows the extent of the pre-update, or the trace indicates the extent of the pre-update, virtualization module 476 may execute the tasks required to compute an updated block or rolled back block based on the preparation result(s). Depending on the embodiment, the update package may comprise instructions for performing the required tasks, or the required tasks may otherwise be known to virtualization module 476.
  • stage 576 it is determined that there are no preparation results in auxiliary memory 240 corresponding to the block, either because pre-updater 210 did not store such a result, or because such a result was stored and later erased.
  • stage 582 is performed with virtualization module 476 generating the updated or rolled back block in volatile memory 250 without reading any preparation result from auxiliary memory 240.
  • the original block or updated block is first read from updatable content memory 230 prior to generating the updated or rolled back block respectively.
  • An updated or reversed block may be generated in stage 582 using any suitable updating procedure, for example based on any of the original/updated block and/or data in backup buffer 260.
  • the updated or reversed block may be generated as described in the aforementioned U.S. Patent No. 6,018,747 and U.S. Publication No. 20070050330 , U.S. Publication No. 2006/004756 , and/or U.S. Application No. 11/997,134 . It is noted that some of the procedures noted in these publications are also valid for stage 582 even though blocks are not usually requested and updated/reversed by virtualization module 476 in a pre-specified update sequence, while in these publications in contrast a pre-specified update sequence is typically although not necessarily followed.
  • updater 420 follows an update sequence, and that updater 420 protects in backup buffer 260 at least data which is required for rolling back content and/or original data from updated blocks which is needed for the updating of other block(s) later in the update sequence.
  • the requester may request blocks from on demand paging module 472 in an arbitrary order, not necessarily in line with the order in which the blocks are being updated/rolled back.
  • updating by virtualization module 476 occurs if the requested block is later in the update sequence than the block currently being updated or rolled back.
  • the virtualization module 476 may update the original content of the requested block if desired, based on the original content in the requested block, the original content in blocks later in the update sequence than the requested block, and/or based on original content which was protected in backup buffer 260 from blocks earlier in the update sequence than the requested block.
  • rolling back by virtualization module 476 occurs if the requested block is earlier in the update sequence than the block currently being updated or rolled back.
  • virtualization module 476 may roll back the updated content of the requested block, based on the updated content of the requested block and/or based on data which was protected in backup buffer 260 which allows the requested block to be rolled back to original content.
  • stage 584 virtualization module 476 supplies the updated block to on demand paging module 472, and on demand paging module 472 in turn provides the supplied block to the requester.
  • stages 566, 572, 576, 582, and 584 may be performed by paging module 472.
  • stage 586 it is determined whether or not the device has been reset (i.e., whether or not stage 558 has been performed). If the device has been reset, then the rendering process ends. If the device has not been reset then the rendering process iterates back to stage 564, waiting for a request for another block. In one embodiment, a determination of whether the device has been reset may be made any time during the execution of stages 564 to 586, ending the rendering process once the device has been reset or proceeding to the next stage if the device has not been reset.
  • on-demand paging module 470 may work conventionally, reading any requested block from updatable content memory 230 (without requiring the assistance of virtualization module 476) and providing the requested block to the requester.
  • virtualization module 476 may read any requested block from updatable content memory 230, supply the requested block to on demand paging module 472, and on demand paging module 472 in turn may provide the supplied block to the requester.
  • a paging module typically although not necessarily would also be comprised in an updatable device which performs an in-place update when the device is not operational (as in method 300), but a virtualization module would typically although not necessarily not be needed while the in-place update is taking place. Assuming a virtualization module is not needed, the paging module would work conventionally, reading blocks from updatable content memory 230 when the device is operational and providing the requested blocks to the requester. Therefore, while the pre-update process is running, the paging module would read original version blocks from updatable content memory 230. After the in-place update has been completed and the device has again become operational (in stage 352), the paging module would read updated (or rolled back) blocks (or blocks whose content is the same in the original and updated version) from updatable content memory 230.
  • cellular telephones belong to a group referred to as embedded devices.
  • embedded devices for example: Personal Digital Assistants (PDAs), set-top boxes and other consumer electronic devices which are controlled and operated by a CPU and software and therefore are associated with storages for storing content, and sometimes it is required to update the content stored therein.
  • PDAs Personal Digital Assistants
  • Such consumer electronic device can be Cameras, e-book readers, Mobile Internet Devices (MID), Navigation systems, car infotainment systems, and more.
  • Embedded device can be also general utility home appliances which are electronically controlled by a CPU and Software, such as washing machines, DVD players, Blue-ray players and other home entertainment systems.
  • embedded devices can medical devices which are controlled by CPU and software, whether outside the human body or inside the human body, such as pacemakers.
  • Embedded devices can also be part of avionic and aerospace control systems involved in guidance and other functions of the craft in which they are embedded in. All these examples of embedded device represent devices associated with storage holding content which sometimes may require updating. There are many more examples of embedded devices and the above provided examples just demonstrate the possible variety and should not be construed as a concise list. Yet, it is possible to update also content stored in storages associated with non-embedded devices, such as PCs or other general purpose computers.
  • 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.
  • updatable devices or “devices” will be used hereinafter, and it should be noted that the term “updatable device” or “device” as used herein can refer to any device that is associated with a storage 107 and allows updating content stored therein.
  • Methods of the present invention may be implemented by performing or completing manually, automatically, or a combination thereof, selected steps or tasks.
  • method may refer to manners, means, techniques and procedures for accomplishing a given task including, but not limited to, those manners, means, techniques and procedures either known to, or readily developed from known manners, means, techniques and procedures by practitioners of the art to which the invention belongs.
  • the present invention may be implemented in the testing or practice with methods and materials equivalent or similar to those described herein.

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)
  • Stored Programmes (AREA)

Claims (15)

  1. Procédé de mise à jour d'une version originale de contenu à une nouvelle version de contenu, dans un dispositif de stockage en mémoire non volatile (200 ; 400), le procédé comprenant le fait :
    de fournir une zone de stockage en mémoire de contenu non volatile (230) stockant la version originale de contenu ;
    de fournir une zone de mémoire auxiliaire (240) ;
    d'exécuter (304), tandis qu'au moins une partie de la version originale de contenu stocké dans la zone de stockage en mémoire de contenu (230) n'est pas en cours de mise à jour, au moins une opération de pré-mise à jour correspondant à au moins une opération de mise à jour sur place pouvant être appliquée, lors d'une mise à jour sur place, à l'au moins une partie de la version originale de contenu ;
    de stocker (306), tandis que l'au moins une partie de la version originale de contenu n'est pas en cours de mise à jour, au moins un résultat de préparation de l'au moins une opération de pré-mise à jour exécutée, sur la zone de mémoire auxiliaire (240) ; et
    d'exécuter une mise à jour sur place (326) de l'au moins une partie de la version originale de contenu comprenant la mise à jour d'une zone discrète à mettre à jour, qui comprend l'utilisation de l'au moins un résultat de préparation (318 ; 322, 324) stocké sur la zone de mémoire auxiliaire (240) si ledit résultat de préparation correspond à ladite zone discrète, et de générer (325) la zone discrète mise à jour sans lire un résultat de préparation quelconque à partir de ladite zone de mémoire auxiliaire (240) s'il est déterminé qu'il n'existe pas de résultat de préparation dans ladite zone de mémoire auxiliaire (240) correspondant à ladite zone discrète.
  2. Procédé selon la revendication 1, dans lequel l'au moins une opération de pré-mise à jour comprend des calculs requis pour la mise à jour sur place.
  3. Procédé selon la revendication 1 ou 2, dans lequel l'au moins une opération de pré-mise à jour résulte en un contenu requis pour une copie ultérieure sur la zone de stockage en mémoire de contenu (230).
  4. Procédé selon l'une des revendications 1 à 3, dans lequel l'exécution (304) d'au moins une opération de pré-mise à jour ou le stockage (306) d'au moins un résultat de préparation sont effectués tandis que la zone de stockage en mémoire de contenu (230) est en cours d'utilisation.
  5. Procédé selon la revendication 4, dans lequel l'exécution d'une mise à jour sur place (326) de l'au moins une partie de la version originale de contenu comprend le fait :
    de copier le contenu stocké sur la zone de mémoire auxiliaire (240) sur la zone de stockage en mémoire de contenu (230) ; et/ou
    d'utiliser les calculs stockés sur la zone de mémoire auxiliaire (240) ce qui permet de réduire un temps de mise à jour sur place.
  6. Procédé selon la revendication 4 ou 5, comprenant en outre l'exécution de la mise à jour sur place tandis que la zone de stockage en mémoire de contenu (230) est en cours d'utilisation ; et l'exécution, tandis que la mise à jour sur place se produit, d'un processus de rendu (564-584) qui comporte le fait de fournir un contenu demandé d'une version particulière à partir de la zone de stockage en mémoire de contenu (230).
  7. Procédé de la revendication 6, dans lequel le fait de fournir le contenu demandé comprend la génération du contenu demandé en utilisant l'au moins un résultat de préparation stocké sur la zone de mémoire auxiliaire (240), dans le cas où le contenu demandé n'est pas disponible sur la zone de stockage en mémoire de contenu (230).
  8. Système permettant de mettre à jour une version originale de contenu à une nouvelle version de contenu, dans un dispositif de stockage en mémoire non volatile (200 ; 400), le système comprenant :
    une zone de stockage en mémoire de contenu non volatile (230) stockant la version originale de contenu ;
    une zone de mémoire auxiliaire (240) ;
    un module de pré-mise à jour (210) ; et
    un module de mise à jour sur place (220),
    dans lequel le module de pré-mise à jour (210) est agencé :
    pour exécuter (304), tandis qu'au moins une partie de la version originale de contenu stocké dans la zone de stockage en mémoire de contenu (230) n'est pas en cours de mise à jour, au moins une opération de pré-mise à jour, où l'au moins une opération de pré-mise à jour correspond à au moins une opération de mise à jour sur place pouvant être appliquée à l'au moins une partie de la version originale de contenu ; et
    pour stocker (306), tandis que l'au moins une partie de la version originale de contenu n'est pas en cours de mise à jour, au moins un résultat de préparation de l'au moins une opération de pré-mise à jour exécutée, sur la zone de mémoire auxiliaire (240), et
    dans lequel le module de mise à jour sur place (210) est agencé pour exécuter une mise à jour sur place (326) de l'au moins une partie de la version originale de contenu comprenant la mise à jour d'une zone discrète à mettre à jour, qui comprend l'utilisation de l'au moins un résultat de préparation stocké sur la zone de mémoire auxiliaire (240) si ledit résultat de préparation correspond à ladite zone discrète, et la génération (325) de la zone discrète mise à jour sans lire un résultat de préparation quelconque à partir de ladite zone de mémoire auxiliaire (240) s'il est déterminé qu'il n'existe pas de résultat de préparation dans ladite zone de mémoire auxiliaire (240) correspondant à ladite zone discrète.
  9. Système selon la revendication 8, dans lequel l'au moins une opération de pré-mise à jour comprend des calculs requis pour la mise à jour sur place.
  10. Système selon la revendication 8 ou 9, dans lequel l'au moins une opération de pré-mise à jour résulte en un contenu requis pour une copie ultérieure sur la zone de stockage en mémoire de contenu (230).
  11. Système selon l'une des revendications 8 à 10, dans lequel le module de pré-mise à jour (210) est agencé pour exécuter (304) au moins une opération de pré-mise à jour ou pour stocker (306) au moins un résultat de préparation de l'au moins une opération de pré-mise à jour exécutée tandis que la zone de stockage en mémoire de contenu (230) est en cours d'utilisation.
  12. Système selon la revendication 11, dans lequel le module de mise à jour sur place (220) est en outre agencé :
    pour copier le contenu stocké sur la zone de mémoire auxiliaire (240) sur la zone de stockage en mémoire de contenu (230) ; et/ou
    pour utiliser les calculs stockés sur la zone de mémoire auxiliaire (240) ce qui permet de réduire le temps de mise à jour sur place.
  13. Système selon la revendication 11 ou 12, comprenant en outre un module de rendu (470) agencé pour exécuter un processus de rendu (564-584) tandis que la mise à jour sur place se produit et tandis que la zone de stockage en mémoire de contenu (230) est en cours d'utilisation, où le processus de rendu comprend le fait de fournir un contenu demandé d'une version particulière à partir de la zone de stockage en mémoire de contenu (230).
  14. Système de la revendication 13, dans lequel le module de rendu (470) est en outre agencé pour générer le contenu demandé en utilisant l'au moins un résultat de préparation stocké sur la zone de mémoire auxiliaire (240), dans le cas où le contenu demandé n'est pas disponible sur la zone de stockage en mémoire de contenu (230).
  15. Produit de programme informatique mis en oeuvre sur un dispositif de stockage lisible par machine, incorporant de manière tangible un programme d'instructions pouvant être exécutées par la machine pour effectuer des étapes de procédé afin de mettre à jour un contenu original stocké dans une zone de stockage en mémoire de contenu non volatile (230) associée à un dispositif (200 ; 400) pour produire un contenu mis à jour, le procédé comprenant le fait :
    d'exécuter (304), tandis qu'au moins une partie du contenu original stocké dans la zone de stockage en mémoire de contenu (230) n'est pas en cours de mise à jour, au moins une opération de pré-mise à jour correspondant à au moins une opération de mise à jour sur place pouvant être appliquée, lors d'une mise à jour sur place, à l'au moins une partie du contenu original ;
    de stocker (306), tandis que l'au moins une partie du contenu original n'est pas en cours de mise à jour, au moins un résultat de préparation de l'au moins une opération de pré-mise à jour exécutée, sur une zone de mémoire auxiliaire (240) ; et
    d'exécuter une mise à jour sur place (326) de l'au moins une partie du contenu original comprenant la mise à jour d'une zone discrète à mettre à jour, qui comprend l'utilisation d'au moins un résultat de préparation (318 ; 322-324) stocké sur la zone de mémoire auxiliaire (240) si ledit résultat de préparation correspond à ladite zone discrète, et de générer (325) la zone discrète mise à jour sans lire un résultat de préparation quelconque à partir de ladite zone de mémoire auxiliaire (240) s'il est déterminé qu'il n'existe pas de résultat de préparation dans ladite zone de mémoire auxiliaire (240) correspondant à ladite zone discrète.
EP09787502.5A 2008-08-04 2009-08-03 Exécution d'une mise à jour préalable dans une mémoire non volatile Active EP2329366B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US8587908P 2008-08-04 2008-08-04
PCT/IL2009/000754 WO2010016057A2 (fr) 2008-08-04 2009-08-03 Exécution d’une mise à jour préalable dans une mémoire non volatile

Publications (2)

Publication Number Publication Date
EP2329366A2 EP2329366A2 (fr) 2011-06-08
EP2329366B1 true EP2329366B1 (fr) 2013-12-11

Family

ID=41520724

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09787502.5A Active EP2329366B1 (fr) 2008-08-04 2009-08-03 Exécution d'une mise à jour préalable dans une mémoire non volatile

Country Status (3)

Country Link
US (1) US8176009B2 (fr)
EP (1) EP2329366B1 (fr)
WO (1) WO2010016057A2 (fr)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4633837B2 (ja) * 2008-01-22 2011-02-16 富士通株式会社 アドレス配信システム、方法およびそのためのプログラム
US9063666B2 (en) * 2010-03-25 2015-06-23 International Business Machines Corporation File index, metadata storage, and file system management for magnetic tape
US9275678B2 (en) * 2010-03-25 2016-03-01 International Business Machines Corporation Primary storage media with associated secondary storage media for efficient data management
US9430155B2 (en) * 2010-03-25 2016-08-30 International Business Machines Corporation File index, metadata storage, and file system management for magnetic tape
CN103457905B (zh) * 2012-05-28 2015-09-09 腾讯科技（深圳）有限公司 数据同步方法、系统及设备
KR102118161B1 (ko) * 2012-06-26 2020-06-03 레드 밴드 리미티드 장치 저장의 제자리 재조직을 위한 시스템들 및 방법들
DE102014208609A1 (de) * 2014-05-08 2015-11-26 Robert Bosch Gmbh Refresh eines Speicherbereichs einer nichtflüchtigen Speichereinheit
TWI610217B (zh) * 2015-03-12 2018-01-01 晨星半導體股份有限公司 視窗系統之電子裝置及其控制方法
US10642602B2 (en) * 2017-12-12 2020-05-05 Nxp Usa, Inc. NVM architecture with OTA support
CN110083381B (zh) * 2018-01-26 2023-04-28 启碁科技股份有限公司 增量升级的方法及装置
US11567672B2 (en) * 2021-06-17 2023-01-31 Vmware, Inc. Data and configuration integrity checking post-rollback using backups in virtualized computing environments
US11645158B2 (en) 2021-06-17 2023-05-09 Vmware, Inc. Automated rollback in virtualized computing environments

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023620A (en) * 1997-02-26 2000-02-08 Telefonaktiebolaget Lm Ecrisson Method for downloading control software to a cellular telephone
FR2767626B1 (fr) * 1997-08-25 1999-10-15 Alsthom Cge Alcatel Terminal radiotelephonique a carte d'identification d'abonne
US6018747A (en) 1997-11-26 2000-01-25 International Business Machines Corporation Method for generating and reconstructing in-place delta files
IL125846A0 (en) 1998-08-19 1999-04-11 Emony Incremental program update
US6754848B1 (en) * 1999-09-30 2004-06-22 International Business Machines Corporation Method, system and program products for operationally migrating a cluster through emulation
JP2004514214A (ja) * 2000-11-17 2004-05-13 ビットフォン　コーポレイション 情報をアップデートおよび配布するシステムおよび方法
US6832373B2 (en) * 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
EP1237078A1 (fr) * 2001-01-19 2002-09-04 Siemens Aktiengesellschaft Exécution d'un échange d'une application logicielle optimisé pour le temps
FR2820849B1 (fr) * 2001-02-15 2003-05-16 Cit Alcatel Procede de stockage de donnees informatiques et dispositif de stockage correspondant
CA2357382A1 (fr) * 2001-09-17 2003-03-17 Soma Networks, Inc. Methode, appareil et systeme de mise a niveau de logiciels
US7086049B2 (en) 2002-02-26 2006-08-01 International Business Machines Corporation Background code update for embedded systems
JP2003323301A (ja) * 2002-02-27 2003-11-14 Fuji Xerox Co Ltd ソフトウェアをダウンロードする情報処理装置、ダウンロード方法及びダウンロードプログラム
KR100744873B1 (ko) * 2002-08-20 2007-08-01 엘지전자 주식회사 컴퓨터 시스템에서의 펌웨어 기록방법
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
JP4412989B2 (ja) * 2003-12-15 2010-02-10 株式会社日立製作所 複数の記憶システムを有するデータ処理システム
EP1738256B1 (fr) * 2004-03-15 2018-05-02 Red Bend Ltd. Procede et appareil de mise a jour fiable d'une version de contenu stockee
US7587433B2 (en) 2004-06-01 2009-09-08 Red Bend Ltd. Method and system for in-place updating content stored in a storage device
JPWO2006067923A1 (ja) * 2004-12-22 2008-06-12 松下電器産業株式会社 メモリコントローラ、不揮発性記憶装置、不揮発性記憶システム及びメモリ制御方法
KR100698655B1 (ko) * 2005-01-04 2007-03-23 주식회사 팬택앤큐리텔 이동통신 단말기의 파일 업데이트 시스템과, ｅｆｓ 영역헤더 손실로 인한 치명적인 에러를 방지하는 이동통신단말기의 부팅 관리 시스템과, 이동통신 단말기의 파일업데이트 방법 및 ｅｆｓ 영역 헤더 손실로 인한 치명적인에러를 방지하는 이동통신 단말기의 부팅 방법
US8561049B2 (en) 2005-08-23 2013-10-15 Red Bend Ltd. Method and system for updating content stored in a storage device
US7802245B2 (en) 2006-04-27 2010-09-21 Agere Systems Inc. Methods and apparatus for performing in-service upgrade of software in network processor
US8200912B2 (en) * 2006-08-31 2012-06-12 St-Ericsson Sa Multi-core device with optimized memory configuration

Also Published As

Publication number Publication date
US20100030823A1 (en) 2010-02-04
US8176009B2 (en) 2012-05-08
WO2010016057A3 (fr) 2010-04-01
WO2010016057A2 (fr) 2010-02-11
EP2329366A2 (fr) 2011-06-08

Similar Documents

Publication Publication Date Title
EP2329366B1 (fr) Exécution d'une mise à jour préalable dans une mémoire non volatile
EP2638466B1 (fr) Procédé de mise à jour de logiciel pour dispositif intégré
US7587433B2 (en) Method and system for in-place updating content stored in a storage device
JP4901095B2 (ja) 不揮発性ストレージにカスタム・ソフトウェア・イメージ・アップデートを適用するフェイルセーフな方法
EP1934729B1 (fr) Procedes et systemes d'actualisation de contenu comprenant une version comprimee
KR100584338B1 (ko) 소프트웨어 업데이트 방법 및 시스템
US20080196019A1 (en) Method and Apparatus for Generating an Update Package
EP2329368B1 (fr) Mise à jour de contenu sans utiliser de mini-système d'exploitation
EP1934727B1 (fr) Procede et systeme de mise a jour in situ de contenu stocke dans un dispositif de stockage
US9043680B2 (en) Method and system for in-place updating content stored in a storage device
CN103164342A (zh) 数据可用性的挂载时协调
EP2329367B1 (fr) Exécution d'une mise à jour sur place d'un dispositif de stockage en fonctionnement
US20080172584A1 (en) Method and system for in-place updating content stored in a storage device
US8055853B2 (en) Data storage system and data storage program for atomic transactions
KR20230001522A (ko) 펌웨어 이미지의 부트 업 활성화를 위한 시스템들 및 방법

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20110303

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

AX Request for extension of the european patent

Extension state: AL BA RS

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: RED BEND LTD.

RIN1 Information on inventor provided before grant (corrected)

Inventor name: MELLER, EVYATAR

Inventor name: PELEG, SHARON

17Q First examination report despatched

Effective date: 20121004

111Z Information provided on other rights and legal means of execution

Free format text: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

Effective date: 20130307

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20130703

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 644895

Country of ref document: AT

Kind code of ref document: T

Effective date: 20140115

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602009020734

Country of ref document: DE

Effective date: 20140206

REG Reference to a national code

Ref country code: NL

Ref legal event code: VDEP

Effective date: 20131211

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 644895

Country of ref document: AT

Kind code of ref document: T

Effective date: 20131211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20140311

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20140411

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20140411

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602009020734

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

26N No opposition filed

Effective date: 20140912

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602009020734

Country of ref document: DE

Effective date: 20140912

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: LU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20140803

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140831

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140831

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 7

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20140803

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20140312

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20090803

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 8

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 9

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20131211

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 10

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230527

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20240723

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20240723

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20240723

Year of fee payment: 16