(57)【要約】【課題】文書が操作された場合に操作前の文書と操作後の文書との間に生じる派生関係を管理するシステムにおいて、本来一連につながっているはずの文書の派生関係が別々の複数の派生関係に分かれていると把握されてしまう場合がある。【解決手段】操作結果文書とその管理ＩＤ、その文書の操作前の管理ＩＤである親ＩＤ、及びその文書の文書属性をクライアントから受信した文書登録部１４０は、その文書を文書ＤＢ１００に、管理ＩＤと親ＩＤの組を派生関係ＤＢ１１０に、その文書の文書属性を文書属性ＤＢ１２０に登録する。派生関係推定部１５２は、派生関係ＤＢ１１０に記憶された派生関係情報群が表す文書の派生関係の木構造の根となる文書の文書属性と、この派生関係情報群に含まれる文書の文書属性と、を文書属性ＤＢ１２０から取得して比較することで、前記木構造の根となる文書の親文書となり得る文書を推定する。【選択図】図４
2008181350.tif 000002
【特許請求の範囲】
【請求項１】
操作前の文書を親とし操作後の文書を子とする派生関係の情報と、前記操作後の文書の文書属性と、を第１の情報処理装置から受信する受信手段と、
受信した前記派生関係情報を記憶する派生関係情報記憶手段と、
受信した前記文書属性を記憶する文書属性記憶手段と、
前記文書属性記憶手段から取得した、前記派生関係記憶手段に記憶された派生関係情報群が表す文書の派生関係の木構造の根となる文書の文書属性と、前記派生関係情報群に含まれる文書の文書属性と、の比較に基づいて、前記木構造の根となる文書の親文書となり得る文書を推定する推定手段と、
を備えることを特徴とする第２の情報処理装置。
【請求項２】
前記木構造の根となる文書を子とし、当該木構造の根となる文書の親文書として前記推定手段で推定された文書を親とする派生関係の情報を擬似派生関係情報とし、この擬似派生関係情報を前記派生関係情報群と区別して記憶する擬似派生関係情報記憶手段をさらに備える請求項１に記載の第２の情報処理装置。
【請求項３】
前記派生関係情報群と、前記擬似派生関係情報記憶手段に記憶された擬似派生関係情報群と、が表す木構造を図式的に表す表示情報であって、当該木構造において、前記派生関係情報群が表す派生関係と、前記擬似派生関係情報群が表す派生関係と、を互いに異なる態様で表す表示情報を生成する表示情報生成手段をさらに備える請求項２に記載の第２の情報処理装置。
【請求項４】
操作前の文書を親とし操作後の文書を子とする派生関係の情報と、前記操作後の文書の文書属性と、を第１の情報処理装置から受信する受信ステップと、
受信した前記派生関係情報を派生関係情報記憶手段に記憶する派生関係情報記憶ステップと、
受信した前記文書属性を文書属性記憶手段に記憶する文書属性記憶ステップと、
前記文書属性記憶手段から取得した、前記派生関係記憶手段に記憶された派生関係情報群が表す文書の派生関係の木構造の根となる文書の文書属性と、前記派生関係情報群に含まれる文書の文書属性と、の比較に基づいて、前記木構造の根となる文書の親文書となり得る文書を推定する推定ステップと、
をコンピュータに実行させるためのプログラム。
【請求項５】
第１の情報処理装置と第２の情報処理装置とを備え、
前記第１の情報処理装置は、
文書が操作された場合に、操作前の文書を親とし操作後の文書を子とする派生関係の情報を生成する派生関係情報生成手段と、
文書の文書属性を取得する文書属性取得手段と、
前記派生関係情報生成手段で生成された派生関係情報と、前記文書属性取得手段で取得された前記操作後の文書の文書属性と、を前記第２の情報処理装置に対して送信する送信手段と、
を備え、
前記第２の情報処理装置は、
前記派生関係情報と、前記操作後の文書の文書属性と、を前記第１の情報処理装置から受信する受信手段と、
受信した前記派生関係情報を記憶する派生関係情報記憶手段と、
受信した前記文書属性を記憶する文書属性記憶手段と、
前記文書属性記憶手段から取得した、前記派生関係記憶手段に記憶された派生関係情報群が表す文書の派生関係の木構造の根となる文書の文書属性と、前記派生関係情報群に含まれる文書の文書属性と、の比較に基づいて、前記木構造の根となる文書の親文書となり得る文書を推定する推定手段と、
を備えることを特徴とする情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
テキスト文書データや音声データ、マルチメディアデータなどの電子文書（以下単に文書とも呼ぶ）をサーバに登録し、ユーザの要求に応じてその文書を提供することが行われている。また、電子文書に対して一意な識別子を付与し、ユーザが入力した識別子に対応する電子文書を提供するシステムも知られている。また、別の公知のシステムでは、電子文書を紙に印刷する場合に、電子文書の識別子をコード化して紙文書に埋め込み、紙文書を複写する際にその紙文書に埋め込まれた識別子を認識し、その識別子に対応した電子文書を取得し、紙に印刷する。
【０００３】
特許文献１に開示されたシステムでは、コンテンツコピー機は、コンテンツＩＤが埋め込まれたコンテンツのコピー原稿からコンテンツＩＤを読み取り、読み取ったコンテンツＩＤとコピーイベント属性の情報とをネットワークを介してコンテンツＩＤ管理センタへ送信する。コンテンツＩＤ管理センタは、受信したコンテンツＩＤからそのコンテンツの原本を取得し、新しいコンテンツＩＤを付与して、そのコンテンツＩＤとコピーイベント属性の情報とを記録し、その新しいコンテンツＩＤをコンテンツの原本に対して埋め込んでコピー要求元へ返す。コンテンツコピー機は、それをコピー結果として出力する。このシステムにおいて、コンテンツＩＤ管理センタは、コンテンツコピー機から受信したコンテンツＩＤに応じて、新たなコンテンツＩＤを発行した場合、その新しいコンテンツＩＤコピー元が前述の受信したコンテンツＩＤであることを記録する（例えば特許文献１の第４１段落末尾）。
【０００４】
他の従来技術の一例として、特許文献２に示されるもののように、紙文書に対する手書きによる編集を、直接的に電子文書に反映し、電子文書の更新された版の系列を、電子文書をノードとする木構造として保持するものがある。特許文献２では、文書やファイルをノードとし、文書やファイルの更新によって生成される版を、枝分かれした版として管理する事ができる文書履歴木の例が開示されている。このようなバージョン管理システムは、CVS（Concurrent Versions System）として広く知られている。特許文献２には、電子文書の更新に関する履歴を、更新前の電子文書を親とし、更新後の電子文書を子とするように文書履歴木を管理する方法が開示されている。
【０００５】
【特許文献１】特開２００２−０１６７８８号公報
【特許文献２】特開２００５−１３５２１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、識別情報を含んだ文書に対して操作を行い、その操作の結果の文書に対して新たな識別情報を組み込む方法では、前者の識別情報と後者の識別情報との間に親子関係すなわち派生関係を定義することができる。ある文書の操作結果に対して別の操作が行われることで更なる操作結果が得られる場合のように操作が連鎖すると、派生関係の系列が得られる。また、同じ識別情報の文書に対し別々の操作が加えられた場合、その識別情報の子孫は２つに分岐する。このような識別情報同士の派生関係の情報をサーバに集め、サーバがそれら派生関係の情報を用いて利用者にサービスを行うシステムが考えられる。
【０００７】
このようなシステムにおいて、何らかの理由で派生関係の系列の一部の情報が欠けていると、本来一連につながっているはずの派生関係が別々の複数の派生関係に分かれていると把握されてしまう場合がある。
【０００８】
本発明は、本来一連につながっているはずの派生関係が別々の複数の派生関係に分かれている場合に、これら別々の複数の派生関係を一連につながっている派生関係として推定できる技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
請求項１に係る発明は、操作前の文書を親とし操作後の文書を子とする派生関係の情報と、前記操作後の文書の文書属性と、を第１の情報処理装置から受信する受信手段と、受信した前記派生関係情報を記憶する派生関係情報記憶手段と、受信した前記文書属性を記憶する文書属性記憶手段と、前記文書属性記憶手段から取得した、前記派生関係記憶手段に記憶された派生関係情報群が表す文書の派生関係の木構造の根となる文書の文書属性と、前記派生関係情報群に含まれる文書の文書属性と、の比較に基づいて、前記木構造の根となる文書の親文書となり得る文書を推定する推定手段と、を備えることを特徴とする第２の情報処理装置である。
【００１０】
請求項２に係る発明は、請求項１に係る発明において、前記木構造の根となる文書を子とし、当該木構造の根となる文書の親文書として前記推定手段で推定された文書を親とする派生関係の情報を擬似派生関係情報とし、この擬似派生関係情報を前記派生関係情報群と区別して記憶する擬似派生関係情報記憶手段をさらに備える。
【００１１】
請求項３に係る発明は、請求項２に係る発明において、前記派生関係情報群と、前記擬似派生関係情報記憶手段に記憶された擬似派生関係情報群と、が表す木構造を図式的に表す表示情報であって、当該木構造において、前記派生関係情報群が表す派生関係と、前記擬似派生関係情報群が表す派生関係と、を互いに異なる態様で表す表示情報を生成する表示情報生成手段をさらに備える。
【００１２】
請求項４に係る発明は、操作前の文書を親とし操作後の文書を子とする派生関係の情報と、前記操作後の文書の文書属性と、を第１の情報処理装置から受信する受信ステップと、受信した前記派生関係情報を派生関係情報記憶手段に記憶する派生関係情報記憶ステップと、受信した前記文書属性を文書属性記憶手段に記憶する文書属性記憶ステップと、前記文書属性記憶手段から取得した、前記派生関係記憶手段に記憶された派生関係情報群が表す文書の派生関係の木構造の根となる文書の文書属性と、前記派生関係情報群に含まれる文書の文書属性と、の比較に基づいて、前記木構造の根となる文書の親文書となり得る文書を推定する推定ステップと、をコンピュータに実行させるためのプログラムである。
【００１３】
請求項５に係る発明は、第１の情報処理装置と第２の情報処理装置とを備え、前記第１の情報処理装置は、文書が操作された場合に、操作前の文書を親とし操作後の文書を子とする派生関係の情報を生成する派生関係情報生成手段と、文書の文書属性を取得する文書属性取得手段と、前記派生関係情報生成手段で生成された派生関係情報と、前記文書属性取得手段で取得された前記操作後の文書の文書属性と、を前記第２の情報処理装置に対して送信する送信手段と、を備え、前記第２の情報処理装置は、前記派生関係情報と、前記操作後の文書の文書属性と、を前記第１の情報処理装置から受信する受信手段と、受信した前記派生関係情報を記憶する派生関係情報記憶手段と、受信した前記文書属性を記憶する文書属性記憶手段と、前記文書属性記憶手段から取得した、前記派生関係記憶手段に記憶された派生関係情報群が表す文書の派生関係の木構造の根となる文書の文書属性と、前記派生関係情報群に含まれる文書の文書属性と、の比較に基づいて、前記木構造の根となる文書の親文書となり得る文書を推定する推定手段と、を備えることを特徴とする情報処理システムである。
【発明の効果】
【００１４】
請求項１に係る第２の情報処理装置によれば、本来一連につながっているはずの派生関係が別々の複数の派生関係に分かれていると把握されている場合であっても、これら別々の複数の派生関係を一連につながっている派生関係として推定することができる。
【００１５】
請求項２に係る第２の情報処理装置によれば、第２の情報処理装置において推定した文書の派生関係の情報について、第１の情報処理装置から受信した文書の派生関係の情報とは区別して管理することができる。
【００１６】
請求項３に係る第２の情報処理装置によれば、第２の情報処理装置において推定した文書の派生関係の情報を第１の情報処理装置から受信した文書の派生関係の情報と区別した態様で表示させることができるので、使用者は派生関係が推定された箇所を木構造の図式の中で視認することができる。
【００１７】
請求項４に係るプログラムによれば、本来一連につながっているはずの派生関係が別々の複数の派生関係に分かれていると把握されている場合であっても、これら別々の複数の派生関係を一連につながっている派生関係として推定することができる。
【００１８】
請求項５に係る情報処理システムによれば、本来一連につながっているはずの派生関係が別々の複数の派生関係に分かれていると把握されている場合であっても、これら別々の複数の派生関係を一連につながっている派生関係として推定することができる。
【発明を実施するための最良の形態】
【００１９】
図１は、文書利用管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。
【００２０】
クライアント端末２０について図２を用いて説明する。クライアント端末２０は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複写機などがその一例である。クライアント端末２０は、文書操作部２００，文書属性取得部２１０，及び登録処理部２２０を備える。
【００２１】
文書操作部２００は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示（ユーザから見れば「閲覧」）、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図２では、文書操作部２００を１つだけ示したが、それら個々の操作を別々の操作部（例えば、編集用のアプリケーション、読取制御用のアプリケーションなどといった別々のアプリケーション）が担当してもよい。例えば、文書操作部２００がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部２００は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部２００は、文書に対して操作を行った場合、その操作の結果を表す識別子（ＩＤ）付き文書３００を出力する。
【００２２】
ＩＤ付き文書３００は、図３に示すように、メタ情報３１０と文書内容３２０を含んだ電子文書である。文書内容３２０は、文書操作部２００の操作の結果生成された文書の内容データである。文書操作部２００が電子文書を作成・編集するためのソフトウエアであれば、文書内容３２０はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部２００が電子文書を印刷する装置であれば、文書内容３２０は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部２００が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容３２０は、例えば、その紙文書を読み取って得られる画像データとすればよい。
【００２３】
メタ情報３１０は、文書管理のための情報であり、管理ＩＤ３１２，親ＩＤ３１４，及びログ情報３１６を含む。
【００２４】
管理ＩＤ３１２は、当該ＩＤ付き文書３００自体の一意な識別情報である。親ＩＤ３１４は、当該ＩＤ付き文書３００の親のＩＤ付き文書の管理ＩＤである。すなわち、本実施形態では、あるＩＤ付き文書と、このＩＤ付き文書に対して操作を加えた結果得られる新たなＩＤ付き文書とを、親と子の関係として取り扱う。第１のＩＤ付き文書を操作して第２のＩＤ付き文書が得られた場合、第１のＩＤ付き文書は第２のＩＤ付き文書の親であり、第２のＩＤ付き文書は第１のＩＤ付き文書の子である。したがって、例えば、管理ＩＤ「Ａ」のＩＤ付き文書を文書操作部２００で操作して、その結果得られた新たなＩＤ付き文書の管理ＩＤが「Ｂ」である場合、後者のメタ情報３１０における管理ＩＤ３１２は「Ｂ」であり、親ＩＤ３１４は「Ａ」である。このような親子の関係を、以下では「（管理ＩＤの）派生関係」という。
【００２５】
なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合（この場合、紙文書を読み取った画像を文書内容とするＩＤ付き文書が生成され、本システムに登録される）に生成されるＩＤ付き文書３００では、親ＩＤ３１４は空（すなわち、親は存在しない）となる。
【００２６】
ログ情報３１６は、当該ＩＤ付き文書が生成された際の操作についての、各種の操作履歴を表すログ項目の情報である。ログ項目には、例えばその操作が行われた時刻、その操作の種別、その操作を指示したユーザ（操作者）などがあるが、もちろんこれに限るものではない。操作の種別には、例えば登録（本システムに新規の文書を登録すること）、閲覧、更新（文書内容の変更）、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部２００を用いて第１のＩＤ付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第２のＩＤ付き文書のログ情報３１６は、編集完了の時刻と、その編集を指示したユーザの識別情報と、操作の種別として「更新」と、を含んだものとなる。
【００２７】
図２の説明に戻り、文書操作部２００は、操作結果として上述のようなＩＤ付き文書３００を作成するために、ＩＤ割り当て部２０２及び派生関係組込部２０４を備える。ＩＤ割り当て部２０２は、操作結果のＩＤ付き文書３００に一意な管理ＩＤを付与する手段である。管理ＩＤは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するＩＤ付き文書３００（ただし管理ＩＤ３１２を除いたもの）のハッシュ値を求め、このハッシュ値をその文書３００のＩＤ付き文書とすればよい。ハッシュ関数としてSHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ管理ＩＤを生成することができる。もちろん、システム内で一意な管理ＩＤを各クライアント端末２０で生成する方法は、これに限らない。管理ＩＤを、クライアント端末２０固有の識別情報を含むものとすれば、システム内で一意な管理ＩＤを各クライアント端末２０で生成することができる。
【００２８】
派生関係組込部２０４は、操作結果の文書に対しＩＤ割り当て部２０２が割り当てた新たな管理ＩＤ３１２と、その操作の元になった親文書の管理ＩＤである親ＩＤ３１４（新規登録の場合は、親ＩＤは無し）と、その操作についてのログ情報３１６と、を含むメタ情報３１０を生成する。そして、派生関係組込部２０４は、そのメタ情報３１０を操作結果の文書内容に付加することにより、操作後のＩＤ付き文書３００を生成して出力する。
【００２９】
文書属性取得部２１０は、文書操作部２００で操作される文書の属性情報である文書属性を取得する手段である。文書属性は、文書そのものについての属性情報であり、その文書に対して行われる操作のログ情報３１６とは別の情報である。文書属性は、クライアント端末２０において文書操作部２００のＩＤ割り当て部２０２及び派生関係組込部２０４と独立して機能するシステム及びソフトウエアなどから取得される。
【００３０】
文書属性の例として、文書の記憶された記憶装置上での文書の格納位置を示すファイルパス名、文書の作成日時、文書の作成者などの情報が挙げられる。文書属性の他の例として、その文書に対して行われる操作の制限を定義するセキュリティポリシがある。セキュリティポリシは、例えば、ある文書について、どのユーザに対してどの種類の操作（閲覧、編集など）を許可／禁止するかという規則を表すものである。例えば異なるセキュリティポリシを表す設定情報が複数存在し、これらの設定情報のうちの１つが文書と関連づけられている場合に、そのセキュリティポリシの設定情報を識別する情報をその文書の文書属性とすることができる。また、UUID（Universally Unique Identifier）など、文書固有の識別子を文書に付すことができる場合は、この識別子を文書属性として用いても良い。UUIDは、１２８ビット幅の２進数値であり、文書ファイルの作成日時、文書ファイルが作成された装置のMAC（Media Access Control）アドレス、及び乱数などを組み合わせて生成される識別子である。
【００３１】
文書属性取得部２１０は、例えば、クライアント端末２０のオペレーティングシステムから、文書操作部２００が出力するＩＤ付き文書３００の文書属性３０２を取得することができる。クライアント端末２０のオペレーティングシステムは、クライアント端末２０において操作されるファイルに関する属性情報を管理している。ファイルに関する属性情報は、例えば、ファイルパス名、ファイルを作成したユーザ名、作成日時、及びセキュリティポリシなどである。文書属性取得部２１０は、クライアント端末２０のオペレーティングシステムが管理しているＩＤ付き文書３００の文書ファイルの属性情報を、ＩＤ付き文書３００の文書属性３０２としてオペレーティングシステムから取得することができる。また、クライアント端末２０で操作される文書は、本実施形態の文書操作部２００，文書属性取得部２１０，及び登録処理部２２０とは別の文書管理システムによって管理されることがある。クライアント端末２０がこのような文書管理システムを備えている場合もあるし、ネットワーク３０を介してクライアント端末２０と接続された端末及びサーバなどの装置がこのような文書管理システムを備えている場合もある。このような文書管理システムは、一般に、クライアント端末２０で操作される文書について、その文書の作成者、作成日時、更新日時、更新版を表す情報、セキュリティポリシ、UUIDなどの文書の属性情報を管理する。クライアント端末２０で操作される文書が上述のような文書管理システムによって管理されている場合、文書属性取得部２１０は、この文書管理システムのサービスのインタフェースを通じて、ＩＤ付き文書３００の文書属性３０２を取得することができる。また例えば、文書属性取得部２１０は、クライアント端末２０において文書に対して操作を行うアプリケーションから文書属性３０２を取得することもできる。クライアント端末２０で操作される文書は、その文書ファイル中に、その文書の内容とその文書ファイルの属性情報（ファイルパス名、作成日時、作成者など）とを含むようなデータ形式を有することがある。例えば、電子文書を作成・編集するためのワードプロセッサなどのソフトウエアで操作されるデータ形式及びPDF（Portable Document Format）形式などの文書ファイル中には、その文書の内容の他に、その文書ファイルの属性情報が含まれる。文書ファイル中にその文書ファイルの属性情報を含むようなデータ形式の文書に対して操作を行うアプリケーションは、通常、操作対象となる文書ファイルからその文書ファイルの属性情報を抽出することができる。文書属性取得部２１０は、ＩＤ付き文書３００の文書ファイルについて、文書に対して操作を行うアプリケーションが抽出した属性情報を、ＩＤ付き文書３００の文書属性３０２として取得することができる。ここで、文書属性取得部２１０へ文書ファイルの属性情報を渡す文書操作アプリケーションは、ＩＤ割り当て部２０２及び派生関係組込部２０４を備える本実施形態の文書操作部２００として機能するアプリケーションであっても良いし、ＩＤ割り当て部２００及び派生関係組込部２０４を備えないような、文書操作部２００とは別のアプリケーションであっても良い。
【００３２】
登録処理部２２０は、文書操作部２００が出力したＩＤ付き文書３００及び文書属性取得部２１０が取得したＩＤ付き文書３００の文書属性３０２を文書管理サーバ１０に登録するための処理を実行する。このように各クライアント端末２０が、自ら実行した操作の結果であるＩＤ付き文書３００及びＩＤ付き文書３００の文書属性３０２を文書管理サーバ１０に登録することにより、文書管理サーバ１０は各ＩＤ付き文書３００間の派生関係を把握することができ、各ＩＤ付き文書３００の文書属性３０２を保持することができる。なお、ＩＤ付き文書３００の文書属性３０２は、ＩＤ付き文書３００と別の情報として存在しても良いし、ＩＤ付き文書３００に含まれていても良い。
【００３３】
文書操作部２００が操作の結果出力するＩＤ付き文書３００は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。他の人からＩＤ付き文書３００を受け取った人が、自分のクライアント端末２０の文書操作部２００を用いてそのＩＤ付き文書３００を操作すると、その操作に応じて新たな管理ＩＤを付与されたＩＤ付き文書が生成されることになる。
【００３４】
また、文書操作部２００が電子文書を印刷する場合、管理ＩＤを生成し、その電子文書の印刷結果にその管理ＩＤを埋め込んでもよい。管理ＩＤの埋め込みは、例えば電子文書の印刷画像に、管理ＩＤを示すコード画像を重畳する等の方法で行うことができる。この場合、文書操作部２００は、その管理ＩＤや操作種別「印刷」等のメタ情報を含んだＩＤ付き文書を文書管理サーバ１０に登録する。なお、ＩＤ付き文書を印刷した場合には、そのＩＤ付き文書の管理ＩＤを親ＩＤ３１４として含んだＩＤ付き文書が生成される。印刷操作に対応するＩＤ付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データをなどの印刷データを、文書内容３２０として組み込んでもよい。
【００３５】
また、管理ＩＤが埋め込まれた紙文書を文書操作部２００が読み取った場合、文書操作部２００は、その読み取り操作に対して新たな管理ＩＤを付与し、読み取り結果の画像を文書内容３２０として含んだＩＤ付き文書を生成して文書管理サーバ１０に登録する。このＩＤ付き文書の親ＩＤ３１４には、紙文書から読み取った管理ＩＤがセットされる。管理ＩＤが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。
【００３６】
ここで、クライアント端末２０において文書に対して操作を行うソフトウエアのすべてについて、前述の文書操作部２００の機能を持たせることができるとは限らない。例えば、異なるデータ形式の文書を操作する文書操作部２００が複数存在する場合に、ある文書操作部２００による操作に適したデータ形式を有する文書を、別の文書操作部２００による操作に適したデータ形式を有する文書に変換する「操作」を行うようなソフトウエアについては、操作結果の文書をＩＤ付き文書として出力する文書操作部２００として機能させることが困難である場合がある。このようなソフトウエアの例として、html（HyperText Markup Language）形式の文書を、ワードプロセッサなどの電子文書の作成・編集のソフトウエアで操作されるデータ形式を有する文書に変換する操作を行うソフトウエアや、電子文書の内容をある言語から別の言語へ変換する翻訳ソフトウエアなどが挙げられる。このような、操作結果の文書をＩＤ付き文書として出力する文書操作部２００として機能しないソフトウエア（以下、「非準拠ソフトウエア」と呼ぶ）によって文書に操作が行われた場合、その操作結果の文書はＩＤ付き文書として出力されない。したがって、クライアント端末２０において非準拠ソフトウエアによって文書に対する操作が行われた場合、クライアント端末２０の登録処理部２２０は、その操作結果の文書を文書管理サーバ１０に送信しないため、その操作結果の文書は文書管理サーバ１０に登録されない。非準拠ソフトウエアによる操作結果の文書について、ユーザが文書管理サーバ１０への登録を望む場合、ユーザは、文書操作部２００を用いて、非準拠ソフトウエアによる操作結果の文書を文書管理サーバ１０に新規に「登録」する操作を行う必要がある。この場合、非準拠ソフトウエアによる操作結果の文書は、この文書の操作前の文書が文書管理サーバ１０に登録されたＩＤ付き文書であったとしても、親ＩＤが空である新規の文書として文書管理サーバ１０に登録される。したがって、非準拠ソフトウエアによってＩＤ付き文書に対して操作が行われ、その操作結果の文書が文書管理サーバ１０に登録されると、文書管理サーバ１０は、非準拠ソフトウエアによる操作前の文書と操作後の文書との間に本来存在するはずの派生関係の情報を取得できない。
【００３７】
次に、文書管理サーバ１０について図４を用いて説明する。文書管理サーバ１０は、システム内の複数のクライアント端末２０から送られてくるＩＤ付き文書３００を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。文書管理サーバ１０は、文書データベース（ＤＢ）１００，派生関係ＤＢ１１０，文書属性ＤＢ１２０，擬似派生関係ＤＢ１３０，文書登録部１４０，及び要求処理部１５０を備える。
【００３８】
文書ＤＢ１００は、クライアント端末２０から送られてきたＩＤ付き文書３００のうちの文書内容３２０を格納するデータベースである。文書ＤＢ１００に格納された各文書内容３２０は、一意な内容ＩＤにより管理される。内容ＩＤとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末２０が内容ＩＤを付与してもよく、この場合、内容ＩＤをメタ情報３１０に組み込んでもよい。
【００３９】
派生関係ＤＢ１１０は、そのようなＩＤ付き文書３００のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図５に、派生関係ＤＢ１１０のデータ内容の一例を示す。図５に示した表における１行の情報が、１つのＩＤ付き文書３００に対応するメタ情報レコードである。この例では、各ＩＤ付き文書３００の管理ＩＤに対応づけて、親ＩＤ、操作種類、操作者、操作時刻の各項目が登録されている。このうち、管理ＩＤと親ＩＤのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。また、図５に示す例では、各管理ＩＤに対応付けて、管理ＩＤの派生関係が表す木構造のツリー番号及びノード番号も登録されている。派生関係ＤＢ１１０内の管理ＩＤの派生関係は、複数の「登録」操作をそれぞれの根とする複数の独立した木構造を表す。ツリー番号は、この複数の木構造（ツリー）を識別する識別情報であり、ノード番号は、１つのツリーに含まれるノードを識別する識別情報である。図５に示す例では、木構造の根となるノードのノード番号を０としている。
【００４０】
なお、図５は派生関係ＤＢ１１０が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係ＤＢ１１０は、一般的なリレーショナルデータベースとして構築することもできるし、管理ＩＤを除くメタ情報を記述したＸＭＬ(eXtensible Markup Language)文書を、管理ＩＤをキーとして登録したデータベースとして構築することもできる。
【００４１】
なお、文書ＤＢ１００に登録された文書内容と派生関係ＤＢ１１０に登録されたメタ情報との対応関係は、図６に示すような対応関係情報により管理される。この対応関係情報は、管理ＩＤに対応づけて文書内容の内容ＩＤを記録したものである。対応関係情報は、文書ＤＢ１００が持っていてもよいし、派生関係ＤＢ１１０が持っていてもよい。
【００４２】
図５に示した派生関係ＤＢ１１０のデータ内容は、図７Ａ，図７Ｂのような木構造を表す。これは、管理ＩＤをノードとし、管理ＩＤ間の親子関係をエッジとする木構造である。図７Ａは、図５の管理ＩＤ"文書１"から"文書５"までの文書の派生関係が表す木構造（ツリー０）を示し、図７Ｂは、図５の管理ＩＤ"文書６"から"文書１０"までの文書の派生関係が表す木構造（ツリー１）を示す。
【００４３】
図５に例示する管理ＩＤ"文書１"から"文書５"までの文書の履歴について、図５〜図７Ａを参照して時系列順に説明すると、以下のようになる。まず、文書管理サーバ１０に登録されていなかった文書の「登録」操作がユーザ１のクライアント端末で実行される。これに応じて管理ＩＤが"文書１"、親ＩＤが空、操作種類が「登録」であるメタ情報と、その文書の文書内容とを含むＩＤ付き文書"文書１"と、このＩＤ付き文書"文書１"の文書属性がユーザ１のクライアント端末から文書管理サーバ１０に送られる。これに応じ、文書管理サーバ１０は、そのＩＤ付き文書"文書１"中の文書内容を文書ＤＢ１００へ、メタ情報を派生関係ＤＢ１１０に、"文書１"の文書属性を文書属性ＤＢ１２０にそれぞれ登録する。登録された文書内容は内容ＩＤ"Content1"に対応づけて管理される。ＩＤ付き文書"文書１"はその後ユーザ２のクライアント端末上で編集（「更新」）され、その編集結果のＩＤ付き文書"文書２"が文書管理サーバ１０に登録される。次にユーザ３が"文書２"を閲覧し、その結果であるＩＤ付き文書"文書３"を文書管理サーバ１０に登録するが、"文書３"の文書内容は、"文書２"の文書内容と同じである。次にユーザ２によるＩＤ付き文書"文書２"の編集（「更新」）に応じて、編集結果のＩＤ付き文書"文書４"が文書管理サーバ１０に登録される。さらにその後、ユーザ１によりＩＤ付き文書"文書１"が閲覧され、閲覧結果のＩＤ付き文書"文書５"が文書管理サーバ１０に登録される。
【００４４】
文書属性ＤＢ１２０は、クライアント端末２０から受信したＩＤ付き文書３００の文書属性３０２を格納するデータベースである。図８に、文書属性ＤＢ１２０のデータ内容の一例を示す。図８に示した表における１行の情報が、１つのＩＤ付き文書３００に対応する文書属性レコードである。この例では、各ＩＤ付き文書３００の管理ＩＤに対応づけて、ツリー番号、ノード番号、及び文書属性の各項目が登録されている。図８に示す例では、文書属性として、ファイルパス名、作成日時、及び作成者の各項目が登録されている。他の項目を文書属性としてクライアント端末２０から受信した場合は、管理ＩＤと対応づけてこの他の項目を登録しても良い。管理ＩＤと文書属性との各項目が対応づけられていれば、ツリー番号及びノード番号は文書属性ＤＢ１２０に登録しなくても良い。
【００４５】
擬似派生関係ＤＢ１３０は、後に詳述する派生関係推定部１５２において推定された文書間の派生関係を、クライアント端末２０から受信した派生関係と区別して記憶するデータベースである。図９に、擬似派生関係ＤＢ１３０のデータ内容の一例を示す。図９に示した表における１行の情報が、１つのＩＤ付き文書３００に対応するレコードである。この例では、各管理ＩＤに対応づけて、ツリー番号、ノード番号、親ノード番号、擬似親ノード記述、擬似子ツリー番号、及び擬似派生関係フラグの各項目が登録されている。親ノード番号は、各ノード（管理ＩＤ）の親となるノードをそのツリー内のノード番号で表したものである。擬似親ノード記述は、各管理ＩＤの親となり得るノードとして派生関係推定部１５２で推定されたノードのツリー番号及びノード番号を記述したものである。擬似子ツリー番号は、各管理ＩＤの子となり得るノードとして派生関係推定部１５２で推定された根ノードについて、そのツリー番号を記述したものである。擬似親ノード記述及び擬似子ツリー番号は、推定されたノードがない場合は空である。擬似派生関係フラグは、木構造の根ノードについて、その根ノードの親となり得るノードが推定されている場合はTRUEに設定され、推定されていない場合はFALSEに設定される。擬似派生関係ＤＢ１３０は、各管理ＩＤと、その管理ＩＤについて推定された擬似親ノードと、その管理ＩＤについて推定された擬似子ノードと、を対応づけるデータベースであれば、図９に示した形式に限定されない。例えば、擬似親ノード及び擬似子ノードについて、ツリー番号及びノード番号で特定するのではなく、そのノードの管理ＩＤを記憶しておいても良い。また、例えば、管理ＩＤ、擬似親ノード、及び擬似子ノード以外の項目がないデータベースであっても良い。擬似派生関係ＤＢ１３０において各管理ＩＤに対応づけられた内容を、派生関係ＤＢ１１０内に持たせても良い。
【００４６】
文書登録部１４０は、クライアント端末２０から受信したＩＤ付き文書３００の中の文書内容を文書ＤＢ１００に、メタ情報を派生関係ＤＢ１１０に、ＩＤ付き文書３００の文書属性３０２を文書属性ＤＢ１２０に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部１４２であり、文書属性の登録を担当するのが文書属性登録部１４４である。
【００４７】
要求処理部１５０は、クライアント端末２０からの管理ＩＤを含んだサービス要求に応じて、派生関係ＤＢ１１０及び擬似派生関係ＤＢ１２０を用いたサービスを提供する。要求処理部１５０が提供するサービスとしては、例えば、サービス要求中の管理ＩＤの来歴、すなわち始祖からその管理ＩＤまでに文書が経てきた操作の履歴（例えば誰がいつどんな操作をしたのかを示す情報のリスト）を表示するサービスがある。また、例えば、サービス要求中の管理ＩＤが生成された後に文書に対して行われた操作の履歴を表示することもできる。また別の例として、サービス要求中の管理ＩＤに対応する始祖の文書又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、サービス要求中の管理ＩＤに対応する文書の最新版を検索するサービスがある。
【００４８】
サービス要求は、クライアント端末２０に保持されたＩＤ付き文書に基づき発せられる。例えば、ユーザがクライアント端末２０の文書操作部２００によりＩＤ付き文書を開いた場合に、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付け、そのＩＤ付き文書の管理ＩＤと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ１０の要求処理部１５０に送信する。
【００４９】
また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理ＩＤを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のＩＤ付き文書の管理ＩＤを親ＩＤとして含んだＩＤ付き文書を生成し、このＩＤ付き文書をサービス要求として文書管理サーバ１０に送ってもよい。この場合、要求処理部１５０は、受け取ったＩＤ付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくＩＤ付き文書内の親ＩＤを、派生関係を用いた処理の起点とする。
【００５０】
要求処理部１５０は、クライアント端末２０からサービス要求を受けた場合、そのサービス要求中に指定された管理ＩＤ及びサービス要求の内容に応じて、派生関係ＤＢ１１０及び擬似派生関係ＤＢ１３０に登録された管理ＩＤと親ＩＤとの派生関係が構成する木を走査（トラバース）し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。
【００５１】
本実施形態では、要求処理部１５０は、派生関係推定部１５２及び表示情報生成部１５４を備える。派生関係推定部１５２は、クライアント端末２０からサービス要求を受けた場合、サービス要求中に指定された管理ＩＤが属する木に含まれるノードの子又は親となり得るノードを、サービス要求中に指定された管理ＩＤが属する木以外の木に含まれるノードの中から推定する処理を行う。表示情報生成部１５４は、クライアント端末２０から、指定された管理ＩＤに対応する文書の履歴を表示するサービス要求を受けた場合に、派生関係ＤＢ１１０及び擬似派生関係ＤＢ１３０を参照して、クライアント端末２０に表示させる表示情報を生成し、生成した表示情報をクライアント端末２０へ送る処理を行う。派生関係推定部１５２及び表示情報生成部１５４で行われる処理については後に詳述する。
【００５２】
次に、本実施形態のシステムで行われる処理の内容を詳しく説明する。まず、文書に対して操作が行われたときのクライアント端末の処理手順の一例を説明する。文書に対する操作が行われた場合、文書操作部２００は操作後の文書に対する管理ＩＤを生成する。そして文書操作部２００は、その操作に関する各種情報をオペレーティングシステムやその他のシステムから取得してメタ情報を生成し、そのメタ情報と操作後の文書内容とを含むＩＤ付き文書を生成し、そのＩＤ付き文書を文書属性取得部２１０及び登録処理部２２０に渡す。文書属性取得部２１０は、文書操作部２００から受け取ったＩＤ付き文書について、クライアント端末２０において文書操作部２００とは別のオペレーティングシステム及びその他のシステムなどからその文書の属性情報を取得し、取得した属性情報を文書操作部２００から受け取ったＩＤ付き文書の文書属性として、登録処理部２２０に渡す。登録処理部２２０は、文書操作部２００からＩＤ付き文書を受け取り、このＩＤ付き文書の文書属性を文書属性取得部２１０から受け取ると、このＩＤ付き文書及びこのＩＤ付き文書の文書属性を文書管理サーバ１０に登録する。
【００５３】
次に、ＩＤ付き文書及びこのＩＤ付き文書の文書属性をクライアント端末２０から受信したときに文書管理サーバ１０の文書登録部１４０が実行する処理の例を説明する。まず文書登録部１４０は、受信したＩＤ付き文書中の文書内容を文書ＤＢ１００に、メタ情報を派生関係ＤＢ１１０に、受信したＩＤ付き文書の文書属性を文書属性ＤＢ１２０に、それぞれ登録する。次に、文書登録部１４０の派生関係登録部１４２は、そのＩＤ付き文書中のメタ情報に親ＩＤが含まれるか否かを判定する。親ＩＤが含まれていれば、その親ＩＤの値を管理ＩＤとして持つレコードに含まれるツリー番号を、受信したＩＤ付き文書の管理ＩＤのツリー番号としてこの管理ＩＤのレコードに登録する。そして、そのツリー番号を有する他のノードのノード番号と重複しないノード番号を生成し、生成したノード番号を受信したＩＤ付き文書の管理ＩＤのノード番号としてこの管理ＩＤのレコードに登録する。受信したＩＤ付き文書中のメタ情報に親ＩＤが含まれていなければ、派生関係ＤＢ１１０内に存在しないツリー番号を新たに生成し、生成したツリー番号と、根ノードであることを表すノード番号０と、を受信したＩＤ付き文書の管理ＩＤのレコードに登録する。その後、派生関係登録部１４２は、擬似派生関係ＤＢ１３０に、受信したＩＤ付き文書の管理ＩＤと、このＩＤ付き文書の管理ＩＤのツリー番号及びノード番号として登録された値と、を関連付けて登録する。さらに、文書登録部１４０の文書属性登録部１４４は、受信したＩＤ付き文書の管理ＩＤのツリー番号及びノード番号として登録された値を、文書属性ＤＢ１２０内のその管理ＩＤのツリー番号及びノード番号として登録する。ここで説明した処理の例では、各管理ＩＤについて、ツリー番号及びノード番号を付与する。こうすることで、文書管理サーバ１０で行われる後の処理が簡単になる。しかし、管理ＩＤと親ＩＤとの派生関係があれば、木構造の情報を得ることができるので、ツリー番号及びノード番号の付与は必ずしも行わなくても良い。
【００５４】
次に、クライアント端末２０から管理ＩＤの指定を含むサービス要求を受けた場合の派生関係推定部１５２及び表示情報生成部１５４の処理の例を説明する。ここでは、指定された管理ＩＤに対応する文書の履歴情報を提供するよう要求するサービス要求をクライアント端末２０から受けた場合の処理を例に説明する。図１０を参照すると、ステップＳ１で、派生関係推定部１５２は、クライアント端末２０から受信したサービス要求中で指定された管理ＩＤを取得する。次に、ステップＳ２で、派生関係推定部１５２は、擬似派生関係ＤＢ１３０を参照し、指定管理ＩＤと関連づけられたツリー番号を取得し、取得したツリー番号と同じツリー番号を有する管理ＩＤ（ノード）を１つ選択する。
【００５５】
ステップＳ３では、派生関係推定部１５２は、ステップＳ２で選択したノードを推定対象のノードとして子ノード推定処理を行う。子ノード推定処理は、推定対象のノードの文書に対する操作の結果生成されたにも関わらず新規文書として文書管理サーバ１０に登録された可能性のあるノードを推定する処理である。
【００５６】
図１１に、ステップＳ３の子ノード推定処理の詳細な手順の例を示す。ステップＳ３の子ノード推定処理が開始されると、図１１に例示する手順に従った処理が開始される。図１１を参照すると、まずステップＳ４１で、派生関係推定部１５２は、文書属性ＤＢ１２０を参照し、推定対象のノードの文書属性を取得する。例えば、図８に例示する表の内容が文書属性ＤＢ１２０に登録されている場合において、ステップＳ２（図１０）で選択された推定対象のノードが管理ＩＤ"文書５"のノードである場合、図８に示す表の"文書５"に対応するレコードが取得される。
【００５７】
次に、ステップＳ４２で、派生関係推定部１５２は、文書属性ＤＢ１２０を参照し、推定対象のノードが含まれる木と異なる木の根ノードの中から、文書属性に関して予め設定された検索条件を満たすノードの文書属性レコードを検索する。つまり、推定対象のノードのツリー番号と異なるツリー番号を有するノードであってノード番号が０であるノードを検索対象として、検索対象のノードの文書属性と推定対象のノードの文書属性とを比較した結果、予め設定された検索条件を満たす検索対象のノードを抽出する。
【００５８】
ここで設定される検索条件は、文書属性ＤＢ１２０に登録された文書属性の各項目の内容に関する条件である。例えば、文書属性のある項目について推定対象のノードと同一の内容を有する検索対象のノードを抽出するような検索条件を設定できる。また例えば、推定対象のノードの文書属性のある項目の内容を示す文字列と、検索対象のノードのその項目の内容を示す文字列と、の間に、所定の割合以上共通の文字が存在する場合にその検索対象のノードを抽出するようにしても良い。また、複数の検索条件を論理式で組み合わせて適用しても良い。また、例えば、推定対象のノードの文書属性のある項目の内容と検索対象のノードの文書属性のその項目の内容とが類似する程度や、推定対象のノードの文書属性の項目の内容と検索対象の文書属性の項目の内容とが同一である項目の数などに基づいて検索対象のノードを順位付けする検索条件を設定することもできる。
【００５９】
図１２に、管理ＩＤ"文書５"のノードが推定対象のノードである場合に、「『ファイルパス名が拡張子部分を除いて推定対象のノードのファイルパス名と同一』、『作成日時が推定対象のノードの作成日時よりも後』、『作成者が推定対象のノードの作成者と同一であれば高順位とする』、及び『作成日時が推定対象のノードの作成日時に近いほど高順位とする』」という検索条件で文書属性ＤＢ１２０から抽出され、順位付けされたレコードの例を示す。図１２に示す表では、"文書６"，"文書１６３"，及び"文書９７８"の３つのレコードが抽出されている。これらのレコードは、文書属性として、"文書５"のファイルパス名「/home/user/仕様書_v2.html」と拡張子部分（.html）を除いて同一のファイルパス名「/home/user/仕様書_v2.doc」を有し、かつ、"文書５"の作成日時「2006/09/20 12:00」よりも後の作成日時を有する。また、図１２に示す例を参照すると、作成者が"文書５"の作成者「ユーザ１」と同一であり、作成日時が"文書５"の作成日時「2006/09/20 12:00」と最も近い、"文書６"のレコードが最も高順位とされている。ステップＳ４２における検索処理において抽出されたノードのうち、最も高順位のノード（図１２の例では、"文書６"）が、推定対象のノードの子となり得るノードとして選択される。ステップＳ４２において、検索対象のノード中に検索条件を満たすノードが存在しない場合は、推定対象のノードの子となり得るノードは選択されない。
【００６０】
次に、ステップＳ４３で、推定対象のノードの子となり得るノードが存在するか否かを判定する。ステップＳ４３では、ステップＳ４２における検索処理の結果、推定対象のノードの子となり得るノードとして選択されたノードが存在すれば、処理はステップＳ４４に進む。ステップＳ４２における検索処理の結果、推定対象のノードの子となり得るノードとして選択されたノードが存在しなければ、ステップＳ４３で推定対象のノードの子となり得るノードが存在しないと判定され、ステップＳ４４の処理を行わずに子ノード推定処理を終了する。
【００６１】
ステップＳ４４では、派生関係推定部１５２は、ステップＳ４２で推定した派生関係を擬似派生関係ＤＢ１３０に登録する。例えば、図９に示すように、"文書５"の擬似子ツリー番号を１に、"文書６"の擬似親ノード記述を「ツリー：０、ノード：４」と設定する。
【００６２】
再び図１０に戻って、ステップＳ３の子ノード推定処理が終了すると、ステップＳ４で、指定管理ＩＤが属する木に含まれる全ノードについて処理が行われたか否かを判定する。全ノードについて処理が行われていなければ、ステップＳ２に戻り、ステップＳ２からステップＳ４までの処理が繰り返される。全ノードについて処理が行われていれば、ステップＳ５に進む。ステップＳ５では、派生関係推定部１５２は、擬似派生関係ＤＢ１３０を参照し、指定管理ＩＤが属する木の根ノード（ノード番号０のノード）の擬似派生関係フラグを確認する。擬似派生関係フラグがFALSEであれば、根ノードの親ノードとして推定されたノードが存在しないと判定し、ステップＳ６の親ノード推定処理に進む。擬似派生関係フラグがTRUEであれば、根ノードの親ノードとして推定されたノードがすでに存在すると判定し、ステップＳ７に進む。
【００６３】
ステップＳ６では、派生関係推定部１５２は、指定管理ＩＤが属する木の根ノードを推定対象のノードとして親ノード推定処理を行う。図１３に、ステップＳ６の親ノード推定処理の詳細な手順の例を示す。ステップＳ６の処理が開始されると、図１３に例示する手順に従った処理が開始される。図１３を参照すると、親ノード推定処理では、ステップＳ７１で、派生関係推定部１５２は、文書属性ＤＢ１２０を参照し、推定対象のノードの文書属性を取得する。例えば、図８に例示する表の内容が文書属性ＤＢ１２０に登録されている場合において、指定管理ＩＤが属する木の根ノードが管理ＩＤ"文書１"のノードである場合、図８に示す表の"文書１"に対応するレコードが取得される。
【００６４】
次に、ステップＳ７２で、派生関係推定部１５２は、文書属性ＤＢ１２０を参照し、推定対象のノードが含まれる木と異なる木のノードの中から、文書属性に関して予め設定された検索条件を満たすノードの文書属性レコードを検索する。つまり、推定対象のノードのツリー番号と異なるツリー番号を有するノードを検索対象として、検索対象のノードの文書属性と推定対象のノードの文書属性とを比較した結果、予め設定された検索条件を満たす検索対象のノードを抽出する。
【００６５】
ここで設定される検索条件は、図１１及び図１２を参照して説明した子ノード推定処理のステップＳ４２の処理における検索条件と同様、文書属性ＤＢ１２０に登録された文書属性の各項目の内容に関する条件である。ここでの検索条件としては、検索対象のノードの中から推定対象のノードの親となり得るノードとして適したノードを抽出できるような条件を設定すると良い。例えば、親ノード推定処理は、推定対象のノードの文書の派生元となった文書のノードを推定する処理なので、作成日時について検索条件を設定する場合、「作成日時が推定対象のノードの作成日時より前」という条件とすることが好適である。また、図１１及び図１２を参照して説明した子ノード推定処理における検索条件と同様に、検索対象のノードを順位付けする条件を設定できる。ステップＳ７２における検索処理において抽出されたノードのうち、最も高順位のノードが、推定対象のノードの親となり得るノードとして選択される。ステップＳ７２において、検索対象のノード中に検索条件を満たすノードが存在しない場合は、推定対象のノードの親となり得るノードは選択されない。
【００６６】
次に、ステップＳ７３において、推定対象のノードの親となり得るノードが存在するか否かを判定する。ステップＳ７３では、ステップＳ７２における検索の結果、推定対象のノードの親となり得るノードとして選択されたノードが存在すれば、処理はステップＳ７４に進む。ステップＳ７２における検索の結果、推定対象のノードの親となり得るノードとして選択されたノードが存在しなければ、ステップＳ７３で推定対象のノードの親となり得るノードが存在しないと判定され、ステップＳ７４の処理を行わずに親ノード推定処理を終了する。
【００６７】
ステップＳ７４では、派生関係推定部１５２は、ステップＳ７３で推定した派生関係を擬似派生関係ＤＢ１３０に登録する。
【００６８】
再び図１０に戻って、ステップＳ６の親ノード推定処理が終了すると、ステップＳ７で、表示情報生成部１５４は、派生関係ＤＢ１１０及び擬似派生関係ＤＢ１３０を参照し、指定管理ＩＤを含む木構造を図式的に表す表示情報を生成する。表示情報生成部１５４が生成した表示情報はクライアント端末２０へ送信される。クライアント端末２０は、受信した表示情報に従って、指定管理ＩＤを含む木構造を表示手段に表示させる。
【００６９】
図１４に、表示情報生成部１５４が生成した表示情報に従ってクライアント端末２０の表示手段に表示される木構造の図の例を示す。図１４は、図５に例示する表のデータ内容が派生関係ＤＢ１１０に記憶され、図９に例示する表のデータ内容が擬似派生関係ＤＢ１３０に記憶されている場合において、指定管理ＩＤが"文書２"である場合にクライアント端末２０の表示手段に表示される木構造の図の例である。図１４を参照すると、指定管理ＩＤ"文書２"を表すアイコン４００と、"文書２"を含むツリー（ツリー番号０。図５参照。）に含まれる"文書１"，"文書３"，"文書４"，"文書５"をそれぞれ表すアイコン４０２，４０４，４０６，４０８と、"文書５"の擬似子ツリー（ツリー番号１。図９参照。）に含まれる"文書６"，"文書７"，"文書８"，"文書９"，"文書１０"をそれぞれ表すアイコン４１０，４１２，４１４，４１６，４１８と、を含む派生関係の木構造が示される。派生関係の木構造は、派生関係ＤＢ１１０及び擬似派生関係ＤＢ１３０を参照することで生成できる。図１４に示す例では、文書管理サーバ１０の派生関係推定部１５２が推定し、擬似派生関係ＤＢ１３０に登録した派生関係である"文書５"と"文書６"との間の派生関係は破線で、その他の文書間の派生関係、すなわち文書管理サーバ１０がクライアント端末２０から受信して派生関係ＤＢ１１０に登録した派生関係は実線で表示される。表示情報生成部１５４は、クライアント端末２０から受信した派生関係と派生関係推定部１５２で推定された派生関係とを異なる態様で表示させるような表示情報を生成する。クライアント端末２０から受信した派生関係と派生関係推定部１５２で推定された派生関係とを表示させる態様は図１４に例示する態様に限られない。例えば、クライアント端末２０から受信した派生関係によって生成される指定管理ＩＤを含むツリーに含まれる文書のアイコン（図１４の例では、アイコン４００〜４０８）と、派生関係推定部１５２において推定された擬似子ツリーに含まれる文書のアイコン（図１４の例では、アイコン４１０〜４１８）と、を異なる色で表示させることとしても良い。
【００７０】
また、図１４に示す例では、各文書を示すアイコン４００〜４１８について、各文書を識別するための情報として、その文書の管理ＩＤ、操作日時、操作者、及び操作の種類が表示される。各文書を識別するために表示される情報は、派生関係ＤＢ１１０に登録されたレコードから取得できる。各文書を識別するために各文書を示すアイコンに表示される情報の項目は、図１４に例示した項目に限られない。
【００７１】
以上、クライアント端末２０から、指定された管理ＩＤに対応する文書の履歴を表示するサービスについてのサービス要求があった場合の処理について説明した。文書の履歴を表示するサービス以外の派生関係を用いたサービス（例えば更新文書の提供など）についてのサービス要求があった場合に、図１０のステップＳ１からステップＳ６までの処理を行って派生関係を推定した後、派生関係ＤＢ１１０に登録された派生関係及び擬似派生関係ＤＢ１３０に登録された擬似派生関係を用いて、サービス要求に応じた処理を行うこともできる。
【００７２】
以上、クライアント端末２０からのサービス要求に応じて、サービス要求中の管理ＩＤを含む木構造について派生関係推定部１５２が処理を行う実施形態の例について説明した。他の１つの実施形態では、クライアント端末２０が文書管理サーバ１０にＩＤ付き文書を新規に登録した場合に、この新規に登録された文書の親文書となり得る文書を推定する処理を文書管理サーバ１０が行うようにしても良い。図１５に、ＩＤ付き文書の新規登録の際に派生関係の推定処理が行われる実施形態の文書管理サーバ１０のブロック図の例を示す。図１５において、図４と同様の構成要素については図４と同じ符号を付し、その詳細な説明を省略する。
【００７３】
図１５を参照すると、派生関係推定部１６０は、派生関係登録部１４２及び文書属性登録部１４４から、それぞれ、新規登録されるＩＤ付き文書の管理ＩＤ及び文書属性を取得し、文書属性ＤＢ１２０及び擬似派生関係ＤＢ１３０を参照して、新規登録されるＩＤ付き文書の親となり得る文書を推定する処理を行う。
【００７４】
以下、図１５に例示する文書管理サーバ１０において、クライアント端末２０からＩＤ付き文書及びこのＩＤ付き文書の文書属性を受信した場合の処理の例について説明する。まず、文書登録部１４０は、受信したＩＤ付き文書中の文書内容を文書ＤＢ１００に、メタ情報を派生関係ＤＢ１１０に、受信したＩＤ付き文書の文書属性を文書属性ＤＢ１２０に、それぞれ登録する。この登録処理とともに、文書登録部１４０は、受信したＩＤ付き文書中のメタ情報及び受信したＩＤ付き文書の文書属性を派生関係推定部１６０に渡す。次に、派生関係登録部１４２は、受信したＩＤ付き文書の管理ＩＤについて、図４を参照して説明したツリー番号及びノード番号の設定の処理と同様の処理を行ってツリー番号及びノード番号を設定し、設定したツリー番号及びノード番号を派生関係ＤＢ１１０においてこの管理ＩＤのレコードに登録する。文書属性登録部１４４は、受信したＩＤ付き文書の管理ＩＤについて派生関係登録部１４２で設定されたツリー番号及びノード番号を文書属性ＤＢ１２０においてこの管理ＩＤのレコードに登録する。
【００７５】
ＩＤ付き文書中のメタ情報及びＩＤ付き文書の文書属性を文書登録部１４０から取得した派生関係推定部１６０は、このメタ情報のログ情報中の操作種類を参照し、その操作種類が「登録」操作である場合、この管理ＩＤ（ノード）について、親となり得るノードを推定する親ノード推定処理を行う。ここで派生関係推定部１６０は、例えば、取得したＩＤ付き文書の管理ＩＤに対応するノードを推定対象のノードとして、図１３を参照して説明した親ノード推定処理と同様の処理を行う。取得したＩＤ付き文書中のメタ情報のログ情報中の操作種類が「登録」以外の操作である場合は、派生関係推定部１６０は、親ノード推定処理を行わない。ＩＤ付き文書中のメタ情報のログ情報中の操作種類を参照する代わりに、メタ情報中の親ＩＤが空である場合に派生関係推定部１６０が親ノード推定処理を行い、メタ情報中に親ＩＤが存在する場合に親ノード推定処理を行わないこととしても良い。
【００７６】
さらに他の１つの実施形態では、派生関係推定部１６０は、文書管理サーバ１０に文書が新規に登録される度にその新規登録された文書について親ノード推定処理を行うのではなく、予め設定された時間間隔で、その時間の間に新規登録された文書について親ノード推定処理を行っても良い。例えば、予め設定された時間の間に新規登録された文書について、派生関係ＤＢ１１０内のその文書に対応するレコードにフラグを設定しておき、設定された時間が経過したときに、フラグが設定された文書のノードを推定対象のノードとして、図１３に示すような親ノード推定処理を行うようにすることができる。
【００７７】
以上で説明した実施形態では、本来一連につながっているはずの派生関係が別々の複数の派生関係に分かれていると把握される場合の例として、非準拠ソフトウエアによってＩＤ付き文書に対して操作が行われ、その操作結果の文書が文書管理サーバ１０に登録される場合について述べた。しかし、上記実施形態の方式の適用対象は、そのような場合に限らない。例えば、一連の派生関係の情報の一部が欠落する状況の他の例として、文書操作部２００の操作の結果ＩＤ付き文書を生成したにもかかわらずそのＩＤ付き文書がクライアント端末２０から文書管理サーバ１０に登録されないという状況を挙げることができる。ネットワーク３０に障害が生じていたり、クライアント端末２０とネットワーク３０の接続が断たれていたり、文書管理サーバ１０に障害が生じていたりする場合などのように、クライアント端末２０が文書管理サーバ１０にアクセスできない場合が、そのような状況の一例である。例えば、クライアント端末２０が文書管理サーバ１０にアクセスできない場合にクライアント端末２０において管理ＩＤ"文書１"の文書が操作されて管理ＩＤ"文書２"の文書が生成され、"文書２"を管理ＩＤとし"文書１"を親ＩＤとするＩＤ付き文書が文書管理サーバ１０に登録されなかったとする。その後、文書管理サーバ１０へアクセスできる他のクライアント端末２０に管理ＩＤ"文書２"の文書が送られ、そのクライアント端末２０において"文書２"が操作され、"文書２"を親ＩＤとする管理ＩＤ"文書３"のＩＤ付き文書が生成され、この"文書３"が文書管理サーバ１０登録されたとする。この場合、文書管理サーバ１０は、"文書３"が未知の"文書２"から派生した文書であることは認識できるが、"文書３"の先祖が"文書１"であることまでは把握できない。しかし、この場合、"文書３"が登録された時点で文書管理サーバ１０内に"文書２"が登録されていないことは検知できるので、その"文書３"を暫定的に根ノードとして扱うことができる。このようにすれば"文書３"を、上述の非準拠ソフトウエアにより操作された後に登録された文書と同様に取り扱うことができる。
【００７８】
例えば、上述のように、文書管理サーバ１０がクライアント端末２０から受信したＩＤ付き文書中のメタ情報に含まれる親ＩＤを管理ＩＤとして持つレコードが派生関係ＤＢ１１０内に存在しない場合、文書登録部１４０は、この受信したＩＤ付き文書の管理ＩＤのレコードを派生関係ＤＢ１１０に登録する際に、この管理ＩＤの親ＩＤの文書が未知であることを示すフラグを設定しておくことができる。そして、このフラグが設定された管理ＩＤのノードを、親ＩＤが空である根ノードと同様に扱って前述のような子ノード推定処理又は親ノード推定処理を行うことができる。例えば、図１１を参照して説明した子ノード推定処理において、親ＩＤが空である根ノード及び親ＩＤの文書が未知であることを示すフラグが設定されたノードをステップＳ４２の処理における検索対象のノードとして処理することができる。また例えば、親ＩＤの文書が未知であることを示すフラグが設定されたノードを推定対象のノードとして、図１３を参照して説明した親ノード推定処理を行うこともできる。
【００７９】
なお、その後クライアント端末２０が文書管理サーバ１０にアクセス可能となった場合に、それまで登録できなかったＩＤ付き文書がクライアント端末２０から文書管理サーバ１０に登録されることも考えられる。この登録により正しい派生関係が文書管理サーバ１０に登録されることになるので、推定した疑似的な派生関係は削除する。例えば以下のような流れとなる。
【００８０】
クライアント端末２０の登録処理部２２０は、クライアント端末２０が文書管理サーバ１０にアクセスできない場合に文書操作部２００によってＩＤ付き文書３００が出力されると、そのＩＤ付き文書３００及びこのＩＤ付き文書３００の文書属性をクライアント端末２０の一時記憶部（図示しない）に保管しておくことができる。その後、文書管理サーバ１０にアクセス可能となったときに、登録処理部２２０は、一時記憶部に保管されたＩＤ付き文書３００及びこのＩＤ付き文書３００の文書属性をサーバ１０に登録するようにすることができる。クライアント端末２０がこのような処理を行う場合、文書管理サーバ１０は、クライアント端末２０からＩＤ付き文書を受信したときに、派生関係ＤＢ１１０内の親ＩＤの文書が未知であることを示すフラグが設定されたレコードのうち、受信したＩＤ付き文書の管理ＩＤを親ＩＤとして持つレコードについて、当該フラグの設定を解除する。このようなレコードの親ＩＤの文書が文書管理サーバ１０にとって未知でなくなるからである。さらに、当該フラグの設定を解除したレコードのノードに関して派生関係推定部が推定した派生関係を擬似派生関係ＤＢ１３０から削除する。
【００８１】
以上に例示した実施形態では、管理ＩＤの発行は各クライアント端末２０で行われていたが、この代わりに文書管理サーバ１０が管理ＩＤを発行してもよい。この場合、クライアント端末２０は、ＩＤ付き文書に対して操作を行った場合、操作前のＩＤ付き文書内の管理ＩＤを親ＩＤ３１４として含み、更にその操作についてのログ情報３１６と操作後の文書内容３２０とを含み、管理ＩＤ３１２は空欄の文書データを生成し、その操作後の文書について取得した文書属性と共に文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書データに対して新たな管理ＩＤを付与し、この管理ＩＤとその文書データとに含まれる情報を、文書ＤＢ１００、派生関係ＤＢ１１０、及び文書属性ＤＢ１２０に登録する。また、文書管理サーバ１０は、付与した管理ＩＤを当該文書データにセットすることによりＩＤ付き文書を生成し、これをクライアント端末２０に返す。クライアント端末２０は、操作前のＩＤ付き文書を、受け取ったＩＤ付き文書に置き換える。このように、文書管理サーバ１０が管理ＩＤを付与する構成でも、上述の実施形態の処理は同様に実行できる。
【００８２】
また以上の実施形態及び変形例では、管理ＩＤ３１２、親ＩＤ３１４、ログ情報３１６、及び文書内容３２０を含んだＩＤ付き文書３００がクライアント端末２０に保存されたが、この代わりに、クライアント端末２０は管理ＩＤしか持たず、その他の情報は文書管理サーバ１０に保存されるようにしてもよい。この場合、クライアント端末２０で文書を操作する場合、その文書に対応する管理ＩＤを文書管理サーバ１０に送り、文書管理サーバ１０からその文書を取得する。
【００８３】
ここで、文書管理サーバ１０が管理ＩＤを付与する場合は、その取得の操作に対応する管理ＩＤを文書管理サーバ１０が生成し、その管理ＩＤと文書とを対応づけてクライアント端末２０に提供するとともに、その取得操作についてのログ情報（操作時刻や操作者など）と、元の管理ＩＤ（すなわち親ＩＤ）と、付与した管理ＩＤとを派生関係ＤＢ１１０に記録する。クライアント端末２０は、文書管理サーバ１０に送信した管理ＩＤを、受け取った管理ＩＤに置き換えると共に、受け取った文書を開く。ユーザは、開かれた文書に対して閲覧や編集などの操作を行う。クライアント端末２０は、文書に対する操作が完了すると、操作後の文書を、管理ＩＤ、当該操作についてのログ情報、及びその操作後の文書について取得した文書属性と共に文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書に対して新たな管理ＩＤを付与して派生関係ＤＢ１１０に登録し、受け取った管理ＩＤを親ＩＤとして派生関係ＤＢ１１０に登録する。また、受け取ったログ情報及び操作後の文書を、派生関係ＤＢ１１０及び文書ＤＢ１００に登録し、受け取った文書属性を文書属性ＤＢ１２０に登録する。そして、文書管理サーバ１０は、新たに付与した管理ＩＤをクライアント端末２０に返す。クライアント端末２０は、元の管理ＩＤを受け取った管理ＩＤで置き換える。以上のような処理により、操作間の派生関係が文書管理サーバ１０に蓄積されることになる。
【００８４】
一方、クライアント端末２０が管理ＩＤを付与する構成の場合は、文書管理サーバ１０は、クライアント端末２０から受け取った管理ＩＤに対応する文書をクライアントに提供する。クライアント端末２０は受け取った文書を開き、ユーザがその文書を操作する。操作の完了後、クライアント端末２０はその操作結果の文書に対して新たな管理ＩＤを付与し、この管理ＩＤを含んだ前述のＩＤ付き文書と同様の情報と、その操作結果の文書について取得した文書属性を、文書管理サーバ１０に送る。そして、クライアント端末２０は、そのＩＤ付き文書のうち管理ＩＤのみを保存し、その他の情報を削除する。
【００８５】
以上のように、端末２０が管理ＩＤしか持たず、その他の情報が文書管理サーバ１０に保存されるようなシステムにも、上記実施形態における派生関係の推定の方式は適用可能である。すなわち、クライアント端末２０が実行した操作により生じた文書間の派生関係の情報が文書管理サーバ１０に通知され記録されるようなシステムであればどのようなシステムでも、上述のような派生関係情報の欠落の問題が生じる可能性があり、そのような問題に対して上記実施形態の方式で対処することができる。
【００８６】
以上に例示したシステムにおける文書管理サーバ１０は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図１５に示すように、ＣＰＵ（中央演算装置）４０、メモリ（一次記憶）４２、各種Ｉ／Ｏ（入出力）インタフェース４４等がバス４６を介して接続された回路構成を有する。また、そのバス４６に対し、例えばＩ／Ｏインタフェース４４経由で、ＨＤＤ（ハードディスクドライブ）４８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ５０が接続される。このようなドライブ４８又は５０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ４８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。クライアント端末２０についても同様である。
【図面の簡単な説明】
【００８７】
【図１】文書利用管理システムの概略構成の例を示すブロック図である。
【図２】クライアント端末の内部構成の例を示すブロック図である。
【図３】ＩＤ付き文書のデータ構造の例を模式的に示す図である。
【図４】文書管理サーバの内部構成の例を示すブロック図である。
【図５】派生関係ＤＢのデータ内容の例を示す図である。
【図６】管理ＩＤと文書内容の対応関係を示すデータの例を示す図である。
【図７Ａ】図５に例示したデータ内容が示す派生関係の一部を図式化して示す図である。
【図７Ｂ】図５に例示したデータ内容が示す派生関係の一部を図式化して示す図である。
【図８】文書属性ＤＢのデータ内容の例を示す図である。
【図９】擬似派生関係ＤＢのデータ内容の例を示す図である。
【図１０】要求処理部の処理手順の例を示すフローチャートである。
【図１１】派生関係推定部で行われる子ノード推定処理の処理手順の例を示すフローチャートである。
【図１２】派生関係推定部で行われる処理において用いられるデータ内容の例を示す図である。
【図１３】派生関係推定部で行われる親ノード推定処理の処理手順の例を示すフローチャートである。
【図１４】表示情報生成部において生成される表示情報に従って表示手段に表示される木構造の例を示す図である。
【図１５】文書管理サーバの内部構成の他の例を示すブロック図である。
【図１６】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【００８８】
１０  文書管理サーバ、２０  クライアント端末、３０  ネットワーク、１００  文書ＤＢ、１１０  派生関係ＤＢ、１２０  文書属性ＤＢ、１３０  擬似派生関係ＤＢ、１４０  文書登録部、１４２  派生関係登録部、１４４  文書属性登録部、１５０  要求処理部、１５２，１６０  派生関係推定部、１５４  表示情報生成部、２００  文書操作部、２０２  ＩＤ割り当て部、２０４  派生関係組込部、２１０  文書属性取得部、２２０  登録処理部、３００  ＩＤ付き文書、３０２  文書属性。
【図１】
2008181350.tif 000003
【図２】
2008181350.tif 000004
【図３】
2008181350.tif 000005
【図４】
2008181350.tif 000006
【図５】
2008181350.tif 000007
【図６】
2008181350.tif 000008
【図７Ａ】
2008181350.tif 000009
【図７Ｂ】
2008181350.tif 000010
【図８】
2008181350.tif 000011
【図９】
2008181350.tif 000012
【図１０】
2008181350.tif 000013
【図１１】
2008181350.tif 000014
【図１２】
2008181350.tif 000015
【図１３】
2008181350.tif 000016
【図１４】
2008181350.tif 000017
【図１５】
2008181350.tif 000018
【図１６】
2008181350.tif 000019