DE69905158T2

DE69905158T2 - Inkrementales aktualisieren

Info

Publication number: DE69905158T2
Application number: DE69905158T
Authority: DE
Inventors: S. Nachenberg; E. Sobel
Original assignee: Symantec Corp
Current assignee: Gen Digital Inc
Priority date: 1998-06-03
Filing date: 1999-06-02
Publication date: 2003-07-17
Anticipated expiration: 2019-06-03
Also published as: CA2334004A1; DE69905158D1; CA2334004C; US6167407A; EP1082651A2; WO1999063432A3; EP1082651B1; WO1999063432A2

Description

Die vorliegende Erfindung betrifft das Gebiet des Updatens von Software. Insbesondere betrifft die vorliegende Erfindung ein System und ein Verfahren zum Verwenden einer Archivversion einer Datei zum Vereinfachen des Updatens.
Manche Hersteller von Computer-Software aktualisieren ihre Softwareanwendungen (Computerprogramme und Datendateien für die Programme) regelmäßig. Diese Updates fügen oft neue Eigenschaften zu den Anwendungen hinzu und beseitigen vorhandene Fehler. Zum Updaten von Softwareanwendungen werden meist bestimmte Verfahren angewendet. Das einfachste Verfahren umfaßt das Ausgeben einer kompletten neuen Softwareanwendung, die die ältere Anwendung ersetzt. Dieses Methode des vollen Updatens ist einfach, aber aufwendig und unpraktisch. In der Regel wird die Software auf einem entfernbaren Medium unter die Leute gebracht, etwa auf Disketten oder CD-ROMs, die in der Herstellung und im Vertrieb teuer sind. Der Endnutzer muß auf die Ankunft des entfernbaren Mediums warten, und das Installieren der Softwareanwendung auf einem Computersystem erfordert wieder Zeit. Diese Unannehmlichkeiten häufen sich, wenn häufig Updates herausgegeben werden.
Wegen des großen Umfangs von vielen Softwareanwendungen ist es im allgemeinen nicht möglich, volle Updates über Computernetzwerke wie das Internet zu verteilen. Wenn volle Updates von größeren Anwendungen über ein Netzwerk verteilt werden, belasten sie die Server oft so stark, daß andere Nutzer auf dem Netzwerk das Nachsehen haben, und die Server haben Schwierigkeiten, mit den Anforderungen fertig zu werden.
Um die Probleme zu umgehen, die mit dieser Art des Software-Updatens verbunden sind, geben einige Hersteller von Software inkrementale Updates heraus. Diese inkrementalen Updates enthalten nicht die ganze Softwareanwendung, sondern nur die Informationen, die erforderlich sind, eine bestimmte Version einer Softwareanwendung in eine neuere Version zu überführen. Das Wort "Version" umfaßt hier eine Datei oder eine Anwendung in einem bestimmten Zustand. Eines der möglichen Verfahren, die für eine solche inkrementale Software-Aktualisierung zur Verfügung stehen, ist das binäre Korrigieren, das von Programmen wie RTPatch von Pocket Soft, Inc. ausgeführt wird. Beim binären Korrigieren werden diejenigen binären Bit einer computerlesbaren Datei verändert, die in einer neueren Version anders sind. Eine binäre Korrektur erfordert außer der alten Datei eine Datendatei, in der die Unterschiede zwischen den beiden Versionen enthalten sind. Da die meisten Software-Updates nur Änderungen an einem kleinen Teil der Softwareanwendung umfassen, sind die inkrementalen Updatedateien im allgemeinen klein. Die kleinen Datendateien, die bei einem binären inkrementalen Korrektur-Update ausgegeben werden, umfassen oft weniger als 1% der Größe eines vollen Updates, wobei vorteilhaft vom erheblichen Umfang der Redundanzen in den beiden Versionen Gebrauch gemacht wird.
Die Verwendung von inkrementalen Updates ermöglicht kleinere Updates, die über Einrichtungen ausgegeben werden können, die nicht für die Verteilung von vollen Updates geeignet sind, etwa über das Internet. Die kleineren inkrementalen Updates ermöglichen auch eine Ausgabe auf Disketten, wobei, wenn ein volles Update viele Disketten erfordern würde, das inkrementale Update meist mit einer Diskette auskommt.
Die Verfahren zum inkrementalen Updaten führen jedoch wiederum zu anderen Problemen: Ein inkrementales Update dient eigentlich nur zum Überführen einer bestimmten Version einer Softwareanwendung in eine andere bestimmte Version. Wenn oft Updates durchzuführen sind, wie bei Virenschutz-Softwareanwendungen, möchten Endnutzer oft eine beliebig alte Version in die neueste Version überführen, wobei mehrere früher ausgegebene Versionen übersprungen werden sollen. Ein inkrementales Update für die neueste Version einer Softwareanwendung aktualisiert im allgemeinen jedoch nur die unmittelbar vorhergehende Version. Um von einer beliebig alten Version mit inkrementalen Updates zu der neuesten Version zu gelangen, muß der Nutzer deshalb eine ganze Anzahl von aufeinanderfolgenden inkrementalen Updates erwerben und ausführen.
Eine Lösung dieses Problems ist es, wenn Hersteller von Software eine Anzahl von inkrementalen Update-Dateien in einer einzigen Gruppe ausgeben. Um die neueste Version zu erhalten, werden nacheinander alle erforderlichen inkrementalen Updates ausgeführt. Die Anzahl von inkrementalen Updates kann jedoch, da eine solche Gruppierung im allgemeinen eine große Anzahl von möglichen Versionen abdeckt, groß werden. Der Nutzen der kleinen Update-Dateien verschwindet mit dem Anwachsen der zusammengruppierten inkrementalen Updates. Das Verringern der Anzahl von zur Verfügung stehenden Update-Dateien erhöht die Anzahl von Daten, die der durchschnittliche Nutzer für ein Update erwerben muß, da der Nutzer wahrscheinlich nicht alle inkrementalen Updates in einer Gruppe benötigt. Das Updaten von Anwendungen kann auch mühsam werden, wenn aus den Gruppen eine Reihe von inkrementalen Updates auszuwählen ist, die dann nacheinander auf die Softwareanwendung angewendet werden.
Eine andere Lösung des Problems der vielen inkrementalen Versionen ist es, viele einzelne inkrementale Updates zu erzeugen, die jeweils eine andere frühere Version in die neueste Version überführen. Der Nutzer benötigt dann nur noch eine Version des inkrementalen Updates. Bei häufigen Updates führt diese Vorgehensweise jedoch zu einer großen Anzahl von Dateien für die inkrementalen Updates, die zu erstellen, zu speichern und für den Nutzer bereitzuhalten sind. Bei Herstellern etwa von Virenschutz-Software, die ihre Anwendungen manchmal täglich aktualisieren, kann dies schnell zu untragbaren Zuständen führen. Die Anzahl von Dateien, die bei dieser Vorgehensweise zur Verfügung stehen müssen, wächst dabei schnell an und macht das Überspielen von inkrementalen Updates auf einem lokalen Server fast unmöglich. Wenn ein Hersteller von Virenschutz- Software täglich Dateien mit neuen Virendefinitionen herausgibt, entstehen jedes Jahr etwa 365 Dateien für inkrementale Updates.
Eine Alternative zu den beschriebenen Verfahren ist die "Push"-Technologie, bei der auf dem Server Daten über die von den einzelnen Nutzern benutzten Versionen liegen. Der Server sendet dann, wenn neue Updates zur Verfügung stehen, die erforderlichen Updates zu den einzelnen Nutzern. Bei diesem System sind "intelligente" Server erforderlich, die die Konfigurationen der einzelnen Nutzer überwachen, um feststellen zu können, was jeder Nutzer benötigt, und um dann die geeigneten Updateinformationen auszugeben. Das Ergebnis ist ein Server-intensives System, das die Server-Ressourcen auf eine Weise beanspruchen kann, die mit der Vorgehensweise beim vollen Updaten vergleichbar ist, wenn viele Nutzer gleichzeitig volle Updates anfordern. Vorzugsweise werden jedoch Systeme verwendet, bei denen die Update-Dateien auf "dummen" Servern gespeichert werden, die lediglich die jeweils angeforderten Dateien abgeben.
Was benötigt wird, ist ein System zum Updaten von Softwareanwendungen von einer beliebigen ersten Version auf eine neuere Version, ohne daß eine große Menge an Informationen am Update-Server zu speichern und aufrechtzuerhalten ist, ohne daß ein Nutzer bei jedem Update eine große Menge an Daten erwerben muß, und ohne daß die Verwendung von "intelligenten" Servern erforderlich ist.
Die Aspekte der vorliegenden Erfindung sind in den anhängenden unabhängigen Patentansprüchen genannt.
Eine Ausführungsform der vorliegenden Erfindung macht von einer "zentralen" Version einer Datei Gebrauch, um das Updaten zu erleichtern. Die Zentralversion wird lokal zu der zu aktualisierenden Version gespeichert. Bei einer Ausführungsform der vorliegenden Erfindung wird einer Zentralversion wenigstens eine aus einer Abfolge (100) von Versionen einer computerlesbaren Datei zugeordnet. An einem Server (200) werden inkrementale Zentral-Updates (110) zum Updaten von früher veröffentlichen Zentralversionen auf die neueste veröffentlichte Zentralversion zur Verfügung gestellt. Auf dem Server (200) wird zum Aktualisieren der zuletzt veröffentlichten Zentralversion auf die gegenwärtige Version ein inkrementales End-Update (112) zur Verfügung gestellt. Mit den beiden inkrementalen Updates (110, 112) kann eine früher veröffentliche Zentralversion zur Erzeugung einer Datei der gegenwärtigen Version verwendet werden. Das erste inkrementale Update (110) wird dazu verwendet (316), die letzte Zentralversion zu erstellen, und das zweite inkrementale Update (112) wird dazu verwendet (322), die gegenwärtige Version zu erstellen.
Bei der Ausführung dieser Aktualisierung wird eine Zwischenversion der Datei, die letzte Zentralversion, erzeugt (316). Die Datei der letzten Zentralversion wird lokal nach dem Erstellen (322) der gegenwärtigen Version gespeichert (324). Die gegenwärtige Version wird als aktive Version benutzt (208), während die letzte Zentralversion eine Archivversion ist (206). Wenn das nächste Mal ein Update ausgeführt wird, wird die Archivversion (206) mit nur den beiden neuen inkrementalen Update-Dateien (110, 112) dazu benutzt, eine Aktualisierung auf die neue gegenwärtige Version zu erhalten. Wenn es nur wenige Zentralversionen gibt, ist die Anzahl von erforderlichen inkrementalen Update- Korrekturen klein. Wenn zum Beispiel ein Hersteller von Virenschutz-Software täglich neue Dateien zur Virendefinition herausgibt, kann er diejenigen Versionen, die jeweils auf den Ersten jedes Monats treffen, als Zentralversionen bezeichnen. Die inkrementalen Updates eines Jahres können dann auf dem Server (200) des Herausgebers in der Form von dreizehn inkrementalen Zentral-Updates (110) und einem inkrementalen End-Update (112) gespeichert werden. Im Gegensatz zu dem Fall, bei dem eine große Anzahl von inkrementalen Updates zusammengefaßt wird, um die Anzahl der Dateien zu verringern, ist jedes der inkrementalen Zentral-Updates (110) und das inkrementale End-Update (112) so klein wie jedes andere inkrementale Update.
Bei einer anderen Ausführungsform der vorliegenden Erfindung werden lokal anstelle der vollen Arichvversion (206) nur die Unterschiede zwischen der aktiven Version (208) und der Archivversion (206) gespeichert. Vor einem Update werden diese Informationen mit der aktiven Version (208) der Datei dazu verwendet, die Archivversion (206) zu erstellen. Diese erzeugte Archivversion (206) wird dann wie oben beschrieben beim Updaten verwendet.
Bei einer anderen Ausführungsform der vorliegenden Erfindung ist die einzige Zentralversion in der Abfolge der Versionen die Ausgangsversion. Diese Ausgangsversion wird lokal zu Updatezwecken für alle Zeiten gespeichert. Wenn ein Update auf eine neue Version der Datei erfolgen soll, ist nur ein inkrementales End-Update (112) erforderlich, das die gegenwärtige Version aus der Anfangsversion aufbaut. Auf diese Weise kann ein Hersteller ein Update dadurch allgemein für die Nutzer von vielen verschiedenen Versionen zur Verfügung stellen, daß er ein einziges inkrementales End-Update (112) herausgibt.
Jeder Nutzer, auch wenn er eine aktive Version (208) verwendet, die neuer ist als die Ausgangsversion, besitzt eine lokale Kopie der Ausgangsversion (206).

KURZBESCHREIBUNG DER ZEICHNUNGEN

Die Fig. 1 ist eine Darstellung einer Abfolge 100 von Dateiversionen und der inkrementalen Updates 110, 112 zu deren Umwandlung.
Die Fig. 2 ist eine Darstellung einer Ausführungsform der vorliegenden Erfindung.
Die Fig. 3 ist ein Flußdiagramm für die Arbeitsweise einer Ausführungsform der vorliegenden Erfindung.

GENAUE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN

In der Fig. 1 ist eine Abfolge 100 von Zuständen 1.0 bis 3.2 einer computerlesbaren Datei gezeigt. Jeder numerierte Zustand entspricht gegenüber Zuständen mit niedrigeren numerischen Bezeichnungen einem späteren Zustand der Datei. Diejenigen Versionen mit numerischen Bezeichnungen, die mit ".0" enden, entsprechen Zentralversionen. Bei einer Ausführungsform sind die Zentralversionen Hauptversionen, und die nicht zentralen Versionen sind untergeordnete Versionen. Die Bezeichnung der Zentralversionen braucht jedoch nicht auf einer solchen Unterscheidung zu beruhen. Bei der gezeigten beispielhaften Ausführungsform ist die computerlesbare Datei eine Datei zur Virendefinition, die von einem Virenerfassungsprogramm verwendet wird. Die Bezeichnung computerlesbare Datei umfaßt hier eine oder mehrere zusammengehörende Dateien. Eine computerlesbare Datei kann eine ausführbare Datei, eine Graphikdatei, eine Audiodatei, eine Datendatei, eine vollständige Softwareanwendung mit Dateien verschiedener Typen und jede andere Art von computerlesbarer Datei sein, auf die von einem Computer zugegriffen werden kann und die von einem Computer aktualisiert werden kann.
In der Fig. 1 werden zwei inkrementale Zentraldateien 110 dazu verwendet, eine Zentralversion aus einer früheren Zentralversion zu erstellen. Das eine inkrementale Zentral-Update 110 verbindet den Zustand 1.0 mit dem Zustand 3.0, und das andere verbindet den Zustand 2.0 mit dem Zustand 3.0. Das inkrementale Zentral-Update 110, das die Zustände 1.0 und 3.0 verbindet, ist eine inkrementale Update-Datei, die dazu verwendet wird, aus der Version 1.0 der Datei die Version 3.0 zu erstellen. Das inkrementale End- Update 112 ist eine inkrementale Updatedatei, die dazu verwendet werden kann, die neueste Version (in diesem Fall 3.2) aus der letzten Zentralversion (in diesem Fall 3.0) zu erstellen.
Der lokale Computer 204 der Fig. 2 enthält zwei Versionen der computerlesbaren Datei. Die aktive Datei 208 ist die neueste Version, die auf dem Computer 204 zur Verfügung steht, sie wird von einem Virenscannerprogramm verwendet. Die Archivdatei 206 entspricht dem Zentralzustand 1.0, der in der Abfolge 100 dem Zustand 1.1 vorangeht, der der aktiven Datei 208 entspricht. Bei der beispielhaften Ausführungsform der vorliegenden Erfindung ist die Archivdatei 206 die letzte Zentralversion, die in der Abfolge 100 nicht später liegt wie die aktive Datei 208. Wenn die aktive Datei 208 eine Zentralversion ist, wird dadurch eine Redundanz vermieden, daß nur eine Version der Datei auf dem Computer 204 gespeichert wird, da in diesem Fall die Archivdatei 206 und die aktive Datei 208 identisch sind. Die Archivdatei 206, die eine ältere Version ist, wird außer in Verbindung mit dem Updaten auf dem Computer 204 nicht verwendet.
Der Updater 210, ein lokales Programm auf dem Computer 204, wird zum Updaten der aktiven Datei 208 und der Archivdatei 206 verwendet. Mit einem inkrementalen Update kann der Updater 210 aus einer älteren Version eine aktualisierte Version erstellen. Die inkrementalen Updatedateien 110 und 112 und der Updater 210 können unter Verwendung eines herkömmlichen inkrementalen Updatesystems wie der binären Korrektur ausgeführt werden.
Bei anderen Ausführungsformen der vorliegenden Erfindung wird die Archivdatei 206 auf dem Computer 204 in komprimierter Form gespeichert. Diese komprimierte Form kann jede der herkömmlichen Formen einer komprimierten Datei sein. Bei einer Ausführungsform wird die Archivdatei 206 auf dem Computer 204 in der Form einer Datei gespeichert, die die binären Unterschiede zwischen der unkomprimierten Archivdatei 206 und der aktiven Datei 208 angibt. Wenn die Archivdatei 206 in komprimierter Form gespeichert wird, wird sie vor der Verwendung zum Updaten entpackt.
Ein Hersteller von Software stellt auf dem Server 200 mehrere inkrementale Zentral-Updates 110 und ein inkrementales End-Update 112 zur Verfügung. Der Server 200 gibt in Reaktion auf eine Anforderung für die Datei eine inkrementale Update-Datei an den lokalen Computer 204 ab. Der Server 200 kann ein Dateiserver auf einem lokalen Netzwerk (LAN), ein Dateiserver auf einem Großbereichs-Netzwerk (WAN), ein FTP- Server (File Transfer Protocol), ein HTTP-Server (Hypertext Transfer Protocol) oder ein NNTP-Server (Network News Transfer Protocol) sein. Außerdem kann der Server 200 ein entfernbares magnetisches oder optisches Speichermedium oder eine andere Art von Speichervorrichtung sein, die in der Lage ist, in Reaktion auf die Anforderung von computerlesbaren Dateien solche Dateien an den lokalen Computer 204 abzugeben. Die minimalen Anforderungen an den Server 200 ermöglichen die Verwendung von herkömmlichen, billigen und einfachen Servern.
Anhand der Fig. 3 wird die Arbeitsweise einer beispielhaften Ausführungsform beschrieben. Zuerst wird die zu aktualisierende aktive Datei 208 in 300 als Original_ Zustand ausgewählt. Dann wird die neueste Version, die auf dem Server 200 zur Verfügung steht, in 302 vom Updater 210 als End_Zustand identifiziert. Die letzte, lokal zur Verfügung stehende Zentralversion wird in 304 als die Original Zentralversion bezeichnet. Dies ist in der Regel die Archivdatei 206. Wenn die aktive Datei 208 eine Zentralversion ist, ist die Original_Zentralversion der Original_Zustand. Dann wird in 306 die neueste Zentralversion, die auf dem Server 200 zur Verfügung steht, vom Updater 210 als End_ Zentralversion bezeichnet. In der Regel steht in der Abfolge der Zustände die End_Zentralversion vor dem End_Zustand. Wenn der End_Zustand ein Zentralzustand ist, sind sie jedoch gleich.
Vom Updater 210 wird dann in 312 ein Test ausgeführt, um festzustellen, ob die Original_Zentralversion und die End_Zentralversion dem gleichen Zustand entsprechen. Wenn ja, ist kein Aktualisieren der Zentralversion erforderlich. Anderenfalls ist ein Zentral-Updaten erforderlich, und vom Server 200 wird in 314 ein inkrementales Zentral- Update 110 abgerufen. Das abgerufene inkrementale Zentral-Update 110 ist ein inkrementales Update für die Überführung der Datei von der Original_Zentralversion in den End Zentralzustand. Das inkrementale Zentral-Update 110 kann über ein Netzwerk heruntergeladen werden, oder es wird von einem entfernbaren Medium wie einer magnetischen oder optischen Platte abgelesen. Das inkrementale Zentral-Update 110 wird vom Updater 210 dazu verwendet, in 316 die Archivdatei 206 aus dem Original_Zentralzustand in den End_Zentralzustand überzuführen.
Nach dem Erstellen einer Datei des End_Zentralzustands auf dem lokalen Computer 204 wird in 318 ein Test vom Updater 210 ausgeführt, um festzustellen, ob der End_Zentralzustand gleich dem End Zustand ist. Wenn ja, ist kein weiteres Updaten erforderlich, um die Version des End Zustands zu erhalten. Anderenfalls wird in 320 vom Server 200 das inkrementale End-Update 112 heruntergeladen. Das inkrementale End- Update 112 ist das inkrementale Update, das dazu verwendet wird, eine Datei vom End_Zentralzustand in den End_Zustand überzuführen. Nach dem Herunterladen wird das inkrementale End-Update 112 vom Updater 210 in 322 dazu verwendet, aus dem End_Zentralzustand den End_Zustand zu erzeugen. Die End_Zentralversion wird in 324 auf dem lokalen Computer 204 gespeichert, nachdem der End_Zustand erzeugt wurde. Wenn das vom Updater 210 angewendete Aktualisierungsschema von der Art ist, bei dem die zu aktualisierende Datei durch eine neue ersetzt wird, ist es erforderlich, vor dem Anwenden des inkrementalen End-Updates 112 darauf eine Kopie des End_Zentralzustandes zu erzeugen. Wenn das Updaten beendet ist, ist die End_Zentralversion die Archivdatei 206, und die End_Zustandsversion ist die aktive Datei 208.
Wegen der Klarheit wurde bei der oben beschriebenen beispielhaften Ausführungsform der End Zustand und der End_Zentralzustand vom Updater 210 explizit identifiziert. In einer bevorzugten Ausführungsform ist auf dem Server 200 jedes inkrementale Zentral-Update 110 mit dem inkrementalen End-Update 112 zusammengepackt. Dieses Paket wird als dem Original Zentralzustand entsprechend identifiziert, auf den das enthaltene inkrementale Zentral-Update 110 angewendet wird. Anstatt festzustellen, was der End_Zentralzustand und der End_Zustand sind, fordert der Updater 210 das als Original_Zentralzustand identifizierte Paket an, extrahiert die enthaltenen inkrementalen Updates und wendet sie auf den Original Zentralzustand an. Wenn der Original_Zentralzustand der gleiche ist wie der End_Zentralzustand, enthält das Paket kein inkrementales Zentral- Update 110, und wenn der End_Zentralzustand der End_Zustand ist, ist kein inkrementales End-Update 112 enthalten. In dieser Ausführungsform stellt der Updater 210 nicht explizit fest, ob der Original Zentralzustand der gleiche ist wie der End_Zentralzustand und ob der End Zentralzustand der gleiche ist wie der End_Zustand. Es braucht somit ganz einfach nur eine Datei heruntergeladen zu werden, und die Kommunikation zwischen dem Updater 210 und dem Server 200 wird auf einem Minimum gehalten. Geeignete Verfahren zum Zusammenpacken der Dateien sind bekannt, sie umfassen auch das Java-Archiv-(JAR)- Plattform-unabhängige Dateiformat von Sun Microsystems.
Durch das Erhöhen der Menge an lokal gespeicherten Informationen ermöglicht die vorliegende Erfindung das Updaten mit einer kleineren Anzahl von inkrementalen Updates, die von einem einfachen Server heruntergeladen werden können, wobei es nicht erforderlich ist, daß eine große Anzahl von inkrementalen Updatedateien auf dem Server gespeichert ist. Ein solches System führt von selbst zum Spiegeln, bei dem die inkrementalen Updatedateien, die für ein Update erforderlich sind, auf Servern gespeichert sind, die nicht vom Hersteller kontrolliert werden. Zum Beispiel kann eine Firma lokal die Dateien speichern, die zum Unterstützen eines häufigen Updatens einer bestimmten Anwendung erforderlich sind. Die Angestellen der Firma können über ein LAN auf die Dateien zugreifen, um das Updaten auszuführen. Dies ist bei den herkömmlichen Systemen schwierig, da entweder die Firma eine sehr große Anzahl von Dateien speichern muß oder die Menge an Informationen, die über das LAN zu senden sind, um das Updaten zu unterstützen, sehr groß ist. Der Nachteil, der für die geringere Menge an Informationen, die über das Netzwerk zu senden sind, und für die geringere Menge an Informationen zu zahlen ist, die auf dem Update-Server gespeichert sind, ist, daß auf den lokalen Computern der Nutzer eine größere Informationsmenge zu speichern ist. Dieser Nachteil ist jedoch im allgemeinen annehmbar, da Massenspeicher wenig kosten, und da auf jedem lokalen Computer nur eine Archivversion der Anwendung zu speichern ist.
Die obige Beschreibung soll die Arbeitsweise von beispielhaften Ausführungsformen illustrieren und nicht den Umfang der Erfindung einschränken. Der Umfang der Erfindung wird nur durch die folgenden Patentansprüche eingeschränkt.

Claims

1. Verfahren zum vereinfachten Updaten einer computerlesbaren Datei (208) aus einem ursprünglichen Zustand (1.1) auf einen Endzustand (3.2), wobei sich die Datei im ursprünglichen Zustand auf einem lokalen Computersystem (204) befinden und der ursprüngliche Zustand und der Endzustand Zustände innerhalb einer geordneten Abfolge (100) von der Datei entsprechenden Zuständen (1.0 bis 3.2) sind, wobei in der Abfolge der Endzustand später liegt als der ursprüngliche Zustand und die Abfolge mindestens einen Zentralzustand (1.0, 2.0, 3.0) aufweist, und wobei die Verfahrensschritte auf einem Servercomputer durchgeführt werden und folgende Schritte umfassen:

Bereitstellen eines Satzes von inkrementalen Updates und Auswählen eines oder mehrerer inkrementaler Updates entsprechend dem ursprünglichen Zustand und Übertragen der Updates als eine Gruppe von einem oder mehreren inkrementalen Updates an das lokale Computersystem, wobei das lokale Computersystem die Datei in den Endzustand updated;

dadurch gekennzeichnet, daß

ein Zentralzustand als End-Zentralzustand (3.0) bestimmt wird, der mindestens genauso früh in der Abfolge wie der Endzustand liegt;

ein Zentralzustand als ursprünglicher Zentralzustand bestimmt wird, wenn er mindestens genauso früh in der Abfolge liegt wie der ursprüngliche Zustand;

in Reaktion darauf, daß der ursprüngliche Zentralzustand nicht der End- Zentralzustand ist, ein inkrementales Zentral-Update bereitgestellt wird, das dafür vorgesehen ist, eine Datei aus dem ursprünglichen Zentralzustand in den End-Zentralzustand zu überführen; und daß

in Reaktion darauf, daß der End-Zentralzustand nicht der Endzustand ist, ein inkrementales End-Update bereitgestellt wird, das dafür vorgesehen ist, eine Datei aus dem End-Zentralzustand in den Endzustand 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) umfaßt, der kein Zentralzustand ist.

3. Verfahren nach Anspruch 1, wobei beim Bereitstellen eines inkrementalen End-Updates für jedes inkrementale Zentral-Update ein Paket bereitgestellt wird, das das inkrementale Zentral-Update und das inkrementale End-Update umfaßt.

4. Verfahren nach Anspruch 1, wobei beim Bestimmen des End-Zentralzustandes der letzte Zentralzustand ausgewählt wird, dem der Endzustand in der Abfolge nicht vorausgeht.

5. 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 inkrementalen Zentral-Updates das inkrementale Zentral-Update auf einen Servercomputer (200) gelegt wird, und wobei beim Bereitstellen des inkrementalen End-Updates das inkrementale End- Update auf den Servercomputer gelegt wird.

7. Verfahren nach Anspruch 1, wobei beim Bereitstellen des inkrementalen Zentral-Updates das inkrementale Zentral-Update auf einem entfernbaren computerlesbaren Speichermedium gespeichert wird, und wobei beim Bereitstellen des inkrementalen End- Updates das inkrementale End-Update auf einem entfernbaren computerlesbaren Speichermedium gespeichert wird.

8. Verfahren nach Anspruch 6, wobei der Servercomputer eine Anfrage von einem lokalen Computersystem (204) aufnimmt, in dem eine aktive Datei (208) in einem ursprünglichen Zustand und eine Archivdatei (206) in einem dem ursprünglichen Zentralzustand entsprechenden Zustand vorhanden sind, wobei die Anfrage den ursprünglichen Zustand identifiziert und ein Update auf den Endzustand anfordert; wobei das Verfahren des weiteren umfaßt, daß der Servercomputer eine Antwort an das lokale Computersystem übermittelt, die eine Gruppe von einem oder mehreren inkrementalen Updates zum Updaten der aktiven Datei und der Archivdatei enthält.

9. Verfahren nach Anspruch 1, mit folgenden weiteren Schritten, die auf dem lokalen Computersystem ausgeführt werden:

Abrufen (300, 302) einer Datei (206) in einem ursprünglichen Zentralzustand aus einem lokalen Speicherplatz, wobei der ursprüngliche Zentralzustand der Zentralzustand in der Abfolge ist, dem der ursprünglicher Zustand in der Abfolge nicht vorangeht;

und in Reaktion darauf, daß der ursprüngliche Zentralzustand nicht der End- Zentralzustand ist:

Abrufen eines inkrementalen Zentral-Updates (210), das Informationen über Unterschiede zwischen dem ursprünglichen Zentralzustand und dem End-Zentralzustand aufweist;

Benutzen des inkrementalen Zentral-Updates und der Datei im ursprünglichen Zentralzustand, um eine Datei im End-Zentralzustand zu erzeugen (316); und

Speichern (324) der Datei im End-Zentralzustand; und

in Reaktion darauf, daß der End-Zentralzustand nicht der Endzustand ist:

Abrufen eines inkrementalen End-Updates, das Informationen über die Unterschiede zwischen dem End-Zentralzustand und dem Endzustand enthält;

Benutzen des inkrementalen End-Updates und der Datei im End-Zentralzustand, um eine Datei im Endzustand zu erzeugen (322); und

Speichern (324) der Datei im Endzustand.

10. Verfahren nach Anspruch 9, wobei die Abfolge mindestens einen Zustand umfaßt, der kein Zentralzustand ist.

11. Verfahren nach Anspruch 9, wobei das inkrementale Zentral-Update und das inkrementale End-Update in einem Paket enthalten sind, und wobei der Zwischenschritt des Abrufens des inkrementalen Zentral-Updates und der Zwischenschritt des Abrufens des inkrementalen End-Updates dadurch durchgeführt werden, daß das Paket abgerufen wird.

12. Verfahren nach Anspruch 9, wobei sich der lokale Speicherort in einem lokalen Computersystems befindet.

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 inkrementalen Zentral-Updates umfaßt, daß das inkrementale Zentral-Update über ein Computernetzwerk abgerufen wird, und wobei der Zwischenschritt des Abrufens eines inkrementalen End-Updates umfaßt, daß das inkrementale End-Update über ein Computernetzwerk abgerufen wird.

15. Verfahren nach Anspruch 9, wobei der ursprüngliche Zentralzustand der letzte Zentralzustand ist, dem der ursprüngliche Zustand in der Abfolge nicht vorangeht.

16. Verfahren nach Anspruch 9, wobei der End-Zentralzustand der letzte Zentralzustand ist, dem der Endzustand in der Abfolge nicht vorangeht.

17. Verfahren nach Anspruch 9, wobei der Zwischenschritt des Speicherns der Datei im End-Zentralzustand umfaßt, daß die Datei im ursprünglichen Zentralzustand am lokalen Speicherort durch die Datei im End-Zentralzustand 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 End-Zentralzustand umfaßt, daß die Datei im End-Zentralzustand in einer komprimierten Form gespeichert wird.

20. Verfahren nach Anspruch 9, wobei nur ein Zentralzustand in der Abfolge existiert, dem der ursprüngliche Zustand in der Abfolge nicht vorangeht.

21. System mit einem Servercomputer (200) und einem lokalen Computersystem (204), das mit dem Servercomputer verbunden ist, wobei der Servercomputer Vorrichtungen zum vereinfachten Updaten einer computerlesbaren Datei (208) aus einem ursprünglichen Zustand (1.1) auf einen Endzustand (3.2) aufweist, wobei sich die Datei im ursprünglichen Zustand auf dem lokalen Computersystem (204) befindet, wobei der ursprüngliche Zustand und der Endzustand Zustände innerhalb einer geordneten Abfolge (100) von der Datei entsprechenden Zuständen sind, wobei in der Abfolge der Endzustand später liegt als der ursprünglichen Zustand und die Abfolge mindestens einen Zentralzustand (1.0, 2.0, 3.0) umfaßt, wobei der Servercomputer derart betreibbar ist, daß eine Gruppe von inkrementalen Updates bereitstellbar ist und ein oder mehrere inkrementale Updates entsprechend dem ursprünglichen Zustand auswählbar sind und die Updates als eine Gruppe von einem oder mehren inkrementalen Updates an das lokale Computersystem übertragbar sind, wodurch das lokale Computersystem die Dateien auf den Endzustand updaten kann, dadurch gekennzeichnet, daß die Abfolge einen End-Zentralzustand (3.0) aufweist, der ein Zentralzustand ist, der in der Abfolge mindestens genauso früh wie der Endzustand liegt und einen ursprünglichen Zentralzustand umfaßt, der ein Zentralzustand ist, der in der Abfolge mindestens genauso früh liegt wie der ursprüngliche Zustand, und daß das System umfaßt:

eine inkrementale Zentral-Updatevorrichtung (110), die dafür vorgesehen ist, eine Datei im ursprünglichen Zentralzustand in den End-Zentralzustand zu überführen, wenn der ursprüngliche Zentralzustand nicht der End-Zentralzustand ist; und

eine inkrementale End-Updatevorrichtung (112), die dafür vorgesehen ist, eine Datei im End-Zentralzustand in den Endzustand zu überführen, wenn der End-Zentralzustand nicht der Endzustand ist; und daß

der Servercomputer Zugang zu allen inkrementalen Zentral-Updates und dem inkrementalen End-Update aufweist und in Reaktion auf eine Anforderung des lokalen Computersystems nach inkrementalen Updates das inkrementale End-Update und das inkrementale Zentral-Update an das lokale Computersystem übergibt.

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 inkrementalen Updates;

Vorrichtungen zum Aufnehmen einer Anforderung von dem lokalen Computersystem nach ein Update einer Datei in einem ursprünglichen Zustand;

Vorrichtungen zum Auswählen einer Gruppe von einer oder mehreren inkrementalen Updates entsprechend dem ursprünglichen Zustand der Datei; und mit

Vorrichtungen zum Übermitteln des inkrementalen End-Updates und eines inkrementalen Zentral-Updates an das lokale Computersystem.

24. Lokales Computersystem (204) für das System nach einem der Ansprüche 21 bis 23, mit

einer Vorrichtung zum Zugriff auf eine Datei im ursprünglichen Zentralzustand an einem lokalen Speicherort, wobei der ursprüngliche Zentralzustand ein Zentralzustand in der Abfolge ist, der in der Abfolge mindestens genauso früh liegt wie der ursprüngliche Zustand;

einer Vorrichtung, die, wenn der ursprüngliche Zentralzustand nicht der End- Zentralzustand ist, ausgelegt ist zum:

Abrufen eines inkrementalen Zentral-Updates mit Informationen über Unterschiede zwischen dem ursprünglichen Zentralzustand und dem End-Zentralzustand;

Benutzen des inkrementalen Zentral-Updates und der Datei im ursprünglichen Zentralzustand, um eine Datei im End-Zentralzustand zu erzeugen; und

Speichern der Datei im End-Zentralzustand; und mit

einer Vorrichtung, die, wenn der End-Zentralzustand nicht der Endzustand ist, ausgelegt ist zum:

Abrufen eines inkrementalen End-Updates mit Informationen über Unterschiede zwischen dem End-Zentralzustand und dem Endzustand;

Benutzen des inkrementalen End-Updates und der Datei im End- Zentralzustand, um eine Datei im Endzustand zu erzeugen; und

Speichern der Datei im Endzustand.

25. Computerlesbares Medium mit einem Computerprogramm, das dazu ausgelegt ist, ein oder mehrere Computer anzuweisen, alle Verfahrensschritte von einem der Ansprüche 1 bis 20 auszuführen.

26. Computerlesbares Medium mit Daten, die ein inkrementales Zentral-Update und ein inkrementales End-Update definieren, die in dem Verfahren von Anspruch 7 verwendet werden.