文書管理システム、文書処理クライアント装置、文書管理サーバ装置及びプログラム
【課題】文書の派生関係を、電子文書と紙文書で統一的に管理する。
【解決手段】電子文書３００が新規登録された場合、電子文書３００のハッシュ値ｈ（Ａ０）をbody要素とするメタ情報３１０が生成される。メタ情報３１０のハッシュ値ｈ（α０）が、電子文書３００の文書識別子である。文書識別子ｈ（α０）を内容として含む参照情報ファイル３２０が、電子文書３００の代わりにシステム内を流通する。ユーザは、所定の文書処理プログラムで参照情報ファイル３２０を開くことで、電子文書３００をサーバから取得し、編集その他の操作を加えることができる。このとき、電子文書３００の印刷操作が行われた場合、文書処理プログラムは、親文書を表すbase要素に文書識別子ｈ（α０）を含んだメタ情報３４０を生成し、そのメタ情報３４０のハッシュ値を印刷結果の紙文書の文書識別子として、例えばバーコードなどの形でその紙文書に印刷する。
【解決手段】電子文書３００が新規登録された場合、電子文書３００のハッシュ値ｈ（Ａ０）をbody要素とするメタ情報３１０が生成される。メタ情報３１０のハッシュ値ｈ（α０）が、電子文書３００の文書識別子である。文書識別子ｈ（α０）を内容として含む参照情報ファイル３２０が、電子文書３００の代わりにシステム内を流通する。ユーザは、所定の文書処理プログラムで参照情報ファイル３２０を開くことで、電子文書３００をサーバから取得し、編集その他の操作を加えることができる。このとき、電子文書３００の印刷操作が行われた場合、文書処理プログラムは、親文書を表すbase要素に文書識別子ｈ（α０）を含んだメタ情報３４０を生成し、そのメタ情報３４０のハッシュ値を印刷結果の紙文書の文書識別子として、例えばバーコードなどの形でその紙文書に印刷する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書管理システム、文書処理クライアント装置、文書管理サーバ装置及びプログラムに関する。
【背景技術】
【０００２】
文書管理の分野では、流通している文書のトレーサビリティ（追跡性）が問題となっている。電子文書、すなわちコンピュータソフトウエアにより作成された文書データを管理するシステムでは、電子文書を誰がダウンロードしたかや、誰から誰に電子文書が提供されたかなどといった電子文書の流通経路に関する情報を求める機能を持つものも存在する。
【０００３】
【特許文献１】特開平１１−２４９７７７号公報
【特許文献２】特開平１１−２５９４５９号公報
【特許文献３】特開２００４−０７２３４３号公報
【特許文献４】特開２００４−１０２６２７号公報
【特許文献５】特開２００５−０３５０９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、電子文書を紙などの物理的な媒体に印刷した場合、又は紙文書などの物理的な媒体に印刷された文書を読み取って電子文書を生成した場合などにおいて、文書間の親子関係（派生関係）を追跡するには、従来のシステムは必ずしも十分とはいえなかった。
【課題を解決するための手段】
【０００５】
請求項１に係る発明は、電子文書と、当該電子文書の内容のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、管理識別子を指定した取得指示に基づいて、当該管理識別子に対応する管理情報を前記管理情報記憶部から取得し、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書記憶部から取得する取得部と、前記取得部が取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を、当該管理情報のハッシュ値である当該媒体文書の管理識別子と対応づけて前記管理情報記憶部に登録すると共に、当該媒体文書の管理識別子を当該媒体文書に対して書き込む印刷管理部と、を備える文書管理システムである。
【０００６】
請求項２に係る発明は、請求項１に係る文書管理システムにおいて、前記取得部が取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書を、当該第２の電子文書の内容識別子と対応づけて前記文書記憶部に登録すると共に、当該第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を、当該管理情報のハッシュ値である当該第２の電子文書の管理識別子と対応づけて前記管理情報記憶部に登録する登録部、を更に備えることを特徴とする。
【０００７】
請求項３に係る発明は、請求項１に係る文書管理システムにおいて、前記印刷管理部は、前記媒体へ印刷される画像を表す印刷画像データを、当該印刷画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、ことを特徴とする。
【０００８】
請求項４に係る発明は、請求項１に係る文書管理システムにおいて、媒体文書に対する読取操作の実行に応じて、当該媒体文書に書き込まれた管理識別子を認識し、当該読取の結果得られる電子文書の管理情報として、前記媒体文書の管理識別子を含む管理情報を生成し、当該電子文書を当該電子文書のハッシュ値である内容識別子と対応づけて前記文書記憶部に登録すると共に、当該管理情報を当該管理情報のハッシュ値である管理識別子と対応づけて前記管理情報記憶部に登録する読取管理部、を更に備える。
【０００９】
請求項５に係る発明は、請求項１に係る文書管理システムにおいて、第１の媒体文書に対する複製操作の実行に応じて、当該第１の媒体文書に書き込まれた管理識別子を認識し、当該複製の結果得られる第２の媒体文書の管理情報として、前記第１の媒体文書の管理識別子を含む管理情報を生成し、当該管理情報を当該管理情報のハッシュ値である第２の管理識別子と対応づけて前記管理情報記憶部に登録すると共に、当該第２の管理識別子を前記第２の媒体文書に対して書き込む複製管理部、を更に備える。
【００１０】
請求項６に係る発明は、請求項５に係る文書管理システムにおいて、前記複製管理部は、前記第１の媒体文書の読取により得られた画像データを、当該画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記第２の媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する。
【００１１】
請求項７に係る発明は、請求項１に係る文書管理システムにおいて、媒体文書に対する廃棄操作の実行に応じて、当該媒体文書に書き込まれた管理識別子を認識し、当該媒体文書の廃棄を示す管理情報として、前記媒体文書の管理識別子を含む管理情報を生成し、当該管理情報を当該管理情報のハッシュ値である管理識別子と対応づけて前記管理情報記憶部に登録する廃棄管理部、を更に備える。
【００１２】
請求項８に係る発明は、請求項７に係る文書管理システムにおいて、前記廃棄管理部は、前記媒体文書の読取により得られた画像データを、当該画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、ことを特徴とする。
【００１３】
請求項９に係る発明は、管理識別子を指定した取得指示に応じて、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶した管理情報記憶部から、当該操作指示にて指定された管理識別子に対応する管理情報を取得するステップと、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を、電子文書と、当該電子文書のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶した文書記憶部から取得するステップと、取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を、当該管理情報のハッシュ値である当該媒体文書の管理識別子と対応づけて前記管理情報記憶部に登録するステップと、当該媒体文書の管理識別子を当該媒体文書に対して書き込むステップと、をコンピュータに実行させるためのプログラムである。
【００１４】
請求項１０に係る発明は、請求項９に係る発明において、取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書を、当該第２の電子文書の内容識別子と対応づけて前記文書記憶部に登録するステップと、当該第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を、当該管理情報のハッシュ値である当該第２の電子文書の管理識別子と対応づけて前記管理情報記憶部に登録するステップと、を更にコンピュータに実行させることを特徴とする。
【００１５】
請求項１１に係る発明は、電子文書と、当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、を備えた文書管理サーバシステムと通信し、利用者に対して文書処理機能を提供する文書処理クライアント装置であって、管理識別子を指定した取得指示に応じて、当該管理識別子に対応する管理情報を前記文書管理サーバから取得し、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書管理サーバから取得する取得部と、前記取得部が取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を生成し、当該媒体文書の管理識別子として当該管理情報のハッシュ値を計算し、計算された管理識別子と当該媒体文書の管理情報とを対応づけて前記文書管理サーバに登録すると共に、当該媒体文書の管理識別子を当該媒体文書に対して書き込む印刷管理部と、を備える文書処理クライアント装置である。
【００１６】
請求項１２に係る発明は、前記請求項１１に係る発明において、前記取得部が取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書についての内容識別子として当該第２の電子文書のハッシュ値を計算し、計算された内容識別子と当該第２の電子文書とを対応づけて前記文書管理サーバに登録する内容登録部と、前記第２の電子文書の管理情報として、前記第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を生成し、当該第２の電子文書の管理識別子として当該管理情報のハッシュ値を計算し、計算された管理識別子と当該第２の電子文書の管理情報とを対応づけて前記文書管理サーバに登録する管理情報登録部と、を更に備える。
【００１７】
請求項１３に係る発明は、電子文書と、当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、を備えた文書管理サーバシステムと通信し、利用者に対して文書処理機能を提供する文書処理クライアント装置、としてコンピュータを機能させるためのプログラムであって、管理識別子を指定した取得指示に応じて、当該管理識別子に対応する管理情報を前記文書管理サーバから取得するステップと、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書管理サーバから取得するステップと、取得された前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を生成するステップと、当該媒体文書の管理識別子として当該管理情報のハッシュ値を計算するステップと、計算された管理識別子と当該媒体文書の管理情報とを対応づけて前記文書管理サーバに登録するステップと、当該媒体文書の管理識別子を当該媒体文書に対して書き込むステップと、を前記コンピュータに実行させるためのプログラム。
【００１８】
請求項１４に係る発明は、請求項１３に係る発明において、取得された前記第１の電子文書に対する操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書についての内容識別子として当該第２の電子文書のハッシュ値を計算するステップと、計算された内容識別子と当該第２の電子文書とを対応づけて前記文書管理サーバに登録するステップと、前記第２の電子文書の管理情報として、前記第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を生成するステップと、当該第２の電子文書の管理識別子として当該管理情報のハッシュ値を計算するステップと、計算された管理識別子と当該第２の電子文書の管理情報とを対応づけて前記文書管理サーバに登録するステップと、を更に前記コンピュータに実行させることを特徴とする。
【００１９】
請求項１５に係る発明は、電子文書と、当該電子文書の内容のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、文書処理クライアント装置から管理識別子を提示した解決要求を受けた場合に当該管理識別子に対応する管理情報を前記管理情報記憶部から前記文書処理クライアント装置に提供し、前記文書処理クライアント装置から内容識別子を提示した解決要求を受けた場合に当該内容識別子に対応する電子文書を前記文書処理クライアント装置に提供する識別子解決部と、前記文書処理クライアント装置から、媒体文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納する媒体情報格納処理部と、を備える文書管理サーバ装置である。
【００２０】
請求項１６に係る発明は、請求項１５に係る発明において、前記文書処理クライアント装置から、電子文書と内容識別子とを含む登録要求を受けた場合に、当該電子文書を当該内容識別子に対応づけて前記文書記憶部に格納する内容格納処理部と、前記文書処理クライアント装置から、電子文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納する管理情報格納処理部と、を更に備える。
【００２１】
請求項１７に係る発明は、請求項１６に係る文書管理サーバ装置において、通知先の第２の文書管理サーバ装置の識別子のリストを記憶したリスト記憶部と、文書処理クライアント装置から電子文書と内容識別子とを含む登録要求を受けた場合に、当該内容識別子と当該文書管理サーバ装置自身の識別子とを含む登録要求を、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に送信し、前記文書処理クライアント装置から管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理識別子と当該文書管理サーバ装置自身の識別子とを含む登録要求を、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に送信する送信部と、第３の文書管理サーバ装置から内容識別子と当該第３の文書管理サーバ装置の識別子とを含む登録要求を受けた場合、前記内容識別子と当該第３の文書管理サーバ装置の識別子とを前記文書記憶部に登録すると共に、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に当該登録要求を転送する第１登録処理部と、前記第３の文書管理サーバ装置から管理識別子と当該第３の文書管理サーバ装置の識別子とを含む登録要求を受けた場合、前記管理識別子と当該第３の文書管理サーバ装置の識別子とを前記管理情報記憶部に登録すると共に、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に当該登録要求を転送する第２登録処理部と、内容識別子を提示した解決要求を受けた場合に、前記文書記憶部に当該内容識別子に対応づけて記憶されている情報が文書管理サーバ装置の識別子であれば、当該識別子に対応する文書管理サーバ装置から当該内容識別子に対応する電子文書を取得し、取得された電子文書を前記解決要求の発行元の装置に返す第１解決処理部と、管理識別子を提示した解決要求を受けた場合に、前記管理情報記憶部に当該管理識別子に対応づけて記憶されている情報が文書管理サーバ装置の識別子であれば、当該識別子に対応する文書管理サーバ装置から当該管理識別子に対応する管理情報を取得し、取得された管理情報を前記解決要求の発行元の装置に返す第１解決処理部と、を更に備える。
【００２２】
請求項１８に係る発明は、文書処理クライアント装置から管理識別子を提示した解決要求を受けた場合に、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部から、当該管理識別子に対応する管理情報を取得し、前記文書処理クライアント装置に提供するステップと、前記文書処理クライアント装置から内容識別子を提示した解決要求を受けた場合に、電子文書と、当該電子文書のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部から、当該内容識別子に対応する電子文書を取得し、前記文書処理クライアント装置に提供するステップと、前記文書処理クライアント装置から、媒体文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納するステップと、をコンピュータに実行させるためのプログラム、である。
【００２３】
請求項１９に係る発明は、請求項１８に係る発明において、前記文書処理クライアント装置から、電子文書と内容識別子とを含む登録要求を受けた場合に、当該電子文書を当該内容識別子に対応づけて前記文書記憶部に格納するステップと、前記文書処理クライアント装置から、電子文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納するステップと、を更にコンピュータに実行させる。
【発明の効果】
【００２４】
本発明によれば、紙などの物理的な媒体に印刷された媒体文書について、電子文書との間の親子関係（派生関係）を管理することができる。
【発明を実施するための最良の形態】
【００２５】
図１は、文書管理システムの構成の一例を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０（以下サーバ１０と略称する）とクライアント装置（以下「クライアント」と略称する）２０−１，２０−２，・・・から構成される。クライアント装置２０−１，２０−２，・・・は、相互に区別する必要のない場合には、クライアント２０と総称する。
【００２６】
サーバ１０は、本システム内で流通する文書を管理する装置である。サーバ１０は、電子文書と紙文書の両方を管理する。電子文書は、アプリケーションプログラムが作成した電子的な文書ファイルである。紙文書は、電子文書の内容を紙などの物理的な媒体に印刷したものである。物理的な媒体は、その表面上に画像を保持することができるものであれば、紙に限らずどのようなものでもよい。なお、この明細書では、分かりやすさのために、物理的な媒体上に画像が形成されることで生成された文書を、紙文書と総称する。サーバ１０は、例えば図２に示すように、文書管理ＤＢ（データベース）１１０（記憶Ｔとも呼ぶ）、派生関係ＤＢ１２０（記憶Ｕとも呼ぶ）、クライアントＩＦ（インターフェイス）部１３０及び派生関係表示生成部１４０を備える。
【００２７】
文書管理ＤＢ１１０には、電子文書が、その電子文書のハッシュ値と対応づけて登録される。また文書管理ＤＢ１１０には、電子文書又は紙文書についてのメタ情報が、当該メタ情報のハッシュ値と対応づけて登録される。文書のメタ情報は、当該文書を管理するための各種の情報を含む。ハッシュ値は、文書管理ＤＢ１１０において電子文書又はメタ情報の検索キーとして機能する。SHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などの耐衝突性を持つ暗号学的ハッシュ関数を用いれば、電子文書又はメタ情報から実用上一意とみなし得るハッシュ値を生成することができる。
【００２８】
図３に、文書管理ＤＢ１１０が持つデータ内容の一例を示す。例示したように、例えば電子文書Ａはその電子文書Ａの内容に対してハッシュ関数ｈを適用して得られるハッシュ値ｈ（Ａ）をキーとして、電子文書Ａについてのメタ情報αは当該メタ情報αのハッシュ値ｈ（α）をキーとして、それぞれ文書管理ＤＢ１１０に登録される。
【００２９】
本実施形態では、文書のメタ情報のハッシュ値を、当該文書の識別子（文書識別子と呼ぶ）として用いる。すなわち、本実施形態では、文書の内容が同一であっても、文書が生成された時の環境（例えば操作の種別や、操作を指示したユーザなど）が異なれば、メタ情報が異なってくるので、文書識別子も異なった値となる。
【００３０】
ここで、文書のメタ情報について更に詳しく説明する。以下に、電子文書のメタ情報の一例を示す。この例は、メタ情報をＸＭＬ(eXtensible Markup Language)文書として記述した場合の例である。
【００３１】
［電子文書のメタ情報の例］
<doc>
<base>"base"</base>
<body>"body"</body>
<info>
<user> "user" </user>
<time> "time" </time>
<method> "method" </method>
<content-type> "content-type" </content-type>
</info>
</doc>
【００３２】
例示したメタ情報docは、base要素、body要素、及びinfo要素を含む。またinfo要素は、user要素、time要素、method要素、及びcontent-type要素を含む。
【００３３】
ここで、body要素は、当該電子文書のハッシュ値である（例えば、１６進符号化すればよい）。base要素は、当該電子文書の親の文書の文書識別子である。例えばある電子文書Ａに対し編集操作が施され、その結果として電子文書Ｂが生成された場合、電子文書Ｂのメタ情報のbase要素には、電子文書Ａの文書識別子の値が記載される。なお、文書管理サーバ１０に対して文書を新規に登録する場合には、親の文書が存在しないので、この場合にはbase要素は空となる。
【００３４】
method要素は、親の文書に対して適用された操作の種類を示す。method要素の値の具体例としては、read（閲覧された）,edited（編集された）,printed（印刷された）,copied（複写された）,scanned（読み取られた）,shredded（シュレッダーで細断された）等がある。user要素は当該操作の実行を命じたユーザの識別情報である。time要素は、当該操作の実行が命じられた時刻である。content-type要素は当該電子文書のコンテント型を示す。コンテント型は、例えばＰＤＦ(Portable Document File)など、当該電子文書を取り扱うアプリケーションを特定する情報である。
【００３５】
上述の例は、文書識別子"base"の文書Ａに対してユーザ"user"が時刻"time"において操作"method"を施したときに結果として得られる電子文書Ｂのハッシュ値が"body"で、その電子文書のコンテント型が"content-type"である場合に生成される、電子文書Ｂのメタ情報である。このメタ情報のハッシュ値が、電子文書Ｂの文書識別子となる。
【００３６】
以上、電子文書のメタ情報について説明した。次に紙文書のメタ情報について説明する。例えば電子文書の印刷や紙文書の複写のように、紙文書が出力される操作が行われたときに、その出力された紙文書に対応するメタ情報は、例えば以下のようなものとなる。
【００３７】
［紙文書のメタ情報の例］
<doc>
<base> "base" </base>
<body> "body" </body>
<media> "uri" </media>
<info>
<user> "user" </user>
<time> "time" </time>
<method> "method" </method>
<content-type> "content-type" </content-type>
<filename> "filename" </filename>
</info>
</doc>
【００３８】
この例において、上に例示した電子文書のメタ情報の要素と同名の要素は、同じ役割の要素である。紙文書ならではの要素としてmedia要素及びfilename要素がある。
【００３９】
media要素は、当該紙文書の媒体の識別子（媒体識別子と呼ぶ）である。
【００４０】
紙文書のメタ情報の場合、操作の結果が紙文書であり、操作の結果となる電子文書は存在しないので、body要素は空としてもよい。また、この代わりに、物理的な媒体に印刷される画像を表すデータ（例えばビットマップデータやページ記述言語データなど）を仮の操作結果とし、そのデータのハッシュ値をbody要素の値としてもよい。媒体識別子は、例えば、
［媒体識別子の例］
"urn:paper:efe3958b4b9da96eea9f4091e4c14ed46c14f620ca947dfa2d4169987556f657"
の様に指定できる。この例は、媒体識別子をURN(Uniform Resource Name)で表した例であり、"urn:"の後に続く"paper"は紙文書の名前空間を表す名前空間識別子である。"urn:paper:"の後から当該識別子の末尾までの文字列は、名前空間固有文字列NSS(Namespace Specific String)であり、紙文書の名前空間の中で、当該紙文書が印刷された媒体を一意に特定する文字列である。このURNにおけるNSSは何らかのメタ情報に対応するコンテクスト（すなわちメタ情報のハッシュ値）であってもよい。例えば、ある紙媒体が以下のようなＸＭＬ記述により一意に特定されるとする。
【００４１】
［紙媒体を一意に特定する記述の例］
<paper>
<company>Fuji Xerox Co., Ltd.</company>
<division>FXPAL Japan Corporate Research Group</division>
<serialnumber>829536</serialnumber>
...
</paper>
【００４２】
この記述例は、company要素で表される会社の中の、division要素で表される部署において、serialnumber要素で表される通し番号と、その他の情報により特定される紙媒体を表している。このような紙媒体を特定するＸＭＬ記述のハッシュ値を、その紙媒体を表す媒体識別子のNSSとして用いてもよい。
【００４３】
このような紙媒体を一意に記述する情報は、紙媒体のメタ情報として扱うことができる。このメタ情報が蓄積されたサーバにアクセスできる環境（例えばcompany要素で指定された会社の社内）では当該紙文書の出自を詳しく知ることができるが、NSSを"resolve"（この処理については後で説明する）できない環境（例えば当該会社の外）ではNSSは単なる識別子に過ぎなくなり、識別子の指す情報は隠蔽される。例えば、当該媒体識別子を持った紙に印刷された紙文書を参考資料として社外の取引先に提供したものとする。その後、その取引先を買収して社内の一部門になり、社内のサーバにアクセスできるような環境に変化した場合、いまや当該会社の社員となったかつての取引先ユーザもNSSの指すメタ情報を利用できるようになる。
【００４４】
媒体識別子は、例えば媒体に対してバーコード等のコード画像として印刷してもよい。コード画像の印刷は、紫外線又は赤外線により読み取れる不可視のインク又はトナーにより印刷してもよい。また、媒体識別子は、媒体に装着されているＲＦＩＤ(Radio Frequency IDentifier)タグに書き込んでもよい。媒体識別子は、印刷前の媒体に対して予め印刷又は書き込まれていてもよいし、プリンタがその媒体に画像を印刷する際に併せて印刷してもよい。また、紙媒体の場合、上述のように媒体識別子を用紙に書き込む代わりに、個々の用紙に固有の微細な繊維構造又は微細な表面構造を表す紙指紋を読み取り、紙指紋を媒体識別子として用いてもよい。
【００４５】
なおmedia要素は、媒体識別子が得られる場合に記入すればよく、得られない場合は空でも構わない。
【００４６】
メタ情報中のfilename要素は、当該紙文書の親である電子文書のファイル名を表す要素である。例えば、電子文書を印刷する場合など、電子文書に対する操作の結果として紙文書が出力される場合に、その電子文書のファイル名をfilename要素として記録するのである。filename要素に記録するファイル名は、拡張子付きでも、拡張子を除去したものでもよい。このように、紙文書の元になった電子文書のファイル名を記録しておけば、当該紙文書を再度電子化した際にその名前が利用できるので便利な場合もある。例えば、電子文書を印刷して得られた紙文書をスキャンした場合に、スキャン結果のファイルに対し、元の電子文書の識別名に由来する名前をつけることができる。
【００４７】
以上では、文書のメタ情報について例示したが、電子文書の集まり（コレクション）を表現するフォルダ（或いはディレクトリ）についても、同様にメタ情報を定義することができる。フォルダのメタ情報は、フォルダの内容を記述した以下に例示するようなフォルダ内容記述（すなわちfolder要素）の値のハッシュ値をbody要素の値として持つ。
【００４８】
［フォルダ内容記述の例］
<folder>
<file
name="fe04-05515.pdf.yui"
created="2006/03/10 20:17:16"
modified="2006/03/10 19:55:03"
accessed="2006/03/10 20:19:53"
did="a4cf754a7efdd53825b5a108949ebd764fc3ff7bf6c3c7c25653bf824286d38a"
size="628260" />
<file
name="fe02-02232.pdf.yui"
created="2006/03/10 20:17:13"
modified="2006/03/10 20:02:00"
accessed="2006/03/10 20:19:46"
did="9ff47dc0ca7b68755735b4f415be11a380b2e1da1f9a61847dd0b524cd22ec8a"
size="156380"/>
</folder>
【００４９】
この記述例は、"fe04-05515.pdf "と"fe04-02232.pdf "という２つの電子文書を含むフォルダを表す。folder要素は、０以上のfile要素を含む。file要素は、フォルダ中の１つの電子文書に関する管理情報を表す。file要素におけるname要素は、当該電子文書に対応する参照情報ファイルのファイル名を示す。参照情報ファイルは、当該電子文書の文書識別子を内容として持つファイルであり、本システムでは電子文書そのものの代わりにシステム内を流通する。created要素、modified要素、accessed要素は、それぞれ当該電子文書の作成時刻、最新の更新時刻、及び最新のアクセス時刻を表す要素である。これら各時刻要素は、通常のファイルシステムがファイル管理において記録している情報と同様でよい。did要素は当該電子文書の文書識別子を表し、size要素は当該電子文書のデータサイズを表す。
【００５０】
フォルダのメタ情報のハッシュ値は、フォルダの識別子として用いられる。このフォルダ識別子を内容として持つファイルを、フォルダに対応する参照情報ファイルとして用いることができる。フォルダに対応する参照情報ファイルを持つユーザは、その参照情報ファイルを用いてサーバ１０にアクセスすることにより、上述のフォルダ内容記述を取得することができる。またユーザは、そのフォルダ内容記述に含まれる電子文書の文書識別子didを用いてサーバ１０にアクセスすることにより、当該電子文書の実体にアクセスすることができる。
【００５１】
例えば、上に例示したフォルダが含む二つの文書がある組織における非常に機密性の高い実在の文書であり、文書管理システムは組織の成員にしか利用できないように制限されているとする。この場合、組織の成員は、上記の文書識別子didを用いることでサーバ１０上の実在の文書にアクセスすることができるが、組織外のユーザはその文書識別子didが仮に分かったとしても、その文書についての情報を全く引き出すことができない。
【００５２】
上記の例ではフォルダを扱ったが、より一般に、複合要素から構成される任意のコンパウンドドキュメントも同様に扱うことができる。例えば、単純なケースでは、ＸＭＬ文書は木構造を持ち、各部分木自体もＸＭＬ文書と捉えることができるので、ＸＭＬ文書はコンパウンドドキュメントの一例である。この場合、DomHash（RFC2803で規定されている）を用いることにより、ＸＭＬ文書の木構造の部分木ごとに対して、それぞれ文書識別子を付与することもできる。
【００５３】
ＸＭＬ文書は可搬性を備えた文書フォーマットとして主流になりつつあるが、データ表現形式としては冗長なため、必要なデータ容量の増大を招いている。このようにＸＭＬ文書のDomHash値をそのＸＭＬ文書自体の識別子とすることによって、重複する要素を重複して保存することなく、また、データ交換の際に必要な部分木のみを交換することによって処理を効率化することもできる。またDomHash自体にＸＭＬ文書の木構造情報がそのまま保存されている為、従来のＸＭＬ文書処理では頻繁に行われていたＸＭＬ文書とＤＯＭ(Document Object Model)木との変換がある意味で不要となり、より処理が効率化される。
【００５４】
以上、文書管理ＤＢ１１０と、それに関連して文書及びフォルダのメタ情報について説明した。以上の例では、電子文書と、電子文書のメタ情報とが、共に文書管理ＤＢ１１０に登録されたが、電子文書とメタ情報とを別々のデータベースに登録してもよい。
【００５５】
再び図２に戻り、派生関係ＤＢ１２０について説明する。
【００５６】
派生関係ＤＢ１２０は、文書管理ＤＢ１１０に登録された文書間の派生関係を記録するデータベースである。文書管理ＤＢ１１０に登録された電子文書Ａに対し、操作が行われた結果電子文書Ｂが生成された場合、「電子文書Ａから電子文書Ｂが派生した」という。この場合電子文書Ａは電子文書Ｂの親である。このような電子文書間の親子関係のことを、ここでは派生関係と呼ぶ。派生関係は、親の電子文書の文書識別子と、子の電子文書の文書識別子のペアで表現することができる。
【００５７】
派生関係ＤＢ１２０が持つデータ内容の例を図４に示す。この例では、派生関係ＤＢ１２０には、電子文書毎に、その電子文書の文書識別子（キー）に対応づけて、その電子文書から派生した子文書の文書識別子のリストが登録されている。前述したように、電子文書Ａの文書識別子は、当該電子文書Ａのメタ情報αのハッシュ値ｈ（α）である。なお、電子文書のメタ情報にはその電子文書の親の文書識別子がbase要素として含まれるので、メタ情報を蓄積した文書管理ＤＢ１１０だけあれば、原理的には電子文書間の派生関係を求めることができる。ただ、本実施形態では処理の効率等の観点から、親から子への派生関係のみを抽出してまとめた派生関係ＤＢ１２０を構築している。
【００５８】
ここで、本実施形態における電子文書、メタ情報、及び参照情報ファイルの関係を概括しておく。図５に示すように、電子文書３００が文書管理サーバ１０に新規登録された場合、その電子文書３００の内容Ａ０のハッシュ値ｈ（Ａ０）をbody要素とするメタ情報３１０が生成される。新規登録された文書の場合、base要素は空である。このメタ情報３１０の内容がα０であるとすると、電子文書３００に対応する文書識別子はｈ（α０）である。この文書識別子ｈ（α０）を内容として含む参照情報ファイル３２０が、電子文書３００の代わりにシステム内を流通する。参照情報ファイル３２０を入手したユーザは、クライアント２０が備える所定の文書処理プログラムでその参照情報ファイル３２０を開くことで、電子文書３００の内容をサーバ１０から取得し、編集その他の操作を加えることができる。この操作の結果、電子文書の内容がＡ０からＡ１へと変わったとする。その操作の後、内容Ａ１を持つ電子文書３３０がクライアント２０の文書処理プログラムからサーバ１０に登録される。このとき、電子文書３３０のメタ情報３４０もサーバ１０に登録される。メタ情報３４０は、親文書を表すbase要素として電子文書３００の文書識別子ｈ（α０）を有し、文書実体を示すbody要素として電子文書３３０のハッシュ値ｈ（Ａ１）を含む。このメタ情報３４０の内容α１のハッシュ値ｈ（α１）が、電子文書３３０の文書識別子となり、電子文書３３０に対応する参照情報ファイル３５０に含まれることとなる。
【００５９】
以上に説明した文書管理ＤＢ１１０（記憶Ｔ）と派生関係ＤＢ１２０（記憶Ｕ）の関係は、例えば以下のように説明される。暗号学的ハッシュ関数ｈを選択する。以下、自由長のオクテット列をデータ、ｈのハッシュ値長のオクテット列をコンテクストと呼ぶ。データｘに対してコンテクストξがｈ（ｘ）=ξのとき、コンテクストξはデータｘに対応していると言う。データ全体の集合をＤ、コンテクスト全体の集合をＣと書くこととする。サーバ１０は記憶Ｔ及び記憶Ｕを持つ。記憶Ｔはコンテクストをキーとし、そのキーに対応する値としてデータを持つ。記憶Ｕはコンテクストをキーとし、そのキーに対応する値としてコンテクストの集合を持つ。ここで、Ｔ[ξ]=ｘ（すなわちＴにおけるキーξに対応する値がｘである）、Ｕ[ξ]=Ｙ（すなわちＵにおけるキーξに対応する値が集合Ｙである）とする。この場合、ｈ（ｘ）=ξであり、集合Ｙの任意の要素ηに対して、ηはＴのキーとして存在し、Ｔ[η]はbase要素を含むメタ情報であって、base要素の内容としてξ（例えばその１６進表現）を含む。つまりＹはξの‘子’の集合である。
【００６０】
以上の説明では、Ｔ[η]の要素をＸＭＬ文書であるメタ情報としているが、ＸＭＬ文書の代わりにメタ情報のＸＭＬ文書に対応するDomHash値とすることも可能である。ＸＭＬ文書の場合にはコンテクストの１６進表現を用いたが、DomHash値を用いる場合にはコンテクストそのものを利用することができる。記憶Ｔ及び記憶Ｕは、ＬをＤのある有限部分集合（つまりオクテット上の有限言語）として、写像Ｔ：ｈ（Ｌ）→Ｌ，Ｕ：ｈ（Ｌ）→２Ｃと見なせる（つまりＬが十分小さい（例えばSHA-256では基数が高々２１２８ 程度）場合、Ｌの上ではｈは単射と見なせるから。ここで２ＣはＣの部分集合全体の集合を表す）。この事実に基づいてｈ（ｘ）をデータｘのコンテクストと呼ぶ。記憶ＴおよびＵの具体的な実装はハッシュテーブルとして与えられるので検索に要する時間計算量はＯ（１）である。また、ストレージに同一データの冗長な保存が決して発生しないというメリットもある。また、サーバ１０をネットワーク上の分散サーバとして実現した場合においても、例えば、Chordのような分散ハッシュテーブルに基づいた場合、検索に要する時間計算量はＯ（ｌｏｇ ｎ）であり（ｎはノード数）、ネットワークのメンテナンスコスト（ルーティングテーブルの更新）もＯ（ｌｏｇ２ ｎ）であり非常に効率的であるためスケーラビリティがある。（サーバ１０を分散サーバとして構成した場合については、後で更に説明する。）
【００６１】
以上、サーバ１０の文書管理ＤＢ１１０及び派生関係ＤＢ１２０について説明した。再び図２の説明に戻ると、サーバ１０は、クライアント２０との間での相互作用のための処理を行うクライアントＩＦ部１３０を備える。クライアントＩＦ部１３０は、後述するクライアント装置２０のサーバＩＦ部２１８との間で通信し、後述する"bind"，"resolve"，"exist? "，"delete"等の基本処理を実行する。これら各基本処理の内容については、後で詳しく説明する。
【００６２】
またサーバ１０は、派生関係生成部１４０を備える。派生関係生成部１４０は、電子文書同士の派生関係の木構造を示した派生関係表示情報を生成する。派生関係生成部１４０の処理は、後で詳しく説明する。
【００６３】
以上、サーバ１０の構成の例について説明した。次に、クライアント２０の構成の例について、図６を参照して説明する。
【００６４】
図６に示すように、クライアント２０は情報処理部２００を備え、情報処理部２００は文書処理部２１０，１以上のアプリケーション２３０及びファイルシステム２４０を備える。情報処理部２００は、オペレーティングシステムにより制御されるコンピュータである。文書処理部２１０は、上述した参照情報ファイルを用いた文書の取り扱い管理を行うための処理ユニットであり、上述した「文書処理プログラム」に該当する。情報処理部２００については、後で詳しく説明する。アプリケーション２３０は、電子文書の生成又は編集、電子的な複写、印刷指示など電子文書についての処理を実行する。プリンタ２５０を制御するプリンタドライバ、又はスキャナ２６０を制御するスキャナドライバなどのドライバプログラムを、アプリケーション２３０の一種とみなしてもよい。ファイルシステム２４０は、情報処理部２００のオペレーティングシステムの一要素であり、ファイル群を管理する。アプリケーション２３０及びファイルシステム２４０は、本実施形態の方式に直接関係するものではなく、従来からあるものでよい。
【００６５】
クライアント２０は、プリンタ２５０、スキャナ２６０及びスキャナ付きシュレッダ２７０のうちの１以上を備えていてもよい。プリンタ２５０及びスキャナ２６０は従来から存在するものでよい。スキャナ付きシュレッダ２７０は、紙文書から文書識別子コードを読み取るためのスキャナを備える。スキャナ付きシュレッダ２７０については、後で詳しく説明する。
【００６６】
本実施形態のクライアント２０は、様々な態様の装置であり得る。例えば、クライアント２０は、プリンタ２５０、スキャナ２６０及びスキャナ付きシュレッダ２７０のいずれも持たない情報処理部２００のみを備えるものであってもよい。例えばクライアント２０がパーソナルコンピュータである場合が、その一例である。また、クライアント２０がいわゆるデジタル複合機である場合、クライアント２０は情報処理部２００とプリンタ２５０とスキャナ２６０を備える。また、クライアント２０がシュレッダ装置である場合、クライアント２０は情報処理部２００とスキャナ付きシュレッダ２７０を備える。なお、クライアント２０は、プリンタ２５０、スキャナ２６０及びスキャナ付きシュレッダ２７０以外にも、紙文書を取り扱う装置を備えていてもよい。
【００６７】
次に、文書処理部２１０について説明する。文書処理部２１０は、ＵＩ（ユーザインターフェイス）部２１２，メタ情報生成部２１４，ハッシュ計算部２１６，サーバＩＦ部２１８，参照情報生成部２２０，操作管理部２２２，紙文書管理部２２４，アクセス禁止処理部２２６，派生関係表示処理部２２８を備える。
【００６８】
ＵＩ部２１２は、文書処理部２１０に対する操作指示のためのＵＩ画面を生成し、クライアント２０のオペレーティングシステムを介して画面に表示する。ＵＩ部２１２が提供するＵＩ画面には、例えば、参照情報ファイルの生成や、参照情報ファイルについてのアクセス禁止処理、派生関係表示処理などといった、参照情報ファイルに関係する処理のための操作メニューが表示される。メタ情報生成部２１４は、上述した電子文書のメタ情報を生成する。
【００６９】
メタ情報生成部２１４は、メタ情報の生成にあたり、操作を行ったユーザの識別情報や時刻、コンテント型、ファイル名などの情報をオペレーティングシステムから取得し、操作結果の電子文書のハッシュ値をハッシュ計算部２１６から取得する。親文書の文書識別子は、操作のために開かれた参照情報ファイルから取得することができる。取得した親文書の文書識別子は、base要素の値として組み込まれる。また、プリンタ２５０又はスキャナ２６０又はスキャナ付きシュレッダ２７０などが備える読取装置が、媒体に書き込まれた媒体識別子のコード画像、又は媒体に付属するＲＦＩＤタグに記憶された媒体識別子、又は媒体の紙指紋を読み取り、その結果得られた媒体識別子をメタ情報生成部２１４がメタ情報に組み込んでもよい。また、プリンタ２５０が用紙に対して媒体識別子のコード画像を印刷する場合、メタ情報生成部２１４がその媒体識別子を取得し、メタ情報に組み込んでもよい。
【００７０】
ハッシュ計算部２１６は、電子文書又はメタ情報など、対象となるデータについて、本システムで採用している所定の暗号学的ハッシュ関数を用いて、ハッシュ値を計算する。
【００７１】
サーバＩＦ部２１８は、サーバ１０のクライアントＩＦ部１３０と通信し、参照情報ファイルについての基本処理、すなわち"bind"，"resolve"，"exist?"，"delete"を実行する。
【００７２】
ここで、これら個々の基本処理の流れを説明する。まず図７を参照して"bind"処理の流れを説明する。"bind"処理は、電子文書又はそのメタ情報をクライアント２０からサーバ１０に登録する処理である。この処理は、登録対象のデータ実体ｘ（電子文書又はメタ情報）を入力とし、そのデータｘのハッシュ値（コンテクスト）ξを出力とする。
【００７３】
クライアント２０のサーバＩＦ部２１８は、データｘを対象とする"bind"処理（すなわちbind(ｘ)）の実行を指示された場合、ハッシュ計算部２１６にデータｘのハッシュ値を計算させ、その計算結果ξを受け取って、その処理の出力データとして出力する（Ｓ１）。また、サーバＩＦ部２１８は、ハッシュ値ξを対象として"exist? "処理を実行する（Ｓ２）。"exist? "処理の手順については、後で詳しく説明する。"exist? "処理の結果が得られると、サーバＩＦ部２１８は、その結果に基づき、ξが既にサーバ１０上に存在しているか否かを判定し（Ｓ３）、存在していなければ、（ξ，ｘ）（すなわちデータｘとそのハッシュ値ξのペア）を含む"bind"メッセージをサーバ１０宛に送る（Ｓ４）。存在していれば、ステップＳ４はスキップされ、"bind"処理は終了する。
【００７４】
サーバ１０のクライアントＩＦ部１３０は、その"bind"メッセージを受信し（Ｓ５）、文書管理ＤＢ１１０に対して、ハッシュ値ξをキーとしてデータｘを登録する（Ｓ６）。
【００７５】
次に、図８を参照して、"resolve"処理の流れを説明する。"resolve"処理は、ハッシュ値ξを入力とし、そのξに対応するデータ実体ｘ（電子文書又はメタ情報）を求める処理であり、その処理の出力はそのデータ実体ｘである。
【００７６】
クライアント２０のサーバＩＦ部２１８は、ハッシュ値ξを対象とする"resolve"処理の実行を指示された場合、ξを引数として含む"resolve"メッセージをサーバ１０に送信する（Ｓ１１）。サーバ１０では、クライアントＩＦ部１３０が、その"resolve"メッセージを受信し（Ｓ１２）、そのメッセージの引数ξをキーとして文書管理ＤＢ１１０を検索する（Ｓ１３）。その検索の結果、文書管理ＤＢ１１０にξをキーとするエントリが存在するか否かを判定し（Ｓ１４）、存在すれば、クライアントＩＦ部１３０は、そのξに対応するエントリ内のデータ実体ｘをクライアント２０に返す（Ｓ１５）。クライアント２０のサーバＩＦ部２１８は、サーバ１０から返されてきたデータ実体ｘを受信し、これを"resolve"処理の結果として出力する（Ｓ１６）。なお、ステップＳ１４でξが存在しないと判定された場合は、クライアントＩＦ部１３０は、問合せ対象のキーが存在しない旨を示す例外コードをクライアント２０に返す（Ｓ１７）。クライアント２０のサーバＩＦ部２１８は、その例外コードを受け取った場合には、その例外コードに応じた所定のエラー処理を実行する（Ｓ１８）。
【００７７】
次に、図９を参照して、"exist? "処理の流れを説明する。"exist? "処理は、ハッシュ値ξを入力とし、そのξに対応するデータ実体ｘ（電子文書又はメタ情報）がサーバ１０に登録済みであるかどうかを判定する処理であり、その処理の出力はその判定結果を示すブール値（「true(存在する)」又は「false(存在しない)」）である。
【００７８】
クライアント２０のサーバＩＦ部２１８は、ハッシュ値ξを対象とする"exist? "処理の実行を指示された場合、ξを引数として含む"exist? "メッセージをサーバ１０に送信する（Ｓ２１）。サーバ１０では、クライアントＩＦ部１３０が、その"exist? "メッセージを受信し（Ｓ２２）、そのメッセージの引数ξをキーとして文書管理ＤＢ１１０を検索する（Ｓ２３）。その検索の結果、文書管理ＤＢ１１０にξをキーとするエントリが存在するか否かを判定し（Ｓ２４）、存在すれば、クライアントＩＦ部１３０は、ブール値ｂの値を"true"にセットし（Ｓ２５）、存在しなければ"false"にセットする（Ｓ２６）。その後、クライアントＩＦ部１３０は、そのブール値をクライアント２０に返す（Ｓ２７）。クライアント２０のサーバＩＦ部２１８は、その返り値ｂを"exist? "処理の結果として出力する（Ｓ２８）。
【００７９】
次に、図１０を参照して、"delete"処理の流れを説明する。"delete"処理は、削除対象のデータのハッシュ値ξを入力とし、そのハッシュ値ξに対応するデータｘをサーバ１０から削除する処理である。
【００８０】
クライアント２０のサーバＩＦ部２１８は、ハッシュ値ξを対象とする"delete"処理の実行を指示された場合、ハッシュ値ξを対象として"exist? "処理を実行する（Ｓ３１）。"exist? "処理の結果として返り値ｂが得られると、サーバＩＦ部２１８は、その返り値が"true"であるか否かを判定し（Ｓ３２）、"true"（すなわち「ξがサーバ１０に存在する」）であれば、ξを引数として含む"delete"メッセージをサーバ１０宛に送る（Ｓ３３）。"true"でなければ、ステップＳ３３はスキップされ、"delete"処理は終了する。
【００８１】
サーバ１０のクライアントＩＦ部１３０は、クライアント２０から"delete"メッセージを受信すると（Ｓ３４）、文書管理ＤＢ１１０から、ハッシュ値ξをキーとするエントリを削除する（Ｓ３５）。これにより、ハッシュ値ξに対応するデータ実体ｘが文書管理ＤＢ１１０から削除される。
【００８２】
以上、サーバＩＦ部２１８の説明と併せて、各基本処理の手順を説明した。これら基本処理のうち"delete"処理がなくてもシステムは成立する。また、"exist?"処理は必ずしも必要ではない。"exist?"処理は冗長なデータ転送を発生させないという効果のためのものである。
【００８３】
次に、再び図６に戻り、参照情報生成部２２０について説明する。参照情報生成部２２０は、クライアント２０のファイルシステム２４０内の電子文書（ファイル）又はフォルダに対応する参照情報ファイルを生成する。まず、電子文書の参照情報ファイルを生成する場合の手順を、図１１を参照して説明する。
【００８４】
例えばＵＩ部２１２に対してユーザが、対象の電子文書を指定して、その電子文書についての参照情報ファイルの生成を指示した場合（Ｓ４１）、参照情報生成部２２０が起動される。ここでは、一例として、指定された対象の電子文書のファイル名が"foo.doc"であるとする。参照情報生成部２２０は、サーバＩＦ部２１８に対し、その電子文書の内容"foo.doc"を対象とする"bind"処理を依頼する（Ｓ４２）。そして、参照情報生成部２２０は、その"bind"処理の出力であるハッシュ値をbody要素の値として含むメタ情報（仮にその名前を"doc"とする）の生成を、メタ情報生成部２１４に依頼する（Ｓ４３）。そして、メタ情報生成部２１４からメタ情報"doc"を受け取ると、参照情報生成部２２０は、そのメタ情報"doc"についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ４４）。そして、参照情報生成部２２０は、その"bind"処理の出力であるハッシュ値を内容とする参照情報ファイルを生成する（Ｓ４５）。この例では、生成された参照情報ファイルに対し、元の電子文書のファイル名"foo.doc"の文字列の後に所定の拡張子（この例では".yui"）を追加したファイル名を付与している。すなわち、参照情報ファイルのファイル名の中には、元の電子文書のファイル名の情報が残る。なお、追加する拡張子".yui"はあくまで一例に過ぎない。
【００８５】
図１１の処理手順では、"bind"処理が行われるので、対象として指定された電子文書とそのメタ情報とが、サーバ１０に登録されることになる。すなわち、参照情報ファイルの生成処理は、サーバ１０に対して新規な電子文書を登録する処理と捉えることもできる。すなわち、クライアント２０にある電子文書は、この参照情報ファイルの生成処理により、本実施形態のシステムの中に組み込まれることになる。組み込まれた後は、その電子文書は、参照情報ファイルの形で各ユーザ間を流通することになる。
【００８６】
次に、図１２を参照して、フォルダに対応する参照情報ファイルの生成手順を説明する。ＵＩ部２１２に対しユーザが対象となるフォルダ（ここでは仮にそのフォルダの識別名を"bar"とする）を指定し、参照情報ファイルの生成を指示すると（Ｓ５１）、参照情報生成部２２０は、そのフォルダ"bar"内に含まれる要素（すなわち電子文書又はフォルダ）毎に、その要素に対応する参照情報ファイルの生成処理を再帰的に実行する（Ｓ５２）。要素が電子文書であれば、参照情報処理部２２０は、その電子文書を対象に図１１の手順を実行する。要素がフォルダであれば、参照情報処理部２２０は、そのフォルダを対象に、この図１２の手順を実行する。フォルダ"bar"内のすべての要素についての参照情報ファイルが生成されると、参照情報処理部２２０は、それら各参照情報ファイルの情報に基づき、フォルダ"bar"の内容を表すフォルダ内容記述（ここでは仮にその名前を"folder"とする）を生成する（Ｓ５３）。フォルダ内容記述については既に説明したが、そのうち各ファイルのname要素は、当該ファイルの参照情報ファイルのファイル名であり、did要素は当該参照情報ファイルの内容であるハッシュ値である。他の要素は、ファイルシステム２４０が管理するファイルの属性情報である。そして、参照情報生成部２２０は、そのフォルダ内容記述"folder"についての"bind"処理を、サーバＩＦ部２１８に依頼する（Ｓ５４）。そして、参照情報生成部２２０は、その"bind"処理の出力値をbody要素として含むメタ情報"doc"（これはフォルダ"bar"のメタ情報である）の生成をメタ情報生成部２１４に依頼し（Ｓ５５）、その結果得られたメタ情報"doc"についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ５６）。そして、参照情報生成部２２０は、その"bind"処理の出力値を内容として持つ参照情報ファイルを生成する（Ｓ５７）。生成された参照情報ファイルには、元のフォルダの名前"bar"の後ろに、所定の拡張子（図示例では".ber"）を付加したファイル名が付与される。拡張子".ber"はあくまで一例である。
【００８７】
以上のような処理により生成された参照情報ファイルは、ファイルシステム２４０における単なるファイルに過ぎないので、通常のファイルに対して実行可能な操作をすべて実行できる。また、例えば、電子メールに対して参照情報ファイルを添付し、送信することもできる。ファイルやフォルダがいかにサイズの大きなデータであったとしても、参照情報ファイルはハッシュ値を内容とするものなので、ファイルサイズは非常に小さい所定値である。例えばSHA-256を用いた場合、参照情報ファイルのファイルサイズは３２バイトに過ぎない。したがって、巨大なフォルダを知人に渡す場合も、電子メールの添付ファイルのデータ量を気にする必要はない。また、誤ってあるいは故意にこれらの参照情報ファイルが、本システムがカバーするドメインの外に送信されてしまったとしても、ドメイン外ではサーバ１０にアクセスできないか、またはクライアント２０が参照情報ファイルを取り扱う文書処理部２１０を持たないので、参照情報ファイルに対応するデータ実体を入手することはできない。
【００８８】
以下、参照情報ファイルに固有の操作について説明する。以下に説明する固有の操作は、操作管理部２２２の管理の下で実行される。
【００８９】
まず、図１３を参照して、アプリケーション２３０による電子文書の操作が指示された場合の手順の例を説明する。この手順では、ＵＩ部２１２に対しユーザから、対象となる電子文書の参照情報ファイル（仮にそのファイル名が"foo.doc.yui"であるとする）の操作の実行が指示されると（Ｓ６１）、操作管理部２２２は、その参照情報ファイルの内容である文書識別子did1を記憶する（Ｓ６２）。ステップＳ６１における操作の指示は、例えば、その参照情報ファイルのアイコンをダブルクリックすることにより行われる。また、操作管理部２２２は、文書識別子did1についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ６３）、その結果としてメタ情報"doc"を取得する（Ｓ６４）。操作管理部２２２は、そのメタ情報のbody要素の値についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ６５）、その結果として電子文書"foo.doc"の内容を取得する（Ｓ６６）。操作管理部２２２は、取得したファイル内容を含んだテンポラリファイルを作成し（Ｓ６７）、そのテンポラリファイルの操作をアプリケーション２３０に委譲する（Ｓ６８）。操作を委譲するアプリケーション２３０としては、電子文書の拡張子（この例では".doc"）に対応するアプリケーション２３０が選ばれる。これにより、操作を委譲されたアプリケーション２３０が、そのテンポラリファイルを開き、ユーザの操作を受け付ける。操作管理部２２２は、アプリケーション２３０がテンポラリファイルを閉じるのを待つ（Ｓ６９）。テンポラリファイルが閉じられたのを検知すると、操作管理部２２２は、その時点のテンポラリファイルの内容についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ７０）。これにより、操作後のテンポラリファイルの内容が、元の電子文書の内容から変化していれば、そのテンポラリファイルの内容がサーバ１０に登録される。そして、操作管理部２２２は、その"bind"処理の出力値ξをbody要素とし前述のdid1をbase要素として含んだメタ情報の生成をメタ情報生成部２１４に依頼し、その結果得られたメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ７１）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を、派生関係ＤＢ１２０に登録する（Ｓ７２）。ここで、生成されるメタ情報のうち、method要素の値は、例えば、閉じられたときのテンポラリファイルの内容が、元の電子文書の内容から変化していれば"edited（編集された）"であり、変化していなければ" read（閲覧された）"とすればよい。そして、操作管理部２２２は、操作対象の参照情報ファイル"foo.doc.yui"の内容をその"bind"処理の出力値に書き換え（Ｓ７３）、テンポラリファイルを削除する（Ｓ７４）。以上の処理手順によれば、参照情報ファイルに対応する電子文書は、クライアント２０のファイルシステム２４０内には残らない。
【００９０】
このような処理において、アプリケーションに操作が委譲されたテンポラリファイルは、当該アプリケーション以外のプロセスからのアクセスを拒むようにしてもよい。これは、例えば、操作管理部２２２が、オペレーティングシステムに対する各プロセスからのシステムコールを監視し、その監視によりテンポラリファイルに対して当該アプリケーション以外のプロセスからアクセスが要求されたことを検知した場合、その要求を拒絶するように制御すればよい。また、当該アプリケーションが操作の委譲されたテンポラリファイル以外のファイルの生成又は書き込みはできないように制御してもよい。このような制御のためには、例えば、当該アプリケーションからのオペレーティングシステムへのシステムコールの監視により、テンポラリファイル以外のファイルに対する操作が要求されたことを検知した場合、その要求を拒絶すればよい。
【００９１】
次に、フォルダに対する操作が指示されたときの、操作管理部２２２の処理手順を、図１４を参照して説明する。
【００９２】
この手順では、ＵＩ部２１２に対しユーザから、対象となるフォルダの参照情報ファイル（仮にそのファイル名が"bar.ber"であるとする）の操作の実行が指示されると（Ｓ８１）、その参照情報ファイルに含まれる識別子did1についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ８２）、その結果としてフォルダ"bar"のメタ情報"doc"を取得する（Ｓ８３）。操作管理部２２２は、そのメタ情報のbody要素の値についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ８４）、その結果としてフォルダ"bar"のフォルダ内容記述"folder"を取得する（Ｓ８５）。操作管理部２２２は、取得したフォルダ内容記述"folder"に基づき、フォルダ"bar"の内容を示すフォルダ画面を生成し、表示する（Ｓ８６）。フォルダ画面は、例えばフォルダ"bar"内のフォルダと電子文書のアイコンを列挙表示したものでよい。フォルダ内容記述"folder"には、フォルダ"bar"内の電子文書及びフォルダの参照情報ファイル及び識別子(did要素)の情報が含まれるので、それら電子文書及びフォルダの参照情報ファイルを示すアイコンを列挙表示したフォルダ画面を生成することができる。参照情報ファイルのアイコンには、対応する電子文書又はフォルダを表す。例えば参照上ファイルのアイコンには、対応する電子文書又はフォルダの名前を対応づけて表示することができる。
【００９３】
操作管理部２２２は、フォルダ画面に表示した参照情報ファイルに対するユーザからの操作指示を受け付け、その操作を実行する（Ｓ８７）。ここで、操作の対象としてユーザが指定した参照情報ファイルが電子文書に対応するものである場合には、操作管理部２２２は、その参照情報ファイルを対象として、図１３の処理手順を実行する。操作の対象としてユーザが指定した参照情報ファイルがフォルダに対応するものである場合には、操作管理部２２２は、その参照情報ファイルを対象として、この図１４の処理手順を再帰的に実行する。なお、図示例では、ステップＳ８７で、参照情報ファイルＸに対する操作が指示されたとする。操作管理部２２２は、参照情報ファイルＸに対する操作の終了を監視する（Ｓ８８）。その操作が終了すると、参照情報ファイルＸの値は、元の値から変化している。操作管理部２２２は、その参照情報ファイルＸの値の変化に応じて、フォルダ"bar"のフォルダ内容記述を作成する（Ｓ８９）。参照情報ファイルＸに操作が行われた場合、参照情報ファイルＸの内容である識別子didは元から変化し、また更新日や最終アクセス日の情報も変化しているので、ステップＳ８９では、それら変化を反映したフォルダ内容記述が生成される。なお、参照情報ファイルＸに対する操作が終了した時点では、フォルダ画面上の参照情報ファイルＸ以外の要素についての識別子や更新日などの情報に変化はない。操作管理部２２２は、ステップＳ８９で作成されたフォルダ内容記述についての"bind"処理をサーバＩＦ部２１８に依頼し（Ｓ９０）、その"bind"処理の出力値をbody要素として含むフォルダ"bar"のメタ情報を生成し、そのメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ９１）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ９２）。そして操作管理部２２２は、参照情報ファイル"bar.ber"の内容を、その"bind"処理の出力値へと書き換える（Ｓ９３）。
【００９４】
以上ではフォルダに対応する参照情報ファイルに対する操作について説明した。シェルの名前空間拡張を実装することで、以上の処理手順を、”C:/DocumentsandSettings/terao/MyDocuments.ber/bar/sample.txt”のようなＵＣＮ（ユニバーサル文字名）による指定に対しても割り当てることができる。この例では、”MyDocument.ber”以下はファイルシステム上のフォルダやファイルではなく、仮想的なフォルダや電子文書を示す参照情報ファイルで構成されている。
【００９５】
このように構成すれば、例えば、複雑なアプリケーションのインストールディレクトリを持ち運ぼうとした場合に、そのディレクトリの参照情報ファイルを生成することで、持ち運びが容易になる。例えば、TeXの操作環境一式のインストールディレクトは様々なアプリケーションやライブラリ、各種クラスファイルやフォントデータなどの多数のファイル・フォルダから構成され、そのデータ量は例えば数百Ｍバイトにも達する。ところが、このディレクトリの参照情報ファイルは、SHA-256を用いた場合には、例えば３２バイトのデータとなる。普段、TeXの操作環境を利用しないユーザが一時的に利用する必要が生じた場合、このインストールディレクトリのフォルダリファレンスをメールで送付してもらいそのまま利用することができる。このようにして一種のThinclientのような運用が可能になる。さらに、このようなアプリケーションの利用方法では後述するようにフォルダリファレンスの所持者にはファイルの利用履歴が入手できるのでアプリケーションの従量課金が容易に行える。
【００９６】
次に、参照情報ファイル経由で電子文書を開いた状態で、その文書を印刷するケースを考える。印刷時の処理手順の例を図１５に示す。図１５の手順は、紙文書管理部２２４により実行される。
【００９７】
図１３の手順のステップＳ６１において参照情報ファイルが開かれ、その参照情報ファイルに対応する電子文書の内容を持つテンポラリファイルに対する操作が、ステップＳ６８でアプリケーション２３０に委譲されたとする。その後、テンポラリファイルが閉じられるまで、紙文書管理部２２４は、アプリケーション２３０に対しユーザからそのテンポラリファイルの印刷の指示があるか、監視する（Ｓ１０１）。印刷指示を検知すると、紙文書管理部２２４は、図１３のステップＳ６３で記憶した識別子did1をbase要素として含むメタ情報を生成し、そのメタ情報に対する"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１０２）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１０３）。ここで、そのメタ情報のbody要素は空でよい。また、印刷指示があると、その時点のテンポラリファイルに対応する印刷画像を記述した印刷画像データをアプリケーション２３０又はプリンタドライバが作成するが、その印刷画像データを"bind"処理し、その"bind"の出力値を前記メタ情報のbody要素としてもよい。印刷画像データは、プリンタ２５０が取り扱い可能なデータ形式のものであればよく、ページ記述言語で記述されたデータであってもビットマップ画像であってもよい。また前記メタ情報のuser要素やtime要素、filename要素などの値は、オペレーティングシステムから入手できる。またmethod要素の値は、この場合は"printed（印刷された）"である。そして紙文書管理部２２４は、その"bind"処理の出力値did2を表すコード画像を生成し、テンポラリファイルの印刷画像データに対して、そのコード画像の画像を埋め込む（Ｓ１０４）。ここで、コード画像は、文字列であってもよい。また、１次元バーコードや２次元バーコード、ＱＲコード（登録商標）などといったコードであってもよい。また、コード画像は透かしデータとして印刷画像に埋め込んでもよい。なお、この値did2は、印刷結果の紙文書の文書識別子として機能する。この文書識別子did2に対応するメタ情報には、その紙文書の元になった電子文書の文書識別子did1がbase要素として含まれている。紙文書管理部２２４は、このように識別子did2が埋め込まれた印刷画像データを、プリンタ２５０に渡して印刷させる（Ｓ１０５）。
【００９８】
次に、印刷時の処理手順の別の例を、図１６を参照して説明する。図１６の手順は、紙文書管理部２２４により実行される。対象となる電子文書を表すテンポラリファイルに対する操作が、図１３のステップＳ６８でアプリケーション２３０に委譲されたとする。その後、テンポラリファイルが閉じられるまで、紙文書管理部２２４は、アプリケーション２３０に対しユーザからそのテンポラリファイルの印刷の指示があるか、監視する（Ｓ１１１）。印刷指示を検知すると、紙文書管理部２２４は、アプリケーション２３０又はプリンタドライバが作成したそのテンポラリファイルの印刷画像データを対象として、サーバＩＦ部２１８に"bind"処理を依頼する（Ｓ１１２）。そして、この"bind"処理の出力値をbody要素として含み、図１３のステップＳ６３で記憶された識別子did1をbase要素として含むメタ情報を生成し、そのメタ情報に対する"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１１３）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１１４）。そして紙文書管理部２２４は、その"bind"処理の出力値did2を内容として含む参照情報ファイルを生成し、これをプリンタ２５０に送信する（Ｓ１１５）。この例では、プリンタ２５０も、文書処理部２１０と同等の機能を備える。プリンタ２５０は、受け取った参照情報ファイルの内容did2についての"resolve"処理を実行する（Ｓ１１６）。すると、サーバ１０からプリンタ２５０に対し、識別子did2に対応するメタ情報が提供される。プリンタ２５０は、そのメタ情報のbody要素に対して"resolve"処理を実行する（Ｓ１１７）。すると、サーバ１０からプリンタ２５０に対し、ステップＳ１１２でサーバ１０に登録された印刷画像データが提供される。プリンタ２５０は、ステップＳ１１７の処理により取得した印刷画像データをレンダリングして、印刷に使用可能なラスタ画像データを生成し（Ｓ１１８）、そのラスタ画像データに対し、識別子did2を表すコード画像を重畳し、重畳後の画像を媒体に印刷する（Ｓ１１９）。
【００９９】
図１６の処理手順を用いれば文書の印刷指示を行うクライアント２０からプリンタ２５０へのデータ送信量は削減される。同一文書を複数回印刷する場合や、さらに、印刷画像データが構造化されている場合、例えば印刷画像データがＸＭＬ文書として表現され、ＸＭＬ文書の文書識別子としてDomHashを用いた場合、さらにデータ送信量は削減される。既に印刷を指示したことのある文書コンポーネントの再送が避けられるためである。またさらにプリンタ２５０にキャッシュを持つようにすればサーバ１０からプリンタ２５０へのデータ送信量も削減される。さらにこれらキャッシュへのインターフェイスを"resolve"に限定すれば、キャッシュに蓄積されたデータのコンテクスト（ハッシュ値）を知らない悪意を持ったユーザがキャッシュのデータを取り出すことはできない。
【０１００】
次に、クライアント２０で紙文書の複写を行う場合の処理の流れを、図１７を参照して説明する。この処理は、紙文書管理部２２４により実行される（図６参照）。
【０１０１】
ユーザがスキャナ２６０に紙文書をセットし、情報処理部２１０に対して複製を指示すると、スキャナ２６０が紙文書を読み取り、その結果得られたスキャン画像が、情報処理部２００が備えるメモリ上に確保されたスキャン画像キュー（図示省略）に蓄積される（Ｓ１２１）。紙文書管理部２２４は、そのスキャン画像から、文書識別子のコード画像の抽出を試みる（Ｓ１２２）。その紙文書に本実施形態の方法に従って文書識別子のコード画像が埋め込まれていれば、紙文書管理部２２４は、その方法に従ってコード画像を抽出することができる。紙文書管理部２２４は、コード画像が抽出されたか否かを判定し（Ｓ１２３）、コード画像が抽出された場合は、紙文書管理部２２４はそのコード画像をデコードし、その値did1を認識する（Ｓ１２４）。これが、紙文書の文書識別子である。そして、スキャン画像からそのコード画像を除去し（Ｓ１２５）、コード画像除去後のスキャン画像に対する"bind"処理の実行をサーバＩＦ部２１８に依頼する（Ｓ１２６）。そして、その"bind"処理の出力値をbody要素として含み、元の紙文書の文書識別子did１をbase要素として含むメタ情報を生成する（Ｓ１２７）。このメタ情報は、これから出力される複製のメタ情報であり、元の紙文書の文書識別子を親の情報として含み、コード画像除去後のスキャン画像のハッシュ値（識別子）を当該複製の画像を示す情報として含んでいる。また、このメタ情報のmethod要素の値は、"copied（複製された）"となる。また、日時や複製を指示したユーザ名などの操作に関係する履歴項目の値は、オペレーティングシステムから入手され、time要素やuser要素などとして組み込まれる。紙文書管理部２２４は、そのメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１２８）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１２９）。そして、コード画像除去後のスキャン画像に対し、その"bind"処理の出力値did2を表すコード画像を重畳し、重畳後の画像をプリンタ２５０に印刷させる（Ｓ１３０）。値did2は、複製された紙文書の文書識別子として機能する。
【０１０２】
また、ステップＳ１２３でスキャン画像からコード画像が抽出されなかったと判定された場合は、ステップＳ１２４及びＳ１２５の処理はスキップされ、ステップＳ１２６に進む。この場合、ステップＳ１２７で作成されるメタ情報のbase要素は空となる。その他の処理は、コード画像が抽出された場合と同様でよい。
【０１０３】
上記の複製手順によれば、元の紙文書に埋め込まれていた文書識別子は、複製操作の情報を表すメタ情報から求められた新たな文書識別子に置換される。したがって、複数回の複製の連鎖に対しても、個々の複製操作のメタ情報を保存でき、後でそれら個々の複製を追跡することができる。
【０１０４】
また、サーバ１０に登録された電子文書を印刷して得られた紙文書を複製する場合、その紙文書に埋め込まれた文書識別子から派生関係を遡ることで、オリジナルの電子文書を特定することができる。特定されたオリジナルの電子文書の画像と複製対象の紙文書の画像の差から、オリジナルの電子文書の画像に対する書き込み（アノテーション）を分離してもよい。本システムで紙文書を複製した場合、紙文書を読み取った画像がサーバ１０に登録される。したがって、ある紙文書を複製して紙文書Ａが得られ、その紙文書Ａに対して書き込みが行われたものが更に複製された場合、複製出力された時点の紙文書Ａの画像はサーバ１０に蓄積されている（蓄積された画像データを１つの電子文書と捉えてもよい）ので、書き込み後の紙文書Ａの複写時に読み取った画像と、その複製時点の紙文書Ａの画像との差を書き込み内容として分離できる。そのようなケースではオリジナルの電子文書の画像に書き込み内容を重畳した画像を複写操作で出力される文書の画像とすることによって、複数回の複製の連鎖に対しても機能する。
【０１０５】
次に、クライアント２０で紙文書のスキャン（読取）を行う場合の処理の流れを、図１８を参照して説明する。この処理は、紙文書管理部２２４により実行される。
【０１０６】
ユーザがスキャナ２６０に紙文書をセットし、情報処理部２００に対してスキャンを指示すると、スキャナ２６０が紙文書を読み取り、その結果得られたスキャン画像が、情報処理部２００が備えるメモリ上に確保されたスキャン画像キューに蓄積される（Ｓ１３１）。紙文書管理部２２４は、そのスキャン画像から、文書識別子のコード画像の抽出を試みる（Ｓ１３２）。紙文書管理部２２４は、コード画像が抽出されたか否かを判定し（Ｓ１３３）、コード画像が抽出された場合は、紙文書管理部２２４はそのコード画像をデコードし、紙文書の文書識別子did1を認識する（Ｓ１３４）。次に紙文書管理部２２４は、その文書識別子についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ１３５）、その結果として得られた紙文書のメタ情報から、オリジナルの電子文書のファイル名（filename要素の値）を得る（Ｓ１３６）。紙文書管理部２２４は、スキャン画像からそのコード画像を除去し（Ｓ１３７）、コード画像除去後のスキャン画像に対する"bind"処理の実行をサーバＩＦ部２１８に依頼する（Ｓ１３８）。そして、その"bind"処理の出力値をbody要素として含み、紙文書の文書識別子did１をbase要素として含むメタ情報を生成する（Ｓ１３９）。このメタ情報は、これから生成されるスキャン画像ファイルのメタ情報であり、元の紙文書の文書識別子を親の情報として含み、コード画像除去後のスキャン画像のハッシュ値（識別子）を当該スキャン画像を示す情報として含んでいる。また、このメタ情報のmethod要素の値は、"scanned（スキャンされた）"となる。また、日時や複製を指示したユーザ名などの操作に関係する履歴項目の値は、オペレーティングシステムから入手され、time要素やuser要素などとして組み込まれる。紙文書管理部２２４は、そのメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１４０）。また、このときに生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１４１）。そして、"bind"処理の出力値did2を内容とする参照情報ファイルを生成する（Ｓ１４２）。ここで、ステップＳ１３６で取得した元の電子文書のファイル名に基づきスキャン画像ファイルのファイル名を作成してもよい。例えば、元の電子文書のファイル名に対し、スキャン画像ファイルのファイル形式に対応した拡張子（例えば".tif"など）を付加したものをスキャン画像のファイル名とするなどである。また、参照情報ファイルのファイル名は、スキャン画像ファイルのファイル名に対し、電子文書の参照情報であることを示す拡張子（例えば".yui"）を付加したものとしてもよい。参照情報ファイルは、例えばスキャン画像ファイルが保存されるフォルダに保存する。
【０１０７】
なお、ステップＳ１３３でスキャン画像からコード画像が抽出されなかったと判定された場合は、ステップＳ１３４〜Ｓ１３７の処理はスキップされ、処理はステップＳ１３８に進む。この場合、ステップＳ１３９で作成されるメタ情報のbase要素は空となる。また、スキャン画像ファイルには所定の規則に従ってファイル名を付与してもよい。例えば、スキャンを指示したユーザのユーザ名とスキャン操作の時刻とを順に並べた文字列に対し、スキャン画像ファイルの形式に対応する拡張子を付加したものを、ファイル名としてもよい。スキャン画像ファイルに対応する参照情報ファイルにはスキャン画像ファイルのファイル名の文字列に対し電子文書の参照情報であることを示す拡張子を付加したものとしてもよい。その他の処理は、コード画像が抽出された場合と同様でよい。
【０１０８】
通常、スキャンで生成されるスキャン画像ファイルは、あらかじめ設定された特定のフォルダに蓄積される。したがって、一般には、各ユーザは、そのスキャン画像ファイルを入手するにはその特定のフォルダにアクセスする必要がある。これに対し、本実施形態では、ユーザは文書の派生関係の木構造を参照できるので、スキャンした紙文書又はその祖先にあたる電子文書の参照情報ファイルを持つユーザは、その特定のフォルダへ明示的にアクセスしなくても、サーバ１０を介してそのスキャン画像ファイルが入手できる。スキャン画像が蓄積されるフォルダを一般に公開しないことによって、スキャン画像の暴露の機会を減らすことができる。
【０１０９】
次に、紙文書をクライアント２０のスキャナ付きシュレッダ２７０にかけて廃棄する場合の処理の流れを、図１９を参照して説明する。この処理は、紙文書管理部２２４により実行される。
【０１１０】
スキャナ付きシュレッダ２７０は、例えば紙を投入する投入口にスキャナが設けられ、破断される前にその紙の画像をそのスキャナにより読み取る。
【０１１１】
ユーザがスキャナ付きシュレッダ２７０に投入すると、スキャナが紙文書を読み取り（Ｓ１５１）、その結果得られたスキャン画像が、情報処理部２００が備えるメモリ上に確保されたスキャン画像キューに蓄積される（Ｓ１５２）。紙文書管理部２２４は、そのスキャン画像から、文書識別子のコード画像の抽出を試みる（Ｓ１５３）。紙文書管理部２２４は、コード画像が抽出されたか否かを判定し（Ｓ１５４）、コード画像が抽出された場合は、紙文書管理部２２４はそのコード画像をデコードし、紙文書の文書識別子did1を認識する（Ｓ１５５）。次に紙文書管理部２２４は、その文書識別子についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ１５６）、その結果として得られた紙文書のメタ情報から、オリジナルの電子文書のファイル名（filename要素の値）を得る（Ｓ１５７）。紙文書管理部２２４は、スキャン画像からそのコード画像を除去し（Ｓ１５８）、コード画像除去後のスキャン画像に対する"bind"処理の実行をサーバＩＦ部２１８に依頼する（Ｓ１５９）。そして、その"bind"処理の出力値をbody要素として含み、紙文書の文書識別子did１をbase要素として含むメタ情報を生成する（Ｓ１６０）。このメタ情報は、破棄された紙文書のメタ情報であり、元の紙文書の文書識別子を親の情報として含み、コード画像除去後のスキャン画像のハッシュ値（識別子）を、破棄された紙文書の画像を示す情報として含んでいる。また、このメタ情報のmethod要素の値は、"shredded（細断された）"となる。紙文書管理部２２４は、そのメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１６１）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１６２）。
【０１１２】
なお、ステップＳ１５４でスキャン画像からコード画像が抽出されなかったと判定された場合は、ステップＳ１５５〜Ｓ１５８の処理はスキップされ、処理はステップＳ１５９に進む。この場合、ステップＳ１６０で作成されるメタ情報のbase要素は空となる。その他の処理は、コード画像が抽出された場合と同様でよい。
【０１１３】
以上に説明したように、紙文書管理部２２４は、印刷管理、スキャン管理、紙文書複製管理、及び紙文書廃棄管理の機能を備える。
【０１１４】
以上では、文書識別子がコード画像として紙文書に印刷される場合を例示したが、用紙がＲＦＩＤタグを備えている場合には、文書識別子をそのＲＦＩＤタグに書き込んでもよい。この場合、プリンタ２５０は、ＲＦＩＤタグに書き込みを行うライタを有していればよい。またスキャナ２６０は、ＲＦＩＤタグを読み取るリーダを有していればよい。シュレッダは、スキャナの代わりにＲＦＩＤタグリーダを有していればよい。
【０１１５】
このようにＲＦＩＤタグを用いる場合、紙文書の移動を検知するためにセキュリティゲート装置を設置してもよい。このセキュリティゲート装置は、ゲートを通過する紙文書のＲＦＩＤタグから文書識別子を読み取り、その文書識別子をbase要素として持つメタ情報を生成する。このメタ情報のmethod要素は、「ゲート通過」という操作を示す。ゲート内に入ったのか、ゲート外に出たのかといったように、更に詳細な操作を記録してもよい。time要素はその装置の時計から得ることができる。セキュリティゲート装置がユーザのＩＤカードを読み取る機能を持てば、読み取ったユーザＩＤをuser要素に記録することもできる。セキュリティゲート装置は、生成されたメタ情報を"bind"処理する。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する。これにより、ゲート通過についてのメタ情報がサーバ１０に蓄積される。
【０１１６】
次に、参照情報ファイルを用いた電子文書へのアクセス禁止処理について説明する。この処理は、アクセス禁止処理部２２６（図６参照）により実行される。
【０１１７】
ＵＩ部２１２に対してユーザが、参照情報ファイルを指定して、アクセス禁止を指示すると、アクセス禁止処理部２２６は、その参照情報ファイル内の文書識別子didを取り出し、didについての"delete"処理をサーバＩＦ部２１８に依頼する。これにより、文書識別子didに対応するメタ情報が文書管理ＤＢ１１０から削除される。
【０１１８】
このように構成すると、削除された参照情報ファイルに対応する文書から派生した文書に対応する参照情報ファイルの所持者は、派生関係の木構造において、削除された文書に対応するノード以前の文書へのアクセスができなくなる。
【０１１９】
また、さらに削除された参照情報ファイルから派生した文書の文書識別子didについての"delete"処理を再帰的にサーバＩＦ部２１８に依頼してもよい。こうすれば、アクセスが禁止された文書をルートとする部分木全体にアクセスできなくなる。このように構成すれば、例えば、特定の情報流通パスを通じて伝播したドキュメントを一斉にアクセス禁止にすることもできる。
【０１２０】
ただし、"delete"処理を用いた操作は深刻な副作用を及ぼす（例えば、参照情報ファイルの所持者が、参照情報ファイルを生成した者の意図とは独立に文書のアクセスを禁止してしまうことができる）ので、そのような操作が可能なユーザを限定してもよい。例えば、参照情報ファイルを作成したユーザだけが、その参照情報ファイルについてのアクセス禁止を指示できるようにしてもよい。このような制限は、例えばユーザ認証機構を設けることにより実現できる。
【０１２１】
次に、派生関係表示のための処理を、図２０を参照して説明する。この処理は、クライアント２０の派生関係表示処理部２２８と、サーバ１０の派生関係表示生成部１４０により実行される。
【０１２２】
ＵＩ部２１２に対し、ユーザから、対象とする参照情報ファイルを指定し、派生関係の表示が指示されると、派生関係表示処理部２２８は、その参照情報ファイルに含まれる文書識別子didを取り出し、そのdidを引数として含む派生関係表示要求をサーバ１０に送る。この要求を受け取ったサーバ１０の派生関係表示生成部１４０は、図２０に示す処理手順を実行する。
【０１２３】
すなわち、派生関係表示生成部１４０は、クライアント２０から受信した文書識別子didに対して"resolve"処理を実行し（Ｓ１７１）、その結果得られるメタ情報からbase要素を抽出する（Ｓ１７２）。抽出の結果、base要素が空であるか否かを判定し（Ｓ１７３）、空でなければ、そのbase要素の値に対して"resolve"処理を実行し（Ｓ１７４）、その結果得られるメタ情報からbase要素を抽出し（Ｓ１７５）、抽出されたbase要素が空であるか否かを判定する（Ｓ１７３）。ステップＳ１７４，Ｓ１７５は、派生関係を親へと１つ遡る処理である。ステップＳ１７３の判定結果が肯定（Ｙｅｓ）となるまで、ステップＳ１７３〜Ｓ１７５が繰り返される。ステップＳ１７３の判定結果が肯定となったことは、クライアント文書識別子didから派生関係の木構造を遡った結果その木構造の根ノードに到達したことを意味する。その場合、派生関係表示生成部１４０は、派生関係ＤＢ１２０を参照することで、その根ノードから派生する子孫ノードからなる木構造全体を求める（Ｓ１７６）。そして、その木構造全体を表す派生関係表示データを生成し、クライアント２０に返す（Ｓ１７７）。派生関係表示データは、例えばＨＴＭＬ文書として作成してもよい。クライアント２０の派生関係表示処理部２２８は、その表示データをレンダリングして派生関係のツリー表示画像を生成し、画面に表示する。
【０１２４】
派生関係表示データが表す表示画像４００の例を、図２１に模式的に示す。表示画像４００は、文書Ａ１に対応する参照情報ファイルを指定して派生関係表示が指示された場合の例である。派生関係表示生成部１４０は、文書Ａ１から派生関係を遡ることで、根ノードである文書Ａ０に到達し、その文書Ａ０から派生する文書Ａ１及び文書Ａ２、文書Ａ１から派生する文書Ａ３を派生関係ＤＢ１２０から求める。そして、それら各文書のアイコン４０２〜４０８を、その派生関係にしたがって配列し、派生関係をエッジで結んで表示した木構造表示を生成する。各アイコン４０２〜４０８には、ファイル名、当該文書が生成された際の操作の種類、その操作を指示したユーザの識別名、その操作の日時、等と行った履歴情報を表示してもよい。このような履歴情報は、各文書に対応するメタ情報から取得できる。また、対象として指示された参照情報ファイルに対応するアイコン４０４は、他のアイコンと区別できる表示形態で表示してもよい（例えば色を変えるなど）。
【０１２５】
以上、実施形態の構成及び処理内容について説明した。以上の例では、文書管理サーバ１０が１つである場合を説明したが、複数の文書管理サーバ１０で分散サーバネットワークを構成してもよい。なお、１つのクライアント２０から、分散サーバネットワークを構成するすべてのサーバ１０を参照できなくても構わない。例えば一部のネットワークがイントラネット上に配置され、インターネット側に存在するクライアントからは到達できない場合や、サーバがクライアントを認証し許可されたクライアントに対してしか反応しないなどの方法で論理的にネットワークが制限される場合などが、このようなケースに該当する。
【０１２６】
このような分散構成の一例を説明する。図２２に示すように、分散ネットワークを構成する各文書管理サーバ１０は、図２に例示した単体構成のサーバが持つ要素の他に、他サーバ通知部１５０を備える。他サーバ通知部１５０は通知先リスト１５２を記憶している。通知先リスト１５２には、通知先である各サーバの識別子が登録されている。以下では、文書管理サーバ１０を単に「サーバ」と呼ぶ。
【０１２７】
この例では、サーバの集合をΣとし、各サーバＳ∈Σにはサーバ識別子idＳが対応付けられているとする。また各サーバＳは通知先リスト１５２としてサーバ識別子の集合FＳを保持する。idＳ'∈FＳである（すなわちサーバＳ'はサーバＳの通知先リスト１５２に含まれる）とすると、サーバＳ及びＳ'をそれぞれグラフのノードとすると、ノードＳからノードＳ'への有向エッジを定義できる。このようにノードと有向エッジを定義すると、サーバの集合Σを表す有向グラフを得ることができる。通知先リストを適切に設定すれば、サーバの集合Σについてのグラフを非循環有向グラフ（DAG: Directed acyclic graph）とすることができる。
【０１２８】
サーバＳがクライアントから"bind"メッセージ(ξ,x)を受信すると、サーバＳは、データｘを記憶すると共に、通知先リスト１５２に含まれる各サーバに"bind"メッセージ(ξ,idＳ)を転送する。サーバＳの識別子idＳとしては、例えばサーバＳのネットワーク上でのアドレスを用いてもよい。また、サーバＳの識別子idＳがサーバＳのアドレスそのものでなくても、識別子idＳからサーバＳのアドレスを解決する仕組みをネットワーク上に設けることは、周知技術により容易に実現できる。
【０１２９】
また、サーバＳ' がサーバＳから"bind"メッセージ(ξ,idＳ)を受信すると、サーバＳ'はidＳをξと関連付けて記憶すると共に、自分の通知先リストに含まれるサーバに"bind"メッセージ(ξ,idＳ)を転送する。Σは有限集合でDAGであるので上記の操作は必ず停止する。
【０１３０】
"resolve"メッセージについても同様に構成することによって、クライアントがリクエストをしたサーバを含むグラフΣの連結成分の全体が仮想的には単一のサーバとして動作することになる。
【０１３１】
"resolve"メッセージを受信したときのサーバの処理手順の一例を、図２３に示す。この例では、ハッシュ値ξについての"resolve"メッセージを装置Ａから受信すると（Ｓ１８１）、サーバはξをキーとして、自分の持つ文書管理ＤＢ１１０を検索する（Ｓ１８２）。ここで、装置Ａは、クライアント２０の場合もあれば、他のサーバの場合もある。サーバは、ステップＳ１８２の検索によりキーξに対応するデータが検索できたかどうかを判定し（Ｓ１８３）、検索できた場合、キーξに対応するデータがサーバ識別子であるか、登録されたデータ実体ｘ（電子文書又はメタ情報）であるかを判定する（Ｓ１８４）。キーξに対応するデータがデータ実体ｘであれば、サーバはそのデータ実体ｘを装置Ａに返す（Ｓ１８５）。キーξに対応するデータがサーバ識別子であれば、サーバはそのサーバ識別子に対応するサーバへ、ハッシュ値ξについての"resolve"メッセージを送信し（Ｓ１８６）、このメッセージに対する返信を待つ。返信には、ξに対応するデータ実体ｘが含まれる。この返信を受け取ったサーバは、そのデータ実体ｘを装置Ａに返す（Ｓ１８７）。
【０１３２】
ステップＳ１８３で、当該サーバ内の文書管理ＤＢ１１０にキーξが存在しないと判定された場合は、他サーバ通知部１５０が、通知先リスト１５２に登録された各サーバに対して、ハッシュ値ξについての"resolve"メッセージを送信し（Ｓ１８８）、そのメッセージに対する返信を受け取る。そしてサーバは、その返信に含まれるデータ実体ｘを装置Ａに返す（Ｓ１８９）。
【０１３３】
"exist?"メッセージは、"resolve"メッセージと同様に処理すればよい。すなわち、例えば図２４に示すように、サーバは、"exist?(ξ)"メッセージを装置Ａから受け取った場合（Ｓ１９１）、自分の文書管理ＤＢ１１０においてキーξを検索し（Ｓ１９２）、キーξが検索できたかどうかを判定する（Ｓ１９３）。検索できた場合、ブール値b=trueを装置Ａに返す（Ｓ１９４）。また、キーξがサーバ内の文書管理ＤＢ１１０に存在しない場合、他サーバ通知部１５０は、通知先リスト１５２を調べる（Ｓ１９５）。通知先リストが空でなければ、そのリスト内の各通知先サーバに対して"exist?(ξ)"メッセージを送信し、各サーバからの返信を待つ（Ｓ１９６）。そして、各サーバからの返信を判定する（Ｓ１９７）。その結果、ブール値b=trueを含む返信が１つでもあれば、サーバはブール値b=trueを装置Ａに返す（Ｓ１９４）。すべての通知先サーバからの返信がブール値b=falseである場合は、サーバはブール値b=falseを装置Ａに返す（Ｓ１９８）。また、ステップＳ１９５で通知先リスト１５２が空であった場合、サーバは、ブール値b=falseを装置Ａに返す（Ｓ１９８）。
【０１３４】
また、"delete(ξ)"メッセージを受け取ったサーバの処理は、例えば以下のようなものでよい。すなわち、この場合サーバは、当該サーバの文書管理ＤＢ１１０内にキーξのエントリが存在すればそれを削除する。また、キーξのエントリが存在するか否かにかかわらず、他サーバ通知部１５０が通知先リスト１５２に登録された各サーバに対し、"delete(ξ)"メッセージを送信する。
【０１３５】
以上に例示した分散サーバ構成は、グラフΣがDAGである要請を満たす範囲で自由にネットワークのトポロジーを変更することが可能である。また、２つのサブグラフが相互に連結していない場合に、一方のサブグラフのリーフの通知先リストに、他方のサブグラフのノードを追加することで、それら２つのサブグラフを連結することができる。このような連結処理により、例えば、異なるドメインに独立に存在していた複数の分散サーバネットワークをアポステリオリにマージして１つの大きな分散サーバネットワークを構築することができる。
【０１３６】
分散サーバ構成の別の例として、周知のChord（http://pdos.csail.mit.edu/chord/）による分散ハッシュテーブルを利用することも可能である。すなわち、分散サーバネットワークを、分散ハッシュテーブルで表現される構造化オーバレイネットワークとして構成するのである。これは、サーバサイドのいわゆるP2Pネットワーク構成と捉えることができる。
【０１３７】
以上、実施形態のシステムを説明した。以上の例では、クライアント２０とサーバ１０とが別々のホストコンピュータ上に存在するとして説明したが、それら両者が同一ホスト上に存在しても構わない（いわゆるP2Pネットワーク構成）。
【０１３８】
以上の例では、電子文書及びフォルダなどのメタ情報をＸＭＬで記述したが、これはあくまで一例に過ぎない。メタ情報は、記述形式に依存するものではない。
【０１３９】
以上の実施形態において、サーバ１０は、典型的には、汎用のコンピュータにて上述の各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図２５に示すように、ＣＰＵ（中央演算装置）４０、メモリ（一次記憶）４２、各種Ｉ／Ｏ（入出力）インターフェイス４４等がバス４６を介して接続された回路構成を有する。また、そのバス４６に対し、例えばＩ／Ｏインターフェイス４４経由で、ハードディスクドライブ４８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ５０が接続される。このようなドライブ４８又は５０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ４８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。クライアント２０も、コンピュータ・ハードウエアを用いて同様に構成することができる。
【図面の簡単な説明】
【０１４０】
【図１】文書管理システムの概略構成の例を示す図である。
【図２】文書管理サーバの内部構成の例を示す図である。
【図３】文書管理ＤＢのデータ内容の一例を示す図である。
【図４】派生関係ＤＢのデータ内容の一例を示す図である。
【図５】電子文書とメタ情報と参照情報ファイルとの関係を説明するための図である。
【図６】クライアント装置の内部構成の例を示す図である。
【図７】bind処理の手順の例を示すフローチャートである。
【図８】resolve処理の手順の例を示すフローチャートである。
【図９】exist?処理の手順の例を示すフローチャートである。
【図１０】delete処理の手順の例を示すフローチャートである。
【図１１】電子文書に対応する参照情報ファイルの生成処理の手順の例を示すフローチャートである。
【図１２】フォルダに対応する参照情報ファイルの生成処理の手順の例を示すフローチャートである。
【図１３】電子文書を出力する操作の手順の例を示すフローチャートである。
【図１４】フォルダに対する操作の手順の例を示すフローチャートである。
【図１５】電子文書の印刷が指示された場合の手順の例を示すフローチャートである。
【図１６】電子文書の印刷が指示された場合の手順の別の例を示すフローチャートである。
【図１７】紙文書の複写が指示された場合の手順の例を示すフローチャートである。
【図１８】紙文書のスキャンが指示された場合の手順の例を示すフローチャートである。
【図１９】紙文書の廃棄が指示された場合の手順の例を示すフローチャートである。
【図２０】派生関係表示が指示された場合の手順の例を示すフローチャートである。
【図２１】派生関係の表示画像の一例を示す図である。
【図２２】複数の文書管理サーバによる分散サーバ構成を採用した場合の、個々の文書管理サーバの内部構成の例を示す図である。
【図２３】分散サーバ構成においてサーバが"resolve"メッセージを受け取ったときに実行する処理の例を示すフローチャートである。
【図２４】分散サーバ構成においてサーバが"exist?"メッセージを受け取ったときに実行する処理の例を示すフローチャートである。
【図２５】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【０１４１】
１０ 文書管理サーバ、２０ クライアント装置、３０ ネットワーク、１１０ 文書管理ＤＢ、１２０ 派生関係ＤＢ、１３０ クライアントＩＦ部、１４０ 派生関係表示生成部、２００ 情報処理部、２１０ 文書処理部、２３０ アプリケーション、２４０ ファイルシステム、２５０ プリンタ、２６０ スキャナ、２７０ スキャナ付きシュレッダ。
【技術分野】
【０００１】
本発明は、文書管理システム、文書処理クライアント装置、文書管理サーバ装置及びプログラムに関する。
【背景技術】
【０００２】
文書管理の分野では、流通している文書のトレーサビリティ（追跡性）が問題となっている。電子文書、すなわちコンピュータソフトウエアにより作成された文書データを管理するシステムでは、電子文書を誰がダウンロードしたかや、誰から誰に電子文書が提供されたかなどといった電子文書の流通経路に関する情報を求める機能を持つものも存在する。
【０００３】
【特許文献１】特開平１１−２４９７７７号公報
【特許文献２】特開平１１−２５９４５９号公報
【特許文献３】特開２００４−０７２３４３号公報
【特許文献４】特開２００４−１０２６２７号公報
【特許文献５】特開２００５−０３５０９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、電子文書を紙などの物理的な媒体に印刷した場合、又は紙文書などの物理的な媒体に印刷された文書を読み取って電子文書を生成した場合などにおいて、文書間の親子関係（派生関係）を追跡するには、従来のシステムは必ずしも十分とはいえなかった。
【課題を解決するための手段】
【０００５】
請求項１に係る発明は、電子文書と、当該電子文書の内容のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、管理識別子を指定した取得指示に基づいて、当該管理識別子に対応する管理情報を前記管理情報記憶部から取得し、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書記憶部から取得する取得部と、前記取得部が取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を、当該管理情報のハッシュ値である当該媒体文書の管理識別子と対応づけて前記管理情報記憶部に登録すると共に、当該媒体文書の管理識別子を当該媒体文書に対して書き込む印刷管理部と、を備える文書管理システムである。
【０００６】
請求項２に係る発明は、請求項１に係る文書管理システムにおいて、前記取得部が取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書を、当該第２の電子文書の内容識別子と対応づけて前記文書記憶部に登録すると共に、当該第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を、当該管理情報のハッシュ値である当該第２の電子文書の管理識別子と対応づけて前記管理情報記憶部に登録する登録部、を更に備えることを特徴とする。
【０００７】
請求項３に係る発明は、請求項１に係る文書管理システムにおいて、前記印刷管理部は、前記媒体へ印刷される画像を表す印刷画像データを、当該印刷画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、ことを特徴とする。
【０００８】
請求項４に係る発明は、請求項１に係る文書管理システムにおいて、媒体文書に対する読取操作の実行に応じて、当該媒体文書に書き込まれた管理識別子を認識し、当該読取の結果得られる電子文書の管理情報として、前記媒体文書の管理識別子を含む管理情報を生成し、当該電子文書を当該電子文書のハッシュ値である内容識別子と対応づけて前記文書記憶部に登録すると共に、当該管理情報を当該管理情報のハッシュ値である管理識別子と対応づけて前記管理情報記憶部に登録する読取管理部、を更に備える。
【０００９】
請求項５に係る発明は、請求項１に係る文書管理システムにおいて、第１の媒体文書に対する複製操作の実行に応じて、当該第１の媒体文書に書き込まれた管理識別子を認識し、当該複製の結果得られる第２の媒体文書の管理情報として、前記第１の媒体文書の管理識別子を含む管理情報を生成し、当該管理情報を当該管理情報のハッシュ値である第２の管理識別子と対応づけて前記管理情報記憶部に登録すると共に、当該第２の管理識別子を前記第２の媒体文書に対して書き込む複製管理部、を更に備える。
【００１０】
請求項６に係る発明は、請求項５に係る文書管理システムにおいて、前記複製管理部は、前記第１の媒体文書の読取により得られた画像データを、当該画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記第２の媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する。
【００１１】
請求項７に係る発明は、請求項１に係る文書管理システムにおいて、媒体文書に対する廃棄操作の実行に応じて、当該媒体文書に書き込まれた管理識別子を認識し、当該媒体文書の廃棄を示す管理情報として、前記媒体文書の管理識別子を含む管理情報を生成し、当該管理情報を当該管理情報のハッシュ値である管理識別子と対応づけて前記管理情報記憶部に登録する廃棄管理部、を更に備える。
【００１２】
請求項８に係る発明は、請求項７に係る文書管理システムにおいて、前記廃棄管理部は、前記媒体文書の読取により得られた画像データを、当該画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、ことを特徴とする。
【００１３】
請求項９に係る発明は、管理識別子を指定した取得指示に応じて、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶した管理情報記憶部から、当該操作指示にて指定された管理識別子に対応する管理情報を取得するステップと、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を、電子文書と、当該電子文書のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶した文書記憶部から取得するステップと、取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を、当該管理情報のハッシュ値である当該媒体文書の管理識別子と対応づけて前記管理情報記憶部に登録するステップと、当該媒体文書の管理識別子を当該媒体文書に対して書き込むステップと、をコンピュータに実行させるためのプログラムである。
【００１４】
請求項１０に係る発明は、請求項９に係る発明において、取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書を、当該第２の電子文書の内容識別子と対応づけて前記文書記憶部に登録するステップと、当該第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を、当該管理情報のハッシュ値である当該第２の電子文書の管理識別子と対応づけて前記管理情報記憶部に登録するステップと、を更にコンピュータに実行させることを特徴とする。
【００１５】
請求項１１に係る発明は、電子文書と、当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、を備えた文書管理サーバシステムと通信し、利用者に対して文書処理機能を提供する文書処理クライアント装置であって、管理識別子を指定した取得指示に応じて、当該管理識別子に対応する管理情報を前記文書管理サーバから取得し、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書管理サーバから取得する取得部と、前記取得部が取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を生成し、当該媒体文書の管理識別子として当該管理情報のハッシュ値を計算し、計算された管理識別子と当該媒体文書の管理情報とを対応づけて前記文書管理サーバに登録すると共に、当該媒体文書の管理識別子を当該媒体文書に対して書き込む印刷管理部と、を備える文書処理クライアント装置である。
【００１６】
請求項１２に係る発明は、前記請求項１１に係る発明において、前記取得部が取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書についての内容識別子として当該第２の電子文書のハッシュ値を計算し、計算された内容識別子と当該第２の電子文書とを対応づけて前記文書管理サーバに登録する内容登録部と、前記第２の電子文書の管理情報として、前記第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を生成し、当該第２の電子文書の管理識別子として当該管理情報のハッシュ値を計算し、計算された管理識別子と当該第２の電子文書の管理情報とを対応づけて前記文書管理サーバに登録する管理情報登録部と、を更に備える。
【００１７】
請求項１３に係る発明は、電子文書と、当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、を備えた文書管理サーバシステムと通信し、利用者に対して文書処理機能を提供する文書処理クライアント装置、としてコンピュータを機能させるためのプログラムであって、管理識別子を指定した取得指示に応じて、当該管理識別子に対応する管理情報を前記文書管理サーバから取得するステップと、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書管理サーバから取得するステップと、取得された前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を生成するステップと、当該媒体文書の管理識別子として当該管理情報のハッシュ値を計算するステップと、計算された管理識別子と当該媒体文書の管理情報とを対応づけて前記文書管理サーバに登録するステップと、当該媒体文書の管理識別子を当該媒体文書に対して書き込むステップと、を前記コンピュータに実行させるためのプログラム。
【００１８】
請求項１４に係る発明は、請求項１３に係る発明において、取得された前記第１の電子文書に対する操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書についての内容識別子として当該第２の電子文書のハッシュ値を計算するステップと、計算された内容識別子と当該第２の電子文書とを対応づけて前記文書管理サーバに登録するステップと、前記第２の電子文書の管理情報として、前記第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を生成するステップと、当該第２の電子文書の管理識別子として当該管理情報のハッシュ値を計算するステップと、計算された管理識別子と当該第２の電子文書の管理情報とを対応づけて前記文書管理サーバに登録するステップと、を更に前記コンピュータに実行させることを特徴とする。
【００１９】
請求項１５に係る発明は、電子文書と、当該電子文書の内容のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、文書処理クライアント装置から管理識別子を提示した解決要求を受けた場合に当該管理識別子に対応する管理情報を前記管理情報記憶部から前記文書処理クライアント装置に提供し、前記文書処理クライアント装置から内容識別子を提示した解決要求を受けた場合に当該内容識別子に対応する電子文書を前記文書処理クライアント装置に提供する識別子解決部と、前記文書処理クライアント装置から、媒体文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納する媒体情報格納処理部と、を備える文書管理サーバ装置である。
【００２０】
請求項１６に係る発明は、請求項１５に係る発明において、前記文書処理クライアント装置から、電子文書と内容識別子とを含む登録要求を受けた場合に、当該電子文書を当該内容識別子に対応づけて前記文書記憶部に格納する内容格納処理部と、前記文書処理クライアント装置から、電子文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納する管理情報格納処理部と、を更に備える。
【００２１】
請求項１７に係る発明は、請求項１６に係る文書管理サーバ装置において、通知先の第２の文書管理サーバ装置の識別子のリストを記憶したリスト記憶部と、文書処理クライアント装置から電子文書と内容識別子とを含む登録要求を受けた場合に、当該内容識別子と当該文書管理サーバ装置自身の識別子とを含む登録要求を、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に送信し、前記文書処理クライアント装置から管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理識別子と当該文書管理サーバ装置自身の識別子とを含む登録要求を、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に送信する送信部と、第３の文書管理サーバ装置から内容識別子と当該第３の文書管理サーバ装置の識別子とを含む登録要求を受けた場合、前記内容識別子と当該第３の文書管理サーバ装置の識別子とを前記文書記憶部に登録すると共に、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に当該登録要求を転送する第１登録処理部と、前記第３の文書管理サーバ装置から管理識別子と当該第３の文書管理サーバ装置の識別子とを含む登録要求を受けた場合、前記管理識別子と当該第３の文書管理サーバ装置の識別子とを前記管理情報記憶部に登録すると共に、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に当該登録要求を転送する第２登録処理部と、内容識別子を提示した解決要求を受けた場合に、前記文書記憶部に当該内容識別子に対応づけて記憶されている情報が文書管理サーバ装置の識別子であれば、当該識別子に対応する文書管理サーバ装置から当該内容識別子に対応する電子文書を取得し、取得された電子文書を前記解決要求の発行元の装置に返す第１解決処理部と、管理識別子を提示した解決要求を受けた場合に、前記管理情報記憶部に当該管理識別子に対応づけて記憶されている情報が文書管理サーバ装置の識別子であれば、当該識別子に対応する文書管理サーバ装置から当該管理識別子に対応する管理情報を取得し、取得された管理情報を前記解決要求の発行元の装置に返す第１解決処理部と、を更に備える。
【００２２】
請求項１８に係る発明は、文書処理クライアント装置から管理識別子を提示した解決要求を受けた場合に、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部から、当該管理識別子に対応する管理情報を取得し、前記文書処理クライアント装置に提供するステップと、前記文書処理クライアント装置から内容識別子を提示した解決要求を受けた場合に、電子文書と、当該電子文書のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部から、当該内容識別子に対応する電子文書を取得し、前記文書処理クライアント装置に提供するステップと、前記文書処理クライアント装置から、媒体文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納するステップと、をコンピュータに実行させるためのプログラム、である。
【００２３】
請求項１９に係る発明は、請求項１８に係る発明において、前記文書処理クライアント装置から、電子文書と内容識別子とを含む登録要求を受けた場合に、当該電子文書を当該内容識別子に対応づけて前記文書記憶部に格納するステップと、前記文書処理クライアント装置から、電子文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納するステップと、を更にコンピュータに実行させる。
【発明の効果】
【００２４】
本発明によれば、紙などの物理的な媒体に印刷された媒体文書について、電子文書との間の親子関係（派生関係）を管理することができる。
【発明を実施するための最良の形態】
【００２５】
図１は、文書管理システムの構成の一例を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０（以下サーバ１０と略称する）とクライアント装置（以下「クライアント」と略称する）２０−１，２０−２，・・・から構成される。クライアント装置２０−１，２０−２，・・・は、相互に区別する必要のない場合には、クライアント２０と総称する。
【００２６】
サーバ１０は、本システム内で流通する文書を管理する装置である。サーバ１０は、電子文書と紙文書の両方を管理する。電子文書は、アプリケーションプログラムが作成した電子的な文書ファイルである。紙文書は、電子文書の内容を紙などの物理的な媒体に印刷したものである。物理的な媒体は、その表面上に画像を保持することができるものであれば、紙に限らずどのようなものでもよい。なお、この明細書では、分かりやすさのために、物理的な媒体上に画像が形成されることで生成された文書を、紙文書と総称する。サーバ１０は、例えば図２に示すように、文書管理ＤＢ（データベース）１１０（記憶Ｔとも呼ぶ）、派生関係ＤＢ１２０（記憶Ｕとも呼ぶ）、クライアントＩＦ（インターフェイス）部１３０及び派生関係表示生成部１４０を備える。
【００２７】
文書管理ＤＢ１１０には、電子文書が、その電子文書のハッシュ値と対応づけて登録される。また文書管理ＤＢ１１０には、電子文書又は紙文書についてのメタ情報が、当該メタ情報のハッシュ値と対応づけて登録される。文書のメタ情報は、当該文書を管理するための各種の情報を含む。ハッシュ値は、文書管理ＤＢ１１０において電子文書又はメタ情報の検索キーとして機能する。SHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などの耐衝突性を持つ暗号学的ハッシュ関数を用いれば、電子文書又はメタ情報から実用上一意とみなし得るハッシュ値を生成することができる。
【００２８】
図３に、文書管理ＤＢ１１０が持つデータ内容の一例を示す。例示したように、例えば電子文書Ａはその電子文書Ａの内容に対してハッシュ関数ｈを適用して得られるハッシュ値ｈ（Ａ）をキーとして、電子文書Ａについてのメタ情報αは当該メタ情報αのハッシュ値ｈ（α）をキーとして、それぞれ文書管理ＤＢ１１０に登録される。
【００２９】
本実施形態では、文書のメタ情報のハッシュ値を、当該文書の識別子（文書識別子と呼ぶ）として用いる。すなわち、本実施形態では、文書の内容が同一であっても、文書が生成された時の環境（例えば操作の種別や、操作を指示したユーザなど）が異なれば、メタ情報が異なってくるので、文書識別子も異なった値となる。
【００３０】
ここで、文書のメタ情報について更に詳しく説明する。以下に、電子文書のメタ情報の一例を示す。この例は、メタ情報をＸＭＬ(eXtensible Markup Language)文書として記述した場合の例である。
【００３１】
［電子文書のメタ情報の例］
<doc>
<base>"base"</base>
<body>"body"</body>
<info>
<user> "user" </user>
<time> "time" </time>
<method> "method" </method>
<content-type> "content-type" </content-type>
</info>
</doc>
【００３２】
例示したメタ情報docは、base要素、body要素、及びinfo要素を含む。またinfo要素は、user要素、time要素、method要素、及びcontent-type要素を含む。
【００３３】
ここで、body要素は、当該電子文書のハッシュ値である（例えば、１６進符号化すればよい）。base要素は、当該電子文書の親の文書の文書識別子である。例えばある電子文書Ａに対し編集操作が施され、その結果として電子文書Ｂが生成された場合、電子文書Ｂのメタ情報のbase要素には、電子文書Ａの文書識別子の値が記載される。なお、文書管理サーバ１０に対して文書を新規に登録する場合には、親の文書が存在しないので、この場合にはbase要素は空となる。
【００３４】
method要素は、親の文書に対して適用された操作の種類を示す。method要素の値の具体例としては、read（閲覧された）,edited（編集された）,printed（印刷された）,copied（複写された）,scanned（読み取られた）,shredded（シュレッダーで細断された）等がある。user要素は当該操作の実行を命じたユーザの識別情報である。time要素は、当該操作の実行が命じられた時刻である。content-type要素は当該電子文書のコンテント型を示す。コンテント型は、例えばＰＤＦ(Portable Document File)など、当該電子文書を取り扱うアプリケーションを特定する情報である。
【００３５】
上述の例は、文書識別子"base"の文書Ａに対してユーザ"user"が時刻"time"において操作"method"を施したときに結果として得られる電子文書Ｂのハッシュ値が"body"で、その電子文書のコンテント型が"content-type"である場合に生成される、電子文書Ｂのメタ情報である。このメタ情報のハッシュ値が、電子文書Ｂの文書識別子となる。
【００３６】
以上、電子文書のメタ情報について説明した。次に紙文書のメタ情報について説明する。例えば電子文書の印刷や紙文書の複写のように、紙文書が出力される操作が行われたときに、その出力された紙文書に対応するメタ情報は、例えば以下のようなものとなる。
【００３７】
［紙文書のメタ情報の例］
<doc>
<base> "base" </base>
<body> "body" </body>
<media> "uri" </media>
<info>
<user> "user" </user>
<time> "time" </time>
<method> "method" </method>
<content-type> "content-type" </content-type>
<filename> "filename" </filename>
</info>
</doc>
【００３８】
この例において、上に例示した電子文書のメタ情報の要素と同名の要素は、同じ役割の要素である。紙文書ならではの要素としてmedia要素及びfilename要素がある。
【００３９】
media要素は、当該紙文書の媒体の識別子（媒体識別子と呼ぶ）である。
【００４０】
紙文書のメタ情報の場合、操作の結果が紙文書であり、操作の結果となる電子文書は存在しないので、body要素は空としてもよい。また、この代わりに、物理的な媒体に印刷される画像を表すデータ（例えばビットマップデータやページ記述言語データなど）を仮の操作結果とし、そのデータのハッシュ値をbody要素の値としてもよい。媒体識別子は、例えば、
［媒体識別子の例］
"urn:paper:efe3958b4b9da96eea9f4091e4c14ed46c14f620ca947dfa2d4169987556f657"
の様に指定できる。この例は、媒体識別子をURN(Uniform Resource Name)で表した例であり、"urn:"の後に続く"paper"は紙文書の名前空間を表す名前空間識別子である。"urn:paper:"の後から当該識別子の末尾までの文字列は、名前空間固有文字列NSS(Namespace Specific String)であり、紙文書の名前空間の中で、当該紙文書が印刷された媒体を一意に特定する文字列である。このURNにおけるNSSは何らかのメタ情報に対応するコンテクスト（すなわちメタ情報のハッシュ値）であってもよい。例えば、ある紙媒体が以下のようなＸＭＬ記述により一意に特定されるとする。
【００４１】
［紙媒体を一意に特定する記述の例］
<paper>
<company>Fuji Xerox Co., Ltd.</company>
<division>FXPAL Japan Corporate Research Group</division>
<serialnumber>829536</serialnumber>
...
</paper>
【００４２】
この記述例は、company要素で表される会社の中の、division要素で表される部署において、serialnumber要素で表される通し番号と、その他の情報により特定される紙媒体を表している。このような紙媒体を特定するＸＭＬ記述のハッシュ値を、その紙媒体を表す媒体識別子のNSSとして用いてもよい。
【００４３】
このような紙媒体を一意に記述する情報は、紙媒体のメタ情報として扱うことができる。このメタ情報が蓄積されたサーバにアクセスできる環境（例えばcompany要素で指定された会社の社内）では当該紙文書の出自を詳しく知ることができるが、NSSを"resolve"（この処理については後で説明する）できない環境（例えば当該会社の外）ではNSSは単なる識別子に過ぎなくなり、識別子の指す情報は隠蔽される。例えば、当該媒体識別子を持った紙に印刷された紙文書を参考資料として社外の取引先に提供したものとする。その後、その取引先を買収して社内の一部門になり、社内のサーバにアクセスできるような環境に変化した場合、いまや当該会社の社員となったかつての取引先ユーザもNSSの指すメタ情報を利用できるようになる。
【００４４】
媒体識別子は、例えば媒体に対してバーコード等のコード画像として印刷してもよい。コード画像の印刷は、紫外線又は赤外線により読み取れる不可視のインク又はトナーにより印刷してもよい。また、媒体識別子は、媒体に装着されているＲＦＩＤ(Radio Frequency IDentifier)タグに書き込んでもよい。媒体識別子は、印刷前の媒体に対して予め印刷又は書き込まれていてもよいし、プリンタがその媒体に画像を印刷する際に併せて印刷してもよい。また、紙媒体の場合、上述のように媒体識別子を用紙に書き込む代わりに、個々の用紙に固有の微細な繊維構造又は微細な表面構造を表す紙指紋を読み取り、紙指紋を媒体識別子として用いてもよい。
【００４５】
なおmedia要素は、媒体識別子が得られる場合に記入すればよく、得られない場合は空でも構わない。
【００４６】
メタ情報中のfilename要素は、当該紙文書の親である電子文書のファイル名を表す要素である。例えば、電子文書を印刷する場合など、電子文書に対する操作の結果として紙文書が出力される場合に、その電子文書のファイル名をfilename要素として記録するのである。filename要素に記録するファイル名は、拡張子付きでも、拡張子を除去したものでもよい。このように、紙文書の元になった電子文書のファイル名を記録しておけば、当該紙文書を再度電子化した際にその名前が利用できるので便利な場合もある。例えば、電子文書を印刷して得られた紙文書をスキャンした場合に、スキャン結果のファイルに対し、元の電子文書の識別名に由来する名前をつけることができる。
【００４７】
以上では、文書のメタ情報について例示したが、電子文書の集まり（コレクション）を表現するフォルダ（或いはディレクトリ）についても、同様にメタ情報を定義することができる。フォルダのメタ情報は、フォルダの内容を記述した以下に例示するようなフォルダ内容記述（すなわちfolder要素）の値のハッシュ値をbody要素の値として持つ。
【００４８】
［フォルダ内容記述の例］
<folder>
<file
name="fe04-05515.pdf.yui"
created="2006/03/10 20:17:16"
modified="2006/03/10 19:55:03"
accessed="2006/03/10 20:19:53"
did="a4cf754a7efdd53825b5a108949ebd764fc3ff7bf6c3c7c25653bf824286d38a"
size="628260" />
<file
name="fe02-02232.pdf.yui"
created="2006/03/10 20:17:13"
modified="2006/03/10 20:02:00"
accessed="2006/03/10 20:19:46"
did="9ff47dc0ca7b68755735b4f415be11a380b2e1da1f9a61847dd0b524cd22ec8a"
size="156380"/>
</folder>
【００４９】
この記述例は、"fe04-05515.pdf "と"fe04-02232.pdf "という２つの電子文書を含むフォルダを表す。folder要素は、０以上のfile要素を含む。file要素は、フォルダ中の１つの電子文書に関する管理情報を表す。file要素におけるname要素は、当該電子文書に対応する参照情報ファイルのファイル名を示す。参照情報ファイルは、当該電子文書の文書識別子を内容として持つファイルであり、本システムでは電子文書そのものの代わりにシステム内を流通する。created要素、modified要素、accessed要素は、それぞれ当該電子文書の作成時刻、最新の更新時刻、及び最新のアクセス時刻を表す要素である。これら各時刻要素は、通常のファイルシステムがファイル管理において記録している情報と同様でよい。did要素は当該電子文書の文書識別子を表し、size要素は当該電子文書のデータサイズを表す。
【００５０】
フォルダのメタ情報のハッシュ値は、フォルダの識別子として用いられる。このフォルダ識別子を内容として持つファイルを、フォルダに対応する参照情報ファイルとして用いることができる。フォルダに対応する参照情報ファイルを持つユーザは、その参照情報ファイルを用いてサーバ１０にアクセスすることにより、上述のフォルダ内容記述を取得することができる。またユーザは、そのフォルダ内容記述に含まれる電子文書の文書識別子didを用いてサーバ１０にアクセスすることにより、当該電子文書の実体にアクセスすることができる。
【００５１】
例えば、上に例示したフォルダが含む二つの文書がある組織における非常に機密性の高い実在の文書であり、文書管理システムは組織の成員にしか利用できないように制限されているとする。この場合、組織の成員は、上記の文書識別子didを用いることでサーバ１０上の実在の文書にアクセスすることができるが、組織外のユーザはその文書識別子didが仮に分かったとしても、その文書についての情報を全く引き出すことができない。
【００５２】
上記の例ではフォルダを扱ったが、より一般に、複合要素から構成される任意のコンパウンドドキュメントも同様に扱うことができる。例えば、単純なケースでは、ＸＭＬ文書は木構造を持ち、各部分木自体もＸＭＬ文書と捉えることができるので、ＸＭＬ文書はコンパウンドドキュメントの一例である。この場合、DomHash（RFC2803で規定されている）を用いることにより、ＸＭＬ文書の木構造の部分木ごとに対して、それぞれ文書識別子を付与することもできる。
【００５３】
ＸＭＬ文書は可搬性を備えた文書フォーマットとして主流になりつつあるが、データ表現形式としては冗長なため、必要なデータ容量の増大を招いている。このようにＸＭＬ文書のDomHash値をそのＸＭＬ文書自体の識別子とすることによって、重複する要素を重複して保存することなく、また、データ交換の際に必要な部分木のみを交換することによって処理を効率化することもできる。またDomHash自体にＸＭＬ文書の木構造情報がそのまま保存されている為、従来のＸＭＬ文書処理では頻繁に行われていたＸＭＬ文書とＤＯＭ(Document Object Model)木との変換がある意味で不要となり、より処理が効率化される。
【００５４】
以上、文書管理ＤＢ１１０と、それに関連して文書及びフォルダのメタ情報について説明した。以上の例では、電子文書と、電子文書のメタ情報とが、共に文書管理ＤＢ１１０に登録されたが、電子文書とメタ情報とを別々のデータベースに登録してもよい。
【００５５】
再び図２に戻り、派生関係ＤＢ１２０について説明する。
【００５６】
派生関係ＤＢ１２０は、文書管理ＤＢ１１０に登録された文書間の派生関係を記録するデータベースである。文書管理ＤＢ１１０に登録された電子文書Ａに対し、操作が行われた結果電子文書Ｂが生成された場合、「電子文書Ａから電子文書Ｂが派生した」という。この場合電子文書Ａは電子文書Ｂの親である。このような電子文書間の親子関係のことを、ここでは派生関係と呼ぶ。派生関係は、親の電子文書の文書識別子と、子の電子文書の文書識別子のペアで表現することができる。
【００５７】
派生関係ＤＢ１２０が持つデータ内容の例を図４に示す。この例では、派生関係ＤＢ１２０には、電子文書毎に、その電子文書の文書識別子（キー）に対応づけて、その電子文書から派生した子文書の文書識別子のリストが登録されている。前述したように、電子文書Ａの文書識別子は、当該電子文書Ａのメタ情報αのハッシュ値ｈ（α）である。なお、電子文書のメタ情報にはその電子文書の親の文書識別子がbase要素として含まれるので、メタ情報を蓄積した文書管理ＤＢ１１０だけあれば、原理的には電子文書間の派生関係を求めることができる。ただ、本実施形態では処理の効率等の観点から、親から子への派生関係のみを抽出してまとめた派生関係ＤＢ１２０を構築している。
【００５８】
ここで、本実施形態における電子文書、メタ情報、及び参照情報ファイルの関係を概括しておく。図５に示すように、電子文書３００が文書管理サーバ１０に新規登録された場合、その電子文書３００の内容Ａ０のハッシュ値ｈ（Ａ０）をbody要素とするメタ情報３１０が生成される。新規登録された文書の場合、base要素は空である。このメタ情報３１０の内容がα０であるとすると、電子文書３００に対応する文書識別子はｈ（α０）である。この文書識別子ｈ（α０）を内容として含む参照情報ファイル３２０が、電子文書３００の代わりにシステム内を流通する。参照情報ファイル３２０を入手したユーザは、クライアント２０が備える所定の文書処理プログラムでその参照情報ファイル３２０を開くことで、電子文書３００の内容をサーバ１０から取得し、編集その他の操作を加えることができる。この操作の結果、電子文書の内容がＡ０からＡ１へと変わったとする。その操作の後、内容Ａ１を持つ電子文書３３０がクライアント２０の文書処理プログラムからサーバ１０に登録される。このとき、電子文書３３０のメタ情報３４０もサーバ１０に登録される。メタ情報３４０は、親文書を表すbase要素として電子文書３００の文書識別子ｈ（α０）を有し、文書実体を示すbody要素として電子文書３３０のハッシュ値ｈ（Ａ１）を含む。このメタ情報３４０の内容α１のハッシュ値ｈ（α１）が、電子文書３３０の文書識別子となり、電子文書３３０に対応する参照情報ファイル３５０に含まれることとなる。
【００５９】
以上に説明した文書管理ＤＢ１１０（記憶Ｔ）と派生関係ＤＢ１２０（記憶Ｕ）の関係は、例えば以下のように説明される。暗号学的ハッシュ関数ｈを選択する。以下、自由長のオクテット列をデータ、ｈのハッシュ値長のオクテット列をコンテクストと呼ぶ。データｘに対してコンテクストξがｈ（ｘ）=ξのとき、コンテクストξはデータｘに対応していると言う。データ全体の集合をＤ、コンテクスト全体の集合をＣと書くこととする。サーバ１０は記憶Ｔ及び記憶Ｕを持つ。記憶Ｔはコンテクストをキーとし、そのキーに対応する値としてデータを持つ。記憶Ｕはコンテクストをキーとし、そのキーに対応する値としてコンテクストの集合を持つ。ここで、Ｔ[ξ]=ｘ（すなわちＴにおけるキーξに対応する値がｘである）、Ｕ[ξ]=Ｙ（すなわちＵにおけるキーξに対応する値が集合Ｙである）とする。この場合、ｈ（ｘ）=ξであり、集合Ｙの任意の要素ηに対して、ηはＴのキーとして存在し、Ｔ[η]はbase要素を含むメタ情報であって、base要素の内容としてξ（例えばその１６進表現）を含む。つまりＹはξの‘子’の集合である。
【００６０】
以上の説明では、Ｔ[η]の要素をＸＭＬ文書であるメタ情報としているが、ＸＭＬ文書の代わりにメタ情報のＸＭＬ文書に対応するDomHash値とすることも可能である。ＸＭＬ文書の場合にはコンテクストの１６進表現を用いたが、DomHash値を用いる場合にはコンテクストそのものを利用することができる。記憶Ｔ及び記憶Ｕは、ＬをＤのある有限部分集合（つまりオクテット上の有限言語）として、写像Ｔ：ｈ（Ｌ）→Ｌ，Ｕ：ｈ（Ｌ）→２Ｃと見なせる（つまりＬが十分小さい（例えばSHA-256では基数が高々２１２８ 程度）場合、Ｌの上ではｈは単射と見なせるから。ここで２ＣはＣの部分集合全体の集合を表す）。この事実に基づいてｈ（ｘ）をデータｘのコンテクストと呼ぶ。記憶ＴおよびＵの具体的な実装はハッシュテーブルとして与えられるので検索に要する時間計算量はＯ（１）である。また、ストレージに同一データの冗長な保存が決して発生しないというメリットもある。また、サーバ１０をネットワーク上の分散サーバとして実現した場合においても、例えば、Chordのような分散ハッシュテーブルに基づいた場合、検索に要する時間計算量はＯ（ｌｏｇ ｎ）であり（ｎはノード数）、ネットワークのメンテナンスコスト（ルーティングテーブルの更新）もＯ（ｌｏｇ２ ｎ）であり非常に効率的であるためスケーラビリティがある。（サーバ１０を分散サーバとして構成した場合については、後で更に説明する。）
【００６１】
以上、サーバ１０の文書管理ＤＢ１１０及び派生関係ＤＢ１２０について説明した。再び図２の説明に戻ると、サーバ１０は、クライアント２０との間での相互作用のための処理を行うクライアントＩＦ部１３０を備える。クライアントＩＦ部１３０は、後述するクライアント装置２０のサーバＩＦ部２１８との間で通信し、後述する"bind"，"resolve"，"exist? "，"delete"等の基本処理を実行する。これら各基本処理の内容については、後で詳しく説明する。
【００６２】
またサーバ１０は、派生関係生成部１４０を備える。派生関係生成部１４０は、電子文書同士の派生関係の木構造を示した派生関係表示情報を生成する。派生関係生成部１４０の処理は、後で詳しく説明する。
【００６３】
以上、サーバ１０の構成の例について説明した。次に、クライアント２０の構成の例について、図６を参照して説明する。
【００６４】
図６に示すように、クライアント２０は情報処理部２００を備え、情報処理部２００は文書処理部２１０，１以上のアプリケーション２３０及びファイルシステム２４０を備える。情報処理部２００は、オペレーティングシステムにより制御されるコンピュータである。文書処理部２１０は、上述した参照情報ファイルを用いた文書の取り扱い管理を行うための処理ユニットであり、上述した「文書処理プログラム」に該当する。情報処理部２００については、後で詳しく説明する。アプリケーション２３０は、電子文書の生成又は編集、電子的な複写、印刷指示など電子文書についての処理を実行する。プリンタ２５０を制御するプリンタドライバ、又はスキャナ２６０を制御するスキャナドライバなどのドライバプログラムを、アプリケーション２３０の一種とみなしてもよい。ファイルシステム２４０は、情報処理部２００のオペレーティングシステムの一要素であり、ファイル群を管理する。アプリケーション２３０及びファイルシステム２４０は、本実施形態の方式に直接関係するものではなく、従来からあるものでよい。
【００６５】
クライアント２０は、プリンタ２５０、スキャナ２６０及びスキャナ付きシュレッダ２７０のうちの１以上を備えていてもよい。プリンタ２５０及びスキャナ２６０は従来から存在するものでよい。スキャナ付きシュレッダ２７０は、紙文書から文書識別子コードを読み取るためのスキャナを備える。スキャナ付きシュレッダ２７０については、後で詳しく説明する。
【００６６】
本実施形態のクライアント２０は、様々な態様の装置であり得る。例えば、クライアント２０は、プリンタ２５０、スキャナ２６０及びスキャナ付きシュレッダ２７０のいずれも持たない情報処理部２００のみを備えるものであってもよい。例えばクライアント２０がパーソナルコンピュータである場合が、その一例である。また、クライアント２０がいわゆるデジタル複合機である場合、クライアント２０は情報処理部２００とプリンタ２５０とスキャナ２６０を備える。また、クライアント２０がシュレッダ装置である場合、クライアント２０は情報処理部２００とスキャナ付きシュレッダ２７０を備える。なお、クライアント２０は、プリンタ２５０、スキャナ２６０及びスキャナ付きシュレッダ２７０以外にも、紙文書を取り扱う装置を備えていてもよい。
【００６７】
次に、文書処理部２１０について説明する。文書処理部２１０は、ＵＩ（ユーザインターフェイス）部２１２，メタ情報生成部２１４，ハッシュ計算部２１６，サーバＩＦ部２１８，参照情報生成部２２０，操作管理部２２２，紙文書管理部２２４，アクセス禁止処理部２２６，派生関係表示処理部２２８を備える。
【００６８】
ＵＩ部２１２は、文書処理部２１０に対する操作指示のためのＵＩ画面を生成し、クライアント２０のオペレーティングシステムを介して画面に表示する。ＵＩ部２１２が提供するＵＩ画面には、例えば、参照情報ファイルの生成や、参照情報ファイルについてのアクセス禁止処理、派生関係表示処理などといった、参照情報ファイルに関係する処理のための操作メニューが表示される。メタ情報生成部２１４は、上述した電子文書のメタ情報を生成する。
【００６９】
メタ情報生成部２１４は、メタ情報の生成にあたり、操作を行ったユーザの識別情報や時刻、コンテント型、ファイル名などの情報をオペレーティングシステムから取得し、操作結果の電子文書のハッシュ値をハッシュ計算部２１６から取得する。親文書の文書識別子は、操作のために開かれた参照情報ファイルから取得することができる。取得した親文書の文書識別子は、base要素の値として組み込まれる。また、プリンタ２５０又はスキャナ２６０又はスキャナ付きシュレッダ２７０などが備える読取装置が、媒体に書き込まれた媒体識別子のコード画像、又は媒体に付属するＲＦＩＤタグに記憶された媒体識別子、又は媒体の紙指紋を読み取り、その結果得られた媒体識別子をメタ情報生成部２１４がメタ情報に組み込んでもよい。また、プリンタ２５０が用紙に対して媒体識別子のコード画像を印刷する場合、メタ情報生成部２１４がその媒体識別子を取得し、メタ情報に組み込んでもよい。
【００７０】
ハッシュ計算部２１６は、電子文書又はメタ情報など、対象となるデータについて、本システムで採用している所定の暗号学的ハッシュ関数を用いて、ハッシュ値を計算する。
【００７１】
サーバＩＦ部２１８は、サーバ１０のクライアントＩＦ部１３０と通信し、参照情報ファイルについての基本処理、すなわち"bind"，"resolve"，"exist?"，"delete"を実行する。
【００７２】
ここで、これら個々の基本処理の流れを説明する。まず図７を参照して"bind"処理の流れを説明する。"bind"処理は、電子文書又はそのメタ情報をクライアント２０からサーバ１０に登録する処理である。この処理は、登録対象のデータ実体ｘ（電子文書又はメタ情報）を入力とし、そのデータｘのハッシュ値（コンテクスト）ξを出力とする。
【００７３】
クライアント２０のサーバＩＦ部２１８は、データｘを対象とする"bind"処理（すなわちbind(ｘ)）の実行を指示された場合、ハッシュ計算部２１６にデータｘのハッシュ値を計算させ、その計算結果ξを受け取って、その処理の出力データとして出力する（Ｓ１）。また、サーバＩＦ部２１８は、ハッシュ値ξを対象として"exist? "処理を実行する（Ｓ２）。"exist? "処理の手順については、後で詳しく説明する。"exist? "処理の結果が得られると、サーバＩＦ部２１８は、その結果に基づき、ξが既にサーバ１０上に存在しているか否かを判定し（Ｓ３）、存在していなければ、（ξ，ｘ）（すなわちデータｘとそのハッシュ値ξのペア）を含む"bind"メッセージをサーバ１０宛に送る（Ｓ４）。存在していれば、ステップＳ４はスキップされ、"bind"処理は終了する。
【００７４】
サーバ１０のクライアントＩＦ部１３０は、その"bind"メッセージを受信し（Ｓ５）、文書管理ＤＢ１１０に対して、ハッシュ値ξをキーとしてデータｘを登録する（Ｓ６）。
【００７５】
次に、図８を参照して、"resolve"処理の流れを説明する。"resolve"処理は、ハッシュ値ξを入力とし、そのξに対応するデータ実体ｘ（電子文書又はメタ情報）を求める処理であり、その処理の出力はそのデータ実体ｘである。
【００７６】
クライアント２０のサーバＩＦ部２１８は、ハッシュ値ξを対象とする"resolve"処理の実行を指示された場合、ξを引数として含む"resolve"メッセージをサーバ１０に送信する（Ｓ１１）。サーバ１０では、クライアントＩＦ部１３０が、その"resolve"メッセージを受信し（Ｓ１２）、そのメッセージの引数ξをキーとして文書管理ＤＢ１１０を検索する（Ｓ１３）。その検索の結果、文書管理ＤＢ１１０にξをキーとするエントリが存在するか否かを判定し（Ｓ１４）、存在すれば、クライアントＩＦ部１３０は、そのξに対応するエントリ内のデータ実体ｘをクライアント２０に返す（Ｓ１５）。クライアント２０のサーバＩＦ部２１８は、サーバ１０から返されてきたデータ実体ｘを受信し、これを"resolve"処理の結果として出力する（Ｓ１６）。なお、ステップＳ１４でξが存在しないと判定された場合は、クライアントＩＦ部１３０は、問合せ対象のキーが存在しない旨を示す例外コードをクライアント２０に返す（Ｓ１７）。クライアント２０のサーバＩＦ部２１８は、その例外コードを受け取った場合には、その例外コードに応じた所定のエラー処理を実行する（Ｓ１８）。
【００７７】
次に、図９を参照して、"exist? "処理の流れを説明する。"exist? "処理は、ハッシュ値ξを入力とし、そのξに対応するデータ実体ｘ（電子文書又はメタ情報）がサーバ１０に登録済みであるかどうかを判定する処理であり、その処理の出力はその判定結果を示すブール値（「true(存在する)」又は「false(存在しない)」）である。
【００７８】
クライアント２０のサーバＩＦ部２１８は、ハッシュ値ξを対象とする"exist? "処理の実行を指示された場合、ξを引数として含む"exist? "メッセージをサーバ１０に送信する（Ｓ２１）。サーバ１０では、クライアントＩＦ部１３０が、その"exist? "メッセージを受信し（Ｓ２２）、そのメッセージの引数ξをキーとして文書管理ＤＢ１１０を検索する（Ｓ２３）。その検索の結果、文書管理ＤＢ１１０にξをキーとするエントリが存在するか否かを判定し（Ｓ２４）、存在すれば、クライアントＩＦ部１３０は、ブール値ｂの値を"true"にセットし（Ｓ２５）、存在しなければ"false"にセットする（Ｓ２６）。その後、クライアントＩＦ部１３０は、そのブール値をクライアント２０に返す（Ｓ２７）。クライアント２０のサーバＩＦ部２１８は、その返り値ｂを"exist? "処理の結果として出力する（Ｓ２８）。
【００７９】
次に、図１０を参照して、"delete"処理の流れを説明する。"delete"処理は、削除対象のデータのハッシュ値ξを入力とし、そのハッシュ値ξに対応するデータｘをサーバ１０から削除する処理である。
【００８０】
クライアント２０のサーバＩＦ部２１８は、ハッシュ値ξを対象とする"delete"処理の実行を指示された場合、ハッシュ値ξを対象として"exist? "処理を実行する（Ｓ３１）。"exist? "処理の結果として返り値ｂが得られると、サーバＩＦ部２１８は、その返り値が"true"であるか否かを判定し（Ｓ３２）、"true"（すなわち「ξがサーバ１０に存在する」）であれば、ξを引数として含む"delete"メッセージをサーバ１０宛に送る（Ｓ３３）。"true"でなければ、ステップＳ３３はスキップされ、"delete"処理は終了する。
【００８１】
サーバ１０のクライアントＩＦ部１３０は、クライアント２０から"delete"メッセージを受信すると（Ｓ３４）、文書管理ＤＢ１１０から、ハッシュ値ξをキーとするエントリを削除する（Ｓ３５）。これにより、ハッシュ値ξに対応するデータ実体ｘが文書管理ＤＢ１１０から削除される。
【００８２】
以上、サーバＩＦ部２１８の説明と併せて、各基本処理の手順を説明した。これら基本処理のうち"delete"処理がなくてもシステムは成立する。また、"exist?"処理は必ずしも必要ではない。"exist?"処理は冗長なデータ転送を発生させないという効果のためのものである。
【００８３】
次に、再び図６に戻り、参照情報生成部２２０について説明する。参照情報生成部２２０は、クライアント２０のファイルシステム２４０内の電子文書（ファイル）又はフォルダに対応する参照情報ファイルを生成する。まず、電子文書の参照情報ファイルを生成する場合の手順を、図１１を参照して説明する。
【００８４】
例えばＵＩ部２１２に対してユーザが、対象の電子文書を指定して、その電子文書についての参照情報ファイルの生成を指示した場合（Ｓ４１）、参照情報生成部２２０が起動される。ここでは、一例として、指定された対象の電子文書のファイル名が"foo.doc"であるとする。参照情報生成部２２０は、サーバＩＦ部２１８に対し、その電子文書の内容"foo.doc"を対象とする"bind"処理を依頼する（Ｓ４２）。そして、参照情報生成部２２０は、その"bind"処理の出力であるハッシュ値をbody要素の値として含むメタ情報（仮にその名前を"doc"とする）の生成を、メタ情報生成部２１４に依頼する（Ｓ４３）。そして、メタ情報生成部２１４からメタ情報"doc"を受け取ると、参照情報生成部２２０は、そのメタ情報"doc"についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ４４）。そして、参照情報生成部２２０は、その"bind"処理の出力であるハッシュ値を内容とする参照情報ファイルを生成する（Ｓ４５）。この例では、生成された参照情報ファイルに対し、元の電子文書のファイル名"foo.doc"の文字列の後に所定の拡張子（この例では".yui"）を追加したファイル名を付与している。すなわち、参照情報ファイルのファイル名の中には、元の電子文書のファイル名の情報が残る。なお、追加する拡張子".yui"はあくまで一例に過ぎない。
【００８５】
図１１の処理手順では、"bind"処理が行われるので、対象として指定された電子文書とそのメタ情報とが、サーバ１０に登録されることになる。すなわち、参照情報ファイルの生成処理は、サーバ１０に対して新規な電子文書を登録する処理と捉えることもできる。すなわち、クライアント２０にある電子文書は、この参照情報ファイルの生成処理により、本実施形態のシステムの中に組み込まれることになる。組み込まれた後は、その電子文書は、参照情報ファイルの形で各ユーザ間を流通することになる。
【００８６】
次に、図１２を参照して、フォルダに対応する参照情報ファイルの生成手順を説明する。ＵＩ部２１２に対しユーザが対象となるフォルダ（ここでは仮にそのフォルダの識別名を"bar"とする）を指定し、参照情報ファイルの生成を指示すると（Ｓ５１）、参照情報生成部２２０は、そのフォルダ"bar"内に含まれる要素（すなわち電子文書又はフォルダ）毎に、その要素に対応する参照情報ファイルの生成処理を再帰的に実行する（Ｓ５２）。要素が電子文書であれば、参照情報処理部２２０は、その電子文書を対象に図１１の手順を実行する。要素がフォルダであれば、参照情報処理部２２０は、そのフォルダを対象に、この図１２の手順を実行する。フォルダ"bar"内のすべての要素についての参照情報ファイルが生成されると、参照情報処理部２２０は、それら各参照情報ファイルの情報に基づき、フォルダ"bar"の内容を表すフォルダ内容記述（ここでは仮にその名前を"folder"とする）を生成する（Ｓ５３）。フォルダ内容記述については既に説明したが、そのうち各ファイルのname要素は、当該ファイルの参照情報ファイルのファイル名であり、did要素は当該参照情報ファイルの内容であるハッシュ値である。他の要素は、ファイルシステム２４０が管理するファイルの属性情報である。そして、参照情報生成部２２０は、そのフォルダ内容記述"folder"についての"bind"処理を、サーバＩＦ部２１８に依頼する（Ｓ５４）。そして、参照情報生成部２２０は、その"bind"処理の出力値をbody要素として含むメタ情報"doc"（これはフォルダ"bar"のメタ情報である）の生成をメタ情報生成部２１４に依頼し（Ｓ５５）、その結果得られたメタ情報"doc"についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ５６）。そして、参照情報生成部２２０は、その"bind"処理の出力値を内容として持つ参照情報ファイルを生成する（Ｓ５７）。生成された参照情報ファイルには、元のフォルダの名前"bar"の後ろに、所定の拡張子（図示例では".ber"）を付加したファイル名が付与される。拡張子".ber"はあくまで一例である。
【００８７】
以上のような処理により生成された参照情報ファイルは、ファイルシステム２４０における単なるファイルに過ぎないので、通常のファイルに対して実行可能な操作をすべて実行できる。また、例えば、電子メールに対して参照情報ファイルを添付し、送信することもできる。ファイルやフォルダがいかにサイズの大きなデータであったとしても、参照情報ファイルはハッシュ値を内容とするものなので、ファイルサイズは非常に小さい所定値である。例えばSHA-256を用いた場合、参照情報ファイルのファイルサイズは３２バイトに過ぎない。したがって、巨大なフォルダを知人に渡す場合も、電子メールの添付ファイルのデータ量を気にする必要はない。また、誤ってあるいは故意にこれらの参照情報ファイルが、本システムがカバーするドメインの外に送信されてしまったとしても、ドメイン外ではサーバ１０にアクセスできないか、またはクライアント２０が参照情報ファイルを取り扱う文書処理部２１０を持たないので、参照情報ファイルに対応するデータ実体を入手することはできない。
【００８８】
以下、参照情報ファイルに固有の操作について説明する。以下に説明する固有の操作は、操作管理部２２２の管理の下で実行される。
【００８９】
まず、図１３を参照して、アプリケーション２３０による電子文書の操作が指示された場合の手順の例を説明する。この手順では、ＵＩ部２１２に対しユーザから、対象となる電子文書の参照情報ファイル（仮にそのファイル名が"foo.doc.yui"であるとする）の操作の実行が指示されると（Ｓ６１）、操作管理部２２２は、その参照情報ファイルの内容である文書識別子did1を記憶する（Ｓ６２）。ステップＳ６１における操作の指示は、例えば、その参照情報ファイルのアイコンをダブルクリックすることにより行われる。また、操作管理部２２２は、文書識別子did1についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ６３）、その結果としてメタ情報"doc"を取得する（Ｓ６４）。操作管理部２２２は、そのメタ情報のbody要素の値についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ６５）、その結果として電子文書"foo.doc"の内容を取得する（Ｓ６６）。操作管理部２２２は、取得したファイル内容を含んだテンポラリファイルを作成し（Ｓ６７）、そのテンポラリファイルの操作をアプリケーション２３０に委譲する（Ｓ６８）。操作を委譲するアプリケーション２３０としては、電子文書の拡張子（この例では".doc"）に対応するアプリケーション２３０が選ばれる。これにより、操作を委譲されたアプリケーション２３０が、そのテンポラリファイルを開き、ユーザの操作を受け付ける。操作管理部２２２は、アプリケーション２３０がテンポラリファイルを閉じるのを待つ（Ｓ６９）。テンポラリファイルが閉じられたのを検知すると、操作管理部２２２は、その時点のテンポラリファイルの内容についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ７０）。これにより、操作後のテンポラリファイルの内容が、元の電子文書の内容から変化していれば、そのテンポラリファイルの内容がサーバ１０に登録される。そして、操作管理部２２２は、その"bind"処理の出力値ξをbody要素とし前述のdid1をbase要素として含んだメタ情報の生成をメタ情報生成部２１４に依頼し、その結果得られたメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ７１）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を、派生関係ＤＢ１２０に登録する（Ｓ７２）。ここで、生成されるメタ情報のうち、method要素の値は、例えば、閉じられたときのテンポラリファイルの内容が、元の電子文書の内容から変化していれば"edited（編集された）"であり、変化していなければ" read（閲覧された）"とすればよい。そして、操作管理部２２２は、操作対象の参照情報ファイル"foo.doc.yui"の内容をその"bind"処理の出力値に書き換え（Ｓ７３）、テンポラリファイルを削除する（Ｓ７４）。以上の処理手順によれば、参照情報ファイルに対応する電子文書は、クライアント２０のファイルシステム２４０内には残らない。
【００９０】
このような処理において、アプリケーションに操作が委譲されたテンポラリファイルは、当該アプリケーション以外のプロセスからのアクセスを拒むようにしてもよい。これは、例えば、操作管理部２２２が、オペレーティングシステムに対する各プロセスからのシステムコールを監視し、その監視によりテンポラリファイルに対して当該アプリケーション以外のプロセスからアクセスが要求されたことを検知した場合、その要求を拒絶するように制御すればよい。また、当該アプリケーションが操作の委譲されたテンポラリファイル以外のファイルの生成又は書き込みはできないように制御してもよい。このような制御のためには、例えば、当該アプリケーションからのオペレーティングシステムへのシステムコールの監視により、テンポラリファイル以外のファイルに対する操作が要求されたことを検知した場合、その要求を拒絶すればよい。
【００９１】
次に、フォルダに対する操作が指示されたときの、操作管理部２２２の処理手順を、図１４を参照して説明する。
【００９２】
この手順では、ＵＩ部２１２に対しユーザから、対象となるフォルダの参照情報ファイル（仮にそのファイル名が"bar.ber"であるとする）の操作の実行が指示されると（Ｓ８１）、その参照情報ファイルに含まれる識別子did1についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ８２）、その結果としてフォルダ"bar"のメタ情報"doc"を取得する（Ｓ８３）。操作管理部２２２は、そのメタ情報のbody要素の値についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ８４）、その結果としてフォルダ"bar"のフォルダ内容記述"folder"を取得する（Ｓ８５）。操作管理部２２２は、取得したフォルダ内容記述"folder"に基づき、フォルダ"bar"の内容を示すフォルダ画面を生成し、表示する（Ｓ８６）。フォルダ画面は、例えばフォルダ"bar"内のフォルダと電子文書のアイコンを列挙表示したものでよい。フォルダ内容記述"folder"には、フォルダ"bar"内の電子文書及びフォルダの参照情報ファイル及び識別子(did要素)の情報が含まれるので、それら電子文書及びフォルダの参照情報ファイルを示すアイコンを列挙表示したフォルダ画面を生成することができる。参照情報ファイルのアイコンには、対応する電子文書又はフォルダを表す。例えば参照上ファイルのアイコンには、対応する電子文書又はフォルダの名前を対応づけて表示することができる。
【００９３】
操作管理部２２２は、フォルダ画面に表示した参照情報ファイルに対するユーザからの操作指示を受け付け、その操作を実行する（Ｓ８７）。ここで、操作の対象としてユーザが指定した参照情報ファイルが電子文書に対応するものである場合には、操作管理部２２２は、その参照情報ファイルを対象として、図１３の処理手順を実行する。操作の対象としてユーザが指定した参照情報ファイルがフォルダに対応するものである場合には、操作管理部２２２は、その参照情報ファイルを対象として、この図１４の処理手順を再帰的に実行する。なお、図示例では、ステップＳ８７で、参照情報ファイルＸに対する操作が指示されたとする。操作管理部２２２は、参照情報ファイルＸに対する操作の終了を監視する（Ｓ８８）。その操作が終了すると、参照情報ファイルＸの値は、元の値から変化している。操作管理部２２２は、その参照情報ファイルＸの値の変化に応じて、フォルダ"bar"のフォルダ内容記述を作成する（Ｓ８９）。参照情報ファイルＸに操作が行われた場合、参照情報ファイルＸの内容である識別子didは元から変化し、また更新日や最終アクセス日の情報も変化しているので、ステップＳ８９では、それら変化を反映したフォルダ内容記述が生成される。なお、参照情報ファイルＸに対する操作が終了した時点では、フォルダ画面上の参照情報ファイルＸ以外の要素についての識別子や更新日などの情報に変化はない。操作管理部２２２は、ステップＳ８９で作成されたフォルダ内容記述についての"bind"処理をサーバＩＦ部２１８に依頼し（Ｓ９０）、その"bind"処理の出力値をbody要素として含むフォルダ"bar"のメタ情報を生成し、そのメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ９１）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ９２）。そして操作管理部２２２は、参照情報ファイル"bar.ber"の内容を、その"bind"処理の出力値へと書き換える（Ｓ９３）。
【００９４】
以上ではフォルダに対応する参照情報ファイルに対する操作について説明した。シェルの名前空間拡張を実装することで、以上の処理手順を、”C:/DocumentsandSettings/terao/MyDocuments.ber/bar/sample.txt”のようなＵＣＮ（ユニバーサル文字名）による指定に対しても割り当てることができる。この例では、”MyDocument.ber”以下はファイルシステム上のフォルダやファイルではなく、仮想的なフォルダや電子文書を示す参照情報ファイルで構成されている。
【００９５】
このように構成すれば、例えば、複雑なアプリケーションのインストールディレクトリを持ち運ぼうとした場合に、そのディレクトリの参照情報ファイルを生成することで、持ち運びが容易になる。例えば、TeXの操作環境一式のインストールディレクトは様々なアプリケーションやライブラリ、各種クラスファイルやフォントデータなどの多数のファイル・フォルダから構成され、そのデータ量は例えば数百Ｍバイトにも達する。ところが、このディレクトリの参照情報ファイルは、SHA-256を用いた場合には、例えば３２バイトのデータとなる。普段、TeXの操作環境を利用しないユーザが一時的に利用する必要が生じた場合、このインストールディレクトリのフォルダリファレンスをメールで送付してもらいそのまま利用することができる。このようにして一種のThinclientのような運用が可能になる。さらに、このようなアプリケーションの利用方法では後述するようにフォルダリファレンスの所持者にはファイルの利用履歴が入手できるのでアプリケーションの従量課金が容易に行える。
【００９６】
次に、参照情報ファイル経由で電子文書を開いた状態で、その文書を印刷するケースを考える。印刷時の処理手順の例を図１５に示す。図１５の手順は、紙文書管理部２２４により実行される。
【００９７】
図１３の手順のステップＳ６１において参照情報ファイルが開かれ、その参照情報ファイルに対応する電子文書の内容を持つテンポラリファイルに対する操作が、ステップＳ６８でアプリケーション２３０に委譲されたとする。その後、テンポラリファイルが閉じられるまで、紙文書管理部２２４は、アプリケーション２３０に対しユーザからそのテンポラリファイルの印刷の指示があるか、監視する（Ｓ１０１）。印刷指示を検知すると、紙文書管理部２２４は、図１３のステップＳ６３で記憶した識別子did1をbase要素として含むメタ情報を生成し、そのメタ情報に対する"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１０２）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１０３）。ここで、そのメタ情報のbody要素は空でよい。また、印刷指示があると、その時点のテンポラリファイルに対応する印刷画像を記述した印刷画像データをアプリケーション２３０又はプリンタドライバが作成するが、その印刷画像データを"bind"処理し、その"bind"の出力値を前記メタ情報のbody要素としてもよい。印刷画像データは、プリンタ２５０が取り扱い可能なデータ形式のものであればよく、ページ記述言語で記述されたデータであってもビットマップ画像であってもよい。また前記メタ情報のuser要素やtime要素、filename要素などの値は、オペレーティングシステムから入手できる。またmethod要素の値は、この場合は"printed（印刷された）"である。そして紙文書管理部２２４は、その"bind"処理の出力値did2を表すコード画像を生成し、テンポラリファイルの印刷画像データに対して、そのコード画像の画像を埋め込む（Ｓ１０４）。ここで、コード画像は、文字列であってもよい。また、１次元バーコードや２次元バーコード、ＱＲコード（登録商標）などといったコードであってもよい。また、コード画像は透かしデータとして印刷画像に埋め込んでもよい。なお、この値did2は、印刷結果の紙文書の文書識別子として機能する。この文書識別子did2に対応するメタ情報には、その紙文書の元になった電子文書の文書識別子did1がbase要素として含まれている。紙文書管理部２２４は、このように識別子did2が埋め込まれた印刷画像データを、プリンタ２５０に渡して印刷させる（Ｓ１０５）。
【００９８】
次に、印刷時の処理手順の別の例を、図１６を参照して説明する。図１６の手順は、紙文書管理部２２４により実行される。対象となる電子文書を表すテンポラリファイルに対する操作が、図１３のステップＳ６８でアプリケーション２３０に委譲されたとする。その後、テンポラリファイルが閉じられるまで、紙文書管理部２２４は、アプリケーション２３０に対しユーザからそのテンポラリファイルの印刷の指示があるか、監視する（Ｓ１１１）。印刷指示を検知すると、紙文書管理部２２４は、アプリケーション２３０又はプリンタドライバが作成したそのテンポラリファイルの印刷画像データを対象として、サーバＩＦ部２１８に"bind"処理を依頼する（Ｓ１１２）。そして、この"bind"処理の出力値をbody要素として含み、図１３のステップＳ６３で記憶された識別子did1をbase要素として含むメタ情報を生成し、そのメタ情報に対する"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１１３）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１１４）。そして紙文書管理部２２４は、その"bind"処理の出力値did2を内容として含む参照情報ファイルを生成し、これをプリンタ２５０に送信する（Ｓ１１５）。この例では、プリンタ２５０も、文書処理部２１０と同等の機能を備える。プリンタ２５０は、受け取った参照情報ファイルの内容did2についての"resolve"処理を実行する（Ｓ１１６）。すると、サーバ１０からプリンタ２５０に対し、識別子did2に対応するメタ情報が提供される。プリンタ２５０は、そのメタ情報のbody要素に対して"resolve"処理を実行する（Ｓ１１７）。すると、サーバ１０からプリンタ２５０に対し、ステップＳ１１２でサーバ１０に登録された印刷画像データが提供される。プリンタ２５０は、ステップＳ１１７の処理により取得した印刷画像データをレンダリングして、印刷に使用可能なラスタ画像データを生成し（Ｓ１１８）、そのラスタ画像データに対し、識別子did2を表すコード画像を重畳し、重畳後の画像を媒体に印刷する（Ｓ１１９）。
【００９９】
図１６の処理手順を用いれば文書の印刷指示を行うクライアント２０からプリンタ２５０へのデータ送信量は削減される。同一文書を複数回印刷する場合や、さらに、印刷画像データが構造化されている場合、例えば印刷画像データがＸＭＬ文書として表現され、ＸＭＬ文書の文書識別子としてDomHashを用いた場合、さらにデータ送信量は削減される。既に印刷を指示したことのある文書コンポーネントの再送が避けられるためである。またさらにプリンタ２５０にキャッシュを持つようにすればサーバ１０からプリンタ２５０へのデータ送信量も削減される。さらにこれらキャッシュへのインターフェイスを"resolve"に限定すれば、キャッシュに蓄積されたデータのコンテクスト（ハッシュ値）を知らない悪意を持ったユーザがキャッシュのデータを取り出すことはできない。
【０１００】
次に、クライアント２０で紙文書の複写を行う場合の処理の流れを、図１７を参照して説明する。この処理は、紙文書管理部２２４により実行される（図６参照）。
【０１０１】
ユーザがスキャナ２６０に紙文書をセットし、情報処理部２１０に対して複製を指示すると、スキャナ２６０が紙文書を読み取り、その結果得られたスキャン画像が、情報処理部２００が備えるメモリ上に確保されたスキャン画像キュー（図示省略）に蓄積される（Ｓ１２１）。紙文書管理部２２４は、そのスキャン画像から、文書識別子のコード画像の抽出を試みる（Ｓ１２２）。その紙文書に本実施形態の方法に従って文書識別子のコード画像が埋め込まれていれば、紙文書管理部２２４は、その方法に従ってコード画像を抽出することができる。紙文書管理部２２４は、コード画像が抽出されたか否かを判定し（Ｓ１２３）、コード画像が抽出された場合は、紙文書管理部２２４はそのコード画像をデコードし、その値did1を認識する（Ｓ１２４）。これが、紙文書の文書識別子である。そして、スキャン画像からそのコード画像を除去し（Ｓ１２５）、コード画像除去後のスキャン画像に対する"bind"処理の実行をサーバＩＦ部２１８に依頼する（Ｓ１２６）。そして、その"bind"処理の出力値をbody要素として含み、元の紙文書の文書識別子did１をbase要素として含むメタ情報を生成する（Ｓ１２７）。このメタ情報は、これから出力される複製のメタ情報であり、元の紙文書の文書識別子を親の情報として含み、コード画像除去後のスキャン画像のハッシュ値（識別子）を当該複製の画像を示す情報として含んでいる。また、このメタ情報のmethod要素の値は、"copied（複製された）"となる。また、日時や複製を指示したユーザ名などの操作に関係する履歴項目の値は、オペレーティングシステムから入手され、time要素やuser要素などとして組み込まれる。紙文書管理部２２４は、そのメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１２８）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１２９）。そして、コード画像除去後のスキャン画像に対し、その"bind"処理の出力値did2を表すコード画像を重畳し、重畳後の画像をプリンタ２５０に印刷させる（Ｓ１３０）。値did2は、複製された紙文書の文書識別子として機能する。
【０１０２】
また、ステップＳ１２３でスキャン画像からコード画像が抽出されなかったと判定された場合は、ステップＳ１２４及びＳ１２５の処理はスキップされ、ステップＳ１２６に進む。この場合、ステップＳ１２７で作成されるメタ情報のbase要素は空となる。その他の処理は、コード画像が抽出された場合と同様でよい。
【０１０３】
上記の複製手順によれば、元の紙文書に埋め込まれていた文書識別子は、複製操作の情報を表すメタ情報から求められた新たな文書識別子に置換される。したがって、複数回の複製の連鎖に対しても、個々の複製操作のメタ情報を保存でき、後でそれら個々の複製を追跡することができる。
【０１０４】
また、サーバ１０に登録された電子文書を印刷して得られた紙文書を複製する場合、その紙文書に埋め込まれた文書識別子から派生関係を遡ることで、オリジナルの電子文書を特定することができる。特定されたオリジナルの電子文書の画像と複製対象の紙文書の画像の差から、オリジナルの電子文書の画像に対する書き込み（アノテーション）を分離してもよい。本システムで紙文書を複製した場合、紙文書を読み取った画像がサーバ１０に登録される。したがって、ある紙文書を複製して紙文書Ａが得られ、その紙文書Ａに対して書き込みが行われたものが更に複製された場合、複製出力された時点の紙文書Ａの画像はサーバ１０に蓄積されている（蓄積された画像データを１つの電子文書と捉えてもよい）ので、書き込み後の紙文書Ａの複写時に読み取った画像と、その複製時点の紙文書Ａの画像との差を書き込み内容として分離できる。そのようなケースではオリジナルの電子文書の画像に書き込み内容を重畳した画像を複写操作で出力される文書の画像とすることによって、複数回の複製の連鎖に対しても機能する。
【０１０５】
次に、クライアント２０で紙文書のスキャン（読取）を行う場合の処理の流れを、図１８を参照して説明する。この処理は、紙文書管理部２２４により実行される。
【０１０６】
ユーザがスキャナ２６０に紙文書をセットし、情報処理部２００に対してスキャンを指示すると、スキャナ２６０が紙文書を読み取り、その結果得られたスキャン画像が、情報処理部２００が備えるメモリ上に確保されたスキャン画像キューに蓄積される（Ｓ１３１）。紙文書管理部２２４は、そのスキャン画像から、文書識別子のコード画像の抽出を試みる（Ｓ１３２）。紙文書管理部２２４は、コード画像が抽出されたか否かを判定し（Ｓ１３３）、コード画像が抽出された場合は、紙文書管理部２２４はそのコード画像をデコードし、紙文書の文書識別子did1を認識する（Ｓ１３４）。次に紙文書管理部２２４は、その文書識別子についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ１３５）、その結果として得られた紙文書のメタ情報から、オリジナルの電子文書のファイル名（filename要素の値）を得る（Ｓ１３６）。紙文書管理部２２４は、スキャン画像からそのコード画像を除去し（Ｓ１３７）、コード画像除去後のスキャン画像に対する"bind"処理の実行をサーバＩＦ部２１８に依頼する（Ｓ１３８）。そして、その"bind"処理の出力値をbody要素として含み、紙文書の文書識別子did１をbase要素として含むメタ情報を生成する（Ｓ１３９）。このメタ情報は、これから生成されるスキャン画像ファイルのメタ情報であり、元の紙文書の文書識別子を親の情報として含み、コード画像除去後のスキャン画像のハッシュ値（識別子）を当該スキャン画像を示す情報として含んでいる。また、このメタ情報のmethod要素の値は、"scanned（スキャンされた）"となる。また、日時や複製を指示したユーザ名などの操作に関係する履歴項目の値は、オペレーティングシステムから入手され、time要素やuser要素などとして組み込まれる。紙文書管理部２２４は、そのメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１４０）。また、このときに生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１４１）。そして、"bind"処理の出力値did2を内容とする参照情報ファイルを生成する（Ｓ１４２）。ここで、ステップＳ１３６で取得した元の電子文書のファイル名に基づきスキャン画像ファイルのファイル名を作成してもよい。例えば、元の電子文書のファイル名に対し、スキャン画像ファイルのファイル形式に対応した拡張子（例えば".tif"など）を付加したものをスキャン画像のファイル名とするなどである。また、参照情報ファイルのファイル名は、スキャン画像ファイルのファイル名に対し、電子文書の参照情報であることを示す拡張子（例えば".yui"）を付加したものとしてもよい。参照情報ファイルは、例えばスキャン画像ファイルが保存されるフォルダに保存する。
【０１０７】
なお、ステップＳ１３３でスキャン画像からコード画像が抽出されなかったと判定された場合は、ステップＳ１３４〜Ｓ１３７の処理はスキップされ、処理はステップＳ１３８に進む。この場合、ステップＳ１３９で作成されるメタ情報のbase要素は空となる。また、スキャン画像ファイルには所定の規則に従ってファイル名を付与してもよい。例えば、スキャンを指示したユーザのユーザ名とスキャン操作の時刻とを順に並べた文字列に対し、スキャン画像ファイルの形式に対応する拡張子を付加したものを、ファイル名としてもよい。スキャン画像ファイルに対応する参照情報ファイルにはスキャン画像ファイルのファイル名の文字列に対し電子文書の参照情報であることを示す拡張子を付加したものとしてもよい。その他の処理は、コード画像が抽出された場合と同様でよい。
【０１０８】
通常、スキャンで生成されるスキャン画像ファイルは、あらかじめ設定された特定のフォルダに蓄積される。したがって、一般には、各ユーザは、そのスキャン画像ファイルを入手するにはその特定のフォルダにアクセスする必要がある。これに対し、本実施形態では、ユーザは文書の派生関係の木構造を参照できるので、スキャンした紙文書又はその祖先にあたる電子文書の参照情報ファイルを持つユーザは、その特定のフォルダへ明示的にアクセスしなくても、サーバ１０を介してそのスキャン画像ファイルが入手できる。スキャン画像が蓄積されるフォルダを一般に公開しないことによって、スキャン画像の暴露の機会を減らすことができる。
【０１０９】
次に、紙文書をクライアント２０のスキャナ付きシュレッダ２７０にかけて廃棄する場合の処理の流れを、図１９を参照して説明する。この処理は、紙文書管理部２２４により実行される。
【０１１０】
スキャナ付きシュレッダ２７０は、例えば紙を投入する投入口にスキャナが設けられ、破断される前にその紙の画像をそのスキャナにより読み取る。
【０１１１】
ユーザがスキャナ付きシュレッダ２７０に投入すると、スキャナが紙文書を読み取り（Ｓ１５１）、その結果得られたスキャン画像が、情報処理部２００が備えるメモリ上に確保されたスキャン画像キューに蓄積される（Ｓ１５２）。紙文書管理部２２４は、そのスキャン画像から、文書識別子のコード画像の抽出を試みる（Ｓ１５３）。紙文書管理部２２４は、コード画像が抽出されたか否かを判定し（Ｓ１５４）、コード画像が抽出された場合は、紙文書管理部２２４はそのコード画像をデコードし、紙文書の文書識別子did1を認識する（Ｓ１５５）。次に紙文書管理部２２４は、その文書識別子についての"resolve"処理をサーバＩＦ部２１８に依頼し（Ｓ１５６）、その結果として得られた紙文書のメタ情報から、オリジナルの電子文書のファイル名（filename要素の値）を得る（Ｓ１５７）。紙文書管理部２２４は、スキャン画像からそのコード画像を除去し（Ｓ１５８）、コード画像除去後のスキャン画像に対する"bind"処理の実行をサーバＩＦ部２１８に依頼する（Ｓ１５９）。そして、その"bind"処理の出力値をbody要素として含み、紙文書の文書識別子did１をbase要素として含むメタ情報を生成する（Ｓ１６０）。このメタ情報は、破棄された紙文書のメタ情報であり、元の紙文書の文書識別子を親の情報として含み、コード画像除去後のスキャン画像のハッシュ値（識別子）を、破棄された紙文書の画像を示す情報として含んでいる。また、このメタ情報のmethod要素の値は、"shredded（細断された）"となる。紙文書管理部２２４は、そのメタ情報についての"bind"処理をサーバＩＦ部２１８に依頼する（Ｓ１６１）。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する（Ｓ１６２）。
【０１１２】
なお、ステップＳ１５４でスキャン画像からコード画像が抽出されなかったと判定された場合は、ステップＳ１５５〜Ｓ１５８の処理はスキップされ、処理はステップＳ１５９に進む。この場合、ステップＳ１６０で作成されるメタ情報のbase要素は空となる。その他の処理は、コード画像が抽出された場合と同様でよい。
【０１１３】
以上に説明したように、紙文書管理部２２４は、印刷管理、スキャン管理、紙文書複製管理、及び紙文書廃棄管理の機能を備える。
【０１１４】
以上では、文書識別子がコード画像として紙文書に印刷される場合を例示したが、用紙がＲＦＩＤタグを備えている場合には、文書識別子をそのＲＦＩＤタグに書き込んでもよい。この場合、プリンタ２５０は、ＲＦＩＤタグに書き込みを行うライタを有していればよい。またスキャナ２６０は、ＲＦＩＤタグを読み取るリーダを有していればよい。シュレッダは、スキャナの代わりにＲＦＩＤタグリーダを有していればよい。
【０１１５】
このようにＲＦＩＤタグを用いる場合、紙文書の移動を検知するためにセキュリティゲート装置を設置してもよい。このセキュリティゲート装置は、ゲートを通過する紙文書のＲＦＩＤタグから文書識別子を読み取り、その文書識別子をbase要素として持つメタ情報を生成する。このメタ情報のmethod要素は、「ゲート通過」という操作を示す。ゲート内に入ったのか、ゲート外に出たのかといったように、更に詳細な操作を記録してもよい。time要素はその装置の時計から得ることができる。セキュリティゲート装置がユーザのＩＤカードを読み取る機能を持てば、読み取ったユーザＩＤをuser要素に記録することもできる。セキュリティゲート装置は、生成されたメタ情報を"bind"処理する。また、このときに、生じた派生関係（親，子）＝（新しいメタ情報のコンテクスト，did1）を派生関係ＤＢ１２０に登録する。これにより、ゲート通過についてのメタ情報がサーバ１０に蓄積される。
【０１１６】
次に、参照情報ファイルを用いた電子文書へのアクセス禁止処理について説明する。この処理は、アクセス禁止処理部２２６（図６参照）により実行される。
【０１１７】
ＵＩ部２１２に対してユーザが、参照情報ファイルを指定して、アクセス禁止を指示すると、アクセス禁止処理部２２６は、その参照情報ファイル内の文書識別子didを取り出し、didについての"delete"処理をサーバＩＦ部２１８に依頼する。これにより、文書識別子didに対応するメタ情報が文書管理ＤＢ１１０から削除される。
【０１１８】
このように構成すると、削除された参照情報ファイルに対応する文書から派生した文書に対応する参照情報ファイルの所持者は、派生関係の木構造において、削除された文書に対応するノード以前の文書へのアクセスができなくなる。
【０１１９】
また、さらに削除された参照情報ファイルから派生した文書の文書識別子didについての"delete"処理を再帰的にサーバＩＦ部２１８に依頼してもよい。こうすれば、アクセスが禁止された文書をルートとする部分木全体にアクセスできなくなる。このように構成すれば、例えば、特定の情報流通パスを通じて伝播したドキュメントを一斉にアクセス禁止にすることもできる。
【０１２０】
ただし、"delete"処理を用いた操作は深刻な副作用を及ぼす（例えば、参照情報ファイルの所持者が、参照情報ファイルを生成した者の意図とは独立に文書のアクセスを禁止してしまうことができる）ので、そのような操作が可能なユーザを限定してもよい。例えば、参照情報ファイルを作成したユーザだけが、その参照情報ファイルについてのアクセス禁止を指示できるようにしてもよい。このような制限は、例えばユーザ認証機構を設けることにより実現できる。
【０１２１】
次に、派生関係表示のための処理を、図２０を参照して説明する。この処理は、クライアント２０の派生関係表示処理部２２８と、サーバ１０の派生関係表示生成部１４０により実行される。
【０１２２】
ＵＩ部２１２に対し、ユーザから、対象とする参照情報ファイルを指定し、派生関係の表示が指示されると、派生関係表示処理部２２８は、その参照情報ファイルに含まれる文書識別子didを取り出し、そのdidを引数として含む派生関係表示要求をサーバ１０に送る。この要求を受け取ったサーバ１０の派生関係表示生成部１４０は、図２０に示す処理手順を実行する。
【０１２３】
すなわち、派生関係表示生成部１４０は、クライアント２０から受信した文書識別子didに対して"resolve"処理を実行し（Ｓ１７１）、その結果得られるメタ情報からbase要素を抽出する（Ｓ１７２）。抽出の結果、base要素が空であるか否かを判定し（Ｓ１７３）、空でなければ、そのbase要素の値に対して"resolve"処理を実行し（Ｓ１７４）、その結果得られるメタ情報からbase要素を抽出し（Ｓ１７５）、抽出されたbase要素が空であるか否かを判定する（Ｓ１７３）。ステップＳ１７４，Ｓ１７５は、派生関係を親へと１つ遡る処理である。ステップＳ１７３の判定結果が肯定（Ｙｅｓ）となるまで、ステップＳ１７３〜Ｓ１７５が繰り返される。ステップＳ１７３の判定結果が肯定となったことは、クライアント文書識別子didから派生関係の木構造を遡った結果その木構造の根ノードに到達したことを意味する。その場合、派生関係表示生成部１４０は、派生関係ＤＢ１２０を参照することで、その根ノードから派生する子孫ノードからなる木構造全体を求める（Ｓ１７６）。そして、その木構造全体を表す派生関係表示データを生成し、クライアント２０に返す（Ｓ１７７）。派生関係表示データは、例えばＨＴＭＬ文書として作成してもよい。クライアント２０の派生関係表示処理部２２８は、その表示データをレンダリングして派生関係のツリー表示画像を生成し、画面に表示する。
【０１２４】
派生関係表示データが表す表示画像４００の例を、図２１に模式的に示す。表示画像４００は、文書Ａ１に対応する参照情報ファイルを指定して派生関係表示が指示された場合の例である。派生関係表示生成部１４０は、文書Ａ１から派生関係を遡ることで、根ノードである文書Ａ０に到達し、その文書Ａ０から派生する文書Ａ１及び文書Ａ２、文書Ａ１から派生する文書Ａ３を派生関係ＤＢ１２０から求める。そして、それら各文書のアイコン４０２〜４０８を、その派生関係にしたがって配列し、派生関係をエッジで結んで表示した木構造表示を生成する。各アイコン４０２〜４０８には、ファイル名、当該文書が生成された際の操作の種類、その操作を指示したユーザの識別名、その操作の日時、等と行った履歴情報を表示してもよい。このような履歴情報は、各文書に対応するメタ情報から取得できる。また、対象として指示された参照情報ファイルに対応するアイコン４０４は、他のアイコンと区別できる表示形態で表示してもよい（例えば色を変えるなど）。
【０１２５】
以上、実施形態の構成及び処理内容について説明した。以上の例では、文書管理サーバ１０が１つである場合を説明したが、複数の文書管理サーバ１０で分散サーバネットワークを構成してもよい。なお、１つのクライアント２０から、分散サーバネットワークを構成するすべてのサーバ１０を参照できなくても構わない。例えば一部のネットワークがイントラネット上に配置され、インターネット側に存在するクライアントからは到達できない場合や、サーバがクライアントを認証し許可されたクライアントに対してしか反応しないなどの方法で論理的にネットワークが制限される場合などが、このようなケースに該当する。
【０１２６】
このような分散構成の一例を説明する。図２２に示すように、分散ネットワークを構成する各文書管理サーバ１０は、図２に例示した単体構成のサーバが持つ要素の他に、他サーバ通知部１５０を備える。他サーバ通知部１５０は通知先リスト１５２を記憶している。通知先リスト１５２には、通知先である各サーバの識別子が登録されている。以下では、文書管理サーバ１０を単に「サーバ」と呼ぶ。
【０１２７】
この例では、サーバの集合をΣとし、各サーバＳ∈Σにはサーバ識別子idＳが対応付けられているとする。また各サーバＳは通知先リスト１５２としてサーバ識別子の集合FＳを保持する。idＳ'∈FＳである（すなわちサーバＳ'はサーバＳの通知先リスト１５２に含まれる）とすると、サーバＳ及びＳ'をそれぞれグラフのノードとすると、ノードＳからノードＳ'への有向エッジを定義できる。このようにノードと有向エッジを定義すると、サーバの集合Σを表す有向グラフを得ることができる。通知先リストを適切に設定すれば、サーバの集合Σについてのグラフを非循環有向グラフ（DAG: Directed acyclic graph）とすることができる。
【０１２８】
サーバＳがクライアントから"bind"メッセージ(ξ,x)を受信すると、サーバＳは、データｘを記憶すると共に、通知先リスト１５２に含まれる各サーバに"bind"メッセージ(ξ,idＳ)を転送する。サーバＳの識別子idＳとしては、例えばサーバＳのネットワーク上でのアドレスを用いてもよい。また、サーバＳの識別子idＳがサーバＳのアドレスそのものでなくても、識別子idＳからサーバＳのアドレスを解決する仕組みをネットワーク上に設けることは、周知技術により容易に実現できる。
【０１２９】
また、サーバＳ' がサーバＳから"bind"メッセージ(ξ,idＳ)を受信すると、サーバＳ'はidＳをξと関連付けて記憶すると共に、自分の通知先リストに含まれるサーバに"bind"メッセージ(ξ,idＳ)を転送する。Σは有限集合でDAGであるので上記の操作は必ず停止する。
【０１３０】
"resolve"メッセージについても同様に構成することによって、クライアントがリクエストをしたサーバを含むグラフΣの連結成分の全体が仮想的には単一のサーバとして動作することになる。
【０１３１】
"resolve"メッセージを受信したときのサーバの処理手順の一例を、図２３に示す。この例では、ハッシュ値ξについての"resolve"メッセージを装置Ａから受信すると（Ｓ１８１）、サーバはξをキーとして、自分の持つ文書管理ＤＢ１１０を検索する（Ｓ１８２）。ここで、装置Ａは、クライアント２０の場合もあれば、他のサーバの場合もある。サーバは、ステップＳ１８２の検索によりキーξに対応するデータが検索できたかどうかを判定し（Ｓ１８３）、検索できた場合、キーξに対応するデータがサーバ識別子であるか、登録されたデータ実体ｘ（電子文書又はメタ情報）であるかを判定する（Ｓ１８４）。キーξに対応するデータがデータ実体ｘであれば、サーバはそのデータ実体ｘを装置Ａに返す（Ｓ１８５）。キーξに対応するデータがサーバ識別子であれば、サーバはそのサーバ識別子に対応するサーバへ、ハッシュ値ξについての"resolve"メッセージを送信し（Ｓ１８６）、このメッセージに対する返信を待つ。返信には、ξに対応するデータ実体ｘが含まれる。この返信を受け取ったサーバは、そのデータ実体ｘを装置Ａに返す（Ｓ１８７）。
【０１３２】
ステップＳ１８３で、当該サーバ内の文書管理ＤＢ１１０にキーξが存在しないと判定された場合は、他サーバ通知部１５０が、通知先リスト１５２に登録された各サーバに対して、ハッシュ値ξについての"resolve"メッセージを送信し（Ｓ１８８）、そのメッセージに対する返信を受け取る。そしてサーバは、その返信に含まれるデータ実体ｘを装置Ａに返す（Ｓ１８９）。
【０１３３】
"exist?"メッセージは、"resolve"メッセージと同様に処理すればよい。すなわち、例えば図２４に示すように、サーバは、"exist?(ξ)"メッセージを装置Ａから受け取った場合（Ｓ１９１）、自分の文書管理ＤＢ１１０においてキーξを検索し（Ｓ１９２）、キーξが検索できたかどうかを判定する（Ｓ１９３）。検索できた場合、ブール値b=trueを装置Ａに返す（Ｓ１９４）。また、キーξがサーバ内の文書管理ＤＢ１１０に存在しない場合、他サーバ通知部１５０は、通知先リスト１５２を調べる（Ｓ１９５）。通知先リストが空でなければ、そのリスト内の各通知先サーバに対して"exist?(ξ)"メッセージを送信し、各サーバからの返信を待つ（Ｓ１９６）。そして、各サーバからの返信を判定する（Ｓ１９７）。その結果、ブール値b=trueを含む返信が１つでもあれば、サーバはブール値b=trueを装置Ａに返す（Ｓ１９４）。すべての通知先サーバからの返信がブール値b=falseである場合は、サーバはブール値b=falseを装置Ａに返す（Ｓ１９８）。また、ステップＳ１９５で通知先リスト１５２が空であった場合、サーバは、ブール値b=falseを装置Ａに返す（Ｓ１９８）。
【０１３４】
また、"delete(ξ)"メッセージを受け取ったサーバの処理は、例えば以下のようなものでよい。すなわち、この場合サーバは、当該サーバの文書管理ＤＢ１１０内にキーξのエントリが存在すればそれを削除する。また、キーξのエントリが存在するか否かにかかわらず、他サーバ通知部１５０が通知先リスト１５２に登録された各サーバに対し、"delete(ξ)"メッセージを送信する。
【０１３５】
以上に例示した分散サーバ構成は、グラフΣがDAGである要請を満たす範囲で自由にネットワークのトポロジーを変更することが可能である。また、２つのサブグラフが相互に連結していない場合に、一方のサブグラフのリーフの通知先リストに、他方のサブグラフのノードを追加することで、それら２つのサブグラフを連結することができる。このような連結処理により、例えば、異なるドメインに独立に存在していた複数の分散サーバネットワークをアポステリオリにマージして１つの大きな分散サーバネットワークを構築することができる。
【０１３６】
分散サーバ構成の別の例として、周知のChord（http://pdos.csail.mit.edu/chord/）による分散ハッシュテーブルを利用することも可能である。すなわち、分散サーバネットワークを、分散ハッシュテーブルで表現される構造化オーバレイネットワークとして構成するのである。これは、サーバサイドのいわゆるP2Pネットワーク構成と捉えることができる。
【０１３７】
以上、実施形態のシステムを説明した。以上の例では、クライアント２０とサーバ１０とが別々のホストコンピュータ上に存在するとして説明したが、それら両者が同一ホスト上に存在しても構わない（いわゆるP2Pネットワーク構成）。
【０１３８】
以上の例では、電子文書及びフォルダなどのメタ情報をＸＭＬで記述したが、これはあくまで一例に過ぎない。メタ情報は、記述形式に依存するものではない。
【０１３９】
以上の実施形態において、サーバ１０は、典型的には、汎用のコンピュータにて上述の各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図２５に示すように、ＣＰＵ（中央演算装置）４０、メモリ（一次記憶）４２、各種Ｉ／Ｏ（入出力）インターフェイス４４等がバス４６を介して接続された回路構成を有する。また、そのバス４６に対し、例えばＩ／Ｏインターフェイス４４経由で、ハードディスクドライブ４８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ５０が接続される。このようなドライブ４８又は５０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ４８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。クライアント２０も、コンピュータ・ハードウエアを用いて同様に構成することができる。
【図面の簡単な説明】
【０１４０】
【図１】文書管理システムの概略構成の例を示す図である。
【図２】文書管理サーバの内部構成の例を示す図である。
【図３】文書管理ＤＢのデータ内容の一例を示す図である。
【図４】派生関係ＤＢのデータ内容の一例を示す図である。
【図５】電子文書とメタ情報と参照情報ファイルとの関係を説明するための図である。
【図６】クライアント装置の内部構成の例を示す図である。
【図７】bind処理の手順の例を示すフローチャートである。
【図８】resolve処理の手順の例を示すフローチャートである。
【図９】exist?処理の手順の例を示すフローチャートである。
【図１０】delete処理の手順の例を示すフローチャートである。
【図１１】電子文書に対応する参照情報ファイルの生成処理の手順の例を示すフローチャートである。
【図１２】フォルダに対応する参照情報ファイルの生成処理の手順の例を示すフローチャートである。
【図１３】電子文書を出力する操作の手順の例を示すフローチャートである。
【図１４】フォルダに対する操作の手順の例を示すフローチャートである。
【図１５】電子文書の印刷が指示された場合の手順の例を示すフローチャートである。
【図１６】電子文書の印刷が指示された場合の手順の別の例を示すフローチャートである。
【図１７】紙文書の複写が指示された場合の手順の例を示すフローチャートである。
【図１８】紙文書のスキャンが指示された場合の手順の例を示すフローチャートである。
【図１９】紙文書の廃棄が指示された場合の手順の例を示すフローチャートである。
【図２０】派生関係表示が指示された場合の手順の例を示すフローチャートである。
【図２１】派生関係の表示画像の一例を示す図である。
【図２２】複数の文書管理サーバによる分散サーバ構成を採用した場合の、個々の文書管理サーバの内部構成の例を示す図である。
【図２３】分散サーバ構成においてサーバが"resolve"メッセージを受け取ったときに実行する処理の例を示すフローチャートである。
【図２４】分散サーバ構成においてサーバが"exist?"メッセージを受け取ったときに実行する処理の例を示すフローチャートである。
【図２５】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【０１４１】
１０ 文書管理サーバ、２０ クライアント装置、３０ ネットワーク、１１０ 文書管理ＤＢ、１２０ 派生関係ＤＢ、１３０ クライアントＩＦ部、１４０ 派生関係表示生成部、２００ 情報処理部、２１０ 文書処理部、２３０ アプリケーション、２４０ ファイルシステム、２５０ プリンタ、２６０ スキャナ、２７０ スキャナ付きシュレッダ。
【特許請求の範囲】
【請求項１】
電子文書と、当該電子文書の内容のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、
電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、
管理識別子を指定した取得指示に基づいて、当該管理識別子に対応する管理情報を前記管理情報記憶部から取得し、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書記憶部から取得する取得部と、
前記取得部が取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を、当該管理情報のハッシュ値である当該媒体文書の管理識別子と対応づけて前記管理情報記憶部に登録すると共に、当該媒体文書の管理識別子を当該媒体文書に対して書き込む印刷管理部と、
を備える文書管理システム。
【請求項２】
前記取得部が取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書を、当該第２の電子文書の内容識別子と対応づけて前記文書記憶部に登録すると共に、当該第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を、当該管理情報のハッシュ値である当該第２の電子文書の管理識別子と対応づけて前記管理情報記憶部に登録する登録部、
を更に備える請求項１記載の文書管理システム。
【請求項３】
前記印刷管理部は、前記媒体へ印刷される画像を表す印刷画像データを、当該印刷画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、
ことを特徴とする請求項１記載の文書管理システム。
【請求項４】
媒体文書に対する読取操作の実行に応じて、当該媒体文書に書き込まれた管理識別子を認識し、当該読取の結果得られる電子文書の管理情報として、前記媒体文書の管理識別子を含む管理情報を生成し、当該電子文書を当該電子文書のハッシュ値である内容識別子と対応づけて前記文書記憶部に登録すると共に、当該管理情報を当該管理情報のハッシュ値である管理識別子と対応づけて前記管理情報記憶部に登録する読取管理部、
を更に備える請求項１記載の文書管理システム。
【請求項５】
第１の媒体文書に対する複製操作の実行に応じて、当該第１の媒体文書に書き込まれた管理識別子を認識し、当該複製の結果得られる第２の媒体文書の管理情報として、前記第１の媒体文書の管理識別子を含む管理情報を生成し、当該管理情報を当該管理情報のハッシュ値である第２の管理識別子と対応づけて前記管理情報記憶部に登録すると共に、当該第２の管理識別子を前記第２の媒体文書に対して書き込む複製管理部、
を更に備える請求項１記載の文書管理システム。
【請求項６】
前記複製管理部は、前記第１の媒体文書の読取により得られた画像データを、当該画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記第２の媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、
ことを特徴とする請求項５記載の文書管理システム。
【請求項７】
媒体文書に対する廃棄操作の実行に応じて、当該媒体文書に書き込まれた管理識別子を認識し、当該媒体文書の廃棄を示す管理情報として、前記媒体文書の管理識別子を含む管理情報を生成し、当該管理情報を当該管理情報のハッシュ値である管理識別子と対応づけて前記管理情報記憶部に登録する廃棄管理部、
を更に備える請求項１記載の文書管理システム。
【請求項８】
前記廃棄管理部は、前記媒体文書の読取により得られた画像データを、当該画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、
ことを特徴とする請求項７記載の文書管理システム。
【請求項９】
管理識別子を指定した取得指示に応じて、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶した管理情報記憶部から、当該操作指示にて指定された管理識別子に対応する管理情報を取得するステップと、
取得された管理情報に含まれる内容識別子に対応する第１の電子文書を、電子文書と、当該電子文書のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶した文書記憶部から取得するステップと、
取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を、当該管理情報のハッシュ値である当該媒体文書の管理識別子と対応づけて前記管理情報記憶部に登録するステップと、
当該媒体文書の管理識別子を当該媒体文書に対して書き込むステップと、
をコンピュータに実行させるためのプログラム。
【請求項１０】
取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書を、当該第２の電子文書の内容識別子と対応づけて前記文書記憶部に登録するステップと、
当該第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を、当該管理情報のハッシュ値である当該第２の電子文書の管理識別子と対応づけて前記管理情報記憶部に登録するステップと、
を更にコンピュータに実行させることを特徴とする請求項９記載のプログラム。
【請求項１１】
電子文書と、当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、
電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、
を備えた文書管理サーバシステムと通信し、利用者に対して文書処理機能を提供する文書処理クライアント装置であって、
管理識別子を指定した取得指示に応じて、当該管理識別子に対応する管理情報を前記文書管理サーバから取得し、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書管理サーバから取得する取得部と、
前記取得部が取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を生成し、当該媒体文書の管理識別子として当該管理情報のハッシュ値を計算し、計算された管理識別子と当該媒体文書の管理情報とを対応づけて前記文書管理サーバに登録すると共に、当該媒体文書の管理識別子を当該媒体文書に対して書き込む印刷管理部と、
を備える文書処理クライアント装置。
【請求項１２】
前記取得部が取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書についての内容識別子として当該第２の電子文書のハッシュ値を計算し、計算された内容識別子と当該第２の電子文書とを対応づけて前記文書管理サーバに登録する内容登録部と、
前記第２の電子文書の管理情報として、前記第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を生成し、当該第２の電子文書の管理識別子として当該管理情報のハッシュ値を計算し、計算された管理識別子と当該第２の電子文書の管理情報とを対応づけて前記文書管理サーバに登録する管理情報登録部と、
を更に備える請求項１１記載の文書処理クライアント装置。
【請求項１３】
電子文書と、当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、
電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、
を備えた文書管理サーバシステムと通信し、利用者に対して文書処理機能を提供する文書処理クライアント装置、としてコンピュータを機能させるためのプログラムであって、
管理識別子を指定した取得指示に応じて、当該管理識別子に対応する管理情報を前記文書管理サーバから取得するステップと、
取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書管理サーバから取得するステップと、
取得された前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を生成するステップと、
当該媒体文書の管理識別子として当該管理情報のハッシュ値を計算するステップと、
計算された管理識別子と当該媒体文書の管理情報とを対応づけて前記文書管理サーバに登録するステップと、
当該媒体文書の管理識別子を当該媒体文書に対して書き込むステップと、
を前記コンピュータに実行させるためのプログラム。
【請求項１４】
取得された前記第１の電子文書に対する操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書についての内容識別子として当該第２の電子文書のハッシュ値を計算するステップと、
計算された内容識別子と当該第２の電子文書とを対応づけて前記文書管理サーバに登録するステップと、
前記第２の電子文書の管理情報として、前記第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を生成するステップと、
当該第２の電子文書の管理識別子として当該管理情報のハッシュ値を計算するステップと、
計算された管理識別子と当該第２の電子文書の管理情報とを対応づけて前記文書管理サーバに登録するステップと、
を更に前記コンピュータに実行させることを特徴とする請求項１３記載のプログラム。
【請求項１５】
電子文書と、当該電子文書の内容のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、
電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、
文書処理クライアント装置から管理識別子を提示した解決要求を受けた場合に当該管理識別子に対応する管理情報を前記管理情報記憶部から前記文書処理クライアント装置に提供し、前記文書処理クライアント装置から内容識別子を提示した解決要求を受けた場合に当該内容識別子に対応する電子文書を前記文書処理クライアント装置に提供する識別子解決部と、
前記文書処理クライアント装置から、媒体文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納する媒体情報格納処理部と、
を備える文書管理サーバ装置。
【請求項１６】
前記文書処理クライアント装置から、電子文書と内容識別子とを含む登録要求を受けた場合に、当該電子文書を当該内容識別子に対応づけて前記文書記憶部に格納する内容格納処理部と、
前記文書処理クライアント装置から、電子文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納する管理情報格納処理部と、
を更に備える請求項１５記載の文書管理サーバ装置。
【請求項１７】
通知先の第２の文書管理サーバ装置の識別子のリストを記憶したリスト記憶部と、
文書処理クライアント装置から電子文書と内容識別子とを含む登録要求を受けた場合に、当該内容識別子と当該文書管理サーバ装置自身の識別子とを含む登録要求を、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に送信し、前記文書処理クライアント装置から管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理識別子と当該文書管理サーバ装置自身の識別子とを含む登録要求を、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に送信する送信部と、
第３の文書管理サーバ装置から内容識別子と当該第３の文書管理サーバ装置の識別子とを含む登録要求を受けた場合、前記内容識別子と当該第３の文書管理サーバ装置の識別子とを前記文書記憶部に登録すると共に、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に当該登録要求を転送する第１登録処理部と、
前記第３の文書管理サーバ装置から管理識別子と当該第３の文書管理サーバ装置の識別子とを含む登録要求を受けた場合、前記管理識別子と当該第３の文書管理サーバ装置の識別子とを前記管理情報記憶部に登録すると共に、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に当該登録要求を転送する第２登録処理部と、
内容識別子を提示した解決要求を受けた場合に、前記文書記憶部に当該内容識別子に対応づけて記憶されている情報が文書管理サーバ装置の識別子であれば、当該識別子に対応する文書管理サーバ装置から当該内容識別子に対応する電子文書を取得し、取得された電子文書を前記解決要求の発行元の装置に返す第１解決処理部と、
管理識別子を提示した解決要求を受けた場合に、前記管理情報記憶部に当該管理識別子に対応づけて記憶されている情報が文書管理サーバ装置の識別子であれば、当該識別子に対応する文書管理サーバ装置から当該管理識別子に対応する管理情報を取得し、取得された管理情報を前記解決要求の発行元の装置に返す第１解決処理部と、
を更に備える請求項１６記載の文書管理サーバ装置。
【請求項１８】
文書処理クライアント装置から管理識別子を提示した解決要求を受けた場合に、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部から、当該管理識別子に対応する管理情報を取得し、前記文書処理クライアント装置に提供するステップと、
前記文書処理クライアント装置から内容識別子を提示した解決要求を受けた場合に、電子文書と、当該電子文書のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部から、当該内容識別子に対応する電子文書を取得し、前記文書処理クライアント装置に提供するステップと、
前記文書処理クライアント装置から、媒体文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納するステップと、
をコンピュータに実行させるためのプログラム。
【請求項１９】
前記文書処理クライアント装置から、電子文書と内容識別子とを含む登録要求を受けた場合に、当該電子文書を当該内容識別子に対応づけて前記文書記憶部に格納するステップと、
前記文書処理クライアント装置から、電子文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納するステップと、
を更にコンピュータに実行させることを特徴とする請求項１８記載のプログラム。
【請求項１】
電子文書と、当該電子文書の内容のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、
電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、
管理識別子を指定した取得指示に基づいて、当該管理識別子に対応する管理情報を前記管理情報記憶部から取得し、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書記憶部から取得する取得部と、
前記取得部が取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を、当該管理情報のハッシュ値である当該媒体文書の管理識別子と対応づけて前記管理情報記憶部に登録すると共に、当該媒体文書の管理識別子を当該媒体文書に対して書き込む印刷管理部と、
を備える文書管理システム。
【請求項２】
前記取得部が取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書を、当該第２の電子文書の内容識別子と対応づけて前記文書記憶部に登録すると共に、当該第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を、当該管理情報のハッシュ値である当該第２の電子文書の管理識別子と対応づけて前記管理情報記憶部に登録する登録部、
を更に備える請求項１記載の文書管理システム。
【請求項３】
前記印刷管理部は、前記媒体へ印刷される画像を表す印刷画像データを、当該印刷画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、
ことを特徴とする請求項１記載の文書管理システム。
【請求項４】
媒体文書に対する読取操作の実行に応じて、当該媒体文書に書き込まれた管理識別子を認識し、当該読取の結果得られる電子文書の管理情報として、前記媒体文書の管理識別子を含む管理情報を生成し、当該電子文書を当該電子文書のハッシュ値である内容識別子と対応づけて前記文書記憶部に登録すると共に、当該管理情報を当該管理情報のハッシュ値である管理識別子と対応づけて前記管理情報記憶部に登録する読取管理部、
を更に備える請求項１記載の文書管理システム。
【請求項５】
第１の媒体文書に対する複製操作の実行に応じて、当該第１の媒体文書に書き込まれた管理識別子を認識し、当該複製の結果得られる第２の媒体文書の管理情報として、前記第１の媒体文書の管理識別子を含む管理情報を生成し、当該管理情報を当該管理情報のハッシュ値である第２の管理識別子と対応づけて前記管理情報記憶部に登録すると共に、当該第２の管理識別子を前記第２の媒体文書に対して書き込む複製管理部、
を更に備える請求項１記載の文書管理システム。
【請求項６】
前記複製管理部は、前記第１の媒体文書の読取により得られた画像データを、当該画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記第２の媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、
ことを特徴とする請求項５記載の文書管理システム。
【請求項７】
媒体文書に対する廃棄操作の実行に応じて、当該媒体文書に書き込まれた管理識別子を認識し、当該媒体文書の廃棄を示す管理情報として、前記媒体文書の管理識別子を含む管理情報を生成し、当該管理情報を当該管理情報のハッシュ値である管理識別子と対応づけて前記管理情報記憶部に登録する廃棄管理部、
を更に備える請求項１記載の文書管理システム。
【請求項８】
前記廃棄管理部は、前記媒体文書の読取により得られた画像データを、当該画像データのハッシュ値である内容識別子と対応づけて前記文書記憶部へ登録すると共に、前記媒体文書の管理情報として、当該内容識別子を更に含んだ管理情報を前記管理情報記憶部に登録する、
ことを特徴とする請求項７記載の文書管理システム。
【請求項９】
管理識別子を指定した取得指示に応じて、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶した管理情報記憶部から、当該操作指示にて指定された管理識別子に対応する管理情報を取得するステップと、
取得された管理情報に含まれる内容識別子に対応する第１の電子文書を、電子文書と、当該電子文書のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶した文書記憶部から取得するステップと、
取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を、当該管理情報のハッシュ値である当該媒体文書の管理識別子と対応づけて前記管理情報記憶部に登録するステップと、
当該媒体文書の管理識別子を当該媒体文書に対して書き込むステップと、
をコンピュータに実行させるためのプログラム。
【請求項１０】
取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書を、当該第２の電子文書の内容識別子と対応づけて前記文書記憶部に登録するステップと、
当該第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を、当該管理情報のハッシュ値である当該第２の電子文書の管理識別子と対応づけて前記管理情報記憶部に登録するステップと、
を更にコンピュータに実行させることを特徴とする請求項９記載のプログラム。
【請求項１１】
電子文書と、当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、
電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、
を備えた文書管理サーバシステムと通信し、利用者に対して文書処理機能を提供する文書処理クライアント装置であって、
管理識別子を指定した取得指示に応じて、当該管理識別子に対応する管理情報を前記文書管理サーバから取得し、取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書管理サーバから取得する取得部と、
前記取得部が取得した前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を生成し、当該媒体文書の管理識別子として当該管理情報のハッシュ値を計算し、計算された管理識別子と当該媒体文書の管理情報とを対応づけて前記文書管理サーバに登録すると共に、当該媒体文書の管理識別子を当該媒体文書に対して書き込む印刷管理部と、
を備える文書処理クライアント装置。
【請求項１２】
前記取得部が取得した前記第１の電子文書に対して操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書についての内容識別子として当該第２の電子文書のハッシュ値を計算し、計算された内容識別子と当該第２の電子文書とを対応づけて前記文書管理サーバに登録する内容登録部と、
前記第２の電子文書の管理情報として、前記第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を生成し、当該第２の電子文書の管理識別子として当該管理情報のハッシュ値を計算し、計算された管理識別子と当該第２の電子文書の管理情報とを対応づけて前記文書管理サーバに登録する管理情報登録部と、
を更に備える請求項１１記載の文書処理クライアント装置。
【請求項１３】
電子文書と、当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、
電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、
を備えた文書管理サーバシステムと通信し、利用者に対して文書処理機能を提供する文書処理クライアント装置、としてコンピュータを機能させるためのプログラムであって、
管理識別子を指定した取得指示に応じて、当該管理識別子に対応する管理情報を前記文書管理サーバから取得するステップと、
取得された管理情報に含まれる内容識別子に対応する第１の電子文書を前記文書管理サーバから取得するステップと、
取得された前記第１の電子文書に対する印刷指示に応じて、その印刷指示に対する印刷結果である媒体文書の管理情報として、前記第１の電子文書の管理識別子を含む管理情報を生成するステップと、
当該媒体文書の管理識別子として当該管理情報のハッシュ値を計算するステップと、
計算された管理識別子と当該媒体文書の管理情報とを対応づけて前記文書管理サーバに登録するステップと、
当該媒体文書の管理識別子を当該媒体文書に対して書き込むステップと、
を前記コンピュータに実行させるためのプログラム。
【請求項１４】
取得された前記第１の電子文書に対する操作が実行され第２の電子文書が生成された場合に、当該第２の電子文書についての内容識別子として当該第２の電子文書のハッシュ値を計算するステップと、
計算された内容識別子と当該第２の電子文書とを対応づけて前記文書管理サーバに登録するステップと、
前記第２の電子文書の管理情報として、前記第２の電子文書の内容識別子と、前記第１の電子文書の管理識別子とを含む管理情報を生成するステップと、
当該第２の電子文書の管理識別子として当該管理情報のハッシュ値を計算するステップと、
計算された管理識別子と当該第２の電子文書の管理情報とを対応づけて前記文書管理サーバに登録するステップと、
を更に前記コンピュータに実行させることを特徴とする請求項１３記載のプログラム。
【請求項１５】
電子文書と、当該電子文書の内容のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部と、
電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部と、
文書処理クライアント装置から管理識別子を提示した解決要求を受けた場合に当該管理識別子に対応する管理情報を前記管理情報記憶部から前記文書処理クライアント装置に提供し、前記文書処理クライアント装置から内容識別子を提示した解決要求を受けた場合に当該内容識別子に対応する電子文書を前記文書処理クライアント装置に提供する識別子解決部と、
前記文書処理クライアント装置から、媒体文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納する媒体情報格納処理部と、
を備える文書管理サーバ装置。
【請求項１６】
前記文書処理クライアント装置から、電子文書と内容識別子とを含む登録要求を受けた場合に、当該電子文書を当該内容識別子に対応づけて前記文書記憶部に格納する内容格納処理部と、
前記文書処理クライアント装置から、電子文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納する管理情報格納処理部と、
を更に備える請求項１５記載の文書管理サーバ装置。
【請求項１７】
通知先の第２の文書管理サーバ装置の識別子のリストを記憶したリスト記憶部と、
文書処理クライアント装置から電子文書と内容識別子とを含む登録要求を受けた場合に、当該内容識別子と当該文書管理サーバ装置自身の識別子とを含む登録要求を、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に送信し、前記文書処理クライアント装置から管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理識別子と当該文書管理サーバ装置自身の識別子とを含む登録要求を、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に送信する送信部と、
第３の文書管理サーバ装置から内容識別子と当該第３の文書管理サーバ装置の識別子とを含む登録要求を受けた場合、前記内容識別子と当該第３の文書管理サーバ装置の識別子とを前記文書記憶部に登録すると共に、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に当該登録要求を転送する第１登録処理部と、
前記第３の文書管理サーバ装置から管理識別子と当該第３の文書管理サーバ装置の識別子とを含む登録要求を受けた場合、前記管理識別子と当該第３の文書管理サーバ装置の識別子とを前記管理情報記憶部に登録すると共に、前記リスト記憶部に記憶された前記第２の文書管理サーバ装置に当該登録要求を転送する第２登録処理部と、
内容識別子を提示した解決要求を受けた場合に、前記文書記憶部に当該内容識別子に対応づけて記憶されている情報が文書管理サーバ装置の識別子であれば、当該識別子に対応する文書管理サーバ装置から当該内容識別子に対応する電子文書を取得し、取得された電子文書を前記解決要求の発行元の装置に返す第１解決処理部と、
管理識別子を提示した解決要求を受けた場合に、前記管理情報記憶部に当該管理識別子に対応づけて記憶されている情報が文書管理サーバ装置の識別子であれば、当該識別子に対応する文書管理サーバ装置から当該管理識別子に対応する管理情報を取得し、取得された管理情報を前記解決要求の発行元の装置に返す第１解決処理部と、
を更に備える請求項１６記載の文書管理サーバ装置。
【請求項１８】
文書処理クライアント装置から管理識別子を提示した解決要求を受けた場合に、電子文書の内容識別子と当該電子文書の親文書の管理識別子とを含む管理情報と、当該管理情報のハッシュ値である当該電子文書の管理識別子と、を対応づけて記憶する管理情報記憶部から、当該管理識別子に対応する管理情報を取得し、前記文書処理クライアント装置に提供するステップと、
前記文書処理クライアント装置から内容識別子を提示した解決要求を受けた場合に、電子文書と、当該電子文書のハッシュ値である当該電子文書の内容識別子と、を対応づけて記憶する文書記憶部から、当該内容識別子に対応する電子文書を取得し、前記文書処理クライアント装置に提供するステップと、
前記文書処理クライアント装置から、媒体文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納するステップと、
をコンピュータに実行させるためのプログラム。
【請求項１９】
前記文書処理クライアント装置から、電子文書と内容識別子とを含む登録要求を受けた場合に、当該電子文書を当該内容識別子に対応づけて前記文書記憶部に格納するステップと、
前記文書処理クライアント装置から、電子文書の管理情報と管理識別子とを含む登録要求を受けた場合に、当該管理情報を当該管理識別子に対応づけて前記管理情報記憶部に格納するステップと、
を更にコンピュータに実行させることを特徴とする請求項１８記載のプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２００８−１５２５４６（Ｐ２００８−１５２５４６Ａ）
【公開日】平成２０年７月３日（２００８．７．３）
【国際特許分類】
【出願番号】特願２００６−３４０１０４（Ｐ２００６−３４０１０４）
【出願日】平成１８年１２月１８日（２００６．１２．１８）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
【公開日】平成２０年７月３日（２００８．７．３）
【国際特許分類】
【出願日】平成１８年１２月１８日（２００６．１２．１８）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
[ Back to top ]