(51) Int Cl. 7 : G06F 9/44. (86) International application number: PCT/US99/ (56) References cited: EP-A

Transkript

1 (19) Europäisches Patentamt European Patent Office Office européen des brevets *EP008261B1* (11) EP B1 (12) EUROPEAN PATENT SPECIFICATION (4) Date of publication and mention of the grant of the patent: Bulletin 03/0 (21) Application number: (22) Date of filing: (1) Int Cl. 7 : G06F 9/44 (86) International application number: PCT/US99/12228 (87) International publication number: WO 99/ ( Gazette 1999/49) (4) INCREMENTAL UPDATING INKREMENTALES AKTUALISIEREN MISE A JOUR INCREMENTIELLE (84) Designated Contracting States: DE FR GB () Priority: US 899 (43) Date of publication of application: Bulletin 01/11 (73) Proprietor: SYMANTEC CORPORATION Cupertino, CA 9014 (US) (72) Inventors: NACHENBERG, Carey, S. Northridge, CA (US) SOBEL, William, E. Stevenson Ranch, CA (US) (74) Representative: Beresford, Keith Denis Lewis et al 2- Warwick Court High Holborn London WC1R DH (GB) (6) References cited: EP-A "USER-FRIENDLY INTERFACE FOR APPLYING SPECIFIC LEVELS OF COORDINATED UPDATES TO SOFTWARE IN THE FIELD" IBM TECHNICAL DISCLOSURE BULLETIN,US,IBM CORP. NEW YORK, vol. 31, no., page XP ISSN: EP B1 Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention). Printed by Jouve, 7001 PARIS (FR)

2 1 EP B1 2 Description [0001] This invention pertains to the field of software updating. More specifically, this invention pertains to a system and method for using an archival version of a file to facilitate updating. [0002] Some computer software publishers update their software applications (computer programs and data files associated with the programs) frequently. These updates often add new features to the applications as well as remove existing bugs. Several methods are commonly used to update software applications. The simplest of these is to distribute one entire software application to replace an older one. This full update method is simple, but expensive and inconvenient. Typically the software is distributed on some type of removable media, such as floppy disks or CD-ROM's, which are costly to produce and distribute. The time an end user must wait for the removable medium to arrive and the time it takes for the software application to install itself on a computer system are inconvenient. This inconvenience is compounded where updates occur frequently. [0003] Because of the large size of many software applications it is generally not feasible to distribute full updates over computer networks, such as the Internet. When full updates of larger applications are distributed over a network, they often cause such high loads on servers that other users suffer slow-downs on the network, and the servers have trouble meeting the demands. [0004] In order to bypass many of the problems associated with this type of software updating, some software publishers distribute incremental updates. These incremental updates do not contain entire software applications, but rather they contain that information which is necessary to transform a particular version of a software application to a newer version. As used herein, the word "version" indicates a file or application of a specified state. Among the methods available to perform such incremental software updating is binary patching, performed by programs such as RTPatch, published by Pocket Soft, Inc. A binary patcher changes those binary bits of a computer readable file which are different in a newer version. A binary patcher needs, in addition to the old file, a data file which includes the differences between the two versions. Because most software updates involve changes to only a small portion of a software application, incremental update files are generally small. The smaller data files distributed for a binary patch incremental update are often less than 1% of the size of a full update, taking advantage of the large amount of redundancy in the two versions. [000] The use of incremental update methods allows for smaller updates which can be distributed by means which are not conducive to the distribution of full updates, such as distribution over the Internet. The smaller incremental updates also make distribution by floppy disk more feasible where a full update would have required many disks, and an incremental update may require only one. [0006] However, incremental update methods introduce another problem: an incremental update is specifically useful for updating only one particular version of a software application to another particular version. When updates occur frequently, as with virus protection software applications, end users may update from an arbitrarily old version to the newest version, skipping over several previously released versions. An incremental update for the newest version of a software application will generally update only from the most recent version, however. To update from an arbitrarily old version to the most recent version with incremental updates, a user often needs to acquire and apply a number of successive incremental updates. [0007] One solution to this problem has been for software publishers to group a number of incremental update files together into one distribution. Each necessary incremental update is applied, one at a time, to update to the newest version. However, the number of incremental updates may be large, due to the fact that a grouping generally covers a large number of possible versions. The benefits of smaller distributed update files begin to disappear, as the size of the grouped-together incremental updates grows. Lowering the number of update files available increases the amount of data the average user must acquire for an update, since the user will not need all of the incremental updates in a grouping. This method of updating applications can also be cumbersome, as a series of incremental updates needs to be selected from the group and applied to the software application one after another. [0008] Another solution to the problem of incremental update version-specificity has been to create many unique incremental update files which each transform a different previous version to the most current version. Then, only one incremental update is needed by any user. However, where updates are very frequent, this scheme results in a large number of incremental update files to produce, store and maintain for users. In the case of publishers, such as virus-protection software publishers, who might update their applications as often as daily, this can quickly become untenable. The number of files which must be made available with this scheme grows quickly, and makes the mirroring of incremental updates on a local server almost impossible. For example, in a case where a virus protection software publisher makes new virus definition files available daily, each year's worth of updates will require approximately 36 incremental update files. [0009] One alternative to the methods described above is the use of"push" technology, in which a server maintains a database of what version each user has. The server then sends the necessary updates to each user, as they become available. This system requires "smart" servers, however, to monitor user configurations, to determine what each user needs, and to send 2

3 3 EP B1 4 the appropriate update information. This results in a server-intensive system which can cause a drain on server resources comparable to that experienced in the full update scheme, when many users are simultaneously requesting full updates. It is preferable to use a system which allows update files to be stored on a "dumb" server which simply provides specifically requested files. [00] What is needed is a system for updating software applications from an arbitrary first version to a newer version without requiring a large amount of information to be stored and maintained by an update server, without requiring a user to acquire a large amount of data to perform each update, and without requiring the use of "smart" servers. [0011] Aspects of the present invention are set out in the appended independent claims. [0012] An embodiment of the present invention makes use of a "hub" version of a file to facilitate updating. The hub version is stored local to the version being updated. In one embodiment of the present invention, at least one of a sequence (0) of versions of a computer readable file is designated a hub version. Hub incremental updates (1) are made available on a server (0) for updating previously published hub versions to the most recently published hub version. A final incremental update (112) is also made available on the server (0), for updating the most recently published hub version to the current version. A previously published hub version can be used with the two incremental updates (1, 112) to produce a file of the current version. The first incremental update (1) is used (316) to produce the most recent hub version, and the second incremental update (112) is used (322) to produce the current version. [0013] When such an update is carried out, an intermediate version of the file, the most recent hub version, is produced (316). The file of the most recent hub version is retained (324) locally subsequent to the current version being constructed (322). The current version is used as an active version (8), while the most recent hub version is an archive version (6). The next time an update is carried out, the archive (6) version is used with just the two new incremental update files (1, 112) to update to the new current version. If there are few hubs, the number of incremental update patches which must be made available is small. For example, if a virus protection software publisher makes new virus definition files available daily, the publisher may designate as hubs those versions which coincide with the first of each month. Over a year's worth of incremental updates can be stored on the publisher's server (0) in the form of thirteen hub incremental updates (1) and one final incremental update (112). Unlike the case in which large numbers of incremental updates are grouped together to lower the number of files to be maintained, each of the hub incremental updates (1) and the final incremental update (112) can be as small as any other incremental updates. [0014] In another embodiment of the present invention, information about the differences between the active version (8) and the archive version (6) are stored locally instead of the full archive version (6). Before an update takes place, this information is used with the active version (8) of the file to construct the archive version (6). This constructed archive version (6) is then used as above to accomplish the update. [001] In yet another embodiment of the present invention, the only hub version in the sequence of versions is the initial version. This initial version is maintained locally at all times for update purposes. When an update to a new version of the file is to be performed, only a final incremental update (112) which constructs the current version from the initial version is required. In this way a publisher can make an update generally available to users of many different versions by publishing a single final incremental update (112). Each user, although possibly using an active version (8) which is newer than the initial version, has a local copy of the initial version (6) available. BRIEF DESCRIPTION OF THE DRAWINGS [0016] Fig. 1 is an illustration of a sequence 0 of file versions and the incremental updates 1, 112 for transforming them. [0017] Fig. 2 is an illustration of one embodiment of the present invention. [0018] Fig. 3 is a flowchart illustrating the operation of one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0019] Referring now to Fig. 1, a sequence 0 of states of a computer readable file is shown. Each numbered state corresponds to a later state of the file than states with lower numerical designations. Those versions with numerical designations ending in ".0" correspond to hub versions. In one embodiment, hub versions are major versions and non-hub versions are minor versions. The designation of hub versions does not need to be based on any such distinction, however. In the illustrative embodiment, the computer readable file is a virus definition file used by a virus detection program. As used herein, the term computer readable file encompasses one or more associated files. A computer readable file can be an executable file, a graphics file, an audio file, a data file, a complete software application comprising files of different types, or any other type of computer readable file which can be accessed and updated by a computer. [00] In Fig. 1, two hub incremental updates 1 are each used to construct a hub version from an earlier hub version. One hub incremental update 1 connects state 1.0 to state 3.0, and the other connects state 2.0 3

4 EP B1 6 to state 3.0. The hub incremental update 1 shown connecting states 1.0 and 3.0 is an incremental update file which is used to construct a version 3.0 file from a version 1.0 file. Final incremental update 112 is an incremental update file which can be used to construct the most recent version (in this case 3.2) from the most recent hub version (in this case 3.0). [0021] Referring now to Fig. 2, local computer 4 includes two versions of the computer readable file. Active file 8 is the most recent version available on computer 4, and is used by a virus scanner program. Archive file 6 corresponds to a hub state 1.0 preceding, in sequence 0, the state 1.1 corresponding to active file 8. In an exemplary embodiment of the present invention, archive file 6 is the latest hub version which is not later in sequence 0 than active file 8. When active file 8 is a hub version, redundancy is avoided by storing only one version of the file on computer 4, since both archive file 6 and active file 8 are the same file in that case. Archive file 6, being an older version, is generally not used on computer 4, except in conjunction with updating. [0022] Updater 2, a program local to computer 4, is used to update active file 8 and archive file 6. Provided with an incremental update, updater 2 can create an updated version from an older version. Incremental update files 1 and 112, and updater 2, can be implemented using a conventional incremental update system, such as binary patching. [0023] In other embodiments of the present invention, archive file 6 is stored on computer 4 in a compressed form. This compressed form can be any conventional form of file compression. In one embodiment, archive file 6 is stored on computer 4 in the form of a file indicating the binary differences between uncompressed archive file 6 and active file 8. If archive file 6 is stored in compressed form, it is uncompressed prior to being used for updating. [0024] A software publisher makes several hub incremental updates 1 and one final incremental update 112 available on server 0. Server 0 transmits an incremental update file to local computer 4 in response to a request for the file. Server 0 can be a file server on a local area network (LAN), a file server on a wide area network (WAN), an FTP (File Transfer Protocol) server, an HTTP (Hypertext Transfer Protocol) server, or an NNTP (Network News Transfer Protocol) server. Additionally, server 0 can be a removable magnetic or optical storage medium, or any other type of storage device capable of supplying computer readable files to local computer 4 in response to a request for such files. The minimal requirements for server 0 enable conventional, inexpensive dumb servers to be used. [002] The operation of an exemplary embodiment is described with reference to Fig. 3. First, active file 8 to be updated is selected 0 as the Original_State. Then, the most recent version available on server 0 is identified 2 by updater 2 as the Final_State. The most recent locally available hub version is designated 4 the Original_Hub. This is ordinarily archive file 6. Where active file 8 is a hub version, however, Original_Hub will be Original_State. Next, the most recent hub version available on server 0 is identified 6 by updater 2 as the Final_Hub. Ordinarily, the Final_Hub state will precede the Final_State in the sequence of states. Where Final_State is a hub state, however, they will be the same. [0026] A test is performed 312 by updater 2 to determine whether Original_Hub and Final_Hub correspond to the same state. If they do, no hub updating is necessary. Otherwise, hub updating is necessary, and a hub incremental update 1 is retrieved 314 from server 0. The hub incremental update 1 retrieved is an incremental update for use in transforming a file of Original_Hub state to Final_Hub state. Hub incremental update 1 can be downloaded over a network, or it can be read from a removable medium, such as a magnetic or optical disk. Hub incremental update 1 is used by updater 2 to transform 316 archive file 6 from the Original_Hub state to the Final_Hub state. [0027] After producing a file of Final_Hub state on local computer 4, a test is performed 318 by updater 2 to determine whether Final_Hub is the same state as Final_State. If so, no further updating is necessary to obtain the Final_State version. Otherwise final incremental update 112 is retrieved 3 from server 0. Final incremental update 112 is the incremental update which is used to transform a file from Final_Hub state to Final_State. After being retrieved, final incremental update 112 is used by updater 2 to create 322 Final_State from Final_Hub. The Final_Hub version is retained 324 on local computer 4 after Final_State has been produced. If the updating scheme used by updater 2 is one which replaces the file being updated with a new one, then it is necessary to create a copy of Final_Hub prior to applying final incremental update 112 to it. When the updating is completed, the Final_Hub version is archive file 6, and the Final_State version is active file 8. [0028] For clarity, in the exemplary embodiment described above, the Final_State and the Final_Hub state are explicitly identified by updater (2). In a preferred embodiment, each hub incremental update 1 is packaged with final incremental update 112 on server 0. This package is identified as corresponding to the Original_Hub state to which the included hub incremental update 1 applies. Rather than determining what the Final_Hub and Final_State are, updater 2 requests the package identified as being for Original_Hub state, extracts the included incremental updates, and applies them to Original_Hub. If Original_Hub is the same as Final_Hub, the package does not contain a hub incremental update 1, and if the Final_Hub is the Final_State, no final incremental update 112 is included. In this embodiment, updater 2 does not explicitly determine whether Original_Hub is the same as 4

5 7 EP B1 8 Final_Hub, or whether Final_Hub is the same as Final_State. For simplicity, only one file needs to be retrieved, and communication between updater 2 and server 0 is minimized. Suitable methods for packaging the files together are known in the art, and include the Java Archive (JAR) platform-independent file format, available from Sun Microsystems. [0029] By increasing the amount of information stored locally, the present invention permits updating from a small number of incremental updates retrieved from a dumb server without requiring that a large number of incremental update files are stored on the server. Such a system lends itself to mirroring, where the incremental update files necessary for an update are stored on servers other than those controlled by the publisher. For example, a company can maintain locally the files necessary to support frequent updating of a particular application. Employees of the company can access the files through a LAN in order to accomplish updating. This would be difficult with conventional systems, because either the company would need to maintain a very large number of files, or the amount of information sent over the LAN to support updates would be large. The tradeoff for the lower amount of information sent over the network and the lower amount of information stored on the update server is that a larger amount of information is stored on each user's local computer. This trade-off is generally acceptable. since mass storage costs are low and only one archival version of an application must be stored on each local computer. [00] The above description is included to illustrate the operation of exemplary embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. Claims 1. A method for facilitating updating of a computer readable file (8) from an original state (1.1) to a final state (3.2), the file of the original state residing on a local computer system (4), the original state and the final state being states within an ordered sequence (0) of states (1.0 to 3.2) associated with the file, the final state being later in the sequence than the original state and the sequence including at least one hub state (1.0, 2.0, 3.0), the method steps being performed by a server computer and comprising: making available a set of incremental updates and selecting one or more incremental updates according to the original state and communicating the updates as a group of one or more incremental updates to the local computer system whereby the local computer system updates the file to the final state; characterised by determining as a final hub state (3.0) a hub state which is at least as early in the sequence as the final state; determining as an original hub state a hub state which is at least as early in the sequence as the original state; responsive to the original hub state not being the final hub state, making available a hub incremental update (1) adapted to transform a file of the original hub state to the final hub state; and responsive to the final hub state not being the final state, making available a final incremental update (112) adapted to transform a file of the final hub state to the final state. 2. The method of claim 1, wherein the sequence includes at least one state (1.1, 2.1, 2.11, 2.2, 3.1, 3.2) which is not a hub state. 3. The method of claim 1, wherein the step of making available a final incremental update comprises, for each hub incremental update, making available a package including the hub incremental update and the final incremental update. 4. The method of claim 1, wherein the step of determining the final hub state comprises selecting the latest hub state which is not preceded in the sequence by the final state.. The method of claim 1, wherein the sequence of states is a temporal sequence, and each state in the sequence is associated with a position in time. 6. The method of claim 1, wherein the step of making available a hub incremental update comprises putting the hub incremental update on a server computer (0), and the step of making available the final incremental update comprises putting the final incremental update on the server computer. 7. The method of claim 1, wherein the step of making available the hub incremental update comprises storing the hub incremental update on a removable computer readable storage medium and the step of making available the final incremental update comprises storing the final incremental update on the removable computer readable storage medium. 8. A method as claimed in claim 6 comprising said server computer receiving a request from a local computer system (4) in which an active file (8) resides in an original state and an archive file (6) resides in a state corresponding to an original hub state, the request identifying the original state and requesting an update to the final state; the method further comprising said server computer transmit-

6 9 EP B1 ting a response to the local computer system containing a group of one or more incremental updates for use in updating the active file and the archive file. 9. A method as claimed in claim 1 further comprising the method steps performed by the local computer system of: accessing (0,2) from a local storage location a file (6) of an original hub state, the original hub state being a hub state in the sequence which is not preceded in the sequence by the original state; responsive to the original hub state not being the final hub state: 1 incremental update comprises accessing the final incremental update over the computer network. 1. The method of claim 9, wherein the original hub state is the latest hub state which is not preceded in the sequence by the original state. 16. The method of claim 9, wherein the final hub state is the latest hub state which is not preceded in the sequence by the final state. 17. The method of claim 9, wherein the sub-step of storing the file of the final hub state comprises replacing the file of the original hub state in the local storage location with the file of the final hub state. accessing a hub incremental update (2) containing information about differences between the original hub state and the final hub state; using the hub incremental update and the file of the original hub state to produce (316) a file of the final hub state; and storing (324) the file of the final hub state; and responsive to the final hub state not being the final state: The method of claim 9, wherein the sequence of states is a temporal sequence, and each state is associated with a position in time. 19. The method of claim 9, wherein the sub-step of storing the file of the final hub state comprises storing the file of the final hub state in a compressed form.. The method of claim 9, wherein there is only one hub state in the sequence, the hub state not being preceded in the sequence by the original state. accessing a final incremental update containing information about differences between the final hub state and the final state; using the final incremental update and the file of the final hub state to produce (322) a file of the final state; and storing (324) the file of the final state.. The method of claim 9, wherein the sequence includes at least one state which is not a hub state. 11. The method of claim 9, wherein the hub incremental update and the final incremental update are included in a package, and the sub-step of accessing the hub incremental update and the sub-step of accessing the final update are both performed by accessing the package. 12. The method of claim 9, wherein the local storage location is internal to the local computer system. 13. The method of claim 9, wherein the local storage location is a removable computer readable storage medium. 14. The method of claim 9, wherein the sub-step of accessing a hub incremental update comprises accessing the hub incremental update over a computer network, and the sub-step of accessing a final A system comprising a server computer (0) and a local computer system (4) coupled to the server computer, the server computer comprising means for facilitating updating of a computer readable file (8) from an original state (1.1) to a final state (3.2), the file of the original state residing on the local computer system (4), the original state and the final state being states within an ordered sequence (0) of states associated with the file, the final state being later in the sequence than the original state and the sequence including at least one hub state (1.0, 2.0, 3.0), the server computer being operable to make available a group of incremental updates and to select one or more incremental updates according to the original state and to communicate the updates as a group of one or more incremental updates to the local computer system whereby the local computer system is operable to update the file to the final state, characterised by the sequence including a final hub state (3.0) which is a hub state at least as early in the sequence as the final state and including an original hub state which is a hub state at least as early in the sequence as the original state, and by the system comprising: a hub incremental update (1) adapted to transform a file of the original hub state to the final hub state, when the original hubstate is not the final hub state; and a final incremental update (112) adapted to 6

7 11 EP B1 12 transform a file of the final hub state to the final state, when the final hub state is not the final state; the server computer having access to any hub incremental updates and the final incremental update, and being operable in response to a request by the local computer system for incremental updates to transmit the final incremental update and hub incremental update to the local computer system. 22. The system of claim 21, wherein the server is coupled to the local computer system by a computer network. 23. A server computer used in the system as claimed in any of claims 21 to 22, comprising: storing means storing said incremental updates; means for receiving from the local computer system a request for updating a file in an original state; means for selecting a group of one or more incremental updates according to the original state of the file; means for transmitting the final incremental update and incremental hub update to the local computer system. 24. A local computer system (4) used in the system of any of claims 21 to 23, comprising: means for accessing from a local storage location a file of an original hub state, the original hub state being a hub state in the sequence which is at least as early in the sequence as the original state; means operable when the original hub state is not the final hub state: accessing a hub incremental update containing information about differences between the original hub state and the final hub state; using the hub incremental update and the file of the original hub state to produce a file of the final hub state; and storing the file of the final hub state; and means operable when the final hub state is not the final state: accessing a final incremental update containing information about differences between the final hub state and the final state; means for using the final incremental update and the file of the final hub state to produce a file of the final state; and means for storing the file of the final state. 2. A computer readable medium containing a computer program adapted to instruct one or more computers to carry out all of the method steps of any one of claims 1 to. 26. A computer readable medium comprising data defining a hub incremental update and a final incremental update used in the method of claim 7. Patentansprüche 1. Verfahren zum vereinfachten Updaten einer computerlesbaren Datei (8) von einem ursprünglichen Zustand (1.1) zu einem endgültigen Zustand (3.2), wobei die Datei im ursprünglichen Zustand auf einem lokalen Computersystem (4) vorhanden ist, wobei der ursprüngliche Zustand und der endgültige Zustand Zustände innerhalb einer geordneten Abfolge (0) von der Datei entsprechenden Zuständen (1.0 bis 3.2) sind, wobei in der Abfolge der endgültige Zustand später auftaucht als der ursprüngliche Zustand, und die Abfolge mindestens einen Hauptzustand (1.0, 2.0, 3.0) aufweist, wobei die Verfahrensschritte auf einem Servercomputer durchgeführt werden und folgende Schritte umfassen: Bereitstellen eines Satzes von incrementalen Updates und Auswählen eines oder mehrerer incrementaler Updates entsprechend dem ursprünglichen Zustand und Übertragen der Updates als eine Gruppe von einem oder mehreren incrementalen Updates an das lokale Computersystem, wobei das lokale Computersystem die Datei auf den endgültigen Zustand updated; dadurch gekennzeichnet, daß ein Hauptzustand als endgültiger Hauptzustand (3.0) festgelegt wird, der mindestens genauso früh in der Abfolge wie der endgültigen Zustand auftaucht; ein Hauptzustand als ursprünglicher Hauptzustand festgelegt wird, der mindestens genauso früh in der Abfolge auftaucht wie der ursprünglichen Zustand; ansprechend darauf, dass der ursprüngliche Hauptzustand nicht der endgültige Hauptzustand ist, ein incrementales Hauptupdate bereitgestellt wird, das dazu ausgelegt ist, eine Datei von dem ursprünglichen Hauptzustand in den endgültigen Hauptzustand zu überführen; und ansprechend darauf, dass der endgültige 7

8 13 EP B1 14 Hauptzustand nicht der endgültige Zustand ist, ein endgültiges incrementales Update bereitgestellt wird, das dazu ausgelegt ist, eine Datei von dem endgültigen Hauptzustand in den endgültigen Zustand zu überführen. 2. Verfahren nach Anspruch 1, wobei die Abfolge mindestens einen Zustand (1.1, 2.1, 2.11, 2.2, 3.1, 3.2) umfasst, der kein Hauptzustand ist. 3. Verfahren nach Anspruch 1, wobei beim Bereitstellen eines endgültigen incrementalen Updates für jedes incrementale Hauptupdate ein Paket bereitgestellt wird, das das incrementale Hauptupdate und das endgültige incrementale Update umfasst. 4. Verfahren nach Anspruch 1, wobei beim Feststellen des endgültigen Hauptzustandes der letzte Hauptzustand ausgewählt wird, dem der endgültige Zustand in der Abfolge nicht vorausgeht.. Verfahren nach Anspruch 1, wobei die Abfolge von Zuständen eine zeitliche Abfolge ist, und jeder Zustand in der Abfolge mit einer Position in der Zeit assoziiert ist. 6. Verfahren nach Anspruch 1, wobei beim Bereitstellen eines incrementalen Hauptupdates das incrementale Hauptupdate auf einen Servercomputer (0) gelegt wird, und beim Bereitstellens des endgültigen incrementalen Updates das endgültige incrementale Update auf den Servercomputer gelegt wird. 7. Verfahren nach Anspruch 1, wobei beim Bereitstellens des incrementalen Hauptupdates das incrementale Hauptupdate auf einem entfernbaren computer-lesbaren Speichermedium gespeichert wird, und beim Bereitstellen des endgültigen incrementalen Updates das endgültige incrementale Update auf einem entfernbaren computer-lesbaren Speichermedium gespeichert wird Verfahren nach Anspruch 1, folgende weitere Schritte umfassend, die auf einem lokalen Computersystem ausgeführt werden: Abrufen (0, 2) einer Datei (6) in einem ursprünglichen Hauptzustand aus einem lokalen Speicherplatz, wobei der ursprüngliche Hauptzustand der Hauptzustand in der Abfolge ist, dem der ursprünglicher Zustand in der Abfolge nicht vorangeht; ansprechend darauf, dass der ursprüngliche Hauptzustand nicht der endgültigen Hauptzustand ist: Abrufen eines incrementalen Hauptupdates (2), das Informationen über Unterschiede zwischen dem ursprünglichen Hauptzustand und dem endgültigen Hauptzustand aufweist; Benutzen des incrementalen Hauptupdates und der Datei im ursprünglichen Hauptzustand, um eine Datei im endgültigen Hauptzustand zu produzieren (316); und Speichern (324) der Datei im endgültigen Hauptzustand; und ansprechend darauf, dass der endgültige Hauptzustand nicht der endgültige Zustand ist: Abrufen eines endgültigen incrementalen Updates, das Informationen über die Unterschiede zwischen dem endgültigen Hauptzustand und dem endgültigen Zustand aufweist; Benutzen des endgültigen incrementalen Updates und der Datei im endgültigen Hauptzustand, um eine Datei im endgültigen Zustand zu produzieren (322); und Speichern (324) der Datei im endgültigen Zustand. 8. Verfahren nach Anspruch 6, wobei der Servercomputer eine Anfrage von einem lokalen Computersystem (4) empfängt, in welchem eine aktive Datei (8) in einem ursprünglichen Zustand und eine Archiydatei (6) in einem dem ursprünglichen Hauptzustand entsprechenden Zustand vorhanden sind, wobei die Anfrage den ursprünglichen Zustand identifiziert und ein Update auf den endgültigen Zustand beantragt; wobei das Verfahren weiter umfasst, dass der Servercomputer eine Antwort an das lokale Computersystem übermittelt, die eine Gruppe von einem oder mehreren incrementalen Updates zum Updaten der aktiven Datei und der Archivdatei umfasst Verfahren nach Anspruch 9, wobei die Abfolge mindestens einen Zustand umfasst, der kein Hauptzustand ist. 11. Verfahren nach Anspruch 9, wobei das incrementale Hauptupdate und das endgültige incrementale Update in einem Paket beinhaltet sind, und der Zwischenschritt des Abrufens des incrementalen Hauptupdates und der Zwischenschritt des Abrufens des endgültigen incrementalen Updates dadurch durchgeführt werden, dass das Paket abgerufen wird. 12. Verfahren nach Anspruch 9, wobei der lokale Speicherort innerhalb eines lokalen Computersystems 8

9 1 EP B1 16 angeordnet ist. 13. Verfahren nach Anspruch 9, wobei der lokale Speicherort ein entfernbares computerlesbares Speichermedium ist. 14. Verfahren nach Anspruch 9, wobei der Zwischenschritt des Abrufens eines incrementalen Hauptupdates umfasst, dass das incrementale Hauptupdate über ein Computernetzwerk abgerufen wird, und der Zwischenschritt des Abrufens eines endgültigen incrementalen Updates umfasst, dass das endgültige incrementale Update über ein Computernetzwerk abgerufen wird. 1. Verfahren nach Anspruch 9, wobei der ursprüngliche Hauptzustand der letzte Hauptzustand ist, dem der ursprüngliche Zustand in der Abfolge nicht vorangeht. 16. Verfahren nach Anspruch 9, wobei der endgültige Hauptzustand der letzte Hauptzustand ist, dem der endgültige Zustand in der Abfolge nicht vorangeht. 17. Verfahren nach Anspruch 9, wobei der Zwischenschritt des Speicherns der Datei im endgültigen Hauptzustand umfasst, dass die Datei im ursprünglichen Hauptzustand an dem lokalen Speicherort durch die Datei im endgültigen Hauptzustand ersetzt wird. 18. Verfahren nach Anspruch 9, wobei die Abfolge von Zuständen eine zeitliche Abfolge ist, und jeder Zustand mit einer Position in der Zeit assoziiert ist. 19. Verfahren nach Anspruch 9, wobei der Zwischenschritt des Speicherns der Datei im endgültigen Hauptzustand umfasst, dass die Datei im endgültigen Hauptzustand in einer kompressierten Form gespeichert wird.. Verfahren nach Anspruch 9, wobei nur ein Hauptzustand in der Abfolge existiert, dem der ursprüngliche Zustand in der Abfolge nicht vorangeht. 21. System mit einem Servercomputer (0) und einem lokalen Computersystem (4), das mit dem Servercomputer verbunden ist, wobei der Servercomputer Vorrichtungen zum vereinfachten Updaten einer computerlesbaren Datei (8) von einem ursprünglichen Zustand (1.1) zu einem endgültigen Zustand (3.2) aufweist, wobei die Datei im ursprünglichen Zustand auf dem lokalen Computersystem (49 angeordnet ist, wobei der ursprüngliche Zustand und der endgültige Zustand Zustände innerhalb einer geordneten Abfolge (0) von der Datei entsprechenden Zuständen sind, wobei in der Abfolge der endgültige Zustand später auftaucht als der ursprünglichen Zustand und die Abfolge mindestens einen Hauptzustand (1.0, 2.0, 3.0) umfasst, wobei der Servercomputer derart betreibbar ist, dass eine Gruppe von incrementalen Updates bereitstellbar ist und ein oder mehrere incrementale Updates entsprechend dem ursprünglichen Zustand auswählbar sind und die Updates als eine Gruppe von einem oder mehren incrementalen Updates an das lokale Computersystem übertragbar sind, wodurch das lokale Computersystem betreibbar ist, die Dateien auf den endgültigen Zustand upzudaten, dadurch gekennzeichnet, dass die Abfolge einen endgültigen Hauptzustand (3.0), der ein Hauptzustand ist, der in der Abfolge mindestens genauso früh wie der endgültige Zustand auftaucht und einen ursprünglichen Hauptzustand umfasst, der ein Hauptzustand ist, der in der Abfolge mindestens genauso früh auftaucht wie der ursprüngliche Zustand, und dass das System umfasst: eine incrementale Hauptupdatevorrichtung (1), die dazu ausgelegt ist, eine Datei im ursprünglichen Hauptzustand in den endgültigen Hauptzustand zu überführen, wenn der ursprüngliche Hauptzustand nicht der endgültigen Hauptzustand ist; und eine endgültige incrementale Updatevorrichtung (112), die dazu ausgelegt ist, eine Datei im endgültigen Hauptzustand in den endgültigen Zustand zu überführen, wenn der endgültige Hauptzustand nicht der endgültige Zustand ist; und dass der Servercomputer Zugang zu allen incrementalen Hauptupdates und dem endgültigen incrementalen Update aufweist und betreibbar ist, in Antwort auf eine Anfrage des lokalen Computersystems nach incrementalen Updates das endgültige incrementale Update und das incrementale Hauptupdate an das lokale Computersystem zu übersenden. 22. System nach Anspruch 21, wobei der Server mit dem lokalen Computersystem über ein Computernetzwerk gekoppelt ist. 23. Computerserver in einem System nach einem der Ansprüche 21 oder 22, mit: Speichervorrichtungen zum Speichern von incrementalen Updates; Vorrichtungen zum Empfangen einer Anfrage von dem lokalen Computersystem für ein Update einer Datei in einem ursprünglichen Zustand; Vorrichtungen zum Auswählen einer Gruppe 9

10 17 EP B1 18 von einer oder mehreren incrementalen Updates entsprechend dem ursprünglichen Zustand der Datei; Vorrichtungen zum Übermitteln des endgültigen incrementalen Updates und eines incrementalen Hauptupdates an das lokale Computersystem. 24. Lokales Computersystem (4) benutzt in dem System nach einem der Ansprüche 21 bis 23, mit: einer Vorrichtung zum Zugriff auf eine Datei im ursprünglichen Hauptzustand aus einem lokalen Speicherort, wobei der ursprüngliche Hauptzustand ein Hauptzustand in der Abfolge ist, der in der Abfolge mindestens genauso früh auftaucht wie der ursprüngliche Zustand; einer Vorrichtung, die, wenn der ursprüngliche Hauptzustand nicht der endgültige Hauptzustand ist, ausgelegt ist zum: Abrufen eines incrementalen Hauptupdates mit Informationen über Unterschiede zwischen dem ursprünglichen Hauptzustand und dem endgültigen Hauptzustand; Benutzen des incrementalen Hauptupdates und der Datei im ursprünglichen Hauptzustand, um eine Datei im endgültigen Hauptzustand zu produzieren; und Speichern der Datei im endgültigen Hauptzustand; und einer Vorrichtung, die, wenn der endgültige Hauptzustand nicht der endgültigen Zustand ist, ausgelegt ist zum: Abrufen eines endgültigen incrementalen Updates mit Informationen über Unterschiede zwischen dem endgültigen Hauptzustand und dem endgültigen Zustand; Benutzen des endgültigen incrementalen Updates und der Datei im endgültigen Hauptzustand, um eine Datei im endgültigen Zustand zu produzieren; und Speichern der Datei im endgültigen Zustand. 2. Computerlesbares Medium mit einem Computerprogramm, das dazu ausgelegt ist, ein oder mehrere Computer anzuweisen, alle Verfahrensschritte von einem der Ansprüche 1 bis auszuführen. 26. Computerlesbares Medium mit Daten, die ein incrementales Hauptupdate und ein endgültiges incrementales Update definieren, die in dem Verfahren von Anspruch 7 verwendet werden Revendications 1. Procédé pour faciliter la mise à jour d'un fichier lisible par ordinateur (8) d'un état originel (1.1) vers un état final (3.2), le fichier de l'état originel résidant sur un système informatique local (4), l'état originel et l'état final étant des états à l'intérieur d'une séquence ordonnée (0) d'états (1.0 à 3.2) associés au fichier, l'état final étant plus tardif dans la séquence que l'état originel et la séquence incluant au moins un état nodal (1.0, 2.0, 3.0), les étapes du procédé étant exécutées par un serveur et consistant à: rendre disponible un ensemble de mises à jour incrémentielles et sélectionner une ou plusieurs mises à jour incrémentielles selon l'état originel et communiquer les mises à jour sous forme d'un groupe d'une ou plusieurs mises à jour incrémentielles au système informatique local de manière que le système informatique local mette à jour le fichier vers son état final ; caractérisé par le fait que il est déterminé en tant qu'état nodal final (3.0) un état nodal qui est au moins aussi précoce dans la séquence que l'état final ; il est déterminé en tant qu'état nodal originel un état nodal qui est au moins aussi précoce dans la séquence que l'état originel ; en réponse au fait que l'état nodal originel ne soit pas l'état nodal final, il est rendu disponible une mise à jour incrémentielle nodale (1) adaptée pour transformer un fichier de l'état nodal originel en son état nodal final ; et en réponse au fait que l'état nodal final ne soit pas l'état final, il est rendu disponible une mise à jour incrémentielle finale (112) adaptée pour transformer un fichier de l'état nodal final en son état final. 2. Procédé selon la revendication 1, dans lequel la séquence inclut au moins un état (1.1, 2.1,2.11,2.2, 3.1, 3.2) qui n'est pas un état nodal. 3. Procédé selon la revendication 1, dans lequel l'étape consistant à rendre disponible une mise à jour incrémentielle finale comprend, pour chaque mise à jour incrémentielle nodale, la mise à disposition d'un package comportant la mise à jour incrémentielle nodale et la mise à jour incrémentielle finale. 4. Procédé selon la revendication 1, dans lequel l'étape consistant à déterminer l'état nodal final comprend la sélection de l'état nodal le plus récent qui n'est pas précédé dans la séquence par l'état final.. Procédé selon la revendication 1, dans lequel la séquence des états est une séquence temporelle, et

11 19 EP B1 chaque état dans la séquence est associé à une position dans le temps. 6. Procédé selon la revendication 1, dans lequel l'étape consistant à rendre disponible une mise à jour incrémentielle nodale comprend la mise de la mise à jour incrémentielle nodale sur un serveur (0), et l'étape consistant à rendre disponible la mise à jour incrémentielle finale comprend la mise de la mise à jour incrémentielle finale sur le serveur. 7. Procédé selon la revendication 1, dans lequel l'étape consistant à rendre disponible une misé à jour incrémentielle nodale comprend le stockage de la mise à jour incrémentielle nodale sur un médium de stockage amovible lisible par ordinateur et l'étape consistant à rendre disponible une mise à jour incrémentielle finale comprend le stockage de la mise à jour incrémentielle finale sur le médium de stockage amovible lisible par ordinateur. 8. Procédé selon la revendication 6, dans lequel ledit serveur reçoit une requête de la part d'un système informatique local (4) dans lequel un fichier actif (8) réside dans un état originel et un fichier archive (6) réside dans un état correspondant à un état nodal originel, la requête identifiant l'état originel et demandant une mise à jour vers l'état final ; le procédé comprenant de plus le fait que le serveur transmet une réponse au système informatique local contenant un groupe d'une ou plusieurs mises à jour incrémentielles pour une utilisation dans la mise à jour du fichier actif et du fichier archive. 9. Procédé selon la revendication 1 comprenant de plus les étapes exécutées par le système informatique local consistant à : accéder à une mise à jour incrémentielle finale contenant l'information concernant les différences entre l'état nodal final et l'état final ; utiliser la mise à jour incrémentielle finale et le fichier de l'état nodal final pour produire (322) un fichier de l'état final ; et stocker (324) le fichier de l'état final.. Procédé selon la revendication 9, dans lequel la séquence inclut au moins un état qui n'est pas un état nodal. 11. Procédé selon la revendication 9, dans lequel la mise à jour incrémentielle nodale et la mise à jour incrémentielle finale sont incluses dans un package, et la sous-étape d'accès à la mise à jour incrémentielle nodale et la sous-étape d'accès à la mise à jour finale sont toutes deux exécutées en accédant au package. 12. Procédé selon la revendication 9, dans lequel l'emplacement de stockage local est interne au système informatique local. 13. Procédé selon la revendication 9, dans lequel l'emplacement de stockage local est un médium de stockage amovible lisible par ordinateur. 14. Procédé selon la revendication 9, dans lequel la sous-étape d'accès à une mise à jour incrémentielle nodale comprend l'accès à la mise à jour incrémentielle nodale sur un réseau informatique, et la sousétape d'accès à une mise à jour incrémentielle finale comprend l'accès à la mise à jour incrémentielle finale sur le réseau informatique. accéder (0, 2) à partir d'un emplacement de stockage local à un fichier (6) dans un état nodal originel, l'état nodal originel état un état nodal dans la séquence qui n'est pas précédé dans la séquence par l'état originel ; en réponse au fait que l'état nodal originel n'est pas l'état nodal final : 4 1. Procédé selon la revendication 9, dans lequel l'état nodal originel est l'état nodal le plus récent qui n'est pas précédé dans la séquence par l'état originel. 16. Procédé selon la revendication 9, dans lequel l'état nodal final est l'état nodal le plus récent qui n'est pas précédé dans la séquence par l'état final. accéder à une mise à jour incrémentielle nodale (2) contenant l'information concernant les différences entre l'état nodal originel et l'état nodal final ; utiliser la mise à jour incrémentielle nodale et le fichier de l'état nodal originel pour produire (316) un fichier de l'état nodal final ; et stocker (324) le fichier de l'état nodal final ; et en réponse au fait que l'état nodal final n'est pas l'état final : Procédé selon la revendication 9, dans lequel la sous-étape de stockage du fichier de l'état nodal final comprend le remplacement du fichier de l'état nodal originel dans l'emplacement de stockage local par le fichier de l'état nodal final. 18. Procédé selon la revendication 9, dans lequel la séquence d'états est une séquence temporelle, et chaque état est associé à une position dans le temps. 19. Procédé selon la revendication 9, dans lequel la 11

12 21 EP B1 22 sous-étape de stockage du fichier de l'état nodal final comprend le stockage du fichier de l'état nodal final sous une forme compressée.. Procédé selon la revendication 9, dans lequel il n'existe qu'un seul état nodal dans la séquence, l'état nodal n'étant pas précédé dans la séquence par l'état originel. 21. Système comprenant un serveur (0) et un système informatique local (4) couplé au serveur, le serveur comprenant des moyens pour faciliter la mise à jour d'un fichier lisible par ordinateur (8) d'un état originel (1.1) vers un état final (3.2), le fichier de l'état originel résidant sur le système informatique local (4), l'état originel et l'état final étant des états à l'intérieur d'une séquence ordonnée (0) d'états associés au fichier, l'état final étant plus tardif dans la séquence que l'état originel et la séquence incluant au moins un état nodal (1.0, 2.0, 3.0), le serveur pouvant être mis en oeuvre pour rendre disponible un groupe de mises à jour incrémentielles et pour sélectionner une ou plusieurs mises à jour incrémentielles selon l'état originel et pour communiquer les mises à jour sous forme d'un groupe d'une ou plusieurs mises à jour incrémentielles au système informatique local de manière que le système informatique local puisse être mis en oeuvre pour mettre à jour le fichier vers l'état final ; caractérisé par le fait que la séquence inclut un état nodal final (3.0) qui est un état nodal qui est au moins aussi précoce dans la séquence que l'état final et inclut un état nodal originel qui est un état nodal au moins aussi précoce dans la séquence que l'état originel, et par le fait que le système comprend : une mise à jour incrémentielle nodale (1) adaptée pour transformer un fichier de l'état nodal originel en son état nodal final, lorsque l'état nodal originel n'est l'état nodal final ; et une mise à jour incrémentielle finale (112) adaptée pour transformer un fichier de l'état nodal final en l'état final, lorsque l'état nodal final n'est pas l'état final ; le serveur ayant accès à n'importe laquelle des mises à jour incrémentielles nodales et à la mise à jour incrémentielle finale, et pouvant être mis en oeuvre en réponse à une requête émise par le système informatique local pour des mises à jour incrémentielles, pour transmettre la mise à jour incrémentielle finale et la mise à jour incrémentielle nodale au système informatique local. 22. Système selon la revendication 21, dans lequel le serveur est couplé au système informatique local par un réseau informatique Serveur utilisé dans le système selon l'une quelconque des revendications 21 à 22, comprenant : des moyens de stockage pour stocker lesdites mises à jour incrémentielles ; des moyens pour recevoir du système informatique local une requête pour la mise à jour d'un fichier dans un état originel ; des moyens pour sélectionner un groupe d'une ou plusieurs mises à jour incrémentielles selon l'état originel du fichier ; des moyens pour transmettre la mise à jour incrémentielle finale et la mise à jour incrémentielle nodale au système informatique local. 24. Système informatique local (4) utilisé dans le système selon l'une quelconque des revendications 21 à 23, comprenant : des moyens pour accéder a partir d'un emplacement de stockage local à un fichier d'un état nodal originel, l'état nodal originel étant un état dans la séquence qui est au moins aussi précoce dans la séquence que l'état originel ; des moyens pouvant être mis en oeuvre lorsque l'état nodal originel n'est pas l'état nodal final pour : accéder à une mise à jour incrémentielle nodale contenant l'information concernant les différences entre l'état nodal originel et l'état nodal final ; utiliser la mise à jour incrémentielle nodale et le fichier de l'état nodal originel pour produire un fichier de l'état nodal final ;et stocker le fichier de l'état nodal final ; et des moyens pouvant être mis en oeuvre lors que l'état nodal final n'est pas l'état final pour : accéder à une mise à jour incrémentielle finale contenant l'information concernant les différences entre l'état nodal final et l'état final ; des moyens pour utiliser la mise à jour incrémentielle finale et le fichier de l'état nodal final pour produire un fichier de l'état final ; et des moyens pour stocker le fichier de l'état final. 2. Médium lisible par ordinateur contenant un programme informatique adapté pour commander à un ou plusieurs ordinateurs l'exécution de toutes les étapes du procédé selon l'une quelconque des revendications 1 à. 26. Médium lisible par ordinateur comprenant des don- 12

13 23 EP B1 24 nées définissant une mise à jour incrémentielle nodale et une mise à jour incrémentielle finale utilisées dans le procédé selon la revendication

14 EP B1 14

15 EP B1 1