EP2329368B1 - Mise à jour de contenu sans utiliser de mini-système d'exploitation - Google Patents

Mise à jour de contenu sans utiliser de mini-système d'exploitation Download PDF

Info

Publication number
EP2329368B1
EP2329368B1 EP09787508.2A EP09787508A EP2329368B1 EP 2329368 B1 EP2329368 B1 EP 2329368B1 EP 09787508 A EP09787508 A EP 09787508A EP 2329368 B1 EP2329368 B1 EP 2329368B1
Authority
EP
European Patent Office
Prior art keywords
update
volatile memory
software
paged
core
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
EP09787508.2A
Other languages
German (de)
English (en)
Other versions
EP2329368A2 (fr
Inventor
Evyatar Meller
Yair Noam
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 EP2329368A2 publication Critical patent/EP2329368A2/fr
Application granted granted Critical
Publication of EP2329368B1 publication Critical patent/EP2329368B1/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

Definitions

  • This invention relates to updating content stored in a storage memory 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. This is non-limiting though and sometimes more than one update package can be obtained which together allow the updating of content.
  • 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.
  • 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 naive manner, though such deltas tend to be rather large.
  • US 6,546,552 (“ Difference extraction between two versions of data-tables containing intra-references", published 2003) discloses a method for generating a compact difference result between an old program and a new program.
  • Each program includes reference entries that contain references that refer to other entries in the program.
  • the old program is scanned and for each reference entry, the reference is replaced by a distinct label mark, whereby a modified old program is generated.
  • the new program is scanned and for each reference entry the reference is replaced by a distinct label mark, whereby a modified new program is generated.
  • the difference result is generated.
  • WO 2004/114130 (“ Method and system for updating versions of content stored in a storage device", published 2004) discloses 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 WO 2004/114130 includes a conversion element generator for generating a conversion element associated with the old version and new version. It also includes a modified version generator for generating a modified version, and an update package generator for generating the compact update package.
  • the compact update package includes the conversion element and a modified delta based on the modified version and the new version.
  • WO 2005/003963 discloses a system and method for updating versions of content stored in a storage.
  • the system of WO 2005/003963 includes an update module for obtaining a conversion element and a small delta. It also includes a converted old items generator for generating converted old items by applying the conversion element to items of an old version, a data entries generator for generating data entries based on the modified data entries and on the converted old item, and a new version generator for generating a new version of content by applying the commands and the data entries to the old version.
  • update package is sometimes referred to as a delta, however, this is non-limiting, and as it appears from WO 2004/114130 and WO 2005/003963 , an update package may sometimes include a delta therewith, or as another example the update package may include the entire updated version.
  • Other methods exist in the art which take care of additional considerations involved in the update. Prior to elaborating on other methods these considerations should be pointed out.
  • 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.
  • US 6,018,747 (“ Methodfor generating and reconstructing in-place delta files", published 2000) discloses a method, apparatus, and article of manufacture for generating, transmitting, replicating, and rebuilding in-place reconstruct software updates to a file from a source computer to a target computer.
  • US 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.
  • US 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.
  • US 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. It was already mentioned before that when in-place updating blocks of content, an original content of a block sometimes forms part of the input used by the update process. In such a case, if the original block (which is corrupted due to interruption) is required, the update process may be unable to resume. It can be impossible to re-update the corrupted block.
  • US 6,832,373 (“System and method for updating and distributing information", published 2004), 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 US 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 US 6,832,373 's inventors, may be performed more quickly than through the use of technologies existing when US 6,832,373 was filed.
  • US 6,832,373 describes using an auxiliary backup block, while all block update operations are performed thereby using two phases 'two-phase protocol' or 'two-phase commit'.
  • the update process in a first phase of updating a block, writes the updated content to the auxiliary backup block and verifies that the content is correctly stored.
  • the update process writes the updated content into its target block to form the updated content of the updated 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 auxiliary 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 auxiliary 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 auxiliary backup block) cannot be smaller than 2n. 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 2n.
  • 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. Thus, WO 2007/023497 resolves write before read conflicts as well as maintaining reliable update.
  • the stored original content of the updatable device is updated.
  • the term "updatable device” or “device” refers to any device that is associated with a storage and which allows updating content stored therein.
  • the stored original content of the updatable device includes software for normal mode process(es), that is for process(es) unrelated to the updating of the content (called here software for the core).
  • the stored original content includes software for the update process which is executed during the update mode, that is software related to updating the stored original content (called here software for the "miniOS", mini-operating system).
  • the stored software for the core and/or for the miniOS is updated.
  • task(s) which is/are neither exclusive to the update process nor to the other unrelated process(es), and therefore may potentially be required both during the update process and during other unrelated process(es) performed by the updatable device.
  • Such task(s) may include for example non-volatile memory read/write, basic user interface such as keyboard functions, etc. Since the core software is subject to updates, in order for an update task to be executable both by the core and the miniOS, the software procedure defining the update-task must be duplicated and stored twice, both as part of the software for the core and as part of the software for the miniOS, being capable of re-writing the core in-place during the update process.
  • each storage of the (duplicated) procedure(s) which may potentially be required both during the update process and during other process(es) necessitates about 5 Megabytes.
  • the miniOS also performs tasks unique to the update process (and which are typically not executed by the core), and therefore the miniOS also includes modules such as an update agent (UA) and update installer (UPI) which typically operate only during the update process.
  • UA update agent
  • UPI update installer
  • the software for the UA and UPI together have a size of between 200 and 400 Kbytes, and therefore the duplicated procedure(s) comprised in the miniOS typically take(s) up a more substantial part of storage than the UA and UPI.
  • non-volatile memory 110 includes a section 112 for storing software for a boot loader, a "critical" section 116 for storing software for the miniOS, a backup section 114 for storing a backup of software for the miniOS, a section 118 for storing the software for the non-paged part of the core, a section 120 for storing the software for the paged part of the core, a file system section 122 for storing inter-alia an update package, and a section with one or more backup buffer(s) 124 for storing a normal mode/update mode flag and possibly other data.
  • the stored software for the miniOS includes: software for the UA, software for the UPI, non-volatile memory read/write drivers, and any other "duplicated" procedure(s) for tasks that may potentially be required both during the update process and during other unrelated process(es).
  • the boot loader checks a normal/update flag in a designated backup buffer 124.
  • the update process is performed only during the update mode, and any process which is unrelated to the update process is performed during normal mode. It is noted that in this configuration the boot loader is kept minimal with the boot loader capable of writing to volatile memory but not to non-volatile memory 110 and with the boot loader incapable of even accessing file system 122. If the flag indicates "normal" mode, the boot loader loads the software for the non-paged core to volatile memory. The non-paged core then starts the normal mode of operation of the updatable device as is known in the art.
  • the boot loader loads the (original) software for the miniOS to volatile memory. Subsequently the boot loader invokes the original UA (whose software, being part of the miniOS software, is now in volatile memory). The UA then obtains an update package from the location where the update package was previously stored by a device management application. The update package relates to updating some or all of the software for the non-paged core and/or paged core, and optionally relates to updating some or all of the software for the miniOS (It should be understood therefore that an updated version of software may in some cases include some identical content as in the original version.) The UA then stores the obtained update package in file system 122.
  • the UA invokes the UPI (whose software, being part of the miniOS software, is now in volatile memory) to update the software of the miniOS, and the UA stores a backup of the updated miniOS software in backup 114. It is noted that for reliability purposes critical section 116 is not updated in-place. Rather, the updated software for the miniOS is written to backup 114 and not immediately to critical section 116 so that if during the writing there is an interruption which erases the volatile memory, the update may be reliably resumed with the original version of the software for the miniOS still stored in critical section 116.
  • the UA overwrites the original version of the software for the miniOS in critical section 116 with the updated backup of the software for miniOS (thereby causing critical section 116 to also contain updated software for the miniOS).
  • the boot loader then loads the updated software for the miniOS from critical section 116 to volatile memory and invokes the updated UA (whose software, being part of the miniOS software is now in volatile memory).
  • the invoked UA (updated or original as described above) then invokes the UPI (updated or original) to update in-place the non-paged core and paged core in sections 118 and 116 respectively (and optionally to update other content in non-volatile memory 110).
  • the UA replaces the update mode flag with the normal mode flag in the designated backup buffer 124.
  • the boot loader then loads the updated software for the non-paged core to volatile memory, invokes the updated non-paged core, and the updated non-paged core starts the normal mode of operation of the updatable device as is known in the art.
  • US 2005/0132359 A1 relates to the problem of how to run an update service from a server to a client and to ensure that the proper patches dealing with applicable versions are used. It does describe in-place updating.
  • FIG. 2 is a schematic illustration of a system 201 for updating content in a cellular network, in accordance with one embodiment of the invention.
  • Cellular telephones 202 associated with storages 203 execute software that enable operation of the cellular telephones and/or updating of the cellular telephones.
  • Storages such as storages 203, are sometimes referred to also as “memories” or "memory units”.
  • Software for a particular cellular telephone 202 is normally stored in associated storage 203.
  • Some or all of storage 203 associated with a particular cellular telephone 202 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. Additionally or alternatively, some or all of storage 203 associated with a cellular telephone 202 may be inside the cellular telephone.
  • any particular associated storage 203 may comprise one or more divisible units.
  • the plurality of units may all be detachable from associated cellular telephone 202, may all be within associated cellular telephone 202 or may be divided between unit(s) which are detachable and unit(s) which are within associated cellular telephone 202.
  • system 201 illustrated in Figure 2 is a non-limiting example and the invention is not limited to updating software. Many other types of content stored in storages require update, such as text, data stored in databases, files stored in the storages etc.
  • the version of the software 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 update package is generated in an update package generator 204, operating, for example, in a personal computer (PC) or in any other type of computer.
  • the update package is stored in an update server 205 and transmitted, via a transmitter 206 to the cellular telephones 202.
  • 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 202.
  • 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.
  • Storages 203 can include volatile memory (such as Random Access Memory RAM, etc) and/or non-volatile memory (such as a hard disk drive, flash memory unit, EPROM (Erasable Programmable Read-Only Memory) and/or EEPROM (Electrically EPROM), etc).
  • volatile memory such as Random Access Memory RAM, etc
  • non-volatile memory such as a hard disk drive, flash memory unit, EPROM (Erasable Programmable Read-Only Memory) and/or EEPROM (Electrically EPROM), etc.
  • a PC or any other computer
  • files that include data required for its operation or for operation of software executing therein (such as "info files” or “dot files” known for those versed in the art).
  • info files or "dot files” known for those versed in the art.
  • it is required to update this data for example, via communication lines, e.g., via the Internet or via any other communication means.
  • the term “content” will be used to mean any type of content including inter-alia software, text, data stored in databases, files stored in the storage, etc.
  • the term “updatable devices” or “devices” will be used hereinafter, and it should be noted as mentioned above that the term “updatable device” or “device” as used herein can refer to any device that is associated with a storage 203 and allows updating content stored therein.
  • update packages are generated, stored in the update server 205 and conveyed to the updatable devices (such as the cellular telephones 202) and the storages 203 associated therewith.
  • updatable devices such as the cellular telephones 202
  • the updatable devices such as the cellular telephones 202
  • the storages 203 associated therewith it is possible to convey an update package without storing it first in an update server 205.
  • the update package is conveyed via the transmitter 206.
  • This is also non-limiting and any other way applicable for conveying the update package can be used.
  • a portable storage 203 such as a compact disk or disk-on-key thus allowing an updatable device (such as the telephones 202) to access the update package by reading it therefrom.
  • an updatable device such as the telephones 202
  • storage 203 and/or the updatable device such as cellular telephone 202 will be written without reference numerals.
  • the single form of update package used herein refers both to embodiments where a single update package provides instructions for an update process and where a plurality of update packages together provide instructions for an update process.
  • Figure 3 illustrates a simplified layout of an apparatus 300 for updating content in-place, according to an embodiment of the present invention.
  • an updatable device (along with associated storage) may comprise apparatus 300.
  • Apparatus 300 includes, inter-alia, an executor 380 which is configured to execute software, and a memory 305.
  • Memory 305 comprises volatile memory 350 (e.g. RAM) and non-volatile memory 310 (e.g. Flash).
  • executor 380 may comprise any suitable hardware capable of carrying out task(s) as defined in software which is stored in non-volatile memory 310 and loaded to volatile memory 350 during the methods described herein.
  • Memory 305 is comprised in the storage associated with the updatable device (although the associated storage may in some cases include additional memory which is irrelevant to described embodiments of the invention and therefore neither illustrated nor described).
  • non-volatile memory 310 includes a section 312 for storing software for boot loader 348, sections 318 and 320 for respectively storing software for a non-paged core 366 and a paged core 336, a file system section 322 for storing inter-alia an update package 334, a section 323 for backing up software for an update agent library (UAL) 362, and one or more backup buffers 324 for storing inter-alia any of the following: a normal mode/update mode of operation flag 332 and a non-paged core update package 360 (i.e. the part of update package 334 which relates to the non-paged core).
  • a normal mode/update mode of operation flag 332 and a non-paged core update package 360 (i.e. the part of update package 334 which relates to the non-paged core).
  • the software for non-paged core 366 and the software for paged core 336 are dissimilar in that the software for non-paged core 366 may be loaded in its entirety from non-volatile memory 310 to volatile memory 350.
  • Software for paged core 336 may not be loaded in its entirety to volatile memory 350 but various "pages" of paged core 336 are instead loaded into (or swapped out of) volatile memory 350 as needed, as is known in the art.
  • executor 380 runs software which has been loaded to volatile memory 350, one or more task(s) which are defined in the software are carried out by the hardware comprised in executor 380.
  • a single executor 380 is illustrated, for simplicity of illustration but it is possible that in some embodiments, different executors run different software.
  • apparatus 300 may be considered to have a configuration comprising the following modules, inter-alia: boot loader 348, non-paged core 366, paged core 336, non-volatile memory 310 and volatile memory 350.
  • Certain tasks assigned to non-paged core 366 are in fact performed by the following (sub) modules of non-paged core 366: update agent "UA” 368 and update agent library "UAL” 370 (wrapping update installer "UPI” module 372).
  • Non-paged core 366 may in some cases comprise other sub-modules, any of which is only described below if necessary for the understanding of the invention. In other embodiments, there may be fewer, more and/or different modules in apparatus 300 than listed above.
  • each of boot loader 348, non-paged core 366, paged core 336, update agent 368, update agent library 370/362 and update installer 372/364 modules may comprise any combination of hardware, software and/or firmware capable of performing the tasks defined and described herein.
  • the core performs tasks vital for the updatable device, and therefore a user typically although not necessarily does not have permission to change the software for the core, but the core may be updated in an update process.
  • non-paged core 366 is capable of performing task(s) unrelated to the updating of content in non-volatile memory 310 during the update process, as well as task(s) relating to the updating of content in non-volatile memory during the update process.
  • the stored software for non-paged core 366 may therefore include software procedures defining tasks which may potentially be required for the update process and/or for process(es) unrelated to the update processes (i.e.
  • the stored software for non-paged core 366 includes procedure(s) defining task(s) which may potentially be required only during the update process, procedure(s) defining task(s) which may potentially be required only for one or more processes unrelated to the update process, and procedure(s) defining task(s) which may potentially be required both during the update process and during one or more processes unrelated to the update process). Therefore, in the illustrated embodiment, there is no need to duplicate storage in non-volatile memory 310 for a procedure which defines a task that may potentially be required both during the update process and during process(es) unrelated to the update process. Similarly, in the illustrated embodiment, there is no need to have separate modules for updating content and for unrelated processes where both would be capable of performing a particular task which could be potentially be required both when updating content and during unrelated process(es).
  • driver(s) for reading from and writing to non-volatile memory 310 may potentially be required both during the update process and during other processes unrelated to the update process.
  • Software for such driver(s) can be stored only once as part of the stored software for non-paged core 366, with non-paged core 366 performing the reading and writing to non-volatile memory 310 both during the update process and during unrelated processes.
  • These drivers may be considered a sub-module of non-paged core 366 and may comprise any combination of hardware, software and/or firmware capable of reading and/or writing to non-volatile memory 310.
  • UA 368 (which may be considered a sub module of non-paged core 366) performs certain tasks assigned to non-paged core 366.
  • UA 368 may perform any of the following: reading update package from non-volatile memory, reading/writing to volatile memory, reading/writing to non-volatile memory (by invoking the aforementioned non-volatile memory driver(s)), calling the UAL, accessing file system 322, etc. More details on certain tasks performed by UA 368 in some embodiments will become apparent from the description.
  • UAL 362 or 370 performs certain tasks assigned to non-paged core 366.
  • UAL 362/370 may perform any of the following: wrap a UPI to enable unified access to the UPI by the update agent or the boot loader, receive pointers to any modules to be invoked by the UAL, etc.
  • the UAL may receive a pointer to the non-volatile memory read or write driver(s) in non-paged core 366 from UA 368, and then invoke the non-volatile memory read or write driver(s). More details on certain tasks performed by the UAL in some embodiments will become apparent from the description.
  • UPI 372 or 364 (wrapped by UAL 370 or 362) performs certain tasks assigned to non-paged core 366.
  • UPI 372 or 364 may perform any of the following: update content, ask UAL to perform read and/or write operations, etc. More details on certain tasks performed by the UPI in some embodiments will become apparent from the description.
  • boot loader 348 loads software from non-volatile memory 310 to volatile memory 350 when the updatable device is reset, and invokes the module whose software has been loaded (for example by causing executor 380 to run the loaded software).
  • boot loader 348 may be capable of writing to volatile memory 350 but not to non-volatile memory 310, and may not have access to file system 322. More details on certain tasks performed by the boot loader in some embodiments will become apparent from the description.
  • non-volatile memory 310 is shown divided into the sections illustrated in Figure 3 in order to facilitate the reader's understanding of the methods that will be described herein for updating content.
  • non-volatile memory 310 may include more, less and/or different sections of memory than illustrated in Figure 3 .
  • additionally or alternatively non-volatile memory 310 may be divided differently than shown in Figure 3 .
  • additionally or alternatively non-volatile memory 310 may store less, more and/or different elements than illustrated in Figure 3 .
  • the order of the sections illustrated in non-volatile memory may be changed and/or the sections may not be contiguous.
  • Figures 4A , 4B are a flowchart of a method 400 for in-place updating content stored in the storage associated with an updatable device, in accordance with an embodiment of the present invention.
  • there may be more, less and/or different stages than illustrated in Figures 4A , 4B 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).
  • the updatable device is in the normal mode of operation.
  • boot loader 348 may have checked flag 332 and because flag 332 showed normal mode, boot loader 348 would have loaded the software for the non-paged core 366 from section 318 to volatile memory 350, invoked non-paged core 366, and non-paged core 366 would have started the normal mode of operation of the updatable device as is known in the art.
  • the device management application of the updatable device has previously obtained an update package 334 and stored update package 334 in non-volatile memory 310, for example in file system 322.
  • non-paged core 366 is capable of performing tasks which are unrelated to the updating of content during the update process, as well as tasks relating to the updating of content during the update process. Therefore, in contrast to the prior art where during normal mode tasks solely related to the updating of content are typically although not necessarily not performed, it is assumed herein that once the non-paged core 366 has been invoked in normal mode, any tasks performable by non-paged core 366 may hypothetically be executed. Examples of tasks which may be performed in normal mode include inter-alia tasks not required for the update process, tasks performed by the UA, UAL or UPI, and/or reading/writing to non-volatile memory.
  • the part of the update process executed during the normal mode of operation includes the backing up of the non-paged core update package and the backing up of the software for the updated UAL, as will be described now. Not all content in the original version of the software for the UAL is necessarily changed and therefore some of the content in the original and updated versions of the software of the UAL may be identical. It is noted that the part of the update process executed in normal mode does not update the software for the core stored in sections 318 and 320 and therefore does not hinder processes executable by the updatable device during the normal mode.
  • UA 368 (for which original version software was loaded to volatile memory 350 upon reset in normal mode as part of the loaded original software for non-paged core 366) obtains a non-paged core update package 360, for example by extracting the part of the update package relating to the non-paged core from update package 334 which is stored in file system 322.
  • a separate update package for the non-paged core 360 may have been received and stored in file system 322 and in stage 404 UA 368 may read the received non-paged core update package 360.
  • UA 368 stores non-paged core update package 360 in backup buffer 324.
  • non-paged core update package 360 is stored in backup buffer 324 because conventionally boot loader 348 can not access file system 322, but boot loader 348 may read from backup buffer 324.
  • Boot loader 348 may therefore conventionally provide the capability of reading non-paged core update package 360 from backup buffer 324 to a module which boot loader 348 invokes (see below).
  • UA 368 may write to non-volatile memory 310 in method 400, for example writing non-paged core update package 360 to backup buffer 324 in stage 406, by invoking the non-volatile memory read/write drivers of non-paged core 366.
  • boot loader 348 does not need to have non-volatile memory write capabilities to perform method 400 because any writing to non-volatile memory 310 in method 400 may rely on the non-volatile memory write drivers in non-paged core 366.
  • stages 404 and 406 may be omitted.
  • boot loader 348 has the capability of accessing file system 322, stages 404 and 406 may be omitted.
  • the updated software for the UAL may be extracted from the update package or may be constructed using the appropriate delta for the UAL software. Assuming first that an update package includes the new version of the software for the UAL (yes to stage 408), then in stage 410 UA 368 extracts the updated software for the UAL from the update package (e.g. from update package 334 or 360) and in stage 430 backs up the updated software for UAL 362 to non-volatile memory 310, for example to section 323.
  • UA 368 invokes UAL 370 (for which original version software was loaded to volatile memory 350 upon reset in normal mode as part of the loaded original software for non-paged core 366).
  • UAL 370 calls UPI 372 (for which original version software was also loaded to volatile memory 350 upon reset in normal mode as part of the loaded original software for non-paged core 366).
  • UPI 372 asks UAL 370 for input.
  • UAL 370 reads the stored original version of the software for UAL from non-volatile memory 310, for example from section 318.
  • stage 418 may be omitted because the original software for UAL was previously loaded to volatile memory 350 upon reset in normal mode as part of the loaded original software for non-paged core 366.
  • UAL 370 reads the delta for the software for the UAL from the update package (e.g. from non-paged core update package 360 stored in backup buffer 324 or from update package 334 stored in file system 322).
  • UPI 372 constructs in volatile memory 350 an updated version of the software for the UAL, using the read delta and original version of the software for the UAL.
  • UA 368 backs up the updated version of the software for UAL 362 to non-volatile memory 310, for example to section 323.
  • the original version of the software for UAL 370 stored in section 318 is not overwritten during normal mode so as to avoid operating in normal mode with a non-paged core comprising partially original and partially updated content. Therefore section 318 retains the original version of the software for UAL 370 even after stage 430 has been performed.
  • UA 368 backs up the updated version of the software for UAL 362 to non-volatile memory 310, for example to section 323 by invoking the non-volatile memory read/write drivers of non-paged core 366.
  • the backup updated software for UAL 362 can be retrieved in some cases where the update process has been interrupted in order to resume the update process (see, for example, the description of method 500 below).
  • an updated version of the software for the entire updated non-paged core may be extracted or constructed and in stage 430 backed up to section 323 but the advantage of backing up only the updated software for the UAL is the small size of the software for the UAL, typically although not necessarily about 128 kilobytes.
  • the updated software for the UAL is extracted or constructed, in this embodiment, not all content in the original version of the software for the non-paged core is necessarily changed and therefore some of the content in the original and updated versions may be identical.
  • flag 332 is set to update mode by UA 368.
  • the updatable device resets and enters the update mode of operation.
  • the updatable device may reset immediately after flag 332 is set to update mode, may reset when convenient to the user, or may reset at a later time.
  • 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. If the user indicates that the user is not ready, then in this embodiment the updatable device remains in normal mode, resetting is deferred, and the updatable device may repeat the question at a later time.
  • the updatable device may proceed directly to resetting stage 434 after stage 432, with or without prior notice to the user that the device will be reset.
  • 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.
  • the updatable device may reset during the next recharging a non-empty battery of the updatable device, and not necessarily soon after stage 432.
  • boot loader 348 loads the backup updated version of the software for UAL 362 (including the updated version of the software for UPI 364) from non-volatile memory 310, for example from section 323, into volatile memory 350.
  • boot loader 348 invokes updated UAL 362. Assuming that boot loader 348 has the conventional capability to read from backup buffer 324, boot loader 348 provides to invoked updated UAL 362 the capability of reading non-paged core update package 360 from backup buffer 324.
  • the updated version of the software for the non-paged core may be loaded or constructed. Assuming first that non-paged core update package 360 (stored for example in backup buffer 324) includes an updated version (yes to stage 440), then in stage 442, updated UAL 362 loads the updated software for the non-paged core from non-paged core update package 360 (stored for example in backup buffer 324) into volatile memory 350.
  • updated UAL 362 calls updated UPI 364.
  • updated UPI 364 asks updated UAL 362 for input.
  • updated UAL 362 reads the stored original version of the software for non-paged core 366 from non-volatile memory 310, for example from section 318.
  • updated UAL 362 reads the delta for the software for the non-paged core from non-paged core update package 360, stored for example in backup buffer 324.
  • updated UPI 364 constructs in volatile memory 350 an updated version of the software for the non-paged core, using the read delta and the original version of the non-paged core.
  • updated UAL 362 loads the updated software for the non-paged core except for the updated software for the UAL from non-paged core update package 360 from backup buffer 324 to volatile memory 350.
  • updated UAL 362 reads the stored original version of the software for non-paged core except for the original version of the software for the UAL from section 318, reads the delta for the software for the non-paged core except for the delta for the software for the UAL in stage 450 from non-paged core update package 360 stored in backup buffer 324, and in stage 452 updated UPI 364 constructs in volatile memory 350 an updated version of the software for the non-paged core (excluding the updated UAL), using the read delta and original version of the software for the non-paged core (excluding the original UAL).
  • the backed-up updated software for UAL 362 which was loaded for example from backup buffer 323 into volatile memory 350 in stage 436 supplements the loaded or constructed updated software for the non-paged core (excluding for
  • updated UAL 362 may instead respectively read the delta in stage 450 or load the updated version in stage 442 of the software for the non-paged core from update package 334 stored in file system 322, and the decision of stage 440 would relate in these alternative embodiments to whether or not the updated software for the non-paged core is in update package 334.
  • stages 404 and 406 were omitted because boot loader 348 has the capability of accessing file system 322 and can provide the capability to invoke updated UAL 362 and there was therefore no separate backing up of a non-paged core update package.
  • stages 436 to 452 may be omitted.
  • boot loader 348 loads the backed-up updated software for the non-paged core from non-volatile memory 310 (for example from section 323) to volatile memory 350 after stage 434 and before stage 454.
  • boot loader 348 invokes the updated non-paged core whose software has come to be located in volatile memory 350 due to any of the various embodiments described above. It is noted that the updated non-paged core comprises inter-alia an updated UA and an updated UAL (which includes an updated UPI).
  • stage 456 the software for the paged core 336 and the software for the non-paged core 366 which are located in sections 320 and 318 respectively of non-volatile memory 310, are updated in place (i.e. so that updated content overwrites original content), using any suitable in-place updating techniques.
  • the updated UA invokes the updated UAL to load into and/or construct in volatile memory 350 the updated software for the paged core and the updated software for the non-paged core and to write in-place the updated software to sections 320 and 318 respectively of non-volatile memory 310.
  • the updated UA copies the updated version of the software for the non-paged core which is already located in volatile memory 350 to section 318 of non-volatile memory 310 (replacing the original version of the software).
  • the updated UA invokes the updated UAL to load into or construct in volatile memory 350 the updated software for the paged core and to write the updated software in place to section 320 of non-volatile memory 310.
  • the updated UAL may load into or construct in volatile memory the updated software for the paged core (and optionally for the non-paged core) by performing stages 440 to 452 for the paged core and optionally for the non-paged core.
  • the updated UAL will call the updated UPI
  • the updated UPI will ask the updated UAL for input
  • the updated UAL will read the original version of the software and the delta
  • the UPI will construct the updated version of the software in volatile memory 350.
  • the updated UAL may write to non-volatile memory 310 by invoking the non-volatile memory read or write driver(s) after receiving a pointer to the non-volatile memory read or write driver(s) from the updated UA. It should be understood that when loading into or constructing in volatile memory 350 software for the paged core, the software for the paged core is typically although not necessarily not all loaded into and/or constructed in volatile memory 350 at one time due to the large size thereof.
  • the invention does not limit the type of in-place update performed in stage 456 to any particular in-place update, and depending on the embodiment, any suitable in-place update may be performed.
  • any suitable in-place update may be performed.
  • US Patent No. 6,018,747 to Burns et al. and US Publication Number 20070050330 describe examples of various techniques for in-place updating, although the invention is not limited to these examples.
  • the first block of content 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 be based on the order of the blocks in non-volatile memory 310, may have been selected in order to limit the potential number of write before read conflicts, or for any other reason.
  • the aforementioned US Patent No. 6,018,747 to Burns et al. and US Publication Number 20070050330 to Meller et al. describe determination of update sequences in update packages.
  • the dynamic selection may be random, may be based on the order of the blocks in non-volatile memory 310, may be made in order to limit the potential number of write before read conflicts, or may be made for any other reason.
  • the updating may include storage of data into a designated non-volatile back-up buffer, for example one of backup buffers 324.
  • buffer(s) 324 examples include inter-alia: original or updated block(s) (at least until the corresponding updated block has been safely written to non-volatile memory 310), any part of original block(s) which is needed for later updating of other block(s) (thereby preventing write before read conflicts) and/or data which will allow a continuation of the update process if there is an interruption which erases volatile memory.
  • the storage in backup buffer(s) 324 may occur immediately prior to the overwriting of the related original block in non-volatile memory 310(or of the first of a plurality of related original blocks) and/or may occur earlier on, for example prior to overwriting any original content in non-volatile memory 310.
  • the update process may not include storage of data in a designated backup buffer. It should be noted that although storage in backup buffer(s) 324 may enhance reliability of the update process in case of interruption and/or prevent write before read conflicts, in other embodiments, other techniques may be used additionally or alternatively.
  • another technique which may increase reliability of the update process and/or prevent write before read conflicts is the storing of data in the update package which itself is stored in non-volatile memory 310, for example in file system 322.
  • 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 update process if there is an interruption which erases volatile memory. It should be understood that the storage in backup buffer 324 and/or in the update package is not required by all embodiments of the invention.
  • boot loader 348 loads the updated software for non-paged core 366 from section 318 in non-volatile memory 310 to volatile memory 350 and invokes the updated non-paged core 366.
  • the updated non-paged core (whose software was loaded in stage 458 or whose software was already in volatile memory 350 prior to stage 458) then starts the normal mode of operation of the updatable device as is known in the art. Method 400 then ends.
  • an update process is considered “reliable”, provided that the 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. It will now be shown how the update process described herein can be resumed in case of interruption.
  • method 400 may be restarted from the beginning. If instead there is an interruption which erases volatile memory 350 subsequent to the completion of stage 406 but prior to the completion of the storage of a backup of the updated software for at least part of the non-paged core (for example the UAL) to section 323 in stage 430, then in one embodiment upon resumption, method 400 may be re-executed beginning with stage 408 or beginning with any stage of method 400 earlier than stage 408.
  • method 400 may be re-executed beginning with stage 432 or beginning with any stage of method 400 earlier than stage 432. If there is instead an interruption which erases volatile memory subsequent to the completion of stage 456, then in one embodiment upon resumption either normal mode may be started or normal mode may be continued with the updated version.
  • Figures 5A , 5B show a flowchart of a method 500 for resuming the in-place update process after an interruption which occurred during stage 456 when only part of the original content to be updated had been overwritten in non-volatile memory 310.
  • 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 assumes that the interruption erased volatile memory 350 and occurred during stage 456 when non-volatile memory 310 includes both original content which still requires update and updated content.
  • the resume point is determined in stage 502 as is known in the art.
  • the resume point may be determined for example as in US Published Application Number 20050216530 to Meller et al. .
  • boot loader 348 loads the updated software for the non-paged core 366 from non-volatile memory 310, for example from section 318, to volatile memory 350.
  • boot loader 348 invokes updated non-paged core 366.
  • updated UA 368 invokes updated UAL 370 to begin updating in-place the software for the paged core (and any other content in non-volatile memory 310 that still requires updating), at least from the resume point, where the in-place updating that is performed may use any appropriate in-place updating techniques as discussed above with reference to stage 456.
  • the invention does not preclude the possibility of rewriting such content during stage 510.
  • flag 332 is set to normal mode by updated UA 368. Updated non-paged core 366 then starts the normal mode of operation of the updatable device as is known in the art. Method 500 then ends.
  • boot loader 348 loads the backed-up updated software for UAL 362 (including the updated version of the software for UPI 364) from non-volatile memory 310 (for example from section 323) into volatile memory 350.
  • boot loader 348 invokes updated UAL 362. Assuming that boot loader 348 has the conventional capability to read from backup buffer 324, boot loader 348 provides to invoked updated UAL 362 the capability of reading non-paged core update package 360 from backup buffer 324.
  • the updated version of software for the non-paged core may be loaded or constructed. Assuming first that non-paged core update package 360 (stored for example in backup buffer 324) includes an updated version (yes to stage 520), then in stage 522, updated UAL 362 loads the updated software for the non-paged core from non-paged core update package 360 (stored for example in backup buffer 324) to volatile memory 350.
  • updated UAL 362 calls updated UPI 364.
  • updated UPI 364 asks updated UAL 362 for input.
  • updated UAL 362 reads from the resume point the stored original version of the software for the non-paged core from non-volatile memory 310, for example from section 318.
  • updated UAL 362 reads the delta for the software for the non-paged core from non-paged core update package 360 stored for example in backup buffer 324.
  • updated UPI 364 constructs in volatile memory 350 an updated version of the software for the non-paged core from the resume point, using the read delta from the interrupted instruction and the original version of the non-paged core from the resume point.
  • updated UAL 362 loads the updated software for the non-paged core except for the updated software for the UAL from non-paged core update package 360 in backup buffer 324 to volatile memory 350.
  • updated UAL 362 reads from the resume point the stored original version of the software for the non-paged core (except for the original version of the software for the UAL) from section 318, reads in stage 532 the delta for the software for the non-paged core except for the delta for the software for the UAL from non-paged core update package 360 stored in backup buffer 324, and in stage 534 UPI 364 constructs in volatile memory 350 an updated version of the software for the non-paged core (excluding the updated UAL) from the resume point, using the read delta from the interrupted instruction and the original version of the software for the non-paged core (excluding the UAL) from the resume point.
  • the backed-up updated software for UAL 362 which was loaded for example from backup buffer 323 into volatile memory 350
  • updated UAL 362 may instead respectively read the delta in stage 532 or load the updated version in stage 522 of the software for the non-paged core from update package 334 stored in file system 322, and the decision of stage 520 would relate in these alternative embodiments to whether or not the updated software for the non-paged core is in update package 334.
  • stages 404 and 406 were omitted because boot loader 348 has the capability of accessing file system 322 and can provide the capability to invoked updated UAL 362 and there was therefore no separate backing up of a non-paged core update package.
  • stages 516 to 534 may be omitted.
  • boot loader 354 loads the backed up updated software for the non-paged core from non-volatile memory 310 (for example from backup buffer 323) to volatile memory 350 after a yes to stage 504 and before stage 540.
  • boot loader 348 invokes the updated non-paged core whose software has come to be located in volatile memory 350 due to any of the various embodiments described above. It is noted that the updated non-paged core includes inter-alia an updated UA and an updated UAL (which includes an updated UPI).
  • the updated UA and the updated UAL update in-place, software content for the non-paged core at least from the resume point and then software content for the paged core (and any other content in non-volatile memory 310 that needs to be updated), where the in-place updating that is performed may use any appropriate in-place updating techniques as discussed above with reference to stage 456 of method 400.
  • the updated software for the non-paged core in volatile memory 350 is first copied by the updated UA to section 318 of non-volatile memory 310, beginning at least with the resume point.
  • the updated UA invokes the updated UAL to construct or load updated software content for the paged core (and any other content in non-volatile memory 310 that needs to be updated) in volatile memory 350 and write the updated content in-place to section 320 and to any other relevant section of non-volatile memory 310.
  • the updated UA invokes the updated UAL to construct and/or or load in volatile memory 350 software content for the non-paged core, paged core, and any other content in non-volatile memory 310 that needs to be updated, and to write the updated content in-place, where for the non-paged core the in-place updating is at least from the resume point.
  • stage 544 after the completion of the update process, flag 332 is set to normal mode by updated UA 368.
  • boot loader 348 loads the updated software for non-paged core 366 from section 318 in non-volatile memory 310 to volatile memory 350 and invokes the updated non-paged core 366.
  • the updated non-paged core (whose software was loaded in stage 544 or was already in volatile memory 350 prior to stage 544) then starts the normal mode of operation of the updatable device as is known in the art. Method 500 then ends.
  • stage 456 it is assumed that in stage 456 the original version of the software for paged core 336 in non-volatile memory 310 , for example in section 320 (and any other content in non-volatile memory that requires to be updated and is not part of the software for the core) is overwritten with the updated version before the original version of the software for non-paged core 366 in non-volatile memory 310, for example in section 318, is overwritten with the updated version.
  • stages 516 to 544 are performed, and therefore stages 504 to 512 may be omitted.
  • the updated UA and the updated UAL update in-place in stage 542 software content for the paged core (and any other content in non-volatile memory 310 that needs to be updated) at least from the resume point and then software content for the non-paged core, where the in-place updating that is performed may use any appropriate in-place updating techniques as discussed above with reference to stage 456 of method 400.
  • the updated UA invokes the updated UAL to construct or load software for the paged core (and any other non-core content in non-volatile memory 310 that needs to be updated) and to write the updated content in-place to non-volatile memory 310 at least from the resume point.
  • the updated UA then copies the updated non-paged core in volatile memory 350 to section 318 of non-volatile memory 310, or the updated UA invokes the updated UAL to construct or load updated software content for the non-paged core and to write the updated content in-place to section 318.
  • the updated UA and the updated UAL update in-place, software content for the non-paged core may use any appropriate in-place updating techniques as discussed above with reference to stage 456 of method 400.
  • the updated UA copies the updated non-paged core in volatile memory 350 to section 318 of non-volatile memory 310 (at least from the resume point), or the updated UA invokes the updated UAL to construct or load updated software content for the non-paged core and to write the updated content in-place (at least from the resume point) to section 318.
  • boot loader 348 loads the software for updated non-paged core 366 from non-volatile memory 310, for example from section 318, to volatile memory 350 and invokes the updated non-paged core 366.
  • the updated non-paged core (whose software was loaded in stage 544 or already in volatile memory 350 prior to stage 544) starts the normal mode of operation of the updatable device as is known in the art. Method 500 then ends.
  • the software for the paged core when loading into or constructing in volatile memory 350 software for the paged core, is typically although not necessarily not all loaded into and/or constructed in volatile memory 350 at one time due to the large size thereof.
  • 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.

Claims (10)

  1. Procédé (400) de mise à jour sur place d'une version initiale de contenu en une version mise à jour de contenu, dans un dispositif de stockage en mémoire non volatile (310), dans lequel le dispositif de stockage en mémoire non volatile (310) comprend une section non paginée (318) stockant un logiciel pour un noyau non paginé (366), dans lequel ledit logiciel pour un noyau non paginé (366) fait partie de ladite version initiale de contenu et comprend des procédures définissant des tâches requises à la fois pendant un processus de mise à jour et pendant un ou plusieurs processus non liés au processus de mise à jour et à une bibliothèque de mise à jour initiale (370), et dans lequel le logiciel pour un noyau non paginé (366) peut être chargé dans son intégralité à partir du dispositif de stockage en mémoire non volatile (310) dans une mémoire volatile (350), le dispositif de stockage en mémoire non volatile (310) pouvant être utilisé dans un mode de fonctionnement normal ou dans un mode de fonctionnement de mise à jour, le procédé comprenant :
    - dans le mode de fonctionnement normal :
    le chargement (402) du logiciel pour un noyau non paginé (366) dans la mémoire volatile (350) et l'appel du logiciel pour un noyau non paginé (366),
    l'obtention (404) d'un paquet de mise à jour (334) nécessaire à la mise à jour de la version initiale de contenu vers la version de contenu mise à jour ;
    l'obtention (410 ; 412-422) d'une nouvelle bibliothèque de mise à jour (362) ;
    le stockage (430) de la nouvelle bibliothèque de mise à jour (362) dans une seconde section (323) dudit dispositif de stockage en mémoire non volatile (310) ; et
    - dans le mode de mise à jour :
    la fourniture d'une version mise à jour du logiciel pour un noyau non paginé (366) dans la mémoire volatile (350), qui comprend le chargement (436) dans la mémoire volatile (350) de la nouvelle bibliothèque de mise à jour (362) et l'appel(438) de ladite nouvelle bibliothèque de mise à jour (362), dans lequel ladite nouvelle bibliothèque de mise à jour appelée (362) construit (444-452) dans une mémoire volatile (350) ou charge dans une mémoire volatile (350) une version mise à jour dudit logiciel pour un noyau non paginé (366) l'utilisation du paquet de mise à jour (334), et
    la mise à jour sur place (456), par la nouvelle bibliothèque de mise à jour (362), de la version initiale de contenu vers la version mise à jour de contenu, dans le dispositif de stockage en mémoire non volatile (310).
  2. Procédé selon la revendication 1, dans lequel l'obtention de la nouvelle bibliothèque de mise à jour (362) comprend l'extraction (410) de la nouvelle bibliothèque de mise à jour (362) du paquet de mise à jour (334 ; 360).
  3. Procédé selon la revendication 1, dans lequel l'obtention d'une nouvelle bibliothèque de mise à jour comprend :
    la dérivation (420) du paquet de mise à jour (334 ; 360), d'une partie requise pour au moins mettre à jour la bibliothèque de mise à jour initiale (370) vers la nouvelle bibliothèque de mise à jour (362) ;
    le stockage de la partie du paquet de mise à jour sur un troisième stockage non volatile ; et
    la génération (422) de la nouvelle bibliothèque de mise à jour (362) en utilisant la bibliothèque de mise à jour initiale (370) et la partie du paquet de mise à jour (334 ; 360) à partir du troisième stockage non volatile.
  4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel la mise à jour comprend en outre l'appel de la version mise à jour du logiciel pour un noyau non paginé (366) dans la mémoire volatile (350).
  5. Procédé selon la revendication 1, dans lequel ladite nouvelle bibliothèque de mise à jour appelée (362) construit dans la mémoire volatile (350) ou charge dans la mémoire volatile (350) une version mise à jour du logiciel pour un noyau non paginé (366) excluant ladite nouvelle bibliothèque de mise à jour (362).
  6. Système (300) pour mettre à jour sur place une version initiale de contenu vers une version mise à jour de contenu, dans un dispositif de stockage en mémoire non volatile (310) pouvant être utilisé dans un mode de fonctionnement normal et dans un mode de fonctionnement de mise à jour, le système comprenant :
    une section de mémoire non paginée (318) sur le dispositif de stockage en mémoire non volatile (310), dans lequel le logiciel pour un noyau non paginé (366) fait partie de ladite version initiale de contenu et comprend des procédures définissant des tâches requises à la fois pendant un processus de mise à jour et pendant un ou plusieurs processus non liés au processus de mise à jour et une bibliothèque de mise à jour (370) et un agent de mise à jour (368) ;
    une mémoire volatile (350), dans laquelle le logiciel pour un noyau non paginé (366) peut être chargé dans son intégralité du dispositif de stockage en mémoire non volatile (310) à la mémoire volatile (350) ; et
    un chargeur de démarrage (348),
    dans lequel, dans le mode de fonctionnement normal, l'agent de mise à jour (368) est conçu pour :
    charger (402) le logiciel pour un noyau non paginé (366) dans la mémoire volatile (350) et appeler le logiciel pour un noyau non paginé (366),
    obtenir (404) un paquet de mise à jour (334) nécessaire à la mise à jour de la version initiale de contenu vers la version de contenu mise à jour ;
    obtenir (410 ; 412-422) une nouvelle bibliothèque de mise à jour (362) ;
    stocker (430) la nouvelle bibliothèque de mise à jour (362) dans une seconde section (323) dudit dispositif de stockage en mémoire non volatile (310) ; et
    dans lequel, dans le mode de fonctionnement de mise à jour, la nouvelle bibliothèque de mise à jour (362) est conçue pour :
    fournir une version mise à jour du logiciel pour un noyau non paginé (366) dans la mémoire volatile (350), qui comprend le chargement du chargeur de démarrage (436), dans la mémoire volatile (350) la nouvelle bibliothèque de mise à jour (362) et le chargeur de démarrage appelant (438) ladite nouvelle bibliothèque de mise à jour (362), dans lequel ladite nouvelle bibliothèque de mise à jour (362) appelée construit (444-452) dans une mémoire volatile (350) ou charge à dans une mémoire volatile (350) une version mise à jour dudit logiciel pour un noyau non paginé (366) utilisant le paquet de mise à jour (334),
    et
    mettre à jour sur place (456) la version initiale de contenu vers la version mise à jour de contenu, dans le dispositif de stockage en mémoire non volatile (310).
  7. Système selon la revendication 6, dans lequel l'agent de mise à jour (368) est conçu pour obtenir une nouvelle bibliothèque de mise à jour (362) par l'extraction de la nouvelle bibliothèque de mise à jour à partir du paquet de mise à jour (334, 360).
  8. Système selon la revendication 6, dans lequel dans l'obtention de la nouvelle bibliothèque de mise à jour (362), l'agent de mise à jour (368) est en outre conçu pour :
    dériver du paquet de mise à jour (334, 360), une partie requise pour au moins mettre à jour la bibliothèque de mise à jour initiale (370) vers la nouvelle bibliothèque de mise à jour (362) ;
    stocker la partie du paquet de mise à jour sur un troisième stockage non volatile ; et
    générer la nouvelle bibliothèque de mise à jour (362) en utilisant la bibliothèque de mise à jour initiale (370) et la partie du paquet de mise à jour du troisième stockage non volatile.
  9. Système selon l'une quelconque des revendications 6 à 8, étant conçu de sorte que la mise à jour comprend en outre l'appel de la version mise à jour du logiciel pour un noyau non paginé (366) dans la mémoire volatile (350).
  10. Système selon l'une quelconque des revendications 6 à 9, étant conçu de sorte que ladite nouvelle bibliothèque de mise à jour appelée (362), construit dans la mémoire volatile (350) ou charge dans la mémoire volatile (350) une version mise à jour du logiciel pour un noyau non paginé (366) excluant ladite nouvelle bibliothèque de mise à jour (362).
EP09787508.2A 2008-08-04 2009-08-04 Mise à jour de contenu sans utiliser de mini-système d'exploitation Active EP2329368B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US8587708P 2008-08-04 2008-08-04
PCT/IL2009/000762 WO2010016062A2 (fr) 2008-08-04 2009-08-04 Mise à jour de contenu sans utiliser de mini-système d'exploitation

Publications (2)

Publication Number Publication Date
EP2329368A2 EP2329368A2 (fr) 2011-06-08
EP2329368B1 true EP2329368B1 (fr) 2019-10-02

Family

ID=41521009

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09787508.2A Active EP2329368B1 (fr) 2008-08-04 2009-08-04 Mise à jour de contenu sans utiliser de mini-système d'exploitation

Country Status (3)

Country Link
US (1) US8689209B2 (fr)
EP (1) EP2329368B1 (fr)
WO (1) WO2010016062A2 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8595716B2 (en) * 2011-04-06 2013-11-26 Robert Bosch Gmbh Failsafe firmware updates
CN103457905B (zh) * 2012-05-28 2015-09-09 腾讯科技（深圳）有限公司 数据同步方法、系统及设备
CN102880495A (zh) * 2012-10-15 2013-01-16 华为终端有限公司 移动终端及其软件升级方法
JP6403463B2 (ja) * 2014-07-07 2018-10-10 キヤノン株式会社 画像形成装置および画像形成装置の制御方法
US11580221B2 (en) * 2016-12-29 2023-02-14 Dropbox, Inc. Malware detection and content item recovery
US10496398B2 (en) * 2017-07-25 2019-12-03 Aurora Labs Ltd. Hot updates to ECU software using tool chain
US10606585B1 (en) * 2019-11-12 2020-03-31 Capital One Services, Llc Computer-based systems configured for automated roll-forward of software package versions and methods of use thereof
JP2023068538A (ja) * 2021-11-02 2023-05-17 キヤノン株式会社 情報処理装置及びその制御方法、並びにプログラム

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
CA2423175A1 (fr) * 2000-09-22 2002-03-28 Patchlink.Com Corporation Systeme et procede d'attribution d'empreintes de retouches et de mise a jour automatique, a distance et sans intervention
US6832373B2 (en) * 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
US8196130B2 (en) * 2000-11-17 2012-06-05 Hewlett-Packard Development Company, L.P. Tri-phase boot process in electronic devices
US20030182414A1 (en) * 2003-05-13 2003-09-25 O'neill Patrick J. System and method for updating and distributing information
JP2003323301A (ja) * 2002-02-27 2003-11-14 Fuji Xerox Co Ltd ソフトウェアをダウンロードする情報処理装置、ダウンロード方法及びダウンロードプログラム
WO2004063899A2 (fr) * 2003-01-13 2004-07-29 Bitfone Corporation Combine mobile ayant la capacite de mettre a jour son agent de mise a jour
AU2004250442B2 (en) 2003-06-23 2010-11-18 Red Bend Ltd. Method and system for updating versions of content stored in a storage device
DE602004028840D1 (de) 2003-07-07 2010-10-07 Red Bend Ltd Verfahren und system zum aktualisieren von versionen von in einer speichereinrichtung gespeichertem inhalt
US7546594B2 (en) * 2003-12-15 2009-06-09 Microsoft Corporation System and method for updating installation components using an installation component delta patch in a networked environment
WO2005088449A1 (fr) * 2004-03-15 2005-09-22 Red Bend Ltd. Procede et appareil de mise a jour fiable d'une version de contenu stockee
US20050257206A1 (en) * 2004-05-14 2005-11-17 Semerdzhiev Krasimir P Pair-update mechanism for update module
US8561049B2 (en) 2005-08-23 2013-10-15 Red Bend Ltd. Method and system for updating content stored in a storage device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
US8689209B2 (en) 2014-04-01
WO2010016062A2 (fr) 2010-02-11
US20100031246A1 (en) 2010-02-04
EP2329368A2 (fr) 2011-06-08
WO2010016062A3 (fr) 2010-05-14

Similar Documents

Publication Publication Date Title
EP2329368B1 (fr) Mise à jour de contenu sans utiliser de mini-système d'exploitation
US8176009B2 (en) Performing a pre-update on a non volatile memory
JP4901095B2 (ja) 不揮発性ストレージにカスタム・ソフトウェア・イメージ・アップデートを適用するフェイルセーフな方法
US8418167B2 (en) Methods and systems for updating content including a compressed version
EP1769343B1 (fr) Procede et systeme destines a une mise a jour <i>in situ</i> de contenu stocke dans un dispositif de stockage
US8561049B2 (en) Method and system for updating content stored in a storage device
US20080196019A1 (en) Method and Apparatus for Generating an Update Package
US20080104441A1 (en) Data processing system and method
JP2013520744A (ja) 最小ブートイメージの生成方法及びその装置
US9043680B2 (en) Method and system for in-place updating content stored in a storage device
WO2019182796A1 (fr) États de récupération configurables
EP2329367B1 (fr) Exécution d'une mise à jour sur place d'un dispositif de stockage en fonctionnement
US8578359B2 (en) Method and apparatus for reliable in-place update
US20080172584A1 (en) Method and system for in-place updating content stored in a storage device
US7222338B2 (en) Method for upgrading data
EP3769225A1 (fr) Passage en espace libre
WO2001050261A2 (fr) Mise a jour d'une memoire non volatile dans un systeme de traitement de donnees
KR100928713B1 (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: NOAM, YAIR

Inventor name: MELLER, EVYATAR

17Q First examination report despatched

Effective date: 20130129

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

D11X Information provided on other rights and legal means of execution (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602009060013

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G06F0009445000

Ipc: G06F0008654000

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 8/654 20180101AFI20190208BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIN1 Information on inventor provided before grant (corrected)

Inventor name: MELLER, EVYATAR

Inventor name: NOAM, YAIR

INTG Intention to grant announced

Effective date: 20190325

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

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

Ref country code: AT

Ref legal event code: REF

Ref document number: 1186940

Country of ref document: AT

Kind code of ref document: T

Effective date: 20191015

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602009060013

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20191002

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1186940

Country of ref document: AT

Kind code of ref document: T

Effective date: 20191002

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: 20191002

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: 20191002

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: 20191002

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: 20191002

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: 20200102

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: 20191002

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: 20200203

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: 20200102

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: 20200103

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: 20191002

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: 20191002

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: 20191002

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

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: 20191002

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: 20191002

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: 20200224

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602009060013

Country of ref document: DE

PG2D Information on lapse in contracting state deleted

Ref country code: IS

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

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: 20191002

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: 20191002

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: 20191002

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: 20200202

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: 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: 20191002

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: 20191002

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: 20191002

26N No opposition filed

Effective date: 20200703

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: 20191002

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: 20191002

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: 20200831

Ref country code: LI

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

Effective date: 20200831

Ref country code: LU

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

Effective date: 20200804

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20200831

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

Ref country code: FR

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

Effective date: 20200831

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 NON-PAYMENT OF DUE FEES

Effective date: 20200831

Ref country code: IE

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

Effective date: 20200804

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

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: 20191002

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: 20191002

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: 20191002

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: 20191002

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: GB

Payment date: 20230720

Year of fee payment: 15

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

Ref country code: DE

Payment date: 20230720

Year of fee payment: 15