JP3707821B2 - ファイル編集システム及び共有ファイル編集システム - Google Patents

Description

【０００１】
【産業上の利用分野】
本発明はファイル編集システムに係わり、特に、計算機の共有ファイル・システムやデータベース・システムにおいて、複数ユーザからの共有ファイルの非同期編集や、ファイルの内容の読み出し保護を実現したものに関する。
【０００２】
【従来の技術】
計算機システムにおいて、システム内の資源に対する複数ユーザからのアクセスを管理するためには、アクセス要求を出したユーザが当該資源に対するアクセス権を有する正規のユーザであるか否かを確認するための認証機構が必要であることが指摘されてきた。特に、システムが巨大化し遠隔ユーザからのアクセスを認める環境では、認証機構の重要性が増してくる。このような機構を実現する代表的な認証システムとしては、Ｋｅｒｂｅｒｏｓなどがある。
【０００３】
こうした認証機構の必要となる典型的なシステムとしては、ＣＳＣＷ（Ｃｏｍｕｐｕｔｅｒ Ｓｕｐｐｏｒｔｅｄ Ｃｏｏｐｅｒａｔｉｖｅ Ｗｏｒｋ）システムが挙げられる。ＣＳＣＷは複数ユーザの協調作業を支援する計算機システムの総称であり、その典型的・根本的なものに共有ファイル・システムがある。共有ファイル・システムでは、複数ユーザが同一のファイルに対して“ｒｅａｄ”“ｗｒｉｔｅ”などのアクセス権を有し、同時に同一のファイルに対してそれらアクセスを許しながら、矛盾を生じることなく編集作業を実行できる。
【０００４】
従来、このような共有ファイル・システムを実現する一般的な形態は、ファイルにアクセスする主体としてのクライアントと、ファイルを管理するサーバとに分離したクライアント・サーバ型を採り、クライアントからのアクセスの認証を行う認証システムを実装するものである。すなわち、サーバはクライアントが正規のアクセス権を保持しているか否かを認証し、さらに必要であればクライアントとサーバ間で送受されるデータを暗号化したり、クライアント側が接続相手が所望のサーバであるか否かの認証などを実現するものである。
【０００５】
こうした共有ファイル・システムが広域化していくにつれ、例えば、あるサイトにファイル・サーバだけを実現するといったサービス形態が要求されるものと考えられる。すなわち、ファイルの保管とアクセス管理は提供するが、ファイルの内容自体はサーバ内では一切読み取れないような形態である。しかしながら、このようなサービスは、従来のセキュリティ・システムでは実現できない。なぜなら、通信データは保護しているが、ファイルの内容はサーバ内では平文の形式で管理されているからである。
【０００６】
また、共有ファイルにおいて同時編集を実現する従来のメカニズムでは、同一のファイルに対してあるユーザが書き込みを伴う編集を行っている間は、他のユーザは高々“ｒｅａｄ”しかできないように制限される。これは厳密な意味での同時編集ではなく、ロック機構を利用して複数ユーザのアクセス間で矛盾の生じないように同期を取る“同期編集”を実現しているのみであった。すなわち、最初のアクセス要求者がファイルにアクセスする間、ロック機構が作動して他の要求者からの“ｗｒｉｔｅ”のためのファイル・アクセス要求は許可されなくなり、他の要求者はファイル・アクセスを一時見合わせてロックの解除を待ち、ロックが解除された後に再度ファイルにアクセスするようにしていた。
【０００７】
これに対し、あるユーザが書き込みを伴う編集を行っている場合であっても他のユーザが同一ファイルに対して書き込みを伴う編集が可能であるようにできれば、より柔軟なシステムとなる。以下、このような操作を、複数ユーザがランダムに発生するアクセス間の同期をとる必要がないという意味で、“非同期編集”と呼ぶ。
【０００８】
一方、共有ファイル・システムに関連したもう一つの技術として、バージョン管理技術がある。従来のバージョン管理法には、ＳＣＣＣ（Ｓｏｕｒｃｅ Ｃｏｄｅ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）やＲＣＳ（Ｒｅｖｉｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）がある。これらの管理法は、プログラム開発を複数の人員で行うような場合に、ある時点におけるファイル全体を全て保存しておく変わりに差分だけを保管していくことにより、ファイル・サイズの圧縮を図るものである。しかしながら、ファイル・サイス面では大きな改善が達成できているものの、共有ファイル・システムでの実現ではロック機構を用いた同期編集しか考慮されていなかった。
【０００９】
【発明が解決しようとする課題】
以上説明したように、従来の共有ファイルの編集を行うためにクライアント・サーバ型の共有ファイル編集システムでは、ファイルの内容をファイル・サーバに対して秘密にできないこと、同時編集はロックを掛けることにより実現されるため同時に複数のアクセス要求者による書き込みを伴う編集すなわち非同期編集ができないことなどの問題点があった。
【００１０】
本発明は、上記問題点を考慮してなされたものであり、ファイルの内容をファイル・サーバからは読み取ることのできない秘匿性の高いファイル編集システムを提供することを目的とする。
【００１１】
また、本発明は、ファイルのバージョン管理をサポートする共有ファイル編集システムであって、非同期編集処理を行うことが可能な共有ファイル編集システムを提供することを目的とする。
【００１２】
また、本発明は、ファイルのバージョン管理をサポートする共有ファイル編集システムであって、ファイルの内容をファイル・サーバに対して秘密にしながら、非同期編集処理を行うことが可能となる共有ファイル編集システムを提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明（請求項１）では、各ファイルが、履歴管理に必要なバージョン間の差分に対応する複数のブロックデータと各ブロックのブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置とから構成され、前記クライアント装置は、前記ファイル管理サーバ装置が管理する所望のファイルに属するブロックデータをブロック単位で取得し、所定の復号鍵を用いてブロック単位で復号化する復号化手段と、前記復号化手段で復号化されたブロックデータから構成される前記所望のファイルを編集して、該所望のファイルになされた編集内容を示す編集データを得る編集手段と、前記編集手段で得られた編集データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集データを得る暗号化手段と、前記暗号化手段で得られた暗号化編集データを前記ファイル管理サーバ装置に送る通信手段とを備え、前記ファイル管理サーバ装置は前記クライアント装置から受取った暗号化編集データと前記各ブロックデータのブロック識別情報とに基づいて前記差分に対応するブロック単位で前記所望のファイルを管理することを特徴とする。
また、本発明（請求項２）では、履歴管理に必要な複数のブロックデータと、対応するブロックデータの生成時と消去時のバージョン情報を有するブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置とから構成され、前記クライアント装置は、前記ファイル管理サーバ装置が管理する所望のファイルに属するブロックデータをブロック単位で取得し、所定の復号鍵を用いてブロック単位で復号化する復号化手段と、前記復号化手段で復号化されたブロックデータから構成される前記所望のファイルを編集して、該所望のファイルになされた編集内容を示す編集データを得る編集手段と、前記編集手段で得られた編集データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集データを得る暗号化手段と、前記暗号化手段で得られた暗号化編集データを前記ファイル管理サーバ装置に送る通信手段とを備え、前記ファイル管理サーバ装置は前記クライアント装置から受取った暗号化編集データと前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理することを特徴とする。
【００１４】
また、本発明（請求項３）では、各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置とから構成され、前記クライアント装置は、前記ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータをブロック単位で取得し、所定の復号鍵を用いてブロック単位で復号化する復号化手段と、前記復号化手段で復号化されたブロックデータから構成される前記所望のファイルの所望のバージョンを編集する編集手段と、前記編集手段で前記所望のファイルの所望のバージョンに対してなされた編集内容を得る手続を示す編集手続データを生成する編集手続生成手段と、前記編集手続生成手段で生成された前記所望のファイルの所望のバージョンに対する編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する編集手続データに変換する編集手続変換手段と、前記編集手段でなされた編集の結果を示す履歴管理情報を、前記編集手続変換手段で得られた前記所望のファイルの最新バージョンに対する編集手続データに基づいて生成する履歴管理情報生成手段と、前記履歴管理情報生成手段で生成された履歴管理情報を、所定の暗号鍵を用いてブロック単位で暗号化して、暗号化履歴管理情報を得る暗号化手段と、前記暗号化手段で得られた暗号化履歴管理情報を前記ファイル管理サーバ装置に送る通信手段とを備え、前記ファイル管理サーバ装置は前記クライアント装置から受取った暗号化履歴管理情報と前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理する履歴管理手段を含むことを特徴とする。
【００１５】
また、本発明（請求項４）では、各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含むファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置とから構成され、前記クライアント装置は、前記ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータをブロック単位で取得し、所定の復号鍵を用いて復号化する復号化手段と、前記復号化手段で復号化されたブロックデータから構成される前記所望のファイルの所望のバージョンを編集する編集手段と、前記編集手段で前記所望のファイルの所望のバージョンに対してなされた編集内容を得る手続を示し、該所望のファイルに挿入される挿入データを含んだ編集手続データを生成する編集手続生成手段と、前記編集手続生成手段で生成された編集手続データに含まれる挿入データを所定の暗号鍵を用いて暗号化して、暗号化編集手続データを得る暗号化手段と、前記暗号化手段で得られた暗号化編集手続データを前記ファイル管理サーバ装置に送る通信手段とを備え、前記ファイル管理サーバ装置は、前記クライアント装置から受取った前記所望のファイルの所望のバージョンに対する暗号化編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する暗号化編集手続データに変換する編集手続変換手段と、前記編集手段でなされた編集の結果を示す履歴管理情報を、前記編集手続変換手段で得られた前記所望のファイルの最新バージョンに対する暗号化編集手続データに基づいて生成する履歴管理情報生成手段と、前記履歴管理情報生成手段で生成された履歴管理情報と前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理する履歴管理手段とを含むことを特徴とする。
【００１６】
また、本発明（請求項５）では、各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含むファイルを管理するファイル管理サーバ装置と、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータを取得し、該ファイル管理サーバ装置から得たブロックデータで構成される前記所望のファイルを編集する、複数のクライアント装置と、前記複数のクライアント装置による非同期編集をサポートする非同期編集サポート手段とから構成され、前記非同期編集サポート手段は、各クライアント装置により前記所望のファイルに対してなされた編集内容を得る手続を示す編集手続データを生成する編集手続生成手段と、前記編集手続生成手段で生成された前記所望のファイルの所望のバージョンに対する編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する編集手続データに変換する編集手続変換手段と、各クライアント装置により前記所望のファイルになされた編集の結果を示す履歴管理情報を、前記編集手続変換手段で得られた前記所望のファイルの最新バージョンに対する編集手続データに基づいて生成する履歴管理情報生成手段とを含み、前記ファイル管理サーバ装置は前記履歴管理情報と前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理することを特徴とする。
【００１７】
また、本発明（請求項６）では、上記（請求項１又は２）において、前記クライアント装置は前記所望のファイルの所望のバージョンに対応するブロックデータを前記ファイル管理サーバ装置から取得し、該ファイル管理サーバ装置は該クライアント装置から受取った前記所望のファイルの所望のバージョンに対する暗号化編集データに基づいて前記所望のファイルの履歴管理を行なう履歴管理手段を含むものであることを特徴とする。
【００１８】
また、本発明（請求項７）では上記（請求項１又は２）において、前記クライアント装置は前記所望のファイルの所望のバージョンに対応するブロックデータを前記ファイル管理サーバ装置から取得し、該ファイル管理サーバ装置は該クライアント装置から受取った前記所望のファイルの最新のバージョンに対する暗号化編集データに基づいて前記所望のファイルの履歴管理を行なう履歴管理手段を含むものであることを特徴とする。
【００１９】
また、本発明（請求項８）では、上記（請求項１又は２）において、前記ファイル管理サーバ装置は、二つ以上のクライアント装置からの同一ファイルに対するアクセス要求を非同期に受け付けて、該二つ以上のクライアント装置が該同一ファイルに対する非同期編集を行なうようにするものであることを特徴とする。
【００２０】
また、本発明（請求項９）では、上記（請求項１から４のいずれか）において、前記ファイル管理サーバ装置は、各ブロックデータをストリーム暗号方式で暗号化された状態で管理し、前記暗号化手段は前記編集データ又は前記履歴管理情報又は前記挿入データをストリーム暗号方式で暗号化することを特徴とする。
【００２１】
また、本発明（請求項１０）では、上記（請求項１、２又は５）において、前記クライアント装置は、前記ファイル管理サーバ装置から取得した複数のブロックデータを新たなブロックデータに再構成するブロックデータ再構成手段と、該ブロックデータ再構成手段で得られた新しいブロックデータを該ファイル管理サーバ装置に送る手段とを含み、該ファイル管理サーバ装置は該クライアント装置から受取った新たなブロックデータに基づいて前記所望のファイルを管理することを特徴とする。
【００２２】
また、本発明（請求項１１）では、上記（請求項１、２又は５）において、前記クライアント装置は、前記所望のファイルの以前アクセスされたバージョンを格納するファイル記憶手段と、前記ファイル記憶手段に格納されている以前アクセスされたバージョンと前記ファイル管理サーバ装置から取得した前記所望のファイルに属するブロックデータとに基づいて、前記所望のファイルの所望のバージョンを構築するファイルデータ構築手段と、を含み、前記ファイル管理サーバ装置は、前記クライアント装置に与えるブロックデータを、前記以前アクセスされたバージョンと前記所望のバージョンとの差分を求めることで構築する差分構築手段を含むことを特徴とする。
【００２３】
また、本発明（請求項１２）では、上記（請求項１、２又は５）において、前記クライアント装置は、前記ファイル管理サーバ装置が管理する暗号化されたファイル又は共有ファイルに対するアクセス要求をオペレーティングシステムが提供するシステムコールにより発行するアクセス要求手段と、前記システムコールに対応するアドレスポインタを登録するシステムコールテーブル手段と、前記クライアント装置から前記ファイル管理サーバ装置に送るファイルアクセス要求を、前記アクセス要求手段が発行したアクセス要求で指定されるシステムコールに対応する前記アドレスポインタに基づいて求めるファイルアクセス処理手段と、を含むものであることを特徴とする。
【００２４】
また、本発明（請求項１３）では、上記（請求項３又は４）において、前記履歴管理手段はそれにより前記所望のファイルの履歴管理を行なうものである履歴データを前記編集手続変換手段に送り、該編集手続変換手段は前記所望のファイルの最新のバージョンに対する編集手続データを前記履歴データによって示される前記所望のバージョンと前記最新バージョンとの関係に基づいて求めるものであることを特徴とする。
【００２５】
また、本発明（請求項１４）では、上記（請求項３又は４）において、前記ファイル管理サーバ装置は各ファイルを、最初に生成されたファイル内容が暗号化された最初のブロックデータと、各編集の前のファイル内容と各編集の後のファイル内容の各差分が暗号化された以降のブロックデータと、各ブロックデータに付与されて各ブロックデータを同定する前記ブロックデータ識別情報とからなる形式で管理することを特徴とする。
【００２６】
また、本発明（請求項１５）では、上記（請求項３又は４）において、前記ファイル管理サーバ装置は各ファイルを、最新の編集されたファイル内容が暗号化された最新のブロックデータと、各編集の前のファイル内容と各編集の後のファイル内容の各差分が暗号化された以前のブロックデータと、各ブロックデータに付与されて各ブロックデータを同定する前記ブロックデータ識別情報とからなる形式で管理することを特徴とする。
【００２７】
また、本発明（請求項１６）では、上記（請求項３又は４）において、前記ファイル管理サーバ装置は各ファイルを、各ファイルに挿入された各内容が暗号化された挿入ブロックデータと、各ファイルから削除された各内容が暗号化された削除ブロックデータと、各ブロックデータに付与されて各ブロックデータの生成時点と消去時点を同定する前記ブロックデータ識別情報とからなる形式で管理することを特徴とする。
【００２８】
また、本発明（請求項１７）では、上記（請求項１６）において、前記ファイル管理サーバ装置は、各ブロックデータを８ビットＣＦＢモード型暗号方式で暗号化された状態で管理し、前記暗号化手段は前記履歴管理情報又は前記挿入データを８ビットＣＦＢモード型暗号方式で暗号化することを特徴とする。
【００２９】
また、本発明（請求項１８）では、上記（請求項３）において、前記履歴管理情報生成手段は前記編集手段でなされた編集の結果得られるブロックデータに対するブロック識別情報を前記履歴管理情報に対し付加し、前記通信手段は前記暗号化履歴管理情報を前記履歴管理情報に付加されたブロック識別情報と共に送ることを特徴とする。
【００３０】
また、本発明（請求項１９）では、上記（請求項３又は４）において、前記履歴管理手段は前記編集手段でなされた編集の結果得られるブロックデータに対するブロック識別情報を前記暗号化履歴管理情報又は前記履歴管理情報に対し付加することを特徴とする。
【００３１】
また、本発明（請求項２０）では、上記（請求項５）において、前記ファイル管理サーバ装置は、該ファイル管理サーバ装置が管理する各ファイルの各バージョンに対応させて、各ファイルの各バージョンを現在編集中であるクライアント装置の数を計数するクライアント計数手段と、特定ファイルの特定バージョンを消去する要求に対し、該特定ファイルの該特定バージョンの消去の実行を、前記クライアント計数手段により計数されたクライアントの数が０になるまで遅延させる消去遅延手段と、を含むものであることを特徴とする。
【００３２】
また、本発明（請求項２１）では、上記（請求項５）において、前記ファイル管理サーバ装置は、あるクライアント装置によりなされた編集手続データを前記編集手続変換手段により変換して得られた前記最新バージョンに対する編集手続データと、他のクライアント装置によりなされた編集手続データを前記編集手続変換手段により変換して得られた前記最新バージョンに対する編集手続データとを比較して競合するか否かを検出し、競合した場合に、その競合の検出を該あるクライアント装置に通知する編集競合検出手段を含むものであることを特徴とする。
【００３３】
また、本発明（請求項２２）では、上記（請求項２１）において、前記ファイル管理サーバ装置は更に、前記編集競合検出手段が該あるクライアント装置についての競合の発生を検出しない時のみ、前記非同期編集サポート手段で前記あるクライアント装置に対して得られた履歴管理情報に基づいて前記所望のファイルの履歴管理を行なう履歴管理手段を含むものであることを特徴とする。
【００３４】
また、本発明（請求項２３）では、各ファイルが、履歴管理に必要なバージョン間の差分に対応する複数のブロックデータと各ブロックのブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置からなるファイル管理システムにおいてファイルを編集する方法であって、前記クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルに属するブロックデータを取得するステップと、前記クライアント装置において、前記ファイル管理サーバ装置から取得したブロックデータを所定の復号鍵を用いてブロック単位で復号化するステップと、前記クライアント装置において、前記復号化するステップで復号化されたブロックデータから構成される前記所望のファイルを編集して、該所望のファイルになされた編集内容を示す編集データを得るステップと、前記クライアント装置において、前記編集するステップで得られた編集データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集データを得る暗号化するステップと、前記暗号化するステップで得られた暗号化編集データを前記クライアント装置から前記ファイル管理サーバ装置に送るステップと、前記ファイル管理サーバ装置が前記クライアント装置から受取った暗号化編集データと前記各ブロックデータのブロック識別情報とに基づいて前記差分積み上げ方式又は前記ＲＣＳにより前記所望のファイルを管理するステップと、から成ることを特徴とする。
また、本発明（請求項２４）では、各ファイルが、履歴管理に必要な複数のブロックデータと、対応するブロックデータの生成時と消去時のバージョン情報を有するブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置からなるファイル管理システムにおいてファイルを編集する方法であって、前記クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルに属するブロックデータを取得するステップと、前記クライアント装置において、前記ファイル管理サーバ装置から取得したブロックデータを所定の復号鍵を用いてブロック単位で復号化するステップと、前記クライアント装置において、前記復号化するステップで復号化されたブロックデータから構成される前記所望のファイルを編集して、該所望のファイルになされた編集内容を示す編集データを得るステップと、前記クライアント装置において、前記編集するステップで得られた編集データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集データを得る暗号化するステップと、前記暗号化するステップで得られた暗号化編集データを前記クライアント装置から前記ファイル管理サーバ装置に送るステップと、前記ファイル管理サーバ装置が前記クライアント装置から受取った暗号化編集データと前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理するステップと、から成ることを特徴とする。
【００３５】
また、本発明（請求項２５）では、各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置からなるファイル管理システムにおいてファイルを編集する方法であって、前記クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータを取得するステップと、前記クライアント装置において、前記ファイル管理サーバ装置から取得したブロックデータを所定の復号鍵を用いてブロック単位で復号化するステップと、前記クライアント装置において、前記復号化するステップで復号化されたブロックデータから構成される前記所望のファイルの所望のバージョンを編集するステップと、前記クライアント装置において、前記編集するステップで前記所望のファイルの所望のバージョンに対してなされた編集内容を得る手続を示す編集手続データを生成するステップと、前記クライアント装置において、前記編集手続データを生成するステップで生成された前記所望のファイルの所望のバージョンに対する編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する編集手続データに変換するステップと、前記クライアント装置において、前記編集するステップでなされた編集の結果を示す履歴管理情報を、前記変換するステップで得られた前記所望のファイルの最新バージョンに対する編集手続データに基づいて生成するステップと、前記クライアント装置において、前記履歴管理情報を生成するステップで生成された履歴管理情報を所定の暗号鍵を用いてブロック単位で暗号化して暗号化履歴管理情報を得る暗号化するステップと、前記暗号化するステップで得られた暗号化履歴管理情報を前記クライアント装置から前記ファイル管理サーバ装置に送るステップと、前記ファイル管理サーバ装置において、前記クライアント装置から受取った暗号化履歴管理情報と前記各ブロックのブロック識別情報とに基づいて前記所望のファイルを管理するステップと、から成ることを特徴とする。
【００３６】
また、本発明（請求項２６）では、各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含むファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置からなるファイル管理システムにおいてファイルを編集する方法であって、前記クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータを取得するステップと、前記クライアント装置において、前記ファイル管理サーバ装置から取得したブロックデータを所定の復号鍵を用いて復号化するステップと、前記クライアント装置において、前記復号化するステップで復号化されたブロックデータから構成される前記所望のファイルの所望のバージョンを編集するステップと、前記クライアント装置において、前記編集するステップで前記所望のファイルの所望のバージョンに対してなされた編集内容を得る手続を示し、該所望のファイルに挿入される挿入データを含んだ編集手続データを生成するステップと、前記クライアント装置において、前記編集手続データを生成するステップで生成された編集手続データに含まれる挿入データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集手続データを得る暗号化するステップと、前記暗号化するステップで得られた暗号化編集手続データを前記クライアント装置から前記ファイル管理サーバ装置に送るステップと、前記ファイル管理サーバ装置において、前記クライアント装置から受取った前記所望のファイルの所望のバージョンに対する暗号化編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する暗号化編集手続データに変換するステップと、前記ファイル管理サーバ装置において、前記編集するステップでなされた編集の結果を示す履歴管理情報を、前記変換するステップで得られた前記所望のファイルの最新バージョンに対する暗号化編集手続データに基づいて生成するステップと、前記ファイル管理サーバ装置において、前記履歴管理情報を生成するステップで生成された履歴管理情報と前記各ブロックのブロック識別情報とに基づいて前記所望のファイルを管理するステップと、から成ることを特徴とする。
【００３７】
また、本発明（請求項２７）では、各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含むファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう複数のクライアント装置からなる共有ファイル管理システムにおいてファイルを編集する方法であって、各クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータを取得するステップと、各クライアント装置において、前記取得するステップで前記ファイル管理サーバ装置から取得したブロックデータによって構成される前記所望のファイルの所望のバージョンを編集するステップと、各クライアント装置により前記所望のファイルになされた編集内容を得る手続を示す編集手続データを生成するステップと、前記編集手続データを生成するステップで生成された前記所望のファイルの所望のバージョンに対する編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する編集手続データに変換するステップと、各クライアント装置により前記所望のファイルになされた編集の結果を示す履歴管理情報を、前記変更するステップで得られた前記所望のファイルの最新バージョンに対する編集手続データに基づいて生成するステップと、前記ファイル管理サーバ装置が前記履歴管理情報と前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理するステップと、から成ることを特徴とする。
【００３８】
【作用】
本発明（請求項１，２，６〜１２，２３、２４）では、ファイル管理サーバ装置に格納管理されるファイルは、データ部分と付加情報部分からなり、データ部分は複数のブロック・データからなり、付加情報部分は各ブロック・データに付加されたブロック識別情報を含み、さらに、各ブロック・データはブロック・データ単位で暗号化されているとともに、データ構造の管理に必要なブロック識別情報は暗号化されていない情報である。そして、クライアント装置は、ファイル管理サーバ装置に対して所望のファイルをブロック・データ単位でアクセスでき、保有している暗号鍵／復号鍵を用いて、該ブロック・データを暗号化／復号化する。また、ファイル管理サーバ装置にはファイルの内容が秘匿されているが、データ構造の管理は実行させることができる。このとき、各ブロックデータは、履歴管理に必要な各差分バージョンに対応する。また、ブロック識別情報にはブロックデータの生成時と消去時のバージョン情報が含まれている。
【００３９】
従って、ファイルの内容をファイル管理サーバ装置からは読み取ることのできない秘匿性の高いファイル編集システムを提供することができる。
【００４０】
また、クライアント装置は、ファイルのうちの必要なデータ・ブロックだけを通信により取得できるので、通信量の削減を図ることができるとともに、必要なブロックだけを復号化／暗号化すれば良いので、クライアント装置での処理量の削減、クライアント装置で必要なバッファ（メモリ）の削減ができる利点もある。
【００４１】
また、本発明（請求項３，９，１３〜１９，２５）では、ファイル管理サーバ装置に格納管理されるファイルは、データ部分と付加情報部分からなり、データ部分は複数のブロック・データからなり、付加情報部分は各ブロック・データに付加されたブロック識別情報を含み、さらに、各ブロック・データはブロック・データ単位で暗号化されているとともに、データ構造の管理に必要なブロック識別情報は暗号化されていない情報である。このブロック識別情報は、履歴を管理するために用いられる。
【００４２】
これによって、ファイルの内容は復号鍵を持っている正規のクライアント装置からのみ読み取れ、ファイルの内容をファイル管理サーバ装置からは読み取ることのできないようにした秘匿性の高いファイル編集システムを提供することができる。
【００４３】
また、クライアント装置は、ファイル管理サーバ装置に対して所望のバージョンのファイルをアクセスし、該ファイルを編集した後、この編集の内容をファイル管理サーバ装置に送り、ファイル管理サーバ装置は、前記クライアント装置から渡された編集の内容を示すデータを、前記クライアント装置がアクセスして得たバージョンがいずれであるかに従い、前記ファイル管理サーバ装置内での最新のバージョンに対する編集内容に変換する処理（マージ処理）を行う。
【００４４】
従って、ファイル管理サーバ装置は、常に各クライアント装置による編集終了時における最新バージョンのファイルの内容に対する更新を行うので、ロックを掛けずに複数のクライアント装置による非同期編集を行うことが可能となる。
【００４５】
また、時間的に古いバージョンを編集し、最新バージョンとする使い方が可能となる。すなわち、非同期編集可能な共有ファイルにおいて、編集対象を現行版に限定しない使い方が可能となる。
【００４６】
また、ファイルのデータ構造として、単純に一つ前（あるいは後）のバージョンとの差分を残していくＲＣＳのような構造ではなく、変形ＳＣＣＳで利用されているようなファイルの先頭から順番に挿入されたデータが挿入された位置にブロックとして管理され、部分的に消去された場合にはブロックの分割を繰り返していく方式に変形を加えて採用すると、ファイル管理サーバ装置が行うマージ処理に必要となる挿入／削除の位置の決定が極めて単純化され、非同期編集が容易となる。
【００４７】
特に、ファイルのデータ構造として変形ＳＣＣＳ方式を用い、暗号方式としてストリーム暗号のうちの８ビットＣＦＢモードによる方式を用いると、ブロックの分割においても再暗号化が不要になる利点がある。
【００４８】
また、本発明（請求項４，９，１３〜１７，１９，２６）では、ファイル管理サーバ装置に格納管理されるファイルは、データ部分と付加情報部分からなり、データ部分は複数のブロック・データからなり、付加情報部分は各ブロック・データに付加されたブロック識別情報を含み、さらに、各ブロック・データはブロック・データ単位で暗号化されているとともに、データ構造の管理に必要なブロック識別情報は暗号化されていない情報である。このブロック識別情報は、履歴を管理するために用いられる。
【００４９】
これによって、ファイルの内容は復号鍵を持っている正規のクライアント装置からのみ読み取れ、ファイルの内容をファイル管理サーバ装置からは読み取ることのできないようにした秘匿性の高いファイル編集システムを提供することができる。
【００５０】
また、クライアント装置は、ファイル管理サーバ装置に対して所望のバージョンのファイルをアクセスし、該ファイルを編集した後、前記ファイル管理サーバ装置に格納されている該ファイルの最新のバージョンの内容と、この編集後の内容との差分を求め、この差分に対応するブロック・データを作成してファイル管理サーバ装置に送り、ファイル管理サーバ装置ではクライアント装置から渡された前記差分に対応するブロック・データを用いて、格納している前記ファイルのバージョンを更新する。
【００５１】
従って、ファイル管理サーバ装置では、常に各クライアント装置による編集終了時における最新バージョンのファイルの内容に対する更新が行われるので、ロックを掛けずに複数のクライアント装置による非同期編集を行うことが可能となる。
【００５２】
また、時間的に古いバージョンを編集し、最新バージョンとする使い方が可能となる。すなわち、非同期編集可能な共有ファイルにおいて、編集対象を現行版に限定しない使い方が可能となる。
【００５３】
また、非同期編集により編集結果のマージ処理を実行する場合に、サーバからはクライアントでの処理に必要となるデータのみを送り、クライアントで必要な処理を実行してサーバに返す形式を実現でき、不必要な履歴に関する部分まで通信されるなどの無駄がなくなり、効率が著しく向上する。
【００５４】
また、ファイルのデータ構造として、単純に一つ前（あるいは後）のバージョンとの差分を残していくＲＣＳのような構造ではなく、変形ＳＣＣＳで利用されているようなファイルの先頭から順番に挿入されたデータが挿入された位置にブロックとして管理され、部分的に消去された場合にはブロックの分割を繰り返していく方式に変形を加えて採用すると、マージ処理に必要となる挿入／削除の位置の決定が極めて単純化され、非同期編集が容易となる。
【００５５】
さらに、先に説明したマージ処理に適した変形ＳＣＣＳのようなデータ構造を採用した場合のデータ内容の暗号化方式として、ビット単位（あるいはバイト単位）のストリーム暗号を利用することができる。このストリーム暗号は平文の特定ビット（あるいはバイト）が暗号文の特定ビット（あるいはバイト）に対応する性質がある。このため、先のような暗号化されたブロックの分割が繰り返される場合に、分割されるポイントより後ろを切りとり、その部分だけ暗号化しなおせばよく、再暗号化のオーバヘッドが軽減される。さらに、サーバ側で分割ポイントより前の部分が変更されていないことを確認することもできる。
【００５６】
また、本発明（請求項５，１０〜１２，２０〜２２，２７）では、クライアント装置は、ファイル管理サーバ装置に対して所望のバージョンのファイルをアクセスし、該ファイルを編集した後、この編集の内容をファイル管理サーバ装置に送り、ファイル管理サーバ装置は、前記クライアント装置から渡された編集の内容を示すデータを、前記クライアント装置がアクセスして得たバージョンがいずれであるかに従い、前記ファイル管理サーバ装置内での最新のバージョンに対する編集内容に変換する処理（マージ処理）を行う。
【００５７】
従って、ファイル管理サーバ装置は、常に各クライアント装置による編集終了時における最新バージョンのファイルの内容に対する更新を行なうので、ロックを掛けずに複数のクライアント装置による非同期編集を行なうことが可能となる。
【００５８】
また、本発明（請求項６及び７）では、ファイル管理サーバ装置に格納管理されるファイルは、データ部分と付加情報部分からなり、データ部分は複数のブロック・データからなり、付加情報部分は各ブロック・データに付加されたブロック識別情報を含み、さらに、各ブロック・データはブロック・データ単位で暗号化されているとともに、データ構造の管理に必要なブロック識別情報は暗号化されていない情報である。
【００５９】
従って、ファイル管理サーバ装置にはファイルの内容が秘匿されているとともに、ブロック識別情報は暗号化されていないので、ファイル管理サーバ装置ではデータ構造の管理を実行することができる。
【００６０】
また、クライアント装置は、ファイル管理サーバ装置に対して所望のファイルをアクセスし保有している復号鍵を用いてブロック単位で復号化する。そして、編集手段を用いてこのファイルを編集し、この編集の内容を示すデータをブロック・データごとに所定の暗号鍵を用いて暗号化する。一方、ファイル管理サーバ装置は、クライアント装置から渡されたブロック・データとブロック識別情報とに基づいて、該ファイルの履歴管理を行う。
【００６１】
このように、ファイルの履歴管理とファイル管理サーバ装置に対するデータの秘匿性を同時に実現できる。
【００６２】
また、クライアント装置からファイル管理サーバ装置には、ファイルのうちの必要なデータ・ブロックだけを通信すれば良いので、通信量の削減を図ることができる。
【００６３】
また、請求項９のように構成した場合、ブロックの分割暗号化に際し、ブロックの先頭から分割ポイントまでの部分は暗号化されたままで再利用でき、分割ポイント以降のみを再暗号化する。なお、全く再暗号化を必要としない方法もある。バージョン管理法として、ＳＣＣＳを変形した方式を用いた場合、ブロックの分割が繰り返されるが、このような場合に有利である。
【００６４】
また、本発明（請求項１０）では、ファイル管理サーバ装置に格納されるファイルは、データ部分と付加情報部分からなり、データ部分は複数のブロック・データからなり、付加情報部分は各ブロック・データに付加されたブロック識別情報を含み、さらに、各ブロック・データはブロック・データ単位で暗号化されているとともに、データ構造の管理に必要なブロック識別情報は暗号化されていない情報である。そして、クライアント装置は、ファイル管理サーバ装置からファイルを得ることができ、保有している復号鍵を用いて該ブロック・データを復号化し、得られた復号化データをブロックとして新たなブロック・データに再構成し、暗号鍵を用いて新たなブロック・データごとに暗号化し、ファイル管理サーバ装置に出力することができる。
【００６５】
これにより、クライアント装置により、履歴情報の消去を行ったり、ファイルのブロック・データ数が多くなった時などにブロックを再構成し、ブロック識別情報によるオーバヘッドを削減することができる。また、これを暗号鍵／復号鍵を有するクライアント装置が行うことにより、サーバに対するファイルの内容の秘匿性は守られる。
【００６６】
また、本発明（請求項１１）では、ファイル管理サーバ装置に格納されるファイルは、データ部分と付加情報部分からなり、データ部分は複数のブロック・データからなり、付加情報部分は各ブロック・データに付加されたブロック識別情報を含む。そして、クライアント装置は、あるバージョンのファイルを保存する手段を有し、ファイル管理サーバ装置から、現在クライアント装置が保有しているバージョンのファイルと、所望のバージョンのファイルの差分情報を受け取り、クライアントが保有している当該ファイルのデータとファイル管理サーバ装置からの差分情報により、所望のバージョンのファイルを構築し編集することができる。
【００６７】
従って、クライアント装置は、ファイル全体ではなく、現在保有するバージョンと所望するバージョンとの差分情報のみをファイル管理サーバ装置から取得すればよく、通信量の削減を図ることができるとともに、ブロック・データが暗号化されている場合はクライアント装置での復号化処理量を削減できる利点がある。
【００６８】
また、本発明（請求項１２）では、オペレーティング・システムによって提供されるシステムコールテーブル中のアドレス・ポインタの値を書き換えるだけで、既存のアプリケーションソフトウェア等のプログラム自体は全く変更せずに、アクセス要求者として利用して非同期編集を行うことが可能になる。
【００６９】
また、請求項１４のように構成した場合、請求項３又は４のファイルのバージョン管理において、履歴の完全性をファイル管理サーバ装置側だけで保証できる。
【００７０】
また、請求項１５のように構成した場合、請求項３又は４のファイルのバージョン管理において、現行バージョンのファイルの取り出しおよび古い履歴の消去が容易となる。
【００７１】
また、請求項１６，１７のように構成した場合、請求項３又は４のファイルのバージョン管理において、古い履歴の消去が容易となる。
【００７２】
また、本発明（請求項２０）では、ファイル管理サーバ装置内に、その管理する各々のファイルの各々のバージョン毎に対応付けて、当該ファイルの当該バージョンを編集中であるクライアント装置の数を計数する手段を設けた。これにより、ファイル管理サーバ装置は、各々のファイルの各々のバージョンについて、それを編集途中であるクライアント装置が存在するかどうかを判断することができる。すなわち、指定されたファイルの指定されたバージョンに対応する計数値が０であるならば、それを編集途中であるクライアントは存在せず、また、計数値が０でないならば、それを編集途中であるクライアントが存在すると判断できる。
【００７３】
そして、ファイル管理サーバ装置は、ファイルのバージョンを消去する要求が発行された際、対応する計数値が０でない場合には、０に等しくなるまで消去の実行を遅延させることができる。
【００７４】
これにより、ファイル管理サーバ装置は、消去の対象となったファイルのバージョンを編集途中のクライアントが存在する間は、該ファイルの該バージョンを消去することがなくなるので、マージ処理の実行に支障をきたすおそれがなくなる。
【００７５】
また、本発明（請求項２１，２２）では、クライアント装置は、ファイル管理サーバ装置に対して所望のバージョンのファイルをアクセスし、該ファイルを編集した後、この編集の内容をファイル管理サーバ装置に送り、ファイル管理サーバ装置は、前記クライアント装置から渡された編集の内容を示すデータを、前記クライアント装置がアクセスして得たバージョンがいずれであるかに従い、前記ファイル管理サーバ装置内での最新のバージョンに対する編集内容に変換し、他のクライアントによって既に行われている編集内容と競合するかどうかの検出を行い、前記クライアント装置に競合検出の結果を通知する。そして、この検出の結果にかかわらず、ファイルの更新（マージ処理）を行う。
【００７６】
従って、各クライアント装置による編集結果は、ファイル管理サーバ装置における最新バージョンのファイルに対する更新に変換され、他のクライアントによる編集と競合するか否かによらず、ファイル管理サーバ装置に最新バージョンとして更新されるため、ロックを掛けずに複数のクライアント装置による非同期編集を行うことが可能となる。
【００７７】
また、ファイル更新を行ったクライアント装置は、ファイル管理サーバ装置により、編集内容の競合検出の結果を通知されるので、その結果に基づいて、ファイルを編集し直すことができる。その際、ファイル管理サーバ装置ではファイルは履歴管理されているので、過去のバージョンを取り出すなどして柔軟に編集を行うことができる。
【００７８】
また、請求項２２のように構成した場合、ファイル管理サーバ装置は、他のクライアントによる編集との競合検出の結果に基づいて、ファイルの更新を行うかどうかを判断することができるので、ファイル管理サーバ装置の最新バージョンのファイルにおいて意味的矛盾が起こりにくい、あるいは起こらないようにすることができる。
【００７９】
【実施例】
以下、図面を参照しながら本発明の実施例について説明する。
【００８０】
まず、本発明の第１実施例に係る共有ファイル編集システムでは、２つの独立して実施可能な発明を適用している。第１の発明は、ファイルをブロック化して管理する共有ファイル編集システムにおいて、ファイルの内容をファイル・サーバからは読み取ることができないようにするものであり、第２の発明は、ファイルのバージョン管理をサポートする共有ファイル編集システムにおいて、非同期編集処理を行うことを可能とするものである。
【００８１】
図１は、本実施例の概念図である。この共有ファイル編集システムは、共有ファイルに対するファイル・アクセス要求を発する１つまたは複数のアクセス要求者（以下、クライアントと呼ぶ）１０１と、ファイルの保管とアクセス要求者１０１に対する所定データの通信などを行うファイル管理サーバ（以下、サーバと呼ぶ）１１０からなる。さらに、各クライアント１０１とサーバ１１０の間には、要求文や応答文を受け渡しするための通信路１１１が設けられている。
【００８２】
クライアント１０１は、実際のアクセス要求を出したユーザやそのユーザの使用している計算機のプロセスなどを抽象化したものである。また、各クライアント１０１には、それぞれ暗号化および復号化を実行する暗号器１１２が備わっている。すなわち、この暗号器１１２は、暗号アルゴリズムを実行する暗号化／復号化処理部（図１５の１１２１，図２４の８１２１）と、暗号鍵および復号鍵を記憶する鍵記憶部（図１５の１１２２，図２４の８１２２）からなる。この暗号化／復号化処理部と鍵記憶部の働きについては後述する。
【００８３】
一方、サーバ１１０は、ファイル管理を行う計算機のプロセスでも良いし、ファイル管理機能を有する独立した装置でも良い。
【００８４】
通信路１１１は、公衆網、ＬＡＮなどのイーサネット、あるいは計算機内のソケットによる通信など、電子的にメッセージを交換できる媒体であれば何を用いても良い。
【００８５】
サーバ１１０は、複数のファイル１１３を保管している。このファイル１１３は、ファイルの内容であるデータだけでなく、後で説明する履歴管理の情報やアクセスが許されたユーザ名のリストや暗号化・復号化に利用される情報などを含む。これらのファイル１１３は、それぞれ正規のクライアント１０１だけが復号できる形式で暗号化されている。
【００８６】
例えば慣用暗号（暗号化の鍵と復号化の鍵が同一の暗号方式）を利用する場合には、正規のクライアント１０１は同一の鍵を所持しており、ファイル１１３はその鍵を利用して暗号化・復号化されている。
【００８７】
ファイル１１３は、そのファイル名自体は同一に保たれても、各アクセス時点で書き込みや消去などが繰り返され、経時的にその内容が変化していく性質のものである。そこで、いくつかの特定の時点でのファイルの内容を保存しておき、後に保存を行った任意の時点における状態を再現したいなどの要求が生じる場合がある。特に、プログラム開発を行っている場合などでは上記要求は一般的である。このような履歴管理（バージョン管理）を実現する最も原始的な方法は、ある時点でのファイルの内容をまるごと保存しておくものである。一般的には、複数のバージョン間での違い（差分）はわずかなことが多いため、このような管理法はサイズの面で無駄があり、ＳＣＣＳ（Ｓｏｕｒｃｅ Ｃｏｄｅ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）やＲＣＳ（Ｒｅｖｉｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）といった差分の情報だけを保存していく方法が通常用いられている。
【００８８】
以下、各履歴管理法でのデータ構造の概要を説明する。
【００８９】
まず、ＲＣＳの原型と考えられる方式を説明する。ここで説明する方式は、差分積み上げ方式と呼ぶこととする。図２に、この差分積み上げ方式でのファイルのデータ構造を示す。この方式では、最初に作成されたバージョンのファイルを全文そのままの形で保存しておき、これをバージョンＶ．１（ブロック２０１）とする。次に、このバージョンＶ．１の一部を消去したり、何か挿入したりして新たなバージョンＶ．２が生成された場合、これを保存する際にＶ．２とＶ．１との間の差分を求め、その差分Ｖ．２−Ｖ．１（ブロック２０２）だけを保存する。ここで、バージョン間の差分は、例えばＵＮＩＸのｄｉｆｆコマンドが提供するような、“どの位置に何が挿入された”とか“どの位置からどの位置までが消去された”といったことを表すデータの集合である。ファイルの全体に渡る変更が行われることはほとんどないので、一般的には差分のサイズの方がファイル全体のサイズよりも小さい。このような保存状態にあるデータすなわちＶ．１のデータと差分Ｖ．２−Ｖ．１のデータが、バージョンＶ．２の復元に十分な情報を提供する。以降は同様に、バージョンＶ．３とＶ．２との差分Ｖ．３−Ｖ．２（ブロック２０３）、Ｖ．４とＶ．３との差分Ｖ．４−Ｖ．３（ブロック２０４）、…というように、常に編集後の新バージョンと保存されている最新のバージョンとの間で差分をとり、その差分だけを追加して保存していく。
【００９０】
従って、この差分積み上げ方式は、最新のバージョン（現行バージョン）を復元するためにそれまでの全ての履歴を利用することとなるが、ファイルのサイズ面では大きな改善がある。
【００９１】
次に、ＲＣＳ方式について説明する。図３に、ＲＣＳによって履歴管理されたファイルのデータ構造を示す。このＲＣＳ方式では、次のように履歴を管理する。まず、現行版（ブロック３０４）は常にファイル全文そのままの形で保管する。ここでは、現行版をＶ．４とする。そして、それの一つ前のバージョンＶ．３はＶ．４との差分Ｖ．３−Ｖ．４（ブロック３０３）という形式で保存する。ここで、差分をとるときに時間的に新しいバージョンを基準にした差分とするのがこの方式の特徴である。Ｖ．３以前のバージョンも同様で、差分Ｖ．２−Ｖ．３（ブロック３０２）、差分Ｖ．１−Ｖ．２（ブロック３０１）が保存される。この状態で新しいバージョンＶ．５が保存される場合には、差分Ｖ．４−Ｖ．５を求める処理と、求めた差分と最新版Ｖ．５を保存する処理が実行される。
【００９２】
このようなデータ構造を利用した場合には、現行版の取り出しが容易になる利点がある。一方、昔のバージョンを復元する場合ほど復元に時間を要することになるが、通常は新しいバージョンほどアクセスする機会が多くなるので、本方式は一般的な利用形態に適したものである。
【００９３】
次に、もう１つの代表的な履歴管理法であるＳＣＣＳ方式に変形を加えた方式について説明する。これは、各ブロック・データに対応させて、どのバージョンでそのブロック・データが挿入されたかを示す情報と、どのバージョンでそのブロック・データが削除されたかを示す情報を記憶するバージョン管理方式である。
【００９４】
図４に、変形ＳＣＣＳにより履歴管理されたファイルのデータ構造の一例を示す。ＳＣＣＳ方式では、ある時点のファイル・データを全文の形で保存しておくことはせず、ファイルをブロック化して管理し、挿入があった場合は挿入された位置から挿入されたサイズだけのブロックが生成される。全てのブロックには、図中フィールド４０６に示す生成時点もしくは該当ブロックが生成された時点でのバージョン番号（こけはブロックの作成時を特定するための情報の一例である）と、フィールド４０７に示す消去時点もしくは該当ブロックが消去された時点でのバージョン番号（これはブロックの削除時を特定するための情報の一例である）の２つのデータ・フィールドが対応づけられている。この４０６，４０７の２つのフィールドは、ブロック識別情報の一例である。ブロック識別情報とは、個々のブロックがどういう位置付けのブロックであるかを把握できるように付加する情報である。先の差分積み上げ方式やＲＣＳの場合にも、個々のブロックには“差分Ｖ．Ｘ−Ｖ．Ｙ”などのタグを付加するが、これらのタグがブロック識別情報である。言い換えれば、ブロック識別情報とは、ブロック同士の関連を示す情報である。
【００９５】
以下、さらにこの変形ＳＣＣＳ履歴管理法について、図４を用いて具体的に説明する。図４のファイルは、Ｖ．１からＶ．４までの４種類のバージョンからなるものである。このファイルのブロックは現在５つで、上から順にｂ１（ブロック４０１）、ｂ２（ブロック４０２）、ｂ３（ブロック４０３），ｂ４（ブロック４０４），ｂ５（ブロック４０５）である。
【００９６】
ここで、前述した２つのデータ・フィールド４０６，４０７の内容を参照することによって、以下のような履歴でこのファイルが編集されたことが分かる。
【００９７】
まず、バージョンＶ．１（最初の版）では、このファイルはｂ２，ｂ３からなる。次に、バージョンＶ．２で一番最初と最後の位置に追加が行われ、Ｖ．２はｂ１，ｂ２，ｂ３，ｂ４からなる。次に、バージョンＶ．３でブロックｂ４の部分が変更され、ブロックｂ５に書き換えられた。なお、このときブロックｂ４にはバージョンＶ．３で消去された旨のフラグが付けられ、新たにブロックｂ４の直下にブロックｂ５が挿入された旨の履歴管理が行われる。従って、Ｖ．３はｂ１，ｂ２，ｂ３，ｂ５からなっている。次に、バージョンＶ．４（現行版）では、ブロックｂ２が消去され、ｂ２にはバージョンＶ．４が消去された旨のフラグが付けられる。従って、Ｖ．４はｂ１，ｂ３，ｂ５からなっている。なお、バージョンＶ．４以前では、ブロックｂ２とｂ３は一固まりのブロックであったのだが、Ｖ．４でその固まりのブロックの前半のｂ２に対応する部分が消去されたのである。
【００９８】
この例で分かるように、変形ＳＣＣＳの履歴管理では、現行版のファイルが一固まりとして存在するわけではないが、任意のバージョンの取り出しに対してそのバージョンを含んで以前の時点で生成され、そのバージョンの時点で消去されていないブロックを上から順に連結すればよいので、任意のバージョンの取り出しが大きな負荷になることなく実現できる特徴がある。また、バージョンが進むにつれ、ブロックの分割が繰り返されていく傾向があることも理解できよう。この履歴管理法では、挿入されるブロックの位置や連続して消去される範囲さえ指定できれば容易に履歴管理できるのである。
【００９９】
ここで、本実施例の共有ファイル編集システムでは、内容の読み出し保護を行うためには、暗号技術を利用する。このとき、ファイルを格納しているサーバ自体にもファイルの内容の読み出しを許さないことが第１の発明の特徴である。また、ファイルに対する編集処理を行う主体が複数であり、しかも共同編集をできるだけロックなどの排除行為なく行えるようにしたことが第２の発明の特徴である。そして、上記のようなファイルのデータ構造と暗号化を結び付けることによってサーバに対する内容の秘匿性を確保した共有ファイル編集システムを実現するとともに、上記のようなファイルのデータ構造を利用して複数主体による非同期編集を実現している。
【０１００】
以下、本実施例の特徴の１つであるロックを掛けない非同期編集について説明する。非同期編集として問題になるのは、あるクライアントＡがファイルの現行バージョンＶ．４を読み出し、それに対する部分的な消去や挿入を実行して新バージョンＶ．Ａを作成したものとする。また、ほぼ同時に他のクライアントＢがその時点でのファイルの現行バージョンＶ．４を読み出し、それに対して部分的な消去や挿入を実行して新バージョンＶ．Ｂを作成したものとする。仮に書き戻しの実行に関し、ライセンスＡの方が早かったものととする。このとき、バージョンＶ．Ａが新バージョンＶ．５として保存され、必要な履歴管理が実行されることになるが、バージョンＶ．Ｂが書き戻されようとすると矛盾が生じる。すなわち、バージョンＶ．Ｂをさらに新しいバージョンＶ．６として保存すると、バージョンＶ．６にはバージョンＶ．５で加えられた変更は何ら残らなくなる。このようなことが起こらないように新バージョンは常にそれまでに行われた変更をマージしたものである必要が必要である。
【０１０１】
こうした非同期編集を実現するために、本実施例の共有ファイル編集システムでは履歴管理を次のように利用する。すなわち、全ての編集行為は削除と挿入の組み合わせで記述できるが、これは編集対象バージョンとの差分として固有に決定される。この点に着目すると、例えばある編集行為Ｅ１がバージョンＶ．４に対して、どこに何を挿入し、どこからどこまでを消去したという手続きの集合Δ１として定義でき、他の編集行為Ｅ２が同じバージョンＶ．４に対する編集手続きの集合Δ２として定義できる。
【０１０２】
まず、編集行為Ｅ１が最初に書き戻された場合、編集手続きΔ１として元のバージョンＶ．４との差分を履歴管理方式に適した形式に変更して格納すれば新バージョンＶ．５ができる。次に、編集行為Ｅ２が書き戻される場合、編集手続きΔ２はバージョンＶ．４との差分を与えるものであるから、これを現行のバージョンＶ．５に対する差分に変更する必要がある。このように変更された編集手続きΔ２′を基にバージョンＶ．５との差分を履歴管理方式に適した形式に変更して格納することにより新バージョンＶ．６とする。以上の行為を繰り返せば、矛盾無く非同期編集を実現可能である。
【０１０３】
このとき、現行バージョンとの差分としては定義されていない編集手続きを、現行バージョンとの差分に矛盾無く変換することが重要である。この機構の応用として、かなり古いバージョンに対して編集を行い、その結果を現行版とマージするような使い方ができる。
【０１０４】
このような手続きを実行するための非同期編集システムの構成を図５に示す。図のように、この非同期編集システムは、編集部５００、編集手続き生成部５０１、編集手続き変換部５０２、履歴管理情報生成部５０３、履歴管理部５１０、データ記憶部５１１からなる。なお、この非同期編集システムは、サーバ１１０とクライアント１０１に分散配置されるものであり、分散配置の仕方はファイルを暗号化するか否かに応じて適宜設定される。ただし、編集部５００はクライアント１０１に、データ記憶部５１１はサーバ１１０に実装されることになる。
【０１０５】
編集部５００は、履歴管理部５１０から得られる編集対象のバージョンでのファイルの内容に対して編集を行うためのものである。
【０１０６】
編集手続き生成部５０１は、編集対象のバージョンでのファイルの内容と、編集部５００にてそのファイルに対して行われた編集結果のファイルの内容を入力し、「どの部分に何が挿入された」、あるいは「どこからどこまでの部分が削除された」などといった挿入データと挿入位置、削除開始位置と削除終了位置などからなる編集手続きデータを出力する。
【０１０７】
編集手続き変換部５０２は、この編集手続きデータと後述の履歴データとを入力し、この編集手続きデータを現行バージョンに対する編集手続きに変換して出力する。例えば、与えられた編集手続きデータに対し、挿入データは不変とし、その挿入位置を現行バージョンに対する挿入位置に変換し、また、削除開始位置や削除終了位置も同様に現行バージョンに対する削除開始位置と削除終了位置に変換する。この変換作業に必要な補助入力として利用されるのが、履歴管理部５１０からの履歴データである。
【０１０８】
履歴管理部５１０は、編集対象のファイルの更新履歴を保存したデータの管理を行っている。編集手続き変換部５０２の出力である編集手続きデータは履歴管理情報生成部５０３に入力され、この履歴管理情報生成部５０３で利用している履歴管理法に適した形式の履歴情報に変換され、この履歴情報が履歴管理部５１０に送られ、最新バージョンの更新が行われる。
【０１０９】
なお、データ記憶部５１１は、複数のファイルを格納するためのものである。
【０１１０】
次に、具体的な履歴管理法に対して、図５に示した非同期編集システムの構成の各部の働きを説明する。
【０１１１】
いずれの履歴管理方式を用いる場合でも、編集手続き生成部５０１はＵＮＩＸのｄｉｆｆコマンドに相当する処理を行う。すなわち、編集対象バージョンのファイル・データと編集後のファイル・データとを比較し、「どこに何が挿入されたか」、あるいは「どこからどこまでが消去されたか」などの編集手続きデータを出力する。
【０１１２】
最初に、履歴管理法として差分積み上げ方式（図２）を用いる場合について、図６に示す例を用いて説明する。
【０１１３】
ここでは、編集対象バージョンがバージョンＶ．２であり、現行版がバージョンＶ．４である場合を想定する。このとき、編集手続き生成部５０１の出力Δ１が、仮に以下のものであったとする。
【０１１４】
・ｉ４
ここから新たに挿入しました。
うまくマージできるでしょうか？
・ｄ８，９
すなわち、バージョンＶ．２に対して４行目に２行（ここから…でしょうか？）を挿入し、Ｖ．２に対して８行目から９行目までの２行を消去したとことを表している。
【０１１５】
編集手続き変換部５０２の機能は、上記の編集手続きΔ１を現行版Ｖ．４に対する編集手続きΔ１′に変換することである。このときに必要となるものが、履歴管理部５１０から得られるＶ．２から現行版Ｖ．４までに加えられた編集履歴の情報である。
【０１１６】
ここで、一例として、バージョンＶ．３ではバージョンＶ．２の２行目と３行目を消去し、さらに５行目に１行（例えば、“ここはＶ．２の５行目です”などのデータ）が挿入されたものとする。また、バージョンＶ．４ではバージョンＶ．３の５行目から７行目までを消去し、８行目に２行（例えば、“この部分気に入らないので／／このように変えました”など。但し，／／が改行を表す）が挿入されたものとする。このとき、編集手続きΔ１における挿入位置はバージョンＶ．２における４行目が現行版Ｖ．４の何行目に対応するかを求めなければならない。これに対し、バージョンＶ．３とＶ．２の差分、バージョンＶ．４とＶ．３の分の２つは必要となる全ての情報を含んでおり、図６に示したようにＶ．４の２行目がＶ．２の４行目に対応していることが分かるので、実際は、“Ｖ．２の４行に２行挿入”は“Ｖ．４の２行目に２行挿入”に変換される。同様に、Ｖ．２の８行目と９行目がＶ．４のそれぞれ何行目になるかを履歴を追って調べると、Ｖ．２の９行目はＶ．４の７行目に対応するが、Ｖ．２の８行目は既にＶ．４で消去されていることが分かる。既に、消去されている部分をさらに消去することは通常意味をなさないので、この場合には、“Ｖ．２の８行目から９行目を消去”は“Ｖ．４の７行目を消去”に変換される。ここに説明した編集手続きの変換（主に変更位置の検索）を行うのが編集手続き変換部５０２である。このように編集手続き変換部５０２では変換のために履歴情報が必要不可欠である。
【０１１７】
こうして作成された編集手続きデータΔ１′を入力として、履歴管理情報生成部５０３は、現行版Ｖ．４と新バージョンとの差分を求める。ここでは履歴管理法として差分積み上げ方式を用いているので、先の“（Ｖ．４の）２行目に２行挿入”と“（Ｖ．４の）７行目を消去”がそのまま履歴管理情報となり履歴管理部５１０へ送られ、履歴として追加される。
【０１１８】
次に、図４の変形ＳＣＣＳのような履歴管理法を利用すると、編集手続き変換部５０２で変更位置の検索処理が単純になる。以下、この点について先の例を用いて説明する。
【０１１９】
ここでは、図７のように、バージョンＶ．２で１０行あったものとする。
【０１２０】
まず、Ｖ．３においてＶ．２の２行目と３行目が消去されたので、２行目と３行目の部分は新たに１つのブロックになり、消去時点フラグに“Ｖ．３”が書かれている。また、Ｖ．２の４行目と５行目の間に１行挿入されたので、Ｖ．２の４行目が１つのブロックになり、またＶ．３で挿入された１行が１つのブロックを構成し、このブロックの生成時間フラグに“Ｖ．３”が書かれている。
【０１２１】
次に、Ｖ．４においてＶ．３の５行目から７行目までが消去されたので、Ｖ．３の時点で消去されていない行を先頭から数えて５行目から７行目までが１つのブロックになり、消去時点フラグ“Ｖ．４”が書かれる。さらに、Ｖ．３の７行目と８行目の間に２行挿入されたので、この挿入された２行が１つのブロックを構成し、その生成時点にフラグに“Ｖ．４”と書かれている。
【０１２２】
編集手続き生成部５０１からの出力である編集手続きΔ１は先に説明したものと同じであるが、履歴管理部５１０から編集手続き変換部５０２に渡される履歴データは図７のバージョンＶ．４に示した形式になっている。編集手続き変換部５０２では、履歴データのうち、Ｖ．２の時点での４行目（挿入位置）と８行目（削除開始位置）、９行目（削除終了位置）を求めるために、Ｖ．２での先頭から４行目，８行目，９行目を数える。数えるときの注意は、Ｖ．２以降で挿入された部分は飛ばすことである。
【０１２３】
こうして求めた位置に新規に挿入された２行（“ここから新たに挿入しました／／うまくマージできるでしょうか？”）を１つのブロックとして挿入する。さらに、削除に関しては、Ｖ．２の８行目は既に削除時点フラグが立っているので何もせず、９行目を１ブロックとして分割し、削除時点フラグに“Ｖ．５”と書けば良い。こうして作成されたバージョンＶ．５を履歴管理部５１０に送り、これを更新する。
【０１２４】
この一連の手続きは履歴管理情報生成部５０３の機能も含んでおり、履歴管理部５１０を更新するところまでが達成される。
【０１２５】
ここで見たように履歴管理法として変形ＳＣＣＳのような方式を利用すると、変更位置の検索が単純に先頭からのカウントだけで達成されるため、極めて処理が単純化される。
【０１２６】
このように、本実施例によれば、履歴管理法として変形ＳＣＣＳのようなデータ構造を利用し、しかも図５に示した諸機能を用いて非同期編集を実現することが可能である。
【０１２７】
次に、本発明の特徴の１つであるファイルデータの暗号化手法について説明する。
【０１２８】
本実施例では、前述のようなファイルの履歴管理で生じるいくつかのデータ・ブロックごとに独立に暗号化し、サーバにはどのデータ・ブロックがどの部分であるかを把握可能な形にする独自の構成を採用する点に特徴がある。
【０１２９】
そのようなファイル構成の具体例は、図２のように差分積み上げ方式を履歴管理法として利用する場合には、ブロック２０１，２０２，２０３，２０４をそれぞれ独立に暗号化し、サーバには「ブロック２０１が最初のバージョンＶ．１のデータを暗号化したものである」「ブロック２０２がバージョンＶ．２とバージョンＶ．１の差分Ｖ．２−Ｖ．１を暗号化したものである」といった対応関係を認識可能な形態にすることである。各暗号化ブロックとそのブロックの意味の対応付けの具体的な一例として、サーバの管理用のフラグ・フィールドを用意し、そこにＶ．１やＶ．２−Ｖ．１などの情報を書き込んでおけばよい。
【０１３０】
このようにサーバが各データブロックの識別に利用する情報を“ブロック識別情報”と呼ぶことにする。ここに述べた管理用のフラグ・フィールドや図４の生成時点（４０６）、消去時点（４０７）の各フィールドはその一例である。
【０１３１】
他の具体例としては、図３のＲＣＳ方式のような履歴管理法を利用する場合に、ブロック「３０１，３０２，３０３，３０４を独立に暗号化し、サーバには「ブロック３０１が差分Ｖ．１−Ｖ．２を暗号化したものである」「ブロック３０２が差分Ｖ．２−Ｖ．３を暗号化したものである」といった対応関係を認識可能な形態にすることである。
【０１３２】
さらに他の具体例としては、図４の変形ＳＣＣＳ方式のような履歴管理法を利用する場合に、ブロック４０１，４０２，４０３，４０４，４０５を独立に暗号化し、サーバには「ブロック４０１が先頭ブロックであり、ブロック４０２がそれに続くブロックであり、…」といった情報を認識可能な形態にすることである。例えば、ブロックの区切りが分かる形で単純に連結するだけでも良い。図４の各ブロックには、生成時点４０６と消去時点４０７の２つのデータ・フィールドが対応づけられていることは先に説明した通りであるが、これらのフィールドは暗号化しない。
【０１３３】
この方式のように暗号化する部分を独立化することの利点は、クライアントの処理量とクライアント・サーバ間の通信量の削減にある。すなわち、クライアントが図３のような履歴管理システムにて現行版をサーバに対して要求した場合、サーバは暗号化されたブロック３０４だけを送信すればよいが、例えば図３のデータ・ファイル全体が一固まりとして暗号化されている場合、サーバは全てのデータを送信しなければならない。さらに、このデータを受信したクライアントは一固まりとして暗号化されている全てのブロック３０１〜３０４を復号しなければならず、不要な処理が多く含まれてしまうことが理解できよう。
【０１３４】
また、例えば図２の履歴管理方式において、クライアント側が新たな編集行為の結果として変更できるのは、差分Ｖ．５−Ｖ．４の暗号化ブロックを追加することだけである。しかし、ファイルが一固まりとして暗号化されているような場合には、特に差分Ｖ．４−Ｖ．３との区切りに近い部分が変更されていないことの検査が困難になる。すなわち、暗号化は通常ファイルの先頭から連鎖的にある長さごとに区切って行われるため、ファイルの終わりに近い部分以外が変更されていた場合には、何らかの改変行為が行われたことが、サーバによって暗号文から推定可能となるが、ファイルの終わりに近い部分（新たに追加された差分に近い部分）は改変の検出ができない。ところが、図２のデータ構造にてブロックごとに独立に暗号化する場合には、新たな差分の暗号化データを追加していくだけであるから履歴に関して改変が行われないようにサーバが容易に管理できる。
【０１３５】
ここで、先に見てきたようにロックを掛けない非同期編集を実現する上では、特に図４のデータ構造を利用した履歴管理法が、マージ処理の簡単化の面でも適している。しかし、このような履歴管理法の特徴として、ある時点で一固まりであったブロックがそれ以降の時点で次々に分割されていくことがある。一般にはブロックの分割に伴い、ブロックデータの再暗号化の必要が生じるが、本実施例では暗号化の処理を軽減可能な暗号方式を用いる。以下、そのような暗号方式について説明する。
【０１３６】
ブロック内のデータはビットあるいはバイトが最小の単位となっていることを想定できるが、本実施例の第１の暗号方式では１つのブロックがいくつかの位置（ブロックの先頭から順にポイント１，ポイント２，…とする）で分割される場合に、ブロックの先頭からポイント１までの暗号データは再暗号化の必要がなく、既に暗号化されているデータをそのまま利用可能である。ポイント１以降のデータのみ再暗号化する。
【０１３７】
さらに、本実施例の第２の暗号方式では、一切再暗号化を必要とせず、一度暗号化されたデータはそのまま利用される。
【０１３８】
最初にこのような利用が可能となるための暗号方式の条件を述べる。まず、任意のポイントで暗号ブロックを分割した場合に、その分割された暗号ブロックの断片から対応する平文が得られなければならない。従って、平文の特定ビット（あるいはバイト）が暗号文の特定ビット（あるいはバイト）に対応しているこが条件となる。このためには当然のことながら、暗号化によるサイズの拡大があってはならい。このようなな性質を持つ暗号方式にストリーム暗号と呼ばれる方式がある。代表例にブロック暗号ＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）をＯＦＢ（Ｏｕｔｐｕｔ ＦｅｅｄＢａｃｋ）モードあるいはＣＦＢ（Ｃｉｐｈｅｒ ＦｅｅｄＢａｃｋ）モードで利用する方式がある。ＯＦＢモードによる暗号化手順は図８に、ＣＦＢモードによる暗号化手順は図９に示した。
【０１３９】
まず、図８を参照しながらＯＦＢモードの動作原理を説明する。送信側と受信側はブロック暗号の鍵Ｋとシフトレジスタ６０２，６１２の初期値であるＩＶ（６０１，６１１）を共有しているものとする。送信側は暗号化に当たりシフトレジスタ６０２の内容を暗号化し、得られた結果６０４の内Ｌビットをシフトレジスタ６０２に帰還させるとともに、平文のＬビットとビット単位で排他的論理和演算（６０５）を行う。この処理を繰り返すことにより、平文をＬビットずつ暗号化する。但し、１回の処理で暗号化される量はＬビットであるが、実はビット単位で暗号化されているものである。
【０１４０】
また、受信側の復号処理も送信側とまったく同様に行われるが、その詳細は自明であるので説明を省略する。
【０１４１】
次に、図９を参照しながらＣＦＢモードの動作原理を説明する。ＯＦＢモードの場合と前提は同じで、ハードウェアの構成もほとんど同様であるが、違いは暗号化時にシフトレジスタ６２２に帰還させるデータがブロック暗号器の出力ではなく、暗号文を用いる点にある。このために、復号側の処理もシフトレジスタ６３２への入力にＬビットの暗号文を用いることになる。原理は図９から明らかなのでここでの説明は省略する。
【０１４２】
これらのモードは１回の暗号化に利用されるビット数（すなわち、シフトレジスタへの帰還ビット数と一致する）を用いて、ＬビットＯＦＢモードもしくはＬビットＣＦＢモードと呼ばれる。１ビットＯＦＢモードもしくは１ビットＣＦＢモードは、代表的なビット単位のストリーム暗号である。また、８ビットＯＦＢモードもしくは８ビットＣＦＢモードは代表的なバイト単位のストリーム暗号である。なお、この両モードにおいて、平文８ビットと暗号器出力の８ビットをビット毎に排他的論理和をとって暗号化／復号化するのではなく、例えば８ビットの加算／減算により暗号化／復号化するように変形することも可能である。
【０１４３】
以下では、ブロック内データの最小単位をバイト単位と仮定して説明を行う。このような、ストリーム暗号による暗号文の強度を保証するためには、鍵Ｋが固定である場合、シフトレジスタの初期値ＩＶを平文ごとに変えた方が好ましい。そのようにしないと、２つの暗号文の同一位置の排他的論理和を取るだけで平文同士の排他的論理和が求められたり、２つの暗号文の先頭がまったく同じ時には、対応する平文もその部分はまったく同じであることが分かるなどの弱点が発生する。この点は、本実施例においては、暗号化のブロックごとに初期値ＩＶを変えることで対応する。
【０１４４】
さて、本実施例の暗号方式によるブロック・データ分割時の暗号手順を図１０を参照しながら説明する。（ａ）が分割前のブロックデータのデータ構造であり、（ｂ）が分割後のブロックデータのデータ構造である。ここでは、ある暗号ブロック（ブロック０）の中間部分が削除されることを例とし、ブロックを前半部（ブロック１）、削除部（ブロック２）、後半部（ブロック３）の３つに再暗号化することを想定する。各ブロックごとに初期値ＩＶを格納する領域６４２が設けられている。但し、この初期値ＩＶは暗号化されない。
【０１４５】
本実施例の第１の暗号方式では、ＬビットＯＦＢモードもしくはＬビットＣＦＢモードを用いる。ただし、Ｌは８の倍数とする。各ブロックの初期値ＩＶは新規にブロックが生成される時点で乱数発生などにより生成される。ブロック・データは先の暗号方式で先頭から順番にＬビットずつ暗号化される。ブロックの最後はちょうどＬビットにならない場合があるが、その場合にも平文の長さで暗号を打ち切る。このようにしても最後の部分を復号できる。
【０１４６】
ブロック・データ分割時（図１０）の暗号化手順を図１１のフローチャートを参照しながら説明する。
【０１４７】
まず削除開始位置より前の部分（ブロック１）がそのまま切り放され１つのブロックとなる（ステップＳ１）。次に、乱数発生などにより初期値ＩＶ１が決定され（ステップＳ２）、この初期値ＩＶ１を初期値としたＯＦＢ（もしくはＣＦＢ）モードにより削除部のデータ（ブロック２に対応する平文データ）が暗号化され、新たに１つのブロックになる（ステップＳ３）。さらに、別の初期値ＩＶ２が決定され（ステップＳ４）、後半部のデータが暗号化され新たな１つのブロックになる（ステップＳ５）。
【０１４８】
この手順では、先頭部分のブロックは初期値ＩＶ０がそのまま利用され、再暗号化の必要がない点に特徴がある。
【０１４９】
次に、本実施例の第２の暗号方式を説明する。第２の暗号方式の特徴は一切の再暗号化を必要としない点にある。この場合には８ビットＣＦＢモードを用いる。
【０１５０】
新規挿入ブロックについては、初期値ＩＶを乱数発生などにより発生し、ブロック・データは先頭から順番に１バイトずつ暗号化する。
【０１５１】
ブロック・データ分割時（図１０）の暗号化手順を図１２のフローチャートを参照しながら説明する。最初に個々の分割位置にて３つのブロックに切断する（ステップＳ１１）。次に、ブロック１の最後の８バイトをブロック２の初期値ＩＶとして保存する（ステップＳ１２）。さらに、ブロック２の最後の８バイトをブロック３の初期値ＩＶとして保存する（ステップＳ１３）。ステップ１２とステップ１３での初期値ＩＶの保存時の注意として、前のブロックが短くて８バイト未満の場合の対処が必要である。その場合には、前のブロックはそのブロックの初期値ＩＶ＋ブロック・データと考え、足りない分は初期値ＩＶから補えば良い。
【０１５２】
この手順は８ビットＣＦＢモードでは任意の位置から復号可能な性質を利用したものであり、ブロックの分割に伴う再暗号化がまったく不要になる利点がある。この利点はさらに、暗号化共有ファイルシステムをクライアント・サーバ・システムにて実現する場合にブロックの分割処理を暗号／復号機能を有しないサーバが実行可能となることを意味し、同システムの効率的な実現を可能にする。本手順を一般のＬビットＣＦＢモード（ただし、Ｌは８の倍数）に拡張することもできるが、そのためには補助的なデータが必要となる。これは、例えば図１０のブロック２が元のブロック０の先頭からＬビットずつの区切り目から始まらない場合があるためである。ブロック２のデータはブロック０の先頭からＬビットずつ暗号化されたデータとなっているため、元のＬビットずつの区切りが再現できるようにしなければならない。そこで、補助的なデータとしてブロックの先頭からｕ（ｕ≦Ｌの整数）ビット分が半端なブロックであることを表すものを用い、復号するときにはブロックデータの最初にダミーの（Ｌ−ｕ）ビットの暗号文を追加して復号を行い、復号結果の先頭の（Ｌ−ｕ）ビットを無視する。それにつながるデータは、Ｌビットずつ復号化すれは良い。また、ブロックの分割時の初期値ＩＶの保存は、前のブロックの最後の半端ビット（Ｌ−ｕビット）の直前の８バイトの内容とする。前のブロックが短い場合の処理は、８ビットＣＦＢモードの場合として説明したものと同様に、足りない部分を初期値ＩＶから補えば良い。
【０１５３】
以上、削除に伴うブロック分割を例として説明したが、挿入においては次のようになる。すなわち、既存ブロックの途中にあるブロックを挿入する場合には、先の図１１もしくは図１２の手順に相当する既存のブロックの分割と、新規挿入ブロック・データの暗号化が必要である。新規挿入部の暗号化は、まず乱数発生などにより初期値ＩＶを決定し、この初期値ＩＶを利用してＯＦＢ（もしくはＣＦＢ）モードにより暗号化する。また、既存ブロック同士の間にあるブロックを挿入する場合には、既存ブロックには何ら変更はなく、新規挿入ブロックだけを暗号化すれば良い。
【０１５４】
次に、本実施例のいくつかの履歴管理方式の特徴を整理する。ここで比較するのは図２に示した暗号化差分積み上げ方式による共有ファイル編集システムと図３に示した暗号化ＲＣＳ方式による共有ファイル編集システムと図４に示した暗号化ＳＣＣＳ方式による共有ファイル編集システムである。
【０１５５】
まず、ロックをかけない非同期編集機能に関しては、先に説明したように暗号化ＳＣＣＳ方式がマージ手続きが単純化できて有利である。
【０１５６】
次に、現行版の取り出しであるが、これは暗号化ＲＳＣ方式では現行版をそのままの形て暗号化データとして保管するためこれが最も有利である。暗号化ＳＣＣＳ方式はその次に有利であり、任意の版が同程度の処理で復元できる特徴がある。
【０１５７】
ファイル・サイズを圧縮するために古い履歴を消去したいことがあるが、この点に関しては、暗号化ＲＳＣ方式と暗号化ＳＣＣＳ方式が優れている。なぜなら、これらの方式ではそうした要求を受けたサーバが単独で履歴消去可能であるからである。暗号化差分積み上げ方式では、クライアントが関与することによって、古い履歴を消去できる。
【０１５８】
なお、注意すべき点として、暗号化ＳＣＣＳ方式の場合、古い履歴を消去してもブロックの融合を行う訳ではなく、不要なブロックの切り離し処理を行うだけであることがあげられる。ブロックの融合まで行う場合にはクライアントの関与が必要である。また、暗号化ＲＣＳ方式の場合には、サーバ単独で実行できるのは古い側の履歴から順番に消去することであることにも注意しなければならない。
【０１５９】
履歴内容は後になって変更したりできないように管理されることが好ましいが、この履歴内容の完全性に対しては、暗号化差分積み上げ方式が優れている。先にも説明したが、この方式では差分を追加していくことしかクライアントには許されていないため、履歴の完全性が保証できる。
【０１６０】
以上説明してきたように、上記２つの発明の一方または両方をファイル編集システムに適用することにより、（ａ）ファイルのバージョン管理をサポートする共有ファイル編集システムであって、ファイルの内容をファイル・サーバに対して秘密にしながら、非同期編集処理を行うことが可能となる共有ファイル編集システム、（ｂ）ファイルのバージョン管理をサポートする共有ファイル編集システムであって、非同期編集処理を行うことが可能な共有ファイル編集システム、（ｃ）ファイルの内容をファイル・サーバからは読み取ることのできない秘匿性の高いファイル編集システムを提供することができる。
【０１６１】
なお、以上では構造化されたファイルの暗号化において、クライアントだけが暗号化／復号化できるようにデータの内容は暗号化するが、データ構造に関してはサーバにも認識できる形式を示し、特にバージョン管理や非同期編集への応用を説明した。本発明は、他にも様々なシステムに応用可能であり、例えばプログラムを、サブルーチンごとに暗号化する方法や、ハイパーテキストなど複数のデータファイルがリンクで結び付けられている場合に個々のデータファイル単位で暗号化し、リンク部分は暗号化しない方法などに応用できる。このようにすれば、サーバに対してはモジュール内容の秘密性を保ちながら、クライアントが必要な部分だけ読み出して利用する効率的な利用ができる。
【０１６２】
次に、上述したサーバへのファイル内容秘匿機能（第１の発明）と非同期編集機能（第２の発明）をクライアント・サーバ型システムに実装してた本発明の第２実施例について説明する。
【０１６３】
まず、ファイルの構造、履歴管理方式、暗号化・復号化方式、非同期編集システムについては前述した第１実施例と同様のものを用いることを前提とする。これらについては、すでに詳細に説明したので、ここでは主に本実施例に特有の構成・動作について説明する。
【０１６４】
図１３には、本実施例の共有ファイル編集システムの第１構成例を示す。図１３のように、この共有ファイル編集システムは、複数のクライアント９１と、サーバ９０からなる。
【０１６５】
サーバ９０は、各クライアント９１と通信路１１１を介して通信を行うための通信部１３１、共有ファイル用履歴管理部５１０、複数のファイルを格納するためのデータ記憶部５１１を備えている。
【０１６６】
また、各クライアント９１は、サーバ９０と通信路１１１を介して通信を行うための通信部１３０、サーバ９０から得たファイルを格納するためのメモリ１２１、共有ファイル編集部１２２、暗号器１１２を備えている。
【０１６７】
図１４のように共有ファイル編集部１２２は、図５で説明した編集部５００、編集手続き生成部５０１、編集手続き変換部５０２、履歴管理情報生成部５０３を備えている。なお、サーバ９０の共有ファイル用履歴管理部５１０とデータ記憶部５１１は、図５における履歴管理部５１０とデータ記憶部５１１に相当する。
【０１６８】
図１５のように暗号器１１２は、共有ファイル編集部１２２と接続される通信部１３２、暗号化／復号化処理部１１２１、鍵記憶部１１２２を備えている。
【０１６９】
ここで、本実施例では、クライアント９１は複数であるために、
（ａ）特定バージョンのファイルデータの読み出し（図５での５１０から５００への矢印）、
（ｂ）編集結果である履歴管理情報の書き込み（図５での５０３から５１０への矢印）、
（ｃ）編集手続きの変換に必要な履歴データの読み出し（図５での５１０から５０２への矢印）
の各要求が様々なタイミングで発生する。
【０１７０】
以下これらの要求を処理する一般的な手順を説明する。
前述したように、１つの履歴管理情報に対応する編集手続きは複数に挿入と削除の組み合わせからなるが、これらを一纏めとして取り扱うことが望ましい。すなわち、あるクライアント９１があるバージョンのファイルに対し、複数箇所の変更を行った場合に、それらの変更がすべてサーバ９０側のデータに反映された時点で新規バージョンとする。履歴管理情報の書き込み要求は１つ１つが待ち行列（キュー）に入れられ、先入れ先出し方式（Ｆｉｒｓｔ−ｉｎ−Ｆｉｒｓｔ−ｏｕｔ）で順次履歴管理部５１０が取り出してファイル・データに反映していく。履歴管理部５１０はクライアント９１からの読み出し要求（先の（ａ），（ｃ））には随時応答するが、履歴管理部５１０があるファイルデータを更新中に同一ファイルの現行版の読み出し要求が来た場合には、更新前のバージョンを送信する必要がある。
【０１７１】
クライアント９１は最初のサーバ９０からあるバージョン（バージョンｘとする）のデータを要求し、メモリ１２１に格納した後、編集部５００にて編集を行い、編集手続き生成部５０１にて編集手続きデータを生成する。バージョンｘが、読み出し時点における最新版であった場合には、編集手続きは変換せずに履歴管理情報を生成し、暗号化してサーバ９０に送信する。受け取ったサーバ９０側ではその時点での最新版にマージ可能な履歴管理情報であるか否かを判定し、マージ不可能な場合には共有ファイル用履歴管理部５１０から履歴データをクライアント９１に送信し、編集手続き変換部５０２による編集手続きの変換を要求する。
【０１７２】
ここで、マージ可能か不可能かの判断は例えば、クライアント９１側で送信する履歴管理情報のヘッダに対象としたデータのバージョン番号をつけるようにし、サーバ９０側では保存している最新版の番号とヘッダの番号を比較して一致していればマージ可能、一致していなければマージ不可能と判断すれば良い。さらに、マージ不可能な場合にクライアント９１に送信する履歴データは、例えば履歴管理情報のヘッダに含まれるバージョン番号と最新のバージョンとの間の履歴データである。クライアント９１では、所定の編集手続きの変換を実施し、新たに履歴管理情報を生成する。これを再びサーバ９０に送り、サーバ９０側では再度マージ可能性を判定する。
【０１７３】
ここで、再びマージ不可能である可能性がある。すなわち、クライアント９１での編集手続きの変換処理の間に、他のクライアントによりファイルのバージョンが更新された場合ある。従って、図５の５１０→５０２→５０３のループを何度も回る可能性がある。
【０１７４】
このような処理の繰り返しを防ぐためにロック機能を利用することも考えられる。すなわち、履歴データをクライアントに送出した時点でサーバ側がファイルデータの更新にロックを掛け、そのクライアントからの履歴管理情報を受信してファイルデータの更新が終わった時点でロックを解除するようにする。ロックがかかっている間は編集対象ファイルデータの読み出しは許可するが、それ以外の処理はサーバ９０側でリジェクトする。リジェクトされたクライアント９１は適当な時間を置いてリトライする。なお、このロック機構による待ち時間は極めて短いものと考えられる。このロック機構は、必ずしも必要ではない。
【０１７５】
一方、最初にサーバ９０から読み出したバージョンｘが読み出し時点での最新版でない場合には、編集手続き変換部５０２での処理のために、サーバ９０に対してバージョンｘから最新版までの履歴データを要求する。後の処理は先に説明したものと同じである。
【０１７６】
以上の手順において、クライアント９１が受信する編集対象ファイルと履歴データ、およびサーバ９０に送る履歴管理情報はすべて構造ごとに暗号化されたデータであり、その暗号化／復号化に暗号器１１２を利用する。
【０１７７】
このように、本実施例では、ファイルの内容は復号鍵を持っている正規のクライアントからのみ読み取れ、ファイルの内容をサーバからは読み取ることのできないようにした秘匿性の高いファイル編集システムを提供することができる。
【０１７８】
また、サーバでは、常に各クライアントによる編集終了時における最新バージョンのファイル内容にに対する更新が行われるので、ロックを掛けずに複数のクライアントによる非同期編集行うことが可能となる。
【０１７９】
また、時間的に古いバージョンを編集し、最新バージョンとする使い方が可能となる。すなわち、非同期編集可能な共有ファイルにおいて、編集対象を現行版に限定しない使い方が可能となる。
【０１８０】
また、非同期編集による編集結果のマージ処理を実行する場合に、サーバからはクライアントでの処理に必要となるデータのみを送り、クライアントで必要な処理を実行してサーバに返す形式を実現でき、不必要な履歴に関する部分まで通信されるなどの無駄がなくなり、効率が著しく向上する。
【０１８１】
また、ファイルのデータ構造として、単純に一つ前（あるいは後）のバージョンとの差分を残していくＲＣＳのような構造ではなく、ＳＣＣＳで利用されているようなファイルの先頭から順番に挿入されたデータが挿入された位置にブロックとして管理され、部分的に消去された場合にはブロックの分割を繰り返していく方式を採用すると、マージ処理に必要となる挿入／削除の位置の決定が極めて単純化され、非同期編集が容易となる。
【０１８２】
さらに、先に説明したマージ処理に適したＳＣＣＳのようなデータ構造を採用した場合のデータ内容の暗号化方式として、ビット単位（あるいはバイト単位）のストリーム暗号を利用することができる。このストリーム暗号は平文の特定ビット（あるいはバイト）が暗号文の特徴ビット（あるいはバイト）に対応する性質がある。このため、先のような暗号化されたブロックの分割が繰り返される場合に、分割されるポイントより後ろを切りとり、その部分だけ暗号化しなおせばよく、再暗号化のオーバヘッドが軽減される。さらに、サーバ側で分割ポイントより前の部分が変更されていないことを確認することもできる。
【０１８３】
以上に説明した共有ファイル編集システム（第１の発明と第２の発明の両方を適用したもの）では、先に示したように図５での５１０→５０２→５０３のループが存在した。以下では、そのループを解消する一実施例を説明する。
【０１８４】
本実施例では、ファイルのデータ構造としては、図４の変形ＳＣＣＳ方式を用い、暗号方式としては、ストリーム暗号のうち８ビットのＣＦＢモードによる方式を用いる。この暗号方式には先に説明したようにブロックの分割においても再暗号化が不要な特徴がある。
【０１８５】
図１６には、本実施例の共有ファイル編集システムの第２構成例を示す。図１６のように、この共有ファイル編集システムは、複数のクライアント２１１と、サーバ２１０からなる。
【０１８６】
サーバ２１０は、各クライアント２１１と通信路１１１を介して通信を行うための通信部２３１と、図５で説明した編集手続き変換部５０２、履歴管理部５１０および複数のファイルを格納するためのデータ記憶部５１１を備えている。なお、この編集手続き変換部５０２は、図５の履歴管理情報生成部５０３の機能も含んだものとする。
【０１８７】
各クライアント２１１は、サーバ２１０と通信路１１１を介して通信を行うための通信部２３０、サーバ２１０から得たファイルを格納するためのメモリ２２１、共有ファイル編集部２２２、暗号器２１２を備えている。図１７のように、クライアント２１１の共有ファイル編集部２２２は、図５で説明した編集部５００および編集手続き生成部５０１を備えている。
【０１８８】
ここで、本実施例では、クライアント２１１は複数であるために、
（ａ）特定バージョンのファイルデータの読み出し（図５での５１０から５００への矢印）、
（ｂ）編集結果を変換した編集手続きデータの書き込み（図５での５０１から５０２への矢印）、
の各要求が様々なタイミングで発生する。
【０１８９】
以下これらの要求を処理する手順の一例を説明する。
クライアント２１１は、最初にサーバ２１０からあるバージョンのデータを要求する。そのバージョンのデータを復号し、メモリ２２１に格納した後、編集部５００にて編集を行い、編集手続き生成部５０１にて編集手続きデータを生成する。ここでの編集手続きデータは、挿入データと削除データの２つである。挿入データは、挿入位置（例えば先頭位置からのバイト数）と挿入ブロック内容の組からなり、削除データは削除開始位置と削除終了位置の組からなる。
【０１９０】
クライアント２１１は、挿入ブロック内容に関しては、初期値ＩＶを生成し、８ビットＣＦＢモードで暗号化する。他のデータ（挿入位置や削除範囲など）は暗号化せずに、暗号化挿入ブロック内容とまとめてサーバ２１０に送る。
【０１９１】
これを受け取ったサーバ２１０では、まず編集手続き変換部５０２にて、挿入位置と削除範囲をその時点での最新版に対する位置データに変換（位置変換）する。次に、履歴管理部５１０にて、挿入位置にはクライアントから送信された暗号化挿入ブロックを配置し、削除範囲ではブロックの分割と消去時点フィールドの記入を行う。以上の結果を最新版とする。
【０１９２】
この手順の中で、暗号化した状態で編集手続きの変換が可能なことがポイントであり、そのために先の一般方式における編集手続き変換のための（前述したような）ループが解消される。暗号化した状態で編集手続きの変換を可能にするファイルのデータ構造と暗号方式として、変形ＳＣＣＳ方式と８ビットＣＦＢモードの組み合わせが挙げられる。他の暗号方式、特にブロック分割の場合に最初のブロックだけは再暗号化を不要にするＬビットＯＦＢモードやＬビットＣＦＢモードのような方式でも同様の効果を得ることができるが、クライアントからサーバに送る編集手続きデータは、ここに示したデータよりも余分なものが必要となる。
【０１９３】
このように、本実施例では、ファイルの内容は復号鍵を持っている正規のクライアントからのみ読み取れ、ファイルの内容をサーバからは読み取ることのできないようにした秘匿性の高いファイル編集システムを提供することができる。
【０１９４】
また、サーバでは、常に各クライアントによる編集終了時における最新バージョンのファイルの内容に対する更新か行われるので、ロックを掛けずに複数のクライアントによる非同期編集を行うことが可能となる。
【０１９５】
尚、上述した図１３と図１６の構成例を要部についてまとめると各々図１８，図１９に示すような構成であると考えられる。
【０１９６】
図１８の構成では、ブロック識別情報はクライアント９１側の履歴管理情報生成手段５０３によりクライアント９１からサーバ９０に送る履歴管理情報に付加されても良い。この場合、ブロック識別情報は暗号化されず履歴管理情報が暗号器１１２で暗号化されるので、サーバ９０は暗号化されておらず従ってサーバ９０側で認識可能なブロック識別情報に基づいて履歴管理情報が示す新しいブロックデータを管理できるが、暗号化されている履歴管理情報のデータ内容はサーバ９０側では認識不可能である。
【０１９７】
これに代えて、ブロック識別情報をクライアント９１からサーバ９０に送る履歴管理情報に付加しないようにしても良い。この場合、履歴管理情報が示す新しいブロックデータに適当なブロック識別情報はサーバ９０側の履歴管理部５１０で付加できる。
【０１９８】
図１９の構成では、編集手続きデータのみがクライアント２１１からサーバ２１０へ送られ、この編集手続きデータに基づいて得られる新しいブロックデータを同定するブロック識別情報はサーバ２１０側の履歴管理情報生成部５０３か履歴管理部５１０により付加される。ここでは、挿入データ内容のみが暗号器２１２で暗号化され、編集手続きデータの他の部分は暗号化されないので、サーバ２１０側の編集手続き変換部５０２はこれらの暗号化されておらず従ってサーバ２１０側で認識可能な編集手続きデータの他の部分と履歴管理部５１０から与えられる履歴データとに基づいて編集手続きデータの変換を行える。
【０１９９】
この図１９の構成を変形して、編集手続き変換部５０２をクライアント２１１側に、編集手続き生成部５０１と暗号器２１２の間に設けるようにして、図１８と図１９の折衷形とすることも可能である。この場合、変換後の編集手続きデータのみがクライアント２１１からサーバ２１０へ送られ、この変換後の編集手続きデータに基づいて得られる新しいブロックデータを同定するブロック識別情報はサーバ２１０側の履歴管理情報生成部５０３か履歴管理部５１０により付加される。ここでは、変換後の挿入データ内容のみが暗号器２１２で暗号化され、変換後の編集手続きデータの他の部分は暗号化されないので、サーバ２１０側の履歴管理情報生成部５０３はこれらの暗号化されておらず従ってサーバ２１０側で認識可能な変換後の編集手続きデータの他の部分に基づいて履歴管理情報の生成を行える。
【０２００】
さて、上述した２つの発明は独立実施可能である。以下で、一方の発明だけを適用した実施例を夫々説明する。
【０２０１】
最初に、上述した非同期編集機能（第２の発明）をクライアント・サーバ型システムに実装した本発明の第３実施例について説明する。
【０２０２】
まず、ファイルの構造、履歴管理方式、非同期編集システムについては前述した第１実施例と同様のものを用いることを前提とする。これらについては、すでに詳細に説明したので、ここでは、主に本実施例に特有の構成・動作について説明する。
【０２０３】
図２０は、本実施例の共有ファイル編集システムの構成を示す。図２０のように、この共有ファイル編集システムは、複数のクライアント７０１と、サーバ７１０からなる。
【０２０４】
サーバ７１０は、各クライアント７０１と通信路１１１を介して通信を行うための通信部７３１、マージ処理部７４０、複数のファイルを格納するためのデータ記憶部７１１を備えている。
【０２０５】
また、各クライアント７０１は、サーバ７１０と通信路１１１を介して通信を行うための通信部７３０、サーバ７１０から得たファイルを格納するためのメモリ７２１、共有ファイル編集部７２２を備えている。
【０２０６】
図２１のように、クライアント７０１の共有ファイル編集部７２２は、図５で説明した編集部５００、編集手続き生成部５０１を備えている。
【０２０７】
また、図２２のように、サーバ７１０のマージ処理部７４０は、図５で説明した編集手続き変換部５０２、履歴管理情報生成部５０３、共有ファイル用履歴管理部５１０を備えている。なお、サーバ７１０のデータ記憶部５１１は、図５におけるデータ記憶部５１１に相当する。
【０２０８】
ここで、本実施例では、クライアント７０１は複数であるために、
（ａ）特定バージョンのファイルデータの読み出し（図５での５１０から５００への矢印）、
（ｂ）編集結果を変換した編集手続きデータの書き込み（図５での５０１から５０２への矢印）、
の各要求が様々なタイミングで発生する。
【０２０９】
以下、これらの要求を処理する手順の一例を説明する。
【０２１０】
この場合、クライアント７０１はサーバ７１０から特定のバージョンのファイルデータを要求し、ファイルをメモリ７２１に格納した後、編集部５００にて編集を行い、編集手続き生成部５０１にて編集手続きデータに変換し、それをサーバ７１０に送る。
【０２１１】
サーバ７１０側では、１つ１つの編集手続きデータをキューに入れ、マージ処理部７４０が順次取り出して履歴に変換して保存していく。先の暗号機能付きの装置の実施例の場合との違いは、サーバ７１０単独で最新版に対する編集手続きデータに変換可能であることにある。すなわち、クライアント７０１の編集手続きデータと履歴データから編集手続きの変換を実施した後に履歴として保存する。従って、図５での５１０→５０２→５０３のループは存在しないため、ループの繰り返しを防ぐ目的でのロック機能は必要としない。
【０２１２】
また、クライアント７０１側に設ける共有ファイル編集部７２２の機能も少なくて済む。
【０２１３】
ただし、前述したサーバへのファイル内容秘匿機能を有する実施例の場合のように、編集手続き変換部５０２および履歴管理情報生成部５０３をクライアント７０１側に設ける構成を採用することは可能である。この場合の各部の動作は自明であるので、詳細な説明は省略する。また、クライアント７０１に設ける共有ファイル編集部７２２の機能のうち、さらに編集手続き生成部５０１をサーバ７１０側へ移すことも可能である。
【０２１４】
このように、本実施例によれば、サーバでは、常に各クライアントによる編集終了時における最新バージョンのファイル内容に対する更新が行われるので、ロックを掛けずに複数のクライアントによる非同期編集を行うことが可能となる。
【０２１５】
また、時間的に古いバージョンを編集し、最新バージョンとする使い方が可能となる。すなわち、非同期編集可能な共有ファイルにおいて、編集対象を現行版に限定しない使い方が可能となる。
【０２１６】
また、非同期編集による編集結果のマージ処理を実行する場合に、サーバからはクライアントでの処理に必要となるデータのみを送り、クライアントで必要な処理を実行してサーバに返す形式を実現でき、不必要な履歴に関する部分まで通信されるなどの無駄がなくなり、効率が著しく向上する。
【０２１７】
また、ファイルのデータ構造として、単純に一つ前（あるいは後）のバージョンとの差分を残していくＲＣＳのような構造ではなく、ＳＣＣＳで利用されているようなファイルの先頭から順番に挿入されたデータが挿入された位置にブロックとして管理され、部分的に消去された場合にはブロックの分割を繰り返していく方式を採用すると、マージ処理に必要となる挿入／削除の位置の決定が極めて単純化され、非同期編集が容易となる。
【０２１８】
次に、上述したサーバへのファイル内容秘匿機能（第１の発明）をクライアント・サーバ型システムに実装した本発明の第４実施例について説明する。
【０２１９】
まず、本実施例で扱うファイルは、複数のブロック・データおよびブロック識別情報を含み、かつ、各ブロック・データはブロック・データ単位で暗号化されている。例えば、図２、図３、図４にそれぞれ示したような構造であるが、これらに限らず、例えばプログラムを、サブルーチンごとに暗号化する方法や、ハイパーテキストなど複数のデータファイルがリンクで結び付けられている場合に個々のデータファイル単位で暗号化し、リンク部分は暗号化しない方法などに応用できる。このようにすれば、サーバに対してはモジュール内容の秘密性を保ちながら、クライアントが必要な部分だけ読み出して利用する効率的な利用ができる。
【０２２０】
また、本実施例では、上記構造を有するファイルに対して、前述したような暗号化・復号化方式を用いることを前提とする。
【０２２１】
図２３は、本実施例のファイル編集システムの構成を示す。このように、本実施例のファイル編集システムは、クライアント８０１と、サーバ８１０からなる。
【０２２２】
サーバ８１０は、クライアント８０１と通信路１１１を介して通信を行うための通信部８３１、データ管理部８４０、複数のファイル１１３を格納するためのデータ記憶部５１１を備えている。
【０２２３】
また、クライアント８０１は、サーバ８１０と通信路１１１を介して通信を行うための通信部８３０、サーバ８１０から得たファイル１１３を格納するためのメモリ８２１、ファイル編集部８２２、暗号器８１２を備えている。暗号器８１２は、図２４のように共有ファイル編集部８２２と接続される通信部８３２、暗号化／復号化処理部８１２１、鍵記憶部８１２２を備えている。
【０２２４】
上記構成において、クライアント８０１はサーバ８１０からあるバージョンのデータを要求し、メモリ８２１に格納した後、ファイル編集部８２２にて編集を行う。その際、前述のようにファイルはブロック・データごとに暗号化されているので、鍵記憶部８１２２に登録してある復号鍵を用いて、暗号化／復号化処理部８１２１にて復号化しておく。ファイルの編集が終了したら、鍵記憶部８１２２に登録してある暗号鍵を用いて、暗号化／復号化処理部８１２１にて暗号化した後、サーバ８１０に送り、データ管理部８４０にてデータ記憶部５１１のファイルが更新される。
【０２２５】
このように、本実施例では、ファイルの内容をサーバからは読み取ることのできない秘匿性の高いファイル編集システムを提供することができる。
【０２２６】
また、クライアントは、ファイルのうちの必要なデータ・ブロックだけを通信により取得できるので、通信量の削減を図ることができるとともに、必要なブロックだけを復号化／暗号化すれば良いので、クライアント装置での処理量の削減、クライアント装置で必要なバッファ（メモリ）の削減ができる利点もある。
【０２２７】
ここで、本実施例に、上述したような履歴管理方式を適用することができる。以下、そのような例について説明する。
【０２２８】
この場合に扱うファイルの構造は、図２、図３、図４にそれぞれ示したようなものを採用する。また、上記構成を有するファイルに対して、前述したような暗号化・復号化方式を用いる。
【０２２９】
ここでは、非同期編集は行わないことから、図５の非同期編集システムの編集手続き変換部５０２を削除して編集手続き生成部５０１と履歴管理情報生成部５０３を直結し、履歴管理部５１０をデータ記憶部５１１を管理する機能だけを有するデータ管理部８４０とする修正を施したものを履歴管理システムとして、これをファイル編集部８２２とデータ管理部８４０とに分散配置する。
【０２３０】
分散配置は、クライアント８０１のファイル編集部８２２に編集部５００を実装し、サーバ８１０にデータ管理部８４０およびデータ記憶部５１１を実装すれば、他はどのような形で分散配置することも可能である。
【０２３１】
ここでは好ましい態様として、図２３のようにサーバ８１０にデータ管理部８４０およびデータ記憶部５１１を実装し、他をクライアント８０１に実装したものを示してある。
【０２３２】
上記構成において、クライアント８０１はサーバ８１０からあるバージョンのデータを要求し、メモリ８２１に格納した後、編集部５００にて編集を行う。その際、前述のようにファイルはブロック・データごとに暗号化されているので、鍵記憶部８１２２に登録してある復号鍵を用いて、暗号化／復号化処理部８１２１にて復号化しておく。ファイルの編集が終了したら、編集手続き生成部５０１にて編集手続きデータを生成する。そして、その編集手続きデータを履歴管理情報生成部５０３にて、利用している履歴管理法に適した形式の履歴情報に変換する。ここで、この履歴情報を鍵記憶部８１２２に登録してある暗号鍵を用いて、暗号化／復号化処理部８１２１にて暗号化した後、サーバ８１０に送り、データ管理部８４０にてデータ記憶部８１１のファイルが更新される。
【０２３３】
このように、ファイルのバージョン管理とファイル管理装置に対するデータの秘匿性を同時に実現できる。
【０２３４】
また、ファイルの構造として図２の差分積み上げ方式による構造を採用した場合、履歴の完全性をファイル管理装置側だけで保証できる。
【０２３５】
また、ファイルの構造として図３のＲＣＳ方式による構造を採用した場合、ファイルのバージョン管理において、現行バージョンのファイルの取り出しおよび古い履歴の消去が容易となる。
【０２３６】
また、ファイルの構造として図４のＳＣＣＳ方式による構造を採用した場合、ファイルのバージョン管理において、古い履歴の消去が容易となる。
【０２３７】
また、暗号として、前述したストリーム暗号を用いる場合、ブロックの分割時の暗号化に際し、ブロックの先頭から分割ポイントまでの部分は暗号化されたままで再利用でき、分割ポイント以降のみを再暗号化する。なお、全く再暗号化を必要としない方法もある。これは、ＳＣＣＳに代表されるブロックの分割が繰り返される場合に有利である。
【０２３８】
次に、図１３、図１６、あるいは図２０を用いて説明した非同期編集機能を有する共有ファイル編集システムにおいて、あるファイルのあるバージョンの消去要求が発行されても、当該ファイルの当該バージョンを編集中であるクライアントが存在しなくなるまで消去実行を遅延させる機能を設けた本発明の第５実施例の共有ファイル編集システムについて説明する。
【０２３９】
履歴管理を行うシステムにおいては、履歴中の一部のバージョンを消去する機能を提供することが考えられる。バージョンの消去は、例えばクライアントが消去コマンドを実行するとこによって行われる場合や、作成から一定時間以上経過したバージョンをシステムが自動的に消去する場合などが考えられる。
【０２４０】
本発明に係る非同期編集機能を有する共有ファイル編集システムにおいては、バージョンを消去する場合には、消去対象となっているバージョンを編集しているクライアント装置が存在していてはならない。なぜならば、このシステムでは、ファイル管理サーバはマージ処理（クライアントがアクセスしたバージョンがいずれであるかに従い、ファイル管理サーバ内での最新のバージョンに変換する処理）を行うからである。もし、いずれかのクライアントが当該バージョンを編集途中に、そのバージョンを消去してしまったとすると、マージ処理が不可能になってしまう。
【０２４１】
本実施例では上記機能を実現するために、ファイル管理サーバ内に、その管理する各々のファイルの各々のバージョン毎に対応付けて、当該ファイルの当該バージョンを編集中であるクライアントの数を計数する手段を設ける。これによりファイル管理サーバは、各々のファイルの各々のバージョンについて、それを編集途中であるクライアントが存在するかどうかを判断することができる。すなわち、指定されたファイルの指定されたバージョンに対応する計数値が０であるならば、それを編集途中であるクライアントは存在せず、また、計数値が０でないならば、それを編集途中であるクライアントが存在すると判断できる。
【０２４２】
そして、本実施例のファイル管理サーバは、ファイルのバージョンを消去する要求が発行された際、該計数値が０でない場合には、０に等しくなるまで消去の実行を遅延する手段を有する。これによりファイル管理サーバは、消去の対象となったファイルのバージョンを編集途中のクライアントが存在する間は、該ファイルの該バージョンを消去することがなくなるので、マージ処理の実行に支障をきたすおそれがなくなる。
【０２４３】
以下、前述の図１３の実施例を基にして、上記機能を設けた共有ファイル編集システムについて説明する。
【０２４４】
図２５は、図１３の実施例に、上記のようなクライアント数を計数する手段を設けた実施例である。図中のアクセス要求者９１、通信路１１１は、図１３の実施例と同様の構成である。ファイル管理サーバ９５は、クライアント計数部９００が加わっている点が図１３と異なる。
【０２４５】
図２６に示すように、クライアント計数部９００は、分岐部９０１、編集開始処理部９０２、消去要求処理部９０３、編集終了処理部９０４、計数記憶部９０５、消去命令発行部９０６を用いて構成される。
【０２４６】
このクライアント計数部９００の機能の概略は、ファイル管理サーバ９５が管理する各々のファイルの各々のバージョン毎に対応付けて、何個のクライアントがそのファイルのそのバージョンを編集中であるかを数えることと、あるクライアントによりあるファイルのあるバージョンを消去する要求が発行された際、その計数値が０でない場合には、０に等しくなるまで消去の実行を遅延することである。
【０２４７】
クライアント計数部９００内部の計数記憶部９０５の基本的な役割は、各々のファイルの各々のバージョンそれぞれに対して、計数値（整数）と消去遅延フラグ（１ビットの真偽値）を対応付けて記憶することである。計数値は、何個のクライアントが対応するファイルの対応するバージョンを編集中であるかを数えるカウンタであり、消去遅延フラグは、計数値が０でなかったために消去の実行が遅延されていることを示すフラグである。
【０２４８】
計数記憶部９０５に記憶されているデータのデータ構造の一例を、図２７に示す。データ構造は、二段階に構成された配列になっている。第一段階目の配列は、ファイル識別子に対して第二段回目の配列を対応付けるものであり、ファイル識別子とアドレスの対を一要素として、それらの配列になっている。第二段階目の配列は、ファイルの各々のバージョンに関する計数値と消去遅延フラグを保持するもので、計数値と消去遅延フラグの対を一要素とする配列となっている。この配列においては、バージョン番号を配列のインデクスとして参照する。したがって例えば、図２７のＣ１１，Ｃ１２，Ｃ１３は、ファイルＩＤ１のファイルのそれぞれバージョン番号１，２，３のバージョンの計数値、また、Ｆ１１，Ｆ１２，Ｆ１３は、ファイルＩＤ１のファイルのそれぞれバージョン番号１，２，３のバージョンの消去遅延フラグの値を表している。なお、計数値の初期値は０、消去遅延フラグの初期値はｆａｌｓｅ（を示す値；例えば０）である。
【０２４９】
本実施例においては、クライアント９１は、ファイルの編集を開始する直前に、ファイル管理サーバ９５に対して、編集開始宣言を行う。この編集開始宣言は、例えば通信路１１１を通してクライアント９１からファイル管理サーバ９５に対して、編集開始宣言であることを示すコマンドワードに続けて編集しようとするファイルの識別子および編集しようとするバージョンのバージョン番号を送信することにより行われる。
【０２５０】
ファイル管理サーバ９５によって受け取られた通信データは、分岐部９０１に入力される。
【０２５１】
分岐部９０１では、例えば通信データの初めの１ワードを読み、それが編集開始宣言を示すコマンドワードであることを判定すると、通信データ中の続くファイルＩＤおよびバージョン番号を編集開始処理部９０２に入力する。
【０２５２】
編集開始処理部９０２では、分岐部９０１からの入力を受けると、計数記憶部９０５にアクセスして、指定されたファイルＩＤの指定されたバージョンに対応する計数値を１つ増加させる。
【０２５３】
一方、上記通信データは、そのままあるいはファイルの識別子およびバージョン番号などが加工しなおされて、分岐部９０１から共有ファイル用履歴管理部５１０に与えられる。そして、上記のように編集開始宣言が処理された後、クライアント９１によるファイルの編集が行われる。このときのファイル編集の機構は、前述の図１３の実施例のときと同様にして行われる。
【０２５４】
次に、ファイルのバージョンを消去する際の処理機能について説明する。本実施例においては、バージョンの消去要求もまた、通信路１１１を通してクライアント９１からファイル管理サーバ９５に対して、バージョン消去要求であることを示すコマンドワードに続けて消去しようとするファイルの識別子および消去しようとするバージョンのバージョン番号を送信することにより行われる。
【０２５５】
ファイル管理サーバ９５によって受け取られた通信データは、分岐部９０１に入力される。分岐部９０１では、通信データの初めの１ワードを読み、それがバージョン消去要求を示すコマンドワードであることを判定すると、通信データ中の続くファイルＩＤおよびバージョン番号を消去要求処理部０９０３に入力する。
【０２５６】
消去要求処理部９０３では、分岐部９０１からの入力を受けると、図２８のフローチャートに示す手順により処理を行う。
【０２５７】
消去要求処理部９０３はまず、計数記憶部９０５にアクセスして、指定されたファイルＩＤの指定されたバージョン番号に対応する計数値を得る（ステップＳ２１）。次に、その計数値の値か０であるかどうかにより条件分岐を行う（ステップＳ２２）。計数値が０である場合には、履歴管理部５１０に対して指定されたファイルＩＤの指定されたバージョンを消去する命令を消去命令発行部９０６から発行する（ステップＳ２３）。また、計数値が０でない場合には、計数記憶部９０５にアクセスして、指定されたファイルのＩＤの指定されたバージョン番号に対応する消去遅延フラグをｔｒｕｅ（を示す値；例えば１）にする（ステップＳ２４）。
【０２５８】
次に、編集終了時の処理について説明する。本実施例においては、クライアント９１は、ファイルの編集を終了した直後に、ファイル管理サーバ９５に対して、編集終了宣言を行う。この編集終了宣言は、通信路１１１を通してクライアント９１からファイル管理サーバ９５に対して、編集終了宣言であることを示すコマンドワードに続けて編集を終了しようとするファイルの識別子および編集を終了しようとするバージョンのバージョン番号を送信することにより行われる。
【０２５９】
ファイル管理サーバ９５によって受け取られた通信データは、分岐部９０１に入力される。分岐部９０１では、通信データの初めの１ワードを読み、それが編集終了宣言を示すコマンドワードであることを判定すると、通信データ中の続くファイルＩＤおよびバージョン番号を編集終了処理部９０４に入力する。なお、必要に応じて、上記通信データは、そのままあるいはファイルの識別子およびバージョン番号などが加工しなおされて、分岐部９０１から共有ファイル用履歴管理部５１０に与えられる。
【０２６０】
編集終了処理部９０４では、図２９のフローチャートに示す手順により処理を行う。
【０２６１】
編集終了処理部９０４の処理手順ではまず、計数記憶部９０５にアクセスして、指定されたファイルＩＤのファイルの指定されたバージョン番号に対応する計数値Ｃと消去遅延フラグＦの値を得る（ステップＳ３１）。次に、計数値Ｃの値を１減らす（ステップＳ３２）。次に、計数値Ｃを計数記憶部９０５に保存する（ステップＳ３３）。次に、計数値Ｃの値が０であるかどうかにより条件分岐を行う（ステップＳ３４）。計数値が０でない場合には、編集終了処理部９０４の処理を終了する。計数値が０である場合には、次に消去遅延フラグＦの値より条件分岐を行う（ステップＳ３５）。消去遅延フラグＦの値がｆａｌｓｅである場合には、編集終了処理部９０４の処理を終了する。消去遅延フラグＦの値がｔｒｕｅである場合には、履歴管理部５１０に対して指定されたファイルＩＤの指定されたバージョンを消去する命令を消去命令発行部９０６から発行する（ステップ３６）。
【０２６２】
なお、分岐部９０１では通信データの初めの１ワードを読み、それが上記した編集開始宣言、バージョン消去要求、編集終了宣言を示すコマンドワード以外のものであることを判定すると、通信データをそのまま共有ファイル用履歴管理部５１０に入力する。
【０２６３】
次に、履歴管理部５１０における消去命令の実行処理の例について述べる。消去命令の処理手順は、履歴管理部５１０が差分積み上げ、ＲＣＳ、変形ＳＣＣＳのいずれの管理方法をとっているかによって異なるものであり、以下ではそれら３方式について夫々一例を説明する。
以下の説明においては、次に示す記号を用いる。
ｒ：消去対象のバージョン番号
ｆ：対象となっているファイルの履歴のうちで、履歴管理部５１０が保持している最も古いバージョンのバージョン番号（多くの場合，ｆ＝１であるが、過去にバージョンの消去命令によってバージョン１が消去されている場合には、ｆは１でない値になる。）
ｎ：対象となっているファイルの履歴のうちで、履歴管理部５１０が保持している最も新しいバージョン（すなわち現行版）のバージョン番号
ｐ（ｘ）：履歴管理部５１０が保持しているバージョンのうちで、バージョンｘの１つ前のバージョンのバージョン番号（多くの場合，ｐ＝ｘ−１であるが、過去にバージョンｘ−１が消去された場合には、ｐ＝ｘ−２に、さらにバージョンｘ−２が消去された場合には、ｐ＝ｘ−３に等々、順次前のバージョンになる。）
ｓ（ｘ）：履歴管理部５１０が保持しているバージョンのうちで、バージョンｘの１つ後のバージョンのバージョン番号（多くの場合，ｓ＝ｘ＋１であるが、過去にバージョンｘ＋１が消去された場合には、ｓ＝ｘ＋２に、さらにバージョンｘ＋２が消去された場合には、ｓ＝ｘ＋３に等々、順次後のバージョンになる。）
Ｖ［ｘ］：バージョンｘ（の内容）
Ｖ［ｘ］−Ｖ［ｙ］：バージョンｘとバージョンｙとの差分
【０２６４】
まず、履歴管理部５１０が差分積み上げ方式により履歴管理を行っている場合について説明する。図３０には、この消去命令の実行処理手順を示す。
ｉ）消去対象が履歴の最初のバージョンや現行版でない場合（ステップＳ４１，Ｓ４５にてｒ≠ｆかつｒ≠ｎの場合）
・消去対象バージョンの前のバージョン（Ｖ［ｐ（ｒ）］）および後のバージョン（Ｖ［ｓ（ｒ）］）を復元し（ステップＳ４７）、それらの２つのバージョンの差分（Ｖ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］）を生成し（ステップＳ４８）、消去対象バージョンの前後の差分（Ｖ［ｓ（ｒ）］−Ｖ［ｒ］）および（Ｖ［ｒ］−Ｖ［ｐ（ｒ）］）をＶ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］と置換する（ステップＳ４９）。
【０２６５】
ｉｉ）消去対象が履歴の最初のバージョンである場合（ステップＳ４１にてｒ＝ｆの場合）
・消去対象の次のバージョン（Ｖ［ｓ（ｒ）］）を復元し（ステップＳ４２）、履歴の最初のバージョン（Ｖ［ｒ］）およびそれと次のバージョンの差分（Ｖ［ｓ（ｒ）］−Ｖ［ｒ］）を消去し（ステップＳ４３）、Ｖ［ｓ（ｒ）］を新たに履歴の最初バージョンとする（ステップＳ４４）。
【０２６６】
ｉｉｉ）消去対象が履歴の最後のバージョン（現行版）である場合（ステップＳ４５にてｒ＝ｎである場合）
・そのバージョンと前のバージョンとの差分（Ｖ［ｒ］−Ｖ［ｐ（ｒ）］）を消去する（ステップＳ４６）。
【０２６７】
次に、履歴管理部５１０がＲＣＳ方式により履歴管理を行っている場合について説明する。図３１には、この消去命令の実行処理手順を示す。
ｉ）消去対象が履歴の最初のバージョンや現行版でない場合（ステップＳ６１，Ｓ６５にてｒ≠ｆかつｒ≠ｎの場合）
・消去対象バージョンの前のバージョン（Ｖ［ｐ（ｒ）］）および後のバージョン（Ｖ［ｓ（ｒ）］）を復元し（ステップＳ６７）、それらの２つのバージョンの差分（Ｖ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］）を生成し（ステップＳ６８）、消去対象バージョンの前後の差分（Ｖ［ｐ（ｒ）］−Ｖ［ｒ］）および（Ｖ［ｒ］−Ｖ［ｓ（ｒ）］）をＶ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］と置換する（ステップＳ６９）。
【０２６８】
ｉｉ）消去対象が履歴の最初のバージョンである場合（ステップＳ６１にてｒ＝ｆの場合）
・そのバージョンと前のバージョンとの差分（Ｖ［ｒ］−Ｖ［ｓ（ｒ）］）を消去する（ステップＳ６２）。
【０２６９】
ｉｉｉ）消去対象が履歴の最後のバージョン（現行版）である場合（ステップＳ６３にてｒ＝ｎである場合）
・現行版の１つ前のバージョン（Ｖ［ｐ（ｒ）］）を復元し（ステップＳ６４）、現行版と１つ前のバージョンとの差分（Ｖ［ｐ（ｒ）］−Ｖ［ｒ］）を消去し（ステップＳ６５）、Ｖ［ｐ（ｒ）］を新たに現行版とする（ステップＳ６６）。
【０２７０】
次に、履歴管理部５１０が変形ＳＣＣＳ方式で履歴管理を行っている場合の消去処理の実施例について説明する。図３２には、この消去命令の実行処理手順を示す。尚、図３２のフローチャートは、履歴を構成するブロックの１つに対する消去処理手順を示している。履歴管理部５１０における消去処理は、本フローチャートに示す手順を、消去対象となっているバージョンを含む全てのブロック各々に対して施すことによって行われる。
【０２７１】
以下の説明においては、次に示す記号を用いる。
ｉ：処理対象となっているブロックの生成時点
ｄ：処理対象となっているブロックの消去時点
現行版においてもまだ消去されていないブロックは、ｄ＝∞で表すものとする。
【０２７２】
ｉ）対象バージョンが現行版でない場合（ステップＳ８１にてｒ≠ｎの場合）・消去対象バージョンにおいてしか存在しなかったブロックについて（ステップＳ８５，Ｓ８６にて、ｉ＝ｒかつｄ＝ｓ（ｒ）の場合）は、該ブロックを履歴情報の中から消去する（ステップＳ９０）。
・消去対象バージョンにおいて生成されたブロックについて（ステップＳ８５，Ｓ８６について、ｉ＝ｒかつｄ≠ｓ（ｒ）の場合）は、消去対象の次のバージョン（Ｖ［ｓ（ｒ）］）において生成されたものとする（ステップＳ８７）。
・消去対象バージョンにおいて消去されたブロックについて（ステップＳ８５，Ｓ８８にて、ｉ≠ｒかつｄ＝ｒの場合）は、消去対象の次のバージョン（Ｖ［ｓ（ｒ）］）において消去されたものとする（ステップＳ８９）。
【０２７３】
ｉｉ）対象バージョンが現行版である場合（ステップＳ８１にてｒ＝ｎの場合）
・現行版において生成されたブロックについて（ステップＳ８２にてｉ＝ｎの場合）は、該ブロックを履歴情報中から消去する（ステップＳ９０）。
【０２７４】
・現行版において消去されたブロックについて（ステップＳ８２，Ｓ８３にて、ｉ≠ｎかつｄ＝ｎの場合）は、未消去のブロック（ｄ＝∞）とする（ステップＳ８４）。
【０２７５】
ここで、上記の処理を全てのブロックに対して実行した後、履歴中の任意の隣接する２つのブロックについて、両者の生成時点が等しく、かつ、両者の消去時点が等しい場合には、この２つのブロックを結合することもできる。
【０２７６】
なお、以上の消去処理の実施例においては、１つの消去命令で１つのバージョンを消去する場合を説明したが、一般のバージョン管理システムにおいても、複数バージョンの消去要求を、その対象となる１つ１つのバージョンに対する消去命令に分解して処理することにより、一消去命令で複数のバージョンを消去する機能を提供するのと同様の効果を得ることは容易である。
【０２７７】
以上のように本実施例によれば、各々のファイルの各々のバージョンについて、それを編集しているクライアントの数を記憶し、ユーザからの消去の要求あっても、消去対象となるファイルのバージョンを編集するクライアントがなくなるまで消去の実行を遅延させるので、いずれかのクライアントが編集途中のバージョンを消去することがなくなり、マージ処理の実行に支承をきたさない非同期編集システムを実現することができる。
【０２７８】
ここで、上記した実施例における履歴の消去は、クライアントからファイル管理装置に対して消去要求を発行するものであったが、クライアント以外から消去要求を生成する構成も考えられる。例えば、作成から一定時間以上経過した履歴に対して、サーバ内部で自動的に消去要求を生成する場合がある。また、最新のバージョンに対する非同期編集のみをサポートすれば十分であって、過去のバージョンを編集することがない場合には、新たなバージョンができた時点で自動的にサーバ内部でその前のバージョンに対する消去要求を生成する構成をとればよい。
【０２７９】
なお、以上は図１３のサーバのファイル内容秘匿機能と非同期編集機能をクライアント・サーバ型システムに実装した実施例に、クライアント計数部を付加した例であったが、クライアント計数部は図１６や図２０の非同期編集機能をクライアント・サーバ型システムに実装した実施例に対して付加することも可能である。この場合、クライアント計数部９００は、図１３の実施例に付加した場合と、同様の構成・機能を有する。
【０２８０】
次に図１３、図１６、あるいは図２０を用いて説明した非同期編集機能を有する共有ファイル編集システムにおいて、あるファイルのブロック・データが暗号化されている場合に、図２５を用いて説明したあるファイルのあるバージョンを編集中であるクライアントが存在しなくなるまで消去実行を遅延させる機能と、当該ファイルののブロック・データを再構成する機能を有する本発明の第６実施例の共有ファイル編集システムについて説明する。
【０２８１】
図２５の実施例で説明したように、履歴管理を行うシステムにおいては履歴中の一部のバージョンを消去する機能を提供することが考えられる。ここでは、ブロック・データが暗号化されている場合にあるバージョンの履歴を消去する機能を提供する実施例を示す。また、ブロック・データの再構成を行うことによりブロック数を減らす機能を提供する実施例も併せて示す。
【０２８２】
本実施例では上記機能を実現するために、クライアント装置内にファイルのブロックデータを再構成する手段を設ける。これにより、クライアント装置は、あるバージョンの履歴を消去するとともにファイルデータを所望のブロックに構成し直すことができる。
【０２８３】
以下、前述の図２５の実施例を基にして、上記機能を設けた共有ファイル編集システムについて説明する。
【０２８４】
図３３は、図２５の実施例に、上記のようなブロック・データを再構成する手段を設けた実施例である。図中のファイル管理サーバ９５、通信路１１１は、図２５の実施例と同様の構成である。アクセス要求者９２は、ブロック・データ再構成部９１０が加わっている点が図２５と異なる。ブロック・データ再構成部９１０はすべてのアクセス要求者に備わっていなくてもよい。あるファイルのあるバージョンの消去命令はクライアント計数部９００の計数値が０であるときに実行される。
【０２８５】
ブロック・データが暗号化されている場合にあるバージョンの履歴を消去する処理手順は、履歴管理部５１０が差分積み上げ、ＲＣＳ、変形ＳＣＣＳのいずれの管理方法をとっているかによって異なるものであり、以下ではそれら３方式についてそれぞれ一例を説明する。
【０２８６】
以下の説明においては、次に示す記号を用いる。
ｒ：消去対象バージョンのバージョン番号
ｆ：対象となっているファイルの履歴のうちで、履歴管理部５１０が保持している最も古いバージョンのバージョン番号（多くの場合ｆ＝１であるが、過去にバージョンの消去命令によってバージョン１が消去されている場合には、ｆは１でない値になる。）
ｎ：対象となっているファイルの履歴のうちで、履歴管理部５１０が保持している最も新しいバージョン（すなわち現行版）のバージョン番号
ｐ（ｘ）：履歴管理部５１０が保持しているバージョンのうちで、バージョンｘの１つ前のバージョンのバージョン番号（多くの場合，ｐ＝ｘ−１であるが、過去にバージョンｘ−１が消去された場合には、ｐ＝ｘ−２に、さらにバージョンｘ−２が消去された場合には、ｐ＝ｘ−３に等々、順次前のバージョンになる。）
ｓ（ｘ）：履歴管理部５１０が保持しているバージョンのうちで、バージョンｘの１つ後のバージョンのバージョン番号（多くの場合、ｓ＝ｘ＋１であるが、過去にバージョンｘ＋１が消去された場合には、ｓ＝ｘ＋２に、さらにバージョンｘ＋２が消去された場合には、ｓ＝ｘ＋３に等々、順次後のバージョンになる。）
Ｖ［ｘ］：バージョンｘ（の内容）
Ｖ［ｘ］−Ｖ［ｙ］：バージョンｘとバージョンｙとの差分
【０２８７】
最初に、履歴管理部５１０が差分積み上げ方式により履歴管理を行っている場合の実施例について説明する。図３４にはクライアント９２におけるブロック・データ再構成部９１０の処理手順を、図３５にはクライアント９２からの消去要求を受けたサーバ９５における履歴管理部５１０の処理手順を示す。
【０２８８】
まず、クライアント９２における処理手順を示す（図３４）。
【０２８９】
１．消去対象が履歴の最初のバージョンや現行版でない場合（ステップＳ１０１、Ｓ１０６にてｒ≠ｆかつｒ≠ｎの場合）
・消去対象の後のバージョンＶ［ｓ（ｒ）］をサーバから読み込む。サーバからは暗号化された（複数の）ブロックデータが送られて来る（ステップＳ１０８）。
・送られてきたブロックデータを復号し、Ｖ［ｓ（ｒ）］とＶ［ｐ（ｒ）］を復元する。Ｖ［ｐ（ｒ）］はステップＳ１０８で読み込んだＶ［ｓ（ｒ）］から得ることができる（ステップＳ１０９）。
・Ｖ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］を生成する（ステップＳ１１０）。
・Ｖ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］を新たなブロック・データとして暗号器で暗号化する（ステップＳ１１１）。
・この暗号化ブロックデータとバージョンｒの消去要求をサーバへ送る（ステップＳ１１２）。
【０２９０】
２．消去対象が履歴の最初のバージョンである場合（ステップＳ１０１にてｒ＝ｆの場合）
・消去対象の後のバージョンＶ［ｓ（ｒ）］をサーバから読み込む。サーバからは暗号化された（複数の）ブロックデータが送られて来る（ステップＳ１０２）。
・送られてきたブロックデータを復号器で復号し、Ｖ［ｓ（ｒ）］を復元する（ステップＳ１０３）。
・Ｖ［ｓ（ｒ）］を新たなブロック・データとして暗号化する（ステップＳ１０４）。
・この暗号化ブロックデータとバージョンｒの消去要求をサーバへ送る（ステップＳ１０５）。
【０２９１】
３．消去対象が履歴の最後のバージョン（現行版）である場合（ステップＳ１０６にてｒ＝ｎの場合）
・バージョンｒの消去要求をサーバへ送る（ステップＳ１０７）。
【０２９２】
次に、クライアント９２からの消去要求を受けたサーバ９５の処理手順を示す（図３５）。
１．消去対象が履歴の最初のバージョンや現行版でない場合（ステップＳ１２１、Ｓ１２３にてｒ≠ｆかつｒ≠ｎの場合）
・Ｖ［ｓ（ｒ）］−Ｖ［ｒ］ブロック・データおよびＶ［ｒ］−Ｖ［ｐ（ｒ）］ブロック・データを消去し、代わりにクライアントから送られてきたＶ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］ブロック・データを挿入（ステップＳ１２５）。
【０２９３】
２．消去対象が履歴の最初のバージョンである場合（ステップＳ１２１にてｒ＝ｆの場合）
・Ｖ［ｒ］ブロック・データおよびＶ［ｓ（ｒ）］−Ｖ［ｒ］ブロック・データを消去し、代わりにクライアントから送られてきたＶ［ｓ（ｒ）］ブロック・データを挿入（ステップＳ１２２）。
【０２９４】
３．消去対象が履歴の最後のバージョン（現行版）である場合（ステップＳ１２３にてｒ＝ｎの場合）
・Ｖ［ｒ］−Ｖ［ｐ（ｒ）］ブロック・データを消去（ステップＳ１２４）。
以上の処理手順により、バージョンｒの履歴が消去される。
【０２９５】
次に、履歴管理部５１０がＲＣＳ方式により履歴管理を行っている場合の実施例について説明する。図３６にはクライアント９２におけるブロック・データ再構成部９１０の処理手順を、図３７にはクライアント９２からの消去要求を受けたサーバ９５における履歴管理部５１０の処理手順を示す。
【０２９６】
まず、クライアント９２における処理手順を示す（図３６）。
１．消去対象が履歴の最初のバージョンや現行版でない場合（ステップＳ１３１、Ｓ１３３にてｒ≠ｆかつｒ≠ｎの場合）
・消去対象の前のバージョンＶ［ｐ（ｒ）］をサーバから読み込む。サーバからは最新バージョンを含む暗号化された（複数の）ブロックデータが送られて来る（ステップＳ１３８）。
・送られてきたブロックデータを復号器で復号し、Ｖ［ｓ（ｒ）］とＶ［ｐ（ｒ）］を復元する。Ｖ［ｓ（ｒ）］はステップＳ１３８で読み込んだＶ［ｐ（ｒ）］から得ることができる（ステップＳ１３９）。
・Ｖ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］を生成する（ステップＳ１４０）。
・Ｖ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］を新たなブロック・データとして暗号器で暗号化する（ステップＳ１４１）。
・この暗号化ブロックデータとバージョンｒの消去要求をサーバへ送る（ステップＳ１４２）。
【０２９７】
２．消去対象が履歴の最初のバージョンである場合（ステップＳ１３１にてｒ＝ｆの場合）
・バージョンｒの消去要求をサーバへ送る（ステップＳ１３２）。
【０２９８】
３．消去対象が履歴の最後のバージョン（現行版）である場合（ステップＳ１３３にてｒ＝ｎの場合）
・消去対象の前のバージョンＶ［ｐ（ｒ）］をサーバから読み込む。サーバからは最新バージョンを含む暗号化された（複数の）ブロックデータが送られて来る（ステップＳ１３４）。
・送られてきたブロックデータを復号し、Ｖ［ｐ（ｒ）］を復元する（ステップＳ１３５）。
・Ｖ［ｐ（ｒ）］を新たなブロック・データとして暗号化する（ステップＳ１３６）。
・この暗号化ブロックデータとバージョンｒの消去要求をサーバへ送る（ステップＳ１３７）。
【０２９９】
次に、クライアント９２からの消去要求を受けたサーバ９５の処理手順を示す（図３７）。
【０３００】
１．消去対象が履歴の最初のバージョンや現行版でない場合（ステップＳ１５１、Ｓ１５３にてｒ≠ｆかつｒ≠ｎの場合）
・Ｖ［ｒ］−Ｖ［ｓ（ｒ）］ブロック・データおよびＶ［ｐ（ｒ）］−Ｖ［ｒ］ブロック・データを消去し、代わりにクライアントから送られてきたＶ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］ブロック・データを挿入（ステップＳ１５５）。
２．消去対象が履歴の最初のバージョンである場合（ステップＳ１５１にてｒ＝ｆの場合）
・Ｖ［ｒ］−Ｖ［ｓ（ｒ）］ブロック・データを消去（ステップＳ１５２）。
３．消去対象が履歴の最後のバージョン（現行版）である場合（ステップＳ１５３にてｒ＝ｎの場合）
・Ｖ［ｒ］ブロック・データおよびＶ［ｐ（ｒ）］−Ｖ［ｒ］ブロック・データを消去し、代わりにクライアントから送られてきたＶ［ｐ（ｒ）］ブロック・データを挿入（ステップＳ１５４）。
以上の処理手順により、バージョンｒの履歴が消去される。
【０３０１】
次に、履歴管理部５１０が変形ＳＣＣＳ方式により履歴管理を行っている場合について説明する。前述したように、変形ＳＣＣＳ方式においてはブロックはバージョンがすすむにつれて分割されてくる。ブロック数が増えると、ブロック識別データやブロック処理のオーバヘッドが増えてきてしまうため、ブロック数が増えすぎないようにするのが望ましい。
【０３０２】
図３２に示したように、変形ＳＣＣＳ方式により履歴管理を行っている場合は、サーバ９５の履歴管理部５１０があるバージョンの履歴消去命令を実行することが出来る。従って、バージョン消去はサーバ９５の履歴管理部５１０が行い、クライアント９２のブロック・データ再構成部９１０はブロックの再構成を行うという実施例が考えられる。その場合の手順は以下のようになる。
【０３０３】
・クライアント９２は、まずサーバ９５にバージョンｒの消去命令を送る。
・サーバ９５の履歴管理部５１０は、図３２に示した手順でバージョンｒの履歴を消去する。
・クライアント９２は、Ｖ［ｓ（ｒ）］あるいはＶ［ｎ］のファイルを読み込み、ブロックデータ・再構成部９１０においてブロックの再構成および暗号化を行う。再構成できるブロックデータは位置が連続しておりかつ生成時間と消去時間が等しいブロックである。これらのブロックを復号した後、任意の新たなブロック・データとして再構成し暗号化してサーバ９５へ送る。
・サーバ９５の履歴管理部５１０は送られてきたブロックを古いブロックと入れ換える。
【０３０４】
尚、この第６実施例におけるブロックデータ再構成に関する特徴を、上述した図２３の様にファイル内容の秘匿機能のみを有するファイル編集システムに組み込むことも可能である。
【０３０５】
次に、図１３、図１６、あるいは図２０を用いて説明したファイル編集システムにおいて、クライアントが、あるファイルのあるバージョンを既に保有しているときに新たに別のバージョンを読み込もうとする場合、ファイル全体を読み込むのではなく、必要な部分だけを読み込む機能を設けた本発明の第７実施例のファイル編集システムについて説明する。
【０３０６】
図３８は、図１３の実施例に、上記のようなクライアントがサーバから必要な部分だけを読み込む機能を設けた実施例である。図中の通信路１１１は、図１３の実施例と同様の構成である。ファイル管理サーバ９６は、差分情報構築部９３０が、アクセス要求者９３はファイル記憶部９２０とファイルデータ構築部９２１が加わっている点が、図１３と異なる。
【０３０７】
クライアント９３は、前回アクセスしたファイルをそのバージョン情報とともにファイル記憶部９２０に保存している。サーバ９６から、同ファイルの別のバージョン（例えば最新バージョン）を読み込もうとする場合、現在保有しているバージョン情報と所望のバージョン情報をサーバ９６に伝える。サーバ９６の差分情報構築部９３０は、クライアント９３からの２つのバージョン情報に基づきクライアント９３が所有するバージョンのファイルに対する差分データを構築しクライアント９３に送り返す。クライアント９３のファイルデータ構築部９２１は、現在保有しているファイルデータとサーバ９６からの差分データにより所望のバージョンを構築する。そして共有ファイル編集部１２２に渡すことによりファイルを編集することができる。
【０３０８】
一般に、バージョン間の差分データはファイル全体のデータよりも少いため通信量が少くてすみ、高速な読み込みが実現できる。
【０３０９】
サーバ９６の差分情報構築部９３０において差分データを構築する方法は、履歴管理部５１０が差分積み上げ、ＲＣＳ、変形ＳＣＣＳのいずれの管理方法をとっているかによって異なる。以下ではそれら３方式についてそれぞれ実施例の一例を説明する。
以下の説明においては、次に示す記号を用いる。
ｃ：クライアントが保有しているファイルのバージョン番号
ｒ：クライアントが新たに読み込むバージョン番号
Ｖ［ｘ］：バージョンｘ（の内容）
Ｖ［ｘ］−Ｖ［ｙ］：バージョンｘとバージョンｙとの差分
最初に、履歴管理部５１０が差分積み上げ方式により履歴管理を行っている場合の、差分情報構築部９３０の処理手順の実施例について説明する。
【０３１０】
１．保有しているバージョンよりも新しいバージョンを読み込む場合（ｒ＞ｃ）
・差分積み上げ方式はバージョン間の差分を積み上げていくものであるから、バージョンｒとｃとの差分ブロック・データを選べばよい。
２．保有しているバージョンよりも古いバージョンを読み込む場合（ｒ＜ｃ）
【０３１１】
以下の２つの方法がある。
【０３１２】
（ａ）差分情報を構築せずＶ［ｒ］を返す。
ブロック・データが暗号化されている場合は、サーバは差分情報を構築できないので本方法をとる。
（ｂ）サーバがＶ［ｒ］とＶ［ｃ］を復元しＶ［ｒ］−Ｖ［ｃ］を生成する。
ブロック・データが暗号化されていない場合は本方法が可能。
【０３１３】
次に、履歴管理部５１０がＲＣＳ方式により履歴管理を行っている場合の、差分情報構築部９３０の処理手順の実施例について説明する。
１．保有しているバージョンよりも新しいバージョンを読み込む場合（ｒ＞ｃ）以下の２つの方法がある。
（ａ）差分情報を構築せずＶ［ｒ］を返す。
ブロック・データが暗号化されている場合は、サーバは差分情報を構築できないので本方法をとる。
（ｂ）サーバがＶ［ｒ］とＶ［ｃ］を復元しＶ［ｒ］−Ｖ［ｃ］を生成する。
ブロック・データが暗号化されていない場合は本方法が可能。
２．保有しているバージョンよりも古いバージョンを読み込む場合（ｒ＜ｃ）・ＲＣＳ方式はバージョン間の逆方向の差分を履歴として残すものであるから、バージョンｃとｒの差分ブロック・データを選べばよい。
【０３１４】
次に、履歴管理部５１０が変形ＳＣＣＳ方式により履歴管理を行っている場合の、差分情報構築部９３０の処理手順の実施例について説明する。図３９に、差分情報構築部９３０がファイルの履歴を構成するブロックから差分ブロックを選択する処理手順のフローチャートを示す。尚、図３９のフローチャートは、履歴を構成するブロックの１つに対する差分ブロック選択処理手順を示している。差分情報構築部９３０における差分ブロック選択処理は、本フローチャートに示す手順を、全てのブロック各々に対して施すことによって行われる。
【０３１５】
以下の説明においては、次に示す記号を用いる。
ｉ：処理対象となっているブロックの生成バージョン番号
ｄ：処理対象となっているブロックの消去バージョン番号
まだ消去されていないブロックは、ｄ＝ＮＵＬＬで表すものとする。
【０３１６】
１．保有しているバージョンよりも新しいバージョンを読み込む場合（ステップＳ１６１においてｒ＞ｃの場合）
以下の条件のどれかを満たすブロックを選択する（ステップＳ１６７）。
（ａ）バージョンｃからｒの間に生成されてｒの時点で消去されていないブロック
つまり、（ｒ＞ｉ＞ｃ）ａｎｄ｛（ｒ＜ｄ）ｏｒ（ｄ＝ＮＵＬＬ）｝（ステップＳ１６２）
（ｂ）バージョンｃの時点で生成されていてｃからｒの間に消去されたブロック
つまり、（ｉ＜ｃ）ａｎｄ（ｒ＞ｄ＞ｃ）（ステップＳ１６３）
【０３１７】
２．保有しているバージョンよりも古いバージョンを読み込む場合（ステップＳ１６４においてｒ＜ｃの場合）
以下の条件のどれかを満たすブロックを選択する（ステップＳ１６７）。
（ａ）バージョンｒからｃの間に生成されてｃの時点で消去されていないブロック
つまり、（ｒ＜ｉ＜ｃ）ａｎｄ｛（ｄ＞ｃ）ｏｒ（ｄ＝ＮＵＬＬ）｝（ステップＳ１６５）
（ｂ）バージョンｃの時点で生成されていてｒからｃの間に消去されたブロック
つまり、（ｉ＞ｃ）ａｎｄ（ｒ＜ｄ＜ｃ）（ステップＳ１６６）
【０３１８】
差分情報構築部９３０は上記手順にて差分ブロックを選択後、そのブロック情報をクライアント９３が現在保有しているバージョンに対する差分情報に変換してクライアント９３に送る。例えば、挿入データに対しては、クライアント９３が保有しているバージョンに対する挿入位置を求め挿入ブロック・データと共に送る。削除データに対しては、クライアント９３が保有しているバージョンに対する削除範囲を求めその情報を送る。これより、クライアント９３は所望のバージョンを容易に構築すことができる。また、サーバ９６からクライアント９３への通信データ量が少くてすむ。
【０３１９】
尚、この第７実施例における所望のバージョンの構築に関する特徴を、上述した図２３の様にファイル内容秘匿機能のみを有するファイル編集システムに組み込むことも可能である。
【０３２０】
次に、図１３、図１６、あるいは図２０を用いて説明した非同期編集機能を有する共有ファイル編集システムにおいて、あるファイルに対して複数のクライアントからの書き込みが非同期に起こるために編集の競合が生じる場合があるが、その対応策を施した本発明の第８実施例を示す。
【０３２１】
図４０は、図１６の実施例に、上記のような機能がサーバに組み込まれた実施例である。図中のアクセス要求者２１１、通信路１１１は、図１６の実施例と同様の構成である。ファイル管理サーバ２２０は、編集競合検出部９４０が加わっている点が図１６と異なる。
【０３２２】
本実施例では、図１６の例と同様に複数のクライアント２１１からのデータの書き込み要求が様々なタイミングで発生する。サーバ２２０では、２１１からの書き込み要求を編集手続き変換部５０２にてその時点での最新版に対する位置データに変換する。そして、編集競合検出部９４０において、その変換された編集データが他のクライアント２１１による編集結果と競合していないかどうかを検出する。その検出結果は、クライアント２１１に返される。ここで競合しているとは、例えば以下のように判断することができる。
・挿入データの挿入地点が既に削除されている
・挿入データの挿入地点に別のデータが挿入されている
・削除範囲に別のデータが挿入されている
０・削除範囲の一部が既に削除されている
【０３２３】
履歴管理部５１０では編集競合検出部９４０の結果は受け取らず、編集手続き変換部５０２にて変換されたクライアント２１１から送られたデータを最新バージョンとして保存する。
【０３２４】
上記のサーバ２２０におけるデータ更新機能は、履歴管理部５１０の管理方法とブロック・データが暗号化されているかどうかにより、実現可能な場合と実現不可能な場合がある。ブロック・データが暗号化されていない場合は、差分積み上げ、ＲＣＳ、変形ＳＣＣＳのいずれの管理方法においても実現可能である。ブロック・データが暗号化されている時は、変形ＳＣＣＳ方式のみで実現可能となる。
【０３２５】
次に同様の構成において編集競合検出部９４０の競合検出結果を履歴管理部５１０に通知し、履歴管理部５１０はその検出結果に基づいてデータの更新を行うかどうかの判断を行う本発明の第９実施例を示す。
【０３２６】
図４１は、図４０の実施例に上記のような機能がサーバに組み込まれた実施例である。図中のアクセス要求者２１１、通信路１１１は、図４０の実施例と同様の構成である。ファイル管理サーバ２２５は、編集競合検出部９４０の出力が履歴管理部５１０に入力されている点が図４０と異なる。
【０３２７】
本実施例によると例えば、他のクライアントとの編集競合が起こらなかった場合は、編集手続き変換部５０２にて変換されたクライアント２１１から送られたデータを最新バージョンとして保存し、編集競合が起こった場合はサーバ２２５のデータを更新しないというという機能が実現できる。この場合、書き込みが行われた最新バージョンは、他のクライアント２１１との編集競合が起こっていないので、意味的矛盾が起こりにくいという利点がある。クライアント２１１は編集競合検出部９４０による検出結果の通知を受けるので、書き込みが行われなかった場合は、サーバ２２５から最新バージョンを読み込み競合が起こらないように編集し直すことができる。
【０３２８】
次に、共有ファイル編集システムを既存のアプリケーション・プログラムから利用することを可能にした本発明の第１０実施例を示す。
【０３２９】
図４１は、既存のアプリケーション・プログラムから共有ファイル編集システムを利用する実施例である。図中のファイル管理サーバ９７０は、通信部１３１、アクセス情報記憶部９７１、共有ファイル履歴管理部９７２、データ記憶部９７３を有する。アクセス要求者９５０は、アクセス要求部９５１、システム・コール・テーブル９５５、共有ファイルアクセス処理部９６０、通信部１３０を有する。ファイル管理サーバ９７０とアクセス要求者９５０は通信部１３０，１３１を通して、通信路１１１により通信可能である。
【０３３０】
本実施例では、アクセス要求部９５１は既存アプリケーション・プログラムであると想定し、アクセス要求部９５１により発せられるアクセス要求はオペレーティング・システムによって提供されるシステム・コールによって行われるとする。
【０３３１】
本実施例おいて、アクセス要求部９５１は、システム・コール・テーブル９５５の持つシステム・コールに対応する関数を参照した上で、ｏｐｅｎ／ｃｌｏｓｅ／ｒｅａｄ／ｗｒｉｔｅの関数を実行する。オペレーティング・システムにおけるシステム・コールの関数を参照するシステム・コール・テーブル９５５のデータは、オペレーティング・システムによって提供されるｏｐｅｎ関数／ｃｌｏｓｅ関数／ｒｅａｄ関数／ｗｒｉｔｅ関数への接続データ（アドレス・ポインタ）から、共有ファイルアクセス処理部９６０によって提供される共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数９６１への接続データ（アドレス・ポインタ）に書き換えられている。この共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数９６１は、通信部１３０を通してファイル管理サーバ９７０に送られる。
【０３３２】
従って、既存のアプリケーション・プログラムからなるアクセス要求部９５１がｏｐｅｎ関数／ｃｌｏｓｅ関数／ｒｅａｄ関数／ｗｒｉｔｅ関数を実行した結果、実際は共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数９６１が実行されることになる。
【０３３３】
ここで、共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数は、それぞれ、“ｏｐｅｎ”をする共有ファイルアクセス要求に応じた処理／“ｃｌｏｓｅ”をする共有ファイルアクセス要求に応じた処理／“ｒｅａｄ”をする共有ファイルアクセス要求に応じた処理／“ｗｒｉｔｅ”をする共有ファイルアクセス要求に応じた処理に該当する。なお、図４２では、共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数９６１は、それぞれ独立した形で構成されているが、各関数９６１に共通する処理に対応する部分は１つの処理実体として４つの関数で共有化してもよい。
【０３３４】
ファイル管理サーバ９７０は、アクセス要求者９５０より共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数を受け取り、共有ファイル用履歴管理部９７２に渡す。共有ファイル用履歴管理部９７２は、アクセス情報記憶部９７１の情報を元にデータ記憶部９７３から所望のデータの読み込みあるいは書き込みを行うことができる。そして、行われたアクセス要求をアクセス情報記憶部９７１のデータに記録する。
【０３３５】
図４３には、アクセス情報記憶部９７１のアクセス履歴リスト９８０の例を示す。アクセス履歴リスト９８０は、ファイル管理サーバ９７０のファイルへのアクセス要求を記憶したリストである。このアクセス履歴リスト９８０には、ファイル識別子９８１、モード９８２、オープン時刻９８３、クローズ時刻９８４、バージョン９８５、カレント９８６の６つのフィールドがある。
【０３３６】
ファイル識別子９８１は、アクセス要求部９５１から共有ファイル用履歴管理部９７２に対して与えられた“ｏｐｅｎ”の共有ファイル・アクセス要求ごとに固有に割り当てられる識別子である。“ｏｐｅｎ”要求以後は、アクセス要求部９５１からの共有ファイル・アクセス要求は、ファイル識別子９８１を用いて管理される。このファイル識別子９８１は、共有ファイル用履歴管理部９７２が“ｏｐｅｎ”の共有ファイルアクセス要求を受け付ける度に、アクセス要求部９５１に対して発給する。
【０３３７】
モード９８２は、このファイルへのｏｐｅｎ要求のモードを示したもので、ここに書かれている“ｒ”は読みだし専用であることを意味している。また、ここに“ｗ”と書かれていれば、書き込み専用または読み書き両用のモードであることを意味している。
【０３３８】
オープン時刻９８３は、このファイルへのｏｐｅｎ要求が発せられた時刻を示している。この例のＩＤ１で表されるファイルは、時刻ｔ１にオープンされたことを意味している。また、クローズ時刻９８４は、このファイルへのｃｌｏｓｅ要求が発せられた時刻を示している。この例では、ＩＤ１で表されるファイルはクローズ時刻９８４が書かれていないので、現在オープン中であることを、ＩＤ２で表されるファイルは、時刻ｔ５にクローズされたことを意味している。
【０３３９】
ここで、上記の時刻は、各事象の発生した時刻の前後関係を示すためのものであり、例えば、計算機の持つ内部的な時計でもよいし、ファイル管理にバージョン番号をつけてそれを時刻として用いてもよい。また、この時刻は共有ファイル用履歴管理部９７２だけで用いるものであるから、必ずしも他の部分（例えばアクセス要求者９５０）から直接にこの時刻が参照できなくてもよい。
【０３４０】
バージョン９８５は、このファイルへのｏｐｅｎ要求が発せられたファイルのバージョンを示す。通常、システム・コールのｏｐｅｎは最新バージョンに対する要求であるので、ｏｐｅｎ要求が発せられた時点での最新のバージョンが入ることが多い。
【０３４１】
カレント９８６は、現在アクセスしているアクセス要求に関して、現在アクセスしている位置を示す値（シーク・ポインタ）である。このシーク・ポインタは、次に来る“ｒｅａｄ”の共有ファイル・アクセス要求に対して、読み出す位置（ファイル内の相対位置）を示すものであり、読みだし専用の“ｏｐｅｎ”の場合、デフォルトとして初期値が０となっている。
【０３４２】
共有ファイル用履歴管理部９７２は、アクセス要求者９５０からの非同期アクセスを管理し、アクセス情報記憶部９７１の内容に従い、データ記憶部９７３から所望のデータの読み書きを行う。共有ファイル用履歴管理部９７２の動作は前述の実施例と同様であるので、ここでは詳細に説明しない。
【０３４３】
このように本実施例によれば、オペレーティング・システムによって提供されるシステム・コール・テーブル９５５中のアドレス・ポインタの値を書き換えるだけで、既存のアプリケーション・ソフトウェア等のプログラム自体は全く変更せずに、アクセス要求者として利用して非同期編集を行うこが可能になる。
【０３４４】
次に、上記第１０実施例と同様な目的をもった本発明の第１１実施例を図４４に示す。図４４においては、図４２のファイル管理サーバ９７０が保有していたアクセス情報記憶部９７１をアクセス要求者９９０が有する構成をとっている。ファイル管理サーバ９０は図１３で示したファイル管理サーバと同様の構成であり、共有ファイル用履歴管理部５１０、データ記憶部５１１、通信部１３１からなる。
【０３４５】
本実施例においては、アクセス要求者の９９０は自らが保有するアクセス要求部９９１からの共有ファイルアクセス情報をアクセス情報記憶部９９５に記憶する。アクセス情報記憶部９９５の内容は、例えば図４３と同じものを用いることができる。
【０３４６】
共有ファイルアクセス処理部９９３は、アクセス情報記憶部９９５の情報を読み込み、共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数９９４の引数として、それぞれの関数に必要な情報を加えてファイル管理サーバ９０に要求を送る。
【０３４７】
例えば、アクセス要求部９９１よりファイル識別子ＩＤ１のファイルから１０バイト読み込みたいというｒｅａｄシステム・コールが発せられた時、共有ファイルアクセス処理部９９３は、アクセス情報記憶部９９５から、ファイル識別子ＩＤ１に関するバージョン情報９８５、カレント位置情報９８６を読み込み、ファイル識別ＩＤ１と読み込むバイト数とともに、共有ｏｐｅｎ関数の引数に付加してファイル管理サーバ９０に送る。
【０３４８】
アクセス要求者９９０からファイル管理サーバ９０に送られる要求には、通常のオペレーティング・システムのシステム・コールで付与される情報以外にアクセス要求者の現在のアクセス情報も含まれているので、その情報をもとに共有ファイル用履歴管理部５１０は、データ記憶部５１１から所望のデータを取り出すことができる。
【０３４９】
このように本実施例においても、オペレーティング・システムによって提供されるシステム・コール・テーブル９９２中のアドレス・ポインタの値を書き換えるだけで、既存のアプリケーションソフトウェア等のプログラム自体は全く変更せずに、アクセス要求者として利用して非同期編集を行うことが可能になる。
【０３５０】
尚、上記第１０，第１１実施例における既存のアプリケーション・プログラムを共有ファイルに対して使用可能とする特徴で、共有ファイルに対するアクセス関数を暗号化ファイルに対するアクセス関数に変えることで、既存のアプリケーション・プログラムを暗号化ファイルに対して使用可能とする特徴として、上述した図２３の様にファイル内容秘匿機能のみを有するファイル編集システムに組み込むことも可能である。
【０３５１】
また、上述の各実施例においてクライアントとサーバの通信部の間の通信路を介した通信はクライアント・コンピュータとサーバ・コンピュータの間のネットワーク通信の形でも良いし、クライアント・プログラムとサーバ・プログラムの間のデータ転送の形でも良い。
【０３５２】
尚、本発明は上述した各実施例に限定されるものではなく、その要旨を逸脱しない範囲で、種々変更して実施することができる。
【０３５３】
【発明の効果】
以上説明したように、本発明（請求項１，２，６〜１２，２３，２４）によれば、ファイルをブロック単位で暗号化するとともに、各ブロックに暗号化していないブロック識別子を付加したので、復号鍵を持つ正規のクライアント装置のみがファイルの内容を読み取ることができるとともに、ファイル管理サーバ装置にはファイルの内容が秘匿されているが、データ構造は管理させることができる秘匿性の高いファイル編集システムを提供することができる。
【０３５４】
本発明（請求項３，９，１３〜１９，２５）によれば、ファイルをブロック単位で暗号化するとともに、各ブロックに暗号化していないブロック識別子を付加したので、復号鍵を持つ正規のクライアント装置のみがファイルの内容を読み取ることかできるとともに、ファイル管理サーバ装置にはファイルの内容が秘匿されているが、データ構造は管理させることができる秘匿性の高い共有ファイル編集システムを提供することができる。
【０３５５】
また、ファイル管理サーバ装置は、クライアント装置から渡されたファイル編集の内容を示すデータを、該クライアント装置がアクセスして得たバージョンがいずれであるかに従って、該ファイル管理サーバ装置内での最新バージョンに対する編集内容に変換する処理を行うので、前記ファイル管理サーバ装置側では例えば“どのクライアントがどのバージョンのファイルをオープンしている”といったアクセス状況の情報を持つ必要がなくロック機構不要な仕組みで非同期編集可能な共有ファイル編集システムを構成することができる。
【０３５６】
特に、時間的に古いバージョンを編集し、最新バージョンとする使い方が可能となる。すなわち、非同期編集可能な共有ファイルにおいて、編集対象を現行版に限定しない使い方が可能となる。
【０３５７】
本発明（請求項４，９，１３〜１７，１９，２６）によれば、ファイルをブロック単位で暗号化するとともに、各ブロックに暗号化していないブロック識別子を付加したので、復号鍵を持つ正規のクライアント装置のみがファイルの内容を読み取ることができるとともに、ファイル管理サーバ装置にはファイルの内容が秘匿されているが、データ構造は管理させることができる秘匿性の高い共有ファイル編集システムを提供することができる。
【０３５８】
一方、上記データを採用することにより、ファイル管理サーバ装置では、常に各クライアント装置による編集終了時における最新バージョンのファイルの内容に対する更新が行われるようにしたので、ロックを掛けずに複数のクライアント装置による非同期編集を行うことが可能となる。
【０３５９】
本発明（請求項５，１０〜１２，２０〜２２，２７）によれば、ファイル管理サーバ装置は、クライアント装置から渡されたファイル編集の内容を示すデータを、該クライアント装置がアクセスして得たバージョンがいずれであるかに従って、該ファイル管理サーバ装置内での最新のバージョンに対する編集内容に変換する処理を行うので、前記ファイル管理サーバ装置側で例えば“どのクライアントがどのバージョンのファイルをオープンしている”といったアクセス状況の情報を持つ必要がなくロック機構不要な仕組みで非同期編集可能な共有ファイル編集システムを構成することができる。
【０３６０】
特に、時間的に古いバージョンを編集し、最新バージョンとする使い方が可能となる。すなわち、非同期編集可能な共有ファイルにおいて、編集対象を現行版に限定しない使い方が可能となる。
【０３６１】
また、本発明（請求項６，７）によれば、ファイルをブロック単位で暗号化するとともに、各ブロックに暗号化していないブロック識別子を付加したので、復号鍵を持つ正規のクライアント装置のみがファイルの内容を読み取ることができるとともに、ファイル管理サーバ装置にはファイルの内容が秘匿されているが、データ構造は管理させることができる秘匿性の高い共有ファイル編集システムを提供することができる。
【０３６２】
一方、上記データ構造を採用することにより、ファイル管理サーバ装置ではクライアント装置から渡された編集内容を示す暗号化されたブロック・データとブロック識別情報とに基づいて、該ファイルの履歴管理を行うことができる。
【０３６３】
このように、ファイルの履歴管理とファイル管理サーバ装置に対するデータの秘匿性を同時に実現できる。
【０３６４】
また、本発明（請求項１０）によれば、クライアント装置は、ファイル管理サーバ装置からファイルを得ることができ、保有している復号鍵を用いて該ブロック・データを復号化し、得られた復号化データをブロック新たなブロック・データに再構成し、暗号鍵を用いて新たなブロック・データごとに暗号化し、ファイル管理サーバ装置に出力することができる。
【０３６５】
また、これにより、クライアント装置により、履歴情報の消去を行ったり、ファイルのブロック・データ数が多くなった時などにブロックを再構成し、ブロック識別情報によるオーバヘッドを削減することができる。暗号鍵／復号鍵を有するクライアント装置が行うことにより、サーバに対するファイルの内容の秘匿性は守られる。
【０３６６】
また、本発明（請求項１１）によれば、クライアント装置は、あるバージョンのファイルを保存する手段を有し、ファイル管理サーバ装置から、現在クライアント装置が保有しているバージョンのファイルと、所望のバージョンのファイルの差分情報を受け取り、クライアントが保有している当該ファイルのデータとファイル管理サーバ装置からの差分情報により、所望のバージョンのファイルを構築し編集することができる。
【０３６７】
従って、クライアント装置は、ファイル全体ではなく、現在保有するバージョンと所望するバージョンとの差分情報のみをファイル管理サーバ装置から取得すればよく、通信量の削減を図ることができるとともに、ブロック・データが暗号化されている場合はクライアント装置での復号化処理量を削減できる。
【０３６８】
本発明（請求項１２）によれば、オペレーティング・システムによって提供されるコールテーブル中のアドレス・ポインタの値を書き換えるだけで、既存のアプリケーションソフトウェア等のプログラム自体は全く変更せずに、アクセス要求者として利用して非同期編集を行うことが可能になる。
【０３６９】
本発明（請求項２０）によれば、ファイル管理サーバ装置では、各々のファイルの各々のバージョンについて、それを編集しているクライアント装置の数を記憶し、ユーザから消去の要求があっても消去対象となるファイルのバージョンを編集するクライアントがなくなるまで消去の実行を遅延させるので、いずれかのクライアントが編集途中のバージョンを消去することがなくなり、マージ処理の実行に支障をきたすおそれがなくなる。
【０３７０】
また、本発明（請求項２１，２２）によれば、各クライアント装置による編集結果は、ファイル管理サーバ装置における最新バージョンのファイルに対する更新に変換され、他のクライアントによる編集と競合するか否かによらず、ファイル管理サーバ装置に最新バージョンとして更新されるため、ロックを掛けずに複数のクライアント装置による非同期編集を行うことが可能となる。
【０３７１】
また、ファイル更新を行ったクライアントは、ファイル管理サーバ装置より、編集内容の競合検出の結果を通知されるので、その結果に基づいて、ファイルを編集し直すことができる。その際、ファイル管理サーバ装置ではファイルは履歴管理されているので、過去のバージョンを取り出すなどして柔軟に編集を行うことができる。
【０３７２】
また、請求項２２のように構成した場合、ファイル管理サーバ装置は、他のクライアントによる編集との競合検出の結果に基づいて、ファイルの更新を行うかどうかを判断することができるので、ファイル管理サーバ装置の最新バージョンのファイルにおいて意味的矛盾が起こりにくい、あるいは起こらないようにすることができる。
【図面の簡単な説明】
【図１】本発明の第１実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図２】同実施例の差分積み上げ方式による履歴管理法でのファイルのデータ構造を示す図。
【図３】同実施例のＲＣＳ方式による履歴管理法でのファイルのデータ構造を示す図。
【図４】同実施例の変形ＳＣＣＳ方式による履歴管理法でのファイルのデータ構造を示す図。
【図５】同実施例の非同期編集機構の基本構成を示すブロック図。
【図６】同実施例の差分積み上げ方式による履歴管理時の非同期編集機構の働きを説明する図。
【図７】同実施例の変形ＳＣＣＳ方式による履歴管理時の非同期編集機構の働きを説明する図。
【図８】同実施例のＯＦＢモードによる暗号化手順を説明するための図。
【図９】同実施例のＣＦＢモードによる暗号化手順を説明するための図。
【図１０】同実施例の暗号方式によるブロック・データ分割時の暗号手順を説明するための図。
【図１１】同実施例のファイル・ブロック分割時の暗号化に関わる処理を説明するフローチャート。
【図１２】同実施例のファイル・ブロック分割時の暗号化に関わる他の処理を説明するフローチャート。
【図１３】本発明の第２実施例に係る共有ファイル編集システムのより具体的な一構成例を示すブロック図。
【図１４】図１３の共有ファイル編集部の内部構成を示すブロック図。
【図１５】図１３の暗号器の内部構成を示すブロック図。
【図１６】本発明の第２実施例に係る共有ファイル編集システムのより具体的な他の構成例を示すブロック図。
【図１７】図１６の共有ファイル編集部の内部構成を示すブロック図。
【図１８】図１３の共有ファイル編集部の要部構成をまとめたブロック図。
【図１９】図１６の共有ファイル編集部の要部構成をまとめたブロック図。
【図２０】本発明の第３実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図２１】図２０の共有ファイル編集部の内部構成を示すブロック図。
【図２２】図２０のマージ処理部の内部構成を示すブロック図。
【図２３】本発明の第４実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図２４】図２３の暗号器の内部構成を示すブロック図。
【図２５】本発明の第５実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図２６】図２５のクライアント計数部の内部構成を示すブロック図。
【図２７】図２６の計数記憶部に記憶されるデータのデータ構造を説明するための図。
【図２８】図２６の消去要求処理部の処理の流れを示すフローチャート。
【図２９】図２６の編集終了処理部の処理の流れを示すフローチャート。
【図３０】図２５で履歴管理部５１０が差分積み上げ方式により履歴管理を行う場合の消去命令の実行処理手順を示すフローチャート。
【図３１】図２５で履歴管理部５１０がＲＣＳ方式により履歴管理を行う場合の消去命令の実行処理手順を示すフローチャート。
【図３２】図２５で履歴管理部５１０が変形ＳＣＣＳ方式により履歴管理を行う場合の消去命令の実行処理手順を示すフローチャート。
【図３３】本発明の第６実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図３４】図３３で履歴管理部が差分積み上げ方式により履歴管理を行う場合のブロック・データ再構成部の処理手順を示すフローチャート。
【図３５】図３３で履歴管理部が差分積み上げ方式により履歴管理を行う場合のサーバの履歴管理部の処理手順を示すフローチャート。
【図３６】図３３で履歴管理部がＲＣＳ方式により履歴管理を行う場合のブロック・データ再構成部の処理手順を示すフローチャート。
【図３７】図３３で履歴管理部がＲＣＳ方式により履歴管理を行う場合のサーバの履歴管理部の処理手順を示すフローチャート。
【図３８】本発明の第７実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図３９】履歴管理部が変形ＳＣＣＳ方式により履歴管理を行う場合のサーバの差分情報構築部の差分ブロック選択処理手順を示すフローチャート。
【図４０】本発明の第８実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図４１】本発明の第９実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図４２】本発明の第１０実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【図４３】図４２のアクセス情報記憶部が記憶する情報の例を示す図。
【図４４】本発明の第１１実施例に係る共有ファイル編集システムの基本構成を示すブロック図。
【符号の説明】
９１，９２，９３，１０１，２１１，７０１，８０１，９５０，９９０ アクセス要求者（クライアント）
９０，９５，９６，１１０，２１０，２２０，２２５，７１０，８１０，９７０ ファイル管理サーバ（サーバ）
１１１ 通信路
１１２，２１２，８１２ 暗号器
１１３ 共有ファイル
１２１，２２１，７２１，８２１ メモリ
１２２，２２２，７２２ 共有ファイル編集部
１３０，１３１，１３２，２３０，２３１，７３０，７３１，８３０〜８３２通信部
２０１，２０２，２０３，２０４ 差分積み上げ方式でのブロック
３０１，３０２，３０３，３０４ ＲＣＳ方式でのブロック
４０１，４０２，４０３，４０４，４０５ ＳＣＣＳ方式でのブロック
４０６ 生成時点フィールド
４０７ 消去時点フィールド
５００ 編集部
５０１ 編集手続き生成部
５０２ 編集手続き変換部
５０３ 履歴管理情報生成部
５１０ 履歴管理部
５１１，９７３ データ記憶部
７４０ マージ処理部
８２２ ファイル編集部
８４０ データ管理部
１１２１，８１２１ 暗号化／復号化処理部
１１２２，８１２２ 鍵記憶部
９００ クライアント計数部
９０１ 分岐部
９０２ 編集開始処理部
９０３ 消去要求処理部
９０４ 編集終了処理部
９０５ 計数記憶部
９０６ 消去命令発行部
９１０ ブロック・データ再構成部
９２０ ファイル記憶部
９２１ ファイルデータ構築部
９３０ 差分情報構築部
９４０ 編集競合検出部
９５１，９９１ アクセス要求部
９５５，９９２ システム・コール・テーブル
９６０，９９３ 共有ファイルアクセス処理部
９６１，９９４ 共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数
９７１，９９５ アクセス情報記憶部
９７２ 共有ファイル用履歴管理部
９８０ アクセス履歴リスト
９８１ ファイル識別子
９８２ モード
９８３ オープン時刻
９８４ クローズ時刻
９８５ バージョン
９８６ カレント

Claims (27)

1. 各ファイルが、履歴管理に必要なバージョン間の差分に対応する複数のブロックデータと各ブロックのブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、
   ファイル編集を行なう少なくとも一つのクライアント装置とから構成され、
   前記クライアント装置は、
   前記ファイル管理サーバ装置が管理する所望のファイルに属するブロックデータをブロック単位で取得し、所定の復号鍵を用いてブロック単位で復号化する復号化手段と、
   前記復号化手段で復号化されたブロックデータから構成される前記所望のファイルを編集して、該所望のファイルになされた編集内容を示す編集データを得る編集手段と、
   前記編集手段で得られた編集データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集データを得る暗号化手段と、
   前記暗号化手段で得られた暗号化編集データを前記ファイル管理サーバ装置に送る通信手段とを備え、
   前記ファイル管理サーバ装置は前記クライアント装置から受取った暗号化編集データと前記各ブロックデータのブロック識別情報とに基づいて前記差分に対応するブロック単位で前記所望のファイルを管理することを特徴とするファイル編集システム。
2. 各ファイルが、履歴管理に必要な複数のブロックデータと、対応するブロックデータの生成時と消去時のバージョン情報を有するブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、
   ファイル編集を行なう少なくとも一つのクライアント装置とから構成され、
   前記クライアント装置は、
   前記ファイル管理サーバ装置が管理する所望のファイルに属するブロックデータをブロック単位で取得し、所定の復号鍵を用いてブロック単位で復号化する復号化手段と、
   前記復号化手段で復号化されたブロックデータから構成される前記所望のファイルを編集して、該所望のファイルになされた編集内容を示す編集データを得る編集手段と、
   前記編集手段で得られた編集データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集データを得る暗号化手段と、
   前記暗号化手段で得られた暗号化編集データを前記ファイル管理サーバ装置に送る通信手段とを備え、
   前記ファイル管理サーバ装置は前記クライアント装置から受取った暗号化編集データと前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理することを特徴とするファイル編集システム。
3. 各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、
   ファイル編集を行なう少なくとも一つのクライアント装置とから構成され、
   前記クライアント装置は、
   前記ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータをブロック単位で取得し、所定の復号鍵を用いてブロック単位で復号化する復号化手段と、
   前記復号化手段で復号化されたブロックデータから構成される前記所望のファイルの所望のバージョンを編集する編集手段と、
   前記編集手段で前記所望のファイルの所望のバージョンに対してなされた編集内容を得る手続を示す編集手続データを生成する編集手続生成手段と、
   前記編集手続生成手段で生成された前記所望のファイルの所望のバージョンに対する編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する編集手続データに変換する編集手続変換手段と、
   前記編集手段でなされた編集の結果を示す履歴管理情報を、前記編集手続変換手段で得られた前記所望のファイルの最新バージョンに対する編集手続データに基づいて生成する履歴管理情報生成手段と、
   前記履歴管理情報生成手段で生成された履歴管理情報を、所定の暗号鍵を用いてブロック単位で暗号化して、暗号化履歴管理情報を得る暗号化手段と、
   前記暗号化手段で得られた暗号化履歴管理情報を前記ファイル管理サーバ装置に送る通信手段とを備え、
   前記ファイル管理サーバ装置は前記クライアント装置から受取った暗号化履歴管理情報と前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理する履歴管理手段を含むことを特徴とするファイル編集システム。
4. 各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含むファイルを管理するファイル管理サーバ装置と、
   ファイル編集を行なう少なくとも一つのクライアント装置とから構成され、
   前記クライアント装置は、
   前記ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータをブロック単位で取得し、所定の復号鍵を用いて復号化する復号化手段と、
   前記復号化手段で復号化されたブロックデータから構成される前記所望のファイルの所望のバージョンを編集する編集手段と、
   前記編集手段で前記所望のファイルの所望のバージョンに対してなされた編集内容を得る手続を示し、該所望のファイルに挿入される挿入データを含んだ編集手続データを生成する編集手続生成手段と、
   前記編集手続生成手段で生成された編集手続データに含まれる挿入データを所定の暗号鍵を用いて暗号化して、暗号化編集手続データを得る暗号化手段と、
   前記暗号化手段で得られた暗号化編集手続データを前記ファイル管理サーバ装置に送る通信手段とを備え、
   前記ファイル管理サーバ装置は、
   前記クライアント装置から受取った前記所望のファイルの所望のバージョンに対する暗号化編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する暗号化編集手続データに変換する編集手続変換手段と、
   前記編集手段でなされた編集の結果を示す履歴管理情報を、前記編集手続変換手段で得られた前記所望のファイルの最新バージョンに対する暗号化編集手続データに基づいて生成する履歴管理情報生成手段と、
   前記履歴管理情報生成手段で生成された履歴管理情報と前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理する履歴管理手段とを含むことを特徴とするファイル編集システム。
5. 各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含むファイルを管理するファイル管理サーバ装置と、
   前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータを取得し、該ファイル管理サーバ装置から得たブロックデータで構成される前記所望のファイルを編集する、複数のクライアント装置と、
   前記複数のクライアント装置による非同期編集をサポートする非同期編集サポート手段とから構成され、
   前記非同期編集サポート手段は、
   各クライアント装置により前記所望のファイルに対してなされた編集内容を得る手続を示す編集手続データを生成する編集手続生成手段と、
   前記編集手続生成手段で生成された前記所望のファイルの所望のバージョンに対する編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまで の編集手続データに基づいて、前記最新バージョンに対する編集手続データに変換する編集手続変換手段と、
   各クライアント装置により前記所望のファイルになされた編集の結果を示す履歴管理情報を、前記編集手続変換手段で得られた前記所望のファイルの最新バージョンに対する編集手続データに基づいて生成する履歴管理情報生成手段とを含み、
   前記ファイル管理サーバ装置は前記履歴管理情報と前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理することを特徴とする共有ファイル編集システム。
6. 請求項１又は２記載のファイル編集システムにおいて、
   前記クライアント装置は前記所望のファイルの所望のバージョンに対応するブロックデータを前記ファイル管理サーバ装置から取得し、該ファイル管理サーバ装置は該クライアント装置から受取った前記所望のファイルの所望のバージョンに対する暗号化編集データに基づいて前記所望のファイルの履歴管理を行なう履歴管理手段を含むものであることを特徴とするファイル編集システム。
7. 請求項１又は２記載のファイル編集システムにおいて、
   前記クライアント装置は前記所望のファイルの所望のバージョンに対応するブロックデータを前記ファイル管理サーバ装置から取得し、該ファイル管理サーバ装置は該クライアント装置から受取った前記所望のファイルの最新のバージョンに対する暗号化編集データに基づいて前記所望のファイルの履歴管理を行なう履歴管理手段を含むものであることを特徴とするファイル編集システム。
8. 請求項１又は２記載のファイル編集システムにおいて、
   前記ファイル管理サーバ装置は、二つ以上のクライアント装置からの同一ファイルに対するアクセス要求を非同期に受け付けて、該二つ以上のクライアント装置が該同一ファイルに対する非同期編集を行なうようにするものであることを特徴とするファイル編集システム。
9. 請求項１から４のいずれかに記載のファイル編集システムにおいて、
   前記ファイル管理サーバ装置は、各ブロックデータをストリーム暗号方式で暗号化された状態で管理し、前記暗号化手段は前記編集データ又は前記履歴管理情報又は前記挿入データをストリーム暗号方式で暗号化することを特徴とするファイル編集システム。
10. 請求項１、２又は５記載のファイル編集システム又は共有ファイル編集システムにおいて、
    前記クライアント装置は、前記ファイル管理サーバ装置から取得した複数のブロックデータを新たなブロックデータに再構成するブロックデータ再構成手段と、該ブロックデータ再構成手段で得られた新しいブロックデータを該ファイル管理サーバ装置に送る手段とを含み、該ファイル管理サーバ装置は該クライアント装置から受取った新たなブロックデータに基づいて前記所望のファイルを管理することを特徴とするファイル編集システム又は共有ファイル編集システム。
11. 請求項１、２又は５記載のファイル編集システム又は共有ファイル編集システムにおいて、
    前記クライアント装置は、前記所望のファイルの以前アクセスされたバージョンを格納するファイル記憶手段と、前記ファイル記憶手段に格納されている以前アクセスされたバージョンと前記ファイル管理サーバ装置から取得した前記所望のファイルに属するブロックデータとに基づいて、前記所望のファイルの所望のバージョンを構築するファイルデータ構築手段と、を含み、
    前記ファイル管理サーバ装置は、前記クライアント装置に与えるブロックデータを、前記以前アクセスされたバージョンと前記所望のバージョンとの差分を求めることで構築する差分構築手段を含む
    ことを特徴とするファイル編集システム又は共有ファイル編集システム。
12. 請求項１、２又は５記載のファイル編集システム又は共有ファイル編集システムにおいて、
    前記クライアント装置は、
    前記ファイル管理サーバ装置が管理する暗号化されたファイル又は共有ファイルに対するアクセス要求をオペレーティングシステムが提供するシステムコールにより発行するアクセス要求手段と、
    前記システムコールに対応するアドレスポインタを登録するシステムコールテーブル手段と、
    前記クライアント装置から前記ファイル管理サーバ装置に送るファイルアクセス要求を、前記アクセス要求手段が発行したアクセス要求で指定されるシステムコールに対応する前記アドレスポインタに基づいて求めるファイルアクセス処理手段と、
    を含むものであることを特徴とするファイル編集システム又は共有ファイル編集システム。
13. 請求項３又は４記載のファイル編集システムにおいて、
    前記履歴管理手段はそれにより前記所望のファイルの履歴管理を行なうものである履歴データを前記編集手続変換手段に送り、該編集手続変換手段は前記所望のファイルの最新のバージョンに対する編集手続データを前記履歴データによって示される前記所望のバージョンと前記最新バージョンとの関係に基づいて求めるものであることを特徴とするファイル編集システム。
14. 請求項３又は４記載のファイル編集システムにおいて、
    前記ファイル管理サーバ装置は各ファイルを、最初に生成されたファイル内容が暗号化された最初のブロックデータと、各編集の前のファイル内容と各編集の後のファイル内容の各差分が暗号化された以降のブロックデータと、各ブロックデータに付与されて各ブロックデータを同定する前記ブロックデータ識別情報とからなる形式で管理することを特徴とするファイル編集システム。
15. 請求項３又は４記載のファイル編集システムにおいて、
    前記ファイル管理サーバ装置は各ファイルを、最新の編集されたファイル内容が暗号化された最新のブロックデータと、各編集の前のファイル内容と各編集の後のファイル内容の各差分が暗号化された以前のブロックデータと、各ブロックデータに付与されて各ブロックデータを同定する前記ブロックデータ識別情報とからなる形式で管理することを特徴とするファイル編集システム。
16. 請求項３又は４記載のファイル編集システムにおいて、
    前記ファイル管理サーバ装置は各ファイルを、各ファイルに挿入された各内容が暗号化された挿入ブロックデータと、各ファイルから削除された各内容が暗号化された削除ブロックデータと、各ブロックデータに付与されて各ブロックデータの生成時点と消去時点を同定する前記ブロックデータ識別情報とからなる形式で管理することを特徴とするファイル編集システム。
17. 請求項１６記載のファイル編集システムにおいて、
    前記ファイル管理サーバ装置は、各ブロックデータを８ビットＣＦＢモード型暗号方式で暗号化された状態で管理し、前記暗号化手段は前記履歴管理情報又は前記挿入データを８ビットＣＦＢモード型暗号方式で暗号化することを特徴とするファイル編集システム。
18. 請求項３記載のファイル編集システムにおいて、
    前記履歴管理情報生成手段は前記編集手段でなされた編集の結果得られるブロックデータに対するブロック識別情報を前記履歴管理情報に対し付加し、前記通信手段は前記暗号化履歴管理情報を前記履歴管理情報に付加されたブロック識別情報と共に送ることを特徴とするファイル編集システム。
19. 請求項３又は４記載のファイル編集システムにおいて、
    前記履歴管理手段は前記編集手段でなされた編集の結果得られるブロックデータに対するブロック識別情報を前記暗号化履歴管理情報又は前記履歴管理情報に対し付加することを特徴とするファイル編集システム。
20. 請求項５記載の共有ファイル編集システムにおいて、
    前記ファイル管理サーバ装置は、
    該ファイル管理サーバ装置が管理する各ファイルの各バージョンに対応させて、各ファイルの各バージョンを現在編集中であるクライアント装置の数を計数するクライアント計数手段と、
    特定ファイルの特定バージョンを消去する要求に対し、該特定ファイルの該特定バージョンの消去の実行を、前記クライアント計数手段により計数されたクライアントの数が０になるまで遅延させる消去遅延手段と、
    を含むものであることを特徴とする共有ファイル編集システム。
21. 請求項５記載の共有ファイル編集システムにおいて、
    前記ファイル管理サーバ装置は、あるクライアント装置によりなされた編集手続データを前記編集手続変換手段により変換して得られた前記最新バージョンに対する編集手続データと、他のクライアント装置によりなされた編集手続データを前記編集手続変換手段により変換して得られた前記最新バージョンに対する編集手続データとを比較して競合するか否かを検出し、競合した場合に、その競合の検出を該あるクライアント装置に通知する編集競合検出手段を含むものであることを特徴とする共有ファイル編集システム。
22. 請求項２１記載の共有ファイル編集システムにおいて、
    前記ファイル管理サーバ装置は更に、前記編集競合検出手段が該あるクライアント装置についての競合の発生を検出しない時のみ、前記非同期編集サポート手段で前記あるクライアント装置に対して得られた履歴管理情報に基づいて前記所望のファイルの履歴管理を行なう履歴管理手段を含むものであることを特徴とする共有ファイル編集システム。
23. 各ファイルが、履歴管理に必要なバージョン間の差分に対応する複数のブロックデータと各ブロックのブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置からなるファイル管理システムにおいてファイルを編集する方法であって、
    前記クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルに属するブロックデータを取得するステップと、
    前記クライアント装置において、前記ファイル管理サーバ装置から取得したブロックデータを所定の復号鍵を用いてブロック単位で復号化するステップと、
    前記クライアント装置において、前記復号化するステップで復号化されたブロックデータから構成される前記所望のファイルを編集して、該所望のファイルになされた編集内容を示す編集データを得るステップと、
    前記クライアント装置において、前記編集するステップで得られた編集データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集データを得る暗号化するステップと、
    前記暗号化するステップで得られた暗号化編集データを前記クライアント装置から前記ファイル管理サーバ装置に送るステップと、
    前記ファイル管理サーバ装置が前記クライアント装置から受取った暗号化編集データと前記各ブロックデータのブロック識別情報とに基づいて前記差分に対応するブロック単位で前記所望のファイルを管理するステップと、
    から成ることを特徴とするファイル編集方法。
24. 各ファイルが、履歴管理に必要な複数のブロックデータと、対応するブロックデータの生成時と消去時のバージョン情報を有するブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置からなるファイル管理システムにおいてファイルを編集する方法であって、
    前記クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルに属するブロックデータを取得するステップと、
    前記クライアント装置において、前記ファイル管理サーバ装置から取得したブロックデ ータを所定の復号鍵を用いてブロック単位で復号化するステップと、
    前記クライアント装置において、前記復号化するステップで復号化されたブロックデータから構成される前記所望のファイルを編集して、該所望のファイルになされた編集内容を示す編集データを得るステップと、
    前記クライアント装置において、前記編集するステップで得られた編集データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集データを得る暗号化するステップと、
    前記暗号化するステップで得られた暗号化編集データを前記クライアント装置から前記ファイル管理サーバ装置に送るステップと、
    前記ファイル管理サーバ装置が前記クライアント装置から受取った暗号化編集データと前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理するステップと、
    から成ることを特徴とするファイル編集方法。
25. 各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含み、かつ前記ブロックデータがブロック単位で暗号化されているファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置からなるファイル管理システムにおいてファイルを編集する方法であって、
    前記クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータを取得するステップと、
    前記クライアント装置において、前記ファイル管理サーバ装置から取得したブロックデータを所定の復号鍵を用いてブロック単位で復号化するステップと、
    前記クライアント装置において、前記復号化するステップで復号化されたブロックデータから構成される前記所望のファイルの所望のバージョンを編集するステップと、
    前記クライアント装置において、前記編集するステップで前記所望のファイルの所望のバージョンに対してなされた編集内容を得る手続を示す編集手続データを生成するステップと、
    前記クライアント装置において、前記編集手続データを生成するステップで生成された前記所望のファイルの所望のバージョンに対する編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する編集手続データに変換するステップと、
    前記クライアント装置において、前記編集するステップでなされた編集の結果を示す履歴管理情報を、前記変換するステップで得られた前記所望のファイルの最新バージョンに対する編集手続データに基づいて生成するステップと、
    前記クライアント装置において、前記履歴管理情報を生成するステップで生成された履歴管理情報を所定の暗号鍵を用いてブロック単位で暗号化して暗号化履歴管理情報を得る暗号化するステップと、
    前記暗号化するステップで得られた暗号化履歴管理情報を前記クライアント装置から前記ファイル管理サーバ装置に送るステップと、
    前記ファイル管理サーバ装置において、前記クライアント装置から受取った暗号化履歴管理情報と前記各ブロックのブロック識別情報とに基づいて前記所望のファイルを管理するステップと、
    から成ることを特徴とするファイル編集方法。
26. 各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含むファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう少なくとも一つのクライアント装置からなるファイル管理システムにおいてファイルを編集する方法であって、
    前記クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータを取得するステップと、
    前記クライアント装置において、前記ファイル管理サーバ装置から取得したブロックデータを所定の復号鍵を用いて復号化するステップと、
    前記クライアント装置において、前記復号化するステップで復号化されたブロックデータから構成される前記所望のファイルの所望のバージョンを編集するステップと、
    前記クライアント装置において、前記編集するステップで前記所望のファイルの所望のバージョンに対してなされた編集内容を得る手続を示し、該所望のファイルに挿入される挿入データを含んだ編集手続データを生成するステップと、
    前記クライアント装置において、前記編集手続データを生成するステップで生成された編集手続データに含まれる挿入データを所定の暗号鍵を用いてブロック単位で暗号化して暗号化編集手続データを得る暗号化するステップと、
    前記暗号化するステップで得られた暗号化編集手続データを前記クライアント装置から前記ファイル管理サーバ装置に送るステップと、
    前記ファイル管理サーバ装置において、前記クライアント装置から受取った前記所望のファイルの所望のバージョンに対する暗号化編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する暗号化編集手続データに変換するステップと、
    前記ファイル管理サーバ装置において、前記編集するステップでなされた編集の結果を示す履歴管理情報を、前記変換するステップで得られた前記所望のファイルの最新バージョンに対する暗号化編集手続データに基づいて生成するステップと、
    前記ファイル管理サーバ装置において、前記履歴管理情報を生成するステップで生成された履歴管理情報と前記各ブロックのブロック識別情報とに基づいて前記所望のファイルを管理するステップと、
    から成ることを特徴とするファイル編集方法。
27. 各ファイルが複数のブロックデータと各ブロックのブロック識別情報とを含むファイルを管理するファイル管理サーバ装置と、ファイル編集を行なう複数のクライアント装置からなる共有ファイル管理システムにおいてファイルを編集する方法であって、
    各クライアント装置において、前記ファイル管理サーバ装置にアクセスして該ファイル管理サーバ装置が管理する所望のファイルの所望のバージョンに対応するブロックデータを取得するステップと、
    各クライアント装置において、前記取得するステップで前記ファイル管理サーバ装置から取得したブロックデータによって構成される前記所望のファイルの所望のバージョンを編集するステップと、
    各クライアント装置により前記所望のファイルになされた編集内容を得る手続を示す編集手続データを生成するステップと、
    前記編集手続データを生成するステップで生成された前記所望のファイルの所望のバージョンに対する編集手続データを、別途既になされた前記所望のバージョンから最新バージョンに至るまでの編集手続データに基づいて、前記最新バージョンに対する編集手続データに変換するステップと、
    各クライアント装置により前記所望のファイルになされた編集の結果を示す履歴管理情報を、前記変更するステップで得られた前記所望のファイルの最新バージョンに対する編集手続データに基づいて生成するステップと、
    前記ファイル管理サーバ装置が前記履歴管理情報と前記各ブロックデータのブロック識別情報とに基づいて前記所望のファイルを管理するステップと、
    から成ることを特徴とする共有ファイル編集方法。

Images