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

Abstract

(57)【要約】 【目的】 ファイルのバージョン管理、ファイルの内容
のサーバに対する秘匿性、非同期編集を同時に実現した
共有ファイル編集システムを提供すること。 【構成】 ファイルサーバと複数のアクセス要求クライ
アントを備え、同一ファイルへの複数アクセスを許す共
有ファイル編集システムにおいて、ファイルは複数のブ
ロックデータとブロック識別情報を含みデータはブロッ
ク単位で暗号化され、アクセス要求クライアントは、サ
ーバから得た所望のバージョンのファイルをブロック毎
に復号化する手段と、ファイル編集手段と、編集の手続
きを該ファイルのサーバ内での最新バージョンに対する
編集手続きに変換する手段と、変換結果から作成した編
集データを暗号化する手段と、暗号化された編集データ
をサーバに出力する手段を備え、サーバは、クライアン
トから受け取った編集データと、ブロック識別情報に基
づいて該ファイルの履歴管理を行う手段を備える。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はファイル編集システムに
係わり、特に、計算機の共有ファイル・システムやデー
タベース・システムにおいて、複数ユーザからの共有フ
ァイルの非同期編集や、ファイルの内容の読み出し保護
を実現したものに関する。

【０００２】

【従来の技術】計算機システムにおいて、システム内の
資源に対する複数ユーザからのアクセスを管理するため
には、アクセス要求を出したユーザが当該資源に対する
アクセス権を有する正規のユーザであるか否かを確認す
るための認証機構が必要であることが指摘されてきた。
特に、システムが巨大化し遠隔ユーザからのアクセスを
認める環境では、認証機構の重要性が増してくる。この
ような機構を実現する代表的な認証システムとしては、
Ｋｅｒｂｅｒｏｓなどがある。

【０００３】こうした認証機構の必要となる典型的なシ
ステムとしては、ＣＳＣＷ（Ｃｏｍｕｐｕｔｅｒ Ｓｕ
ｐｐｏｒｔｅｄ Ｃｏｏｐｅｒａｔｉｖｅ Ｗｏｒｋ）
システムが挙げられる。ＣＳＣＷは複数ユーザの協調作
業を支援する計算機システムの総称であり、その典型的
・根本的なものに共有ファイル・システムがある。共有
ファイル・システムでは、複数ユーザが同一のファイル
に対して“ｒｅａｄ”“ｗｒｉｔｅ”などのアクセス権
を有し、同時に同一のファイルに対してそれらアクセス
を許しながら、矛盾を生じることなく編集作業を実行で
きる。

【０００４】従来、このような共有ファイル・システム
を実現する一般的な形態は、ファイルにアクセスする主
体としてのクライアントと、ファイルを管理するサーバ
とに分離したクライアント・サーバ型を採り、クライア
ントからのアクセスの認証を行う認証システムを実装す
るものである。すなわち、サーバはクライアントが正規
のアクセス権を保持しているか否かを認証し、さらに必
要であればクライアントとサーバ間で送受されるデータ
を暗号化したり、クライアント側が接続相手が所望のサ
ーバであるか否かの認証などを実現するものである。

【０００５】こうした共有ファイル・システムが広域化
していくにつれ、例えば、あるサイトにファイル・サー
バだけを実現するといったサービス形態が要求されるも
のと考えられる。すなわち、ファイルの保管とアクセス
管理は提供するが、ファイルの内容自体はサーバ内では
一切読み取れないような形態である。しかしながら、こ
のようなサービスは、従来のセキュリティ・システムで
は実現できない。なぜなら、通信データは保護している
が、ファイルの内容はサーバ内では平文の形式で管理さ
れているからである。

【０００６】また、共有ファイルにおいて同時編集を実
現する従来のメカニズムでは、同一のファイルに対して
あるユーザが書き込みを伴う編集を行っている間は、他
のユーザは高々“ｒｅａｄ”しかできないように制限さ
れる。これは厳密な意味での同時編集ではなく、ロック
機構を利用して複数ユーザのアクセス間で矛盾の生じな
いように同期を取る“同期編集”を実現しているのみで
あった。すなわち、最初のアクセス要求者がファイルに
アクセスする間、ロック機構が作動して他の要求者から
の“ｗｒｉｔｅ”のためのファイル・アクセス要求は許
可されなくなり、他の要求者はファイル・アクセスを一
時見合わせてロックの解除を待ち、ロックが解除された
後に再度ファイルにアクセスするようにしていた。

【０００７】これに対し、あるユーザが書き込みを伴う
編集を行っている場合であっても他のユーザが同一ファ
イルに対して書き込みを伴う編集が可能であるようにで
きれば、より柔軟なシステムとなる。以下、このような
操作を、複数ユーザがランダムに発生するアクセス間の
同期をとる必要がないという意味で、“非同期編集”と
呼ぶ。

【０００８】一方、共有ファイル・システムに関連した
もう一つの技術として、バージョン管理技術がある。従
来のバージョン管理法には、ＳＣＣＣ（Ｓｏｕｒｃｅ
Ｃｏｄｅ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）やＲＣＳ
（Ｒｅｖｉｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）
がある。これらの管理法は、プログラム開発を複数の人
員で行うような場合に、ある時点におけるファイル全体
を全て保存しておく変わりに差分だけを保管していくこ
とにより、ファイル・サイズの圧縮を図るものである。
しかしながら、ファイル・サイス面では大きな改善が達
成できているものの、共有ファイル・システムでの実現
ではロック機構を用いた同期編集しか考慮されていなか
った。

【０００９】

【発明が解決しようとする課題】以上説明したように、
従来の共有ファイルの編集を行うためにクライアント・
サーバ型の共有ファイル編集システムでは、ファイルの
内容をファイル・サーバに対して秘密にできないこと、
同時編集はロックを掛けることにより実現されるため同
時に複数のアクセス要求者による書き込みを伴う編集す
なわち非同期編集ができないことなどの問題点があっ
た。

【００１０】本発明は、上記問題点を考慮してなされた
ものであり、ファイルの内容をファイル・サーバからは
読み取ることのできない秘匿性の高いファイル編集シス
テムを提供することを目的とする。

【００１１】また、本発明は、ファイルのバージョン管
理をサポートする共有ファイル編集システムであって、
非同期編集処理を行うことが可能な共有ファイル編集シ
ステムを提供することを目的とする。

【００１２】また、本発明は、ファイルのバージョン管
理をサポートする共有ファイル編集システムであって、
ファイルの内容をファイル・サーバに対して秘密にしな
がら、非同期編集処理を行うことが可能となる共有ファ
イル編集システムを提供することを目的とする。

【００１３】

【課題を解決するための手段】本発明（請求項１）で
は、各ファイルが複数のブロックデータと各ブロックの
ブロック識別情報とを含み、かつ前記ブロックデータが
ブロック単位で暗号化されているファイルを、前記各ブ
ロックのブロック識別情報に基づいて管理するファイル
管理サーバ装置と、ファイル編集を行なう少なくとも一
つのクライアント装置とから構成され、前記クライアン
ト装置は、前記ファイル管理サーバ装置にアクセスして
取得した、該ファイル管理サーバ装置が管理する所望の
ファイルに属するブロックデータを、所定の復号鍵を用
いてブロック単位で復号化する復号化手段と、前記復号
化手段で復号化されたブロックデータから構成される前
記所望のファイルを編集して、該所望のファイルになさ
れた編集内容を示す編集データを得る編集手段と、前記
編集手段で得られた編集データを所定の暗号鍵を用いて
ブロック単位で暗号化して暗号化編集データを得る暗号
化手段と、前記暗号化手段で得られた暗号化編集データ
を前記ファイル管理サーバ装置に送る通信手段とを備
え、前記ファイル管理サーバ装置は前記クライアント手
段から受取った暗号化編集データに基づいて前記所望の
ファイルを管理することを特徴とする。

【００１４】また、本発明（請求項２）では、各ファイ
ルが複数のブロックデータと各ブロックのブロック識別
情報とを含み、かつ前記ブロックデータがブロック単位
で暗号化されているファイルを管理するファイル管理サ
ーバ装置と、ファイル編集を行なう少なくとも一つのク
ライアント装置とから構成され、前記クライアント装置
は、前記ファイル管理サーバ装置にアクセスして取得し
た、該ファイル管理サーバ装置が管理する所望のファイ
ルの所望のバージョンに対応するブロックデータを、所
定の復号鍵を用いてブロック単位で復号化する復号化手
段と、前記復号化手段て復号化されたブロックデータか
ら構成される前記所望のファイルの所望のバージョンを
編集する編集手段と、前記編集手段で前記所望のファイ
ルの所望のバージョンに対してなされた編集内容を得る
手続を示す編集手続データを生成する編集手続生成手段
と、前記編集手続生成手段で生成された前記所望のファ
イルの所望のバージョンに対する編集手続データを、所
望のファイルの最新バージョンに対する編集手続データ
に変換する編集手続変換手段と、前記編集手段でなされ
た編集の結果を示す履歴管理情報を、前記編集手続変換
手段で得られた前記所望のファイルの最新バージョンに
対する編集手続データに基づいて生成する履歴管理情報
生成手段と、前記履歴管理情報生成手段で生成された履
歴管理情報を、所定の暗号鍵を用いてブロック単位で暗
号化して、暗号化履歴管理情報を得る暗号化手段と、前
記暗号化手段で得られた暗号化履歴管理情報を前記ファ
イル管理サーバ装置に送る通信手段とを備え、前記ファ
イル管理サーバ装置は前記クライアント装置から受取っ
た暗号化履歴管理情報と前記各ブロックデータのブロッ
ク識別情報とに基づいて前記所望のファイルを管理する
履歴管理手段を含むことを特徴とする。

【００１５】また、本発明（請求項３）では、各ファイ
ルが複数のブロックデータと各ブロックのブロック識別
情報とを含むファイルを管理するファイル管理サーバ装
置と、ファイル編集を行なう少なくとも一つのクライア
ント装置とから構成され、前記クライアント装置は、前
記ファイル管理サーバ装置にアクセスして取得した、該
ファイル管理サーバ装置が管理する所望のファイルの所
望のバージョンに対応するブロックデータを、所定の復
号鍵を用いて復号化する復号化手段と、前記復号化手段
で復号化されたブロックデータから構成される前記所望
のファイルの所望のバージョンを編集する編集手段と、
前記編集手段で前記所望のファイルの所望のバージョン
に対してなされた編集内容を得る手続を示し、該所望の
ファイルに挿入される挿入データを含んだ編集手続デー
タを生成する編集手続生成手段と、前記編集手続生成手
段で生成された編集手続データに含まれる挿入データを
所定の暗号鍵を用いて暗号化して、暗号化編集手続デー
タを得る暗号化手段と、前記暗号化手段で得られた暗号
化編集手続データを前記ファイル管理サーバ装置に送る
通信手段とを備え、前記ファイル管理サーバ装置は、前
記クライアント装置から受取った前記所望のファイルの
所望のバージョンに対する暗号化編集手続データを、所
望のファイルの最新バージョンに対する暗号化編集手続
データに変換する編集手続変換手段と、前記編集手段で
なされた編集の結果を示す履歴管理情報を、前記編集手
続変換手段で得られた前記所望のファイルの最新バージ
ョンに対する暗号化編集手続データに基づいて生成する
履歴管理情報生成手段と、前記履歴管理情報生成手段で
生成された履歴管理情報と前記各ブロックデータのブロ
ック識別情報とに基づいて前記所望のファイルを管理す
る履歴管理手段とを含むことを特徴とする。

【００１６】また、本発明（請求項４）では、各ファイ
ルが複数のブロックデータと各ブロックのブロック識別
情報とを含むファイルを管理するファイル管理サーバ装
置と、前記ファイル管理サーバ装置にアクセスして該フ
ァイル管理サーバ装置が管理する所望のファイルの所望
のバージョンに対応するブロックデータを取得し、該フ
ァイル管理サーバ装置から得たブロックデータで構成さ
れる前記所望のファイルを編集する、複数のクライアン
ト装置と、前記複数のクライアント装置による非同期編
集をサポートする非同期編集サポート手段とから構成さ
れ、前記非同期編集サポート手段は、各クライアント装
置により前記所望のファイルに対してなされた編集内容
を得る手続を示す編集手続データを生成する編集手続生
成手段と、前記編集手続生成手段で生成された前記所望
のファイルの所望のバージョンに対する編集手続データ
を、所望のファイルの最新バージョンに対する編集手続
データに変換する編集手続変換手段と、各クライアント
装置により前記所望のファイルになされた編集の結果を
示す履歴管理情報を、前記編集手続変換手段で得られた
前記所望のファイルの最新バージョンに対する編集手続
データに基づいて生成する履歴管理情報生成手段とを含
み、前記ファイル管理サーバ装置は前記履歴管理情報と
前記各ブロックデータのブロック識別情報とに基づいて
前記所望のファイルを管理することを特徴とする。

【００１７】また、本発明（請求項５）では、上記（請
求項１）において、前記クライアント装置は前記所望の
ファイルの所望のバージョンに対応するブロックデータ
を前記ファイル管理サーバ装置から取得し、該ファイル
管理サーバ装置は該クライアント装置から受取った前記
所望のファイルの所望のバージョンに対する暗号化編集
データに基づいて前記所望のファイルの履歴管理を行な
う履歴管理手段を含むものであることを特徴とする。

【００１８】また、本発明（請求項６）では上記（請求
項１）において、前記クライアント装置は前記所望のフ
ァイルの所望のバージョンに対応するブロックデータを
前記ファイル管理サーバ装置から取得し、該ファイル管
理サーバ装置は該クライアント装置から受取った前記所
望のファイルの最新のバージョンに対する暗号化編集デ
ータに基づいて前記所望のファイルの履歴管理を行なう
履歴管理手段を含むものであることを特徴とする。

【００１９】また、本発明（請求項７）では、上記（請
求項）において、前記ファイル管理サーバ装置は、二つ
以上のクライアント装置からの同一ファイルに対するア
クセス要求を非同期に受け付けて、該二つ以上のクライ
アント装置が該同一ファイルに対する非同期編集を行な
うようにするものであることを特徴とする。

【００２０】また、本発明（請求項８）では、上記（請
求項１から３のいずれか）において、前記ファイル管理
サーバ装置は、各ブロックデータをストリーム暗号方式
で暗号化された状態で管理し、前記暗号化手段は前記編
集データ又は前記履歴管理情報又は前記挿入データをス
トリーム暗号方式で暗号化することを特徴とする。

【００２１】また、本発明（請求項９）では、上記（請
求項１又は４）において、前記クライアント装置は、前
記ファイル管理サーバ装置から取得した複数のブロック
データを新たなブロックデータに再構成するブロックデ
ータ再構成手段と、該ブロックデータ再構成手段で得ら
れた新しいブロックデータを該ファイル管理サーバ装置
に送る手段とを含み、該ファイル管理サーバ装置は該ク
ライアント装置から受取った新たなブロックデータに基
づいて前記所望のファイルを管理することを特徴とす
る。

【００２２】また、本発明（請求項１０）では、上記
（請求項１又は４）において、前記クライアント装置
は、前記所望のファイルの以前アクセスされたバージョ
ンを格納するファイル記憶手段と、前記ファイル記憶手
段に格納されている以前アクセスされたバージョンと前
記ファイル管理サーバ装置から取得した前記所望のファ
イルに属するブロックデータとに基づいて、前記所望の
ファイルの所望のバージョンを構築するファイルデータ
構築手段と、を含み、前記ファイル管理サーバ装置は、
前記クライアント装置に与えるブロックデータを、前記
以前アクセスされたバージョンと前記所望のバージョン
との差分を求めることで構築する差分構築手段を含むこ
とを特徴とする。

【００２３】また、本発明（請求項１１）では、上記
（請求項１又は４）において、前記クライアント装置
は、前記ファイル管理サーバ装置が管理する暗号化され
たファイル又は共有ファイルに対するアクセス要求をオ
ペレーティングシステムが提供するシステムコールによ
り発行するアクセス要求手段と、前記システムコールに
対応するアドレスポインタを登録するシステムコールテ
ーブル手段と、前記クライアント装置から前記ファイル
管理サーバ装置に送るファイルアクセス要求を、前記ア
クセス要求手段が発行したアクセス要求で指定されるシ
ステムコールに対応する前記アドレスポインタに基づい
て求めるファイルアクセス処理手段と、を含むものであ
ることを特徴とする。

【００２４】また、本発明（請求項１２）では、上記
（請求項２又は３）において、前記履歴管理手段はそれ
により前記所望のファイルの履歴管理を行なうものであ
る履歴データを前記編集手続変換手段に送り、該編集手
続変換手段は前記所望のファイルの最新のバージョンに
対する編集手続データを前記履歴データによって示され
る前記所望のバージョンと前記最新バージョンとの関係
に基づいて求めるものであることを特徴とする。

【００２５】また、本発明（請求項１３）では、上記
（請求項２又は３）において、前記ファイル管理サーバ
装置は各ファイルを、最初に生成されたファイル内容が
暗号化された最初のブロックデータと、各編集の前のフ
ァイル内容と各編集の後のファイル内容の各差分が暗号
化された以降のブロックデータと、各ブロックデータに
付与されて各ブロックデータを同定する前記ブロックデ
ータ識別情報とからなる形式で管理することを特徴とす
る。

【００２６】また、本発明（請求項１４）では、上記
（請求項２又は３）において、前記ファイル管理サーバ
装置は各ファイルを、最新の編集されたファイル内容が
暗号化された最新のブロックデータと、各編集の前のフ
ァイル内容と各編集の後のファイル内容の各差分が暗号
化された以前のブロックデータと、各ブロックデータに
付与されて各ブロックデータを同定する前記ブロックデ
ータ識別情報とからなる形式で管理することを特徴とす
る。

【００２７】また、本発明（請求項１５）では、上記
（請求項２又は３）において、前記ファイル管理サーバ
装置は各ファイルを、各ファイルに挿入された各内容が
暗号化された挿入ブロックデータと、各ファイルから削
除された各内容が暗号化された削除ブロックデータと、
各ブロックデータに付与されて各ブロックデータの生成
時点と消去時点を同定する前記ブロックデータ識別情報
とからなる形式で管理することを特徴とする。

【００２８】また、本発明（請求項１６）では、上記
（請求項１５）において、前記ファイル管理サーバ装置
は、各ブロックデータを８ビットＣＦＢモード型暗号方
式で暗号化された状態で管理し、前記暗号化手段は前記
履歴管理情報又は前記挿入データを８ビットＣＦＢモー
ド型暗号方式で暗号化することを特徴とする。

【００２９】また、本発明（請求項１７）では、上記
（請求項２）において、前記履歴管理情報生成手段は前
記編集手段でなされた編集の結果得られるブロックデー
タに対するブロック識別情報を前記履歴管理情報に対し
付加し、前記通信手段は前記暗号化履歴管理情報を前記
履歴管理情報に付加されたブロック識別情報と共に送る
ことを特徴とする。

【００３０】また、本発明（請求項１８）では、上記
（請求項２又は３）において、前記履歴管理手段は前記
編集手段でなされた編集の結果得られるブロックデータ
に対するブロック識別情報を前記暗号化履歴管理情報又
は前記履歴管理情報に対し付加することを特徴とする。

【００３１】また、本発明（請求項１９）では、上記
（請求項４）において、前記ファイル管理サーバ装置
は、該ファイル管理サーバ装置が管理する各ファイルの
各バージョンに対応させて、各ファイルの各バージョン
を現在編集中であるクライアント装置の数を計数するク
ライアント計数手段と、特定ファイルの特定バージョン
を消去する要求に対し、該特定ファイルの該特定バージ
ョンの消去の実行を、前記クライアント計数手段により
計数されたクライアントの数が０になるまで遅延させる
消去遅延手段と、を含むものであることを特徴とする。

【００３２】また、本発明（請求項２０）では、上記
（請求項４）において、前記ファイル管理サーバ装置
は、あるクライアント装置によりなされた編集内容と他
のクライアント装置によりなされた他の編集内容との競
合の発生を検出して、検出された競合の発生を該あるク
ライアント装置に通知する編集競合検出手段を含むもの
であることを特徴とする。

【００３３】また、本発明（請求項２１）では、上記
（請求項２０）において、前記ファイル管理サーバ装置
は更に、前記編集競合検出手段が該あるクライアント装
置についての競合の発生を検出しない時のみ、前記非同
期編集サポート手段で前記あるクライアント装置に対し
て得られた履歴管理情報に基づいて前記所望のファイル
の履歴管理を行なう履歴管理手段を含むものであること
を特徴とする。

【００３４】また、本発明（請求項２２）では、各ファ
イルが複数のブロックデータと各ブロックのブロック識
別情報とを含み、かつ前記ブロックデータがブロック単
位で暗号化されているファイルを管理するファイル管理
サーバ装置と、ファイル編集を行なう少なくとも一つの
クライアント装置からなるファイル管理システムにおい
てファイルを編集する方法であって、前記クライアント
装置において、前記ファイル管理サーバ装置にアクセス
して該ファイル管理サーバ装置が管理する所望のファイ
ルに属するブロックデータを取得するステップと、前記
クライアント装置において、前記ファイル管理サーバ装
置から取得したブロックデータを所定の復号鍵を用いて
ブロック単位で復号化するステップと、前記クライアン
ト装置において、前記復号化するステップで復号化され
たブロックデータから構成される前記所望のファイルを
編集して、該所望のファイルになされた編集内容を示す
編集データを得るステップと、前記クライアント装置に
おいて、前記編集するステップで得られた編集データを
所定の暗号鍵を用いてブロック単位で暗号化して暗号化
編集データを得る暗号化するステップと、前記暗号化す
るステップで得られた暗号化編集データを前記クライア
ント装置から前記ファイル管理サーバ装置に送るステッ
プと、前記ファイル管理サーバ装置が前記クライアント
装置から受取った暗号化編集データに基づいて前記所望
のファイルを管理するステップと、から成ることを特徴
とする。

【００３５】また、本発明（請求項２３）では、各ファ
イルが複数のブロックデータと各ブロックのブロック識
別情報とを含み、かつ前記ブロックデータがブロック単
位で暗号化されているファイルを管理するファイル管理
サーバ装置と、ファイル編集を行なう少なくとも一つの
クライアント装置からなるファイル管理システムにおい
てファイルを編集する方法であって、前記クライアント
装置において、前記ファイル管理サーバ装置にアクセス
して該ファイル管理サーバ装置が管理する所望のファイ
ルの所望のバージョンに対応するブロックデータを取得
するステップと、前記クライアント装置において、前記
ファイル管理サーバ装置から取得したブロックデータを
所定の復号鍵を用いてブロック単位で復号化するステッ
プと、前記クライアント装置において、前記復号化する
ステップで復号化されたブロックデータから構成される
前記所望のファイルの所望のバージョンを編集するステ
ップと、前記クライアント装置において、前記編集する
ステップで前記所望のファイルの所望のバージョンに対
してなされた編集内容を得る手続を示す編集手続データ
を生成するステップと、前記クライアント装置におい
て、前記編集手続データを生成するステップで生成され
た前記所望のファイルの所望のバージョンに対する編集
手続データを、所望のファイルの最新バージョンに対す
る編集手続データに変換するステップと、前記クライア
ント装置において、前記編集するステップでなされた編
集の結果を示す履歴管理情報を、前記変換するステップ
で得られた前記所望のファイルの最新バージョンに対す
る編集手続データに基づいて生成するステップと、前記
クライアント装置において、前記履歴管理情報を生成す
るステップで生成された履歴管理情報を所定の暗号鍵を
用いてブロック単位で暗号化して暗号化履歴管理情報を
得る暗号化するステップと、前記暗号化するステップで
得られた暗号化履歴管理情報を前記クライアント装置か
ら前記ファイル管理サーバ装置に送るステップと、前記
ファイル管理サーバ装置において、前記クライアント装
置から受取った暗号化履歴管理情報と前記各ブロックの
ブロック識別情報とに基づいて前記所望のファイルを管
理するステップと、から成ることを特徴とする。

【００３６】また、本発明（請求項２４）では、各ファ
イルが複数のブロックデータと各ブロックのブロック識
別情報とを含むファイルを管理するファイル管理サーバ
装置と、ファイル編集を行なう少なくとも一つのクライ
アント装置からなるファイル管理システムにおいてファ
イルを編集する方法であって、前記クライアント装置に
おいて、前記ファイル管理サーバ装置にアクセスして該
ファイル管理サーバ装置が管理する所望のファイルの所
望のバージョンに対応するブロックデータを取得するス
テップと、前記クライアント装置において、前記ファイ
ル管理サーバ装置から取得したブロックデータを所定の
復号鍵を用いて復号化するステップと、前記クライアン
ト装置において、前記復号化するステップで復号化され
たブロックデータから構成される前記所望のファイルの
所望のバージョンを編集するステップと、前記クライア
ント装置において、前記編集するステップで前記所望の
ファイルの所望のバージョンに対してなされた編集内容
を得る手続を示し、該所望のファイルに挿入される挿入
データを含んだ編集手続データを生成するステップと、
前記クライアント装置において、前記編集手続データを
生成するステップで生成された編集手続データに含まれ
る挿入データを所定の暗号鍵を用いてブロック単位で暗
号化して暗号化編集手続データを得る暗号化するステッ
プと、前記暗号化するステップで得られた暗号化編集手
続データを前記クライアント装置から前記ファイル管理
サーバ装置に送るステップと、前記ファイル管理サーバ
装置において、前記クライアント装置から受取った前記
所望のファイルの所望のバージョンに対する暗号化編集
手続データを、所望のファイルの最新バージョンに対す
る暗号化編集手続データに変換するステップと、前記フ
ァイル管理サーバ装置において、前記編集するステップ
でなされた編集の結果を示す履歴管理情報を、前記変換
するステップで得られた前記所望のファイルの最新バー
ジョンに対する暗号化編集手続データに基づいて生成す
るステップと、前記ファイル管理サーバ装置において、
前記履歴管理情報を生成するステップで生成された履歴
管理情報と前記各ブロックのブロック識別情報とに基づ
いて前記所望のファイルを管理するステップと、から成
ることを特徴とする。

【００３７】また、本発明（請求項２５）では、各ファ
イルが複数のブロックデータと各ブロックのブロック識
別情報とを含むファイルを管理するファイル管理サーバ
装置と、ファイル編集を行なう複数のクライアント装置
からなる共有ファイル管理システムにおいてファイルを
編集する方法であって、各クライアント装置において、
前記ファイル管理サーバ装置にアクセスして該ファイル
管理サーバ装置が管理する所望のファイルの所望のバー
ジョンに対応するブロックデータを取得するステップ
と、各クライアント装置において、前記取得するステッ
プで前記ファイル管理サーバ装置から取得したブロック
データによって構成される前記所望のファイルの所望の
バージョンを編集するステップと、各クライアント装置
により前記所望のファイルになされた編集内容を得る手
続を示す編集手続データを生成するステップと、前記編
集手続データを生成するステップで生成された前記所望
のファイルの所望のバージョンに対する編集手続データ
を、所望のファイルの最新バージョンに対する編集手続
データに変換するステップと、各クライアント装置によ
り前記所望のファイルになされた編集の結果を示す履歴
管理情報を、前記変更するステップで得られた前記所望
のファイルの最新バージョンに対する編集手続データに
基づいて生成するステップと、前記ファイル管理サーバ
装置が前記履歴管理情報と前記各ブロックデータのブロ
ック識別情報とに基づいて前記所望のファイルを管理す
るステップと、とから成ることを特徴とする。

【００３８】

【作用】本発明（請求項１，５〜１１，２２）では、フ
ァイル管理サーバ装置に格納管理されるファイルは、デ
ータ部分と付加情報部分からなり、データ部分は複数の
ブロック・データからなり、付加情報部分は各ブロック
・データに付加されたブロック識別情報を含み、さら
に、各ブロック・データはブロック・データ単位で暗号
化されているとともに、データ構造の管理に必要なブロ
ック識別情報は暗号化されていない情報である。そし
て、クライアント装置は、ファイル管理サーバ装置に対
して所望のファイルをブロック・データ単位でアクセス
でき、保有している暗号鍵／復号鍵を用いて、該ブロッ
ク・データを暗号化／復号化する。また、ファイル管理
サーバ装置にはファイルの内容が秘匿されているが、デ
ータ構造の管理は実行させることができる。

【００３９】従って、ファイルの内容をファイル管理サ
ーバ装置からは読み取ることのできない秘匿性の高いフ
ァイル編集システムを提供することができる。

【００４０】また、クライアント装置は、ファイルのう
ちの必要なデータ・ブロックだけを通信により取得でき
るので、通信量の削減を図ることができるとともに、必
要なブロックだけを復号化／暗号化すれば良いので、ク
ライアント装置での処理量の削減、クライアント装置で
必要なバッファ（メモリ）の削減ができる利点もある。

【００４１】また、本発明（請求項２，８，１２〜１
８，２３）では、ファイル管理サーバ装置に格納管理さ
れるファイルは、データ部分と付加情報部分からなり、
データ部分は複数のブロック・データからなり、付加情
報部分は各ブロック・データに付加されたブロック識別
情報を含み、さらに、各ブロック・データはブロック・
データ単位で暗号化されているとともに、データ構造の
管理に必要なブロック識別情報は暗号化されていない情
報である。このブロック識別情報は、履歴を管理するた
めに用いられる。

【００４２】これによって、ファイルの内容は復号鍵を
持っている正規のクライアント装置からのみ読み取れ、
ファイルの内容をファイル管理サーバ装置からは読み取
ることのできないようにした秘匿性の高いファイル編集
システムを提供することができる。

【００４３】また、クライアント装置は、ファイル管理
サーバ装置に対して所望のバージョンのファイルをアク
セスし、該ファイルを編集した後、この編集の内容をフ
ァイル管理サーバ装置に送り、ファイル管理サーバ装置
は、前記クライアント装置から渡された編集の内容を示
すデータを、前記クライアント装置がアクセスして得た
バージョンがいずれであるかに従い、前記ファイル管理
サーバ装置内での最新のバージョンに対する編集内容に
変換する処理（マージ処理）を行う。

【００４４】従って、ファイル管理サーバ装置は、常に
各クライアント装置による編集終了時における最新バー
ジョンのファイルの内容に対する更新を行うので、ロッ
クを掛けずに複数のクライアント装置による非同期編集
を行うことが可能となる。

【００４５】また、時間的に古いバージョンを編集し、
最新バージョンとする使い方が可能となる。すなわち、
非同期編集可能な共有ファイルにおいて、編集対象を現
行版に限定しない使い方が可能となる。

【００４６】また、ファイルのデータ構造として、単純
に一つ前（あるいは後）のバージョンとの差分を残して
いくＲＣＳのような構造ではなく、変形ＳＣＣＳで利用
されているようなファイルの先頭から順番に挿入された
データが挿入された位置にブロックとして管理され、部
分的に消去された場合にはブロックの分割を繰り返して
いく方式に変形を加えて採用すると、ファイル管理サー
バ装置が行うマージ処理に必要となる挿入／削除の位置
の決定が極めて単純化され、非同期編集が容易となる。

【００４７】特に、ファイルのデータ構造として変形Ｓ
ＣＣＳ方式を用い、暗号方式としてストリーム暗号のう
ちの８ビットＣＦＢモードによる方式を用いると、ブロ
ックの分割においても再暗号化が不要になる利点があ
る。

【００４８】また、本発明（請求項３，８，１２〜１
６，１８，２４）では、ファイル管理サーバ装置に格納
管理されるファイルは、データ部分と付加情報部分から
なり、データ部分は複数のブロック・データからなり、
付加情報部分は各ブロック・データに付加されたブロッ
ク識別情報を含み、さらに、各ブロック・データはブロ
ック・データ単位で暗号化されているとともに、データ
構造の管理に必要なブロック識別情報は暗号化されてい
ない情報である。このブロック識別情報は、履歴を管理
するために用いられる。

【００４９】これによって、ファイルの内容は復号鍵を
持っている正規のクライアント装置からのみ読み取れ、
ファイルの内容をファイル管理サーバ装置からは読み取
ることのできないようにした秘匿性の高いファイル編集
システムを提供することができる。

【００５０】また、クライアント装置は、ファイル管理
サーバ装置に対して所望のバージョンのファイルをアク
セスし、該ファイルを編集した後、前記ファイル管理サ
ーバ装置に格納されている該ファイルの最新のバージョ
ンの内容と、この編集後の内容との差分を求め、この差
分に対応するブロック・データを作成してファイル管理
サーバ装置に送り、ファイル管理サーバ装置ではクライ
アント装置から渡された前記差分に対応するブロック・
データを用いて、格納している前記ファイルのバージョ
ンを更新する。

【００５１】従って、ファイル管理サーバ装置では、常
に各クライアント装置による編集終了時における最新バ
ージョンのファイルの内容に対する更新が行われるの
で、ロックを掛けずに複数のクライアント装置による非
同期編集を行うことが可能となる。

【００５２】また、時間的に古いバージョンを編集し、
最新バージョンとする使い方が可能となる。すなわち、
非同期編集可能な共有ファイルにおいて、編集対象を現
行版に限定しない使い方が可能となる。

【００５３】また、非同期編集により編集結果のマージ
処理を実行する場合に、サーバからはクライアントでの
処理に必要となるデータのみを送り、クライアントで必
要な処理を実行してサーバに返す形式を実現でき、不必
要な履歴に関する部分まで通信されるなどの無駄がなく
なり、効率が著しく向上する。

【００５４】また、ファイルのデータ構造として、単純
に一つ前（あるいは後）のバージョンとの差分を残して
いくＲＣＳのような構造ではなく、変形ＳＣＣＳで利用
されているようなファイルの先頭から順番に挿入された
データが挿入された位置にブロックとして管理され、部
分的に消去された場合にはブロックの分割を繰り返して
いく方式に変形を加えて採用すると、マージ処理に必要
となる挿入／削除の位置の決定が極めて単純化され、非
同期編集が容易となる。

【００５５】さらに、先に説明したマージ処理に適した
変形ＳＣＣＳのようなデータ構造を採用した場合のデー
タ内容の暗号化方式として、ビット単位（あるいはバイ
ト単位）のストリーム暗号を利用することができる。こ
のストリーム暗号は平文の特定ビット（あるいはバイ
ト）が暗号文の特定ビット（あるいはバイト）に対応す
る性質がある。このため、先のような暗号化されたブロ
ックの分割が繰り返される場合に、分割されるポイント
より後ろを切りとり、その部分だけ暗号化しなおせばよ
く、再暗号化のオーバヘッドが軽減される。さらに、サ
ーバ側で分割ポイントより前の部分が変更されていない
ことを確認することもできる。

【００５６】また、本発明（請求項４，９〜１１，１９
〜２１，２５）では、クライアント装置は、ファイル管
理サーバ装置に対して所望のバージョンのファイルをア
クセスし、該ファイルを編集した後、この編集の内容を
ファイル管理サーバ装置に送り、ファイル管理サーバ装
置は、前記クライアント装置から渡された編集の内容を
示すデータを、前記クライアント装置がアクセスして得
たバージョンがいずれであるかに従い、前記ファイル管
理サーバ装置内での最新のバージョンに対する編集内容
に変換する処理（マージ処理）を行う。

【００５７】従って、ファイル管理サーバ装置は、常に
各クライアント装置による編集終了時における最新バー
ジョンのファイルの内容に対する更新を行なうので、ロ
ックを掛けずに複数のクライアント装置による非同期編
集を行なうことが可能となる。

【００５８】また、本発明（請求項５及び６）では、フ
ァイル管理サーバ装置に格納管理されるファイルは、デ
ータ部分と付加情報部分からなり、データ部分は複数の
ブロック・データからなり、付加情報部分は各ブロック
・データに付加されたブロック識別情報を含み、さら
に、各ブロック・データはブロック・データ単位で暗号
化されているとともに、データ構造の管理に必要なブロ
ック識別情報は暗号化されていない情報である。

【００５９】従って、ファイル管理サーバ装置にはファ
イルの内容が秘匿されているとともに、ブロック識別情
報は暗号化されていないので、ファイル管理サーバ装置
ではデータ構造の管理を実行することができる。

【００６０】また、クライアント装置は、ファイル管理
サーバ装置に対して所望のファイルをアクセスし保有し
ている復号鍵を用いてブロック単位で復号化する。そし
て、編集手段を用いてこのファイルを編集し、この編集
の内容を示すデータをブロック・データごとに所定の暗
号鍵を用いて暗号化する。一方、ファイル管理サーバ装
置は、クライアント装置から渡されたブロック・データ
とブロック識別情報とに基づいて、該ファイルの履歴管
理を行う。

【００６１】このように、ファイルの履歴管理とファイ
ル管理サーバ装置に対するデータの秘匿性を同時に実現
できる。

【００６２】また、クライアント装置からファイル管理
サーバ装置には、ファイルのうちの必要なデータ・ブロ
ックだけを通信すれば良いので、通信量の削減を図るこ
とができる。

【００６３】また、請求項８のように構成した場合、ブ
ロックの分割暗号化に際し、ブロックの先頭から分割ポ
イントまでの部分は暗号化されたままで再利用でき、分
割ポイント以降のみを再暗号化する。なお、全く再暗号
化を必要としない方法もある。バージョン管理法とし
て、ＳＣＣＳを変形した方式を用いた場合、ブロックの
分割が繰り返されるが、このような場合に有利である。

【００６４】また、本発明（請求項９）では、ファイル
管理サーバ装置に格納されるファイルは、データ部分と
付加情報部分からなり、データ部分は複数のブロック・
データからなり、付加情報部分は各ブロック・データに
付加されたブロック識別情報を含み、さらに、各ブロッ
ク・データはブロック・データ単位で暗号化されている
とともに、データ構造の管理に必要なブロック識別情報
は暗号化されていない情報である。そして、クライアン
ト装置は、ファイル管理サーバ装置からファイルを得る
ことができ、保有している復号鍵を用いて該ブロック・
データを復号化し、得られた復号化データをブロックと
して新たなブロック・データに再構成し、暗号鍵を用い
て新たなブロック・データごとに暗号化し、ファイル管
理サーバ装置に出力することができる。

【００６５】これにより、クライアント装置により、履
歴情報の消去を行ったり、ファイルのブロック・データ
数が多くなった時などにブロックを再構成し、ブロック
識別情報によるオーバヘッドを削減することができる。
また、これを暗号鍵／復号鍵を有するクライアント装置
が行うことにより、サーバに対するファイルの内容の秘
匿性は守られる。

【００６６】また、本発明（請求項１０）では、ファイ
ル管理サーバ装置に格納されるファイルは、データ部分
と付加情報部分からなり、データ部分は複数のブロック
・データからなり、付加情報部分は各ブロック・データ
に付加されたブロック識別情報を含む。そして、クライ
アント装置は、あるバージョンのファイルを保存する手
段を有し、ファイル管理サーバ装置から、現在クライア
ント装置が保有しているバージョンのファイルと、所望
のバージョンのファイルの差分情報を受け取り、クライ
アントが保有している当該ファイルのデータとファイル
管理サーバ装置からの差分情報により、所望のバージョ
ンのファイルを構築し編集することができる。

【００６７】従って、クライアント装置は、ファイル全
体ではなく、現在保有するバージョンと所望するバージ
ョンとの差分情報のみをファイル管理サーバ装置から取
得すればよく、通信量の削減を図ることができるととも
に、ブロック・データが暗号化されている場合はクライ
アント装置での復号化処理量を削減できる利点がある。

【００６８】また、本発明（請求項１１）では、オペレ
ーティング・システムによって提供されるシステムコー
ルテーブル中のアドレス・ポインタの値を書き換えるだ
けで、既存のアプリケーションソフトウェア等のプログ
ラム自体は全く変更せずに、アクセス要求者として利用
して非同期編集を行うことが可能になる。

【００６９】また、請求項１３のように構成した場合、
請求項２又は３のファイルのバージョン管理において、
履歴の完全性をファイル管理サーバ装置側だけで保証で
きる。

【００７０】また、請求項１４のように構成した場合、
請求項２又は３のファイルのバージョン管理において、
現行バージョンのファイルの取り出しおよび古い履歴の
消去が容易となる。

【００７１】また、請求項１５，１６のように構成した
場合、請求項２又は３のファイルのバージョン管理にお
いて、古い履歴の消去が容易となる。

【００７２】また、本発明（請求項１９）では、ファイ
ル管理サーバ装置内に、その管理する各々のファイルの
各々のバージョン毎に対応付けて、当該ファイルの当該
バージョンを編集中であるクライアント装置の数を計数
する手段を設けた。これにより、ファイル管理サーバ装
置は、各々のファイルの各々のバージョンについて、そ
れを編集途中であるクライアント装置が存在するかどう
かを判断することができる。すなわち、指定されたファ
イルの指定されたバージョンに対応する計数値が０であ
るならば、それを編集途中であるクライアントは存在せ
ず、また、計数値が０でないならば、それを編集途中で
あるクライアントが存在すると判断できる。

【００７３】そして、ファイル管理サーバ装置は、ファ
イルのバージョンを消去する要求が発行された際、対応
する計数値が０でない場合には、０に等しくなるまで消
去の実行を遅延させることができる。

【００７４】これにより、ファイル管理サーバ装置は、
消去の対象となったファイルのバージョンを編集途中の
クライアントが存在する間は、該ファイルの該バージョ
ンを消去することがなくなるので、マージ処理の実行に
支障をきたすおそれがなくなる。

【００７５】また、本発明（請求項２０，２１）では、
クライアント装置は、ファイル管理サーバ装置に対して
所望のバージョンのファイルをアクセスし、該ファイル
を編集した後、この編集の内容をファイル管理サーバ装
置に送り、ファイル管理サーバ装置は、前記クライアン
ト装置から渡された編集の内容を示すデータを、前記ク
ライアント装置がアクセスして得たバージョンがいずれ
であるかに従い、前記ファイル管理サーバ装置内での最
新のバージョンに対する編集内容に変換し、他のクライ
アントによって既に行われている編集内容と競合するか
どうかの検出を行い、前記クライアント装置に競合検出
の結果を通知する。そして、この検出の結果にかかわら
ず、ファイルの更新（マージ処理）を行う。

【００７６】従って、各クライアント装置による編集結
果は、ファイル管理サーバ装置における最新バージョン
のファイルに対する更新に変換され、他のクライアント
による編集と競合するか否かによらず、ファイル管理サ
ーバ装置に最新バージョンとして更新されるため、ロッ
クを掛けずに複数のクライアント装置による非同期編集
を行うことが可能となる。

【００７７】また、ファイル更新を行ったクライアント
装置は、ファイル管理サーバ装置により、編集内容の競
合検出の結果を通知されるので、その結果に基づいて、
ファイルを編集し直すことができる。その際、ファイル
管理サーバ装置ではファイルは履歴管理されているの
で、過去のバージョンを取り出すなどして柔軟に編集を
行うことができる。

【００７８】また、請求項２１のように構成した場合、
ファイル管理サーバ装置は、他のクライアントによる編
集との競合検出の結果に基づいて、ファイルの更新を行
うかどうかを判断することができるので、ファイル管理
サーバ装置の最新バージョンのファイルにおいて意味的
矛盾が起こりにくい、あるいは起こらないようにするこ
とができる。

【００７９】

【実施例】以下、図面を参照しながら本発明の実施例に
ついて説明する。

【００８０】まず、本発明の第１実施例に係る共有ファ
イル編集システムでは、２つの独立して実施可能な発明
を適用している。第１の発明は、ファイルをブロック化
して管理する共有ファイル編集システムにおいて、ファ
イルの内容をファイル・サーバからは読み取ることがで
きないようにするものであり、第２の発明は、ファイル
のバージョン管理をサポートする共有ファイル編集シス
テムにおいて、非同期編集処理を行うことを可能とする
ものである。

【００８１】図１は、本実施例の概念図である。この共
有ファイル編集システムは、共有ファイルに対するファ
イル・アクセス要求を発する１つまたは複数のアクセス
要求者（以下、クライアントと呼ぶ）１０１と、ファイ
ルの保管とアクセス要求者１０１に対する所定データの
通信などを行うファイル管理サーバ（以下、サーバと呼
ぶ）１１０からなる。さらに、各クライアント１０１と
サーバ１１０の間には、要求文や応答文を受け渡しする
ための通信路１１１が設けられている。

【００８２】クライアント１０１は、実際のアクセス要
求を出したユーザやそのユーザの使用している計算機の
プロセスなどを抽象化したものである。また、各クライ
アント１０１には、それぞれ暗号化および復号化を実行
する暗号器１１２が備わっている。すなわち、この暗号
器１１２は、暗号アルゴリズムを実行する暗号化／復号
化処理部（図１５の１１２１，図２４の８１２１）と、
暗号鍵および復号鍵を記憶する鍵記憶部（図１５の１１
２２，図２４の８１２２）からなる。この暗号化／復号
化処理部と鍵記憶部の働きについては後述する。

【００８３】一方、サーバ１１０は、ファイル管理を行
う計算機のプロセスでも良いし、ファイル管理機能を有
する独立した装置でも良い。

【００８４】通信路１１１は、公衆網、ＬＡＮなどのイ
ーサネット、あるいは計算機内のソケットによる通信な
ど、電子的にメッセージを交換できる媒体であれば何を
用いても良い。

【００８５】サーバ１１０は、複数のファイル１１３を
保管している。このファイル１１３は、ファイルの内容
であるデータだけでなく、後で説明する履歴管理の情報
やアクセスが許されたユーザ名のリストや暗号化・復号
化に利用される情報などを含む。これらのファイル１１
３は、それぞれ正規のクライアント１０１だけが復号で
きる形式で暗号化されている。

【００８６】例えば慣用暗号（暗号化の鍵と復号化の鍵
が同一の暗号方式）を利用する場合には、正規のクライ
アント１０１は同一の鍵を所持しており、ファイル１１
３はその鍵を利用して暗号化・復号化されている。

【００８７】ファイル１１３は、そのファイル名自体は
同一に保たれても、各アクセス時点で書き込みや消去な
どが繰り返され、経時的にその内容が変化していく性質
のものである。そこで、いくつかの特定の時点でのファ
イルの内容を保存しておき、後に保存を行った任意の時
点における状態を再現したいなどの要求が生じる場合が
ある。特に、プログラム開発を行っている場合などでは
上記要求は一般的である。このような履歴管理（バージ
ョン管理）を実現する最も原始的な方法は、ある時点で
のファイルの内容をまるごと保存しておくものである。
一般的には、複数のバージョン間での違い（差分）はわ
ずかなことが多いため、このような管理法はサイズの面
で無駄があり、ＳＣＣＳ（Ｓｏｕｒｃｅ Ｃｏｄｅ Ｃ
ｏｎｔｒｏｌ Ｓｙｓｔｅｍ）やＲＣＳ（Ｒｅｖｉｓｉ
ｏｎ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）といった差分の
情報だけを保存していく方法が通常用いられている。

【００８８】以下、各履歴管理法でのデータ構造の概要
を説明する。

【００８９】まず、ＲＣＳの原型と考えられる方式を説
明する。ここで説明する方式は、差分積み上げ方式と呼
ぶこととする。図２に、この差分積み上げ方式でのファ
イルのデータ構造を示す。この方式では、最初に作成さ
れたバージョンのファイルを全文そのままの形で保存し
ておき、これをバージョンＶ．１（ブロック２０１）と
する。次に、このバージョンＶ．１の一部を消去した
り、何か挿入したりして新たなバージョンＶ．２が生成
された場合、これを保存する際にＶ．２とＶ．１との間
の差分を求め、その差分Ｖ．２−Ｖ．１（ブロック２０
２）だけを保存する。ここで、バージョン間の差分は、
例えばＵＮＩＸのｄｉｆｆコマンドが提供するような、
“どの位置に何が挿入された”とか“どの位置からどの
位置までが消去された”といったことを表すデータの集
合である。ファイルの全体に渡る変更が行われることは
ほとんどないので、一般的には差分のサイズの方がファ
イル全体のサイズよりも小さい。このような保存状態に
あるデータすなわちＶ．１のデータと差分Ｖ．２−Ｖ．
１のデータが、バージョンＶ．２の復元に十分な情報を
提供する。以降は同様に、バージョンＶ．３とＶ．２と
の差分Ｖ．３−Ｖ．２（ブロック２０３）、Ｖ．４と
Ｖ．３との差分Ｖ．４−Ｖ．３（ブロック２０４）、…
というように、常に編集後の新バージョンと保存されて
いる最新のバージョンとの間で差分をとり、その差分だ
けを追加して保存していく。

【００９０】従って、この差分積み上げ方式は、最新の
バージョン（現行バージョン）を復元するためにそれま
での全ての履歴を利用することとなるが、ファイルのサ
イズ面では大きな改善がある。

【００９１】次に、ＲＣＳ方式について説明する。図３
に、ＲＣＳによって履歴管理されたファイルのデータ構
造を示す。このＲＣＳ方式では、次のように履歴を管理
する。まず、現行版（ブロック３０４）は常にファイル
全文そのままの形で保管する。ここでは、現行版をＶ．
４とする。そして、それの一つ前のバージョンＶ．３は
Ｖ．４との差分Ｖ．３−Ｖ．４（ブロック３０３）とい
う形式で保存する。ここで、差分をとるときに時間的に
新しいバージョンを基準にした差分とするのがこの方式
の特徴である。Ｖ．３以前のバージョンも同様で、差分
Ｖ．２−Ｖ．３（ブロック３０２）、差分Ｖ．１−Ｖ．
２（ブロック３０１）が保存される。この状態で新しい
バージョンＶ．５が保存される場合には、差分Ｖ．４−
Ｖ．５を求める処理と、求めた差分と最新版Ｖ．５を保
存する処理が実行される。

【００９２】このようなデータ構造を利用した場合に
は、現行版の取り出しが容易になる利点がある。一方、
昔のバージョンを復元する場合ほど復元に時間を要する
ことになるが、通常は新しいバージョンほどアクセスす
る機会が多くなるので、本方式は一般的な利用形態に適
したものである。

【００９３】次に、もう１つの代表的な履歴管理法であ
るＳＣＣＳ方式に変形を加えた方式について説明する。
これは、各ブロック・データに対応させて、どのバージ
ョンでそのブロック・データが挿入されたかを示す情報
と、どのバージョンでそのブロック・データが削除され
たかを示す情報を記憶するバージョン管理方式である。

【００９４】図４に、変形ＳＣＣＳにより履歴管理され
たファイルのデータ構造の一例を示す。ＳＣＣＳ方式で
は、ある時点のファイル・データを全文の形で保存して
おくことはせず、ファイルをブロック化して管理し、挿
入があった場合は挿入された位置から挿入されたサイズ
だけのブロックが生成される。全てのブロックには、図
中フィールド４０６に示す生成時点もしくは該当ブロッ
クが生成された時点でのバージョン番号（こけはブロッ
クの作成時を特定するための情報の一例である）と、フ
ィールド４０７に示す消去時点もしくは該当ブロックが
消去された時点でのバージョン番号（これはブロックの
削除時を特定するための情報の一例である）の２つのデ
ータ・フィールドが対応づけられている。この４０６，
４０７の２つのフィールドは、ブロック識別情報の一例
である。ブロック識別情報とは、個々のブロックがどう
いう位置付けのブロックであるかを把握できるように付
加する情報である。先の差分積み上げ方式やＲＣＳの場
合にも、個々のブロックには“差分Ｖ．Ｘ−Ｖ．Ｙ”な
どのタグを付加するが、これらのタグがブロック識別情
報である。言い換えれば、ブロック識別情報とは、ブロ
ック同士の関連を示す情報である。

【００９５】以下、さらにこの変形ＳＣＣＳ履歴管理法
について、図４を用いて具体的に説明する。図４のファ
イルは、Ｖ．１からＶ．４までの４種類のバージョンか
らなるものである。このファイルのブロックは現在５つ
で、上から順にｂ１（ブロック４０１）、ｂ２（ブロッ
ク４０２）、ｂ３（ブロック４０３），ｂ４（ブロック
４０４），ｂ５（ブロック４０５）である。

【００９６】ここで、前述した２つのデータ・フィール
ド４０６，４０７の内容を参照することによって、以下
のような履歴でこのファイルが編集されたことが分か
る。

【００９７】まず、バージョンＶ．１（最初の版）で
は、このファイルはｂ２，ｂ３からなる。次に、バージ
ョンＶ．２で一番最初と最後の位置に追加が行われ、
Ｖ．２はｂ１，ｂ２，ｂ３，ｂ４からなる。次に、バー
ジョンＶ．３でブロックｂ４の部分が変更され、ブロッ
クｂ５に書き換えられた。なお、このときブロックｂ４
にはバージョンＶ．３で消去された旨のフラグが付けら
れ、新たにブロックｂ４の直下にブロックｂ５が挿入さ
れた旨の履歴管理が行われる。従って、Ｖ．３はｂ１，
ｂ２，ｂ３，ｂ５からなっている。次に、バージョン
Ｖ．４（現行版）では、ブロックｂ２が消去され、ｂ２
にはバージョンＶ．４が消去された旨のフラグが付けら
れる。従って、Ｖ．４はｂ１，ｂ３，ｂ５からなってい
る。なお、バージョンＶ．４以前では、ブロックｂ２と
ｂ３は一固まりのブロックであったのだが、Ｖ．４でそ
の固まりのブロックの前半のｂ２に対応する部分が消去
されたのである。

【００９８】この例で分かるように、変形ＳＣＣＳの履
歴管理では、現行版のファイルが一固まりとして存在す
るわけではないが、任意のバージョンの取り出しに対し
てそのバージョンを含んで以前の時点で生成され、その
バージョンの時点で消去されていないブロックを上から
順に連結すればよいので、任意のバージョンの取り出し
が大きな負荷になることなく実現できる特徴がある。ま
た、バージョンが進むにつれ、ブロックの分割が繰り返
されていく傾向があることも理解できよう。この履歴管
理法では、挿入されるブロックの位置や連続して消去さ
れる範囲さえ指定できれば容易に履歴管理できるのであ
る。

【００９９】ここで、本実施例の共有ファイル編集シス
テムでは、内容の読み出し保護を行うためには、暗号技
術を利用する。このとき、ファイルを格納しているサー
バ自体にもファイルの内容の読み出しを許さないことが
第１の発明の特徴である。また、ファイルに対する編集
処理を行う主体が複数であり、しかも共同編集をできる
だけロックなどの排除行為なく行えるようにしたことが
第２の発明の特徴である。そして、上記のようなファイ
ルのデータ構造と暗号化を結び付けることによってサー
バに対する内容の秘匿性を確保した共有ファイル編集シ
ステムを実現するとともに、上記のようなファイルのデ
ータ構造を利用して複数主体による非同期編集を実現し
ている。

【０１００】以下、本実施例の特徴の１つであるロック
を掛けない非同期編集について説明する。非同期編集と
して問題になるのは、あるクライアントＡがファイルの
現行バージョンＶ．４を読み出し、それに対する部分的
な消去や挿入を実行して新バージョンＶ．Ａを作成した
ものとする。また、ほぼ同時に他のクライアントＢがそ
の時点でのファイルの現行バージョンＶ．４を読み出
し、それに対して部分的な消去や挿入を実行して新バー
ジョンＶ．Ｂを作成したものとする。仮に書き戻しの実
行に関し、ライセンスＡの方が早かったものととする。
このとき、バージョンＶ．Ａが新バージョンＶ．５とし
て保存され、必要な履歴管理が実行されることになる
が、バージョンＶ．Ｂが書き戻されようとすると矛盾が
生じる。すなわち、バージョンＶ．Ｂをさらに新しいバ
ージョンＶ．６として保存すると、バージョンＶ．６に
はバージョンＶ．５で加えられた変更は何ら残らなくな
る。このようなことが起こらないように新バージョンは
常にそれまでに行われた変更をマージしたものである必
要が必要である。

【０１０１】こうした非同期編集を実現するために、本
実施例の共有ファイル編集システムでは履歴管理を次の
ように利用する。すなわち、全ての編集行為は削除と挿
入の組み合わせで記述できるが、これは編集対象バージ
ョンとの差分として固有に決定される。この点に着目す
ると、例えばある編集行為Ｅ１がバージョンＶ．４に対
して、どこに何を挿入し、どこからどこまでを消去した
という手続きの集合Δ１として定義でき、他の編集行為
Ｅ２が同じバージョンＶ．４に対する編集手続きの集合
Δ２として定義できる。

【０１０２】まず、編集行為Ｅ１が最初に書き戻された
場合、編集手続きΔ１として元のバージョンＶ．４との
差分を履歴管理方式に適した形式に変更して格納すれば
新バージョンＶ．５ができる。次に、編集行為Ｅ２が書
き戻される場合、編集手続きΔ２はバージョンＶ．４と
の差分を与えるものであるから、これを現行のバージョ
ンＶ．５に対する差分に変更する必要がある。このよう
に変更された編集手続きΔ２′を基にバージョンＶ．５
との差分を履歴管理方式に適した形式に変更して格納す
ることにより新バージョンＶ．６とする。以上の行為を
繰り返せば、矛盾無く非同期編集を実現可能である。

【０１０３】このとき、現行バージョンとの差分として
は定義されていない編集手続きを、現行バージョンとの
差分に矛盾無く変換することが重要である。この機構の
応用として、かなり古いバージョンに対して編集を行
い、その結果を現行版とマージするような使い方ができ
る。

【０１０４】このような手続きを実行するための非同期
編集システムの構成を図５に示す。図のように、この非
同期編集システムは、編集部５００、編集手続き生成部
５０１、編集手続き変換部５０２、履歴管理情報生成部
５０３、履歴管理部５１０、データ記憶部５１１からな
る。なお、この非同期編集システムは、サーバ１１０と
クライアント１０１に分散配置されるものであり、分散
配置の仕方はファイルを暗号化するか否かに応じて適宜
設定される。ただし、編集部５００はクライアント１０
１に、データ記憶部５１１はサーバ１１０に実装される
ことになる。

【０１０５】編集部５００は、履歴管理部５１０から得
られる編集対象のバージョンでのファイルの内容に対し
て編集を行うためのものである。

【０１０６】編集手続き生成部５０１は、編集対象のバ
ージョンでのファイルの内容と、編集部５００にてその
ファイルに対して行われた編集結果のファイルの内容を
入力し、「どの部分に何が挿入された」、あるいは「ど
こからどこまでの部分が削除された」などといった挿入
データと挿入位置、削除開始位置と削除終了位置などか
らなる編集手続きデータを出力する。

【０１０７】編集手続き変換部５０２は、この編集手続
きデータと後述の履歴データとを入力し、この編集手続
きデータを現行バージョンに対する編集手続きに変換し
て出力する。例えば、与えられた編集手続きデータに対
し、挿入データは不変とし、その挿入位置を現行バージ
ョンに対する挿入位置に変換し、また、削除開始位置や
削除終了位置も同様に現行バージョンに対する削除開始
位置と削除終了位置に変換する。この変換作業に必要な
補助入力として利用されるのが、履歴管理部５１０から
の履歴データである。

【０１０８】履歴管理部５１０は、編集対象のファイル
の更新履歴を保存したデータの管理を行っている。編集
手続き変換部５０２の出力である編集手続きデータは履
歴管理情報生成部５０３に入力され、この履歴管理情報
生成部５０３で利用している履歴管理法に適した形式の
履歴情報に変換され、この履歴情報が履歴管理部５１０
に送られ、最新バージョンの更新が行われる。

【０１０９】なお、データ記憶部５１１は、複数のファ
イルを格納するためのものである。

【０１１０】次に、具体的な履歴管理法に対して、図５
に示した非同期編集システムの構成の各部の働きを説明
する。

【０１１１】いずれの履歴管理方式を用いる場合でも、
編集手続き生成部５０１はＵＮＩＸのｄｉｆｆコマンド
に相当する処理を行う。すなわち、編集対象バージョン
のファイル・データと編集後のファイル・データとを比
較し、「どこに何が挿入されたか」、あるいは「どこか
らどこまでが消去されたか」などの編集手続きデータを
出力する。

【０１１２】最初に、履歴管理法として差分積み上げ方
式（図２）を用いる場合について、図６に示す例を用い
て説明する。

【０１１３】ここでは、編集対象バージョンがバージョ
ンＶ．２であり、現行版がバージョンＶ．４である場合
を想定する。このとき、編集手続き生成部５０１の出力
Δ１が、仮に以下のものであったとする。

【０１１４】・ｉ４ ここから新たに挿入しました。 うまくマージできるでしょうか？ ・ｄ８，９ すなわち、バージョンＶ．２に対して４行目に２行（こ
こから…でしょうか？）を挿入し、Ｖ．２に対して８行
目から９行目までの２行を消去したとことを表してい
る。

【０１１５】編集手続き変換部５０２の機能は、上記の
編集手続きΔ１を現行版Ｖ．４に対する編集手続きΔ
１′に変換することである。このときに必要となるもの
が、履歴管理部５１０から得られるＶ．２から現行版
Ｖ．４までに加えられた編集履歴の情報である。

【０１１６】ここで、一例として、バージョンＶ．３で
はバージョンＶ．２の２行目と３行目を消去し、さらに
５行目に１行（例えば、“ここはＶ．２の５行目です”
などのデータ）が挿入されたものとする。また、バージ
ョンＶ．４ではバージョンＶ．３の５行目から７行目ま
でを消去し、８行目に２行（例えば、“この部分気に入
らないので／／このように変えました”など。但し，／
／が改行を表す）が挿入されたものとする。このとき、
編集手続きΔ１における挿入位置はバージョンＶ．２に
おける４行目が現行版Ｖ．４の何行目に対応するかを求
めなければならない。これに対し、バージョンＶ．３と
Ｖ．２の差分、バージョンＶ．４とＶ．３の分の２つは
必要となる全ての情報を含んでおり、図６に示したよう
にＶ．４の２行目がＶ．２の４行目に対応していること
が分かるので、実際は、“Ｖ．２の４行に２行挿入”は
“Ｖ．４の２行目に２行挿入”に変換される。同様に、
Ｖ．２の８行目と９行目がＶ．４のそれぞれ何行目にな
るかを履歴を追って調べると、Ｖ．２の９行目はＶ．４
の７行目に対応するが、Ｖ．２の８行目は既にＶ．４で
消去されていることが分かる。既に、消去されている部
分をさらに消去することは通常意味をなさないので、こ
の場合には、“Ｖ．２の８行目から９行目を消去”は
“Ｖ．４の７行目を消去”に変換される。ここに説明し
た編集手続きの変換（主に変更位置の検索）を行うのが
編集手続き変換部５０２である。このように編集手続き
変換部５０２では変換のために履歴情報が必要不可欠で
ある。

【０１１７】こうして作成された編集手続きデータΔ
１′を入力として、履歴管理情報生成部５０３は、現行
版Ｖ．４と新バージョンとの差分を求める。ここでは履
歴管理法として差分積み上げ方式を用いているので、先
の“（Ｖ．４の）２行目に２行挿入”と“（Ｖ．４の）
７行目を消去”がそのまま履歴管理情報となり履歴管理
部５１０へ送られ、履歴として追加される。

【０１１８】次に、図４の変形ＳＣＣＳのような履歴管
理法を利用すると、編集手続き変換部５０２で変更位置
の検索処理が単純になる。以下、この点について先の例
を用いて説明する。

【０１１９】ここでは、図７のように、バージョンＶ．
２で１０行あったものとする。

【０１２０】まず、Ｖ．３においてＶ．２の２行目と３
行目が消去されたので、２行目と３行目の部分は新たに
１つのブロックになり、消去時点フラグに“Ｖ．３”が
書かれている。また、Ｖ．２の４行目と５行目の間に１
行挿入されたので、Ｖ．２の４行目が１つのブロックに
なり、またＶ．３で挿入された１行が１つのブロックを
構成し、このブロックの生成時間フラグに“Ｖ．３”が
書かれている。

【０１２１】次に、Ｖ．４においてＶ．３の５行目から
７行目までが消去されたので、Ｖ．３の時点で消去され
ていない行を先頭から数えて５行目から７行目までが１
つのブロックになり、消去時点フラグ“Ｖ．４”が書か
れる。さらに、Ｖ．３の７行目と８行目の間に２行挿入
されたので、この挿入された２行が１つのブロックを構
成し、その生成時点にフラグに“Ｖ．４”と書かれてい
る。

【０１２２】編集手続き生成部５０１からの出力である
編集手続きΔ１は先に説明したものと同じであるが、履
歴管理部５１０から編集手続き変換部５０２に渡される
履歴データは図７のバージョンＶ．４に示した形式にな
っている。編集手続き変換部５０２では、履歴データの
うち、Ｖ．２の時点での４行目（挿入位置）と８行目
（削除開始位置）、９行目（削除終了位置）を求めるた
めに、Ｖ．２での先頭から４行目，８行目，９行目を数
える。数えるときの注意は、Ｖ．２以降で挿入された部
分は飛ばすことである。

【０１２３】こうして求めた位置に新規に挿入された２
行（“ここから新たに挿入しました／／うまくマージで
きるでしょうか？”）を１つのブロックとして挿入す
る。さらに、削除に関しては、Ｖ．２の８行目は既に削
除時点フラグが立っているので何もせず、９行目を１ブ
ロックとして分割し、削除時点フラグに“Ｖ．５”と書
けば良い。こうして作成されたバージョンＶ．５を履歴
管理部５１０に送り、これを更新する。

【０１２４】この一連の手続きは履歴管理情報生成部５
０３の機能も含んでおり、履歴管理部５１０を更新する
ところまでが達成される。

【０１２５】ここで見たように履歴管理法として変形Ｓ
ＣＣＳのような方式を利用すると、変更位置の検索が単
純に先頭からのカウントだけで達成されるため、極めて
処理が単純化される。

【０１２６】このように、本実施例によれば、履歴管理
法として変形ＳＣＣＳのようなデータ構造を利用し、し
かも図５に示した諸機能を用いて非同期編集を実現する
ことが可能である。

【０１２７】次に、本発明の特徴の１つであるファイル
データの暗号化手法について説明する。

【０１２８】本実施例では、前述のようなファイルの履
歴管理で生じるいくつかのデータ・ブロックごとに独立
に暗号化し、サーバにはどのデータ・ブロックがどの部
分であるかを把握可能な形にする独自の構成を採用する
点に特徴がある。

【０１２９】そのようなファイル構成の具体例は、図２
のように差分積み上げ方式を履歴管理法として利用する
場合には、ブロック２０１，２０２，２０３，２０４を
それぞれ独立に暗号化し、サーバには「ブロック２０１
が最初のバージョンＶ．１のデータを暗号化したもので
ある」「ブロック２０２がバージョンＶ．２とバージョ
ンＶ．１の差分Ｖ．２−Ｖ．１を暗号化したものであ
る」といった対応関係を認識可能な形態にすることであ
る。各暗号化ブロックとそのブロックの意味の対応付け
の具体的な一例として、サーバの管理用のフラグ・フィ
ールドを用意し、そこにＶ．１やＶ．２−Ｖ．１などの
情報を書き込んでおけばよい。

【０１３０】このようにサーバが各データブロックの識
別に利用する情報を“ブロック識別情報”と呼ぶことに
する。ここに述べた管理用のフラグ・フィールドや図４
の生成時点（４０６）、消去時点（４０７）の各フィー
ルドはその一例である。

【０１３１】他の具体例としては、図３のＲＣＳ方式の
ような履歴管理法を利用する場合に、ブロック「３０
１，３０２，３０３，３０４を独立に暗号化し、サーバ
には「ブロック３０１が差分Ｖ．１−Ｖ．２を暗号化し
たものである」「ブロック３０２が差分Ｖ．２−Ｖ．３
を暗号化したものである」といった対応関係を認識可能
な形態にすることである。

【０１３２】さらに他の具体例としては、図４の変形Ｓ
ＣＣＳ方式のような履歴管理法を利用する場合に、ブロ
ック４０１，４０２，４０３，４０４，４０５を独立に
暗号化し、サーバには「ブロック４０１が先頭ブロック
であり、ブロック４０２がそれに続くブロックであり、
…」といった情報を認識可能な形態にすることである。
例えば、ブロックの区切りが分かる形で単純に連結する
だけでも良い。図４の各ブロックには、生成時点４０６
と消去時点４０７の２つのデータ・フィールドが対応づ
けられていることは先に説明した通りであるが、これら
のフィールドは暗号化しない。

【０１３３】この方式のように暗号化する部分を独立化
することの利点は、クライアントの処理量とクライアン
ト・サーバ間の通信量の削減にある。すなわち、クライ
アントが図３のような履歴管理システムにて現行版をサ
ーバに対して要求した場合、サーバは暗号化されたブロ
ック３０４だけを送信すればよいが、例えば図３のデー
タ・ファイル全体が一固まりとして暗号化されている場
合、サーバは全てのデータを送信しなければならない。
さらに、このデータを受信したクライアントは一固まり
として暗号化されている全てのブロック３０１〜３０４
を復号しなければならず、不要な処理が多く含まれてし
まうことが理解できよう。

【０１３４】また、例えば図２の履歴管理方式におい
て、クライアント側が新たな編集行為の結果として変更
できるのは、差分Ｖ．５−Ｖ．４の暗号化ブロックを追
加することだけである。しかし、ファイルが一固まりと
して暗号化されているような場合には、特に差分Ｖ．４
−Ｖ．３との区切りに近い部分が変更されていないこと
の検査が困難になる。すなわち、暗号化は通常ファイル
の先頭から連鎖的にある長さごとに区切って行われるた
め、ファイルの終わりに近い部分以外が変更されていた
場合には、何らかの改変行為が行われたことが、サーバ
によって暗号文から推定可能となるが、ファイルの終わ
りに近い部分（新たに追加された差分に近い部分）は改
変の検出ができない。ところが、図２のデータ構造にて
ブロックごとに独立に暗号化する場合には、新たな差分
の暗号化データを追加していくだけであるから履歴に関
して改変が行われないようにサーバが容易に管理でき
る。

【０１３５】ここで、先に見てきたようにロックを掛け
ない非同期編集を実現する上では、特に図４のデータ構
造を利用した履歴管理法が、マージ処理の簡単化の面で
も適している。しかし、このような履歴管理法の特徴と
して、ある時点で一固まりであったブロックがそれ以降
の時点で次々に分割されていくことがある。一般にはブ
ロックの分割に伴い、ブロックデータの再暗号化の必要
が生じるが、本実施例では暗号化の処理を軽減可能な暗
号方式を用いる。以下、そのような暗号方式について説
明する。

【０１３６】ブロック内のデータはビットあるいはバイ
トが最小の単位となっていることを想定できるが、本実
施例の第１の暗号方式では１つのブロックがいくつかの
位置（ブロックの先頭から順にポイント１，ポイント
２，…とする）で分割される場合に、ブロックの先頭か
らポイント１までの暗号データは再暗号化の必要がな
く、既に暗号化されているデータをそのまま利用可能で
ある。ポイント１以降のデータのみ再暗号化する。

【０１３７】さらに、本実施例の第２の暗号方式では、
一切再暗号化を必要とせず、一度暗号化されたデータは
そのまま利用される。

【０１３８】最初にこのような利用が可能となるための
暗号方式の条件を述べる。まず、任意のポイントで暗号
ブロックを分割した場合に、その分割された暗号ブロッ
クの断片から対応する平文が得られなければならない。
従って、平文の特定ビット（あるいはバイト）が暗号文
の特定ビット（あるいはバイト）に対応しているこが条
件となる。このためには当然のことながら、暗号化によ
るサイズの拡大があってはならい。このようなな性質を
持つ暗号方式にストリーム暗号と呼ばれる方式がある。
代表例にブロック暗号ＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐ
ｔｉｏｎ Ｓｔａｎｄａｒｄ）をＯＦＢ（Ｏｕｔｐｕｔ
ＦｅｅｄＢａｃｋ）モードあるいはＣＦＢ（Ｃｉｐｈ
ｅｒ ＦｅｅｄＢａｃｋ）モードで利用する方式があ
る。ＯＦＢモードによる暗号化手順は図８に、ＣＦＢモ
ードによる暗号化手順は図９に示した。

【０１３９】まず、図８を参照しながらＯＦＢモードの
動作原理を説明する。送信側と受信側はブロック暗号の
鍵Ｋとシフトレジスタ６０２，６１２の初期値であるＩ
Ｖ（６０１，６１１）を共有しているものとする。送信
側は暗号化に当たりシフトレジスタ６０２の内容を暗号
化し、得られた結果６０４の内Ｌビットをシフトレジス
タ６０２に帰還させるとともに、平文のＬビットとビッ
ト単位で排他的論理和演算（６０５）を行う。この処理
を繰り返すことにより、平文をＬビットずつ暗号化す
る。但し、１回の処理で暗号化される量はＬビットであ
るが、実はビット単位で暗号化されているものである。

【０１４０】また、受信側の復号処理も送信側とまった
く同様に行われるが、その詳細は自明であるので説明を
省略する。

【０１４１】次に、図９を参照しながらＣＦＢモードの
動作原理を説明する。ＯＦＢモードの場合と前提は同じ
で、ハードウェアの構成もほとんど同様であるが、違い
は暗号化時にシフトレジスタ６２２に帰還させるデータ
がブロック暗号器の出力ではなく、暗号文を用いる点に
ある。このために、復号側の処理もシフトレジスタ６３
２への入力にＬビットの暗号文を用いることになる。原
理は図９から明らかなのでここでの説明は省略する。

【０１４２】これらのモードは１回の暗号化に利用され
るビット数（すなわち、シフトレジスタへの帰還ビット
数と一致する）を用いて、ＬビットＯＦＢモードもしく
はＬビットＣＦＢモードと呼ばれる。１ビットＯＦＢモ
ードもしくは１ビットＣＦＢモードは、代表的なビット
単位のストリーム暗号である。また、８ビットＯＦＢモ
ードもしくは８ビットＣＦＢモードは代表的なバイト単
位のストリーム暗号である。なお、この両モードにおい
て、平文８ビットと暗号器出力の８ビットをビット毎に
排他的論理和をとって暗号化／復号化するのではなく、
例えば８ビットの加算／減算により暗号化／復号化する
ように変形することも可能である。

【０１４３】以下では、ブロック内データの最小単位を
バイト単位と仮定して説明を行う。このような、ストリ
ーム暗号による暗号文の強度を保証するためには、鍵Ｋ
が固定である場合、シフトレジスタの初期値ＩＶを平文
ごとに変えた方が好ましい。そのようにしないと、２つ
の暗号文の同一位置の排他的論理和を取るだけで平文同
士の排他的論理和が求められたり、２つの暗号文の先頭
がまったく同じ時には、対応する平文もその部分はまっ
たく同じであることが分かるなどの弱点が発生する。こ
の点は、本実施例においては、暗号化のブロックごとに
初期値ＩＶを変えることで対応する。

【０１４４】さて、本実施例の暗号方式によるブロック
・データ分割時の暗号手順を図１０を参照しながら説明
する。（ａ）が分割前のブロックデータのデータ構造で
あり、（ｂ）が分割後のブロックデータのデータ構造で
ある。ここでは、ある暗号ブロック（ブロック０）の中
間部分が削除されることを例とし、ブロックを前半部
（ブロック１）、削除部（ブロック２）、後半部（ブロ
ック３）の３つに再暗号化することを想定する。各ブロ
ックごとに初期値ＩＶを格納する領域６４２が設けられ
ている。但し、この初期値ＩＶは暗号化されない。

【０１４５】本実施例の第１の暗号方式では、Ｌビット
ＯＦＢモードもしくはＬビットＣＦＢモードを用いる。
ただし、Ｌは８の倍数とする。各ブロックの初期値ＩＶ
は新規にブロックが生成される時点で乱数発生などによ
り生成される。ブロック・データは先の暗号方式で先頭
から順番にＬビットずつ暗号化される。ブロックの最後
はちょうどＬビットにならない場合があるが、その場合
にも平文の長さで暗号を打ち切る。このようにしても最
後の部分を復号できる。

【０１４６】ブロック・データ分割時（図１０）の暗号
化手順を図１１のフローチャートを参照しながら説明す
る。

【０１４７】まず削除開始位置より前の部分（ブロック
１）がそのまま切り放され１つのブロックとなる（ステ
ップＳ１）。次に、乱数発生などにより初期値ＩＶ１が
決定され（ステップＳ２）、この初期値ＩＶ１を初期値
としたＯＦＢ（もしくはＣＦＢ）モードにより削除部の
データ（ブロック２に対応する平文データ）が暗号化さ
れ、新たに１つのブロックになる（ステップＳ３）。さ
らに、別の初期値ＩＶ２が決定され（ステップＳ４）、
後半部のデータが暗号化され新たな１つのブロックにな
る（ステップＳ５）。

【０１４８】この手順では、先頭部分のブロックは初期
値ＩＶ０がそのまま利用され、再暗号化の必要がない点
に特徴がある。

【０１４９】次に、本実施例の第２の暗号方式を説明す
る。第２の暗号方式の特徴は一切の再暗号化を必要とし
ない点にある。この場合には８ビットＣＦＢモードを用
いる。

【０１５０】新規挿入ブロックについては、初期値ＩＶ
を乱数発生などにより発生し、ブロック・データは先頭
から順番に１バイトずつ暗号化する。

【０１５１】ブロック・データ分割時（図１０）の暗号
化手順を図１２のフローチャートを参照しながら説明す
る。最初に個々の分割位置にて３つのブロックに切断す
る（ステップＳ１１）。次に、ブロック１の最後の８バ
イトをブロック２の初期値ＩＶとして保存する（ステッ
プＳ１２）。さらに、ブロック２の最後の８バイトをブ
ロック３の初期値ＩＶとして保存する（ステップＳ１
３）。ステップ１２とステップ１３での初期値ＩＶの保
存時の注意として、前のブロックが短くて８バイト未満
の場合の対処が必要である。その場合には、前のブロッ
クはそのブロックの初期値ＩＶ＋ブロック・データと考
え、足りない分は初期値ＩＶから補えば良い。

【０１５２】この手順は８ビットＣＦＢモードでは任意
の位置から復号可能な性質を利用したものであり、ブロ
ックの分割に伴う再暗号化がまったく不要になる利点が
ある。この利点はさらに、暗号化共有ファイルシステム
をクライアント・サーバ・システムにて実現する場合に
ブロックの分割処理を暗号／復号機能を有しないサーバ
が実行可能となることを意味し、同システムの効率的な
実現を可能にする。本手順を一般のＬビットＣＦＢモー
ド（ただし、Ｌは８の倍数）に拡張することもできる
が、そのためには補助的なデータが必要となる。これ
は、例えば図１０のブロック２が元のブロック０の先頭
からＬビットずつの区切り目から始まらない場合がある
ためである。ブロック２のデータはブロック０の先頭か
らＬビットずつ暗号化されたデータとなっているため、
元のＬビットずつの区切りが再現できるようにしなけれ
ばならない。そこで、補助的なデータとしてブロックの
先頭からｕ（ｕ≦Ｌの整数）ビット分が半端なブロック
であることを表すものを用い、復号するときにはブロッ
クデータの最初にダミーの（Ｌ−ｕ）ビットの暗号文を
追加して復号を行い、復号結果の先頭の（Ｌ−ｕ）ビッ
トを無視する。それにつながるデータは、Ｌビットずつ
復号化すれは良い。また、ブロックの分割時の初期値Ｉ
Ｖの保存は、前のブロックの最後の半端ビット（Ｌ−ｕ
ビット）の直前の８バイトの内容とする。前のブロック
が短い場合の処理は、８ビットＣＦＢモードの場合とし
て説明したものと同様に、足りない部分を初期値ＩＶか
ら補えば良い。

【０１５３】以上、削除に伴うブロック分割を例として
説明したが、挿入においては次のようになる。すなわ
ち、既存ブロックの途中にあるブロックを挿入する場合
には、先の図１１もしくは図１２の手順に相当する既存
のブロックの分割と、新規挿入ブロック・データの暗号
化が必要である。新規挿入部の暗号化は、まず乱数発生
などにより初期値ＩＶを決定し、この初期値ＩＶを利用
してＯＦＢ（もしくはＣＦＢ）モードにより暗号化す
る。また、既存ブロック同士の間にあるブロックを挿入
する場合には、既存ブロックには何ら変更はなく、新規
挿入ブロックだけを暗号化すれば良い。

【０１５４】次に、本実施例のいくつかの履歴管理方式
の特徴を整理する。ここで比較するのは図２に示した暗
号化差分積み上げ方式による共有ファイル編集システム
と図３に示した暗号化ＲＣＳ方式による共有ファイル編
集システムと図４に示した暗号化ＳＣＣＳ方式による共
有ファイル編集システムである。

【０１５５】まず、ロックをかけない非同期編集機能に
関しては、先に説明したように暗号化ＳＣＣＳ方式がマ
ージ手続きが単純化できて有利である。

【０１５６】次に、現行版の取り出しであるが、これは
暗号化ＲＳＣ方式では現行版をそのままの形て暗号化デ
ータとして保管するためこれが最も有利である。暗号化
ＳＣＣＳ方式はその次に有利であり、任意の版が同程度
の処理で復元できる特徴がある。

【０１５７】ファイル・サイズを圧縮するために古い履
歴を消去したいことがあるが、この点に関しては、暗号
化ＲＳＣ方式と暗号化ＳＣＣＳ方式が優れている。なぜ
なら、これらの方式ではそうした要求を受けたサーバが
単独で履歴消去可能であるからである。暗号化差分積み
上げ方式では、クライアントが関与することによって、
古い履歴を消去できる。

【０１５８】なお、注意すべき点として、暗号化ＳＣＣ
Ｓ方式の場合、古い履歴を消去してもブロックの融合を
行う訳ではなく、不要なブロックの切り離し処理を行う
だけであることがあげられる。ブロックの融合まで行う
場合にはクライアントの関与が必要である。また、暗号
化ＲＣＳ方式の場合には、サーバ単独で実行できるのは
古い側の履歴から順番に消去することであることにも注
意しなければならない。

【０１５９】履歴内容は後になって変更したりできない
ように管理されることが好ましいが、この履歴内容の完
全性に対しては、暗号化差分積み上げ方式が優れてい
る。先にも説明したが、この方式では差分を追加してい
くことしかクライアントには許されていないため、履歴
の完全性が保証できる。

【０１６０】以上説明してきたように、上記２つの発明
の一方または両方をファイル編集システムに適用するこ
とにより、（ａ）ファイルのバージョン管理をサポート
する共有ファイル編集システムであって、ファイルの内
容をファイル・サーバに対して秘密にしながら、非同期
編集処理を行うことが可能となる共有ファイル編集シス
テム、（ｂ）ファイルのバージョン管理をサポートする
共有ファイル編集システムであって、非同期編集処理を
行うことが可能な共有ファイル編集システム、（ｃ）フ
ァイルの内容をファイル・サーバからは読み取ることの
できない秘匿性の高いファイル編集システムを提供する
ことができる。

【０１６１】なお、以上では構造化されたファイルの暗
号化において、クライアントだけが暗号化／復号化でき
るようにデータの内容は暗号化するが、データ構造に関
してはサーバにも認識できる形式を示し、特にバージョ
ン管理や非同期編集への応用を説明した。本発明は、他
にも様々なシステムに応用可能であり、例えばプログラ
ムを、サブルーチンごとに暗号化する方法や、ハイパー
テキストなど複数のデータファイルがリンクで結び付け
られている場合に個々のデータファイル単位で暗号化
し、リンク部分は暗号化しない方法などに応用できる。
このようにすれば、サーバに対してはモジュール内容の
秘密性を保ちながら、クライアントが必要な部分だけ読
み出して利用する効率的な利用ができる。

【０１６２】次に、上述したサーバへのファイル内容秘
匿機能（第１の発明）と非同期編集機能（第２の発明）
をクライアント・サーバ型システムに実装してた本発明
の第２実施例について説明する。

【０１６３】まず、ファイルの構造、履歴管理方式、暗
号化・復号化方式、非同期編集システムについては前述
した第１実施例と同様のものを用いることを前提とす
る。これらについては、すでに詳細に説明したので、こ
こでは主に本実施例に特有の構成・動作について説明す
る。

【０１６４】図１３には、本実施例の共有ファイル編集
システムの第１構成例を示す。図１３のように、この共
有ファイル編集システムは、複数のクライアント９１
と、サーバ９０からなる。

【０１６５】サーバ９０は、各クライアント９１と通信
路１１１を介して通信を行うための通信部１３１、共有
ファイル用履歴管理部５１０、複数のファイルを格納す
るためのデータ記憶部５１１を備えている。

【０１６６】また、各クライアント９１は、サーバ９０
と通信路１１１を介して通信を行うための通信部１３
０、サーバ９０から得たファイルを格納するためのメモ
リ１２１、共有ファイル編集部１２２、暗号器１１２を
備えている。

【０１６７】図１４のように共有ファイル編集部１２２
は、図５で説明した編集部５００、編集手続き生成部５
０１、編集手続き変換部５０２、履歴管理情報生成部５
０３を備えている。なお、サーバ９０の共有ファイル用
履歴管理部５１０とデータ記憶部５１１は、図５におけ
る履歴管理部５１０とデータ記憶部５１１に相当する。

【０１６８】図１５のように暗号器１１２は、共有ファ
イル編集部１２２と接続される通信部１３２、暗号化／
復号化処理部１１２１、鍵記憶部１１２２を備えてい
る。

【０１６９】ここで、本実施例では、クライアント９１
は複数であるために、（ａ）特定バージョンのファイル
データの読み出し（図５での５１０から５００への矢
印）、（ｂ）編集結果である履歴管理情報の書き込み
（図５での５０３から５１０への矢印）、（ｃ）編集手
続きの変換に必要な履歴データの読み出し（図５での５
１０から５０２への矢印）の各要求が様々なタイミング
で発生する。

【０１７０】以下これらの要求を処理する一般的な手順
を説明する。前述したように、１つの履歴管理情報に対
応する編集手続きは複数に挿入と削除の組み合わせから
なるが、これらを一纏めとして取り扱うことが望まし
い。すなわち、あるクライアント９１があるバージョン
のファイルに対し、複数箇所の変更を行った場合に、そ
れらの変更がすべてサーバ９０側のデータに反映された
時点で新規バージョンとする。履歴管理情報の書き込み
要求は１つ１つが待ち行列（キュー）に入れられ、先入
れ先出し方式（Ｆｉｒｓｔ−ｉｎ−Ｆｉｒｓｔ−ｏｕ
ｔ）で順次履歴管理部５１０が取り出してファイル・デ
ータに反映していく。履歴管理部５１０はクライアント
９１からの読み出し要求（先の（ａ），（ｃ））には随
時応答するが、履歴管理部５１０があるファイルデータ
を更新中に同一ファイルの現行版の読み出し要求が来た
場合には、更新前のバージョンを送信する必要がある。

【０１７１】クライアント９１は最初のサーバ９０から
あるバージョン（バージョンｘとする）のデータを要求
し、メモリ１２１に格納した後、編集部５００にて編集
を行い、編集手続き生成部５０１にて編集手続きデータ
を生成する。バージョンｘが、読み出し時点における最
新版であった場合には、編集手続きは変換せずに履歴管
理情報を生成し、暗号化してサーバ９０に送信する。受
け取ったサーバ９０側ではその時点での最新版にマージ
可能な履歴管理情報であるか否かを判定し、マージ不可
能な場合には共有ファイル用履歴管理部５１０から履歴
データをクライアント９１に送信し、編集手続き変換部
５０２による編集手続きの変換を要求する。

【０１７２】ここで、マージ可能か不可能かの判断は例
えば、クライアント９１側で送信する履歴管理情報のヘ
ッダに対象としたデータのバージョン番号をつけるよう
にし、サーバ９０側では保存している最新版の番号とヘ
ッダの番号を比較して一致していればマージ可能、一致
していなければマージ不可能と判断すれば良い。さら
に、マージ不可能な場合にクライアント９１に送信する
履歴データは、例えば履歴管理情報のヘッダに含まれる
バージョン番号と最新のバージョンとの間の履歴データ
である。クライアント９１では、所定の編集手続きの変
換を実施し、新たに履歴管理情報を生成する。これを再
びサーバ９０に送り、サーバ９０側では再度マージ可能
性を判定する。

【０１７３】ここで、再びマージ不可能である可能性が
ある。すなわち、クライアント９１での編集手続きの変
換処理の間に、他のクライアントによりファイルのバー
ジョンが更新された場合ある。従って、図５の５１０→
５０２→５０３のループを何度も回る可能性がある。

【０１７４】このような処理の繰り返しを防ぐためにロ
ック機能を利用することも考えられる。すなわち、履歴
データをクライアントに送出した時点でサーバ側がファ
イルデータの更新にロックを掛け、そのクライアントか
らの履歴管理情報を受信してファイルデータの更新が終
わった時点でロックを解除するようにする。ロックがか
かっている間は編集対象ファイルデータの読み出しは許
可するが、それ以外の処理はサーバ９０側でリジェクト
する。リジェクトされたクライアント９１は適当な時間
を置いてリトライする。なお、このロック機構による待
ち時間は極めて短いものと考えられる。このロック機構
は、必ずしも必要ではない。

【０１７５】一方、最初にサーバ９０から読み出したバ
ージョンｘが読み出し時点での最新版でない場合には、
編集手続き変換部５０２での処理のために、サーバ９０
に対してバージョンｘから最新版までの履歴データを要
求する。後の処理は先に説明したものと同じである。

【０１７６】以上の手順において、クライアント９１が
受信する編集対象ファイルと履歴データ、およびサーバ
９０に送る履歴管理情報はすべて構造ごとに暗号化され
たデータであり、その暗号化／復号化に暗号器１１２を
利用する。

【０１７７】このように、本実施例では、ファイルの内
容は復号鍵を持っている正規のクライアントからのみ読
み取れ、ファイルの内容をサーバからは読み取ることの
できないようにした秘匿性の高いファイル編集システム
を提供することができる。

【０１７８】また、サーバでは、常に各クライアントに
よる編集終了時における最新バージョンのファイル内容
にに対する更新が行われるので、ロックを掛けずに複数
のクライアントによる非同期編集行うことが可能とな
る。

【０１７９】また、時間的に古いバージョンを編集し、
最新バージョンとする使い方が可能となる。すなわち、
非同期編集可能な共有ファイルにおいて、編集対象を現
行版に限定しない使い方が可能となる。

【０１８０】また、非同期編集による編集結果のマージ
処理を実行する場合に、サーバからはクライアントでの
処理に必要となるデータのみを送り、クライアントで必
要な処理を実行してサーバに返す形式を実現でき、不必
要な履歴に関する部分まで通信されるなどの無駄がなく
なり、効率が著しく向上する。

【０１８１】また、ファイルのデータ構造として、単純
に一つ前（あるいは後）のバージョンとの差分を残して
いくＲＣＳのような構造ではなく、ＳＣＣＳで利用され
ているようなファイルの先頭から順番に挿入されたデー
タが挿入された位置にブロックとして管理され、部分的
に消去された場合にはブロックの分割を繰り返していく
方式を採用すると、マージ処理に必要となる挿入／削除
の位置の決定が極めて単純化され、非同期編集が容易と
なる。

【０１８２】さらに、先に説明したマージ処理に適した
ＳＣＣＳのようなデータ構造を採用した場合のデータ内
容の暗号化方式として、ビット単位（あるいはバイト単
位）のストリーム暗号を利用することができる。このス
トリーム暗号は平文の特定ビット（あるいはバイト）が
暗号文の特徴ビット（あるいはバイト）に対応する性質
がある。このため、先のような暗号化されたブロックの
分割が繰り返される場合に、分割されるポイントより後
ろを切りとり、その部分だけ暗号化しなおせばよく、再
暗号化のオーバヘッドが軽減される。さらに、サーバ側
で分割ポイントより前の部分が変更されていないことを
確認することもできる。

【０１８３】以上に説明した共有ファイル編集システム
（第１の発明と第２の発明の両方を適用したもの）で
は、先に示したように図５での５１０→５０２→５０３
のループが存在した。以下では、そのループを解消する
一実施例を説明する。

【０１８４】本実施例では、ファイルのデータ構造とし
ては、図４の変形ＳＣＣＳ方式を用い、暗号方式として
は、ストリーム暗号のうち８ビットのＣＦＢモードによ
る方式を用いる。この暗号方式には先に説明したように
ブロックの分割においても再暗号化が不要な特徴があ
る。

【０１８５】図１６には、本実施例の共有ファイル編集
システムの第２構成例を示す。図１６のように、この共
有ファイル編集システムは、複数のクライアント２１１
と、サーバ２１０からなる。

【０１８６】サーバ２１０は、各クライアント２１１と
通信路１１１を介して通信を行うための通信部２３１
と、図５で説明した編集手続き変換部５０２、履歴管理
部５１０および複数のファイルを格納するためのデータ
記憶部５１１を備えている。なお、この編集手続き変換
部５０２は、図５の履歴管理情報生成部５０３の機能も
含んだものとする。

【０１８７】各クライアント２１１は、サーバ２１０と
通信路１１１を介して通信を行うための通信部２３０、
サーバ２１０から得たファイルを格納するためのメモリ
２２１、共有ファイル編集部２２２、暗号器２１２を備
えている。図１７のように、クライアント２１１の共有
ファイル編集部２２２は、図５で説明した編集部５００
および編集手続き生成部５０１を備えている。

【０１８８】ここで、本実施例では、クライアント２１
１は複数であるために、（ａ）特定バージョンのファイ
ルデータの読み出し（図５での５１０から５００への矢
印）、（ｂ）編集結果を変換した編集手続きデータの書
き込み（図５での５０１から５０２への矢印）、の各要
求が様々なタイミングで発生する。

【０１８９】以下これらの要求を処理する手順の一例を
説明する。クライアント２１１は、最初にサーバ２１０
からあるバージョンのデータを要求する。そのバージョ
ンのデータを復号し、メモリ２２１に格納した後、編集
部５００にて編集を行い、編集手続き生成部５０１にて
編集手続きデータを生成する。ここでの編集手続きデー
タは、挿入データと削除データの２つである。挿入デー
タは、挿入位置（例えば先頭位置からのバイト数）と挿
入ブロック内容の組からなり、削除データは削除開始位
置と削除終了位置の組からなる。

【０１９０】クライアント２１１は、挿入ブロック内容
に関しては、初期値ＩＶを生成し、８ビットＣＦＢモー
ドで暗号化する。他のデータ（挿入位置や削除範囲な
ど）は暗号化せずに、暗号化挿入ブロック内容とまとめ
てサーバ２１０に送る。

【０１９１】これを受け取ったサーバ２１０では、まず
編集手続き変換部５０２にて、挿入位置と削除範囲をそ
の時点での最新版に対する位置データに変換（位置変
換）する。次に、履歴管理部５１０にて、挿入位置には
クライアントから送信された暗号化挿入ブロックを配置
し、削除範囲ではブロックの分割と消去時点フィールド
の記入を行う。以上の結果を最新版とする。

【０１９２】この手順の中で、暗号化した状態で編集手
続きの変換が可能なことがポイントであり、そのために
先の一般方式における編集手続き変換のための（前述し
たような）ループが解消される。暗号化した状態で編集
手続きの変換を可能にするファイルのデータ構造と暗号
方式として、変形ＳＣＣＳ方式と８ビットＣＦＢモード
の組み合わせが挙げられる。他の暗号方式、特にブロッ
ク分割の場合に最初のブロックだけは再暗号化を不要に
するＬビットＯＦＢモードやＬビットＣＦＢモードのよ
うな方式でも同様の効果を得ることができるが、クライ
アントからサーバに送る編集手続きデータは、ここに示
したデータよりも余分なものが必要となる。

【０１９３】このように、本実施例では、ファイルの内
容は復号鍵を持っている正規のクライアントからのみ読
み取れ、ファイルの内容をサーバからは読み取ることの
できないようにした秘匿性の高いファイル編集システム
を提供することができる。

【０１９４】また、サーバでは、常に各クライアントに
よる編集終了時における最新バージョンのファイルの内
容に対する更新か行われるので、ロックを掛けずに複数
のクライアントによる非同期編集を行うことが可能とな
る。

【０１９５】尚、上述した図１３と図１６の構成例を要
部についてまとめると各々図１８，図１９に示すような
構成であると考えられる。

【０１９６】図１８の構成では、ブロック識別情報はク
ライアント９１側の履歴管理情報生成手段５０３により
クライアント９１からサーバ９０に送る履歴管理情報に
付加されても良い。この場合、ブロック識別情報は暗号
化されず履歴管理情報が暗号器１１２で暗号化されるの
で、サーバ９０は暗号化されておらず従ってサーバ９０
側で認識可能なブロック識別情報に基づいて履歴管理情
報が示す新しいブロックデータを管理できるが、暗号化
されている履歴管理情報のデータ内容はサーバ９０側で
は認識不可能である。

【０１９７】これに代えて、ブロック識別情報をクライ
アント９１からサーバ９０に送る履歴管理情報に付加し
ないようにしても良い。この場合、履歴管理情報が示す
新しいブロックデータに適当なブロック識別情報はサー
バ９０側の履歴管理部５１０で付加できる。

【０１９８】図１９の構成では、編集手続きデータのみ
がクライアント２１１からサーバ２１０へ送られ、この
編集手続きデータに基づいて得られる新しいブロックデ
ータを同定するブロック識別情報はサーバ２１０側の履
歴管理情報生成部５０３か履歴管理部５１０により付加
される。ここでは、挿入データ内容のみが暗号器２１２
で暗号化され、編集手続きデータの他の部分は暗号化さ
れないので、サーバ２１０側の編集手続き変換部５０２
はこれらの暗号化されておらず従ってサーバ２１０側で
認識可能な編集手続きデータの他の部分と履歴管理部５
１０から与えられる履歴データとに基づいて編集手続き
データの変換を行える。

【０１９９】この図１９の構成を変形して、編集手続き
変換部５０２をクライアント２１１側に、編集手続き生
成部５０１と暗号器２１２の間に設けるようにして、図
１８と図１９の折衷形とすることも可能である。この場
合、変換後の編集手続きデータのみがクライアント２１
１からサーバ２１０へ送られ、この変換後の編集手続き
データに基づいて得られる新しいブロックデータを同定
するブロック識別情報はサーバ２１０側の履歴管理情報
生成部５０３か履歴管理部５１０により付加される。こ
こでは、変換後の挿入データ内容のみが暗号器２１２で
暗号化され、変換後の編集手続きデータの他の部分は暗
号化されないので、サーバ２１０側の履歴管理情報生成
部５０３はこれらの暗号化されておらず従ってサーバ２
１０側で認識可能な変換後の編集手続きデータの他の部
分に基づいて履歴管理情報の生成を行える。

【０２００】さて、上述した２つの発明は独立実施可能
である。以下で、一方の発明だけを適用した実施例を夫
々説明する。

【０２０１】最初に、上述した非同期編集機能（第２の
発明）をクライアント・サーバ型システムに実装した本
発明の第３実施例について説明する。

【０２０２】まず、ファイルの構造、履歴管理方式、非
同期編集システムについては前述した第１実施例と同様
のものを用いることを前提とする。これらについては、
すでに詳細に説明したので、ここでは、主に本実施例に
特有の構成・動作について説明する。

【０２０３】図２０は、本実施例の共有ファイル編集シ
ステムの構成を示す。図２０のように、この共有ファイ
ル編集システムは、複数のクライアント７０１と、サー
バ７１０からなる。

【０２０４】サーバ７１０は、各クライアント７０１と
通信路１１１を介して通信を行うための通信部７３１、
マージ処理部７４０、複数のファイルを格納するための
データ記憶部７１１を備えている。

【０２０５】また、各クライアント７０１は、サーバ７
１０と通信路１１１を介して通信を行うための通信部７
３０、サーバ７１０から得たファイルを格納するための
メモリ７２１、共有ファイル編集部７２２を備えてい
る。

【０２０６】図２１のように、クライアント７０１の共
有ファイル編集部７２２は、図５で説明した編集部５０
０、編集手続き生成部５０１を備えている。

【０２０７】また、図２２のように、サーバ７１０のマ
ージ処理部７４０は、図５で説明した編集手続き変換部
５０２、履歴管理情報生成部５０３、共有ファイル用履
歴管理部５１０を備えている。なお、サーバ７１０のデ
ータ記憶部５１１は、図５におけるデータ記憶部５１１
に相当する。

【０２０８】ここで、本実施例では、クライアント７０
１は複数であるために、（ａ）特定バージョンのファイ
ルデータの読み出し（図５での５１０から５００への矢
印）、（ｂ）編集結果を変換した編集手続きデータの書
き込み（図５での５０１から５０２への矢印）、の各要
求が様々なタイミングで発生する。

【０２０９】以下、これらの要求を処理する手順の一例
を説明する。

【０２１０】この場合、クライアント７０１はサーバ７
１０から特定のバージョンのファイルデータを要求し、
ファイルをメモリ７２１に格納した後、編集部５００に
て編集を行い、編集手続き生成部５０１にて編集手続き
データに変換し、それをサーバ７１０に送る。

【０２１１】サーバ７１０側では、１つ１つの編集手続
きデータをキューに入れ、マージ処理部７４０が順次取
り出して履歴に変換して保存していく。先の暗号機能付
きの装置の実施例の場合との違いは、サーバ７１０単独
で最新版に対する編集手続きデータに変換可能であるこ
とにある。すなわち、クライアント７０１の編集手続き
データと履歴データから編集手続きの変換を実施した後
に履歴として保存する。従って、図５での５１０→５０
２→５０３のループは存在しないため、ループの繰り返
しを防ぐ目的でのロック機能は必要としない。

【０２１２】また、クライアント７０１側に設ける共有
ファイル編集部７２２の機能も少なくて済む。

【０２１３】ただし、前述したサーバへのファイル内容
秘匿機能を有する実施例の場合のように、編集手続き変
換部５０２および履歴管理情報生成部５０３をクライア
ント７０１側に設ける構成を採用することは可能であ
る。この場合の各部の動作は自明であるので、詳細な説
明は省略する。また、クライアント７０１に設ける共有
ファイル編集部７２２の機能のうち、さらに編集手続き
生成部５０１をサーバ７１０側へ移すことも可能であ
る。

【０２１４】このように、本実施例によれば、サーバで
は、常に各クライアントによる編集終了時における最新
バージョンのファイル内容に対する更新が行われるの
で、ロックを掛けずに複数のクライアントによる非同期
編集を行うことが可能となる。

【０２１５】また、時間的に古いバージョンを編集し、
最新バージョンとする使い方が可能となる。すなわち、
非同期編集可能な共有ファイルにおいて、編集対象を現
行版に限定しない使い方が可能となる。

【０２１６】また、非同期編集による編集結果のマージ
処理を実行する場合に、サーバからはクライアントでの
処理に必要となるデータのみを送り、クライアントで必
要な処理を実行してサーバに返す形式を実現でき、不必
要な履歴に関する部分まで通信されるなどの無駄がなく
なり、効率が著しく向上する。

【０２１７】また、ファイルのデータ構造として、単純
に一つ前（あるいは後）のバージョンとの差分を残して
いくＲＣＳのような構造ではなく、ＳＣＣＳで利用され
ているようなファイルの先頭から順番に挿入されたデー
タが挿入された位置にブロックとして管理され、部分的
に消去された場合にはブロックの分割を繰り返していく
方式を採用すると、マージ処理に必要となる挿入／削除
の位置の決定が極めて単純化され、非同期編集が容易と
なる。

【０２１８】次に、上述したサーバへのファイル内容秘
匿機能（第１の発明）をクライアント・サーバ型システ
ムに実装した本発明の第４実施例について説明する。

【０２１９】まず、本実施例で扱うファイルは、複数の
ブロック・データおよびブロック識別情報を含み、か
つ、各ブロック・データはブロック・データ単位で暗号
化されている。例えば、図２、図３、図４にそれぞれ示
したような構造であるが、これらに限らず、例えばプロ
グラムを、サブルーチンごとに暗号化する方法や、ハイ
パーテキストなど複数のデータファイルがリンクで結び
付けられている場合に個々のデータファイル単位で暗号
化し、リンク部分は暗号化しない方法などに応用でき
る。このようにすれば、サーバに対してはモジュール内
容の秘密性を保ちながら、クライアントが必要な部分だ
け読み出して利用する効率的な利用ができる。

【０２２０】また、本実施例では、上記構造を有するフ
ァイルに対して、前述したような暗号化・復号化方式を
用いることを前提とする。

【０２２１】図２３は、本実施例のファイル編集システ
ムの構成を示す。このように、本実施例のファイル編集
システムは、クライアント８０１と、サーバ８１０から
なる。

【０２２２】サーバ８１０は、クライアント８０１と通
信路１１１を介して通信を行うための通信部８３１、デ
ータ管理部８４０、複数のファイル１１３を格納するた
めのデータ記憶部５１１を備えている。

【０２２３】また、クライアント８０１は、サーバ８１
０と通信路１１１を介して通信を行うための通信部８３
０、サーバ８１０から得たファイル１１３を格納するた
めのメモリ８２１、ファイル編集部８２２、暗号器８１
２を備えている。暗号器８１２は、図２４のように共有
ファイル編集部８２２と接続される通信部８３２、暗号
化／復号化処理部８１２１、鍵記憶部８１２２を備えて
いる。

【０２２４】上記構成において、クライアント８０１は
サーバ８１０からあるバージョンのデータを要求し、メ
モリ８２１に格納した後、ファイル編集部８２２にて編
集を行う。その際、前述のようにファイルはブロック・
データごとに暗号化されているので、鍵記憶部８１２２
に登録してある復号鍵を用いて、暗号化／復号化処理部
８１２１にて復号化しておく。ファイルの編集が終了し
たら、鍵記憶部８１２２に登録してある暗号鍵を用い
て、暗号化／復号化処理部８１２１にて暗号化した後、
サーバ８１０に送り、データ管理部８４０にてデータ記
憶部５１１のファイルが更新される。

【０２２５】このように、本実施例では、ファイルの内
容をサーバからは読み取ることのできない秘匿性の高い
ファイル編集システムを提供することができる。

【０２２６】また、クライアントは、ファイルのうちの
必要なデータ・ブロックだけを通信により取得できるの
で、通信量の削減を図ることができるとともに、必要な
ブロックだけを復号化／暗号化すれば良いので、クライ
アント装置での処理量の削減、クライアント装置で必要
なバッファ（メモリ）の削減ができる利点もある。

【０２２７】ここで、本実施例に、上述したような履歴
管理方式を適用することができる。以下、そのような例
について説明する。

【０２２８】この場合に扱うファイルの構造は、図２、
図３、図４にそれぞれ示したようなものを採用する。ま
た、上記構成を有するファイルに対して、前述したよう
な暗号化・復号化方式を用いる。

【０２２９】ここでは、非同期編集は行わないことか
ら、図５の非同期編集システムの編集手続き変換部５０
２を削除して編集手続き生成部５０１と履歴管理情報生
成部５０３を直結し、履歴管理部５１０をデータ記憶部
５１１を管理する機能だけを有するデータ管理部８４０
とする修正を施したものを履歴管理システムとして、こ
れをファイル編集部８２２とデータ管理部８４０とに分
散配置する。

【０２３０】分散配置は、クライアント８０１のファイ
ル編集部８２２に編集部５００を実装し、サーバ８１０
にデータ管理部８４０およびデータ記憶部５１１を実装
すれば、他はどのような形で分散配置することも可能で
ある。

【０２３１】ここでは好ましい態様として、図２３のよ
うにサーバ８１０にデータ管理部８４０およびデータ記
憶部５１１を実装し、他をクライアント８０１に実装し
たものを示してある。

【０２３２】上記構成において、クライアント８０１は
サーバ８１０からあるバージョンのデータを要求し、メ
モリ８２１に格納した後、編集部５００にて編集を行
う。その際、前述のようにファイルはブロック・データ
ごとに暗号化されているので、鍵記憶部８１２２に登録
してある復号鍵を用いて、暗号化／復号化処理部８１２
１にて復号化しておく。ファイルの編集が終了したら、
編集手続き生成部５０１にて編集手続きデータを生成す
る。そして、その編集手続きデータを履歴管理情報生成
部５０３にて、利用している履歴管理法に適した形式の
履歴情報に変換する。ここで、この履歴情報を鍵記憶部
８１２２に登録してある暗号鍵を用いて、暗号化／復号
化処理部８１２１にて暗号化した後、サーバ８１０に送
り、データ管理部８４０にてデータ記憶部８１１のファ
イルが更新される。

【０２３３】このように、ファイルのバージョン管理と
ファイル管理装置に対するデータの秘匿性を同時に実現
できる。

【０２３４】また、ファイルの構造として図２の差分積
み上げ方式による構造を採用した場合、履歴の完全性を
ファイル管理装置側だけで保証できる。

【０２３５】また、ファイルの構造として図３のＲＣＳ
方式による構造を採用した場合、ファイルのバージョン
管理において、現行バージョンのファイルの取り出しお
よび古い履歴の消去が容易となる。

【０２３６】また、ファイルの構造として図４のＳＣＣ
Ｓ方式による構造を採用した場合、ファイルのバージョ
ン管理において、古い履歴の消去が容易となる。

【０２３７】また、暗号として、前述したストリーム暗
号を用いる場合、ブロックの分割時の暗号化に際し、ブ
ロックの先頭から分割ポイントまでの部分は暗号化され
たままで再利用でき、分割ポイント以降のみを再暗号化
する。なお、全く再暗号化を必要としない方法もある。
これは、ＳＣＣＳに代表されるブロックの分割が繰り返
される場合に有利である。

【０２３８】次に、図１３、図１６、あるいは図２０を
用いて説明した非同期編集機能を有する共有ファイル編
集システムにおいて、あるファイルのあるバージョンの
消去要求が発行されても、当該ファイルの当該バージョ
ンを編集中であるクライアントが存在しなくなるまで消
去実行を遅延させる機能を設けた本発明の第５実施例の
共有ファイル編集システムについて説明する。

【０２３９】履歴管理を行うシステムにおいては、履歴
中の一部のバージョンを消去する機能を提供することが
考えられる。バージョンの消去は、例えばクライアント
が消去コマンドを実行するとこによって行われる場合
や、作成から一定時間以上経過したバージョンをシステ
ムが自動的に消去する場合などが考えられる。

【０２４０】本発明に係る非同期編集機能を有する共有
ファイル編集システムにおいては、バージョンを消去す
る場合には、消去対象となっているバージョンを編集し
ているクライアント装置が存在していてはならない。な
ぜならば、このシステムでは、ファイル管理サーバはマ
ージ処理（クライアントがアクセスしたバージョンがい
ずれであるかに従い、ファイル管理サーバ内での最新の
バージョンに変換する処理）を行うからである。もし、
いずれかのクライアントが当該バージョンを編集途中
に、そのバージョンを消去してしまったとすると、マー
ジ処理が不可能になってしまう。

【０２４１】本実施例では上記機能を実現するために、
ファイル管理サーバ内に、その管理する各々のファイル
の各々のバージョン毎に対応付けて、当該ファイルの当
該バージョンを編集中であるクライアントの数を計数す
る手段を設ける。これによりファイル管理サーバは、各
々のファイルの各々のバージョンについて、それを編集
途中であるクライアントが存在するかどうかを判断する
ことができる。すなわち、指定されたファイルの指定さ
れたバージョンに対応する計数値が０であるならば、そ
れを編集途中であるクライアントは存在せず、また、計
数値が０でないならば、それを編集途中であるクライア
ントが存在すると判断できる。

【０２４２】そして、本実施例のファイル管理サーバ
は、ファイルのバージョンを消去する要求が発行された
際、該計数値が０でない場合には、０に等しくなるまで
消去の実行を遅延する手段を有する。これによりファイ
ル管理サーバは、消去の対象となったファイルのバージ
ョンを編集途中のクライアントが存在する間は、該ファ
イルの該バージョンを消去することがなくなるので、マ
ージ処理の実行に支障をきたすおそれがなくなる。

【０２４３】以下、前述の図１３の実施例を基にして、
上記機能を設けた共有ファイル編集システムについて説
明する。

【０２４４】図２５は、図１３の実施例に、上記のよう
なクライアント数を計数する手段を設けた実施例であ
る。図中のアクセス要求者９１、通信路１１１は、図１
３の実施例と同様の構成である。ファイル管理サーバ９
５は、クライアント計数部９００が加わっている点が図
１３と異なる。

【０２４５】図２６に示すように、クライアント計数部
９００は、分岐部９０１、編集開始処理部９０２、消去
要求処理部９０３、編集終了処理部９０４、計数記憶部
９０５、消去命令発行部９０６を用いて構成される。

【０２４６】このクライアント計数部９００の機能の概
略は、ファイル管理サーバ９５が管理する各々のファイ
ルの各々のバージョン毎に対応付けて、何個のクライア
ントがそのファイルのそのバージョンを編集中であるか
を数えることと、あるクライアントによりあるファイル
のあるバージョンを消去する要求が発行された際、その
計数値が０でない場合には、０に等しくなるまで消去の
実行を遅延することである。

【０２４７】クライアント計数部９００内部の計数記憶
部９０５の基本的な役割は、各々のファイルの各々のバ
ージョンそれぞれに対して、計数値（整数）と消去遅延
フラグ（１ビットの真偽値）を対応付けて記憶すること
である。計数値は、何個のクライアントが対応するファ
イルの対応するバージョンを編集中であるかを数えるカ
ウンタであり、消去遅延フラグは、計数値が０でなかっ
たために消去の実行が遅延されていることを示すフラグ
である。

【０２４８】計数記憶部９０５に記憶されているデータ
のデータ構造の一例を、図２７に示す。データ構造は、
二段階に構成された配列になっている。第一段階目の配
列は、ファイル識別子に対して第二段回目の配列を対応
付けるものであり、ファイル識別子とアドレスの対を一
要素として、それらの配列になっている。第二段階目の
配列は、ファイルの各々のバージョンに関する計数値と
消去遅延フラグを保持するもので、計数値と消去遅延フ
ラグの対を一要素とする配列となっている。この配列に
おいては、バージョン番号を配列のインデクスとして参
照する。したがって例えば、図２７のＣ１１，Ｃ１２，
Ｃ１３は、ファイルＩＤ１のファイルのそれぞれバージ
ョン番号１，２，３のバージョンの計数値、また、Ｆ１
１，Ｆ１２，Ｆ１３は、ファイルＩＤ１のファイルのそ
れぞれバージョン番号１，２，３のバージョンの消去遅
延フラグの値を表している。なお、計数値の初期値は
０、消去遅延フラグの初期値はｆａｌｓｅ（を示す値；
例えば０）である。

【０２４９】本実施例においては、クライアント９１
は、ファイルの編集を開始する直前に、ファイル管理サ
ーバ９５に対して、編集開始宣言を行う。この編集開始
宣言は、例えば通信路１１１を通してクライアント９１
からファイル管理サーバ９５に対して、編集開始宣言で
あることを示すコマンドワードに続けて編集しようとす
るファイルの識別子および編集しようとするバージョン
のバージョン番号を送信することにより行われる。

【０２５０】ファイル管理サーバ９５によって受け取ら
れた通信データは、分岐部９０１に入力される。

【０２５１】分岐部９０１では、例えば通信データの初
めの１ワードを読み、それが編集開始宣言を示すコマン
ドワードであることを判定すると、通信データ中の続く
ファイルＩＤおよびバージョン番号を編集開始処理部９
０２に入力する。

【０２５２】編集開始処理部９０２では、分岐部９０１
からの入力を受けると、計数記憶部９０５にアクセスし
て、指定されたファイルＩＤの指定されたバージョンに
対応する計数値を１つ増加させる。

【０２５３】一方、上記通信データは、そのままあるい
はファイルの識別子およびバージョン番号などが加工し
なおされて、分岐部９０１から共有ファイル用履歴管理
部５１０に与えられる。そして、上記のように編集開始
宣言が処理された後、クライアント９１によるファイル
の編集が行われる。このときのファイル編集の機構は、
前述の図１３の実施例のときと同様にして行われる。

【０２５４】次に、ファイルのバージョンを消去する際
の処理機能について説明する。本実施例においては、バ
ージョンの消去要求もまた、通信路１１１を通してクラ
イアント９１からファイル管理サーバ９５に対して、バ
ージョン消去要求であることを示すコマンドワードに続
けて消去しようとするファイルの識別子および消去しよ
うとするバージョンのバージョン番号を送信することに
より行われる。

【０２５５】ファイル管理サーバ９５によって受け取ら
れた通信データは、分岐部９０１に入力される。分岐部
９０１では、通信データの初めの１ワードを読み、それ
がバージョン消去要求を示すコマンドワードであること
を判定すると、通信データ中の続くファイルＩＤおよび
バージョン番号を消去要求処理部０９０３に入力する。

【０２５６】消去要求処理部９０３では、分岐部９０１
からの入力を受けると、図２８のフローチャートに示す
手順により処理を行う。

【０２５７】消去要求処理部９０３はまず、計数記憶部
９０５にアクセスして、指定されたファイルＩＤの指定
されたバージョン番号に対応する計数値を得る（ステッ
プＳ２１）。次に、その計数値の値か０であるかどうか
により条件分岐を行う（ステップＳ２２）。計数値が０
である場合には、履歴管理部５１０に対して指定された
ファイルＩＤの指定されたバージョンを消去する命令を
消去命令発行部９０６から発行する（ステップＳ２
３）。また、計数値が０でない場合には、計数記憶部９
０５にアクセスして、指定されたファイルのＩＤの指定
されたバージョン番号に対応する消去遅延フラグをｔｒ
ｕｅ（を示す値；例えば１）にする（ステップＳ２
４）。

【０２５８】次に、編集終了時の処理について説明す
る。本実施例においては、クライアント９１は、ファイ
ルの編集を終了した直後に、ファイル管理サーバ９５に
対して、編集終了宣言を行う。この編集終了宣言は、通
信路１１１を通してクライアント９１からファイル管理
サーバ９５に対して、編集終了宣言であることを示すコ
マンドワードに続けて編集を終了しようとするファイル
の識別子および編集を終了しようとするバージョンのバ
ージョン番号を送信することにより行われる。

【０２５９】ファイル管理サーバ９５によって受け取ら
れた通信データは、分岐部９０１に入力される。分岐部
９０１では、通信データの初めの１ワードを読み、それ
が編集終了宣言を示すコマンドワードであることを判定
すると、通信データ中の続くファイルＩＤおよびバージ
ョン番号を編集終了処理部９０４に入力する。なお、必
要に応じて、上記通信データは、そのままあるいはファ
イルの識別子およびバージョン番号などが加工しなおさ
れて、分岐部９０１から共有ファイル用履歴管理部５１
０に与えられる。

【０２６０】編集終了処理部９０４では、図２９のフロ
ーチャートに示す手順により処理を行う。

【０２６１】編集終了処理部９０４の処理手順ではま
ず、計数記憶部９０５にアクセスして、指定されたファ
イルＩＤのファイルの指定されたバージョン番号に対応
する計数値Ｃと消去遅延フラグＦの値を得る（ステップ
Ｓ３１）。次に、計数値Ｃの値を１減らす（ステップＳ
３２）。次に、計数値Ｃを計数記憶部９０５に保存する
（ステップＳ３３）。次に、計数値Ｃの値が０であるか
どうかにより条件分岐を行う（ステップＳ３４）。計数
値が０でない場合には、編集終了処理部９０４の処理を
終了する。計数値が０である場合には、次に消去遅延フ
ラグＦの値より条件分岐を行う（ステップＳ３５）。消
去遅延フラグＦの値がｆａｌｓｅである場合には、編集
終了処理部９０４の処理を終了する。消去遅延フラグＦ
の値がｔｒｕｅである場合には、履歴管理部５１０に対
して指定されたファイルＩＤの指定されたバージョンを
消去する命令を消去命令発行部９０６から発行する（ス
テップ３６）。

【０２６２】なお、分岐部９０１では通信データの初め
の１ワードを読み、それが上記した編集開始宣言、バー
ジョン消去要求、編集終了宣言を示すコマンドワード以
外のものであることを判定すると、通信データをそのま
ま共有ファイル用履歴管理部５１０に入力する。

【０２６３】次に、履歴管理部５１０における消去命令
の実行処理の例について述べる。消去命令の処理手順
は、履歴管理部５１０が差分積み上げ、ＲＣＳ、変形Ｓ
ＣＣＳのいずれの管理方法をとっているかによって異な
るものであり、以下ではそれら３方式について夫々一例
を説明する。以下の説明においては、次に示す記号を用
いる。 ｒ：消去対象のバージョン番号 ｆ：対象となっているファイルの履歴のうちで、履歴管
理部５１０が保持している最も古いバージョンのバージ
ョン番号（多くの場合，ｆ＝１であるが、過去にバージ
ョンの消去命令によってバージョン１が消去されている
場合には、ｆは１でない値になる。） ｎ：対象となっているファイルの履歴のうちで、履歴管
理部５１０が保持している最も新しいバージョン（すな
わち現行版）のバージョン番号 ｐ（ｘ）：履歴管理部５１０が保持しているバージョン
のうちで、バージョンｘの１つ前のバージョンのバージ
ョン番号（多くの場合，ｐ＝ｘ−１であるが、過去にバ
ージョンｘ−１が消去された場合には、ｐ＝ｘ−２に、
さらにバージョンｘ−２が消去された場合には、ｐ＝ｘ
−３に等々、順次前のバージョンになる。） ｓ（ｘ）：履歴管理部５１０が保持しているバージョン
のうちで、バージョンｘの１つ後のバージョンのバージ
ョン番号（多くの場合，ｓ＝ｘ＋１であるが、過去にバ
ージョンｘ＋１が消去された場合には、ｓ＝ｘ＋２に、
さらにバージョンｘ＋２が消去された場合には、ｓ＝ｘ
＋３に等々、順次後のバージョンになる。） Ｖ［ｘ］：バージョンｘ（の内容） Ｖ［ｘ］−Ｖ［ｙ］：バージョンｘとバージョンｙとの
差分

【０２６４】まず、履歴管理部５１０が差分積み上げ方
式により履歴管理を行っている場合について説明する。
図３０には、この消去命令の実行処理手順を示す。 ｉ）消去対象が履歴の最初のバージョンや現行版でない
場合（ステップＳ４１，Ｓ４５にてｒ≠ｆかつｒ≠ｎの
場合） ・消去対象バージョンの前のバージョン（Ｖ［ｐ
（ｒ）］）および後のバージョン（Ｖ［ｓ（ｒ）］）を
復元し（ステップＳ４７）、それらの２つのバージョン
の差分（Ｖ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］）を生成し
（ステップＳ４８）、消去対象バージョンの前後の差分
（Ｖ［ｓ（ｒ）］−Ｖ［ｒ］）および（Ｖ［ｒ］−Ｖ
［ｐ（ｒ）］）をＶ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］と置
換する（ステップＳ４９）。

【０２６５】ｉｉ）消去対象が履歴の最初のバージョン
である場合（ステップＳ４１にてｒ＝ｆの場合） ・消去対象の次のバージョン（Ｖ［ｓ（ｒ）］）を復元
し（ステップＳ４２）、履歴の最初のバージョン（Ｖ
［ｒ］）およびそれと次のバージョンの差分（Ｖ［ｓ
（ｒ）］−Ｖ［ｒ］）を消去し（ステップＳ４３）、Ｖ
［ｓ（ｒ）］を新たに履歴の最初バージョンとする（ス
テップＳ４４）。

【０２６６】ｉｉｉ）消去対象が履歴の最後のバージョ
ン（現行版）である場合（ステップＳ４５にてｒ＝ｎで
ある場合） ・そのバージョンと前のバージョンとの差分（Ｖ［ｒ］
−Ｖ［ｐ（ｒ）］）を消去する（ステップＳ４６）。

【０２６７】次に、履歴管理部５１０がＲＣＳ方式によ
り履歴管理を行っている場合について説明する。図３１
には、この消去命令の実行処理手順を示す。 ｉ）消去対象が履歴の最初のバージョンや現行版でない
場合（ステップＳ６１，Ｓ６５にてｒ≠ｆかつｒ≠ｎの
場合） ・消去対象バージョンの前のバージョン（Ｖ［ｐ
（ｒ）］）および後のバージョン（Ｖ［ｓ（ｒ）］）を
復元し（ステップＳ６７）、それらの２つのバージョン
の差分（Ｖ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］）を生成し
（ステップＳ６８）、消去対象バージョンの前後の差分
（Ｖ［ｐ（ｒ）］−Ｖ［ｒ］）および（Ｖ［ｒ］−Ｖ
［ｓ（ｒ）］）をＶ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］と置
換する（ステップＳ６９）。

【０２６８】ｉｉ）消去対象が履歴の最初のバージョン
である場合（ステップＳ６１にてｒ＝ｆの場合） ・そのバージョンと前のバージョンとの差分（Ｖ［ｒ］
−Ｖ［ｓ（ｒ）］）を消去する（ステップＳ６２）。

【０２６９】ｉｉｉ）消去対象が履歴の最後のバージョ
ン（現行版）である場合（ステップＳ６３にてｒ＝ｎで
ある場合） ・現行版の１つ前のバージョン（Ｖ［ｐ（ｒ）］）を復
元し（ステップＳ６４）、現行版と１つ前のバージョン
との差分（Ｖ［ｐ（ｒ）］−Ｖ［ｒ］）を消去し（ステ
ップＳ６５）、Ｖ［ｐ（ｒ）］を新たに現行版とする
（ステップＳ６６）。

【０２７０】次に、履歴管理部５１０が変形ＳＣＣＳ方
式で履歴管理を行っている場合の消去処理の実施例につ
いて説明する。図３２には、この消去命令の実行処理手
順を示す。尚、図３２のフローチャートは、履歴を構成
するブロックの１つに対する消去処理手順を示してい
る。履歴管理部５１０における消去処理は、本フローチ
ャートに示す手順を、消去対象となっているバージョン
を含む全てのブロック各々に対して施すことによって行
われる。

【０２７１】以下の説明においては、次に示す記号を用
いる。 ｉ：処理対象となっているブロックの生成時点 ｄ：処理対象となっているブロックの消去時点 現行版においてもまだ消去されていないブロックは、ｄ
＝∞で表すものとする。

【０２７２】ｉ）対象バージョンが現行版でない場合
（ステップＳ８１にてｒ≠ｎの場合） ・消去対象バージョンにおいてしか存在しなかったブロ
ックについて（ステップＳ８５，Ｓ８６にて、ｉ＝ｒか
つｄ＝ｓ（ｒ）の場合）は、該ブロックを履歴情報の中
から消去する（ステップＳ９０）。 ・消去対象バージョンにおいて生成されたブロックにつ
いて（ステップＳ８５，Ｓ８６について、ｉ＝ｒかつｄ
≠ｓ（ｒ）の場合）は、消去対象の次のバージョン（Ｖ
［ｓ（ｒ）］）において生成されたものとする（ステッ
プＳ８７）。 ・消去対象バージョンにおいて消去されたブロックにつ
いて（ステップＳ８５，Ｓ８８にて、ｉ≠ｒかつｄ＝ｒ
の場合）は、消去対象の次のバージョン（Ｖ［ｓ
（ｒ）］）において消去されたものとする（ステップＳ
８９）。

【０２７３】ｉｉ）対象バージョンが現行版である場合
（ステップＳ８１にてｒ＝ｎの場合） ・現行版において生成されたブロックについて（ステッ
プＳ８２にてｉ＝ｎの場合）は、該ブロックを履歴情報
中から消去する（ステップＳ９０）。

【０２７４】・現行版において消去されたブロックにつ
いて（ステップＳ８２，Ｓ８３にて、ｉ≠ｎかつｄ＝ｎ
の場合）は、未消去のブロック（ｄ＝∞）とする（ステ
ップＳ８４）。

【０２７５】ここで、上記の処理を全てのブロックに対
して実行した後、履歴中の任意の隣接する２つのブロッ
クについて、両者の生成時点が等しく、かつ、両者の消
去時点が等しい場合には、この２つのブロックを結合す
ることもできる。

【０２７６】なお、以上の消去処理の実施例において
は、１つの消去命令で１つのバージョンを消去する場合
を説明したが、一般のバージョン管理システムにおいて
も、複数バージョンの消去要求を、その対象となる１つ
１つのバージョンに対する消去命令に分解して処理する
ことにより、一消去命令で複数のバージョンを消去する
機能を提供するのと同様の効果を得ることは容易であ
る。

【０２７７】以上のように本実施例によれば、各々のフ
ァイルの各々のバージョンについて、それを編集してい
るクライアントの数を記憶し、ユーザからの消去の要求
あっても、消去対象となるファイルのバージョンを編集
するクライアントがなくなるまで消去の実行を遅延させ
るので、いずれかのクライアントが編集途中のバージョ
ンを消去することがなくなり、マージ処理の実行に支承
をきたさない非同期編集システムを実現することができ
る。

【０２７８】ここで、上記した実施例における履歴の消
去は、クライアントからファイル管理装置に対して消去
要求を発行するものであったが、クライアント以外から
消去要求を生成する構成も考えられる。例えば、作成か
ら一定時間以上経過した履歴に対して、サーバ内部で自
動的に消去要求を生成する場合がある。また、最新のバ
ージョンに対する非同期編集のみをサポートすれば十分
であって、過去のバージョンを編集することがない場合
には、新たなバージョンができた時点で自動的にサーバ
内部でその前のバージョンに対する消去要求を生成する
構成をとればよい。

【０２７９】なお、以上は図１３のサーバのファイル内
容秘匿機能と非同期編集機能をクライアント・サーバ型
システムに実装した実施例に、クライアント計数部を付
加した例であったが、クライアント計数部は図１６や図
２０の非同期編集機能をクライアント・サーバ型システ
ムに実装した実施例に対して付加することも可能であ
る。この場合、クライアント計数部９００は、図１３の
実施例に付加した場合と、同様の構成・機能を有する。

【０２８０】次に図１３、図１６、あるいは図２０を用
いて説明した非同期編集機能を有する共有ファイル編集
システムにおいて、あるファイルのブロック・データが
暗号化されている場合に、図２５を用いて説明したある
ファイルのあるバージョンを編集中であるクライアント
が存在しなくなるまで消去実行を遅延させる機能と、当
該ファイルののブロック・データを再構成する機能を有
する本発明の第６実施例の共有ファイル編集システムに
ついて説明する。

【０２８１】図２５の実施例で説明したように、履歴管
理を行うシステムにおいては履歴中の一部のバージョン
を消去する機能を提供することが考えられる。ここで
は、ブロック・データが暗号化されている場合にあるバ
ージョンの履歴を消去する機能を提供する実施例を示
す。また、ブロック・データの再構成を行うことにより
ブロック数を減らす機能を提供する実施例も併せて示
す。

【０２８２】本実施例では上記機能を実現するために、
クライアント装置内にファイルのブロックデータを再構
成する手段を設ける。これにより、クライアント装置
は、あるバージョンの履歴を消去するとともにファイル
データを所望のブロックに構成し直すことができる。

【０２８３】以下、前述の図２５の実施例を基にして、
上記機能を設けた共有ファイル編集システムについて説
明する。

【０２８４】図３３は、図２５の実施例に、上記のよう
なブロック・データを再構成する手段を設けた実施例で
ある。図中のファイル管理サーバ９５、通信路１１１
は、図２５の実施例と同様の構成である。アクセス要求
者９２は、ブロック・データ再構成部９１０が加わって
いる点が図２５と異なる。ブロック・データ再構成部９
１０はすべてのアクセス要求者に備わっていなくてもよ
い。あるファイルのあるバージョンの消去命令はクライ
アント計数部９００の計数値が０であるときに実行され
る。

【０２８５】ブロック・データが暗号化されている場合
にあるバージョンの履歴を消去する処理手順は、履歴管
理部５１０が差分積み上げ、ＲＣＳ、変形ＳＣＣＳのい
ずれの管理方法をとっているかによって異なるものであ
り、以下ではそれら３方式についてそれぞれ一例を説明
する。

【０２８６】以下の説明においては、次に示す記号を用
いる。 ｒ：消去対象バージョンのバージョン番号 ｆ：対象となっているファイルの履歴のうちで、履歴管
理部５１０が保持している最も古いバージョンのバージ
ョン番号（多くの場合ｆ＝１であるが、過去にバージョ
ンの消去命令によってバージョン１が消去されている場
合には、ｆは１でない値になる。） ｎ：対象となっているファイルの履歴のうちで、履歴管
理部５１０が保持している最も新しいバージョン（すな
わち現行版）のバージョン番号 ｐ（ｘ）：履歴管理部５１０が保持しているバージョン
のうちで、バージョンｘの１つ前のバージョンのバージ
ョン番号（多くの場合，ｐ＝ｘ−１であるが、過去にバ
ージョンｘ−１が消去された場合には、ｐ＝ｘ−２に、
さらにバージョンｘ−２が消去された場合には、ｐ＝ｘ
−３に等々、順次前のバージョンになる。） ｓ（ｘ）：履歴管理部５１０が保持しているバージョン
のうちで、バージョンｘの１つ後のバージョンのバージ
ョン番号（多くの場合、ｓ＝ｘ＋１であるが、過去にバ
ージョンｘ＋１が消去された場合には、ｓ＝ｘ＋２に、
さらにバージョンｘ＋２が消去された場合には、ｓ＝ｘ
＋３に等々、順次後のバージョンになる。） Ｖ［ｘ］：バージョンｘ（の内容） Ｖ［ｘ］−Ｖ［ｙ］：バージョンｘとバージョンｙとの
差分

【０２８７】最初に、履歴管理部５１０が差分積み上げ
方式により履歴管理を行っている場合の実施例について
説明する。図３４にはクライアント９２におけるブロッ
ク・データ再構成部９１０の処理手順を、図３５にはク
ライアント９２からの消去要求を受けたサーバ９５にお
ける履歴管理部５１０の処理手順を示す。

【０２８８】まず、クライアント９２における処理手順
を示す（図３４）。

【０２８９】１．消去対象が履歴の最初のバージョンや
現行版でない場合（ステップＳ１０１、Ｓ１０６にてｒ
≠ｆかつｒ≠ｎの場合） ・消去対象の後のバージョンＶ［ｓ（ｒ）］をサーバか
ら読み込む。サーバからは暗号化された（複数の）ブロ
ックデータが送られて来る（ステップＳ１０８）。 ・送られてきたブロックデータを復号し、Ｖ［ｓ
（ｒ）］とＶ［ｐ（ｒ）］を復元する。Ｖ［ｐ（ｒ）］
はステップＳ１０８で読み込んだＶ［ｓ（ｒ）］から得
ることができる（ステップＳ１０９）。 ・Ｖ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］を生成する（ステッ
プＳ１１０）。 ・Ｖ［ｓ（ｒ）］−Ｖ［ｐ（ｒ）］を新たなブロック・
データとして暗号器で暗号化する（ステップＳ１１
１）。 ・この暗号化ブロックデータとバージョンｒの消去要求
をサーバへ送る（ステップＳ１１２）。

【０２９０】２．消去対象が履歴の最初のバージョンで
ある場合（ステップＳ１０１にてｒ＝ｆの場合） ・消去対象の後のバージョンＶ［ｓ（ｒ）］をサーバか
ら読み込む。サーバからは暗号化された（複数の）ブロ
ックデータが送られて来る（ステップＳ１０２）。 ・送られてきたブロックデータを復号器で復号し、Ｖ
［ｓ（ｒ）］を復元する（ステップＳ１０３）。 ・Ｖ［ｓ（ｒ）］を新たなブロック・データとして暗号
化する（ステップＳ１０４）。 ・この暗号化ブロックデータとバージョンｒの消去要求
をサーバへ送る（ステップＳ１０５）。

【０２９１】３．消去対象が履歴の最後のバージョン
（現行版）である場合（ステップＳ１０６にてｒ＝ｎの
場合） ・バージョンｒの消去要求をサーバへ送る（ステップＳ
１０７）。

【０２９２】次に、クライアント９２からの消去要求を
受けたサーバ９５の処理手順を示す（図３５）。 １．消去対象が履歴の最初のバージョンや現行版でない
場合（ステップＳ１２１、Ｓ１２３にてｒ≠ｆかつｒ≠
ｎの場合） ・Ｖ［ｓ（ｒ）］−Ｖ［ｒ］ブロック・データおよびＶ
［ｒ］−Ｖ［ｐ（ｒ）］ブロック・データを消去し、代
わりにクライアントから送られてきたＶ［ｓ（ｒ）］−
Ｖ［ｐ（ｒ）］ブロック・データを挿入（ステップＳ１
２５）。

【０２９３】２．消去対象が履歴の最初のバージョンで
ある場合（ステップＳ１２１にてｒ＝ｆの場合） ・Ｖ［ｒ］ブロック・データおよびＶ［ｓ（ｒ）］−Ｖ
［ｒ］ブロック・データを消去し、代わりにクライアン
トから送られてきたＶ［ｓ（ｒ）］ブロック・データを
挿入（ステップＳ１２２）。

【０２９４】３．消去対象が履歴の最後のバージョン
（現行版）である場合（ステップＳ１２３にてｒ＝ｎの
場合） ・Ｖ［ｒ］−Ｖ［ｐ（ｒ）］ブロック・データを消去
（ステップＳ１２４）。以上の処理手順により、バージ
ョンｒの履歴が消去される。

【０２９５】次に、履歴管理部５１０がＲＣＳ方式によ
り履歴管理を行っている場合の実施例について説明す
る。図３６にはクライアント９２におけるブロック・デ
ータ再構成部９１０の処理手順を、図３７にはクライア
ント９２からの消去要求を受けたサーバ９５における履
歴管理部５１０の処理手順を示す。

【０２９６】まず、クライアント９２における処理手順
を示す（図３６）。 １．消去対象が履歴の最初のバージョンや現行版でない
場合（ステップＳ１３１、Ｓ１３３にてｒ≠ｆかつｒ≠
ｎの場合） ・消去対象の前のバージョンＶ［ｐ（ｒ）］をサーバか
ら読み込む。サーバからは最新バージョンを含む暗号化
された（複数の）ブロックデータが送られて来る（ステ
ップＳ１３８）。 ・送られてきたブロックデータを復号器で復号し、Ｖ
［ｓ（ｒ）］とＶ［ｐ（ｒ）］を復元する。Ｖ［ｓ
（ｒ）］はステップＳ１３８で読み込んだＶ［ｐ
（ｒ）］から得ることができる（ステップＳ１３９）。 ・Ｖ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］を生成する（ステッ
プＳ１４０）。 ・Ｖ［ｐ（ｒ）］−Ｖ［ｓ（ｒ）］を新たなブロック・
データとして暗号器で暗号化する（ステップＳ１４
１）。 ・この暗号化ブロックデータとバージョンｒの消去要求
をサーバへ送る（ステップＳ１４２）。

【０２９７】２．消去対象が履歴の最初のバージョンで
ある場合（ステップＳ１３１にてｒ＝ｆの場合） ・バージョンｒの消去要求をサーバへ送る（ステップＳ
１３２）。

【０２９８】３．消去対象が履歴の最後のバージョン
（現行版）である場合（ステップＳ１３３にてｒ＝ｎの
場合） ・消去対象の前のバージョンＶ［ｐ（ｒ）］をサーバか
ら読み込む。サーバからは最新バージョンを含む暗号化
された（複数の）ブロックデータが送られて来る（ステ
ップＳ１３４）。 ・送られてきたブロックデータを復号し、Ｖ［ｐ
（ｒ）］を復元する（ステップＳ１３５）。 ・Ｖ［ｐ（ｒ）］を新たなブロック・データとして暗号
化する（ステップＳ１３６）。 ・この暗号化ブロックデータとバージョンｒの消去要求
をサーバへ送る（ステップＳ１３７）。

【０２９９】次に、クライアント９２からの消去要求を
受けたサーバ９５の処理手順を示す（図３７）。

【０３００】１．消去対象が履歴の最初のバージョンや
現行版でない場合（ステップＳ１５１、Ｓ１５３にてｒ
≠ｆかつｒ≠ｎの場合） ・Ｖ［ｒ］−Ｖ［ｓ（ｒ）］ブロック・データおよびＶ
［ｐ（ｒ）］−Ｖ［ｒ］ブロック・データを消去し、代
わりにクライアントから送られてきたＶ［ｐ（ｒ）］−
Ｖ［ｓ（ｒ）］ブロック・データを挿入（ステップＳ１
５５）。 ２．消去対象が履歴の最初のバージョンである場合（ス
テップＳ１５１にてｒ＝ｆの場合） ・Ｖ［ｒ］−Ｖ［ｓ（ｒ）］ブロック・データを消去
（ステップＳ１５２）。 ３．消去対象が履歴の最後のバージョン（現行版）であ
る場合（ステップＳ１５３にてｒ＝ｎの場合） ・Ｖ［ｒ］ブロック・データおよびＶ［ｐ（ｒ）］−Ｖ
［ｒ］ブロック・データを消去し、代わりにクライアン
トから送られてきたＶ［ｐ（ｒ）］ブロック・データを
挿入（ステップＳ１５４）。以上の処理手順により、バ
ージョンｒの履歴が消去される。

【０３０１】次に、履歴管理部５１０が変形ＳＣＣＳ方
式により履歴管理を行っている場合について説明する。
前述したように、変形ＳＣＣＳ方式においてはブロック
はバージョンがすすむにつれて分割されてくる。ブロッ
ク数が増えると、ブロック識別データやブロック処理の
オーバヘッドが増えてきてしまうため、ブロック数が増
えすぎないようにするのが望ましい。

【０３０２】図３２に示したように、変形ＳＣＣＳ方式
により履歴管理を行っている場合は、サーバ９５の履歴
管理部５１０があるバージョンの履歴消去命令を実行す
ることが出来る。従って、バージョン消去はサーバ９５
の履歴管理部５１０が行い、クライアント９２のブロッ
ク・データ再構成部９１０はブロックの再構成を行うと
いう実施例が考えられる。その場合の手順は以下のよう
になる。

【０３０３】・クライアント９２は、まずサーバ９５に
バージョンｒの消去命令を送る。 ・サーバ９５の履歴管理部５１０は、図３２に示した手
順でバージョンｒの履歴を消去する。 ・クライアント９２は、Ｖ［ｓ（ｒ）］あるいはＶ
［ｎ］のファイルを読み込み、ブロックデータ・再構成
部９１０においてブロックの再構成および暗号化を行
う。再構成できるブロックデータは位置が連続しており
かつ生成時間と消去時間が等しいブロックである。これ
らのブロックを復号した後、任意の新たなブロック・デ
ータとして再構成し暗号化してサーバ９５へ送る。 ・サーバ９５の履歴管理部５１０は送られてきたブロッ
クを古いブロックと入れ換える。

【０３０４】尚、この第６実施例におけるブロックデー
タ再構成に関する特徴を、上述した図２３の様にファイ
ル内容の秘匿機能のみを有するファイル編集システムに
組み込むことも可能である。

【０３０５】次に、図１３、図１６、あるいは図２０を
用いて説明したファイル編集システムにおいて、クライ
アントが、あるファイルのあるバージョンを既に保有し
ているときに新たに別のバージョンを読み込もうとする
場合、ファイル全体を読み込むのではなく、必要な部分
だけを読み込む機能を設けた本発明の第７実施例のファ
イル編集システムについて説明する。

【０３０６】図３８は、図１３の実施例に、上記のよう
なクライアントがサーバから必要な部分だけを読み込む
機能を設けた実施例である。図中の通信路１１１は、図
１３の実施例と同様の構成である。ファイル管理サーバ
９６は、差分情報構築部９３０が、アクセス要求者９３
はファイル記憶部９２０とファイルデータ構築部９２１
が加わっている点が、図１３と異なる。

【０３０７】クライアント９３は、前回アクセスしたフ
ァイルをそのバージョン情報とともにファイル記憶部９
２０に保存している。サーバ９６から、同ファイルの別
のバージョン（例えば最新バージョン）を読み込もうと
する場合、現在保有しているバージョン情報と所望のバ
ージョン情報をサーバ９６に伝える。サーバ９６の差分
情報構築部９３０は、クライアント９３からの２つのバ
ージョン情報に基づきクライアント９３が所有するバー
ジョンのファイルに対する差分データを構築しクライア
ント９３に送り返す。クライアント９３のファイルデー
タ構築部９２１は、現在保有しているファイルデータと
サーバ９６からの差分データにより所望のバージョンを
構築する。そして共有ファイル編集部１２２に渡すこと
によりファイルを編集することができる。

【０３０８】一般に、バージョン間の差分データはファ
イル全体のデータよりも少いため通信量が少くてすみ、
高速な読み込みが実現できる。

【０３０９】サーバ９６の差分情報構築部９３０におい
て差分データを構築する方法は、履歴管理部５１０が差
分積み上げ、ＲＣＳ、変形ＳＣＣＳのいずれの管理方法
をとっているかによって異なる。以下ではそれら３方式
についてそれぞれ実施例の一例を説明する。以下の説明
においては、次に示す記号を用いる。 ｃ：クライアントが保有しているファイルのバージョン
番号 ｒ：クライアントが新たに読み込むバージョン番号 Ｖ［ｘ］：バージョンｘ（の内容） Ｖ［ｘ］−Ｖ［ｙ］：バージョンｘとバージョンｙとの
差分 最初に、履歴管理部５１０が差分積み上げ方式により履
歴管理を行っている場合の、差分情報構築部９３０の処
理手順の実施例について説明する。

【０３１０】１．保有しているバージョンよりも新しい
バージョンを読み込む場合（ｒ＞ｃ） ・差分積み上げ方式はバージョン間の差分を積み上げて
いくものであるから、バージョンｒとｃとの差分ブロッ
ク・データを選べばよい。 ２．保有しているバージョンよりも古いバージョンを読
み込む場合（ｒ＜ｃ）

【０３１１】以下の２つの方法がある。

【０３１２】（ａ）差分情報を構築せずＶ［ｒ］を返
す。ブロック・データが暗号化されている場合は、サー
バは差分情報を構築できないので本方法をとる。 （ｂ）サーバがＶ［ｒ］とＶ［ｃ］を復元しＶ［ｒ］−
Ｖ［ｃ］を生成する。ブロック・データが暗号化されて
いない場合は本方法が可能。

【０３１３】次に、履歴管理部５１０がＲＣＳ方式によ
り履歴管理を行っている場合の、差分情報構築部９３０
の処理手順の実施例について説明する。 １．保有しているバージョンよりも新しいバージョンを
読み込む場合（ｒ＞ｃ）以下の２つの方法がある。 （ａ）差分情報を構築せずＶ［ｒ］を返す。ブロック・
データが暗号化されている場合は、サーバは差分情報を
構築できないので本方法をとる。 （ｂ）サーバがＶ［ｒ］とＶ［ｃ］を復元しＶ［ｒ］−
Ｖ［ｃ］を生成する。ブロック・データが暗号化されて
いない場合は本方法が可能。 ２．保有しているバージョンよりも古いバージョンを読
み込む場合（ｒ＜ｃ） ・ＲＣＳ方式はバージョン間の逆方向の差分を履歴とし
て残すものであるから、バージョンｃとｒの差分ブロッ
ク・データを選べばよい。

【０３１４】次に、履歴管理部５１０が変形ＳＣＣＳ方
式により履歴管理を行っている場合の、差分情報構築部
９３０の処理手順の実施例について説明する。図３９
に、差分情報構築部９３０がファイルの履歴を構成する
ブロックから差分ブロックを選択する処理手順のフロー
チャートを示す。尚、図３９のフローチャートは、履歴
を構成するブロックの１つに対する差分ブロック選択処
理手順を示している。差分情報構築部９３０における差
分ブロック選択処理は、本フローチャートに示す手順
を、全てのブロック各々に対して施すことによって行わ
れる。

【０３１５】以下の説明においては、次に示す記号を用
いる。 ｉ：処理対象となっているブロックの生成バージョン番
号 ｄ：処理対象となっているブロックの消去バージョン番
号 まだ消去されていないブロックは、ｄ＝ＮＵＬＬで表す
ものとする。

【０３１６】１．保有しているバージョンよりも新しい
バージョンを読み込む場合（ステップＳ１６１において
ｒ＞ｃの場合） 以下の条件のどれかを満たすブロックを選択する（ステ
ップＳ１６７）。 （ａ）バージョンｃからｒの間に生成されてｒの時点で
消去されていないブロック つまり、（ｒ＞ｉ＞ｃ）ａｎｄ｛（ｒ＜ｄ）ｏｒ（ｄ＝
ＮＵＬＬ）｝（ステップＳ１６２） （ｂ）バージョンｃの時点で生成されていてｃからｒの
間に消去されたブロック つまり、（ｉ＜ｃ）ａｎｄ（ｒ＞ｄ＞ｃ）（ステップＳ
１６３）

【０３１７】２．保有しているバージョンよりも古いバ
ージョンを読み込む場合（ステップＳ１６４においてｒ
＜ｃの場合） 以下の条件のどれかを満たすブロックを選択する（ステ
ップＳ１６７）。 （ａ）バージョンｒからｃの間に生成されてｃの時点で
消去されていないブロック つまり、（ｒ＜ｉ＜ｃ）ａｎｄ｛（ｄ＞ｃ）ｏｒ（ｄ＝
ＮＵＬＬ）｝（ステップＳ１６５） （ｂ）バージョンｃの時点で生成されていてｒからｃの
間に消去されたブロック つまり、（ｉ＞ｃ）ａｎｄ（ｒ＜ｄ＜ｃ）（ステップＳ
１６６）

【０３１８】差分情報構築部９３０は上記手順にて差分
ブロックを選択後、そのブロック情報をクライアント９
３が現在保有しているバージョンに対する差分情報に変
換してクライアント９３に送る。例えば、挿入データに
対しては、クライアント９３が保有しているバージョン
に対する挿入位置を求め挿入ブロック・データと共に送
る。削除データに対しては、クライアント９３が保有し
ているバージョンに対する削除範囲を求めその情報を送
る。これより、クライアント９３は所望のバージョンを
容易に構築すことができる。また、サーバ９６からクラ
イアント９３への通信データ量が少くてすむ。

【０３１９】尚、この第７実施例における所望のバージ
ョンの構築に関する特徴を、上述した図２３の様にファ
イル内容秘匿機能のみを有するファイル編集システムに
組み込むことも可能である。

【０３２０】次に、図１３、図１６、あるいは図２０を
用いて説明した非同期編集機能を有する共有ファイル編
集システムにおいて、あるファイルに対して複数のクラ
イアントからの書き込みが非同期に起こるために編集の
競合が生じる場合があるが、その対応策を施した本発明
の第８実施例を示す。

【０３２１】図４０は、図１６の実施例に、上記のよう
な機能がサーバに組み込まれた実施例である。図中のア
クセス要求者２１１、通信路１１１は、図１６の実施例
と同様の構成である。ファイル管理サーバ２２０は、編
集競合検出部９４０が加わっている点が図１６と異な
る。

【０３２２】本実施例では、図１６の例と同様に複数の
クライアント２１１からのデータの書き込み要求が様々
なタイミングで発生する。サーバ２２０では、２１１か
らの書き込み要求を編集手続き変換部５０２にてその時
点での最新版に対する位置データに変換する。そして、
編集競合検出部９４０において、その変換された編集デ
ータが他のクライアント２１１による編集結果と競合し
ていないかどうかを検出する。その検出結果は、クライ
アント２１１に返される。ここで競合しているとは、例
えば以下のように判断することができる。 ・挿入データの挿入地点が既に削除されている ・挿入データの挿入地点に別のデータが挿入されている ・削除範囲に別のデータが挿入されている ０・削除範囲の一部が既に削除されている

【０３２３】履歴管理部５１０では編集競合検出部９４
０の結果は受け取らず、編集手続き変換部５０２にて変
換されたクライアント２１１から送られたデータを最新
バージョンとして保存する。

【０３２４】上記のサーバ２２０におけるデータ更新機
能は、履歴管理部５１０の管理方法とブロック・データ
が暗号化されているかどうかにより、実現可能な場合と
実現不可能な場合がある。ブロック・データが暗号化さ
れていない場合は、差分積み上げ、ＲＣＳ、変形ＳＣＣ
Ｓのいずれの管理方法においても実現可能である。ブロ
ック・データが暗号化されている時は、変形ＳＣＣＳ方
式のみで実現可能となる。

【０３２５】次に同様の構成において編集競合検出部９
４０の競合検出結果を履歴管理部５１０に通知し、履歴
管理部５１０はその検出結果に基づいてデータの更新を
行うかどうかの判断を行う本発明の第９実施例を示す。

【０３２６】図４１は、図４０の実施例に上記のような
機能がサーバに組み込まれた実施例である。図中のアク
セス要求者２１１、通信路１１１は、図４０の実施例と
同様の構成である。ファイル管理サーバ２２５は、編集
競合検出部９４０の出力が履歴管理部５１０に入力され
ている点が図４０と異なる。

【０３２７】本実施例によると例えば、他のクライアン
トとの編集競合が起こらなかった場合は、編集手続き変
換部５０２にて変換されたクライアント２１１から送ら
れたデータを最新バージョンとして保存し、編集競合が
起こった場合はサーバ２２５のデータを更新しないとい
うという機能が実現できる。この場合、書き込みが行わ
れた最新バージョンは、他のクライアント２１１との編
集競合が起こっていないので、意味的矛盾が起こりにく
いという利点がある。クライアント２１１は編集競合検
出部９４０による検出結果の通知を受けるので、書き込
みが行われなかった場合は、サーバ２２５から最新バー
ジョンを読み込み競合が起こらないように編集し直すこ
とができる。

【０３２８】次に、共有ファイル編集システムを既存の
アプリケーション・プログラムから利用することを可能
にした本発明の第１０実施例を示す。

【０３２９】図４１は、既存のアプリケーション・プロ
グラムから共有ファイル編集システムを利用する実施例
である。図中のファイル管理サーバ９７０は、通信部１
３１、アクセス情報記憶部９７１、共有ファイル履歴管
理部９７２、データ記憶部９７３を有する。アクセス要
求者９５０は、アクセス要求部９５１、システム・コー
ル・テーブル９５５、共有ファイルアクセス処理部９６
０、通信部１３０を有する。ファイル管理サーバ９７０
とアクセス要求者９５０は通信部１３０，１３１を通し
て、通信路１１１により通信可能である。

【０３３０】本実施例では、アクセス要求部９５１は既
存アプリケーション・プログラムであると想定し、アク
セス要求部９５１により発せられるアクセス要求はオペ
レーティング・システムによって提供されるシステム・
コールによって行われるとする。

【０３３１】本実施例おいて、アクセス要求部９５１
は、システム・コール・テーブル９５５の持つシステム
・コールに対応する関数を参照した上で、ｏｐｅｎ／ｃ
ｌｏｓｅ／ｒｅａｄ／ｗｒｉｔｅの関数を実行する。オ
ペレーティング・システムにおけるシステム・コールの
関数を参照するシステム・コール・テーブル９５５のデ
ータは、オペレーティング・システムによって提供され
るｏｐｅｎ関数／ｃｌｏｓｅ関数／ｒｅａｄ関数／ｗｒ
ｉｔｅ関数への接続データ（アドレス・ポインタ）か
ら、共有ファイルアクセス処理部９６０によって提供さ
れる共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅ
ａｄ関数／共有ｗｒｉｔｅ関数９６１への接続データ
（アドレス・ポインタ）に書き換えられている。この共
有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関
数／共有ｗｒｉｔｅ関数９６１は、通信部１３０を通し
てファイル管理サーバ９７０に送られる。

【０３３２】従って、既存のアプリケーション・プログ
ラムからなるアクセス要求部９５１がｏｐｅｎ関数／ｃ
ｌｏｓｅ関数／ｒｅａｄ関数／ｗｒｉｔｅ関数を実行し
た結果、実際は共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数
／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数９６１が実行
されることになる。

【０３３３】ここで、共有ｏｐｅｎ関数／共有ｃｌｏｓ
ｅ関数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数は、そ
れぞれ、“ｏｐｅｎ”をする共有ファイルアクセス要求
に応じた処理／“ｃｌｏｓｅ”をする共有ファイルアク
セス要求に応じた処理／“ｒｅａｄ”をする共有ファイ
ルアクセス要求に応じた処理／“ｗｒｉｔｅ”をする共
有ファイルアクセス要求に応じた処理に該当する。な
お、図４２では、共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関
数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数９６１は、
それぞれ独立した形で構成されているが、各関数９６１
に共通する処理に対応する部分は１つの処理実体として
４つの関数で共有化してもよい。

【０３３４】ファイル管理サーバ９７０は、アクセス要
求者９５０より共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関数
／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数を受け取り、
共有ファイル用履歴管理部９７２に渡す。共有ファイル
用履歴管理部９７２は、アクセス情報記憶部９７１の情
報を元にデータ記憶部９７３から所望のデータの読み込
みあるいは書き込みを行うことができる。そして、行わ
れたアクセス要求をアクセス情報記憶部９７１のデータ
に記録する。

【０３３５】図４３には、アクセス情報記憶部９７１の
アクセス履歴リスト９８０の例を示す。アクセス履歴リ
スト９８０は、ファイル管理サーバ９７０のファイルへ
のアクセス要求を記憶したリストである。このアクセス
履歴リスト９８０には、ファイル識別子９８１、モード
９８２、オープン時刻９８３、クローズ時刻９８４、バ
ージョン９８５、カレント９８６の６つのフィールドが
ある。

【０３３６】ファイル識別子９８１は、アクセス要求部
９５１から共有ファイル用履歴管理部９７２に対して与
えられた“ｏｐｅｎ”の共有ファイル・アクセス要求ご
とに固有に割り当てられる識別子である。“ｏｐｅｎ”
要求以後は、アクセス要求部９５１からの共有ファイル
・アクセス要求は、ファイル識別子９８１を用いて管理
される。このファイル識別子９８１は、共有ファイル用
履歴管理部９７２が“ｏｐｅｎ”の共有ファイルアクセ
ス要求を受け付ける度に、アクセス要求部９５１に対し
て発給する。

【０３３７】モード９８２は、このファイルへのｏｐｅ
ｎ要求のモードを示したもので、ここに書かれている
“ｒ”は読みだし専用であることを意味している。ま
た、ここに“ｗ”と書かれていれば、書き込み専用また
は読み書き両用のモードであることを意味している。

【０３３８】オープン時刻９８３は、このファイルへの
ｏｐｅｎ要求が発せられた時刻を示している。この例の
ＩＤ１で表されるファイルは、時刻ｔ１にオープンされ
たことを意味している。また、クローズ時刻９８４は、
このファイルへのｃｌｏｓｅ要求が発せられた時刻を示
している。この例では、ＩＤ１で表されるファイルはク
ローズ時刻９８４が書かれていないので、現在オープン
中であることを、ＩＤ２で表されるファイルは、時刻ｔ
５にクローズされたことを意味している。

【０３３９】ここで、上記の時刻は、各事象の発生した
時刻の前後関係を示すためのものであり、例えば、計算
機の持つ内部的な時計でもよいし、ファイル管理にバー
ジョン番号をつけてそれを時刻として用いてもよい。ま
た、この時刻は共有ファイル用履歴管理部９７２だけで
用いるものであるから、必ずしも他の部分（例えばアク
セス要求者９５０）から直接にこの時刻が参照できなく
てもよい。

【０３４０】バージョン９８５は、このファイルへのｏ
ｐｅｎ要求が発せられたファイルのバージョンを示す。
通常、システム・コールのｏｐｅｎは最新バージョンに
対する要求であるので、ｏｐｅｎ要求が発せられた時点
での最新のバージョンが入ることが多い。

【０３４１】カレント９８６は、現在アクセスしている
アクセス要求に関して、現在アクセスしている位置を示
す値（シーク・ポインタ）である。このシーク・ポイン
タは、次に来る“ｒｅａｄ”の共有ファイル・アクセス
要求に対して、読み出す位置（ファイル内の相対位置）
を示すものであり、読みだし専用の“ｏｐｅｎ”の場
合、デフォルトとして初期値が０となっている。

【０３４２】共有ファイル用履歴管理部９７２は、アク
セス要求者９５０からの非同期アクセスを管理し、アク
セス情報記憶部９７１の内容に従い、データ記憶部９７
３から所望のデータの読み書きを行う。共有ファイル用
履歴管理部９７２の動作は前述の実施例と同様であるの
で、ここでは詳細に説明しない。

【０３４３】このように本実施例によれば、オペレーテ
ィング・システムによって提供されるシステム・コール
・テーブル９５５中のアドレス・ポインタの値を書き換
えるだけで、既存のアプリケーション・ソフトウェア等
のプログラム自体は全く変更せずに、アクセス要求者と
して利用して非同期編集を行うこが可能になる。

【０３４４】次に、上記第１０実施例と同様な目的をも
った本発明の第１１実施例を図４４に示す。図４４にお
いては、図４２のファイル管理サーバ９７０が保有して
いたアクセス情報記憶部９７１をアクセス要求者９９０
が有する構成をとっている。ファイル管理サーバ９０は
図１３で示したファイル管理サーバと同様の構成であ
り、共有ファイル用履歴管理部５１０、データ記憶部５
１１、通信部１３１からなる。

【０３４５】本実施例においては、アクセス要求者の９
９０は自らが保有するアクセス要求部９９１からの共有
ファイルアクセス情報をアクセス情報記憶部９９５に記
憶する。アクセス情報記憶部９９５の内容は、例えば図
４３と同じものを用いることができる。

【０３４６】共有ファイルアクセス処理部９９３は、ア
クセス情報記憶部９９５の情報を読み込み、共有ｏｐｅ
ｎ関数／共有ｃｌｏｓｅ関数／共有ｒｅａｄ関数／共有
ｗｒｉｔｅ関数９９４の引数として、それぞれの関数に
必要な情報を加えてファイル管理サーバ９０に要求を送
る。

【０３４７】例えば、アクセス要求部９９１よりファイ
ル識別子ＩＤ１のファイルから１０バイト読み込みたい
というｒｅａｄシステム・コールが発せられた時、共有
ファイルアクセス処理部９９３は、アクセス情報記憶部
９９５から、ファイル識別子ＩＤ１に関するバージョン
情報９８５、カレント位置情報９８６を読み込み、ファ
イル識別ＩＤ１と読み込むバイト数とともに、共有ｏｐ
ｅｎ関数の引数に付加してファイル管理サーバ９０に送
る。

【０３４８】アクセス要求者９９０からファイル管理サ
ーバ９０に送られる要求には、通常のオペレーティング
・システムのシステム・コールで付与される情報以外に
アクセス要求者の現在のアクセス情報も含まれているの
で、その情報をもとに共有ファイル用履歴管理部５１０
は、データ記憶部５１１から所望のデータを取り出すこ
とができる。

【０３４９】このように本実施例においても、オペレー
ティング・システムによって提供されるシステム・コー
ル・テーブル９９２中のアドレス・ポインタの値を書き
換えるだけで、既存のアプリケーションソフトウェア等
のプログラム自体は全く変更せずに、アクセス要求者と
して利用して非同期編集を行うことが可能になる。

【０３５０】尚、上記第１０，第１１実施例における既
存のアプリケーション・プログラムを共有ファイルに対
して使用可能とする特徴で、共有ファイルに対するアク
セス関数を暗号化ファイルに対するアクセス関数に変え
ることで、既存のアプリケーション・プログラムを暗号
化ファイルに対して使用可能とする特徴として、上述し
た図２３の様にファイル内容秘匿機能のみを有するファ
イル編集システムに組み込むことも可能である。

【０３５１】また、上述の各実施例においてクライアン
トとサーバの通信部の間の通信路を介した通信はクライ
アント・コンピュータとサーバ・コンピュータの間のネ
ットワーク通信の形でも良いし、クライアント・プログ
ラムとサーバ・プログラムの間のデータ転送の形でも良
い。

【０３５２】尚、本発明は上述した各実施例に限定され
るものではなく、その要旨を逸脱しない範囲で、種々変
更して実施することができる。

【０３５３】

【発明の効果】以上説明したように、本発明（請求項
１，５〜１１，２２）によれば、ファイルをブロック単
位で暗号化するとともに、各ブロックに暗号化していな
いブロック識別子を付加したので、復号鍵を持つ正規の
クライアント装置のみがファイルの内容を読み取ること
ができるとともに、ファイル管理サーバ装置にはファイ
ルの内容が秘匿されているが、データ構造は管理させる
ことができる秘匿性の高いファイル編集システムを提供
することができる。

【０３５４】本発明（請求項２，８，１２〜１８，２
３）によれば、ファイルをブロック単位で暗号化すると
ともに、各ブロックに暗号化していないブロック識別子
を付加したので、復号鍵を持つ正規のクライアント装置
のみがファイルの内容を読み取ることかできるととも
に、ファイル管理サーバ装置にはファイルの内容が秘匿
されているが、データ構造は管理させることができる秘
匿性の高い共有ファイル編集システムを提供することが
できる。

【０３５５】また、ファイル管理サーバ装置は、クライ
アント装置から渡されたファイル編集の内容を示すデー
タを、該クライアント装置がアクセスして得たバージョ
ンがいずれであるかに従って、該ファイル管理サーバ装
置内での最新バージョンに対する編集内容に変換する処
理を行うので、前記ファイル管理サーバ装置側では例え
ば“どのクライアントがどのバージョンのファイルをオ
ープンしている”といったアクセス状況の情報を持つ必
要がなくロック機構不要な仕組みで非同期編集可能な共
有ファイル編集システムを構成することができる。

【０３５６】特に、時間的に古いバージョンを編集し、
最新バージョンとする使い方が可能となる。すなわち、
非同期編集可能な共有ファイルにおいて、編集対象を現
行版に限定しない使い方が可能となる。

【０３５７】本発明（請求項３，８，１２〜１６，１
８，２４）によれば、ファイルをブロック単位で暗号化
するとともに、各ブロックに暗号化していないブロック
識別子を付加したので、復号鍵を持つ正規のクライアン
ト装置のみがファイルの内容を読み取ることができると
ともに、ファイル管理サーバ装置にはファイルの内容が
秘匿されているが、データ構造は管理させることができ
る秘匿性の高い共有ファイル編集システムを提供するこ
とができる。

【０３５８】一方、上記データを採用することにより、
ファイル管理サーバ装置では、常に各クライアント装置
による編集終了時における最新バージョンのファイルの
内容に対する更新が行われるようにしたので、ロックを
掛けずに複数のクライアント装置による非同期編集を行
うことが可能となる。

【０３５９】本発明（請求項４，９〜１１，１９〜２
１，２５）によれば、ファイル管理サーバ装置は、クラ
イアント装置から渡されたファイル編集の内容を示すデ
ータを、該クライアント装置がアクセスして得たバージ
ョンがいずれであるかに従って、該ファイル管理サーバ
装置内での最新のバージョンに対する編集内容に変換す
る処理を行うので、前記ファイル管理サーバ装置側で例
えば“どのクライアントがどのバージョンのファイルを
オープンしている”といったアクセス状況の情報を持つ
必要がなくロック機構不要な仕組みで非同期編集可能な
共有ファイル編集システムを構成することができる。

【０３６０】特に、時間的に古いバージョンを編集し、
最新バージョンとする使い方が可能となる。すなわち、
非同期編集可能な共有ファイルにおいて、編集対象を現
行版に限定しない使い方が可能となる。

【０３６１】また、本発明（請求項５，６）によれば、
ファイルをブロック単位で暗号化するとともに、各ブロ
ックに暗号化していないブロック識別子を付加したの
で、復号鍵を持つ正規のクライアント装置のみがファイ
ルの内容を読み取ることができるとともに、ファイル管
理サーバ装置にはファイルの内容が秘匿されているが、
データ構造は管理させることができる秘匿性の高い共有
ファイル編集システムを提供することができる。

【０３６２】一方、上記データ構造を採用することによ
り、ファイル管理サーバ装置ではクライアント装置から
渡された編集内容を示す暗号化されたブロック・データ
とブロック識別情報とに基づいて、該ファイルの履歴管
理を行うことができる。

【０３６３】このように、ファイルの履歴管理とファイ
ル管理サーバ装置に対するデータの秘匿性を同時に実現
できる。

【０３６４】また、本発明（請求項９）によれば、クラ
イアント装置は、ファイル管理サーバ装置からファイル
を得ることができ、保有している復号鍵を用いて該ブロ
ック・データを復号化し、得られた復号化データをブロ
ック新たなブロック・データに再構成し、暗号鍵を用い
て新たなブロック・データごとに暗号化し、ファイル管
理サーバ装置に出力することができる。

【０３６５】また、これにより、クライアント装置によ
り、履歴情報の消去を行ったり、ファイルのブロック・
データ数が多くなった時などにブロックを再構成し、ブ
ロック識別情報によるオーバヘッドを削減することがで
きる。暗号鍵／復号鍵を有するクライアント装置が行う
ことにより、サーバに対するファイルの内容の秘匿性は
守られる。

【０３６６】また、本発明（請求項１０）によれば、ク
ライアント装置は、あるバージョンのファイルを保存す
る手段を有し、ファイル管理サーバ装置から、現在クラ
イアント装置が保有しているバージョンのファイルと、
所望のバージョンのファイルの差分情報を受け取り、ク
ライアントが保有している当該ファイルのデータとファ
イル管理サーバ装置からの差分情報により、所望のバー
ジョンのファイルを構築し編集することができる。

【０３６７】従って、クライアント装置は、ファイル全
体ではなく、現在保有するバージョンと所望するバージ
ョンとの差分情報のみをファイル管理サーバ装置から取
得すればよく、通信量の削減を図ることができるととも
に、ブロック・データが暗号化されている場合はクライ
アント装置での復号化処理量を削減できる。

【０３６８】本発明（請求項１１）によれば、オペレー
ティング・システムによって提供されるコールテーブル
中のアドレス・ポインタの値を書き換えるだけで、既存
のアプリケーションソフトウェア等のプログラム自体は
全く変更せずに、アクセス要求者として利用して非同期
編集を行うことが可能になる。

【０３６９】本発明（請求項１９）によれば、ファイル
管理サーバ装置では、各々のファイルの各々のバージョ
ンについて、それを編集しているクライアント装置の数
を記憶し、ユーザから消去の要求があっても消去対象と
なるファイルのバージョンを編集するクライアントがな
くなるまで消去の実行を遅延させるので、いずれかのク
ライアントが編集途中のバージョンを消去することがな
くなり、マージ処理の実行に支障をきたすおそれがなく
なる。

【０３７０】また、本発明（請求項２０，２１）によれ
ば、各クライアント装置による編集結果は、ファイル管
理サーバ装置における最新バージョンのファイルに対す
る更新に変換され、他のクライアントによる編集と競合
するか否かによらず、ファイル管理サーバ装置に最新バ
ージョンとして更新されるため、ロックを掛けずに複数
のクライアント装置による非同期編集を行うことが可能
となる。

【０３７１】また、ファイル更新を行ったクライアント
は、ファイル管理サーバ装置より、編集内容の競合検出
の結果を通知されるので、その結果に基づいて、ファイ
ルを編集し直すことができる。その際、ファイル管理サ
ーバ装置ではファイルは履歴管理されているので、過去
のバージョンを取り出すなどして柔軟に編集を行うこと
ができる。

【０３７２】また、請求項２１のように構成した場合、
ファイル管理サーバ装置は、他のクライアントによる編
集との競合検出の結果に基づいて、ファイルの更新を行
うかどうかを判断することができるので、ファイル管理
サーバ装置の最新バージョンのファイルにおいて意味的
矛盾が起こりにくい、あるいは起こらないようにするこ
とができる。

【図面の簡単な説明】

【図１】本発明の第１実施例に係る共有ファイル編集シ
ステムの基本構成を示すブロック図。

【図２】同実施例の差分積み上げ方式による履歴管理法
でのファイルのデータ構造を示す図。

【図３】同実施例のＲＣＳ方式による履歴管理法でのフ
ァイルのデータ構造を示す図。

【図４】同実施例の変形ＳＣＣＳ方式による履歴管理法
でのファイルのデータ構造を示す図。

【図５】同実施例の非同期編集機構の基本構成を示すブ
ロック図。

【図６】同実施例の差分積み上げ方式による履歴管理時
の非同期編集機構の働きを説明する図。

【図７】同実施例の変形ＳＣＣＳ方式による履歴管理時
の非同期編集機構の働きを説明する図。

【図８】同実施例のＯＦＢモードによる暗号化手順を説
明するための図。

【図９】同実施例のＣＦＢモードによる暗号化手順を説
明するための図。

【図１０】同実施例の暗号方式によるブロック・データ
分割時の暗号手順を説明するための図。

【図１１】同実施例のファイル・ブロック分割時の暗号
化に関わる処理を説明するフローチャート。

【図１２】同実施例のファイル・ブロック分割時の暗号
化に関わる他の処理を説明するフローチャート。

【図１３】本発明の第２実施例に係る共有ファイル編集
システムのより具体的な一構成例を示すブロック図。

【図１４】図１３の共有ファイル編集部の内部構成を示
すブロック図。

【図１５】図１３の暗号器の内部構成を示すブロック
図。

【図１６】本発明の第２実施例に係る共有ファイル編集
システムのより具体的な他の構成例を示すブロック図。

【図１７】図１６の共有ファイル編集部の内部構成を示
すブロック図。

【図１８】図１３の共有ファイル編集部の要部構成をま
とめたブロック図。

【図１９】図１６の共有ファイル編集部の要部構成をま
とめたブロック図。

【図２０】本発明の第３実施例に係る共有ファイル編集
システムの基本構成を示すブロック図。

【図２１】図２０の共有ファイル編集部の内部構成を示
すブロック図。

【図２２】図２０のマージ処理部の内部構成を示すブロ
ック図。

【図２３】本発明の第４実施例に係る共有ファイル編集
システムの基本構成を示すブロック図。

【図２４】図２３の暗号器の内部構成を示すブロック
図。

【図２５】本発明の第５実施例に係る共有ファイル編集
システムの基本構成を示すブロック図。

【図２６】図２５のクライアント計数部の内部構成を示
すブロック図。

【図２７】図２６の計数記憶部に記憶されるデータのデ
ータ構造を説明するための図。

【図２８】図２６の消去要求処理部の処理の流れを示す
フローチャート。

【図２９】図２６の編集終了処理部の処理の流れを示す
フローチャート。

【図３０】図２５で履歴管理部５１０が差分積み上げ方
式により履歴管理を行う場合の消去命令の実行処理手順
を示すフローチャート。

【図３１】図２５で履歴管理部５１０がＲＣＳ方式によ
り履歴管理を行う場合の消去命令の実行処理手順を示す
フローチャート。

【図３２】図２５で履歴管理部５１０が変形ＳＣＣＳ方
式により履歴管理を行う場合の消去命令の実行処理手順
を示すフローチャート。

【図３３】本発明の第６実施例に係る共有ファイル編集
システムの基本構成を示すブロック図。

【図３４】図３３で履歴管理部が差分積み上げ方式によ
り履歴管理を行う場合のブロック・データ再構成部の処
理手順を示すフローチャート。

【図３５】図３３で履歴管理部が差分積み上げ方式によ
り履歴管理を行う場合のサーバの履歴管理部の処理手順
を示すフローチャート。

【図３６】図３３で履歴管理部がＲＣＳ方式により履歴
管理を行う場合のブロック・データ再構成部の処理手順
を示すフローチャート。

【図３７】図３３で履歴管理部がＲＣＳ方式により履歴
管理を行う場合のサーバの履歴管理部の処理手順を示す
フローチャート。

【図３８】本発明の第７実施例に係る共有ファイル編集
システムの基本構成を示すブロック図。

【図３９】履歴管理部が変形ＳＣＣＳ方式により履歴管
理を行う場合のサーバの差分情報構築部の差分ブロック
選択処理手順を示すフローチャート。

【図４０】本発明の第８実施例に係る共有ファイル編集
システムの基本構成を示すブロック図。

【図４１】本発明の第９実施例に係る共有ファイル編集
システムの基本構成を示すブロック図。

【図４２】本発明の第１０実施例に係る共有ファイル編
集システムの基本構成を示すブロック図。

【図４３】図４２のアクセス情報記憶部が記憶する情報
の例を示す図。

【図４４】本発明の第１１実施例に係る共有ファイル編
集システムの基本構成を示すブロック図。

【符号の説明】

９１，９２，９３，１０１，２１１，７０１，８０１，
９５０，９９０ アクセス要求者（クライアント） ９０，９５，９６，１１０，２１０，２２０，２２５，
７１０，８１０，９７０ ファイル管理サーバ（サー
バ） １１１ 通信路 １１２，２１２，８１２ 暗号器 １１３ 共有ファイル １２１，２２１，７２１，８２１ メモリ １２２，２２２，７２２ 共有ファイル編集部 １３０，１３１，１３２，２３０，２３１，７３０，７
３１，８３０〜８３２通信部 ２０１，２０２，２０３，２０４ 差分積み上げ方式で
のブロック ３０１，３０２，３０３，３０４ ＲＣＳ方式でのブロ
ック ４０１，４０２，４０３，４０４，４０５ ＳＣＣＳ方
式でのブロック ４０６ 生成時点フィールド ４０７ 消去時点フィールド ５００ 編集部 ５０１ 編集手続き生成部 ５０２ 編集手続き変換部 ５０３ 履歴管理情報生成部 ５１０ 履歴管理部 ５１１，９７３ データ記憶部 ７４０ マージ処理部 ８２２ ファイル編集部 ８４０ データ管理部 １１２１，８１２１ 暗号化／復号化処理部 １１２２，８１２２ 鍵記憶部 ９００ クライアント計数部 ９０１ 分岐部 ９０２ 編集開始処理部 ９０３ 消去要求処理部 ９０４ 編集終了処理部 ９０５ 計数記憶部 ９０６ 消去命令発行部 ９１０ ブロック・データ再構成部 ９２０ ファイル記憶部 ９２１ ファイルデータ構築部 ９３０ 差分情報構築部 ９４０ 編集競合検出部 ９５１，９９１ アクセス要求部 ９５５，９９２ システム・コール・テーブル ９６０，９９３ 共有ファイルアクセス処理部 ９６１，９９４ 共有ｏｐｅｎ関数／共有ｃｌｏｓｅ関
数／共有ｒｅａｄ関数／共有ｗｒｉｔｅ関数 ９７１，９９５ アクセス情報記憶部 ９７２ 共有ファイル用履歴管理部 ９８０ アクセス履歴リスト ９８１ ファイル識別子 ９８２ モード ９８３ オープン時刻 ９８４ クローズ時刻 ９８５ バージョン ９８６ カレント

───────────────────────────────────────────────────── フロントページの続き (72)発明者 友田 一郎 神奈川県川崎市幸区小向東芝町１ 株式会 社東芝研究開発センター内

Claims (25)

【特許請求の範囲】
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. 【請求項２５】 各ファイルが複数のブロックデータと
    各ブロックのブロック識別情報とを含むファイルを管理
    するファイル管理サーバ装置と、ファイル編集を行なう
    複数のクライアント装置からなる共有ファイル管理シス
    テムにおいてファイルを編集する方法であって、 各クライアント装置において、前記ファイル管理サーバ
    装置にアクセスして該ファイル管理サーバ装置が管理す
    る所望のファイルの所望のバージョンに対応するブロッ
    クデータを取得するステップと、 各クライアント装置において、前記取得するステップで
    前記ファイル管理サーバ装置から取得したブロックデー
    タによって構成される前記所望のファイルの所望のバー
    ジョンを編集するステップと、 各クライアント装置により前記所望のファイルになされ
    た編集内容を得る手続を示す編集手続データを生成する
    ステップと、 前記編集手続データを生成するステップで生成された前
    記所望のファイルの所望のバージョンに対する編集手続
    データを、所望のファイルの最新バージョンに対する編
    集手続データに変換するステップと、 各クライアント装置により前記所望のファイルになされ
    た編集の結果を示す履歴管理情報を、前記変更するステ
    ップで得られた前記所望のファイルの最新バージョンに
    対する編集手続データに基づいて生成するステップと、 前記ファイル管理サーバ装置が前記履歴管理情報と前記
    各ブロックデータのブロック識別情報とに基づいて前記
    所望のファイルを管理するステップと、 とから成ることを特徴とする共有ファイル編集方法。