DE69529635T2

DE69529635T2 - Gemeinsame Benutzung eines Dateiedierungssystems mit geheimem Dateiinhalt, Versionsverwaltung und asynchroner Edierung

Info

Publication number: DE69529635T2
Application number: DE69529635T
Authority: DE
Inventors: Masao Murota; Atsushi Shimbo; Toshinari Takahashi; Ichiro Tomoda
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1994-03-15
Filing date: 1995-03-15
Publication date: 2003-10-23
Anticipated expiration: 2015-03-16
Also published as: US5835601A; EP0674253B1; EP1265122A2; EP1265122A3; EP0674253A1; DE69529635D1

Description

HINTERGRUND DER ERFINDUNG

Gebiet der Erfindung

Die vorliegende Erfindung betrifft ein Dateieditiersystem zum Verwirklichen eines asynchronen Editierens einer gemeinsam durch eine Vielzahl von Benutzern genutzten Datei und einen Dateiinhaltleseschutz in einem computerbasierten gemeinsamen Dateisystem oder Datenbanksystem.

Beschreibung des Standes der Technik

Es wurde ausgeführt, dass es in einem Computersystem, um die Zugriffe von einer Vielzahl von Benutzern mit Bezug auf eine Ressource innerhalb des Systems zu handhaben, notwendig ist, einen Authentisierungsmechanismus bereitzustellen, um zu bestätigen, ob ein eine Zugriffsanforderung ausgebender Benutzer ein richtiger Nutzer ist, der ein Zugriffsrecht mit Bezug auf diese Ressource hat oder nicht. Insbesondere in einer Umgebung eines Systems großer Dimensionierung, in dem ein Zugriff von einem fernab befindlichen Nutzer erlaubt ist, wird solch ein Authentisierungsmechanismus sehr wichtig, Ein beispielhaftes bekanntes System zur Realisierung solch eines Authentisierungsmechanismus ist Kerberos.
Ein typisches bekanntes System, das solch einen Authentisierungsmechanismus erfordert, ist das CSCW (Computer Supported Cooperative Work) (computerunterstützte gemeinsame Arbeit). Das CSCW ist ein generischer Name für Computersysteme, die die kooperative Arbeit einer Vielzahl von Nutzern unterstützen, und das gemeinsame Dateisystem (gemeinsam benutztes Dateisystem) ist das grundlegendste und typische Beispiel. In einem gemeinsamen Dateisystem haben eine Vielzahl von Nutzern Zugriffsrechte wie beispielsweise "Lesen" und "Schreiben" mit Bezug auf die identische Datei, und das System kann die Editierarbeit realisieren, ohne irgendeinen Widerspruch zu bewirken, während die Zugriffe durch diese Nutzer mit Bezug auf eine identische Datei simultan zugelassen werden.
Herkömmlicherweise war eine allgemeine Struktur zur Realisierung solch eines gemeinsamen Dateisystems der Client- Server-Typ, bei dem der Client, als ein Zugriffe auf Dateien tätigendes Subjekt, und der Server, der die Dateien handhabt, getrennt angeordnet sind, und das Authentisierungssystem zum Durchführen der Authentisierung der Zugriffe von dem Client darin implementiert. Das heißt, der Server authentisiert das richtige Zugriffsrecht des Clients, und falls notwendig, führt der Server auch das Verschlüsseln der mit dem Client zu übertragenden Daten durch, während der Client die Richtigkeit des angeschlossenen Servers authentisiert. Herkömmliche bekannte Beispiele solch eines gemeinsam genutzten Dateisystems umfassen Lotus Notes. Es gibt auch ein CFS (Kryptographisches Dateisystem) genanntes System, das als ein Beispiel eines Dateisystems bekannt ist, in dem das Verschlüsseln der Dateiinhalte durch den Client durchgeführt werden kann.
Da dieser Typ von gemeinsam genutztem Dateisystem hinsichtlich seines Service größere Breite aufweist, kann angenommen werden, dass eine Notwendigkeit für ein Service- Format entsteht, in dem nur ein Datei-Server an einem bestimmten Ort erforderlich ist. Dieses ist ein Format, bei dem das Datei-Management und das Zugriffs-Management bereitgestellt sind, jedoch die Dateiinhalte am Server selbst nicht ausgelesen werden können. Diese Art von Service kann jedoch nicht unter Verwendung des bekannten Sicherheitssystems realisiert werden, da das bekannte Sicherheitssystem nur die Kommunikationsdaten schützt, und die Dateiinhalte am Server in Form von einfachem Text gehandhabt werden. Weiter ist beim bekannten Mechanismus zum Realisieren des gleichzeitigen Editierens einer gemeinsamen Datei, während ein Nutzer das Editieren durchführt, was das Schreiben mit Bezug auf eine bestimmte Datei beinhaltet, das, was die anderen Benutzer mit. Bezug auf die gleiche Datei durchführen können, allerhöchstens auf das Lesen beschränkt. Somit ist es genauer gesagt nicht ein wirkliches gleichzeitiges Editieren, es ist lediglich ein Realisieren eines synchronen Editierens, bei dem die Synchronisation unter Verwendung des Sperrmechanismus vorgenommen wird, um so einen Widerspruch zwischen den Zugriffen von einer Vielzahl von Nutzern zu verhindern. Es wird nämlich, wenn der erste Zugriff anfordernde Benutzer einen Zugriff tätigt, der Verriegelungsmechanismus so aktiviert, dass die Dateizugriffsanforderung zum Schreiben vom anderen Benutzer nicht erlaubt ist, und der andere Benutzer dazu gezwungen wird, den Dateizugriff zeitweilig auszusetzen, das Freigeben der Sperrung abzuwarten, und den Dateizugriff später erneut zu versuchen, wenn die Sperre freigegeben ist.
In dieser Hinsicht kann ein flexibleres System realisiert werden, falls es nötig ist, es einem Benutzer zu erlauben, das Editieren durchzuführen, das das Schreiben mit Bezug auf eine bestimmte Datei beinhaltet, auch wenn der andere Benutzer das Editieren durchführt, das das Schreiben mit Bezug auf die gleiche Datei beinhaltet. Im folgenden wird dieser Typ von Operation als asynchrones Editieren bezeichnet, in einer Hinsicht, in der es keine Notwendigkeit gibt, die Synchronisation zwischen den Zugriffen zu tätigen, die zufallsweise durch eine Vielzahl von Benutzern erzeugt werden.
Auf der anderen Seite ist ein anderes Verfahren hinsichtlich des gemeinsamen Dateisystems das Versions- Managementverfahren. Das herkömmlich bekannte Versions- Managementverfahren umfasst das SCCS (Source Code Control System) (Quellcode-Kontrollsystem), und das RCS (Revision Control System) (Revisions-Kontrollsystem). Solch ein Versions-Managementverfahren erzielt die Kompression der Dateigröße durch Bewahren nur einer Differenz zwischen den unterschiedlichen Versionen, anstatt eines Haltens der gesamten Dateien zu einem gegebenen Zeitpunkt, z. B. falls eine Programmentwicklung durch eine Vielzahl von Programmierern durchgeführt wird. Trotz ihrer Vorteile hinsichtlich der reduzierten Dateigröße ist die Einbeziehung in das gemeinsame Dateisystem so weit bis auf einen Fall eines synchronen Editierens unter Verwendung des Sperrmechanismus beschränkt.

ZUSAMMENFASSUNG DER ERFINDUNG

Es ist daher eine Aufgabe der vorliegenden Erfindung, ein gemeinsames Dateieditiersystem bereitzustellen, das das Dateiversions-Management unterstützt, und das ein asynchrones Editieren realisieren kann.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein gemeinsames Dateieditiersystem bereitzustellen, das das Dateiversions-Management unterstützt, und das das asynchrone Editieren realisieren kann, während die Dateiinhalte vor dem Datei-Server geheimgehalten werden.
Es ist eine sekundäre Aufgabe der vorliegenden Erfindung, ein Dateieditiersystem bereitzustellen, das einen höheren Geheimhaltungsstand realisieren kann, so dass die Dateiinhalte vom Datei-Server nicht gelesen werden können.
In Übereinstimmung mit einem Gesichtspunkt der vorliegenden Erfindung ist ein Dateieditiersystem bereitgestellt, umfassend: Eine Dateiverwaltungs-Servervorrichtung zum Verwalten von Dateien, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält; und mindestens eine Client-Vorrichtung, die einen Zugriff auf die Dateiverwaltungs-Servervorrichtung tätigt, um die Blockdaten entsprechend einer erwünschten Version einer durch die Dateiverwaltungs-Servervorrichtung verwalteten erwünschten Datei zu erhalten, wobei die Client- Vorrichtung umfasst: Eine Entschlüsselungseinrichtung zum Entschlüsseln der von der Dateiverwaltungs-Servervorrichtung erhaltenen Blockdaten, unter Verwendung eines vorgegebenen Dechiffrierschlüssels; eine Editiereinrichtung zum Editieren der erwünschten Version der erwünschten Datei, gebildet durch die durch die Entschlüsselungseinrichtung entschlüsselten Blockdaten; eine Editierprozedur-Erzeugungseinrichtung zum Erzeugen von Editierprozedurdaten, die eine Prozedur bezeichnen, um eine getätigte Editierung in der erwünschten Version der erwünschten Datei durch die Editiereinrichtung zu erhalten, und um Einfügungsdaten einzufügen, die in die erwünschte Datei einzufügen sind; eine Verschlüsselungseinrichtung zum Verschlüsseln der in die durch die Editierprozedur-Erzeugungseinrichtung erzeugten Editierprozedurdaten eingefügten Einfügungsdaten, unter Verwendung eines vorgegebenen Chiffrierschlüssels, um chiffrierte Editierprozedurdaten zu erlangen; und eine Kommunikationseinrichtung, um die verschlüsselten Editierprozedurdaten, erhalten durch die Verschlüsselungseinrichtung, zu der Dateiverwaltungs- Servervorrichtung zu übermitteln; wobei die Dateiverwaltungs- Servervorrichtung umfasst: Eine Editierprozedur- Umwandlungseinrichtung, um die verschlüsselten Editierprozedurdaten für die erwünschte Version der erwünschten Datei, empfangen von der Client-Vorrichtung, in verschlüsselte Editierprozedurdaten für eine neueste Version der erwünschten Datei umzuwandeln; eine Datensatzverwaltungs- Informationserzeugungseinrichtung zum Erzeugen von Datensatzverwaltungsinformation, die ein Ergebnis der durch die Editiereinrichtung getätigten Editierung anzeigt, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die neueste Version der erwünschten Datei, erlangt durch die Editierprozedur-Umwandlungseinrichtung; und eine Datensatzverwaltungseinrichtung zum Durchführen einer Datensatzverwaltung der erwünschten Datei in Übereinstimmung mit der Datensatzverwaltungsinformation, erlangt durch die Datensatzverwaltungs-Informationserzeugungseinrichtung, und der Blockidentifikationsinformation für jede Blockdaten.
In Übereinstimmung mit einem weiteren Gesichtspunkt der vorliegenden Erfindung ist ein Verfahren zur Dateieditierung bereitgestellt, in einem Dateieditiersystem, gebildet durch eine Dateiverwaltungs-Servervorrichtung und mindestens eine Client-Vorrichtung, die Schritte umfassend: Verwalten von Dateien an der Dateiverwaltungs-Servervorrichtung, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält; Durchführen eines Zugriffs auf die Dateiverwaltungs- Servervorrichtung, um die Blockdaten entsprechend einer erwünschten Version einer durch die Dateiverwaltungs- Servervorrichtung verwalteten erwünschten Datei an der Client-Vorrichtung zu erlangen; Entschlüsseln der von der Dateiverwaltungs-Servervorrichtung erhaltenen Blockdaten, unter Verwendung eines vorgegebenen Dechiffrierschlüssels, an der Client-Vorrichtung; Editieren der erwünschten Version der erwünschten Datei, gebildet durch die durch den Entschlüsselungsschritt entschlüsselten Blockdaten, an der Client-Vorrichtung; Erzeugen von Editierprozedurdaten, die eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch den Editierschritt getätigten Editierung zu erlangen, und Einfügen von in die erwünschte Datei einzufügenden Einfügungsdaten, an der Client- Vorrichtung; Verschlüsseln der in die Editierprozedurdaten, erzeugt durch den Editierprozedurdaten-Erzeugungsschritt, eingefügten Einfügungsdaten, unter Verwendung eines vorgegebenen Chiffrierschlüssels, um verschlüsselte Editierprozedurdaten an der Client-Vorrichtung zu erhalten; Übertragen der verschlüsselten Editierprozedurdaten, erhalten durch den Verschlüsselungsschritt, von der Client-Vorrichtung zu der Dateiverwaltungs-Servervorrichtung; Umwandeln der verschlüsselten Editierprozedurdaten für die erwünschten Version der erwünschten Datei, empfangen von der Client- Vorrichtung, in verschlüsselte Editierprozedurdaten für eine neueste Version der erwünschten Datei, an der Dateiverwaltungs-Servervorrichtung; Erzeugen von Datensatzverwaltungs-Information, die ein Ergebnis einer durch den Editierschritt getätigten Editierung anzeigt, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die neueste Version der erwünschten Datei, erlangt durch den Umwandlungsschritt, an der Dateiverwaltungs- Servervorrichtung; und Durchführen einer Datensatzverwaltung der erwünschten Datei an der Dateiverwaltungs- Servervorrichtung, in Übereinstimmung mit der durch den Datensatzverwaltungsinformations-Erzeugungsschritt erhaltene Datensatzverwaltungs-Information, und der Blockidentifikationsinformation für jede Blockdaten.
In Übereinstimmung mit einem weiteren Gesichtspunkt der vorliegenden Erfindung ist eine Client-Vorrichtung bereitgestellt, um einen Zugriff auf eine Servervorrichtung zu tätigen, die Dateien verwaltet, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, um so die Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei zu erhalten, wobei die Client-Vorrichtung umfasst: Eine Entschlüsselungseinheit zum Entschlüsseln der von der Servervorrichtung erlangten Blockdaten, unter Verwendung eines vorgegebenen Dechiffrierschlüssels; eine Editiereinheit zum Editieren der erwünschten Version der erwünschten Datei, gebildet durch die durch die Entschlüsselungseinheit entschlüsselten Blockdaten; eine Editierprozedur- Erzeugungseinheit zum Erzeugen von Editierprozedurdaten, die eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch die Editiereinheit getätigten Editierung zu erlangen, und um in die erwünschten Datei einzufügende Einfügungsdaten einzufügen; eine Chiffriereinheit zum Verschlüsseln der Einfügungsdaten, eingefügt in die durch die Editierprozedur-Erzeugungseinheit erzeugen Editierprozedurdaten, unter Verwendung eines vorgegebenen Chiffrierschlüssels, um verschlüsselte Editierprozedurdaten zu erlangen; und eine Kommunikationseinheit zum Übertragen der verschlüsselten Editierprozedurdaten, erlangt durch die Chiffriereinheit, zu der Servervorrichtung.
In Übereinstimmung mit einem weiteren Gesichtspunkt der vorliegenden Erfindung ist ein Verfahren bereitgestellt, um einen Zugriff auf eine Servervorrichtung zu tätigen, die Dateien verwaltet, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, wobei das Verfahren die Schritte umfasst: Erlangen der Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei; Entschlüsseln der von der Servervorrichtung erlangten Blockdaten unter Verwendung eines vorgegebenen Dechiffrierschlüssels; Editieren der erwünschten Version der erwünschten Datei, gebildet durch die durch den Entschlüsselungsschritt entschlüsselten Blockdaten; Erzeugen von Editierprozedurdaten, die eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch den Editierschritt getätigte Editierung zu erlangen, und um in die erwünschte Datei einzufügende Einfügungsdaten einzufügen; Verschlüsseln der in die Editierprozedurdaten, erzeugt durch den Erzeugungsschritt, eingefügten Einfügungsdaten, unter Verwendung eines vorgegebenen Chiffrierschlüssels, um verschlüsselte Editierprozedurdaten zu erhalten; und Übertragen der verschlüsselten Editierprozedurdaten, erhalten durch den Verschlüsselungsschritt, zu der Servervorrichtung.
In Übereinstimmung mit einem weiteren Gesichtspunkt der vorliegenden Erfindung ist ein Herstellungsartikel bereitgestellt, umfassend: Ein computerlesbares Medium mit einer computerlesbaren Programmcodeeinrichtung, die darin verkörpert ist, um zu bewirken, dass ein Computer als eine Client-Vorrichtung arbeitet, um einen Zugriff auf eine Servervorrichtung zu tätigen, die Dateien verwaltet, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, um so die Blockdaten zu erlangen, die einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei entsprechen, wobei die computerlesbare Programmcodeeinrichtung umfasst: Eine erste computerlesbare Programmcodeeinrichtung zum Bewirken, dass der Computer die von der Servervorrichtung erlangten Blockdaten entschlüsselt, unter Verwendung eines vorgegebenen Dechiffrierschlüssels; eine zweite computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer die erwünschte Version der erwünschten Datei, gebildet durch die durch die erste computerlesbare Programmcodeeinrichtung verschlüsselte Blockdaten, zu editieren; eine dritte computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer Editierprozedurdaten erzeugt, die eine Prozedur anzeigen, um eine Editierung zu erhalten, die in der erwünschten Version der erwünschten Datei durch die zweite computerlesbare Programmcodeeinrichtung getätigt wurde, und um in die erwünschten Datei einzufügende Einfügungsdaten einzufügen; eine dritte computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer die in die Editierprozedurdaten, erzeugt durch die dritte computerlesbare Programmcodeeinrichtung, eingefügten Einfügungsdaten unter Verwendung eines vorgegebenen Chiffrierschlüssels verschlüsselt, um verschlüsselte Editierprozedurdaten zu erlangen; und eine fünfte computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer die verschlüsselten Editierprozedurdaten, erhalten durch die vierte computerlesbare Programmcodeeinrichtung, zu der Servervorrichtung übermittelt.
In Übereinstimmung mit einem weiteren Gesichtspunkt der vorliegenden Erfindung ist eine Servervorrichtung zum Verwalten von Dateien bereitgestellt, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, wobei eine Client-Vorrichtung einen Zugriff auf die Servervorrichtung tätigt, um die Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei zu erlangen, wobei die Servervorrichtung umfasst: Eine Editierprozedur-Umwandlungseinheit zum Umwandeln von verschlüsselten Editierprozedurdaten für die erwünschten Version der erwünschten Datei, empfangen von der Client- Vorrichtung, in verschlüsselte Editierprozedurdaten für eine neueste Version der erwünschten Datei, wobei die verschlüsselten Editierprozedurdaten eine Prozedur bezeichnen, um eine Editierung zu erlangen, die in der erwünschten Version der erwünschten Datei durch die Client- Vorrichtung getätigt würde, und um in die erwünschte Datei einzufügende Einfügungsdaten einzufügen, wobei die Einfügungsdaten unter Verwendung eines vorgegebenen Chiffrierschlüssels verschlüsselt sind; eine Datensatzverwaltungsinformations-Erzeugungseinheit zum Erzeugen von Datensatzverwaltungsinformation, die ein Ergebnis der durch die Client-Vorrichtung getätigten Editierung anzeigen; in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die neueste Version der erwünschten Datei, erlangt durch die Editierprozedur- Umwandlungseinheit; und eine Datensatzverwaltungseinheit zum Durchführen einer Datensatzverwaltung der erwünschten Datei in Übereinstimmung mit der durch die Datensatzverwaltungsinformations-Erzeugungseinheit erlangten Datensatzverwaltungsinformation, und der Blockidentifikationsinformation für jede Blockdaten.
In Übereinstimmung mit einem weiteren Gesichtspunkt der vorliegenden Erfindung ist ein Verfahren bereitgestellt, um Dateien an einer Servervorrichtung zu verwalten, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, wobei eine Client-Vorrichtung einen Zugriff auf die Servervorrichtung tätigt, um die Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei zu erlangen, wobei das Verfahren die Schritte umfasst: Umwandeln von verschlüsselten Editierprozedurdaten für die erwünschte Version der erwünschten Datei, empfangen von der Client-Vorrichtung, in verschlüsselte Editierprozedurdaten für eine neueste Version der erwünschten Datei, wobei die verschlüsselten Editierprozedurdaten eine Prozedur bezeichnen, um eine Editierung zu erlangen, die in der erwünschten Version der erwünschten Datei durch die Client-Vorrichtung getätigt wurde, und um in die erwünschte Datei einzufügende Einfügungsdaten einzufügen, wobei die Einfügungsdaten unter Verwendung eines vorgegebenen Chiffrierschlüssels verschlüsselt sind; Erzeugen von Datensatzverwaltungsinformation, die ein Ergebnis der durch die Client-Vorrichtung getätigten Editierung anzeigen, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die neueste Version der erwünschten Datei, erlangt durch den Umwandlungsschritt; und Durchführen einer Datensatzverwaltung der erwünschten Datei in Übereinstimmung mit der Datensatzverwaltungsinformation, erlangt durch den Erzeugungsschritt, und der Blockidentifikationsinformation für jede Blockdaten.
In Übereinstimmung mit einem weiteren Gesichtspunkt der vorliegenden Erfindung ist ein Herstellungsartikel bereitgestellt, umfassend: Ein computerverwendbares Medium mit einer darin verkörperten computerlesbaren Programmcodeeinrichtung, um zu bewirken, dass ein Computer als eine Servervorrichtung zum Verwalten von Dateien arbeitet, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten umfasst, wobei eine Client-Vorrichtung einen Zugriff auf die Servervorrichtung tätigt, um die Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei zu erlangen, wobei die computerlesbare Programmcodeeinrichtung umfasst: Eine erste computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer verschlüsselte Editierprozedurdaten für die erwünschte Version der erwünschten Datei, empfangen von der Client-Vorrichtung, in verschlüsselte Editierprozedurdaten für eine neueste Version der erwünschten Datei umwandelt, wobei die verschlüsselte Editierprozedurdaten eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch die Client-Vorrichtung getätigten Editierung zu erlangen, und um in die erwünschte Datei einzufügende Einfügungsdaten einzufügen, wobei die Einfügungsdaten unter Verwendung eines vorgegebenen Chiffrierschlüssels verschlüsselt sind; eine zweite computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer Datensatzverwaltungsinformation erzeugt, die ein Ergebnis der durch die Client-Vorrichtung getätigten Editierung anzeigen, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die neueste Version der erwünschten Datei, erlangt durch die erste computerlesbare Programmcodeeinrichtung, und eine dritte computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer eine Datensatzverwaltung der erwünschten Datei in Übereinstimmung mit der Datensatzverwaltungsinformation, erlangt durch die zweite computerlesbare Programmcodeeinrichtung, und der Blockidentifikationsinformation für jede Blockdaten durchführt.
Andere Merkmale, und Vorteile der vorliegenden Erfindung werden sich aus der folgenden Beschreibung ergeben, wenn diese in Zusammenhang mit den begleitenden Zeichnungen gesehen wird.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 zeigt ein schematisches Diagramm einer Gesamtkonfiguration des ersten Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 2 ist ein Diagramm zur Erläuterung einer Datei- Datenstruktur in einem Differenzstapelverfahren, das in dem System von Fig. 1 als Datensatzverwaltungsverfahren verwendet werden kann.
Fig. 3 zeigt ein Diagramm zur Erläuterung einer Datei- Datenstruktur in einem RCS-Verfahren, das in dem System von Fig. 1 als ein Datensatzverwaltungsverfahren verwendet werden kann.
Fig. 4 zeigt ein Diagramm zur Erläuterung einer Datei- Datenstruktur in einem modifizierten SCCS- Verfahren, das in dem System von Fig. 1 als Datensatzverwaltungsverfahren verwendet werden kann.
Fig. 5 zeigt ein Blockdaten eines asynchronen Editiersystems, in das System von Fig. 1 zu inkorporieren.
Fig. 6 zeigt ein Diagramm zur Erläuterung eines Verfahrens bei einer Datensatzverwaltung bei dem asynchronen Editiersystem von Fig. 5 in einem Fall einer Verwendung des Differenzstapelverfahrens von Fig. 2.
Fig. 7 zeigt ein Diagramm zur Erläuterung eines Verfahrens bei einer Datensatzverwaltung in dem asynchronen Editiersystem von Fig. 5 in einem Fall einer Verwendung des modifizierten SCCS-Verfahrens von Fig. 4.
Fig. 8 zeigt ein Diagramm zur Erläuterung eines OFB-Modus- Strom-Chiffrierverfahrens, das in dem System von Fig. 1 als ein Datei-Datenchiffrierverfahren verwendet werden kann.
Fig. 9 zeigt ein Diagramm zur Erläuterung eines CFB-Nodus- Strom-Chiffrierverfahren, das in dem System von Fig. 1 als ein Datei-Datenchiffrierverfahren verwendet werden kann.
Fig. 10 zeigt ein Diagramm zur Erläuterung einer Verschlüsselungsprozedur in dem System von Fig. 1 zu einem Zeitpunkt einer Blockdatenteilung.
Fig. 11 zeigt ein Flussdiagramm einer Verschlüsselungsprozedur in dem System von Fig. 1, zeitlich bei einer Blockdatenteilung, in einem Fall bei einer Verwendung des ersten Verschlüsselungsverfahrens.
Fig. 12 zeigt ein Flussdiagramm einer Verschlüsselungsprozedur im System von Fig. 1, zu einem Zeitpunkt bei einer Blockdatenteilung, in einem Fall bei einer Verwendung des zweiten Verschlüsselungsverfahrens.
Fig. 13 zeigt ein Blockdiagramm einer ersten beispielhaften Konfiguration im zweiten Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 14 zeigt ein Blockdiagramm einer gemeinsamen Dateieditiereinheit in dem System von Fig. 13.
Fig. 15 zeigt ein Blockdiagramm einer Chiffriereinheit in dem System von Fig. 13.
Fig. 16 zeigt ein Blockdiagramm einer zweiten beispielhaften Konfiguration im zweiten Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 17 zeigt ein Blockdiagramm einer gemeinsamen Dateieditiereinheit in dem System von Fig. 16.
Fig. 18 zeigt ein Blockdiagramm, das die Hauptmerkmale in der ersten beispielhaften Konfiguration von Fig. 13 zusammenfasst.
Fig. 19 zeigt ein Blockdiagramm, das die Hauptmerkmale in der zweiten beispielhaften Konfiguration von Fig. 16 zusammenfasst.
Fig. 20 zeigt ein Blockdiagramm des dritten Ausführungsbeispiels des gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 21 zeigt ein Blockdiagramm einer gemeinsamen Dateieditiereinheit in dem System von Fig. 20.
Fig. 22 zeigt ein Blockdiagramm einer Verknüpfungsverarbeitungseinheit in dem System von Fig. 20.
Fig. 23 zeigt ein Blockdiagramm des vierten Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 24 zeigt ein Blockdiagramm einer Chiffriereinheit in dem System von Fig. 23.
Fig. 25 zeigt ein Blockdiagramm des fünften Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 26 zeigt ein Blockdiagramm einer Client-Zähleinheit in dem System von Fig. 25.
Fig. 27 zeigt ein Diagramm zur Erläuterung einer beispielhaften Datenstruktur für eine Zählspeichereinheit in der Client-Zähleinheit von Fig. 26.
Fig. 28 zeigt ein Flussdiagramm für einen Betrieb einer Löschanforderungsverarbeitungseinheit in der Client-Zähleinheit von Fig. 26.
Fig. 29 zeigt ein Flussdiagramm für einen Betrieb einer Editier-Ende-Verarbeitungseinheit in der Client- Zähleinheit von Fig. 26.
Fig. 30 zeigt ein Flussdiagramm für eine Löschbefehlsausführungsverarbeitung durch eine Datensatzverwaltungseinheit in dem System von Fig. 25, in einem Fall bei einer Verwendung des Differenz Differenzstapelverfahrens von Fig. 2.
Fig. 31 zeigt ein Flussdiagramm für eine Löschbefehlsausführungsverarbeitung durch eine Datensatzverwaltungseinheit in dem System von Fig. 25, in einem Fall bei einer Verwendung des RCS- Verfahrens von Fig. 3.
Fig. 32 zeigt ein Flussdiagramm für eine Löschbefehlsausführungsverarbeitung durch eine Datensatzverwaltungseinheit in dem System von Fig. 25, in dem Fall bei einer Verwendung des modifizierten SCCS-Verfahrens von Fig. 4.
Fig. 33 zeigt ein Blockdiagramm des sechsten Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 34 zeigt ein Flussdiagramm für einen Betrieb einer Blockdatenrekonstruktionseinheit in dem System von Fig. 33 während einer Löschbefehlsausführungsverarbeitung in dem System von Fig. 33, in einem Fall bei einer Verwendung des Differenzstapelverfahrens von Fig. 2.
Fig. 35 zeigt ein Flussdiagramm für einen Betrieb einer Datensatzverwaltungseinheit in dem System von Fig. 33 während einer Löschbefehlsausführungsverarbeitung in dem System von Fig. 33, in einem Fall bei einer Verwendung des Differenzstapelverfahrens von Fig. 2.
Fig. 36 zeigt ein Flussdiagramm für einen Betrieb einer Blockdatenrekonstruktionseinheit in dem System von Fig. 33 während einer Löschbefehlsausführungsverarbeitung in dem System von Fig. 33, in einem Fall bei einer Verwendung des RCS-Verfahrens von Fig. 3.
Fig. 37 zeigt ein Flussdiagramm für einen Betrieb einer Datensatzverwaltungseinheit in dem System von Fig. 33 während einer Löschbefehlsausführungsverarbeitung in dem System von Fig. 33, in einem Fall bei einer Verwendung des RCS-Verfahrens von Fig. 3.
Fig. 38 zeigt ein Blockdiagramm des siebten Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 39 zeigt ein Flussdiagramm für einen Betrieb einer Differenzinformations-Konstruktionseinheit in dem System von Fig. 38, in einem Fall bei einer Verwendung des modifizierten SCCS-Verfahrens von Fig. 4.
Fig. 40 zeigt ein Blockdiagramm des achten Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 41 zeigt ein Blockdiagramm des neunten Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.
Fig. 42 zeigt ein Blockdiagramm des zehnten Ausführungsbeispiels eines gemeinsamen Dateieditiersystems der vorliegenden Erfindung.
Fig. 43 zeigt ein Diagramm einer beispielhaften Zugriffsdatensatzliste, wie sie durch eine Zugriffsinformationsspeichereinheit im System von Fig. 42 verwendet wird.
Fig. 44 zeigt ein Blockdiagramm des elften Ausführungsbeispiels eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE

Nun wird das erste Ausführungsbeispiel eines gemeinsamen Dateieditiersystems (Dateieditiersystem für gemeinsam genutzte Dateien) gemäß der vorliegenden Erfindung detailliert erläutert.
Dieses gemeinsame Dateieditiersystem des ersten Ausführungsbeispiels verwirklicht zwei unabhängig realisierbare Merkmale der vorliegenden Erfindung. Das erste Merkmal betrifft, es unmöglich zu machen, dass Dateninhalte von einem Datei-Server in einem gemeinsamen Dateieditiersystem, das Dateien in Blöcken verwaltet, auszulesen, während das zweite Merkmal betrifft, es möglich zu machen, dass ein asynchroner Editierbetrieb in einem gemeinsamen Dateieditiersystem, das die Dateiversionsverwaltung unterstützt, durchgeführt werden kann.
In diesem ersten Ausführungsbeispiel weist das gemeinsame Dateieditiersystem die in Fig. 1 gezeigte allgemeine Konfiguration auf, die einen oder mehrere von zugriffsanfordernden Clients 101 (im folgenden einfach als Clients bezeichnet) umfasst, die Dateizugriffsanforderungen mit Bezug auf gemeinsam genutzte Dateien ausgeben, und einen Dateiverwaltungsserver 110 (im folgenden einfach als Server bezeichnet), un die Verwaltung der Dateien und die Kommunikation von Anforderungsdaten mit Bezug auf die Clients 101 durchzuführen. Hier ist zwischen jedem Client 101 und dem Server 110 ein Kommunikationspfad 111 bereitgestellt, um Anforderungsnachrichten und Antwortnachrichten zu übertragen und zu empfangen.
Dabei ist der Client 101 ist eine Abstraktion eines Konzepts, das einen Benutzer umfasst, der die tatsächliche Zugriffsanforderung abgegeben hat, einen Prozess auf einen Computer, der durch diesen Benutzer benutzt wird, etc. Weiter, wie in Fig. 1 gezeigt, ist jeder Client 101 mit einer Chiffriereinheit 112 ausgestattet, um die Verschlüsselung und Entschlüsselungsbetriebsvorgänge durchzuführen. Wie es unterhalb detailliert beschrieben wird, umfasst diese Chiffriereinheit 112 weiter eine Verschlüsselungs- /Entschlüsselungs-Verarbeitungseinheit, um den Verschlüsselungsalgorithmus auszuführen, und eine Schlüsselspeichereinheit, um einen Chiffrierschlüssel und einen Dechiffrierschlüssel zu speichern. Weitere Details bezüglich Funktionen dieser Verschlüsselung- /Entschlüsselungs-Verarbeitungseinheit und Schlüsselspeichereinheit werden später beschrieben.
Auf der anderen Seite kann der Server 110 ein Prozess auf einem Computer sein, um die Dateiverwaltung durchzuführen, oder eine unabhängige Vorrichtung mit der Dateiverwaltungsfunktion.
Der Kommunikationspfad 111 kann irgendein Medium sein, das Nachrichten elektronisch austauschen kann, wie beispielsweise ein öffentliches Netzwerk, LAN, Ethernet oder eine Kommunikation unter Verwendung von Sockets innerhalb eines Computers.
Der Server 110 verwaltet eine Vielzahl von Dateien 113. Hier umfassen die Dateien 113 nicht nur Daten, die Dateiinhalte repräsentieren, sondern auch Information für eine Datensatzverwaltung, eine Liste von Benutzernamen, von denen die Zugriffe erlaubt sind, Information, die in der Verschlüsselungs-/Entschlüsselungsverarbeitung verwendet wird, etc., was später detaillierter beschrieben wird. Diese Dateien 113 sind in einem Format verschlüsselt, das nur durch die jeweiligen richtigen Clients 101 entschlüsselt werden kann.
Im Falle, dass ein gewöhnliches Chiffrierverfahren verwendet wird, in dem der Chiffrierschlüssel und der Dechiffrierschlüssel identisch sind, besitzt der zulässige Client 101 diesen identischen Schlüssel; mittels dem die Dateien 113 verschlüsselt oder entschlüsselt werden können.
Nun weist die Datei 113 eine Eigenschaft auf, dass ihr Inhalt sich von Zeit zu Zeit als eine Folge von Editieroperationen ändert, wie beispielsweise ein Schreiben und Löschen, das während Zugriffen durchgeführt wird, auch wenn der Dateiname selbst unverändert verbleibt. Aus diesem Grund gibt es Fälle, in denen es notwendig ist, den Dateiinhalt der Datei 113 zu gewissen ausgewählten Zeitpunkten zu speichern, um so in der Lage zu sein, eine spätere Anforderung zur Reproduktion eines Zustands der Datei 113 zu einem der ausgewählten Zeitpunkte zu bedienen. Diese Art von Anforderung ist im Falle der Programmentwicklung relativ häufig.
Das einfachste Verfahren zur Realisierung solch einer Datensatzverwaltung (Versions-Management) ist es, den gesamten Dateiinhalt zu jedem ausgewählten Zeitpunkt zu speichern. Es ist jedoch die Differenz (Diskrepanz) zwischen unterschiedlichen Versionen allgemein ziemlich klein, so dass dieses einfache Verwaltungsverfahren hinsichtlich Dateigrößen verschwenderisch ist. Demzufolge wird normalerweise ein Verfahren verwendet, wie beispielsweise das SCCS (Source Code Control System) und das RCS (Revision Control System), die nur Information bezüglich einer Differenz speichern.
Im folgenden wird das Prinzip der Datenstruktur in jedem Datensatzverwaltungsverfahren erläutert.
Zuerst wird ein Verfahren erläutert, dass als ein Prototyp des RCS erachtet werden kann. Hier wird dieses Verfahren als Differenzstapelverfahren bezeichnet. Eine Datei-Datenstruktur in diesem Differenzstapelverfahren ist in Fig. 2 gezeigt. In diesem Verfahren wird die Datei in der ersten Version zu einem Zeitpunkt ihrer Erzeugung im vollen Umfang gespeichert, und als Version V.1 (Block 201) bezeichnet. Wenn als nächstes eine Version V.2 erzeugt wird, indem ein Teil der Version V.1 gelöscht wird, oder etwas in die Version V.1 eingefügt wird, wird eine Differenz zwischen der Version V.2 und der Version V.2 erlangt, und nur die erlangte Differenz V.2-V.1 (Block 202) wird gespeichert. Hier ist die Differenz zwischen Versionen ein Satz von Daten, die Tatsächliches bezeichnet, wie beispielsweise "was wurde wo eingefügt", und "von wo bis wo wurde gelöscht", wie zum Beispiel durch den "diff"-Befehl bei UNIX. Eine die gesamte Datei umfassende Änderung wird selten vorgenommen, so dass die Größe der Differenz allgemein kleiner als die Größe der gesamten Datei ist. Die Daten in solch einem gespeicherten Zustand, d. h. die Daten für die Version V.1 und die Daten für die Differenz V.2-V.1 können ausreichende Information zum Wiederherstellen der Version V.2 bereitstellen.
Nachfolgend wird die Differenz zwischen einer neuen Version nach dem Editieren und der letzten gespeicherten Version gebildet, wie beispielsweise die Differenz V.3-V.2 (Block 203) zwischen den Versionen V.3 und V.2, die Differenz V.4- V.3 (Block 204) zwischen den Versionen V.4 und V.3, etc., und zwar jedes Mal, und nur die Differenz wird in ähnlicher Art und Weise zusätzlich gespeichert.
Um die neueste Version (momentane Version) wiederherzustellen, ist es demzufolge bei diesem Differenzstapelverfahren notwendig, die Datensätze aller bisherig kompilierten Versionen zu verwenden, jedoch gibt es eine signifikante Verbesserung hinsichtlich der Dateigrößen.
Als nächstes wird das RCS-Verfahren erläutert. Eine Datei- Datenstruktur für eine Datensatzverwaltung bei dem RCS- Verfahren ist in Fig. 3 gezeigt. In diesem RCS-Verfahren werden die Datensätze wie folgt verwaltet. Zuerst wird die momentane Version (Block 304) immer in ihrer Gesamtheit gespeichert. In Fig. 3 ist ein Fall gezeigt, bei dem die momentane Version die Version V.4 ist. Dann wird die Version V.3, die die unmittelbar der Version V.4 vorhergehende ist, in einem Format der Differenz V.3-V.4 (Block 303) mit Bezug auf die Version V.4 gespeichert. Dieses Verfahren ist dadurch charakterisiert, dass die Differenz mit Bezug auf eine zeitlich gesehen neuere Version auf diese Weise abgenommen wird. Somit werden für die Versionen vor der Version V.3 der Unterschied V.2-V.3 (Block 302) und die Differenz V.1-V.2 (Block 301) auf ähnliche Weise gespeichert. In diesem Zustand wird im Falle eines Speicherns einer neuen Version V.5 eine Verarbeitung zum Erhalten der Differenz V.4-V.5 und eine Verarbeitung zum Speichern der erlangten Differenz und der neuen Version V.5 durchgeführt.
Wenn diese Datenstruktur verwendet wird, ist es ein Vorteil, dass die momentane Version einfach herausgenommen werden kann. Auf der anderen Seite wird ein Fall eines Wiederherstellens der älteren Version eine längere Zeit benötigen, jedoch wird normalerweise eine neuere Version öfter benutzt werden, sodass dieses Verfahren der allgemeinen Nutzungsweise entspricht.
Als nächstes wird ein Verfahren erläutert, bei dem ein weiteres repräsentatives Datensatzverwaltungsverfahren, als SCCS-Verfahren bekannt, modifiziert ist. Dieses ist ein Versions-Verwaltungsverfahren, um in Entsprechung zu jedem Datenblock Information zu speichern, die anzeigt, in welcher Version dieser Datenblock eingefügt wurde, und Information, die anzeigt, in welcher Version dieser Datenblock gelöscht wurde.
Eine beispielhafte Datei-Datenstruktur für eine Datensatzverwaltung in diesem modifizierten SCCS-Verfahren ist in Fig. 4 gezeigt. In diesem SCCS-Verfahren, anstelle eines Speicherns der Datei-Daten zu einem bestimmten Zeitpunkt in ihrer Gesamtheit, wird die Datei hinsichtlich Blöcken verwaltet, und in einem Falle einer Einfügung wird ein Block mit einer eingefügten Größe von einer eingefügten Position erzeugt. Hier ist jeder Block mit zwei Datenfeldern. 406 und 407 verknüpft, wobei ein Datenfeld 406 eine Erzeugungszeit oder eine Versionszahl zu einem Zeitpunkt der Erzeugung jedes Blocks anzeigt (was als ein Beispiel einer Information zum Identifizieren einer Erzeugungszeit jedes Blocks dient), und wobei ein Feld 407 eine Löschzeit oder eine Versionsnummer zum Zeitpunkt der Löschung eines jeden Blocks anzeigt (was als ein Beispiel einer Information zur Identifizierung eines Löschzeitpunkts jedes Blocks dient).
Diese zwei Datenfelder 406 und 407 sind lediglich ein Beispiel von Blockidentifikationsinformation, welche eine Information ist, die hinzuzufügen ist, um das Verstehen einer Positionierung von einem individuellen Block zu unterstützen. Sogar beim oben beschriebenen Differenzstapelverfahren oder dem RCS-Verfahren wurde die Blockidentifikationsinformation in einer Form eines Markers gegeben, wie beispielsweise "Differenz V.X-V.Y", was dem individuellen Block hinzugefügt wurde. Mit anderen Worten ist die Blockidentifikationsinformation eine Information, die ein Verhältnis unter Blöcken bezeichnet.
Genauer gesagt, wie in Fig. 4 gezeigt, umfast eine beispielhafte Datei in diesem modifizierten SCCS- Datensatzverwaltungsverfahren beispielsweise vier unterschiedliche Versionen V.1 bis V.4, und diese Datei weist momentan fünf Blöcke auf, einschließlich b1 (Block 401), b2 (Block 402), b3 (Block 403), b4 (Block 404), und b5 (Block 405).
Darm ist es durch Bezugnahme auf die Inhalte der zwei Datenfelder 406 und 407, oben beschrieben, möglich, festzustellen, dass die Datei wie folgt editiert wurde.
Zuerst, in der Version V.l (erste Version) umfasste diese Datei zwei Blöcke b2 und b3. Dann wurden in der Version V.2 Blöcke b2 und b4 am oberen Ende bzw. am unteren Ende der Datei hinzugefügt, so dass diese Datei in der Version V.2 vier Blöcke b1, b2, b3 und b4 umfasste. Als nächstes wurde in der Version V.3 ein Abschnitt des Blocks b4 geändert und als Block b5 umgeschrieben. In diesem Fall ist dem Block b4 ein Flag (Markierung) hinzugefügt, das anzeigt, dass er in der Version v.3 gelöscht wurde, und der Datensatzverwaltung wird angezeigt, dass der Block b5 neuerlich eingefügt wurde, unmittelbar unterhalb Block b4. Demzufolge umfasst diese Datei in der Version V.3 vier Blöcke b1, b2, b3 und b5. Dann wurde in der Version V.4 (momentane Version) der Block b2 gelöscht, so dass der Block b2 mit einem Flag versehen ist, das anzeigt, dass er in der Version V.4 entsprechend gelöscht wurde. Demzufolge umfasst die Datei in der Version V.4 drei Blöcke, b1, b3 und b5. Es wird darauf hingewiesen, dass vor der Version V:4 die Blöcke b2 und b3 ein einzelner Block waren, jedoch in der Version V.4 eine erste Hälfte dieses Blocks entsprechend dem Block b2 gelöscht wurde.
Wie es aus dem obigen Beispiel ersichtlich ist, existiert im modifizierten SCCS-Datensatzverwaltungsverfahren die Datei in der momentanen Version nicht als ein kontinuierlicher Satz, sondern eine beliebige Version kann herausgenommen werden, indem solche Blöcke verbunden werden, die in dieser Version oder vorhergehenden Versionen erzeugt wurden, und die zum Zeitpunkt dieser Version nicht gelöscht waren, in einer Reihenfolge von oben nach unten, sodass es dadurch gekennzeichnet ist, dass eine beliebige Version ohne viel Laden herausgezogen werden kann. Weiter ist es ersichtlich, dass Blöcke die Tendenz aufweisen, weiter aufgeteilt zu werden, wenn die Versionen voranschreiten. Somit kann in diesem modifizierten SCCS-Verfahren die Datensatzverwaltung einfach realisiert werden, so lange es möglich ist, die Position des einzufügenden Blocks und eines zu löschenden Bereichs zusammen anzuzeigen.
Nunmehr wird in dem gemeinsamen Dateieditiersystem dieses ersten Ausführungsbeispiels das Verschlüsselungsverfahren verwendet, um einen Schutz hinsichtlich eines Lesens des Dateiinhalts bereitzustellen. In dieser Hinsicht ist das erste Merkmal der vorliegenden Erfindung durch die Tatsache gekennzeichnet, dass es dem Server, der die Datei speichert, nicht erlaubt ist, den Dateiinhalt auszulesen, während das zweite Merkmal der vorliegenden Erfindung durch die Tatsache gekennzeichnet ist, dass es eine Vielzahl von Subjekten unterstützt, um den Editierbetrieb mit Bezug auf die Datei auszuführen, indem der asynchrone Editierbetrieb soweit wie möglich ohne exklusive Vorgänge wie beispielsweise Verriegeln realisiert wird. Dann wird es durch Kombinieren der Datei- Datenstruktur, wie oben beschrieben, mit dieser Verschlüsselungseigenschaft möglich, das gemeinsame Dateieditiersystem zu realisieren, bei dem die Geheimhaltung des Dateiinhalts mit Bezug auf den Server sichergestellt werden kann, während der asynchrone Editierbetrieb durch eine Vielzahl von Subjekten realisiert werden kann, indem die oben beschriebenen Datei-Datenstruktur verwendet wird.
Im folgenden wird das das asynchrone Editieren betreffende Merkmal, ohne das Verriegeln zu verwenden, erläutert. Beim Realisieren des asynchronen Editierens muss das folgende Problem gelöst werden. Es sei angenommen, dass ein bestimmter Client A die Datei in der momentanen Version V.4 ausgelesen hat, und eine neue Version V. A erzeugt hat, durch ein Ausführen einer teilweisen Löschung und Einfügung mit Bezug auf die ausgelesene Version, während in etwa zum gleichen Zeitpunkt ein weiterer Client B auch die Datei in der momentanen Version V.4 zu diesem Zeitpunkt ausgelesen hat, und eine neue Version V. B erzeugt hat, indem er eine teilweise Löschung und Einfügung mit Bezug auf die ausgelesene Version durchgeführt hat. Dann wird angenommen, dass das Zurückschreiben der durch den Client A getätigten Editierung ausgeführt wurde, bevor das Rückschreiben der durch den Client B getätigten Editierung ausgeführt wurde. In solch einem Fall wir die Version V. A als eine neue Version V.5 gespeichert werden, und die notwendige Datensatzverwaltung wird ausgeführt, jedoch kann dann das Zurückschreiben der Version V.B einen Widerspruch hervorrufen. Das heißt, falls die Version V.B als eine noch neuere Version V.6 gespeichert wird, wird die neueste Version V.6 nicht die in der früheren Version V.5 getätigten Änderungen widerspiegeln. Um diese Probleme zu verhindern, ist es notwendig, dass jede neue Version nur alle Änderungen vereinen kann, die bis dorthin getätigt wurden.
Um diese Art von asynchroner Editierung zu realisieren, verwendet das gemeinsame Dateieditiersystem dieses ersten Ausführungsbeispiels die Datensatzverwaltung wie folgt. Es wird der Tatsache Aufmerksamkeit geschenkt, dass jede Editieraktion als eine Kombination einer Löschung und Einfügung geschrieben werden kann, und diese Beschreibung kann eindeutig als eine Differenz hinsichtlich der editierten Zielversion bestimmt werden. Unter Berücksichtigung dieser Tatsache kann eine Editieraktion E1 als ein Satz von Δ1 von Editierprozeduren definiert werden, zur Einfügung was bis wohin und zum Löschen von wo bis wo mit Bezug auf die Version V.4, während eine weitere Editieraktion E2 auf ähnliche Weise als ein Satz Δ2 definiert werden kann, von anderen Editierprozeduren mit Bezug auf die gleiche Version V.4.
Wenn dann das Zurückschreiben der Editieraktion E1 zuerst zu tätigen ist, wird die neue Version V.5 durch ein Speichern der Editierprozeduren Δ1 als eine Differenz mit Bezug auf die editierte Zielversion V.4 in einem für das Datensatzverwaltungsverfahren geeigneten Format erzeugt. Wenn dann das Zurückschreiben der Editieraktion E2 zu tätigen ist, werden die Editierprozeduren Δ2, die eine Differenz mit Bezug auf die Editierung der Zielversion V.4 spezifizieren, in umgewandelte Editierprozeduren Δ2' umgewandelt, die eine Differenz mit Bezug auf die neueste Version V.5 spezifizieren, und die neue Version V.6 wird durch ein Speichern der umgewandelten Editierprozeduren Δ2' als eine Differenz mit Bezug auf die vorhergehende Version V.5 in einem für das Datensatzverwaltungsverfahren geeigneten Format gespeichert. Indem dieser Betrieb wiederholt wird, ist es möglich, die asynchrone Editierung ohne Widerspruch auszuführen.
Was in diesem Zusammenhang wichtig ist, ist es, die Editierprozeduren, die nicht ursprünglich als eine Differenz mit Bezug auf die momentane Version definiert sind, in eine Differenz mit Bezug auf die momentane Version ohne irgendeinen Widerspruch umzuwandeln. Dieser Mechanismus kann auch dazu verwendet werden, einen Betrieb zu unterstützen, um die Editierung mit Bezug auf eine viel ältere Version durchzuführen, und das Ergebnis dieser Editierung der momentanen Version zu vereinen.
Nunmehr wird eine Konfiguration für ein asynchrones Editiersystem zur Realisierung des oben beschriebenen Betriebs mit Bezug auf Fig. 5 erläutert. In Fig. 5 umfasst das asynchrone Editiersystem eine Editiereinheit 500, eine Editierprozedur-Erzeugungseinheit 501, eine Editierprozedur- Umwandlungseinheit 502, eine Datensatzinformations- Erzeugungseinheit 503, eine Datensatzverwaltungseinheit 510 und eine Datenspeichereinheit 511. Es wird darauf hingewiesen, dass dieses asynchrone Editiersystem über den Server 110 und den Client 101 zu verteilen ist, wie im zweiten Ausführungsbeispiel beschrieben, und eine Art und Weise einer verteilten Anordnung der Elemente dieses Systems festzulegen ist, in Übereinstimmung damit, ob oder ob nicht die Verschlüsselung der Datei zu verwenden ist, obwohl in jedem Fall die Editiereinheit 500 auf dem Client 101 und die Datenspeichereinheit auf dem Server 110 implementiert sein wird.
Die Editiereinheit 500 führt die Editierung mit Bezug auf den Dateiinhalt beim Editieren der Zielversion aus, erhalten von der Datensatzverwaltungseinheit 510.
Die Editierprozedur-Erzeugungseinheit 501 empfängt den Dateiinhalt in der Editierzielversion und den Dateiinhalt, der sich aus der mit Bezug auf diese Datei durch die Editiereinheit 500 durchgeführten Editierung ergibt, und erzeugt Editierprozedurdaten, einschließlich Einfügungsdaten, Einfügungspositionen, Löschungsbeginnpositionen, und Löschungsendpositionen, die anzeigen, "was wo eingefügt ist" und "von wo nach wo gelöscht ist".
Die Editierprozedur-Umwandlungseinheit 502 empfängt diese Editierprozedurdaten und Datensatz-Daten, unterhalb beschrieben, und erzeugt die Editierprozedurdaten; umgewandelt in die Editierprozeduren mit Bezug auf die momentane Version. Für gegebene Editierprozedurdaten sind beispielsweise die Einfügungsdaten unverändert, während die Einfügungspositionen in entsprechende Positionen mit Bezug auf die momentane Version umgewandelt sind, und die Löschungsstartpositionen und die Löschungsendpositionen sind auf ähnliche Weise in entsprechende Positionen mit Bezug auf die momentane Version umgewandelt. Bei diesem Umwandlungsbetrieb werden die von der Datensatzverwaltungseinheit 510 gelieferten Datensatz-Daten als notwendige zusätzliche Eingabe verwendet.
Die Datensatzverwaltungseinheit 510 führt die Verwaltung der als einen Aktualisierungsdatensatz der Editierzieldatei gespeicherten Datensatz-Daten durch. Die Editierprozedurdaten, ausgegeben von der Editierprozedur- Umwandlungseinheit 502, werden in die Datensatzinformations- Erzeugungseinheit 503 eingegeben, und in die Datensatz-Daten umgewandelt, in einem Format, das für das durch diese Datensatzverwaltungsinformations-Erzeugungseinheit 503 verwendete Datensatzverwaltungsverfahren geeignet ist, und diese Datensatz-Daten werden zu der Datensatzverwaltungseinheit 510 gesendet, um so die Aktualisierung der neuesten Version durchzuführen.
Die Datenspeichereinheit 511 speichert die Dateiinhalte einer Vielzahl von Dateien.
Als nächstes wird der Betrieb für jedes Element in diesem Asynchroneditiersystem, in Fig. 5 gezeigt, für bestimmte Datensatzverwaltungsverfahren beschrieben. In jedem Fall führt die Editierprozedur-Erzeugungseinheit 501 den Betrieb gemäß dem "diff"-Befehl von UNIX aus. Dabei vergleicht die Editierprozedur-Erzeugungseinheit 501 die Datei-Daten in der Editier-Zielversion und die Datei-Daten nach der Editierung, und gibt die Editierprozedurdaten aus, wie beispielsweise "was ist wo eingefügt" und "von wo bis wo ist gelöscht".
Zuerst wird ein Fall mit Bezug auf eine beispielhafte Situation beschrieben, die in Fig. 6 gezeigt ist, bei dem das Differenzstapelverfahren von Fig. 2, oben beschrieben, als Datensatzverwaltungsverfahren verwendet wird.
In diesem Beispiel ist die Editierzielversion die Version V.2 und die momentane Version ist die Version V.4. Dann wird angenommen, dass die Ausgabe Δ1 der Editierprozedur- Erzeugungseinheit 501 wie folgt ist.
* i4 Von hier neu eingefügt. Kann es gut eingefügt werden? * d8, 9
Diese Ausgabe zeigt an, dass, mit Bezug auf die Version V.2 zwei Z eilen ("Von hier neu eingefügt." und "Kann es gut eingefügt werden?") an der Zeile 4 eingefügt werden, und zwei Zeilen von der Zeile 8 bis zur Zeile 9 gelöscht werden.
Die Editierprozedur-Umwandlungseinheit 502 wird veranlasst, die oben beschriebene Editierprozedurdaten Δ1 in Editierprozedurdaten Δ1' mit Bezug auf die momentane Version V.4 umzuwandeln. Bei dieser Umwandlung sind die Datensatz- Daten von der Datensatzverwaltungseinheit 510 notwendig, die die vergangenen Datensätze von Editierungen bezeichnen, die von der Version V.2 bis zu der momentanen Version V.4 getätigt wurden.
Als ein Beispiel wird angenommen, dass die Version V.3 die Zeile 2 und die Zeile 3 der Version V.2 gelöscht aufweist, und eine Zeile ("dies ist Zeile 5 von V.2.") an der Zeile 5 der Version V.2 eingefügt aufweist, während die Version V.4 die Zeile 5 bis zur Zeile 7 der Version V.3 gelöscht aufweist, und zwei Zeilen ("Dieser Teil ist geändert, auf diese // Weise, wie ich sie nicht mag.", wobei // die Zeilenänderung anzeigt) an der Zeile 8 der Version V.3 eingefügt aufweist. In diesem Fall ist es für die Einfügungsposition in der Editierprozedur Δ1 notwendig, zu bestimmen, welche Zeile der momentanen Version V.4 die Zeile 4 der Version V.2 entspricht. In dieser Hinsicht enthält die Differenz zwischen Versionen V.3 und V.2 und die Differenz zwischen Versionen V.4 und V.3 alle notwendige Information, und es kann festgestellt werden, dass die Zeile 2 der Version V.4 der Zeile 4 der Version V.2 entspricht, sodass "füge zwei Zeilen an der Zeile 4 der Version V.2 ein" in "füge zwei Zeilen an der Zeile 2 der Version V.4 ein" entsprechend umgewandelt wird. Auf ähnliche Weise kann bei der Löschung, wenn die Zeilen der Version V.4, die den Zeilen 8 und 9 der Version V.2 in Übereinstimmung mit den Datensatz-Daten überprüft werden, festgestellt werden, dass die Zeile 9 der Version V.2 der Zeile 7 der Version V.4 entspricht, jedoch die Zeile 8 der Version V.2 in der Version V.4 bereits gelöscht wurde. Diese Löschung eines Teils, der bereits gelöscht wurde, macht normalerweise keinen Sinn, so dass "lösche Zeile 8 bis zur Zeile 9 der Version V.2" in diesem Fall umgewandelt wird in "lösche die Zeile 7 der Version V.4". Die Editierprozedur-Umwandlungseinheit 502 führt die Umwandlung der Editierprozeduren (hauptsächlich die Suche der geänderten Positionen umfassend) wie oben beschrieben durch. Somit sind die Datensatz-Daten bei dieser Editierprozedur- Umwandlungseinheit 502 unerlässlich.
Die Datensatzverwaltungsinformations-Erzeugungseinheit 503 erlangt die Differenz zwischen der momentanen Version V.4 und der neuen Version entsprechend der Editierprozedurdaten Δ1',. die so erlangt und dorthin eingefügt wurden. Dabei wird, da das Differenzstapelverfahren als das Datensatzverwaltungsverfahren verwendet wird, das oben erwähnte "füge zwei Zeilen an der Zeile 2 der Version V.4" und "lösche die Zeile 7 der Version V.4" in die Datensatz- Daten umgewandelt, so wie sie sind, und diese Datensatz-Daten werden zu der Datensatzverwaltungseinheit 510 übermittelt, und dem gespeicherten Datensatz hinzugefügt.
Als nächstes wird ein Fall einer Verwendung des oben beschriebenen modifizierten SCCS-Verfahrens von Fig. 4 als das Datensatzverwaltungsverfahren mit Bezug auf eine in Fig. 4 gezeigte beispielhafte Situation beschrieben. In diesem Fall kann der Betrieb bei einem Suchen der geänderten Positionen an der Editierprozedur-Umwandlungseinheit 502 wie folgt vereinfacht werden.
Es wird dabei angenommen, dass die Version V.2 10 Zeilen aufwies, wie in Fig. 7 gezeigt. Dann wird zuerst, da die Zeile 2 und die Zeile 3 der Version V.2 in der Version V.3 gelöscht sind, der Bereich dieser Zeilen 2 und 3 zu einem Block, wobei das Löschungszeit-Flag "V.3" anzeigt. Weiter wird, da eine Zeile zwischen der Zeile 4 und der Zeile 5 der Version V.2 eingefügt ist, die Zeile 4 der Version V.2 zu einem Block, während eine Zeile, die in der Version V.3 eingefügt ist, zu einem weiteren Block wird, mit dem Erzeugungszeit-Flag, das "V.3" anzeigt.
Als nächstes, da die Zeile 5 bis zur Zeile 7 der Version V.3 in der Version V.4 gelöscht werden, wird die Zeile 5 bis zur Zeile 7 in der Version V.3, durch ein Zählen nur solcher Zeilen, die zu einem Zeitpunkt der Version V.3 von oben nicht gelöscht sind, zu einem Block, mit dem Löschungszeit-Flag, das "V.4" anzeigt. Weiter, da zwei Zeilen zwischen der Zeile 7 und der Zeile 8 der Version V.3 eingefügt sind, bilden diese zwei eingefügten Zeilen einen Block mit dem Erzeugungszeit-Flag, das "V.4" anzeigt.
Die von der Editierprozedur-Erzeugungseinheit 501 ausgegebene Editierprozedur A1 ist ähnlich zu der oben beschriebenen, jedoch werden die Datensatz-Daten, die von der Datensatzverwaltungseinheit 510 der Editierprozedur- Umwandlungseinheit 502 geliefert werden, in einer Form der Version V.4 in Fig. 4 gegeben. Dann werden an der Editierprozedur-Erzeugungseinheit 502, um die Zeile 4 (Einfügungsposition), die Zeile 8 (Löschungsstartposition), und die Zeile 9 (Löschungsendposition) zum Zeitpunkt der Version V.2 zu bestimmen, die vierte, achte und neunte Zeile von oben in der Version V.2 herausgesucht. Hier ist es der entscheidende Punkt, solche Abschnitte zu überspringen, die nach der Version V.2 eingefügt sind.
An der so bestimmten Einfügungsposition werden die zwei neu eingefügten Zeilen ("neu von hier eingefügt. // Kann es gut eingefügt werden?") als ein Block eingefügt. Zusätzlich wird hinsichtlich der Löschung nichts für die Zeile 8 der Version V.2 vorgenommen, da das Löschzeit-Flag für diese bereits gesetzt wurde, während die Zeile 9 als ein Block mit dem Löschungszeit-Flag, das "V.5" anzeigt, aufgeteilt wird. Die auf diese Weise erzeugte Version V.5 wird dann zu der Datensatzverwaltungseinheit 510 gesendet, um die gespeicherten Datensatz-Daten zu aktualisieren.
Die Datensatzverwaltungsinformations-Erzeugungseinheit 503 berücksichtigt den Betrieb bis zur Aktualisierung an der Datensatzverwaltungseinheit 510 in der oben beschriebenen Sequenz.
Wenn ein Verfahren wie beispielsweise das modifizierte SCCS- Verfahren als das Datensatzverwaltungsverfahren verwendet wird, kann, wie erläutert, die Suche der geänderten Position durch ein einfaches Zählen von oben erzielt werden, so dass der notwendige Betrieb beträchtlich vereinfacht werden kann.
Das heißt, es ist im ersten Ausführungsbeispiel möglich, die Datenstruktur von Fig. 4 für das modifizierte SCCS-Verfahren als das Datensatzverwaltungsverfahren zu verwenden, während das asynchrone Editieren entsprechend der Konfiguration von Fig. 5 zu gleichen Zeit realisiert wird.
Nunmehr wird ein weiteres Merkmal dieses ersten Ausführungsbeispiels betreffend eines Verschlüsselungsverfahrens für die Datei-Daten detailliert erläutert.
Das Verschlüsselungsverfahren in diesem ersten Ausführungsbeispiel ist durch die Tatsache gekennzeichnet, dass die Datei in Einheiten von Datenblöcken verschlüsselt/entschlüsselt ist, erzeugt bei einem Ablauf der Datensatzverwaltung, wie oben beschrieben, Block für Block, und dass die Dateistruktur verwendet wird, die es dem Server ermöglicht, zu verstehen, welcher Datenblock zu welchem Bereich der Datei gehört.
Genauer gesagt wird als ein Beispiel solch einer Dateistruktur, im Falle einer Verwendung des Differenzstapelverfahrens von Fig. 2 als das Datensatzverwaltungsverfahren, jeder der Blöcke 201, 202, 203 und 204 unabhängig verschlüsselt und in einer Form bereitgestellt, mit der der Server das Entsprechungsverhältnis erkennen kann, wie beispielsweise "ein Block 201 zeigt die verschlüsselten Daten für die erste Version V.1", "ein Block 202 zeigt die verschlüsselten Daten der Differenz V.2-V.1 zwischen der Version V.2 und der Version V.1", etc. Als ein konkretes Beispiel ist es möglich, ein Flag-Feld für die Serververwaltung für jeden zu verschlüsselnden Block bereitzustellen, und eine geeignete Information wie beispielsweise V.1 oder V.2-V.1 darin einzufügen.
Solch eine durch den Server zur Identifizierung jedes Datenblocks zu verwendende Information wird als die Blockidentifikationsinformation bezeichnet. Das Flag-Feld für die oben erwähnte Serververwaltung, und die Datenfelder 406 und 407 für die Erzeugungszeit und die Löschungszeit in Figur
4, oben beschrieben, sind Beispiele dieser Blockidentifikationsinformation.
Als ein weiteres Beispiel der Dateistruktur, im Falle einer Verwendung des RCS-Verfahrens von Fig. 3 als das Datensatzverwaltungsverfahren, ist jeder der Blöcke 301, 302, 303 und 304 unabhängig verschlüsselt, und in einer Form bereitgestellt, mit der der Server das Entsprechungsverhältnis erkennen kann, wie beispielsweise "ein Block 301 zeigt die verschlüsselten Daten der Differenz V.1-V.2", "ein Block 302 zeigt die verschlüsselten Daten der Differenz V.2-V.3", etc.
Als noch ein weiteres Beispiel dieser Dateistruktur, im Falle eines Verwendens des modifizierten SCCS-Verfahrens von Fig. 4 als das Datensatzverwaltungsverfahren, ist jeder der Blöcke 401, 402, 403 und 404 unabhängig verschlüsselt, und in einer Form bereitgestellt, mit der der Server das Entsprechungsverhältnis erkennen kann, wie beispielsweise "ein Block 401 ist ein oberster Block, ein Block 402 ist ein dem obersten Block folgender Block", etc. Hier ist es ausreichend, einfach Blöcke so zu verbinden, dass die Trennungen zwischen den Blöcken ersichtlich werden. Jeder Block in Fig. 4 weist zwei Datenfelder 406 und 407 für die Erzeugungszeit und die Löschzeit in Übereinstimmung mit dem obig erwähnten auf, jedoch sind diese Datenfelder nicht zu verschlüsseln.
Diese Art und Weise zum unabhängigen Verschlüsseln jedes Datenblocks hat den Vorteil, dass der am Client erforderliche Verarbeitungsaufwand und der Kommunikationsaufwand zwischen dem Client und dem Server verringert ist. Wenn nämlich der Client eine Anforderung hinsichtlich der momentanen Version zum Server im Datensatzverwaltungssystem von Fig. 3 tätigt, ist es für den Server ausreichend, alleine den verschlüsselten Block 304 zu übertragen. Falls im Gegensatz dazu die gesamten Datei-Daten von Fig. 3 gemeinsam verschlüsselt sind, wäre es notwendig, dass der Server die gesamten verschlüsselten Daten überträgt, und zusätzlich wäre es weiter notwendig, dass der Client, der diese übermittelten Daten empfangen hat, alle Blöcke 301 bis 304, die miteinander verschlüsselt sind, entschlüsselt, sodass viele andernfalls nicht notwendige Verarbeitungsschritte notwendig werden würden.
Weiter ist beim Datensatzverwaltungsverfahren von Fig. 2 nur eine Änderung, die durch die Client-Seite als ein Ergebnis einer neuen Editieraktion getätigt werden kann, eine Hinzfügung eines verschlüsselten Blocks für die Differenz V.5-V.4. In solch einem Fall, falls die gesamte Datei gemeinsam verschlüsselt wäre, wäre es besonders schwierig, zu verifizieren, dass ein Abschnitt nahe des Abschnitts mit Bezug auf die Differenz V.4-V.3 nicht geändert wurde. Die Verschlüsselung wird nämlich normalerweise von einem Beginn der Datei getätigt, in einer Form einer Kette von bestimmten die Datei unterteilenden Längen, sodass es dem Server möglich ist, das Auftreten einer Aktion zur Änderung eines sich vom Bereich nahe dem Ende der Datei befindlichen Abschnitt aus dem chiffrierten Text zu vermuten, jedoch ist solch eine Erfassung eine Änderung nicht am Bereich nahe dem Ende der Datei möglich (d. h. einem Abschnitt nahe der neu hinzugefügten Differenz). Im Gegensatz dazu, wenn das Verschlüsseln in Einheiten von Blöcken vorgenommen wird, wie oben beschrieben, für die Dateistruktur von Fig. 2, reicht es aus, sequentiell die verschlüsselten Daten für eine neue Differenz hinzuzufügen, sodass der Server die Verwaltung zur Verhinderung der Änderung der Datensätze einfach durchführen kann.
Im Hinblick auf eine Realisierung der asynchronen Editierung ohne Verriegelung, wie oben beschrieben, ist es insbesondere geeignet, das Datensatzverwaltungsverfahren zu verwenden, das die Dateistruktur von Fig. 4 verwendet, sogar von einem Gesichtspunkt der Vereinfachung einer Einfügungsverarbeitung. Es weist dieser Typ von Datensatzverwaltungsverfahren jedoch eine Eigenschaft darin auf, dass der Block, der zu einem Zeitpunkt eine abgeschlossene Einheit gebildet hat, nachfolgend an nachfolgenden Zeitpunkten unterteilt werden wirt Allgemein ergibt sich in Verbindung mit der Unterteilung eines Blockes eine Notwendigkeit, die Blockdaten erneut zu verschlüsseln, und aus diesem Grund verwendet dieses erste Ausführungsbeispiel das Verschlüsselungsverfahren, das die Verschlüsselungs- /Entschlüsselungs-Verarbeitung reduzieren kann, was nun detailliert erläutert werden wird.
Die Daten innerhalb jedes Blocks können als durch Bits oder Bytes als Minimaleinheiten gegeben verstanden werden, und in dem ersten Verschlüsselungsverfahren für dieses erste Ausführungsbeispiel, unterhalb beschrieben, in einem Fall einer Unterteilung eines Blocks an mehreren Positionen (Punkt-1, Punkt-2, und so weiter, in einer Reihenfolge von dem Anfang des Blocks), ist es nicht notwendig, die verschlüsselten Daten vom Beginn des Blocks zum Punkt-1 erneut zu verschlüsseln, und die bereits verschlüsselten Daten können so verwendet werden wie sie sind, sodass nur die Daten nach dem Punkt-1 erneut verschlüsselt werden müssen.
Darüber hinaus besteht beim zweiten Verschlüsselungsverfahren für dieses erste Ausführungsbeispiel, unterhalb beschrieben, absolut keine Notwendigkeit für eine erneute Verschlüsselung irgendwelcher Daten, und die bereits verschlüsselten Daten können so verwendet werden wie sie sind.
Um solch eine erneute Verwendung der bereits verschlüsselten Daten möglich zu machen, muss das Verschlüsselungsverfahren die folgende Bedingung erfüllen. Im Falle dass der Chiffrierblock an einem beliebigen Punkt unterteilt ist, muss es möglich sein, den entsprechenden Klartext aus einem Fragment dieses unterteilten verschlüsselten Blocks zu erlangen. Demzufolge ist es notwendig, dass ein bestimmtes Bit (oder Byte) des Klartextes einem bestimmten Bit (oder Byte) des verschlüsselten Textes entspricht. Als eine natürliche Konsequenz dieser Tatsache, sollte aufgrund der Verschlüsselung keine Größenerhöhung stattfinden. Als ein Verschlüsselungsverfahren mit solch einer Eigenschaft ist ein als Stromverschlüsselungsverfahren bezeichnetes Verfahren bekannt, und ein veranschaulichendes Beispiel dieses Verfahrens ist ein Verfahren zur Verwendung des Blockverschlüsselungs-DES (Datenverschlüsselungsstandard) in entweder dem OFB-(Ausgaberückführungs-)Modus oder dem CFB- (Verschlüsselungsrückführungs-)Modus. Die Verschlüsselungsprozedur in dem OFB-Modus ist in Fig. 8 gezeigt, während die Verschlüsselungsprozedur in dem CFB- Modus ist, in Fig. 9 gezeigt ist.
Als erstes wird mit Bezug auf Fig. 8 das Betriebsprinzip in dem OFB-Modus erläutert. In diesem Fall werden die übertragende Seite und die empfangende Seite einen Schlüssel K für die Blockchiffriervorrichtungen 603 und 613 und einen anfänglichen Wert IV für die Schieberegister 602 und 612, einzustellen in Anfangswertregister 601 und 611, gemeinsam nutzen.
Zu einem Zeitpunkt einer Verschlüsselung verschlüsselt die übertragende Seite einen Inhalt des Schieberegisters 602 durch die Blockverschlüsselungsvorrichtung 603, und L-Bits des erhaltenen verschlüsselten Ergebnisses in dem Verschlüsselungsergebnisregister 604 werden zum Schieberegister 602 zurückgeführt, während sie ebenso der Exklusiv-ODER-Operation mit Bezug auf L-Bits des Klartextes an der XOR-Schaltung 605 unterzogen werden. Durch ein Wiederholen dieser Verarbeitung wird der Klartext in Einheiten von L-Bits verschlüsselt. Hier wird, auch wenn eine durch eine Verarbeitung zu verschlüsselnde Größe L-Bits ist, die Verschlüsselung tatsächlich Bit um Bit getätigt.
Zum Zeitpunkt einer Entschlüsselung entschlüsselt die empfangende Seite auf ähnliche Weise einen Inhalt für das Schieberegister 612 durch die Blockverschlüsselungsvorrichtung 613, und L-Bits des erhaltenen verschlüsselten Ergebnisses in dem Verschlüsselungsergebnisregister 614 werden zum Schieberegister 612 zurückgeführt, während sie ebenso der Exklusiv-ODER-Operation mit Bezug auf L-Bits des chiffrierten Textes an der XOR-Schaltung 615 unterzogen werden. Durch ein Wiederholen dieser Verarbeitung wird der verschlüsselte Text in Einheiten von L-Bits entschlüsselt. Wiederum, auch obwohl eine durch eine Verarbeitung zu entschlüsselnde Größe L-Bits ist, wird die Entschlüsselung tatsächlich Bit um Bit durchgeführt.
Als erstes wird mit Bezug auf Fig. 9 das Arbeitsprinzip in dem CFB-Modus erläutert. In diesem Fall nutzen die übertragende Seite und die empfangende Seite einen Schlüssel K für die Blockverschlüsselungsvorrichtungen 623 und 633 und einen anfänglichen Wert IV für Schieberegister 622 und 623, in Anfangswertregistern 621 und 631 einzustellen, gemeinsam.
Zum Zeitpunkt einer Verschlüsselung verschlüsselt die übertragende Seite einen Inhalt des Schieberegisters 622 durch die Blockverschlüsselungsvorrichtung 623, und L-Bits des erhaltenen verschlüsselten Ergebnisses in dem Verschlüsselungsergebnisregister 624 werden der Exklusiv- ODER-Operation mit Bezug auf L-Bits des Klartextes an der XOF; -Schaltung 625 unterzogen, während L-Bits des durch die XOR-Schaltung 625 erhaltenen chiffrierten Textes zum Schieberegister 622 zurückgeführt werden.
Zum Zeitpunkt einer Entschlüsselung entschlüsselt auf ähnliche Weise die empfangene Seite einen Inhalt des Schieberegisters 632 mit der Blockverschlüsselungsvorrichtung 633, und L-Bits des erhaltenen verschlüsselten Ergebnisses in dem Verschlüsselungsergebnisregister 634 werden der Exklusiv- ODER-Operation mit Bezug auf L-Bits des chiffrierten Textes an der XOR-Schaltung 635 unterzogen, während L-Bits des empfangenen chiffrierten Textes zu dem Schieberegister 632 zurückgeführt werden.
Somit unterscheidet sich dieser Fall eines CFB-Modus von dem oben beschriebenen Fall eines OFB-Modus nur darin, dass die zu dem Schieberegister zum Zeitpunkt einer Verschlüsselung-/Entschlüsselung zurückgeführten Daten der chiffrierte Text sein sollen, statt der Ausgabe der Bockchiffriervorrichtung, auf der übertragenen Seite, wie auch auf der empfangenen Seite.
Diese Moden werden L-Bit-OFB-Modus oder L-Bit-CFB-Modus genannt, und verwenden eine Anzahl von Bits, die bei einer Verschlüsselungs-/Entschlüsselungs-Verarbeitung verwendet werden, (was mit einer Anzahl von zu den Schieberegistern zurückzuführenden Bits übereinstimmt), was veranschaulichende Beispiele der Strom-Chiffrierung in einer Bit-Einheit darstellt. Auf ähnliche Weise enthalten die Beispiele der Stromverschlüsselung in Byte-Einheit einen 8-Bit-OFB-Modus und einen 8-Bit-CFB-Modus. In diese Moden, anstelle einer Verschlüsselung/Entschlüsselung durch Abnehmen des Exklusiv- ODERs von 8 Bits des Klartextes und 8 Bits der Verschlüsselungsvorrichtungsausgabe Bit um Bit, ist es auch möglich, diese so zu modifizieren, dass sie die Verschlüsselung/Entschlüsselung beispielsweise durch eine Addition/Subtraktion von 8 Bits verwenden.
Im folgenden wird angenommen, dass die Minimaleinheiten der Daten innerhalb jedes Blocks Bytes sind.
Um die Stärke des verschlüsselten Textes unter Verwendung der Stromverschlüsselung, wie oben beschrieben, sicherzustellen, wenn der Schlüssel K festgelegt ist, ist es vorzuziehen, den anfänglichen Wert IV des Schieberegisters für jeden Klartext zu ändern. Andernfalls weist der verschlüsselte Text Schwachpunkte darin auf, dass das Exklusiv-ODER von zwei Klartexten erhalten werden kann, indem das Exklusiv-ODER der gleichen Position in zwei verschlüsselten Texten vorgenommen wird, und dass die zwei Klartexte als die gleichen erkannt werden können, wenn zwei entsprechende verschlüsselte Texte den gleichen Anfangsabschnitt aufweisen. Aus diesem Grund wird bei diesem ersten Ausführungsbeispiel der Anfangswert IV des Schieberegisters für jeden zu verschlüsselnden/entschlüsselnden Block geändert.
Nunmehr wird die Verschlüsselungsprozedur in einem Fall der Blockdatenunterteilung unter Verwendung des Verschlüsselungsverfahrens dieses ersten Ausführungsbeispiels mit Bezug auf Fig. 10 erläutert. In dieser Fig. 10 zeigt eine linke Seite eines Pfeils die Datenstruktur vor der Blockdatenunterteilung, und die rechte Seite eines Pfeils zeigt die Dateistruktur nach der Blockdatenunterteilung. Hier zeigt Fig. 10 einen beispielhaften Fall, bei dem ein mittlerer Abschnitt eines bestimmten, verschlüsselten Blocks (Block-0) gelöscht ist, wobei in diesem Fall dieser Block als drei Blöcke erneut verschlüsselt wird, für den Anfangsabschnitt (Block-1), den Mittelabschnitt (Block-2) und dem unteren Abschnitt (Block-3). Für jeden Block wird ein Bereich 642 bereitgestellt, um die Anfangswertdaten IV (IV0 bis IV2) zu speichern. Diese Anfangswertdaten IV sind jedoch nicht zu verschlüsseln.
Im ersten Verschlüsselungsverfahren dieses ersten Ausführungsbeispiels wird der L-Bit-OFB-Modus oder der L-Bit- CFB-Modus verwendet, wobei L auf ein Multiples von 8 eingestellt ist. Die Anfangswertdaten IV jedes Blocks werden mittels der Zufallszahlenerzeugung zum Zeitpunkt einer neuen Blockerzeugung erzeugt. Die Blockdaten werden L-Bits um L- Bits verschlüsselt, um eine Reihenfolge vom Beginn an, wie oben beschrieben. Dies ist ein Fall, bei dem das Ende des Blocks nicht mit dem L-ten Bit genau übereinstimmt, jedoch wird auch in einem solchen Fall die Verschlüsselung an der Länge des Klartextes abgeschnitten. Es ist auch in solch einem Fall immer noch möglich, den letzten Abschnitt zu entschlüsseln.
Die Verschlüsselungsprozedur in einem Fall der Blockdatenunterteilung, wie in Fig. 10 gezeigt, wird mit Bezug auf das Flussdiagramm von Fig. 11 erläutert.
Zuerst wird der Anfangsbereich vor der Löschungsstartposition als ein Block (Block-1) so wie er ist, abgetrennt (Schritt S1). Dann wird der Anfangswert IV1 mittels der Zufallszahlerzeugung (Schritt S2) bestimmt, und durch den OFB (oder CFB) Modus unter Verwendung dieses anfänglichen Wertes IV1, werden Daten des gelöschten Abschnitts (Klartext entsprechend Block-2) verschlüsselt, um einen neuen Block (Block-2) zu bilden (Schritt S3). Als nächstes wird ein weiterer anfänglicher Wert IV2 bestimmt (Schritt S4), und Daten des unteren Abschnitts werden verschlüsselt, um einen neuen Block (Block-3) zu bilden (Schritt S5).
Diese Verschlüsselungsprozedur ist durch die Tatsache gekennzeichnet, dass der Block des oberen Abschnitts den ursprünglichen anfänglichen Wert IV0 verwendet, so wie er ist, so dass es keine Notwendigkeit einer erneuten Verschlüsselung des Blocks gibt.
Als nächstes wird das zweite Verschlüsselungsverfahren des ersten Ausführungsbeispiels beschrieben, was durch die Tatsache gekennzeichnet ist, dass es überhaupt keine Notwendigkeit gibt, irgendwelche Taten erneut zu verschlüsseln. In diesem Fall wird der 8-Bit-CFB-Modus verwendet.
Mit Bezug auf einen neuen Einfügungsblock werden die Anfangswertdaten IV mittels der Zufallszahlenerzeugung erzeugt, und die Blockdaten werden Byte um Byte in einer Reihenfolge vom Beginn an verschlüsselt.
Die Verschlüsselungsprozedur im Falle einer Blockdatenunterteilung, wie in Fig. 10 gezeigt, wird mit Bezug auf das Flussdiagramm von Fig. 12 erläutert.
Zuerst wird der Verschlüsselungsblock (Block-0) an individuellen Unterteilungspositionen (Schritt S1) in drei unterteilt. Als nächstes werden die letzten 8 Bytes des Blocks-1 als die Anfangswertdaten IV des Blocks-2 (Schritt S12) gespeichert. Dann werden die letzten 8 Bytes des Blocks- 2 als die Anfangswertdaten IV des Blocks-3 (Schritt S13) gespeichert. Im Falle einer Speicherung der Anfangswertdaten IV in den Schritten S12 und 513 kann es einen Fall geben, bei dem der vorhergehende Block kleiner als 8 Bytes lang ist. In solch einem Fall ist es notwendig, eine gesonderte Behandlung zu verwenden, bei der der vorhergehende Block als Anfangswertdaten IV + Blockdaten betrachtet wird, sodass die Blockdaten durch so viele Bytes der Anfangswertdaten IV aufgefüllt werden können, wie notwendig.
Dieses zweite Verschlüsselungsverfahren nutzt die Eigenschaft des 8-Bit-CFB-Modus, dass die Entschlüsselung von einer beliebigen Position aus getätigt werden kann, und hat einen Vorteil darin, dass die erneute Verschlüsselung in Verbindung mit der Blockunterteilung völlig unnötig wird. Dieser Vorteil impliziert weiter, dass im Falle einer Realisierung des verschlüsselten geteilten Dateisystems durch das Client- Server-System, der Server ohne die Verschlüsselungs-/Entschlüsselungsfunktion die Blockunterteilungsverarbeitung durchführen kann, sodass die effiziente Realisierung des Systems möglich wird. Es ist weiter möglich, die obige Verschlüsselungsprozedur auf den allgemeinen L-Bit-CFB-Modus zu erweitern (wobei L als ein Multiples von 8 eingestellt ist), jedoch werden zu diesem Zweck die Zusatzdaten notwendig, da es einen Fall geben kann, bei dem der Block-2 von Fig. 10 nicht an der Partition bei L- Bits vom Beginn des ursprünglichen Blocks-0 beginnt. Die Daten des Blocks-2 werden in Einheiten von L-Bits vom Beginn des Blocks-0 verschlüsselt, so dass es notwendig ist, es möglich zu machen, die ursprünglichen Partitionen in Einheiten von L-Bits zu reproduzieren. In dieser Hinsicht werden u-Bits (u ist eine ganze Zahl für die u 5 L) vom Beginn des Blocks als die zusätzlichen Daten verwendet, um anzuzeigen, dass es ein fragmentarischer Block ist, und zum Zeitpunkt einer Entschlüsselung wird er entschlüsselt, nachdem der chiffrierte Text von (L-u) Bits als ein Dummy am Beginn der Blockdaten hinzugefügt sind, und die obersten (Lu) Bits im entschlüsselten Ergebnis werden ignoriert. Die nachfolgenden Daten können in Einheiten von L-Bits entschlüsselt werden. Weiter werden die Anfangswertdaten IV, zum Zeitpunkt der Blockunterteilung zu speichern, so gesetzt, dass sie ein Inhalt von 8 Bytes sind, unmittelbar vor den fragmentarischen Bits (L-u Bits) am Ende des vorhergehenden Blocks. Im Falle dass der vorhergehende Block zu kurz ist, genauso wie in einem ähnlichen Fall des 8-Bit-CFB-Modus, oben erläutert, können die Blockdaten durch die Anfangswertdaten IV ergänzt werden, so weit wie dies nötig ist.
Im obigen wurde ein Fall der Blockunterteilung in Verbindung mit der Löschung erläutert, jedoch wird es bei einem Fall der Einfügung wie folgt sein. Im Falle einer Einfügung eines bestimmten Blocks in einer Mitte eines bereits existierenden Blocks ergibt sich nämlich eine Notwendigkeit für eine Unierteilung des bereits existierenden Blocks entsprechend der Prozedur von Fig. 11 oder Fig. 12, oben erläutert, und auch für die Verschlüsselung von neuen Einfügungsblockdaten. Hier wird die Verschlüsselung eines neuen Einfügungsabschnitts getätigt, in den der Anfangswert IV mittels der Zufallszahlenerzeugung bestimmt wird, und dann durch Verwenden des OFB (oder CFB) Modus unter Verwendung dieses Anfangswertes IV. Weiter ist im Falle einer Einfügung eines bestimmten Blocks zwischen drei existierenden Blöcken keine Änderung für die bereits existierenden Blöcke notwendig, und es ist ausreichend, alleinig den neuen Einfügungsblock zu verschlüsseln.
Im folgenden werden die Merkmale des Datensatzverwaltungsverfahrens gemäß dieses ersten Ausführungsbeispiels zusammengefasst. Hier wird das gemeinsame Dateieditiersystem unter Verwendung des in Fig. 2 gezeigten Verschlüsselungsdifferenzstapelverfahrens, das gemeinsame Dateieditiersystem unter Verwendung des in Fig. 3 gezeigten verschlüsselten RCS-Verfahrens, und das gemeinsame Dateieditiersystem unter Verwendung des in Fig. 4 gezeigten Verschlüsselungs-SCCS-Verfahrens verglichen.
Zuerst ist hinsichtlich der asynchronen Editierfunktion ohne Verriegelung das Verschlüsselungs-SCCS-Verfahren vorteilhaft, da die Verbindungssverarbeitung vereinfacht werden kann, wie bereits oben erläutert.
Weiter ist hinsichtlich des Herausziehens der momentanen Version das Verschlüsselungs-RCS-Verfahren höchst vorteilhaft, da es die momentane Version so speichert, wie sie ist, in einer Form von verschlüsselten Daten. Das Verschlüsselungs-SCCS-Verfahren ist als nächstes vorteilhaft, und weist eine Eigenschaft darin auf, dass eine beliebige Version durch den gleichen Verarbeitungsaufwand wiederhergestellt werden kann.
Weiter ist hinsichtlich eines Falles, in dem es wünschenswert ist, die alten Datensätze zu löschen, um die Dateigröße zu kontrollieren, das Verschlüsselungs-RCS-Verfahren und das Verschlüsselungs-SCCS-Verfahren, beide überlegen. Dieses rührt daher, dass bei diesem Verfahren der Server, der in dies er Hinsicht eine Anforderung empfangen hat, die Datensätze selbst löschen kann. Bei den Verschlüsselungsdifferenz-Stapelverfahren können die alten Datensätze durch eine Interaktion vom Client gelöscht werden.
Es sollte hier darauf hingewiesen werden, dass im Falle des Verschlüsselungs-SCCS-Verfahrens die Fusion der Blöcke nicht stattfindet, auch wenn die alten Datensätze gelöscht werden, und nur die Separierung von nicht notwendigen Blöcken durchgeführt wird. Auch im Falle eines Durchführens der Fusion der Blöcke wird die Interaktion vom Client notwendig. Weiter sollte darauf hingewiesen werden, dass beim Verschlüsselungs-RCS-Verfahren der Server selbst das Löschen der Datensätze in einer Reihenfolge von der älteren Seite ausgehend durchführen kann.
Es ist vorzuziehen, den nicht nachher zu verändernden Datensatzinhalt zu verwalten, und hinsichtlich solch einer Vollständigkeit des Datensatzinhaltes ist das Verschlüsselungsdifferenz-Stapelverfahren überlegen. Wie vorher erläutert, ist es dem Client nur erlaubt, sequentiell Differenzen in diesem Verfahren hinzuzufügen, sodass die Vollständigkeit der Datensätze garantiert werden kann.
Wie oben erläutert, wird es durch ein Anwenden einer oder beider der charakteristischen Merkmale des ersten Ausführungsbeispiels möglich, ein gemeinsames Dateieditiersystem bereitzustellen, das die Dateiversionsverwaltung unterstützt, das das asynchrone Editieren realisieren kann, während die Dateiinhalte vor dem Datei-Server geheimgehalten werden, oder ein gemeinsames Dateieditiersystem, das die Dateiversionsverwaltung unterstützt, das ein Realisieren des asynchronen Editierens ermöglichen kann, oder ein Dateieditiersystem, das ein höheres Niveau einer Sicherheit realisieren kann, so dass die Dateiinhalte nicht vom Datei-Server ausgelesen werden können.
Oben ist beim Verschlüsseln der strukturierten Dateien der Dateiinhalt so verschlüsselt, dass nur der Client ihn verschlüsseln/entschlüsseln kann, es ist jedoch die Datenstruktur in einem Format gezeigt, das auch durch den Server erkannt werden kann, und insbesondere wurden Anwendungen auf die Versionsverwaltung und das asynchrone Editieren beschrieben. Die vorliegende Erfindung ist auf verschiedene andere Systeme und Verfahren anwendbar, wie beispielsweise ein Verfahren zum Verschlüsseln des Programms in Einheiten von Subroutinen, und ein Verfahren zum Handhaben einer Vielzahl von Daten-Dateien, die miteinander in dem Hyper-Text verknüpft sind, wobei die Daten-Dateien in Einheiten von Daten-Dateien verschlüsselt sind, und verknüpfte Abschnitte nicht verschlüsselt sind. Auf diese Weise wird es möglich, eine effiziente Nutzungsweise zu realisieren, bei der der Client nur den notwendigen Bereich auslesen kann, während die Sicherheit des Modulinhalts mit Bezug auf den Server aufrechterhalten wird.
Als nächstes wird das zweite Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert beschrieben, bei dem das oben beschriebene erste Merkmal bezüglich der Dateiinhaltsgeheimhaltung mit Bezug auf den Server und die oben beschriebene zweite Eigenschaft bezüglich der asynchronen Editierung auf dem Client-Serversystem implementiert sind.
In diesem zweiten Ausführungsbeispiel sind die einzelnen Merkmale bezüglich Dateistruktur, des Datensatzverwaltungsverfahrens, des Verschlüsselungsverfahrens und des asynchronen Editiersystems im wesentlichen die gleichen wie die für das erste oben beschriebenen Ausführungsbeispiel, und deren detaillierte Beschreibungen werden hier nicht wiederholt. Im folgenden wird die Konfiguration und die Betriebscharakteristik dieses zweiten Ausführungsbeispiels erläutert.
Fig. 13 zeigt eine erste Konfiguration des gemeinsamen Dateieditiersystems dieses zweiten Ausführungsbeispiels, das allgemein eine Vielzahl von Clients 91 und einen Server 90 umfasst.
Der Server 90 umfasst weiter eine Kommunikations-(COMM-) Einheit 131 zum Durchführen einer Kommunikation mit jedem Client 91 über einen Kommunikationspfad 111, eine Datensatzverwaltungseinheit (für gemeinsam genutzte Dateien) 510 zum Verwalten von Datensätzen von gemeinsam genutzten Dateien, und eine Datenspeichereinheit 511 zum Speichern einer Vielzahl von Dateien, wobei die Datensatzverwaltungseinheit 510 und die Datenspeichereinheit 511 der Datensatzverwaltungseinheit 510 und der Datenspeichereinheit 511 beim asynchronen Editiersystem aus Fig. 5, oben beschrieben, entsprechen.
Auf der anderen Seite umfasst jeder Client 91 weiter eine Kommunikations-(COMM-)Einheit 130 zum Durchführen einer Kommunikation mit dem Server 90 über den Kommunikationspfad 111, einen Speicher 121 zum Speichern von von dem Server 90 erhaltenen Dateien, eine gemeinsame Dateieditiereinheit 122 zum Editieren der gemeinsam genutzten Dateien, und eine Chiffriereinheit 112 zum Verschlüsseln/Entschlüsseln der Dateien.
Wie in Fig. 14 gezeigt, umfasst die gemeinsame Dateieditiereinheit 122 die Editiereinheit 500, die Editierprozedur-Erzeugungseinheit 501, die Editierprozedur- Umwandlungseinheit 502, und die
Datensatzverwaltungsinformations-Erzeugungseinheit 503 entsprechend denen beim oben beschriebenen asynchronen Editiersystem von Fig. 5.
Wie in Fig. 15 gezeigt, umfasst die Chiffriereinheit 112 eine Kommunikations-(COMM-)Einheit 132, die mit der gemeinsamen Editiereinheit 122 verbunden ist, eine Verschlüsselungs-/Entschlüsselungs-Verarbeitungseinheit 1121, die mit der Kommunikationseinheit 132 verbunden ist, und eine Schlüsselspeichereinheit 1122, die mit der Verschlüsselungs-/Entschlüsselungs-Verarbeitungseinheit 1121 verbunden ist.
Da eine Vielzahl von Clients in diesem zweiten Ausführungsbeispiel bereitgestellt ist, treten nunmehr zu verschiedenen Zeiten Anfragen für die folgenden drei Typen von Betriebsvorgängen auf:
(a) Ein Lesen von Datei-Daten einer bestimmten Version (Pfeil von 510 zu 500 in Fig. 5);
(b) Ein Schreiben einer Datensatzverwaltungsinformation, die ein Editierergebnis ist (Pfeil von 503 nach 510 in Fig. 5); und
(c) Ein Lesen von Datensatz-Daten, notwendig bei einem Umwandeln der Editierprozedur (Pfeil von 510 nach 502 in Fig. 5).
Hier wird eine allgemeine Prozedur zum Handhaben dieser Anfragen in diesem zweiten Ausführungsbeispiel erläutert.
Wie oben beschrieben, umfasst die Editierprozedur entsprechend einer Datensatzverwaltungsinformation eine Kombination einer Vielzahl von Einfügungen und Löschungen, und es ist vorzuziehen, diese gemeinsam zu handhaben. Das heißt, wenn ein bestimmter Client 91 an einer Vielzahl von Positionen in der Datei bei einer bestimmten Version Änderungen vorgenommen hat, wird eine neue Version hergestellt, zu einem Zeitpunkt, an dem alle diese Änderungen in den Daten auf der Server-90-Seite wiedergespiegelt werden. Die Schreibanfragen für die Datensatzverwaltungsinformation wird eine nach der anderen in eine Warteschleife gesetzt, und sequentiell in die Datei-Daten wiedergespiegelt, so wie sie durch die Datensatzverwaltungseinheit 510 in einer First-in- First-Out Art und Weise sequentiell herausgezogen werden. Dabei antwortet die Datensatzverwaltungseinheit 510 auf die Leseanfragen ((a) und (c), oben erwähnt), von dem Client 91, wann immer dies nötig ist, wenn jedoch die Leseanfrage für die momentane Version einer Datei während der Aktualisierung der Datei-Daten für die gleiche Datei an der Datensatzverwaltungseinheit 510 ankommt, besteht eine Notwendigkeit, die Version vor der Aktualisierung zu übertragen.
Der Client 91 fordert die Daten einer bestimmten Version (Version X) anfänglich vom Server 90 an, und nach einer Speichern der Daten in dem Speicher 121 wird die Editierung an der Editiereinheit 500 ausgeführt, und die Editierprozedurdaten werden an der Editierprozedur- Erzeugungseinheit 501 erzeugt. Im Falle, dass sie Version X die neueste Version zu einem Zeitpunkt eines Lesens ist, wird die Editierprozedur nicht gewandelt, und die Datensatzverwaltungsinformation wird sofort erzeugt, und nachfolgend verschlüsselt und zum Server 90 übertragen. An der empfangenden Server-90-Seite wird beurteilt, ob es die Datensatzverwaltungsinformation ist, die mit der letzten Version zu diesem Zeitpunkt verbunden werden kann, oder nicht, und falls diese nicht verbunden werden kann, werden die Datensatz-Daten von der Datensatzverwaltungseinheit 510 zum Client 91 übermittelt, um die Umwandlung der Editierprozedur an der Editierprozedur-Umwandlungseinheit 502 anzufordern.
Dabei kann die Beurteilung, ob verbunden werden kann oder nicht, getätigt werden, indem eine Versionsnummer der Zieldaten zu einem Kopfbereich der Datensatzverwaltungsinformation, die an der Client-91-Seite zu übertragen ist, hinzugefügt wird, so dass die Server-90- Seite die Versionsnummer in den Kopfbereich mit der Versionsnummer der neuesten darin gespeicherten Version vergleichen kann, und beurteilen kann, dass verbunden werden kann, wenn sie übereinstimmen, und dass im anderen Fall nicht verbunden werden kann. Zusätzlich können die Datensatz-Daten, die zum Client 91 zu übermitteln sind, wenn sie nicht verbunden werden können, zum Beispiel die Datensatz-Daten zwischen der neuesten Version und der durch die Versionsnummer im Kopfbereich der Datensatzverwaltungsinformation angezeigten Version sein. An der Client-91-Seite wird die vorgegebene Editierprozedurumwandlung durchgeführt, um eine neue Datensatzverwaltungsinformation zu erzeugen, und diese wird wiederum zum Server 90 übermittelt, so dass die Server-90- Seite beurteilt, ob verbunden werden kann oder wiederum nicht.
Hier gibt es eine Möglichkeit, dass die neue Datensatzverwaltungsinformation wiederum nicht verbunden werden kann. Wenn nämlich die Dateiversion durch einen anderen Client während der Editierprozedur- Umwandlungsverarbeitung am Client 91 aktualisiert wurde. Demzufolge gibt es die Möglichkeit eines Zirkulierens durch die Schleife von 510 → 502 → 503 in Fig. 5 eine Anzahl von Male.
Um solch eine wiederholte Verarbeitung zu verhindern, ist es möglich, die Verriegelungsfunktion zu verwenden. Wenn nämlich zu einem Zeitpunkt, an dem die Datensatz-Daten zum Client 91 übermittelt werden, die Server-90-Seite die Verriegelung hinsichtlich der Aktualisierung der Datei-Daten setzt, und die Verriegelung zu einem Zeitpunkt freigibt, an dem die Aktualisierung der Datei-Daten beendet ist, nachdem die Datensatzverwaltungsinformation von diesem Client 91 empfangen wurde. Während die Verriegelung gesetzt ist, ist das Lesen der Editierzieldatei-Daten erlaubt, jedoch ist die andere Verarbeitung an der Server-90-Seite nicht erlaubt. Der andere Client 91, dessen Anfrage zurückgewiesen wurde, wird nach einer geeigneten Zeitspanne einen erneuten Versuch vornehmen. Hier kann die Wartezeitperiode während dieses Verriegelungsmechanismus als sehr kurz erachtet werden, jedoch ist dieser Verriegelungsmechanismus nicht absolut notwendig.
Auf der anderen Seite, im Falle dass die anfänglich vom Server 90 ausgelesene Version X nicht die neueste Version zu einem Lesezeitpunkt ist, werden zum Zwecke der Verarbeitung an der Editierprozedur-Umwandlungseinheit 502 die Datensatz- Daten von dieser Version X bis zur neuesten Version zu dem Server 90 angefordert. Danach wird ein zum bereits beschriebenen ähnlicher Betrieb aufgeführt.
Bei der obigen Prozedur sind die Editierzieldatei und die Datensatz-Daten, empfangen durch den Client 91, und die Datensatzverwaltungsinformation, die zum Server 90 übermittelt wird, alle in Einheiten von strukturellen Einheiten verschlüsselt, und mittels der Chiffriereinheit 112 verschlüsselt/entschlüsselt.
Auf diese Weise kann in diesem zweiten Ausführungsbeispiel der Dateiinhalt vom geeigneten Client ausgelesen werden, der den Dechiffrierschlüssel hat, und der Dateiinhalt kann nicht von dem Server ausgelesenen werden, so dass das Dateieditiersystem mit einer hohen Geheimhaltung für den Dateiinhalt realisiert werden kann.
Weiter wird am Server die Aktualisierung mit Bezug auf den Dateiinhalt der neuesten Version immer zu einem Zeitpunkt der Vervollständigung der Editierung durch jeden Client getätigt, sodass es möglich wird, die asynchrone Editierung durch eine Vielzahl von Clients zu realisieren, ohne den Verriegelungsmechanismus zu verwenden.
Weiter wird es möglich, eine Nutzungsweise zu realisieren, bei der die Version editiert wird, die zeitlich gesehen bereits alt ist, und die neueste Version wird aus ihr gemacht. Es wird nämlich bei der gemeinsam genutzten Datei, die asynchron editiert werden kann, möglich, eine Nutzungsweise zu realisieren, bei der das Editierziel nicht notwendigerweise auf die momentane Version allein beschränkt ist.
Weiter ist es im Falle einer Ausführung der Verbindungsverarbeitung der durch die asynchrone Editierung erhaltenen Editierergebnisse möglich, ein Verfahren zu realisieren, bei dem nur für die Verarbeitung an alleine der Client-Seite notwendige Daten vom Server übermittelt werden, und das Verbindungsergebnis zum Server zurückübermittelt wird, nachdem die notwendige Verarbeitung an der Client-Seite ausgeführt wurde, so dass die verschwenderische Kommunikation von Abschnitten bezüglich unbenötigter Datensätze vermieden werden kann, und demzufolge die Systemeffizienz beträchtlich verbessert werden kann.
Hinsichtlich der Datei-Datenstruktur kann durch Verwenden der in dem SCCS-Verfahren verwendeten Struktur, bei dem die sequentiell vom Beginn der Datei an eingefügten Daten an Einfügungspositionen als Blöcke gehandhabt werden, und die Blöcke im Falle der teilweisen Löschungen sequentiell aufgeteilt werden, eher als bei der beim RCS-Verfahren verwendete Struktur, bei dem die Differenz mit Bezug auf die unmittelbar vorhergehende (oder nachfolgende) Version einfach belassen wird, die bei der Verbindungsverarbeitung erforderliche Bestimmung der Einfügungs-/Löschpositionen beträchtlich vereinfacht werden, so dass die asynchrone Editierung einfacher wird.
Weiter kann, da das Verschlüsselungsverfahren für den Dateiinhalt im Falle einer Verwendung der Datenstruktur des SCCS-Verfahrens, geeignet für die Verbindungsverarbeitung, der Strom-Chiffrierer in Bit-Einheit (oder Byte-Einheit) verwendet werden. Dieser Strom-Chiffrierer weist eine Eigenschaft darin auf, dass ein bestimmtes Bit (oder Byte) des Klartextes einem bestimmten Bit (oder Byte) des chiffrierten Textes entspricht. Aus diesem Grund ist es, wenn die verschlüsselten Blöcke sequentiell aufgeteilt werden, ausreichend, den Abschnitt nach dem Teilungspunkt zu separieren und nur diesen separierten Abschnitt erneut zu verschlüsseln, so dass der Overhead aufgrund der erneuten Verschlüsselung reduziert werden kann. Weiter ist es auch der Server-Seite möglich, zu bestätigen, dass der Abschnitt vor dem Teilungspunkt nicht geändert wurde.
Wie oben erwähnt, enthält das gemeinsame Dateieditiersystem dieses→-4 503 in Fig. 5. Im folgenden wird die zweite Konfiguration für dieses zweite Ausführungsbeispiel erläutert, das diese Schleife auflöst.
In dieser zweiten Konfiguration wird die Datei-Datenstruktur des modifizierten SCCS-Verfahrens, in Fig. 4 gezeigt, verwendet, und das Schlüsselungsverfahren des 8 Bit CFB-Modus an den Strom-Chiffrierer wird verwendet. Das Schlüsselungsverfahren weist eine Eigenschaft darin auf, dass das erneute Verschlüsseln auch bei einer Teilung der Blöcke vollständig unnötig ist, wie vorhergehend erläutert.
Fig. 16 zeigt diese zweite Konfiguration des gemeinsamen Dateieditiersystems dieses zweiten Ausführungsbeispiels, das allgemein eine Vielzahl von Client 211 und einen Server 210 umfasst.
Der Server 210 umfasst weiter eine Kommunikations- (COMM-)Einheit 231 zum Durchführen einer Kommunikation mit jedem Client 91 über einen Kommunikationspfad 111, eine Editierprozedur-Umwandlungseinheit 502 zum Umwandeln der Editierprozedur, eine Datensatzverwaltungseinheit (für eine gemeinsam genutzte Datei) 510, um Datensätze für gemeinsam benutzte Dateien zu verwalten, und eine Datenspeichereinheit 511 zum Speichern einer Vielzahl von Dateien, wobei die Editierprozedur-Umwandlungseinheit 502, die Datensatzverwaltungseinheit 510 und die Datenspeichereinheit 511 der Editierprozedur-Umwandlungseinheit 502, der Datensatzverwaltungseinheit 510 und der Datenspeichereinheit 511 im asynchronen Editiersystem von Fig. 5, oben beschrieben, entsprechen. Hierbei arbeitet die Editierprozedur-Umwandlungseinheit 502 auch als die Datensatzverwaltungsinformations-Erzeugungseinheit 503 von Fig. 5.
Auf der anderen Seite umfasst dieser Client 211 weiter eine Kommunikations-(COMM-)Einheit 230 zum Durchführen einer Kommunikation mit dem Server 210 über den Kommunikationspfad 111, einen Speicher 221 zum Speichern der von dem Server 210 erhaltenen Dateien, eine gemeinsame Dateieditiereinheit 222 zum Editieren der gemeinsam genutzten Dateien, und eine Chiffriereinheit 212 zum Verschlüsseln/Entschlüsseln der Dateien.
Wie in Fig. 17 gezeigt, umfasst die gemeinsame Editiereinheit 222 die Editiereinheit 500 und die Editierprozedur- Erzeugungseinheit 501, die denen im asynchronen Editiersystem von Fig. 5, oben beschrieben, entsprechen.
Nunmehr werden, da eine Vielzahl von Clients 211 in diesem zweiten Ausführungsbeispiel bereitgestellt ist, Anforderungen für die folgenden zwei Typen von Operationen zu verschiedenen Zeiten auftreten:
(a) Ein Lesen von Datei-Daten einer bestimmten Version (Pfeil von 510 nach 500 in Fig. 5); und
(b) Ein Schreiben von Editierprozedurdaten, erhalten durch Umwandeln eines Editierergebnisses (Pfeil von 501 nach 502 in Fig. 5).
Nun wird eine beispielhafte Prozedur zum Handhaben dieser Anforderungen im zweiten Ausführungsbeispiel erläutert.
Der Client 211 fordert anfänglich die Daten einer bestimmten Version vom Server 210 an. Danach werden die Daten dieser Version entschlüsselt und in dem Speicher 221 gespeichert, die Editierung wird an der Editiereinheit 500 ausgeführt, und die Editierprozedurdaten werden an der Editierprozedur- Erzeugungseinheit 501 erzeugt. Es umfassen die Editierprozedurdaten zwei Datentypen von Einfügungsdaten und Löschdaten. Die Einfügungsdaten umfassen einen Satz bestehend aus einer Einfügungsposition (beispielsweise eine Anzahl von Byte von einer obersten Position), und einen Einfügungsblockinhalt, während die Löschdaten einen Satz umfassen, bestehend aus einer Löschanfangsposition und einer Löschendposition.
Für den Einfügungsblockinhalt erzeugt der Client 211 den Anfangswert IV und verschlüsselt den Block mit dem 8 Bit CFB- Modus. Die anderen Daten (wie beispielsweise die Einfügungsposition und der Löschbereich) werden nicht verschlüsselt, und zusammen mit dem verschlüsselten Einfügungsblockinhalt zum Server 210 übermittelt.
Am Server 210, der dies empfängt, werden die Einfügungsposition und der Löschbereich umgewandelt (Positionsumwandlung), in Positionsdaten mit Bezug auf die neueste Version zu diesem Zeitpunkt, und zwar durch die Editierprozedur-Umwandlungseinheit 502. Dann wird der vom Client übermittelte verschlüsselte Einfügungsblock an der umgewandelten Einfügungsposition angeordnet, während die Blockunterteilung und der Löschzeitfeldeintrag für den umgewandelten Löschbereich durch die Datensatzverwaltungseinheit 510 vorgenommen wird. Das soweit erhaltene Ergebnis wird dann als die neueste Version bezeichnet.
Bei der obigen Prozedur ist es der entscheidende Punkt, dass die Umwandlung der Editierprozedur in einem verschlüsselten Zustand getätigt werden kann, und aus diesem Grund die oben beschriebene Schleife zum Zwecke der Editierprozedur- Umwandlung bei der obigen beschriebenen allgemeinen Prozedur aufgelöst werden kann. Als die Datei-Datenstruktur und das Verschlüsselungsverfahren zum Ermöglichen der Editierprozedur-Umwandlung in dem verschlüsselten Zustand, wird eine Kombination des modifizierten SCCS-Verfahrens und der 8 Bit CFB-Modus verwendet. Ein ähnlicher Effekt kann auch durch ein Verwenden eines anderen Verschlüsselungsverfahrens erhalten werden, wie beispielsweise dem L-Bit-OFB-Modus oder den L-Bit-CFB-Modus, für die das erneute Verschlüsseln für den ersten Block im Falle der Blockunterteilung nicht notwendig ist, wobei jedoch in solch einem Fall im Vergleich mit einem oben beschriebenen Fall zusätzliche Daten als die Editierprozedurdaten notwendig sein werden, zu übertragen von dem Client zum Server.
Auf diese Weise kann in diesem zweiten Ausführungsbeispiel der Dateiinhalt von dem berechtigten Client aus gelesen werden, der den Dechiffrierschlüssel innehat, und der Dateiinhalt kann nicht vom Server ausgelesen werden, so dass das Dateieditiersystem mit einem hohen Geheimhaltungsniveau für den Dateiinhalt realisiert werden kann.
Weiter wird am Server die Aktualisierung mit Bezug auf den Dateiinhalt der neuesten Version immer zu einem Zeitpunkt der Beendigung der Editierung durch einen jeden Client vorgenommen, so dass es möglich wird, die asynchrone Editierung mit einer Vielzahl von Clients zu realisieren, ohne den Verriegelungsmechanismus zu verwenden.
Somit kann in diesem zweiten Ausführungsbeispiel die Anordnung der Hauptmerkmale in dieser ersten Konfiguration von Fig. 13 und der zweiten Konfiguration von Fig. 16, oben beschrieben, zusammengefasst werden, wie in Fig. 18 bzw. 19 gezeigt.
In der Konfiguration von Fig. 18 kann die Blockidentifikationsinformation der Datensatzverwaltungsinformation hinzugefügt werden, die durch einen Betrieb der Datensatzverwaltungsinformations- Erzeugungseinheit 503 auf der Client-91-Seite vom Client 91 zum Server 90 zu übertragen ist. In solch einem Fall wird die Blockidentifikationsinformation nicht verschlüsselt, während die gesamte Datensatzverwaltungsinformation durch die Chiffriereinheit 112 verschlüsselt wird, so dass der Server 90 den durch die Datensatzverwaltungsinformation bezeichneten neuen Datenblock verwalten kann, in Übereinstimmung mit der hinzugefügt Blockidentifikationsinformation, die nicht verschlüsselt ist, und daher auf der Server-90-Seite erfassbar ist, auch wenn der Dateiinhalt der verschlüsselten Datensatzverwaltungsinformation durch den Server 90 nicht erlangt werden kann. Demzufolge kann die Blockidentifikationsinformation nicht der Datensatzverwaltungsinformation, die vom Client 91 zum Server 90 zu übertragen ist, hinzugefügt werden, wobei in diesem Fall die geeignete Blockidentifikationsinformation zur Identifikation der neuen Blockdaten, bezeichnet durch die Datensatzverwaltungsinformation, an der Datensatzverwaltungseinheit 510 auf der Server-90-Seite hinzugefügt werden kann.
Bei der Konfiguration von Fig. 19 werden nur die Editierprozedurdaten vom Client 211 zum Server 210 übertragen, und die Blockidentifikationsinformation zum Identifizieren der neuen Blockdaten, die sich aus diesen Editierprozedurdaten ergeben, wird durch den Betrieb der Datensatzverwaltungsinformations-Erzeugungseinheit 503 oder der Datensatzverwaltungseinheit 510 auf der Server-210-Seite hinzugefügt. Hier werden nur die Einfügungsdateninhalte durch die Chiffriereinheit 212 verschlüsselt, während andere Teile der Editierprozedurdaten nicht verschlüsselt werden, so dass die Editierprozedur-Umwandlungseinheit 502 auf der Server- 210-Seite die Umwandlung der Editierprozedurdaten durchführen kann, in Übereinstimmung mit diesen anderen Teilen der Editierprozedurdaten, die nicht verschlüsselt sind, und daher auf der Server-210-Seite erfasst werden können, zusammen mit den durch die Datensatzverwaltungseinheit 510 bereitgestellten Datensatz-Daten.
Es ist weiter möglich, diese Konfiguration von Fig. 19 zu modifizieren, um die Editierprozedur-Umwandlungseinheit 502 auf der Client-211-Seite bereitzustellen, zwischen der Editierprozedur-Erzeugungseinheit 501 und der Chiffriereinheit 212, um ein Hybrid der Konfigurationen von Fig. 18 und 19 zu realisieren. In solch einem Fall werden nur die umgewandelten Editierprozedurdaten vom Client 211 zum Server 210 übermittelt, und die Blockidentifikationsinformation zum Identifizieren der neuen Blockdaten, die sich aus diesen umgewandelten Editierprozedurdaten ergeben, werden durch den Betrieb der Datensatzverwaltungsinformations-Erzeugungseinheit 503 oder der Datensatzverwaltungseinheit 510 auf der Server-210-Seite hinzugefügt. In diesem Fall werden nur die umgewandelten Einfügungsdateninhalte durch diese Chiffriereinheit 212 verschlüsselt, während die anderen Teile der Editierprozedurdaten nicht verschlüsselt werden, so dass die Editierprozedur-Umwandlungseinheit 502 auf der Server-210- Seite die Erzeugung der Datensatzverwaltungsinformation in Übereinstimmung mit diesen anderen Teilen der umgewandelten Editierprozedurdaten, die nicht verschlüsselt sind und daher auf der Server-210-Seite erfassbar sind, durchführen.
Nunmehr ist die obige beschriebene erste Eigenschaft bezüglich der Dateiinhaltsgeheimhaltung mit Bezug auf den Server und die oben beschriebene, zweite Eigenschaft bezüglich der asynchronen Editierung getrennt realisierbar. Im folgenden werden die Ausführungsbeispiele eines gemeinsamen Dateieditiersystems detailliert erläutert, das eines dieser Eigenschaften separat implementiert.
Zuerst wird das dritte Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert, bei dem die oben beschriebene zweite Eigenschaft bezüglich der asynchronen Editierung auf dem Client-Server-System implementiert ist.
In diesem dritten Ausführungsbeispiel sind die einzelnen Merkmale bezüglich der Dateistruktur, des Datensatzverwaltungsverfahrens und des asynchronen Editiersystems im wesentlichen die gleichen wie die für das oben beschriebene erste Ausführungsbeispiel, und deren detaillierte Beschreibungen werden hier nicht wiederholt. Im folgenden wird die Konfiguration und die Betriebscharakteristik dieses dritten Ausführungsbeispiels beschrieben.
Fig. 20 zeigt eine Konfiguration des gemeinsamen Dateieditiersystems dieses dritten Ausführungsbeispiels, das allgemein eine Vielzahl von Clients 701 und einen Server 710 umfasst.
Der Server 710 umfasst weiter eine Kommunikations- (COMM-)Einheit 731 zum Durchführen einer Kommunikation mit jedem Client 701 über einen Kommunikationspfad 111, eine Verbindungsverarbeitungseinheit 740 zum Durchführen der Verbindungsverarbeitung, und eine Datenspeichereinheit 511 zum Speichern einer Vielzahl von Dateien, wobei die Datenspeichereinheit 511 der Datenspeichereinheit 511 beim ober beschriebenen asynchronen Editiersystem von Fig. 5 entspricht.
Auf der anderen Seite umfasst jeder Client 701 weiter eine Kommunikations-(COMM-)Einheit 730 zum Durchführen einer Kommunikation mit dem Server 710 über den Kommunikationspfad 111, einen Speicher 721 zum Speichern von von dem Server 710 erhaltenen Dateien, und eine gemeinsame Dateieditiereinheit 722 zum Editieren der gemeinsam genutzten Dateien.
Wie in Fig. 21 gezeigt, umfasst die gemeinsame Dateieditiereinheit 722 des Clients 701 die Editiereinheit 500 die Editierprozedur-Erzeugungseinheit 501, die denen im oben beschriebenen asynchronen Editiersystem von Fig. 5 entsprechen.
Wie in Fig. 22 gezeigt, umfasst die Verbindungsverarbeitungseinheit 740 des Servers 710 die Editierprozedur-Umwandlungseinheit 502, die Datensatzverwaltungsinformations-Erzeugungseinheit 503, und die Datensatzverwaltungseinheit 510, die denen im oben beschriebenen asynchronen Editiersystem von Fig. 5 entsprechen.
Da eine Vielzahl von Clients 701 in diesem dritten Ausführungsbeispiel bereitgestellt ist, werden Anfragen für die folgenden zwei Arten von Operationen zu verschiedenen Zeitpunkten auftreten:
(a) Ein Lesen von Dateidaten einer bestimmten Version (Pfeil von 510 nach 500 in Fig. 5); und
(b) Ein Schreiben von Editierprozedurdaten, erhalten durch ein Umwandeln eines Editierergebnisses (Pfeil von 501 nach 502 in Fig. 5).
Hier wird eine beispielhafte Prozedur zum Handhaben dieser Anfragen in diesem zweiten Ausführungsbeispiel erläutert.
In diesem Fall fordert der Client 701 die Dateidaten einer bestimmten Version vom Server 710 an, und nachdem die Datei in den Speicher 721 gespeichert wurde, wird die Editierung an der Editiereinheit 500 ausgeführt, die Editierprozedurdaten werden an der Editierprozedur-Erzeugungseinheit 501 erzeugt, und die erhaltenen Editierprozedurdaten werden zum Server 710 übertragen.
Am Server 710 werden die Editierprozedurdaten nacheinander in die Warteschlange eingereiht, und die Verbindungsverarbeitungseinheit 740 nimmt sequentiell die Editierprozedurdaten in der Schlange heraus, wandelt diese in Datensätze um, und speichert diese. Anders als im Falle des Systems mit der Verschlüsselungsfunktion, oben beschrieben, ist dieses dritte Ausführungsbeispiel dadurch gekennzeichnet, dass der Server 710 selbst die Editierprozedur-Umwandlung mit Bezug auf die neueste Version durchführen kann. Das heißt, der Client 701 führt die Editierprozedur-Umwandlung in Übereinstimmung mit den Editierprozedurdaten und den Datensatz-Daten aus, und speichert dann das Ergebnis als den Datensatz. Demzufolge ist die oben erwähnte Schleife von 510 → 502 → 503 in Fig. 5 in diesem dritten Ausführungsbeispiel abwesend, und daher besteht keine Notwendigkeit für den Verriegelungsmechanismus zum Zwecke eines Verhinderns der wiederholten Verarbeitung durch die Schleife. Zusätzlich kann auch die Funktion der gemeinsamen Dateieditiereinheit 722, auf der Client-701-Seite bereitgestellt, reduziert werden.
Hier ist es, genauso wie im Falle des Ausführungsbeispiels, das die erste Eigenschaft bezüglich der Dateiinhaltsgeheimhältung mit Bezug auf den Server verwirklicht, auch möglich, eine Konfiguration zu verwenden, bei der die Editierprozedur-Umwandlungseinheit 502 und die Datensatzverwaltungsinformations-Erzeugungseinheit 503 auf der Client-701-Seite bereitgestellt sind. In solch einem Fall ist der Betrieb jedes Elements im wesentlichen gleich zu dem oben für das zweite Ausführungsbeispiel beschriebenen. Es ist weiter möglich, die Editierprozedur-Erzeugungseinheit 501 von der gemeinsamen Dateieditiereinheit 722, bereitgestellt am Client 701, zur Server-710-Seite zu versetzen.
Somit wird in diesem dritten Ausführungsbeispiel am Server die Aktualisierung mit Bezug auf den Dateiinhalt der neuesten Version immer zu einem Zeitpunkt der Beendigung der Editierung durch einen jeden Client durchgeführt, so dass es möglich wird, die asynchrone Editierung durch eine Vielzahl von Clients ohne Verwendung des Verriegelungsmechanismus zu realisieren.
Weiter wird es möglich, eine Nutzungsweise zu realisieren, bei der eine zeitlich gesehen bereits alte Version editiert wird, und die neueste Version aus ihr hergestellt wird. Es wird nämlich bei der gemeinsam genutzten Datei, die asynchron editiert wird, möglich, eine Nutzungsweise zu realisieren, bei der das Editierziel nicht notwendigerweise nur auf die momentane Version beschränkt ist.
Weiter ist es im Falle einer Durchführung der Verbindungsverarbeitung der durch die asynchrone Editierung erhaltenen Editierergebnisse möglich, ein Verfahren zu realisieren, bei dem nur die Daten, die für die Verbindung an der Client-Seite notwendig sind, von dem Server übermittelt werden, und das Verbindungsergebnis zum Server rückgeliefert wird, nachdem die notwendige Verarbeitung an der Client-Seite durchgeführt wurde, so dass die verschwenderische Kommunikation von Abschnitten bezüglich nicht notwendiger Datensätze vermieden werden kann, und demzufolge die Systemeffizienz beträchtlich verbessert werden kann.
Durch Verwenden der beim SCCS-Verfahren genutzten Struktur, wobei die Daten, die sequentiell von einem Beginn der Datei eingefügt wurden, an Einfügungspositionen als Blöcke gehandhabt werden, und die Blöcke sequentiell in einem Fall der partiellen Löschungen aufgeteilt werden, kann hinsichtlich der Datei-Datenstruktur, statt der in dem RCS- Verfahren verwendeten Struktur, bei der die Differenz mit Bezug auf die unmittelbar vorhergehende (oder nachfolgende) Version einfach ausgelassen wird, die Bestimmung der Einfügungs-/Löschposition, erforderlich bei der Verbindungsverarbeitung, beträchtlich vereinfacht werden, so dass die asynchrone Editierung einfacher wird.
Als nächstes wird das vierte Ausführungsbeispiel eines Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert, bei dem die oben beschriebene erste Eigenschaft bezüglich der Dateiinhaltsgeheimhaltung mit Bezug auf den Server auf dem Client-Server-System implementiert ist.
Die in diesem vierten Ausführungsbeispiel gehandhabte Datei umfasst eine Vielzahl von Blockdaten und Blockidentifikationsinformation, und jede Blockdaten sind in Einheiten von Blockdaten verschlüsselt. Die Datei-Daten weisen beispielsweise die von Fig. 2, Fig. 3 oder Fig. 4, oben beschrieben, auf, jedoch ist daneben dieses vierte Ausführungsbeispiel auch auf andere Systeme und Verfahren verschiedener Art anwendbar, wie beispielsweise ein Verfahren zum Verschlüsseln des Programms in Einheiten von Subroutinen, und ein Verfahren zum Handhaben einer Vielzahl von Daten- Dateien, die zusammen in einem Hyper-Text verknüpft sind, wobei die Daten-Dateien in Einheiten von Daten-Dateien verschlüsselt sind, und Verknüpfungsbereiche nicht verschlüsselt sind. Auf diese Weise wird es möglich, eine effiziente Nutzungsweise zu realisieren, bei der der Client nur den notwendigen Abschnitt ausliest, während die Geheimhaltung des Modulinhalts mit Bezug auf den Server aufrechterhalten wird.
Weiter wird in diesem vierten Ausführungsbeispiel mit Bezug auf die Dateien mit der Datenstruktur, wie oben beschrieben, das oben für das erste Ausführungsbeispiel beschriebene Schlüsselungsverfahren verwendet.
Fig. 23 zeigt eine Konfiguration des Dateieditiersystems dieses vierten Ausführungsbeispiels, das allgemein eine Vielzahl von Clients 801 und einen Server 810 umfasst.
Der Server 810 umfasst weiter eine Kommunikations- (COMM-)Einheit 831 zum Durchführen einer Kommunikation mit jedem Client 801 über einen Kommunikationspfad 111, eine Datensatzverwaltungseinheit 840 zum Verwalten der Datei- Daten, und eine Datenspeichereinheit 511 zum Speichern einer Vielzahl von Dateien.
Auf der anderen Seite umfasst jeder Client 901 eine Kommunikations-(COMM-)Einheit 830, zum Durchführen einer Kommunikation mit dem Server 810 über den Kommunikationspfad 111, einen Speicher 821 zum Speichern von von dem Server 810 erhaltenen Dateien, eine Dateieditiereinheit 822 zum Editieren der Dateien, und eine Chiffriereinheit 812 zum Verschlüsseln/Entschlüsseln der Dateien.
Wie in Fig. 24 gezeigt, umfasst die Chiffriereinheit 812 eine Kommunikations-(COMM-)Einheit 832, die mit der Dateieditiereinheit 822 verbunden ist, eine Verschlüsselungs-/Entschlüsselungs-Verarbeitungseinheit 8121, die mit der Kommunikationseinheit 832 verbunden ist, und eine Schlüsselspeichereinheit 8122, die mit der Verschlüsselung/Entschlüsselungs-Verarbeitungseinheit 8121 verbunden ist.
Bei dieser Konfiguration fordert der Client 801 die Datei- Daten einer bestimmten Version vom Server 810 an, und nachdem die Datei in dem Speicher 821 gespeichert ist, wird die Editierung an der Datei an der Dateieditiereinheit 822 ausgeführt. An dieser Stelle wird die Datei in Einheiten von Blockdaten verschlüsselt, wie bereits oben erwähnt, so dass die Datei unter Verwendung eines Chiffrierschlüssels, registriert in der Schlüsselspeichereinheit 8122, an der Verschlüsselungs-/Entschlüsselungs-Verarbeitungseinheit 8121 entschlüsselt wird. Nachdem die Editierung der Datei beendet ist, wird die Datei durch Verwendung des Chiffrierschlüssels, registriert in der Schlüsselspeichereinheit 8122, an der Verschlüsselungs-/Entschlüsselungs-Verarbeitungseinheit 8121 verschlüsselt, und zum Server 810 übertragen, so dass die Datei in der Datenspeichereinheit 511 durch die Datensatzverwaltungseinheit 840 am Server 810 aktualisiert wird.
Auf diese Weise ist es in diesem vierten Ausführungsbeispiel möglich, das Dateieditiersystem mit einer hohen Geheimhaltung für den Dateiinhalt zu realisieren, bei dem der Dateiinhalt durch den Server nicht ausgelesen werden kann.
Weiter muss der Client lediglich den notwendigen Datenblock aus den Dateien über die Kommunikation erhalten, sodass es möglich ist, den Kommunikationsaufwand zu reduzieren, und es weiter ausreicht, nur die notwendigen Blöcke zu ent schlüsseln/verschlüsseln, so dass es möglich ist, den Verarbeitungsaufwand auf der Client-Seite zu reduzieren, und demzufolge kann auch der für den Client erforderliche Puffer (Speicher) reduziert werden.
Dabei ist es in diesem vierten Ausführungsbeispiel möglich, das Datensatzverwaltungsverfahren anzuwenden, wie oben für das erste Ausführungsbeispiel beschrieben, und zwar wie folgt.
In diesem Fall wird die oben beschriebene Datei-Datenstruktur aus Fig. 2, Fig. 3 oder Fig. 4 verwendet. Weiter wird mit Bezug auf die Dateien mit solch einer Datenstruktur das für das erste Ausführungsbeispiel oben beschriebene Verschlüsselungsverfahren verwendet.
Dabei wird die asynchrone Editierung nicht durchgeführt, so dass es möglich ist, das Datensatzverwaltungssystem zu verwenden, bei dem die Editierprozedur-Umwandlungseinheit 502 beim asynchronen Editiersystem von Fig. 5 weggelassen wird, und die Editierprozedur-Erzeugungseinheit 501 und die Datensatzverwaltungsinformations-Erzeugungseinheit 503 können direkt verbunden werden, und die Datensatzverwaltungseinheit 510 wird als die Datenverwaltungseinheit 840 eingesetzt, die abgewandelt ist, eine Funktion aufzuweisen, um die Datenspeichereinheit 511 ausschließlich zu handhaben. Dieses Datensatzverwaltungssystem ist in der Datei-Editiereinheit 822 und der Datensatzverwaltungseinheit 840 verteilt angeordnet.
Dabei können die anderen Elemente in irgendeiner beliebigen Form verteilt angeordnet werden, solange die Editiereinheit 500 an der Dateieditiereinheit 822 des Clients 801 implementiert ist, und die Datenverwaltungseinheit 840 und die Datenspeichereinheit 511 am Server 810 implementiert sind.
Als eine bevorzugte Ausführung sind nur die Datenverwaltungseinheit 840 und die Datenspeichereinheit 511 am Server 810 implementiert, während alle anderen Elemente am Client 801 implementiert sind, wie in Fig. 23, und dies wird beschrieben.
Bei dieser Konfiguration fordert der Client 801 die Datei- Daten einer bestimmten Version vom Server 810 an, und nachdem die Datei in dem Speicher 821 gespeichert ist, wird die Editierung an der Datei-Editiereinheit 500 ausgeführt. Zu diesem Zeitpunkt ist die Datei in Einheiten von Blockdaten verschlüsselt, wie oben erwähnt, so dass die Datei durch Verwendung des in der Schlüsselspeichereinheit 8122 an der Verschlüsselungs-/Entschlüsselungs-Verarbeitungseinheit 8121 registrierten Dechiffrierschlüssels entschlüsselt wird. Nachdem die Editierung der Datei beendet ist, werden die Editierprozedurdaten an der Editierprozedur-Erzeugungseinheit 501 erzeugt. Dann werden die erhaltenen Editierprozedurdaten in I> atensatz-Daten umgewandelt, mit einem Format, das für das an der Datensatzverwaltungsinformations-Erzeugungseinheit 503 verwendete Datensatzverwaltungsverfahren geeignet ist. Dann werden die Datensatz-Daten unter Verwendung des in der Schlüsselspeichereinheit 8122 an der Verschlüsselungs-/Entschlüsselungs-Verarbeitungseinheit 8121 registrierten Chiffrierschlüssel verschlüsselt, und zum Server 810 übermittelt, so dass die Datei in der Datenspeichereinheit 511 durch die Datensatzverwaltungseinheit 840 an dem Server 810 aktualisiert wird.
Auf diese Weise können die Dateiversionsverwaltung und die Datei-Datengeheimhaltung mit Bezug auf den Dateiverwaltungs- Server gleichzeitig realisiert werden.
Weiter kann dann, wenn die Datei-Datenstruktur des Differenzstapelverfahrens, in Fig. 2 gezeigt, die Vollständigkeit des Datensatzes alleine durch die Dateiverwaltungs-Serverseite garantiert werden.
Weiter kann in einem Fall, bei dem die Datei-Datenstruktur des in Fig. 3 gezeigten RCS-Verfahrens verwendet wird, das Lesen der Datei in der momentanen Version und das Löschen von alten Datensätzen bei der Dateiversionsverwaltung vereinfacht werden.
Weiter kann in einem Fall, in dem die Datei-Datenstruktur des in Fig. 4 gezeigten modifizierten SCCS-Verfahrens verwendet wird, die Löschung von alten Datensätzen bei der Dateiversionsverwaltung vereinfacht werden.
Falls das Strom-Chiffrieren als Schlüsselungsverfahren angewendet wird, kann weiter bei der Verschlüsselung zum Zeitpunkt einer Blockunterteilung ein Abschnitt von einem Beginn des Blockes bis zu dem Unterteilungspunkt in dem verschlüsselten Zustand erneut verwendet werden, und es ist ausreichend, nur einen Bereich nach dem Unterteilungspunkt erneut zu verschlüsseln. Es ist weiter möglich, das Schlüsselungsverfahren zu verwenden, bei dem überhaupt kein erneutes Verschlüsseln notwendig ist. Dieses Verschlüsselungsverfahren ist vorteilhaft in einem Fall eines sequentiellen Unterteilens von Blöcken, wie beim SCCS- Verfahren.
Als nächstes wird das fünfte Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert. In diesem fünften Ausführungsbeispiel ist das oben beschriebene gemeinsame Dateieditiersystem von Fig. 13, Fig. 16 oder Fig. 20 mit einer zusätzlichen Funktion ausgestattet, zum Verzögern einer Ausführung einer Löschung einer Version in Reaktion auf eine Löschanforderung für eine bestimmte Version einer bestimmten Datei, bis kein Client mehr die bestimmte Version der bestimmten Datei editiert.
BEei dem die Datensatzverwaltung verwendenden System ist es möglich, eine Funktion zum Löschen einiger Versionen unter den Datensätzen bereitzustellen. Solch eine Löschung einer Version kann getätigt werden, wenn beispielsweise der Client einen Löschbefehl ausführt, oder falls das System automatisch und eine Version löscht, bei der seit ihrer Erzeugung mehr als eine vorgegebene Zeitperiode abgelaufen ist.
Bei dem gemeinsamen Dateieditiersystem mit der asynchronen Editierfunktion gemäß der vorliegenden Erfindung sollte es zu einem Zeitpunkt einer Löschung einer Version keinen Client geben, der diese Löschzielversion editiert. Dies rührt daher, dass der Dateiverwaltungsserver die Verbindungsverarbeitung zum Umwandeln der Version durchführt, auf die der Client zugegriffen hat, in die neueste Version im Datensatzverwaltungsserver in solch einem System, und falls eine Version gelöscht wird, während diese Version durch irgendeinen Client in solch einem System editiert wird, würde Verbindungsverarbeitung für die durch diesen Client getätigte Editierung unmöglich werden.
In diesem fünften Ausführungsbeispiel ist, um die Versionslöschfunktion zu realisieren, der Datensatzverwaltungsserver ausgestattet mit einer Einrichtung zum Zählen der Anzahl von Clients, die eine jede Version einer jeden Datei editieren, in Übereinstimmung mit jeder Version einer Datei, die durch den Dateiverwaltungsserver verwaltet wird. Durch diese Einrichtung kann der Dateiverwaltungsserver beurteilen, ob es irgendeinen Client gibt, der eine jede Version einer jeden Datei editiert. Wenn nämlich der Zählwert für eine bestimmte Version einer bestimmten Datei 0 ist, impliziert dies, dass es einen Client gibt, der diese Version dieser Datei editiert, wohingegen dann, wenn der Zählwert nicht gleich 0 ist, impliziert ist, das es einen Client gibt, der diese Version dieser Datei editiert.
Dann ist der Dateiverwaltungsserver dieses fünften Ausführungsbeispiels weiter mit einer Einrichtung ausgestattet, um die Ausführung der Löschung einer Version zu verzögern, wenn die Löschung einer bestimmten Version einer bestimmten Datei angefragt wird, und der Zählwert für diese Version dieser Datei nicht gleich 0 ist, bis dieser Zählwert zu 0 wird. Durch diese Einrichtung wird der Dateiverwaltungsserver nicht eine solche der Datei löschen, während es einen Client gibt, der diese Version der Datei editiert, die das Löschziel ist, so dass die Verbindungsverarbeitung für die durch diesen Client getätigte Editierung ohne Probleme ausgeführt werden kann.
Fig. 25 zeigt eine Konfiguration des gemeinsamen Dateieditiersystems dieses fünften Ausführungsbeispiels, wie oben ausgeführt, basierend auf dem oben beschriebenen gemeinsamen Dateieditiersystem von Fig. 13.
In dieser Konfiguration von Fig. 25 ist jeder Zugriffe anfragende Client 91 und der Kommunikationspfad 111 im wesentlichen entsprechend zu denen in Fig. 13. Der Dateiverwaltungsserver 95 unterscheidet sich von dem in Fig. 13 darin, dass er weiter eine Client-Zähleinheit 900 enthält.
Wie in Fig. 26 gezeigt, umfasst diese Client-Zähleinheit 900 eine Verzweigungseinheit 901, eine Editierstart- Verarbeitungseinheit 902, eine Löschanforderungs- Verarbeitungseinheit 903, und eine Editierend- Verarbeitungseinheit 904, eine Zählerspeichereinheit 905, und eine Löschbefehlsausgabeeinheit 906.
Die grundlegenden Funktionen dieser Client-Zähleinheit 900 enthalten ein Zählen, wie viele Clients eine jede Version einer jeden Datei in Übereinstimmung mit jeder Version einer jeden Datei, gehandhabt durch den Dateiverwaltungsserver 95 editieren, und die Verzögerung der Ausführung einer Löschung einer Version, wenn die Löschung einer bestimmten Version einer bestimmten Datei von einem bestimmten Client angefragt wird, jedoch der Zählwert für diese Version dieser Datei, gezählt durch die Client-Zähleinrichtung 900, nicht gleich 0 ist, bis dieser Zählwert zu 0 wird.
Hier ist es die grundlegende Aufgabe der Zählerspeichereinheit 905 in der Client-Zähleinheit 900, dass für jede Version einer jeden Datei diese den Zählwert (eine ganze Zahl) speichert, und ein Löschverzögerungs-Flag (ein Bit, was Wahr oder Falsch anzeigt), in Entsprechung. Der Zählerwert ist ein Zähler zum Zählen, wie viele Clients diese Version dieser Datei editieren, während das Löschverzögerungs-Flag ein Flag ist, um anzuzeigen, dass die Ausführung der Löschung verzögert ist, da der Zählerwert nicht gleich 0 ist.
Eine beispielhafte Datenstruktur der in der Zählerspeichereinheit 905 gespeicherten Daten in Fig. 27 gezeigt, in der Form einer Anordnung in zwei Schritten. Die Anordnung des ersten Schritts stellt eine Entsprechung zwischen der Dateiidentifikation und den Anordnungen des zweiten Schritts her, was eine Anordnung von Einträgen darstellt, wobei ein jeder Eintrag eine Paarung der Dateiidentifikation und einer Zähleranordnungsadresse enthält. Jede Anordnung des zweiten Schritts speichert den Zählerwert und das Löschverzögerungs-Flag für unterschiedliche Versionen jeder Datei, was eine Anordnung von Einträgen ist, wobei jeder Eintrag eine Paarung des Fehlerwertes und des Löschverzögerungs-Flags enthält. In dieser Anordnung des zweiten Schritts wird die Versionsnummer als ein Index in der Anordnung bezeichnet. Somit sind beispielsweise C11, C12 und C13, in Fig. 27 gezeigt, die Zählerwerte für die Version mit den Versionsnummern 1, 2 und 3 der Datei mit der Datei ID1, während F11, F12 und F13, in Fig. 27 gezeigt, die Löschverzögerungs-Flags für diese Versionen mit den Versionsnummern 1, 2 und 3 für die Datei mit der Datei ID1 sind. Hier wird der anfängliche Wert für jeden Zählerwert auf 0 gesetzt, und der anfängliche Wert für jedes Löschverzögerungs-Flag wird auf Falsch eingestellt (oder einen falsch anzeigenden Wert wie beispielsweise "0").
In diesem fünften Ausführungsbeispiel tätigt der Client 91 die Editierstartdeklaration gegenüber dem Dateiverwaltungsserver 95, unmittelbar vor einem Beginn der Editierung der Datei. Diese Editierstartdeklaration wird durch ein Übertragen eines Befehlswortes vom Client 91 zum Dateiverwaltungsserver 95 über den Kommunikationspfad 111 getätigt, was anzeigt, dass es die Editierstartdeklaration ist, gefolgt durch die Datei ID (Identifikation) der Datei, die ein Ziel der Editierung sein soll, und der Versionsnummer für die zu editierende Version.
Die Kommunikationsdaten, empfangen durch den Dateiverwaltungsserver 95 werden dann in die Verzweigungseinheit 901 eingeführt. An der Verzweigungseinheit 901 wird das erste eine Wort der Kommunikationsdaten ausgelesen, und wenn festgestellt wird, dass es das Befehlswort ist, das anzeigt, dass es die Editierstartdeklaration ist, dann werden die folgende Datei ID und die Versionsnummer in den Kommunikationsdaten in die Editierstart-Verarbeitungseinheit 902 geführt.
An der Editierstart-Verarbeitungseinheit 902 wird, wenn die Eingabe von der Verzweigungseinheit 901 empfangen wird, ein Zugriff auf die Zählerspeichereinheit 905 getätigt, um den Zählerwert entsprechend der bestimmten Version der bestimmten Datei ID um Eins zu erhöhen.
Auf der anderen Seite werden die an der Verzweigungseinheit 901 empfangene Kommunikationsdaten auch zu der Datensatzverwaltungseinheit 510 übergeben, entweder so wie sie sind, oder wenn die Datei ID und die Versionsnummer geeignet verarbeitet sind. Dann wird, nachdem die Editierstartdeklaration wie oben erläutert, verarbeitet wurde, die Editierung der Datei durch den Client 91 durchgeführt. Zu diesem Zeitpunkt ist der Datei- Editiermechanismus ähnlich zu der oben beschriebenen Konfiguration von Fig. 13.
Als nächstes wird ein Verarbeitungsmechanismus für einen Fall einer Löschung einer Version einer Datei erläutert. In diesem fünften Ausführungsbeispiel wird die Versionslöschanforderung ebenso getätigt durch ein Übertragen eines Befehlswortes vom Client 91 zum Dateiverwaltungsserver 95 über den Kommunikationspfad 111, das anzeigt, dass es die Versionslöschanforderung ist, gefolgt durch die Datei ID der Datei, die in Ziel der Löschung sein soll, und der Versionsnummer der zu löschenden Version.
Die durch den Dateiverwaltungsserver 95 empfangenen Kommunikationsdaten werden dann in die Verzweigungseinheit 901 eingeführt. An der Verzweigungseinheit 901 wird das erste eine Wort der Kommunikationsdaten ausgelesen, und wenn festgestellt wird, dass es das Befehlswort ist, das anzeigt, dass es die Versionslöschanforderung ist, werden die folgende Datei ID und die Versionsnummer in den Kommunikationsdaten in die Löschanforderungs-Verarbeitungseinheit 903 eingeführt. An der Löschanforderungs-Verarbeitungseinheit 903 wird, wenn die Eingabe von der Verzweigungseinheit 901 empfangen ist, die Verarbeitung entsprechend dem Flussdiagramm von Fig. 28 wie folgt durchgeführt.
An der Löschanforderungs-Verarbeitungseinheit 903 wird zuerst auf die Zählerspeichereinheit 905 zugegriffen, und der Zählerwert C für die spezifizierte Versionsnummer der spezifizierten Datei ID wird erlangt (Schritt S21).
Als nächstes wird beurteilt, ob der Zählerwert C gleich 0 ist oder nicht (Schritt S22). Wenn der Zählerwert C gleich 0 ist, wird der Befehl zum Löschen der spezifizierten Version der spezifizierten Datei von der Löschbefehlsausgabe 906 an die Datensatzverwaltungseinheit 510 abgegeben (Schritt S23), wohingegen dann, wenn der Zählerwert C nicht gleich 0 ist, auf die Zählerspeichereinheit 905 zugegriffen wird, und das Löschverzögerungs-Flag für die spezifizierte Versionsnummer der spezifizierten Datei ID auf Wahr (True) eingestellt wird (oder einen Wahr-anzeigenden Wert, wie beispielsweise "1") (Schritt S24).
Als nächstes wird die Verarbeitung an einem Ende der Editierung beschrieben. In diesem fünften Ausführungsbeispiel führt der Client 91 die Editierenddeklaration gegenüber dem Dateiverwaltungsserver 95 durch, unmittelbar nach einem Ende der Editierung der Datei. Diese Editierenddeklaration wird getätigt durch ein Übertragen eines Befehlsworts vom Client 91 zum Dateiverwaltungsserver 95 über den Kommunikationspfad 111, das anzeigt, dass es die Editierenddeklaration ist, gefolgt durch die Datei ID der Datei, für die die Editierung beendet ist, und der Versionsnummer der Version, für die Editierung beendet ist.
Die durch den Dateiverwaltungsserver 95 empfangenen Kommunikationsdaten werden in die Verzweigungseinheit 901 eingeführt. An der Verzweigungseinheit 901 wird das erste eine Wort der Kommunikationsdaten ausgelesen, und wenn festgestellt wird, dass es das Befehlswort ist, das anzeigt, dass es die Editierenddeklaration ist, werden die folgende Datei ID und die Versionsnummer in den Kommunikationsdaten in die Editierendverarbeitungseinheit 904 eingeführt. Wann immer notwendig, werden die an der Verzweigungseinheit 901 empfangenen Kommunikationsdaten auch zur Datensatzverwaltungseinheit 510 geführt, entweder so wie sie sind, oder wenn die Datei ID und die Versionsnummer geeignet verarbeitet sind.
An der Editierendverarbeitungseinheit 904 wird, wenn die Eingabe von der Verzweigungseinheit 901 empfangen ist, die Verarbeitung in Übereinstimmung mit dem Flussdiagramm von Fig. 29 wie folgt erläutert, durchgeführt.
An der Editierendverarbeitungseinheit 904 wird zuerst auf die Zählerspeichereinheit 905 zugegriffen, und der Zählerwert C und das Löschverzögerungs-Flag F für die spezifizierte Versionsnummer der spezifizierten Datei ID wird erlangt (Schritt S31). Dann wird dieser Zählerwert. C um Eins vermindert (Schritt S32), und der sich ergebende Zählerwert C wird in der Zählerspeichereinheit 905 gespeichert (Schritt S33).
Als nächstes wird beurteilt, ob der Zählerwert gleich 0 ist oder nicht (Schritt S34). Wenn der Zählerwert C nicht gleich 0 ist, wird die Verarbeitung an der Editierendverarbeitungseinheit 904 beendet. Auf der anderen Seite wird, wenn der Zählerwert gleich 0 ist, beurteilt, ob das Löschverzögerungs-Flag Wahr oder Falsch ist (Schritt S35). Wenn das Löschverzögerungs-Flag F falsch steht, ist die Verarbeitung an der Editierendverarbeitungseinheit 904 beendet. Auf der anderen Seite, wenn das Löschverzögerungs- Flag F Wahr ist, wird der Befehl zum Löschen der spezifizierten Version der spezifizierten Datei von der Löschbefehlsausgabeeinheit 906 an die Datensatzverwaltungseinheit 510 ausgegeben (Schritt S36).
Es wird darauf hingewiesen, dass an der Verzweigungseinheit 901, wenn das erste eine Wort der Kommunikationsdaten ausgelesen wird, und wenn festgestellt wird, dass es keines der Befehlsworte für die Editierstartdeklaration, die Versionslöschanforderung, und die Editierenddeklaration, oben erläutert, ist, die Kommunikationsdaten in die Datensatzverwaltungseinheit 510 eingegeben werden, so wie sie sind.
Als nächstes wird eine beispielhafte Löschbefehlausführungsverarbeitung an der Datensatzverwaltungseinheit 510 beschrieben. Hier unterscheidet sich die Löschbefehls-Verarbeitungsprozedur in Abhängigkeit davon, ob das Differenzstapelverfahren, das RCS- Verfahren, oder das modifizierte SCCS-Verfahren durch die Datensatzverwaltungseinheit 510 verwendet wird, so dass ein Beispiel für jeden dieser drei Fälle beschrieben wird.
Bei der folgenden Erläuterung werden die folgenden Symbole verwendet.
r: Eine Versionsnummer der Löschzielversion
f: Eine Versionsnummer der ältesten Version, gespeichert durch die Datensatzverwaltungseinheit 510, aus den Datensätzen für die Zieldatei (in vielen Fällen ist f = 1, wenn jedoch die Version 1 durch den Versionslöschbefehl in der Vergangenheit gelöscht wurde, kann f einen anderen Wert als 1 annehmen)
n: Eine Versionsnummer der neuesten Version (momentane Version), die durch die Datensatzverwaltungseinheit 510 gespeichert wird, unter den Datensätzen für die Zieldatei
p(x): Eine Versionsnummer für eine Version, die unmittelbar einer bestimmten Version x aus den durch die Datensatzverwaltungseinheit 510 gespeicherten Versionen vorhergeht (in vielen Fällen ist p = x-1, falls jedoch die Version x-1 in der Vergangenheit gelöscht wurde, ist p = x-2, und falls die Version x-2 in der Vergangenheit ebenso gelöscht wurde, ist p = x-3, usw.
s(x): Eine Versionsnummer einer Version, die einer bestimmten Version x aus dem durch die Datensatzverwaltungseinheit 510 gespeicherten Versionen unmittelbar nachfolgt (in vielen Fällen s = x+1, falls jedoch die Version x+1 in der Vergangenheit gelöscht wurde, ist s = x+2, und falls die Version x+2 in der Vergangenheit ebenso gelöscht wurde, ist s = -x+3, und so weiter)
V[x]: (Inhalt von) Version x
V[x]-V[y]: Eine Differenz zwischen der Version x und der Version y
Zunächst wird ein Fall erläutert, bei dem die Datensatzverwaltungseinheit 510 die Datensatzverwaltung in Übereinstimmung mit dem Differenzstapelverfahren ausführt. Fig. 30 zeigt ein Flussdiagramm für die Löschbefehlausführungsverarbeitung in diesem Fall.
(i) Ein Fall, bei dem das Löschziel nicht die erste Version der Datensätze der momentanen Version ist (ein Fall, bei dem r ≠ f im Schritt S41 und r ≠ n im Schritt S45)
In diesem Fall werden die vorhergehende Version (V[p(r)]) und die nachfolgende Version (V[s(r)]) der Löschzielversion restauriert (Schritt S47), eine Differenz (V[s(r)]-V[p(r)]) zwischen diesen zwei Versionen wird erlangt (Schritt S48), und die Differenzen (V[s(r)]-V[r]) und (V[r]-V[p(r)]) der Löschzielversion mit Bezug auf ihre vorhergehende und nachfolgende Version werden durch die erlangte Differenz (V[s(r)]-V[p(r)]) ersetzt (Schritt S49).
(ii) Ein Fall, bei dem das Löschziel die erste Version der Datensätze ist (ein Fall von r = f im Schritt S41)
In diesem Fall wird die der Löschzielversion nachfolgende Version (V[s(r)]) der Löschzielversion restauriert (Schritt S42), die erste Version (V[r]) der Datensätze und eine Differenz zwischen der ersten Version und ihrer nachfolgenden Version (V[s(r)])-V[r]) werden gelöscht (Schritt S43), und V[s(r)] wird als neue erste Version der Datensätze eingesetzt (Schritt S44).
(iii) Ein Fall, bei dem das Löschziel die letzte Version (momentane Version) der Datensätze ist (ein Fall von r = n im Schritt S45).
In diesem Fall wird eine Differenz (V[r]-V[p(r)]) zwischen dieser Version und ihre vorhergehende Version gelöscht (Schritt S46).
Als nächstes wird ein Fall erläutert, bei dem die Datensatzverwaltungseinheit 510 die Datensatzverwaltung in Übereinstimmung mit dem RCS-Verfahren ausführt. Fig. 31 zeigt ein Flussdiagramm für die Löschbefehlsausführungsverarbeitung in diesem Fall.
(i) Ein Fall, in dem das Löschziel nicht die erste Version der Datensätze oder die momentane Version ist (ein Fall von r ≠ f im Schritt S61 und r ≠ n im Schritt S65)
In diesem Fall werden die vorhergehende Version (V[p(r)]) und die nachfolgende Version (V[s(r)]) der Löschzielversion restauriert (Schritt S67), eine Differenz (V[p(r)] V[s(r)]) zwischen diesen zwei Versionen wird erlangt (Schritt S68), und die Differenzen (V[p(r)]-V[r]) und (V[r]-V[s(r)]) der Löschzielversion mit Bezug auf ihre vorhergehende und nachfolgende Version werden durch die erlangte Differenz (V[p(r)])-V[s(r)]) (Schritt S69).
(ii) Ein Fall, bei dem das Löschziel die erste Version der Datensätze ist (ein Fall von r = f im Schritt S61) In diesem Fall wird eine Differenz (V[r] - V[s(r)]) zwischen dieser Version und ihrer vorhergehenden Version gelöscht (Schritt S62).
(iii) Ein Fall, bei dem das Löschziel die neueste Version (momentane Version) der Datensätze ist (ein Fall von r = n im Schritt S63).
In diesem Fall wird die der momentanen Version vorhergehende Version (V[p(r)]) restauriert (Schritt S64), eine Differenz zwischen der momentanen Version und ihrer vorhergehenden Version (V[p(r)]-V[r]) wird gelöscht (Schritt S65), und V[p(r)] wird als neue momentane Version gesetzt (Schritt S66).
Als nächstes wird ein Fall erläutert, bei dem die Datensatzverwaltungseinheit die Datensatzverwaltung in Übereinstimmung mit dem modifizierten SCCS-Verfahren ausführt. Fig. 32 zeigt ein Flussdiagramm für die Löschbefehlsausführungsverarbeitung in diesem Fall. Hier zeigt das Flussdiagramm von Fig. 32 die Löschverarbeitungsprozedur für einen Block, der den Datensatz darstellt. Die Löschverarbeitung an der Datensatzverwaltungseinheit 510 wird ausgeführt, indem diese Prozedur auf alle Blöcke angewendet wird, die die Löschzielversion enthalten.
In der folgenden Erläuterung werden die folgenden Symbole weiterverwendet.
i: Ein Erstellungszeitpunkt eines Blocks, der ein Verarbeitungsziel ist
d: Ein Löschzeitpunkt eines Blocks, der ein Verarbeitungsziel ist
Hier wird der Block, der noch nicht einmal in der momentanen Version gelöscht ist, mit d = ∞ bezeichnet.
(i) Ein Fall, bei dem das Löschziel nicht die momentane Version ist (ein Fall von r ≠ n im Schritt S81).
In diesem Fall werden für solche Blöcke, die nur in der Löschzielversion existiert haben (i = r im Schritt S85 und d = s(r) im Schritt S86), diese Blöcke von den Datensatz- Daten gelöscht (Schritt S90).
Für solche Blöcke, die in der Löschzielversion (i = r im Schritt S85 und d ≠ s(r) im Schritt S86) erzeugt werden, diese Blöcke als in der der Löschzielversion nachfolgenden Version (V[s(r)]) erzeugt erachtet (Schritt S87).
Für solche Blöcke, die in der Löschzielversion gelöscht werden (i ≠ r im Schritt S85 und d = r im Schritt S88), werden diese Blöcke als in der der Löschzielversion nachfolgenden Version (V[s(r)] gelöscht betrachtet (Schritt S89).
(ii) Ein Fall, bei dem das Löschziel die momentane Version ist (ein Fall von r = n im Schritt S81)
In diesem Fall werden für solche Blöcke, die in der momentanen Version erzeugt werden (i = n im Schritt S82), diese Blöcke von den Datensatz-Daten gelöscht (Schritt S90).
Für solche Blöcke, die in der momentanen Version gelöscht werden (i ≠ n im Schritt S82 und d = n im Schritt S83), werden diese Blöcke erachtet, die nicht gelöscht werden (d = ∞) (Schritt S84).
Nachdem die obige Verarbeitung auf alle Blöcke angewendet wurde, können für beliebige benachbarte zwei Blöcke in den Datensätzen, falls sie die identische Erzeugungszeit und die identische Löschzeit aufweisen, diese zwei Blöcke miteinander verbunden werden.
Es wird darauf hingewiesen, dass bei dem Obigen ein Fall einer Löschung einer Version durch einen Löschbefehl erläutert wurde, das jedoch in dem allgemeinen Versionsverwaltungssystem es durch eine Verarbeitung der Löschanforderung für eine Vielzahl Versionen durch ein Auftrennen von diesen in eine Vielzahl von Löschbefehlen für eine jede der Zielversionen, einfach ist, einen ähnlichen Effekt zu erzielen, wie bei Bereitstellen einer Funktion zum Löschen einer Vielzahl von Versionen durch einen Löschbefehl.
Wie erläutert, ist in Übereinstimmung mit diesem fünften Ausführungsbeispiel eine Anzahl von Clients, die eine jede Version einer jeden Datei editieren, für jede Version einer jeden Datei gespeichert, und die Ausführung der Löschung wird verzögert, bis kein Client verbleibt, der die Löschzielversion für die Zieldatei editiert, auch wenn es eine Anfrage für ein Löschen dieser Version der Datei von dem Nutzer gibt, so dass kein Client die Version während der Editierung löschen kann, und daher ist es möglich, das asynchrone Editiersystem zu realisieren, bei dem die Verbindungsverarbeitung ohne Probleme ausgeführt werden kann.
Hier wurde die Löschung des Datensatzes in diesem fünften Ausführungsbeispiel durchgeführt, als die Löschanforderung vom Client an den Dateiverwaltungsserver ausgegeben würde, es ist jedoch auch möglich, eine Konfiguration zu betrachten, bei der die Löschanforderung von einem Element erzeugt wird, das sich vom Client unterscheidet. Beispielsweise kann für einen beliebigen Datensatz, für den eine vorgegebene Zeitperiode seit seiner Erzeugung abgelaufen ist, die Löschanforderung automatisch innerhalb des Servers erzeugt werden. In einem Fall ist es weiter ausreichend, die asynchrone Editierung nur für die neueste Version zu unterstützen, und keine Editierung für die vergangene Version ist enthalten, und dann ist es ausreichend, eine Konfiguration zu verwenden, bei der die Löschanforderung für eine vorhergehende Version automatisch innerhalb des Servers zu einer Zeit einer Erzeugung einer neuen Version erzeugt wird.
Es wird darauf hingewiesen, dass dieses fünfte Ausführungsbeispiel ein Fall war, bei dem die Client- Zähleinheit zu einer Konfiguration von Fig. 13 hinzugefügt ist, bei der die Dateiinhalt-Geheimhaltungsfunktion und die asynchrone Editierfunktion auf dem Client-Server-System implementiert sind, es ist jedoch auch möglich, die Client- Zieleinheit einer Konfiguration von Fig. 16 oder Fig. 20 hinzuzufügen, bei der die asynchrone Editierfunktion auf dem Client des Serversystems implementiert ist. In solch einem Fall kann eine Konfiguration und eine Funktion der Client- Zähleinheit im wesentlichen die gleiche sein, wie oben für einen Fall einer Verwendung einer Konfiguration von Fig. 13 erläutert.
Als nächstes wird das sechste Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert. In diesem sechsten Ausführungsbeispiel ist das gemeinsame Dateieditiersystem von Fig. 13, Fig. 16 oder Fig. 20, oben beschrieben, weiter ausgestattet, wenn die Blockdaten einer bestimmten Version verschlüsselt werden, mit einer Funktion zum Verzögern einer Ausführung einer Löschung einer Version in Reaktion auf eine Löschanforderung für eine bestimmte Version einer bestimmten Datei, bis ein Client verbleibt, der diese bestimmte Version dieser bestimmten Datei editiert, wie in Fig. 25 oben beschrieben, und eine zusätzliche Funktion zum Rekonstruieren der Blockdaten dieser bestimmten Datei.
Wie oben erwähnt, ist es bei dem die Datensatzverwaltung verwendenden System möglich, eine Funktion bereitzustellen, um einige Versionen aus den Datensätzen zu löschen. Dieses sechste Ausführungsbeispiel liefert eine Funktion zum Löschen des Datensatzes einer bestimmten Version, wenn die Blockdaten verschlüsselt sind. Zusätzlich liefert dieses sechste Ausführungsbeispiel weiter eine Funktion zum Reduzieren einer Anzahl von Blöcken durch Rekonstruieren der Blockdaten.
Um solch zusätzliche Funktionen zu realisieren, ist in diesem sechsten Ausführungsbeispiel der Client mit einer Einrichtung zum Rekonstruieren der Blockdaten der Datei ausgestattet. Durch diese Einrichtung kann der Client die Datensätze einer bestimmten Version löschen und die Datei-Daten in die erwünschten Blöcke rekonstruieren.
Fig. 33 zeigt eine Konfiguration des gemeinsamen Dateieditiersystems dieses sechsten Ausführungsbeispiels, wie oben erläutert, basierende auf dem gemeinsamen Dateieditiersystem von Fig. 25, oben erläutert.
Bei dieser Konfiguration von Fig. 33 ist der Dateiverwaltungsserver 95 und der Kommunikationspfad 111 im wesentlichen ähnlich zu denen in Fig. 25. Jeder Zugriffanfragende Client 92 unterscheidet sich von dem von Fig. 25 darin, dass er weiter eine Blockdatenrekonstruktionseinheit 910 enthält. Es muss dabei die Blockdatenrekonstruktionseinheit 910 nicht notwendigerweise in jedem der Clients 92 des Systems bereitgestellt sein. Somit wird in diesem sechsten Ausführungsbeispiel die Versionslöschanforderung für eine bestimmte Datei ausgeführt, wenn der Zählerwert der Client-Zähleinheit 900 gleich 0 ist, genauso wie im fünften Ausführungsbeispiel, oben beschrieben.
Nunmehr wird eine beispielhafte Ausführungsverarbeitung zum Löschen des Datensatzes einer bestimmten Version erläutert, im Falle, dass die Blockdaten verschlüsselt sind. Dabei unterscheidet sich die Versionslöschverarbeitungsprozedur in Abhängigkeit davon, ob das Differenzstapelverfahren, das RCS- Verfahren oder das modifizierte SCCS-Verfahren durch die Datensatzverwaltungseinheit 510 verwendet wird, sodass ein Beispiel für jeden dieser drei Fälle nacheinander erläutert wird.
In der folgenden Erläuterung werden die folgenden Symbole verwendet.
r: Eine Versionsnummer der Löschzielversion
f: Eine Versionsnummer der ältesten Version, gespeichert durch die Datensatzverwaltungseinheit 510, unter den Datensätzen für die Zieldatei (in vielen Fällen ist f = 1, wenn jedoch die Version 1 durch den Versionslöschbefehl in der Vergangenheit gelöscht wurde, kann f einen Wert annehmen, der sich von 1 unterscheidet)
n: Eine Versionsnummer der neuesten Version (momentane Version), gespeichert durch die Datensatzverwaltungseinheit 510, unter den Datensätzen für die Zieldatei
p(x): Eine Versionsnummer einer Version, die unmittelbar einer bestimmten Version x vorhergeht, unter den Versionen, die durch die Datensatzverwaltungseinheit 510 gespeichert sind (in vielen Fällen ist d = x-1, falls jedoch die Version x-1 in der Vergangenheit gelöscht wurde, ist p = x-2, und falls die Version x-2 ebenso in der Vergangenheit gelöscht wurde, ist p = x-3, und so weiter)
s (x) Eine Versionsnummer einer Version, die unmittelbar einer bestimmten Version x nachfolgt, aus den durch die Datensatzverwaltungseinheit 510 gespeicherten Versionen (in vielen Fällen ist s = x+1, falls jedoch die Version x+1 in der Vergangenheit gelöscht wurde, ist s = x-2, und falls die Version x+2 ebenso in der Vergangenheit gelöscht wurde, ist s = x+3, und so weiter)
V[x]: (Inhalt von) Version x
V[x]-V[y]: eine Differenz zwischen Version x und Version Y.
Erst wird ein Fall erläutert, bei dem die Datensatzverwaltungseinheit 510 die Datensatzverwaltung in Übereinstimmung mit dem Differenzstapelverfahren ausführt. Fig. 34 zeigt ein Flussdiagramm für die Verarbeitungsprozedur an der Blockdatenrekonstruktionseinheit 910 im Client 92 in diesem Fall, wohingegen Fig. 35 ein Flussdiagramm für die Verarbeitungsprozedur an der Datensatzverwaltungseinheit 510 in dem Server 95 zeigt, der die Löschanforderung vom Client 92 in diesem Fall empfangen hat.
Zuerst wird die Verarbeitungsprozedur des Clients 92 mit Bezug auf Fig. 34 erläutert.
(i) Ein Fall, bei dem das Löschziel nicht die erste Version der Datensätze oder die momentane Version ist (ein Fall von r ≠ f im Schritt S101 und r ≠ n im Schritt S106).
In diesem Fall wird die momentane Version (V[s(r)]) der Löschzielversion vom Server 95 ausgelesen (Schritt S108). Hier wird (eine Vielzahl von) verschlüsselten Blockdaten vom Server 95 übermittelt.
Dann werden die übermittelten Blockdaten durch die Chiffriereinheit 112 entschlüsselt, und die nachfolgende Version (V[s(r)]) und die vorhergehende Version (V[p(r)]) der Löschzielversion werden restauriert (Schritt S109). Dabei kann (V[s(r)]) erlangt werden von (V[s(r)]), ausgelesen im Schritt S108.
Dann wird eine Differenz (V[s(r)])-(V[p(r)]) zwischen diesen zwei Versionen erlangt (Schritt S110).
Dann wird die erlangte Differenz (V[s(r)])-(V[p(r)]) durch die Chiffriereinheit 112 als neue Blockdaten verschlüsselt (Schritt S111).
Zuletzt werden diese verschlüsselten Blockdaten und die Löschanforderung für die Version r zum Server 95 übermittelt (Schritt S112).
(ii) Ein Fall, bei dem das Löschziel die erste Version der Datensätze ist (ein Fall von r = f im Schritt S101)
In diesem Fall wird die der Löschzielversion nachfolgende Version (V[s(r)]) vom Server 95 ausgelesen (Schritt S102). Dabei werden (eine Vielzahl von) verschlüsselten Blockdaten vom Server 95 übermittelt.
Dann werden die übermittelten Blockdaten durch die Chiffriereinheit 112 entschlüsselt, und die der Löschzielversion nachfolgende Version (V[s(r)]) wird restauriert (Schritt S103).
Dann wird das Erlangte (V[s(r)]) durch die Chiffriereinheit 112 als neue Blockdaten verschlüsselt (Schritt S104).
Zuletzt werden diese verschlüsselten Blockdaten und die Löschanforderung für die Version r zum Server 95 übermittelt (Schritt S105).
(iii) Ein Fall, bei dem das Löschziel die letzte Version (momentane Version) der Datensätze ist (ein Fall von r = n im Schritt S106).
In diesem Fall wird die Löschanforderung für die Version r zum Server 95 übermittelt (Schritt S107).
Als nächstes wird die Verarbeitungsprozedur des Servers 95 mit Bezug auf Fig. 35 erläutert, der die Löschanforderung vom Client 92 empfangen hat.
(i) Ein Fall, bei dem das Löschziel nicht die erste Version der Datensätze oder die momentane Version ist (ein Fall von r ≠ f im Schritt S121 und r + n im Schritt S123)
In diesem Fall werden Blockdaten (V[s(r)])-V[r]) und Blockdaten (V[s(r)])-V[p(r)]) gelöscht, und Blockdaten (V[s(r)])-V[p(r)]), vom Client 92 übermittelt, werden stattdessen eingefügt (Schritt S125).
(ii) Ein Fall, bei dem das Löschziel die erste Version der Datensätze ist (ein Fall von r = f im Schritt S101)
In diesem Fall werden Blockdaten V[r] und Blockdaten (V[s(r)])-V[r]) gelöscht, und Blockdaten V[s(r)], übermittelt vom Client 92, werden stattdessen eingefügt (Schritt S122).
(iii) Ein Fall, bei dem das Löschziel die neueste Version (momentane Version) der Datensätze ist (ein Fall von r = n im Schritt S106).
In diesem Fall werden Blockdaten (V[r]-(V[p(r)]) gelöscht (Schritt S124).
Durch die obige Prozedur kann der Datensatz der Version r gelöscht werden.
Als nächstes wird ein Fall erläutert, bei dem die Datensatzverwaltungseinheit 510 die Datensatzverwaltung in Übereinstimmung mit dem RCS-Verfahren ausführt. Fig. 36 zeigt ein Flussdiagramm für die Verarbeitungsprozedur an der Blockdatenrekonstruktionseinheit 910 im Client 92 in diesem Fall, während Fig. 37 in diesem Fall ein Flussdiagramm für die Verarbeitungsprozedur an der Datensatzverwaltungseinheit 510 im Server 95 zeigt, der die Löschanforderung vom Client 92 erhalten hat.
Zuerst wird die Verarbeitungsprozedur des Clients 92 mit Bezug auf Fig. 36 erläutert.
(i) Ein Fall, bei dem das Löschziel nicht die erste Version der Datensätze oder die momentane Version ist (ein Fall von r ≠ f im Schritt S131 und r ≠ n im Schritt S133).
In diesem Fall wird die der Löschzielversion vorhergehende Version (V[p(r)]) vom Server 95 ausgelesen (Schritt S138). Dabei wird (eine Vielzahl von) verschlüsselten Blockdaten, die die neueste Version enthalten, vom Server 95 übermittelt.
Dann werden die übertragenen Blockdaten durch die Chiffriereinheit 112 entschlüsselt, und die nachfolgende Version (V[s(r)]) und die vorhergehende Version (V[p(r)]) der Löschzielversion werden restauriert (Schritt S139). Dabei kann V[s(r)] aus V[p(r)], gelesen im Schritt S138, erhalten werden.
Dann wird eine Differenz (V[p(r)]- V[s(r)]) zwischen diesen zwei Versionen erlangt (Schritt S140).
Dann wird die erlangte Differenz (V[p(r)]-V(s(r)]) durch die Chiffriereinheit 112 als neue Blockdaten verschlüsselt (Schritt S141).
Zuletzt werden diese verschlüsselten Blockdaten und die Löschanforderung für die Version r zum Server 95 übertragen (Schritt S142).
ii) Ein Fall, bei dem das Löschziel die erste Version der Datensätze ist (ein Fall von r = f im Schritt S131)
In die em Fall wird die Löschanforderung für die Version r zum Server 95 übertragen (Schritt S132).
(iii) Ein Fall, bei dem das Löschen die neueste Version (momentane Version) der Datensätze ist (ein Fall von r = n im Schritt S133).
In diesem Fall wird die der Löschzielversion vorhergehende Version (V[p(r)]) vom Server 95 ausgelesen (Schritt S134). Datei werden (eine Vielzahl von) verschlüsselten Blockdaten, die die neueste Version enthalten, vom Server 95 übertragen.
Dann werden die übertragenen Blockdaten durch die Chiffriereinheit 112 entschlüsselt, und die der Löschzielversion vorhergehende Version (V[p(r)]) wird restauriert (Schritt S135).
Dann wird das Erlangte (V[p(r)]) durch die Chiffriereinheit 112 als neue Blockdaten verschlüsselt (Schritt S136).
Zuletzt werden diese verschlüsselten Blockdaten und die Löschanforderung für die Version r zum Server 95 übertragen (Schritt S137).
Als nächstes wird die Verarbeitungsprozedur des Servers 95, der die Löschanforderung vom Client 92 empfangen hat, mit Bezug auf Fig. 37 erläutert.
(i) Ein Fall, bei dem das Löschziel nicht die erste Version der Datensätze oder die momentane Version ist (ein Fall von r ≠ f im Schritt S151 und r + n im Schritt S153)
In diesem Fall werden Blockdaten (V[r]-V[s(r)]) gelöscht, und Blockdaten (V[p(r)]-(V[s(r)]), übertragen vom Client 92, stattdessen eingefügt (Schritt S155).
(ii) Ein Fall, bei dem das Löschziel die erste Version der Datensätze ist (ein Fall von r = f im Schritt S151) In diesem Fall werden Blockdaten (V[r]-V[s(r)]) gelöscht (Schritt S152).
(iii) Ein Fall, bei dem das Löschziel die neueste Version (momentane Version) der Datensätze ist (ein Fall von r = n im Schritt S153).
in diesem Fall werden Blockdaten V[r] und Blockdaten V[p(r)]-V[r]) gelöscht, und Blockdaten V[p(r)], übertragen vom Client 92, werden stattdessen eingefügt (Schritt S154).
Durch die obige Prozedur kann der Datensatz der Version r gelöscht werden.
Als nächstes wird ein Fall erläutert, bei dem die Datensatzverwaltungseinheit 510 die Datensatzverwaltung in Übereinstimmung mit dem modifizierten SCCS-Verfahren ausführt. Wie oben erwähnt, werden beim modifizierten SCCS- Verfahren die Blöcke sequentiell aufgeteilt, wenn die Version voranschreitet. Wenn die Anzahl von Blöcken sich erhöht, erhöht sich der Overhead aufgrund der Blockidentifikationsinformation und der Blockverarbeitung, so dass es vorzuziehen ist, die Anzahl von Blöcken nicht zu weit ansteigen zu lassen.
Wie in Fig. 32 gezeigt, kann im Falle einer Durchführung der Datensatzverwaltung durch das modifizierte SCCS-Verfahren die Datensatzverwaltungseinheit 510 des Servers 95 den Versionsdatensatzlöschbefehl ausführen. Demzufolge ist es möglich, eine Konfiguration zu verwenden, bei dem die Versionslöschung durch die Datensatzverwaltungseinheit 510 des Servers 95 durchgeführt wird, während die Blockrekonstruktion durch die Blockdatenrekonstruktionseinheit 910 des Clients 92 durchgeführt wird. In solch einem Fall ist die Verarbeitungsprozedur wie folgt.
Der Client 92 überträgt zuerst den Löschbefehl für die Version r zum Server 95.
Dann löscht die Datensatzverwaltungseinheit 510 des Servers 95 den Datensatz der Version r durch die Prozedur von Fig. 32.
Dann liest der Client 92 die Dateien von V[s(r)] oder V[n] aus, und führt die Blockrekonstruktion an der Blockdatenrekonstruktionseinheit 910 und die Verschlüsselung an der Chiffriereinheit 112 durch, und liefert dann die rekonstruierten Blockdaten zum Server 95 zurück. Dabei sind die Blockdaten, die rekonstruiert werden können, solche Blockdaten, die in ihren Positionen fortlaufend angeordnet sind, und die einen identischen Erzeugungszeitpunkt und Löschzeitpunkt aufweisen. Nachdem diese Blöcke entschlüsselt sind, werden sie rekonstruiert, und als beliebige neue Blockdaten verschlüsselt, und dann zum Server 95 übertragen.
Zuletzt ersetzt die Datensatzverwaltungseinheit 510 des Servers 95 den alten Block mit den übertragenen neuen Blockdaten.
Es wird darauf hingewiesen, dass das Merkmal zur Rekonstruktion der Blockdaten in Übereinstimmung mit diesem sechsten Ausführungsbeispiel in dem Dateieditiersystem mit alleine der Dateiinhaltsgeheimhaltungseigenschaft, wie beispielsweise den von Fig. 23, oben erläutert, verwirklicht sein kann.
Nunmehr wird das siebte Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert. In diesem siebten Ausführungsbeispiel ist das gemeinsame Dateieditiersystem von Fig. 13, Fig. 16 oder Fig. 20, oben beschrieben, weiter mit einer zusätzlichen Funktionalität ausgestattet, die es dem Client, der bereits eine bestimmte Version einer bestimmten Datei besitzt, ermöglicht, nur einen notwendigen Abschnitt einer weiteren Version neu auszulesen, anstatt die gesamte Datei dieser anderen Version auszulesen.
Fig. 38 zeigt eine Konfiguration des gemeinsamen Dateieditiersystems dieses siebten Ausführungsbeispiels, wie oben erläutert, basierend auf dem oben beschriebenen gemeinsamen Dateieditiersystem von Fig. 13.
Bei dieser Konfiguration von Fig. 38 ist der Kommunikationspfad 111 im wesentlichen ähnlich zu dem von Fig. 13. Der Dateiverwaltungsserver 96 unterscheidet sich von dem von Fig. 13 darin, dass er weiter eine Differenzinformationserstellungseinheit 930 umfasst, und wobei jeder Zugriffanfragende Client 93 sich von dem in Fig. 13 darin unterscheidet, dass er weiter eine Dateispeichereinheit 920 und eine Dateidatenerstellungseinheit 921 umfasst.
Der Client 93 speichert die Datei, auf die vorhergehend zugegriffen wurde, zusammen mit ihrer Versionsinformation in der Dateispeichereinheit 920. Im Falle eines Auslesens einer anderen Version (wie beispielsweise der neuesten Version) der gemeinsamen Datei von dem Server 96, benachrichtigt der Client 93 den Server 96 mit der momentan innegehaltenen Versionsinformation und der erwünschten Versionsinformation. Dann erstellt die Differenzinformationserstellungseinheit 930 des Servers 96 die Differenzdaten zwischen der erwünschten Version und der bereits besessenen Version, in Übereinstimmung mit den obigen zwei Versionsinformationen, benachrichtigt vom Client 93, und liefert die erstellten Differenzdaten zum Client 93 zurück. Dann erstellt die Datei- Datenerstellungseinheit 921 des Clients 93 die erwünschte Version aus den momentan innegehaltenen Dateidaten und den Differenzdaten, übermittelt vom Server 96. Dann wird die erstellte erwünschte Version der gemeinsamen Dateieditiereinheit 122 übergeben, zum Durchführen der Editierung mit Bezug auf die erwünschte Version.
Allgemein sind die Differenzdaten zwischen Versionen geringer als die Daten der gesamten Datei, so dass ein Datenkommunikationsaufwand reduziert werden kann, und ein Hochgeschwindigkeitsauslesebetrieb in diesem siebten Ausführungsbeispiel realisiert werden kann.
Dabei unterscheidet sich ein Verfahren zum Erstellen der Differenzdaten an der Differenzinformationserstellungseinheit 930 des Servers 96 in Abhängigkeit davon, ob das Differenzstapelverfahren, das RCS-Verfahren, oder das modifizierte SCCS-Verfahren durch die Datensatzverwaltungseinheiten 510 verwendet wird, so dass ein Beispiel für jeden dieser drei Fälle nacheinander erläutert wird.
In der folgenden Erläuterung werden die folgenden Symbole verwendet.
c. eine Versionsnummer der bereits durch den Client 93 innegehaltenen Version
r. eine Versionsnummer einer erwünschten Version, neuerlich durch den Client 93 auszulesen
V[x]: (Inhalt von) Version x
V[x]-V[y] eine Differenz zwischen Version x und Version y
Zuerst wird die Verarbeitungsprozedur für die Differenzinformationseinheit 930 in einem Fall erläutert, bei dem die Datensatzverwaltungseinheit 510 die Datensatzverwaltung in Übereinstimmung mit dem Differenzstapelverfahren durchführt.
(i) Ein Fall eines Auslesens einer Version, die neuer als die bereits innegehaltene Version ist (r > c).
In diesem Fall, da das Differenzstapelverfahren ein Verfahren ist, das die Differenzen zwischen Versionen aufeinanderlegt, ist es ausreichend, die Differenzblockdaten zwischen der Version r und der Version c auszuwählen.
(ii) Ein Fall eines Auslesens einer Version, die älter als die bereits innegehaltene Version ist (r < c).
In diesem Fall sind die folgenden zwei Verfahren verfügbar.
(a) V[r] wird wiederholt ohne die Differenzdaten aufzubauen.
Im Falle dass die Blockdaten verschlüsselt sind, kann der Server die Differenzdaten nicht erstellen, so dass dieses Verfahren verwendet werden sollte.
(b) Der Server restauriert V[r] und V[r], und erlangt V[r]- V[r].
Dieses Verfahren ist möglich, wenn die Blockdaten nicht verschlüsselt sind.
Als nächstes wird die Verarbeitungsprozedur für die Differenzinformationserstellungseinheit 930 in einem Fall erläutert, bei dem die Datensatzverwaltungseinheit 510 die Datensatzverwaltung in Übereinstimmung mit dem RCS-Verfahren durchführt. Fig. 31 zeigt ein Flussdiagramm für die Löschbefehlsausführungsverarbeitung in diesem Fall.
(i) Ein Fall eines Auslesens einer Version, die neuer als die bereits innegehaltene Version ist (r > c).
In diesem Fall sind die folgenden zwei Verfahren verfügbar.
(a) V[r] wird wiederholt, ohne die Differenzdaten zu erstellen.
Falls die Blockdaten verschlüsselt sind, kann der Server die Differenzdaten nicht erstellen, so dass dieses Verfahren verwendet werden sollte.
(b) Der Server restauriert V[r] und V[c], und erlangt V[r]- V[c].
Dieses Verfahren ist möglich, wenn die Blockdaten nicht verschlüsselt sind.
(ii) Ein Fall eines Auslesens einer Version, die älter als die bereits innegehaltene Version ist (r < c).
In diesem Fall, da das RCS-Verfahren ein Verfahren ist, was die Differenz zwischen Versionen in rückwärtiger Richtung als einen Datensatz belässt, ist es ausreichend, die Differenzblockdaten zwischen der Version r und der Version c auszuwählen.
Als nächstes wird die Verarbeitungsprozedur für die Diffferenzinformationserstellungseinheit 930 in einem Fall erläutert, bei dem die Datensatzverwaltungseinheit 510 die Datensatzverwaltung in Übereinstimmung mit dem modifizierten SCCS-Verfahren durchführt. Fig. 39 zeigt ein Flussdiagramm für die Verarbeitungsprozedur für die Differenzinformationserstellungseinheit 930, um den Differenzblock aus den Blöcken auszuwählen, die den Datensatz der Datei darstellen. Dabei zeigt das Flussdiagramm von Fig. 39 die Differenzblockauswahlverarbeitungsprozedur für einen Black, der den Datensatz darstellt. Die Differenzblockauswahlverarbeitung einer Differenzinformationserstellungseinheit 930 wird durch ein Anwenden dieser Prozedur auf alle Blöcke durchgeführt.
In der folgenden Erläuterung werden weiter die folgenden Symbole verwendet.
1: eine Erzeugungsversionsnummer eines Blocks, der ein Verarbeitungsziel ist.
d. Eine Löschversionsnummer eines Blocks, der ein Verarbeitungsziel ist.
Hier wird der Block, der noch nicht gelöscht ist, durch d = NULL bezeichnet.
(i) Ein Fall eines Auslesens einer Version, die neuer als die bereits innegehaltene Version ist (r > c im Schritt S161).
In diesem Fall wird ein Block ausgewählt, der eine der folgenden zwei Bedingungen erfüllt (Schritt S167).
(a) Ein Block, der während einer Periode von der Version c zur Version r erzeugt wurde, und der zu einem Zeitpunkt der Version r nicht gelöscht wurde, d. h., (r ≥ i > c) und {(r < d) oder (d = NULL)} (Schritt S162).
(b) Ein Block, der zu einem Zeitpunkt der Version c bereits erzeugt wurde, und der während einer Periode von der Version c zur Version r gelöscht wurde, d. h., (i ≤ c) und (r ≥ d > c) (Schritt S163).
(ii) Im Fall eines Auslesens einer Version, die älter als die bereits innegehaltene Version ist (r < c im Schritt S164).
In diesem Fall wird ein Block ausgewählt, der eine der zwei folgenden Bedingungen erfüllt (Schritt S167).
(a) Ein Block, der während einer Periode von der Version r zur Version c erzeugt wurde, und der zu einem Zeitpunkt der Version c nicht gelöscht wurde, d. h., (r < i ≤ c) und {(d < c) oder (d = NULL)} (Schritt S165).
(b) Ein Block, der zu einem Zeitpunkt der Version c bereits erzeugt war, und der während einer Periode von der Version r zur Version c gelöscht wurde, d. h., (i ≥ c) und (r < d ≤ c) (Schritt S166).
Nach einem Auswählen des Differenzblocks durch die obige Prozedur wandelt die Differenzinformationserstellungseinheit 930 die ausgewählten Differenzblockdaten in die Differenzinformation mit Bezug auf die bereits durch den Client 93 innegehaltene Version um, und übermittelt die erlangte Änderungsinformation zum Client 93. Beispielsweise werden hinsichtlich der Einfügungsdaten die Einfügungspositionen in Bezug auf die durch den Client 93 innegehaltene Version erlangt, und zusammen mit den Einfügungsblockdaten übermittelt. Hinsichtlich der Löschdaten wird der Löschbereich mit Bezug auf die durch den Client 93 innegehaltene Version erlangt und so übermittelt, wie er ist. Aufgrund dessen kann der Client 93 die erwünschte Version einfach erstellen, und der Datenkommunikationsaufwand vom Server 96 zum Client 93 kann gering gehalten werden.
Es wird darauf hingewiesen, dass die Funktionalität zum Erstellen der erwünschten Version an der Clientseite in Übereinstimmung mit diesem siebten Ausführungsbeispiel in dem Dateieditiersystem mit dem mit nur der Dateigeheimhaltungseigenschaft verwirklicht werden kann, wie beispielsweise in dem oben beschriebenen von Fig. 23.
Als nächstes wird das achte Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert. In diesem achten Ausführungsbeispiel ist das oben beschriebene gemeinsame Dateieditiersystem von Fig. 13, Fig. 16 und Fig. 20, was die asynchrone Editierfunktion aufweist, weiter mit einer zusätzlichen Funktionalität ausgestattet, zum Handhaben des Konflikts beim Editieren aufgrund eines asynchronen Auftretens von Schreibbetriebsvorgängen von einer Vielzahl von Clients mit Bezug auf eine bestimmte Datei.
Fig. 40 zeigt eine Konfiguration des gemeinsamen Dateieditiersystems dieses achten Ausführungsbeispiels, wie oben erläutert, basierend auf dem oben beschriebenen gemeinsamen Dateieditiersystem von Fig. 16.
Bei dieser Konfiguration von Fig. 40 ist jeder Zugriff anfordernde Client 211 und der Kommunikationspfad 111 im wesentlichen ähnlich zu denen in Fig. 16. Der Dateiverwaltungsserver 220 unterscheidet sich von dem in Fig. 16 darin, dass er weiter eine Editierkonflikterfassungseinheit 940 enthält.
In diesem achten Ausführungsbeispiel, genauso wie im Fall von Fig. 16, treten Datenschreibanfragen von einer Vielzahl von Clients 211 zu verschiedenen Zeitpunkten auf. Am Server 220 wird die Schreibanfrage von jedem Client 211 in die Positionsdaten mit Bezug auf die neueste Version zu diesem Zeitpunkt durch die Editierprozedurumwandlungseinheit 502 umgewandelt. Dann wird an der Editierkonflikterfassungseinheit 940 erfasst, ob die umgewandelten Editierdaten in Konflikt zu dem durch die anderen Clients 211 getätigten Editierergebnis stehen, oder nicht. Das erlangte Erfassungsergebnis wird dann zu einem jeden Client 211 zurückgeliefert.
Hier kann der Konflikt beim Editieren in Übereinstimmung mit beispielsweise den folgenden Kriterien beurteilt werden.
(a) Die Einfügungsposition der Einfügungsdaten wurde bereits gelöscht.
(b) Die Einfügungsposition der Einfügungsdaten weist die anderen Daten bereits eingefügt auf.
(c) Der Löschbereich weist andere bereits eingefügte Daten auf.
(d) Ein Teil des Löschbereichs wurde bereits gelöscht.
An der Datensatzverwaltungseinheit 510 wird das Erfassungsergebnis der Editierkonflikterfassungseinheit 940 nicht empfangen, und die vom Client 211 übertragenen Daten, und durch die Editierprozedurumwandlungseinheit 502 umgewandelt, werden als die neueste Version gespeichert.
Dabei kann die Datenaktualisierung durch den Server 220 möglich sein, oder unmöglich sein, in Abhängigkeit von dem durch die Datensatzverwaltungseinheit 510 verwendeten Verwaltungsverfahren, und davon, ob oder ob nicht die Blockdaten verschlüsselt sind. Falls die Blockdaten nicht verschlüsselt sind, ist die Datenaktualisierung durch den Server 220 möglich, und zwar für das Differenzstapelverfahren, das RCS-Verfahren, und das modifizierte SCCS-Verfahren. Falls die Blockdaten verschlüsselt sind, ist die Datenaktualisierung durch den Server 220 lediglich für das modifizierte SCCS-Verfahren möglich.
Als nächstes wird das neunte Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert. In diesem neunten Ausführungsbeispiel ist das gemeinsame Dateieditiersystem des achten Ausführungsbeispiels, oben beschrieben, weiter dadurch abgewandelt, dass die Editierkonflikterfassungseinheit 940 das Erfassungsergebnis der Datensatzverwaltungseinheit 510 zustellt, und die Datensatzverwaltungseinheit 510 beurteilt, ob oder ob nicht die Datenaktualisierung in Übereinstimmung mit dem zugestellten Erfassungsergebnis durchzuführen ist.
Fig. 41 zeigt eine Konfiguration des gemeinsamen Dateieditiersystems dieses neunten Ausführungsbeispiels, wie oben erläutert, basierend auf dem oben erläuterten gemeinsamen Dateieditiersystem von Fig. 40.
Bei dieser Konfiguration von Fig. 41 ist jeder Zugriff anfordernde Client 211 und der Kommunikationspfad 111 im wesentlichen ähnlich zu denen in Fig. 40. Der Dateiverwaltungsserver 225 unterscheidet sich von dem von Fig. 40 darin, dass die Ausgabe der Editierkonflikterfassungseinheit 940 weiter zu der Datensatzverwaltungseinheit 510 geliefert wird.
In diesem neunten Ausführungsbeispiel werden, wenn der Editierkonflikt mit den anderen Clients nicht auftritt, die vom Client 211 übermittelten und durch die Editierprozedurumwandlungseinheit 502 umgewandelten Daten als die neueste Version gespeichert, wohingegen dann, wenn der Editierkonflikt mit den anderen Clients auftritt, die Datenaktualisierung durch den Server 225 nicht durchgeführt wird. In diesem Fall ist die neueste Version, an der das Schreiben tatsächlich durchgeführt wurde, als frei vom Editierkonflikt mit den anderen Clients bekannt, so dass es ein Vorteil ist, dass ein Bedeutungswiderspruch unwahrscheinlich ist. Der Client 211 empfängt die Benachrichtigung von dem Erfassungsergebnis, erlangt durch die Editierkonflikterfassungseinheit 940, so dass, falls das Schreiben nicht durchgeführt wurde, der Client 211 die neueste Version vom Server auslesen und eine Differenzeditierung durchführen kann, die das Auftreten des Konflikts vermeidet.
Als nächstes wird das zehnte Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert. In diesem zehnten Ausführungsbeispiel ist das gemeinsame Dateieditiersystem so ausgebildet, dass es von dem bereits existierenden Anbindungsprogramm verwendet werden kann.
Fig. 42 zeigt eine Konfiguration des gemeinsamen Dateieditiersystems des zehnten Ausführungsbeispiels, wie oben erläutert, allgemein eine Vielzahl von Zugriff anfordernden Clients 950 und einen Datenverwaltungsserver 970 umfassend, die über einen Kommunikationspfad 111 verbunden sind. Der Dateiverwaltungsserver 970 enthält weiter eine Kommunikations-(COMM) Einheit 131, eine Zugriffsinformationsspeichereinheit 971, eine Datensatzverwaltungseinheit (für eine gemeinsam benutzte Datei) 972, und eine Datenspeichereinheit 973. Dieser Zugriff anfordernde Client 950 enthält weiter eine Zugriffsanforderungseinheit 951, eine Systemaufruftabelle 955, eine gemeinsame Dateizugriffsverarbeitungseinheit 960, und eine Kommunikations- (COMM) Einheit 130. Jeder Zugriff anfordernde Client 950 und der Dateiverwaltungsserver 970 können über den Kommunikationspfad 111 mittels der jeweiligen Kommunikations-(COMM) Einheiten 130 und 131 kommunizieren.
In diesem zehnten Ausführungsbeispiel wird angenommen, dass die Zugriffsanforderungseinheit 951 das bereits existierende Anwendungsprogramm ist, und die durch die Zugriffsanforderungseinheit 951 ausgegebene Zugriffsanfrage durch den Systemaufruf, geliefert durch das Betriebssystem, auszuführen ist.
In jenem zehnten Ausführungsbeispiel bezieht sich die Zugriffsanforderungseinheit 961 auf die Funktionen, die in der Systemaufruftabelle 955 aufgelisteten System aufrufen entsprechen, und führt eine von Öffnen/Schließen/Lesen/Schreiben-Funktionen aus. Die Daten in der Systemaufruftabelle 955, die sich auf die Funktionen der Systemaufrufe in dem Betriebssystem beziehen, werden umgeschrieben, von den Verbindungsdaten (Address Pointers) zu Öffnungsfunktion/Schließfunktion/Lesefunktion/- Schreibfunktion, bereitgestellt durch das Betriebssystem, in die Verbindungsdaten (Address Pointers) der gemeinsamen Öffnungsfunktion/gemeinsamen Schließfunktion/gemeinsamen Lesefunktion/gemeinsamen Schreibfunktion, die durch die gemeinsame Dateizugriffsverarbeitungseinheit 960 bereitgestellt werden. Diese gemeinsame Öffnungsfunktion/gemeinsame Schließfunktion/gemeinsame Lesefunktion/gemeinsame Schreibfunktion 961 werden dann über die Kommunikation- (COMM) Einheit 130 zu dem Dateiverwaltungsserver 970 übermittelt.
Wenn daher die Zugriffsanforderungseinheit 951, das bereits existierende Anwendungsprogramm umfassend, die Öffnungsfunktion/Schließfunktion/Lesefunktion/Schreibfunktion ausführt, werden tatsächlich die gemeinsame Öffnungsfunktion/gemeinsame Schließfunktion/gemeinsame Lesefunktion/gemeinsame Schreibfunktion 961 ausgeführt werden.
Dabei entsprechen die gemeinsame Öffnungsfunktion/gemeinsame Schließfunktion/gemeinsame Lesefunktion/gemeinsame Schreibfunktion 961 tatsächlich der Verarbeitung in Übereinstimmung mit der gemeinsamen Dateizugriffsanfrage zum Durchführen der "Öffnung", der Verarbeitung in Übereinstimmung mit der gemeinsamen Dateizugriffsanfrage zum Durchführen der "Schließung", der Verarbeitung in Übereinstimmung mit der gemeinsamen Dateizugriffsanfrage zum Durchführen des "Lesens", und bzw. der Verarbeitung in Übereinstimmung mit der gemeinsamen Dateizugriffsanfrage zum Durchführen des "Schreibens". Es wird darauf hingewiesen, dass in Fig. 42 die gemeinsame Öffnungsfunktion/gemeinsame Schließfunktion/gemeinsame Lesefunktion/gemeinsame Schreibfunktion 961 getrennt bereitgestellt werden, jedoch die alle in diesen Funktionen 961 gemeinsame Verarbeitung als ein. Prozess bereitgestellt werden kann, und durch diese vier Funktionen gemeinsam genutzt werden können.
Der Dateiverwaltungsserver 970 empfängt die gemeinsame Öffnungsfunktion/gemeinsame Schließfunktion/gemeinsame Lesefunktion/gemeinsame Schreibfunktion 961 von dem Zugriff anfordernden Client 950, und übergibt sie der Datensatzverwaltungseinheit 972. Dann kann die Datensatzverwaltungseinheit 72 das Lesen oder das Schreiben der gewünschten Daten von der Datenspeichereinheit 973 in Übereinstimmung mit der Information der Zugriffsinformationsspeichereinheit 971 durchführen. Dann wird die ausgeführte Zugriffsanfrage als Daten in der Zugriffsinformationsspeichereinheit 971 aufgezeichnet.
Fig. 43 zeigt ein Beispiel der Zugriffsdatensatzliste 980 in der Zugriffinformationsspeichereinheit 971. Diese Zugriffdatensatzliste 980 ist eine Liste zum Speichern der Zugriffsanfragen auf die Dateien in dem Dateiverwaltungsserver 970. Die Zugriffsdatensatzliste 980 weist sechs Felder auf, für eine Datei ID 981, einen Modus 982, einen Öffnungszeitpunkt 983, einen Schließzeitpunkt 984 eine Version 985 und eine Momentane 986.
Die Datei ID 981 ist ein Identifizierer, der jeder gemeinsame-Datei-Zugriffsanfrage für "Öffnen" eindeutig zugeordnet ist, ausgegeben von der Zugriffsanfrage 951 an die Datensatzverwaltungseinheit 972. Nach der "Öffnungs"-Anfrage werden die gemeinsamen Dateizugriffsanfragen von der Zugriffsanforderungseinheit 951 unter Verwendung dieser Datei IL 981 verwaltet. Diese Datei ID 981 wird an die Zugriffsanforderungseinheit 951 ausgegeben, wann immer die gemeinsame-Datei-Zugriffsanfrage für "Öffnen" durch die Datensatzverwaltungseinheit 972 empfangen wird.
Der Modus 982 bezeichnet einen Modus der Öffnungsanfrage für diese Datei, wobei "r" anzeigt, dass es ein Nur-Lesemodus, ist, und "w", anzeigt, dass es entweder ein Nur-Schreibmodus oder ein Lese- und Schreibmodus ist.
Der Öffnungszeitpunkt 983 bezeichnet eine Zeit, zu der die Öffnungsanfrage für diese Zeit ausgegeben wurde. In diesem Beispiel wird die als ID2 bezeichnete Datei als zu einem Zeitpunkt C1 geöffnet bezeichnet. Weiter bezeichnet der Schließzeitpunkt 984 einen Zeitpunkt, zu dem die Schließanfrage für diese Datei ausgegeben wurde. In diesem Beispiel wird die durch ID1 bezeichnete Datei als immer noch offen angezeigt, da die Schließzeit 984 nicht eingegeben wurde, wohingegen die durch ID2 bezeichnete Datei als zu einem Zeitpunkt t5 geschlossen angezeigt ist.
Dabei wird die Zeit dazu verwendet, das Zeitverhältnis zwischen den Auftrittszeiten von verschiedenen Ereignissen zu bezeichnen, und kann durch eine interne Uhr eine Computers vorgegeben werden, oder die für die Dateiverwaltung verwendete Versionsnummer kann als Zeitangabe verwendet werden. Weiter wird diese Zeitangabe nur durch die Datensatzverwaltungseinheit 972 verwendet, so dass es keine Notwendigkeit gibt, dass die anderen Elemente, wie beispielsweise der Zugriffanfragende Client 950 dazu in der Lage sein müssen, direkt auf diese Zeitvorgabe Bezug zu nehmen.
Die Version 985 bezeichnet die Version der Datei, von der die Öffnungsanfrage zu dieser Datei ausgegeben wurde. Normalerweise ist der Systemaufruf "Öffnen" einer Anfrage mit Bezug auf die neueste Version, so dass diese Version 985 normalerweise durch die neueste Version zu einem Zeitpunkt eines Ausgebens der Öffnungsanfrage gegeben ist.
Die Momentane 986 ist ein Wert (Such-Pointer), der die Position angibt, auf die momentan zugegriffen wird, für die momentan zugreifende Zugriffsanfrage. Dieser Such-Pointer bezeichnet die Ausleseposition (relative Position innerhalb der Datei) gegenüber der gemeinsame-Datei-Zugriffsanfrage für "Lesen", was als nächstes kommt. Im Falle des "Öffnens" im Nur-Lesemodus, wird als eine Voreinstellung, der Anfangswert auf 0 eingestellt.
Die Datensatzverwaltungseinheit 972 verwaltet die asynchronen Zugriffe von den Zugriff anfordernden Clients 950 und führt das Lesen und das Schreiben der gewünschten Daten mit Bezug auf die Datenspeichereinheit 9173 in Übereinstimmung mit den Inhalten der Zugriffsinformationsspeichereinheit 971 durch. Dabei ist der Betrieb der Datensatzverwaltungseinheit 9172 selbst ähnlich zu dem in dem vorhergehenden oben beschriebenen Ausführungsbeispielen, so dass die Erläuterung davon ausgelastet wird.
In Übereinstimmung mit diesem zehnten Ausführungsbeispiel, oben erläutert, kann das bereits bestehende Anwendungssoftwareprogramm als Zugriffs anfragender Client verwendet werden, um das asynchrone Editieren in diesem System auszuführen, ohne irgendeine Änderung im Programm selbst zu erfordern, in dem einfach die Werte der Adress- Pointer in der Systemaufruftabelle 955, bereitgestellt durch das Betriebssystem, umgeschrieben werden.
Als nächstes wird das elfte Ausführungsbeispiel eines gemeinsamen Dateieditiersystems gemäß der vorliegenden Erfindung detailliert erläutert. Diese elfte Ausführungsbeispiel ist eine Modifikation des zehnten Ausführungsbeispiels, oben erläutert, und zielt auf den gleichen Zweck wie das zehnte Ausführungsbeispiel.
Fig. 44 zeigt eine Konfiguration des gemeinsamen Dateieditiersystems dieses elften Ausführungsbeispiels, das sich von der Konfiguration von Fig. 42 darin unterscheidet, dass die Zugriffsinformationsspeichereinheit 971 in dem Dateiverwaltungsserver 970 in Fig. 42 bereitgestellt, nunmehr als die Zugriffsinformationsspeichereinheit 995 in dem Zugriff anfordernden Client 990 in Fig. 44 bereitgestellt ist. In diesem Fall ist der Dateiverwaltungsserver 90 einschließlich der Datensatzverwaltungseinheit 510, der Datenspeichereinheit 511 und der Kommunikations- (COMM) Einheit 131 im wesentlichen ähnlich zu den oben in Verbindung mit Fig. 13 beschriebenen.
In diesem elften Ausführungsbeispiel speichert der Zugriff anfordernde Client 990 die gemeinsame Dateizügriffsinformation von seiner eigenen Zugriffsanforderungseinheit 991 in der Zugriffsinformationsspeichereinheit 995. Der Inhalt der Zugriffsinformationsspeichereinheit 995 kann beispielsweise ähnlich zu dem oben in Verbindung mit Fig. 43 beschriebenen sein.
Die gemeinsame Dateizugriffsverarbeitungseinheit 993 liest die Information in der Zugriffsinformationsspeichereinheit 995 aus, und überträgt die Anfrage zum Dateiverwaltungsserver 90, indem die notwendige Information zu der gemeinsamen Öffnungsfunktion/gemeinsamen Schließfunktion/gemeinsamen Lesefunktion/gemeinsamen Schreibfunktion 994 als die Argumente der jeweiligen Funktionen hinzugefügt wird.
Wenn beispielsweise der Lesesystemaufruf für ein Lesen von 10 Bytes von der Datei mit der Datei ID mit ID1 von der Zugriffsanforderungseinheit 991 ausgegeben wird, liest die gemeinsame Dateizugriffsverarbeitungseinheit 993 die Versionsinformation 985 und die momentane Positionsinformation 986 betreffend die Datei ID mit ID1 aus der Zugriffsinformationsspeichereinheit 995 aus, und fügt diese Information zusammen mit der Datei ID von ID1 und der Anzahl von auszulesenden Bytes zum Argument der gemeinsamen Öffnungsfunktion hinzu, und überträgt dann dieses zum Dateiverwaltungsserver 90.
Die vom Zugriff anfordernden Client 990 zum Dateiverwaltungsserver 90 übertragene Anfrage enthält die momentane Zugriffsinformation des Zugriffs anfragenden Clients, zusätzlich zu der normalen Information, gegeben durch den Systemaufruf des Betriebssystems, so dass die Datensatzverwaltungseinheit 510 die erwünschten Daten von der Datenspeichereinheit 511 in Übereinstimmung mit dieser Information herausziehen kann.
Wie erläutert, kann auch in diesem elften Ausführungsbeispiel das bereits bestehende Anwendungssoftwareprogramm als der Zugriff anfordernde Client verwendet werden, um das asynchrone Editieren in diesem System durchzuführen, ohne irgendeine Änderung am Programm selbst zu erfordern, in dem ein einfach die Werte der Adress-Pointer in der Systemaufruftabelle 992, geliefert durch das Betriebssystem, umgeschrieben werden.
Es wird darauf hingewiesen, dass die Eigenschaft zum Ermöglichen der Verwendung des bereits bestehenden Anwendungsprogramms mit Bezug auf die gemeinsame genutzten Dateien in Übereinstimmung mit dem zehnten und elften Ausführungsbeispiel als eine Eigenschaft verwendet werden kann, um die Verwendung des bereits bestehenden Anwendungsprogramms mit Bezug auf die verschlüsselten Dateien zu ermöglichen, indem die Zugriffsfunktionen für die gemeinsam genutzten Dateien in der obigen Beschreibung durch die Zugriffsfunktionen für die verschlüsselten Dateien ersetzt werden, in dem Dateieditiersystem mit nur der Dateiinhaltsgeheimhaltungseigenschaft, wie beispielsweise in Fig. 23 oben beschrieben.
Es ist auch darauf hinzuweisen, dass in den verschiedenen oben beschriebenen Ausführungsbeispielen die Kommunikation durch einen Kommunikationspfad zwischen Kommunikationseinheiten, bereitgestellt an dem Client und an dem Server, in der Form einer Netzwerkkommunikation zwischen der Client Computervorrichtung und der Server Computervorrichtung realisiert werden kann, oder in einer Form einer Datenübertragung zwischen dem Client Programm und dem Server Programm innerhalb einer einzelnen Computervorrichtung.
Es ist weiterhin darauf hinzuweisen, neben dem bereits oben Erwähnten, dass viele Modifikationen und Veränderungen der obigen Ausführungsbeispiele getätigt werden können, ohne von den neuen und vorteilhaften Eigenschaften der vorliegenden Erfindung abzuweichen. Demzufolge sollen alle solchem Modifikationen und Veränderungen im Umfang der hinzugefügten Ansprüche enthalten sein.

Claims

1. Ein Dateieditiersystem, umfassend:

eine Dateiverwaltungs-Servervorrichtung (210) zum Verwalten von Dateien, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält; und

mindestens eine Client-Vorrichtung (221(A), (221(B), (221(C)), die auf die Dateiverwaltungs-Servervorrichtung zugreift, um die Blockdaten entsprechend einer erwünschten Version einer durch die Dateiverwaltungs- Servervorrichtung verwalteten erwünschten Datei zu erlangen, wobei die Client-Vorrichtung umfasst:

eine Entschlüsselungseinrichtung (230) zum Entschlüsseln der von der Dateiverwaltungs-Servervorrichtung erhaltenen Blockdaten unter Verwendung eines vorgegebenen Dechiffrierschlüssels;

eine Editiereinrichtung (500) zum Editieren der erwünschten Version der erwünschten Datei, gebildet durch die durch die Entschlüsselungseinrichtung entschlüsselten Blockdaten;

eine Editierprozedur-Erzeugungseinrichtung (501) zum Erzeugen von Editierprozedurdaten, die eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch die Editiereinrichtung getätigte Editierung zu erlangen, und einschließlich in die erwünschte Datei einzufügenden Einfügungsdaten;

eine Verschlüsselungseinrichtung (212) zum Verschlüsseln der Einfügungsdaten, die in den durch die Editierprozedur-Erzeugungseinrichtung erzeugten Editierprozedurdaten enthalten sind, unter Verwendung eines vorgegebenen Chiffrierschlüssels, um verschlüsselte Editierprozedurdaten zu erlangen; und

eine Kommunikationseinrichtung (230) zum Übertragen der durch die Verschlüsselungseinrichtung erlangten verschlüsselten Editierprozedurdaten zu der Dateiverwaltungs-Servervorrichtung;

wobei die Dateiverwaltungs-Servervorrichtung enthält:

eine Editierprozedur-Umwandlungseinrichtung (502) zum Umwandeln der von der von der Clientvorrichtung erhalten verschlüsselten Editierprozedurdaten für die erwünschte Version der erwünschten Datei in verschlüsselte Editierprozedurdaten für eine letzte Version der erwünschten Datei;

eine Datensatzverwaltungsinformations- Erzeugungseinrichtung (503) zum Erzeugen von Datensatzverwaltungsinformation, die ein Ergebnis der durch die Editiereinrichtung getätigten Editierung anzeigen, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die letzte Version der erwünschten Datei, erlangt durch die Editierprozedur- Umwandlungseinrichtung; und

eine Datensatz-Verwaltungseinrichtung (510) zum Durchführen einer Datensatzverwaltung der erwünschten Datei in Übereinstimmung mit der durch die Datensatzmanagementinformations-Erzeugungseinrichtung erlangten Datensatzverwaltungsinformation und der Blockidentifikationsinformation für jede Blockdaten.

2. Das System nach Anspruch 1, wobei die Editierprozedur- Umwandlungseinrichtung (502) die verschlüsselten Editierprozedurdaten für die letzte Version der erwünschten Datei erlangt, in Übereinstimmung mit einem Verhältnis zwischen der erwünschten Version und der letzten Version, angezeigt durch Datensatzdaten, gemäß denen die Datensatzverwaltungseinrichtung die Datensatzverwaltung der erwünschten Datei durchführt.

3. Das System nach Anspruch 1, wobei die Dateiverwaltungs- Servervorrichtung (210) jede Datei verwaltet, in einer Form von ersten Blockdaten, in denen ein ursprünglich erzeugter Dateiinhalt verschlüsselt ist, nachfolgenden Blockdaten, in denen ein Unterschied zwischen einem Dateiinhalt vor jeder Editierung und einem Dateiinhalt nach jeder Editierung verschlüsselt ist, und der Blockidentifikationsinformation, die jeden Blockdaten beigefügt sind, die jede Blockdaten identifizieren.

4. Das System nach Anspruch 1, wobei die Dateiverwaltungs- Servervorrichtung (210) jede Datei verwaltet, in einer Form von letzten Blockdaten, in denen ein zuletzt editierter Dateiinhalt verschlüsselt ist, vorhergehenden Blockdaten, in denen ein Unterschied zwischen einem Dateiinhalt vor jeder Editierung und einem Dateiinhalt nach jeder Editierung verschlüsselt ist, und der Blockidentifikationsinformation, die jeden Blockdaten beigefügt ist, die jede Blockdaten identifizieren.

5. Das System nach Anspruch 1, wobei die Dateiverwaltungs- Servervorrichtung (210) jede Datei verwaltet, in einer Form von Einfügungsblockdaten, in denen ein in jede Datei eingefügter Inhalt verschlüsselt ist, Löschblockdaten, in denen jeder von jeder Datei gelöschter Inhalt verschlüsselt ist, und der Blockidentifikationsinformation, die jeden Blockdaten beigefügt ist, und die einen Erzeugungszeitpunkt und einen Löschzeitpunkt von jeden Blockdaten anzeigt.

6. Das System nach Anspruch 1, wobei die Dateiverwaltungs- Servervorrichtung (210) jede Blockdaten verwaltet, in einem in Einheiten von Blöcken mit einem 8 Bit CFB Modetyp Chiffrierverfahren verschlüsselten Zustand, und wobei die Verschlüsselungseinrichtung die Einfügungsdaten mit dem 8 Bit CFB Modetyp Chiffrierverfahren verschlüsselt.

7. Das System nach Anspruch 1, wobei die Dateiverwaltungs- Servervorrichtung 210 jede Blockdaten verwaltet, in einem Zustand mit zumindest einem Einfügungsdatenabschnitt von jeden Blockdaten, verschlüsselt mit einem Strom-Chiffrierverfahren, und wobei die Verschlüsselungseinrichtung die Einfügungsdaten mit dem Strom-Chiffrierverfahren verschlüsselt.

8. Das System nach Anspruch 1, wobei die Datensatzverwaltungsinformations-Erzeugungseinrichtung (503) und/oder die Datensatzverwaltungseinrichtung (510) die Blockidentifikationsinformation für die Blockdaten, die sich aus der durch die Editiereinrichtung getätigten Editierung ergeben, an die Datensatz- Verwaltungsinformation anfügt.

9. Ein Verfahren zum Editieren in einem Dateieditiersystem, gebildet durch eine Dateiverwaltungs-Servervorrichtung und mindestens eine Client-Vorrichtung, mit den Schritten:

Verwalten von Dateien an der Dateiverwaltungs- Servervorrichtung, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält;

Tätigen eines Zugriffs auf die Dateiverwaltungs- Servervorrichtung, um die Blockdaten entsprechend einer erwünschten Version einer durch die Dateiverwaltungs- Servervorrichtung verwalteten erwünschten Datei zu erlangen, an der Client-Vorrichtung;

Entschlüsseln der von der Dateiverwaltungs- Servervorrichtung erlangten Blockdaten unter Verwendung eines vorgegebenen Dechiffrierschlüssels, an der Client- Vorrichtung;

Editieren der erwünschten Version der durch die durch den Entschlüsslungsschritt entschlüsselten Blockdaten gebildeten erwünschten Datei, an der Client-Vorrichtung;

Erzeugen von Editierprozedurdaten, die eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch den Editierschritt getätigten Editierung zu erlangen, und einschließlich in die erwünschte Datei einzufügen Einfügungsdaten, an der Client-Vorrichtung;

Verschlüsseln der Einfügungsdaten, enthalten in den durch den Editierprozedurdaten-Erzeugungsschritt erzeugten Editierprozedurdaten, durch Verwendung eines vorgegebenen Chiffrierschlüssels, um verschlüsselte Editierprozedurdaten an der Client-Vorrichtung zu erlangen;

Übertragen der durch den Verschlüsselungsschritt erlangten verschlüsselten Editierprozedurdaten von der Client-Vorrichtung zu der Dateiverwaltungs- Servervorrichtung;

Umwandeln der verschlüsselten Editierprozedurdaten für die erwünschte Version der erwünschten Datei, empfangen von der Client-Vorrichtung, in verschlüsselte Editierprozedurdaten für eine letzte Version der erwünschten Datei, an der Dateiverwaltungs- Servervorrichtung;

Erzeugen von Datensatzverwaltungsinformation, die ein Ergebnis der durch den Editierschritt getätigten Editierung anzeigt, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die letzte Version der erwünschten Datei, erlangt durch den Umwandlungsschritt, an der Dateiverwaltungs- Servervorrichtung; und

Durchführen einer Datensatzverwaltung der erwünschten Datei an der Dateiverwaltungsservervorrichtung, in Übereinstimmung mit der durch den Datensatzverwaltungsinformations-Erzeugungsschritt erlangten Datensatzverwaltungsinformation, und der Blockidentifikationsinformation für jede Blockdaten.

10. Eine Client-Vorrichtung (221(A), 221(B), 221 (C)) zum Tätigen eines Zugriffs auf eine Servervorrichtung (210), die Datei verwaltet, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, um so die Blockdaten zu erlangen, die einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei entsprechen, wobei die Client-Vorrichtung umfasst:

eine Entschlüsselungseinheit (230) zum Entschlüsseln der von der Servervorrichtung erhaltenen Blockdaten, unter Verwendung eines vorgegebenen Dechiffrierschlüssels;

eine Editiereinheit (500) zum Editieren der erwünschten Version der erwünschten Datei, gebildet durch die durch die Entschlüsselungseinheit entschlüsselten Blockdaten;

eine Editierprozedur-Erzeugungseiheit (501) zum Erzeugen von Editierprozedurdaten, die eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch die Editiereinheit getätigten Editierung zu erlangen, und einschließlich in die erwünschte Datei einzufügenden Einfügungsdaten;

eine Chiffriereinheit (212) zum Verschlüsseln der Einfügungsdaten, enthalten in den Editierprozedurdaten, erzeugt durch die Editierprozedur-Erzeugungseinheit, durch Verwendung eines vorgegebenen Chiffrierschlüssels, um verschlüsselte Editierprozedurdaten zu erlangen; und

eine Kommunikationseinheit (230) zum Übertragen der durch die Chiffriereinheit erlangten verschlüsselten Editierprozedurdaten zu der Servervorrichtung.

11. Ein Verfahren zum Tätigen eines Zugriffs auf eine Servervorrichtung, der Dateien verwaltet, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, wobei das Verfahren die Schritte umfasst:

Erlangen der Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei;

Entschlüsseln der von der Servervorrichtung erlangten Blockdaten unter Verwendung eines vorgegebenen Dechiffrierschlüssels;

Editieren der erwünschten Version der erwünschten Datei, gebildet durch die durch den Entschlüsselungsschritt entschlüsselten Blockdaten;

Erzeugen von Editierprozedurdaten, die eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch den Editierschritt getätigten Editierung zu erlangen, und einschließlich in die erwünschte Datei einzufügenden Einfügungsdaten;

Verschlüsseln der in den durch den Erzeugungsschritt erzeugten Editierprozedurdaten enthaltenen Einfügungsdaten durch Verwendung eines vorgegebenen Chiffrierschlüssels, um verschlüsselte Editierprozedurdaten zu erlangen; und

Übertragen der durch den Verschlüsselungsschritt erlangten verschlüsselten Editierprozedurdaten zu der Servervorrichtung.

12. Ein Herstellungsartikel, umfassend:

ein computernutzbares Medium mit einer darin verkörperten computerlesbaren Programmcodeeinrichtung, um zu bewirken, dass ein Computer als eine Client- Vorrichtung arbeitet, zum Tätigen eines Zugriffs auf eine Servervorrichtung, die Dateien verwaltet, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, um so die Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei zu erhalten, wobei die computerlesbare Programmcodeeinrichtung umfasst:

eine erste computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer die von der Servervorrichtung erhaltenen Blockdaten entschlüsselt, unter Verwendung eines vorgegebenen Dechiffrierschlüssels;

eine zweite computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer die erwünschte Version der erwünschten Datei, gebildet durch die durch die erste computerlesbare Programmcodeeinrichtung entschlüsselten Blockdaten, editiert;

eine dritte computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer Editierprozedurdaten erzeugt, die eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch die zweite computerlesbare Programmcodeeinrichtung getätigte Editierung zu erlangen, und einschließlich in die erwünschte Datei einzufügenden Einfügungsdaten;

eine vierte computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer die in die durch die dritte computerlesbare Programmcodeeinrichtung erzeugten Editierprozedurdaten eingefügten Einfügungsdaten verschlüsselt, unter Verwendung eines vorgegebenen Chiffrierschlüssels, um verschlüsselte Editierprozedurdaten zu erhalten; und

eine fünfte computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer die verschlüsselten Editierprozedurdaten, erhalten durch die vierte computerlesbare Programmcodeeinrichtung, zur Servervorrichtung übermittelt.

13. Eine Servervorrichtung (210) zum Verwalten von Dateien, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, wobei eine Client-Vorrichtung (221(A), 221(B), 221(C) einen Zugriff auf die Servervorrichtung tätigt, um die Blockdaten zu erlangen, die einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei entsprechen, wobei die Servervorrichtung umfasst:

eine Editierprozedur-Umwandlungseinheit (502), um verschlüsselte Editierprozedurdaten für die erwünschte Version der erwünschten Datei, von der Client- Vorrichtung empfangen, in verschlüsselte Editierprozedurdaten für eine letzte Version der erwünschten Datei umzuwandeln, wobei die verschlüsselten Editierprozedurdaten eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch die Client-Vorrichtung getätigte Editierung zu erlangen, und einschließlich in die erwünschte Datei einzufügenden Einfügungsdaten, wobei die Einfügungsdaten unter Verwendung eines vorgegebenen Chiffrierschlüssels verschlüsselt sind;

eine Datensatzverwaltungsinformations-Erzeugungseinheit (503), um Datensatzverwaltungsinformation zu erzeugen, die ein Ergebnis der durch die Client-Vorrichtung getätigten Editierung anzeigt, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die letzte Version der erwünschten Datei, erhalten durch die Editierprozedur-Umwandlungseinheit; und

eine Datensatzverwaltungseinheit (510), um eine Datensatzverwaltung der erwünschten Datei in Übereinstimmung mit der durch die Datensatzverwaltungsinformations-Erzeugungseinheit erhaltenen Datensatzverwaltungsinformation und der Blockidentifikationsinformation für jede Blockdaten durchzuführen.

14. Ein Verfahren zum Verwalten von Dateien an einer Servervorrichtung, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, wobei eine Client-Vorrichtung einen Zugriff auf die Servervorrichtung tätigt, um die Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei zu erlangen, wobei das Verfahren die Schritte umfasst:

Umwandeln verschlüsselter Editierprozedurdaten für die erwünschte Version der erwünschten Datei, von der Client-Vorrichtung empfangen, in verschlüsselte Editierprozedurdaten für eine letzte Version der erwünschten Datei, wobei die verschlüsselten Editierprozedurdaten eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch die Client-Vorrichtung getätigte Editierung zu erlangen, und einschließlich in die erwünschte Datei einzufügende Einfügungsdaten, wobei die Einfügungsdaten unter Verwendung eines vorgegebenen Chiffrierschlüssels verschlüsselt sind;

Erzeugen von Datensatzverwaltungsinformation, die ein Ergebnis der durch die Client-Vorrichtung getätigten Editierung anzeigt, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die letzte Version der erwünschten Datei, erhalten durch den Umwandlungsschritt; und

Durchführen einer Datensatzverwaltung der erwünschten Datei, in Übereinstimmung mit der durch den Erzeugungsschritt erlangten Datensatzverwaltungsinformation und der Blockidentifikationsinformation für jede Blockdaten.

15. Ein Herstellungsartikel, umfassend:

ein computernutzbares Medium mit einer darin verkörperten computerlesbaren Programmcodeeinrichtung, um zu bewirken, dass ein Computer als eine Servervorrichtung zur Verwaltung von Dateien arbeitet, wobei jede Datei eine Vielzahl von Blockdaten und Blockidentifikationsinformation für jede Blockdaten enthält, und wobei eine Client-Vorrichtung einen Zugriff auf die Servervorrichtung tätigt, um die Blockdaten entsprechend einer erwünschten Version einer durch die Servervorrichtung verwalteten erwünschten Datei zu erlangen, wobei die computerlesbare Programmcodeeinrichtung enthält:

eine erste computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer verschlüsselte Editierprozedurdaten für die erwünschte Version der erwünschten Datei, empfangen von der Client-Vorrichtung, in verschlüsselte Editierprozedurdaten für eine letzte Version der erwünschten Datei umwandelt, wobei die verschlüsselten Editierprozedurdaten eine Prozedur bezeichnen, um eine in der erwünschten Version der erwünschten Datei durch die Client-Vorrichtung getätigte Editierung zu erlangen, einschließlich in die erwünschte Datei einzufügenden Einfügungsdaten, wobei die Einfügungsdaten unter Verwendung eines vorgegebenen Chiffrierschlüssels verschlüsselt sind;

eine zweite computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer Datensatzverwaltungsinformation erzeugt, die ein Ergebnis der durch die Client-Vorrichtung getätigten Editierung anzeigt, in Übereinstimmung mit den verschlüsselten Editierprozedurdaten für die letzte Version der erwünschten Datei, erhalten durch die erste computerlesbare Programmcodeeinrichtung; und

eine dritte computerlesbare Programmcodeeinrichtung, um zu bewirken, dass der Computer eine Datensatzverwaltung der erwünschten Datei in Übereinstimmung mit der durch die zweite computerlesbare Programmcodeeinrichtung erhaltenen Datensatzverwaltungsinformation und der Blockidentifikationsinformation für jede Blockdaten durchführt.