JP5082460B2 - 情報処理装置及びプログラム及び情報処理システム - Google Patents

Description

本発明は、情報処理装置及びプログラム及び情報処理システムに関する。

テキスト文書データや音声データ、マルチメディアデータなどの電子文書（以下単に文書とも呼ぶ）をサーバに登録し、ユーザの要求に応じてその文書を提供することが行われている。また、電子文書に対して一意な識別子を付与し、ユーザが入力した識別子に対応する電子文書を提供するシステムも知られている。また、別の公知のシステムでは、電子文書を紙に印刷する場合に、電子文書の識別子をコード化して紙文書に埋め込み、紙文書を複写する際にその紙文書に埋め込まれた識別子を認識し、その識別子に対応した電子文書を取得し、紙に印刷する。

特許文献１に開示されたシステムでは、コンテンツコピー機は、コンテンツＩＤが埋め込まれたコンテンツのコピー原稿からコンテンツＩＤを読み取り、読み取ったコンテンツＩＤとコピーイベント属性の情報とをネットワークを介してコンテンツＩＤ管理センタへ送信する。コンテンツＩＤ管理センタは、受信したコンテンツＩＤからそのコンテンツの原本を取得し、新しいコンテンツＩＤを付与して、そのコンテンツＩＤとコピーイベント属性の情報とを記録し、その新しいコンテンツＩＤをコンテンツの原本に対して埋め込んでコピー要求元へ返す。コンテンツコピー機は、それをコピー結果として出力する。このシステムにおいて、コンテンツＩＤ管理センタは、コンテンツコピー機から受信したコンテンツＩＤに応じて、新たなコンテンツＩＤを発行した場合、その新しいコンテンツＩＤのコピー元が前述の受信したコンテンツＩＤであることを記録する（例えば特許文献１の第４１段落末尾）。

特許文献２に開示されたシステムでは、端末装置は、コンテンツＩＤが埋め込まれたコンテンツの複製物またはその一部からコンテンツＩＤを読み取り，そのコンテンツＩＤと検索補助情報とを コンテンツＩＤ管理センタへ送信する。コンテンツＩＤ管理センタは、コンテンツＩＤと検索補助情報とを受け取ると、そのコンテンツＩＤに対応する コンテンツの原本もしくはそれに関連するコンテンツを端末装置へ返送する。

特開２００２−０１６７８８号公報 特開２００２−０１４９７８号公報

ところで、文書に対して操作が行われた場合に、操作前の文書から操作後の文書が派生したことを示す派生関係を記録し、その記録を用いてサービスを提供することが考えられる。このような仕組みを、いずれかの利用者が登録した文書を各利用者に配布し、各利用者がその文書に対して操作を施した結果の文書を収集する場合、単に派生関係を記録するだけでは利用者ごとや操作内容ごとの文書の収集などを実現できない。

本発明は、文書間の派生関係の情報を利用して、文書に対する各利用者の操作の結果の文書を収集可能とする技術を提供することを目的とする。

請求項１に係る発明は、第１の情報処理装置から、第１の文書に対する操作を行った操作者と、当該操作の時刻と、当該操作の結果である第２の文書と、を含んだ履歴情報を受け取って記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、対象文書を特定する情報を含んだ収集指示に応じて、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、各操作者の最新の文書を前記履歴情報群に基づき特定して提供する文書提供部と、対象文書を特定する情報を含んだ最新原本取得の指示に応じて、前記対象文書を起点として前記記憶部に記憶された派生関係群のなす木を先祖の方向に遡ることにより、前記対象文書の属する木の根に該当する文書である原本文書を特定する原本特定部と、特定された前記原本文書に対応する前記履歴情報から前記原本文書を登録した操作者を特定する操作者特定部と、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、対応する履歴情報中の操作者が前記操作者特定手段により特定された前記操作者と同じである最新の文書を前記履歴情報群に基づき特定して提供する最新原本提供部と、を備える第２の情報処理装置である。

請求項２に係る発明は、請求項１に係る発明において、前記登録部は、前記操作の種類を更に含んだ前記履歴情報を前記記憶部に登録し、前記文書提供部は、前記対象文書の属する木に含まれる文書群のうち、対応する履歴情報中の前記操作の種類が公開操作である文書の中から、各操作者の最新の文書を特定する、ことを特徴とする。

請求項３に係る発明は、コンピュータを、第１の情報処理装置から、第１の文書に対する操作を行った操作者と、当該操作の時刻と、当該操作の結果である第２の文書と、を含んだ履歴情報を受け取って記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、対象文書を特定する情報を含んだ収集指示に応じて、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、各操作者の最新の文書を前記履歴情報群に基づき特定して提供する提供部、対象文書を特定する情報を含んだ最新原本取得の指示に応じて、前記対象文書を起点として前記記憶部に記憶された派生関係群のなす木を先祖の方向に遡ることにより、前記対象文書の属する木の根に該当する文書である原本文書を特定する原本特定部、特定された前記原本文書に対応する前記履歴情報から前記原本文書を登録した操作者を特定する操作者特定部、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、対応する履歴情報中の操作者が前記操作者特定手段により特定された前記操作者と同じである最新の文書を前記履歴情報群に基づき特定して提供する最新原本提供部、として機能させるためのプログラムである。

請求項４に係る発明は、第１の情報処理装置と第２の情報処理装置とを備え、前記第１の情報処理装置は、第１の文書に対する操作を行った操作者と、当該操作の時刻と、当該操作の結果である第２の文書と、を含んだ履歴情報を送信する送信部、を備え、前記第２の情報処理装置は、前記第１の情報処理装置から、前記履歴情報を受け取って記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、対象文書を特定する情報を含んだ収集指示に応じて、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、各操作者の最新の文書を前記履歴情報群に基づき特定して提供する文書提供部と、対象文書を特定する情報を含んだ最新原本取得の指示に応じて、前記対象文書を起点として前記記憶部に記憶された派生関係群のなす木を先祖の方向に遡ることにより、前記対象文書の属する木の根に該当する文書である原本文書を特定する原本特定部と、特定された前記原本文書に対応する前記履歴情報から前記原本文書を登録した操作者を特定する操作者特定部と、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、対応する履歴情報中の操作者が前記操作者特定手段により特定された前記操作者と同じである最新の文書を前記履歴情報群に基づき特定して提供する最新原本提供部と、を備える、ことを特徴とする情報処理システムである。

請求項１に係る発明によれば、各文書に対応する履歴情報中に含まれる操作者及び操作時刻の情報に基づき、対象文書の属する木に含まれる文書群、すなわち対象文書と同じ文書から派生した文書群の中で、各操作者の最新の操作の結果の文書を収集して提供することができる。更に、各操作者が操作する文書の原本である木の根に該当する文書について、その原本を登録した操作者による操作の結果の文書の中から最新のものを求め、最新の原本として提供することができる。

請求項２に係る発明によれば、収集の対象を、操作者が公開操作を行った文書のみに限定することができる。

請求項３に係る発明によれば、各文書に対応する履歴情報中に含まれる操作者及び操作時刻の情報に基づき、対象文書の属する木に含まれる文書群の中で、各操作者の最新の操作の結果の文書を収集して提供することができる。更に、各操作者が操作する文書の原本である木の根に該当する文書について、その原本を登録した操作者による操作の結果の文書の中から最新のものを求め、最新の原本として提供することができる。

請求項４に係る発明によれば、各文書に対応する履歴情報中に含まれる操作者及び操作時刻の情報に基づき、対象文書の属する木に含まれる文書群の中で、各操作者の最新の操作の結果の文書を収集して提供することができる。更に、各操作者が操作する文書の原本である木の根に該当する文書について、その原本を登録した操作者による操作の結果の文書の中から最新のものを求め、最新の原本として提供することができる。

図１は、文書利用管理システムの概略構成の例を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。

クライアント端末２０の例について図２を用いて説明する。クライアント端末は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複写機などがその一例である。クライアント端末２０は、図２に示すように、文書操作部２００及び登録処理部２１０を備える。

文書操作部２００は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示（ユーザから見れば「閲覧」）、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図では、文書操作部２００を１つだけ示したが、それら個々の操作を別々の操作部（例えば、編集用のアプリケーション、読取制御用のアプリケーションなど）が担当してもよい。例えば、文書操作部２００がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部２００は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部２００は、文書に対して操作を行った場合、その操作の結果を表す識別子（ＩＤ）付き文書３００を出力する。

ＩＤ付き文書３００は、図３に示すように、メタ情報３１０と文書内容３２０を含んだ電子文書である。文書内容３２０は、文書操作部２００の操作の結果生成された文書の内容データである。文書操作部２００が電子文書を作成・編集するためのソフトウエアであれば、文書内容３２０はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部２００が電子文書を印刷する装置であれば、文書内容３２０は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部２００が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容３２０は、例えば、その紙文書を読み取って得られる画像データとすればよい。

メタ情報３１０は、文書管理のための情報であり、管理ＩＤ３１２，親ＩＤ３１４，及びログ情報３１６を含む。

管理ＩＤ３１２は、当該ＩＤ付き文書３００自体の一意な識別情報である。親ＩＤ３１４は、当該ＩＤ付き文書３００の親のＩＤ付き文書の管理ＩＤである。すなわち、本実施形態では、あるＩＤ付き文書と、このＩＤ付き文書に対して操作を加えた結果得られる新たなＩＤ付き文書とを、親と子の関係として取り扱う。第１のＩＤ付き文書を操作して第２のＩＤ付き文書が得られた場合、第１のＩＤ付き文書は第２のＩＤ付き文書の親であり、第２のＩＤ付き文書は第１のＩＤ付き文書の子である。したがって、例えば、管理ＩＤ「Ａ」のＩＤ付き文書を文書操作部２００で操作して、その結果得られた新たなＩＤ付き文書の管理ＩＤが「Ｂ」である場合、後者のメタ情報３１０における管理ＩＤ３１２は「Ｂ」であり、親ＩＤ３１４は「Ａ」である。このような親子の関係を、以下では「（管理ＩＤの）派生関係」という。

なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合（この場合、紙文書を読み取った画像を文書内容とするＩＤ付き文書が生成され、本システムに登録される）に生成されるＩＤ付き文書３００では、親ＩＤ３１４は空（すなわち、親は存在しない）となる。

ログ情報３１６は、当該ＩＤ付き文書が生成された際の操作についての、各種のログ項目の情報である。ログ項目には、例えばその操作が行われた時刻、その操作の種別、その操作を指示したユーザ（操作者）などがあるが、もちろんこれに限るものではない。操作の種別には、例えば登録（本システムに新規の文書を登録すること）、閲覧、更新（文書内容の変更）、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部２００を用いて第１のＩＤ付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第２のＩＤ付き文書のログ情報３１６は、編集完了の時刻と、その編集を指示したユーザの識別情報と、操作の種別として「更新」と、を含んだものとなる。

なお、文書操作部２００が、操作した文書を暗号化してもよい。この暗号化は、本システムに準拠した文書操作部２００ならば、復号できるようなものとする。この場合、文書操作部２００が出力するＩＤ付き文書３００の文書内容３２０は、暗号化されることにより、本システムに準拠した文書操作部２００でないと復号できなくなる。したがって、ＩＤ付き文書３００が操作される場合には文書操作部２００が用いられるので、文書操作部２００がその操作を検知し、その操作の内容が文書操作部２００から文書管理サーバ１０に通知される。なお、文書内容３２０だけでなく、後述するメタ情報３１０（またはその一部）に対しても暗号化を施してもよい。

図２の説明に戻り、文書操作部２００は、操作結果として上述のようなＩＤ付き文書３００を作成するために、ＩＤ割り当て部２０２及び派生関係組込部２０４を備える。ＩＤ割り当て部２０２は、操作結果のＩＤ付き文書３００に一意な管理ＩＤを付与する手段である。管理ＩＤは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するＩＤ付き文書３００（ただし管理ＩＤ３１２を除いたもの）のハッシュ値を求め、このハッシュ値をその文書３００のＩＤ付き文書とすればよい。ハッシュ関数としてSHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ管理ＩＤを生成することができる。もちろん、システム内で一意な管理ＩＤを各クライアント端末２０で生成する方法は、これに限らない。管理ＩＤを、クライアント端末２０固有の識別情報を含むものとすれば、システム内で一意な管理ＩＤを各クライアント端末２０で生成することができる。

派生関係組込部２０４は、操作結果の文書に対しＩＤ割り当て部２０２が割り当てた新たな管理ＩＤ３１２と、その操作の元になった親文書の管理ＩＤである親ＩＤ３１４（新規登録の場合は、親ＩＤは無し）と、その操作についての履歴を表すログ情報３１６と、を含むメタ情報３１０を生成する。そして、派生関係組込部２０４は、そのメタ情報３１０を操作結果の文書内容に付加することにより、操作後のＩＤ付き文書３００を生成して出力する。

登録処理部２１０は、文書操作部２００が出力したＩＤ付き文書３００を文書管理サーバ１０に登録するための処理を実行する。このように各クライアント端末２０が、自ら実行した操作の結果であるＩＤ付き文書３００を文書管理サーバ１０に登録することにより、文書管理サーバ１０は各ＩＤ付き文書３００間の派生関係を把握することができる。

文書操作部２００が操作の結果出力するＩＤ付き文書３００は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。他の人からＩＤ付き文書３００を受け取った人が、自分のクライアント端末２０の文書操作部２００を用いてそのＩＤ付き文書３００を操作すると、その操作に応じて新たな管理ＩＤを付与されたＩＤ付き文書が生成されることになる。

また、文書操作部２００が電子文書を印刷する場合、管理ＩＤを生成し、その電子文書の印刷結果にその管理ＩＤを埋め込んでもよい。管理ＩＤの埋め込みは、例えば電子文書の印刷画像に、管理ＩＤを示すコード画像を重畳する等の方法で行うことができる。この場合、文書操作部２００は、その管理ＩＤや操作種別「印刷」等のメタ情報を含んだＩＤ付き文書を文書管理サーバ１０に登録する。なお、ＩＤ付き文書を印刷した場合には、そのＩＤ付き文書の管理ＩＤを親ＩＤ３１４として含んだＩＤ付き文書が生成される。印刷操作に対応するＩＤ付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データなどの印刷データを、文書内容３２０として組み込んでもよい。

また、管理ＩＤが埋め込まれた紙文書を文書操作部２００が読み取った場合、文書操作部２００は、その読み取り操作に対して新たな管理ＩＤを付与し、読み取り結果の画像を文書内容３２０として含んだＩＤ付き文書を生成して文書管理サーバ１０に登録する。このＩＤ付き文書の親ＩＤ３１４には、紙文書から読み取った管理ＩＤがセットされる。管理ＩＤが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。

次に、文書管理サーバ１０の例について説明する。文書管理サーバ１０は、システム内の複数のクライアント端末２０から送られてくるＩＤ付き文書３００を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。図４に示すように、文書管理サーバ１０は、文書ＤＢ１００，派生関係ＤＢ１１０，文書登録部１３０，要求処理部１４０を備える。

文書ＤＢ１００は、クライアント端末２０から送られてきたＩＤ付き文書３００のうちの文書内容３２０を格納するデータベース（ＤＢ）である。文書ＤＢ１００に格納された各文書内容３２０は、一意な内容ＩＤにより管理される。内容ＩＤとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末２０が内容ＩＤを付与してもよく、この場合、内容ＩＤをメタ情報３１０に組み込んでもよい。

文書登録部１３０は、クライアント端末２０から受信したＩＤ付き文書の中の文書内容を文書ＤＢ１００に、メタ情報を派生関係ＤＢ１１０に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部１３２である。

派生関係ＤＢ１１０は、そのようなＩＤ付き文書３００のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図５に、派生関係ＤＢ１１０のデータ内容の一例を示す。図５に示した表における１行の情報が、１つのＩＤ付き文書３００に対応するメタ情報レコードである。この例では、各ＩＤ付き文書３００の管理ＩＤに対応づけて、親ＩＤ、操作種類、操作者、操作時刻、及び、文書内容の内容ＩＤ、の各項目が登録されている。このうち、管理ＩＤと親ＩＤのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。

なお、図５は派生関係ＤＢ１１０が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係ＤＢ１１０は、一般的なリレーショナルデータベースとして構築することもできるし、管理ＩＤを除くメタ情報を記述したＸＭＬ(eXtensible Markup Language)文書を、管理ＩＤをキーとして登録したデータベースとして構築することもできる。

図５に示した派生関係ＤＢ１１０のデータ内容は、図６のような木構造を成す。これは、管理ＩＤをノードとし、管理ＩＤ間の親子関係をエッジとする木構造である。

図５〜図６の例が示す文書の履歴を時系列順に説明すると、以下のようになる。この例は、あるユーザが申請書等のフォーム（ひな形文書）を本システムに登録し、他のユーザがそのフォームに対して記入を行い、記入済みフォームを本システムに登録する業務の流れを表している。

この例ではまず、文書（フォーム）の「登録」操作がuser1のクライアント端末で実行される。「登録」操作は、文書管理サーバ１０に未登録の文書（すなわち、管理ＩＤを有していない文書）を当該サーバ１０に登録するための操作である。この操作に応じて管理ＩＤが"Doc1"、親ＩＤが空、操作種類が「登録」であるメタ情報と、その文書の文書内容とを含むＩＤ付き文書"Doc1"がuser1のクライアント端末から文書管理サーバ１０に送られる。これに応じ、文書管理サーバ１０は、そのＩＤ付き文書"Doc1"中の文書内容を文書ＤＢ１００へ、メタ情報を派生関係ＤＢ１１０にそれぞれ登録する。登録された文書内容は内容ＩＤ"Content1"に対応づけて管理される。その後、user1は、登録したＩＤ付き文書を他のユーザuser2，user3，・・・に配布する。この配布は、例えば、電子メールにそのＩＤ付き文書を添付して各ユーザに送信することにより、行うことができる。

その後、他のユーザuser2が自分のクライアント端末の文書操作部２００でＩＤ付き文書"Doc1"を閲覧する。閲覧されるのは内容ＩＤ"Content1"の文書内容である。クライアント端末は、閲覧の結果としてＩＤ付き文書"Doc2"を生成し、文書管理サーバ１０に登録する。「閲覧」操作では、文書内容は変更されないので、文書内容の内容ＩＤは"Content1"のままである。なお、このように文書内容が変更されない操作を行った場合、クライアント端末２０は、文書内容を省略したＩＤ付き文書を文書管理サーバ１０に送ってもよい。なお、この操作の前にuser2のクライアント端末２０内にあったＩＤ付き文書"Doc1"は、この操作に伴い、派生関係組込部２０４によりＩＤ付き文書"Doc2"に置き換えられる。この置き換え処理では、派生関係組込部２０４は、元のＩＤ付き文書"Doc1"のうち、メタ情報３１０の管理ＩＤ３１２を新たに発行したＩＤ"Doc2"へ変更すると共に、元の文書"Doc1"の管理ＩＤ"Doc1"を親ＩＤ３１４の値にセットする。また、派生関係組込部２０４は、ログ情報３１６中の操作種別の値を今回の操作の種類である「閲覧」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser2に変更する。なお、今回の操作は閲覧なので、文書内容３２０は変化しない。

このようにＩＤ付き文書"Doc1"は、閲覧されると、閲覧後のＩＤ付き文書"Doc2"に置き換えられる。したがって、その置き換えの後は、ＩＤ付き文書"Doc1"自体はそのクライアント端末２０には存在せず、その代わりにＩＤ付き文書"Doc2"が存在することとなる。

次に、更に別のユーザuser3が自分のクライアント端末２０の文書操作部２００でそのＩＤ付き文書"Doc1"を編集する。この場合、user3が、文書操作部２００でＩＤ付き文書"Doc1"を開くと、文書内容"Content1"が提示され、user3はこの文書内容に対して編集を加える。user1が登録したフォーム原本に対して、user3が記入を行う場合、このような編集操作が行われる。user3が編集を終えて文書を閉じると、文書操作部２００は、その編集の結果としてＩＤ付き文書"Doc3"を生成し、文書管理サーバ１０に登録する。ＩＤ付き文書"Doc3"には、管理ＩＤ"Doc3"、親ＩＤ"Doc1"、操作種別「編集」、操作者"user3"などの項目を含んだメタ情報３１０と、編集後の文書内容３２０とが含まれる。ＩＤ付き文書"Doc3"の文書内容は、編集操作により元のものから変わっているので、その文書内容は新たな内容ＩＤ"Content2"と対応づけて文書ＤＢ１００に登録される。

次に、user2が、ＩＤ付き文書"Doc2"を開き、これに応じて提示される文書内容"Content1"に対して編集を行う。編集が終了すると、文書操作部２００は、ＩＤ付き文書"Doc2"を、編集結果の文書内容を含んだＩＤ付き文書"Doc4"に置き換える。ＩＤ付き文書"Doc4"内のメタ情報３１０に含まれる管理ＩＤは"Doc4"であり、親ＩＤは"Doc2"である。そして、文書操作部２００は、操作結果であるＩＤ付き文書"Doc4"を文書管理サーバ１０に登録する。ＩＤ付き文書"Doc4"に含まれる文書内容は、元の文書内容"Content1"から変化しているので、新たな内容ＩＤ"Content3"と対応づけて文書ＤＢ１００に登録される。

その後、user2は、文書操作部２００に対しＩＤ付き文書"Doc4"の「公開」操作の実行を指示する。「公開」操作は、例えばＩＤ付き文書に対して実行可能な手続きの１つとして実装されている。例えば、ユーザがフォルダ内のファイルやフォルダを一覧表示する画面上で、ＩＤ付き文書のアイコン上にカーソルを置いて右クリック等の所定の操作を行うと、操作メニューの１項目として「公開」が提示され、その項目をユーザが選択すると「公開」操作が実行される。「公開」操作は、対象のＩＤ付き文書（この例では"Doc4"）の文書内容（この例では"Content3"）を、その大本（始祖）であるＩＤ付き文書（この例では"Doc1"）の「登録」操作を指示した操作者（この例では"user1"）に開示する意思を記録するための操作である。すなわち、管理ＩＤ"Doc4"に対応する編集操作が実行された段階では、user1は、まだその編集結果の文書内容"Content3"を取得することはできないが、user2がその後、「公開」操作（"Doc5"）を行うことで、user1は、文書内容"Content3"を取得可能となる。まだ記入途中で編集をいったん終了してしまった場合や、公開するか否かの判断に時間を要する場合などには、user2は、「公開」操作を行わずにいれば、user1にその段階の編集結果を見られずに済む。「公開」操作の結果文書管理サーバ１０に登録されるＩＤ付き文書"Doc5"は、親ＩＤ３１４の値が"Doc4"であり、操作種別の値が「公開」となる。文書管理サーバ１０は、user1からＩＤ付き文書が要求された場合、そのＩＤ付き文書の操作種別が「公開」であれば、そのＩＤ付き文書をuser１に提供する。そうでない場合は、そのＩＤ付き文書をuser１には提供しない。また、user1からＩＤ付き文書の検索要求を受けた場合、文書管理サーバ１０は、検索条件に合致するＩＤ付き文書群の中から、操作種別が「公開」であるものだけをuser1に提供する。

なお、以上の例では、ＩＤ付き文書についての「公開」操作は、そのＩＤ付き文書の大本の文書を登録した人に対してそのＩＤ付き文書を公開するためのものであった。しかし、これに限らず、「公開」操作を、対象のＩＤ付き文書を、本システムを利用する人一般に広く公開するための操作としてもよい。

次に、user3が自分のクライアント端末に対しＩＤ付き文書"Doc3"の「公開」を指示すると、クライアント端末は、管理ＩＤ３１２の値が"Doc6"、親ＩＤ３１４の値が"Doc3"、操作種別の値が「公開」であるＩＤ付き文書"Doc6"を生成して、これをＩＤ付き文書"Doc3"と置き換えると共に、そのＩＤ付き文書"Doc6"を文書管理サーバ１０に登録する。これにより、派生関係ＤＢ１１０には、管理ＩＤ"Doc6"のレコードが登録される。

その後、user3がＩＤ付き文書"Doc6"をuser4に電子メール等で送信し、user4が自分のクライアント端末でそのＩＤ付き文書"Doc6"を閲覧すると、クライアント端末はＩＤ付き文書"Doc6"を、閲覧操作を反映した新たなＩＤ付き文書"Doc7"に置き換え、そのＩＤ付き文書"Doc7"を文書管理サーバ１０に登録する。

次に、user2が、ＩＤ付き文書"Doc5"に対して編集を加える。例えば、一度記入して公開した文書内容に修正が必要な場合、user2はこのように公開済みのＩＤ付き文書に対して編集を加える。この編集結果のＩＤ付き文書"Doc8"が文書管理サーバ１０に登録される。更にその後、user2がＩＤ付き文書"Doc8"の「公開」操作の実行を指示すると、その「公開」操作を反映したＩＤ付き文書"Doc9"が文書管理サーバ１０に登録される。

次に、user3が、一度公開したＩＤ付き文書"Doc6"に対して編集を加えると、その編集操作を反映したＩＤ付き文書"Doc10"が文書管理サーバ１０に登録される。

その後、user1が、自分のクライアント端末内にあるＩＤ付き文書"Doc1"（すなわちフォーム原本）の内容の確認のために、ＩＤ付き文書"Doc1"の閲覧を行う。すると、クライアント端末は、閲覧操作を反映したＩＤ付き文書"Doc11"を生成し、文書管理サーバ１０に登録する。このとき、クライアント端末内のＩＤ付き文書"Doc1"はＩＤ付き文書"Doc11"に置き換えられる。図５及び図６は、この時点での派生関係ＤＢ１１０内の、"Doc1"から派生する文書或いは操作の様子を示している。この時点では、user3は、ＩＤ付き文書"Doc10"に対する「公開」操作は行っていない。

以上、派生関係ＤＢ１１０のデータ内容を例に取り、本システムにおける文書操作の情報の登録の様子を説明した。

図４の説明に戻り、要求処理部１４０は、クライアント端末２０からの管理ＩＤを含んだサービス要求に応じて、派生関係ＤＢ１１０を用いたサービスを提供する。要求処理部１４０が提供するサービスとしては、例えば、サービス要求中の管理ＩＤに対応する文書の最新版を検索するサービスがある。また別の例として、サービス要求中の管理ＩＤに対応する始祖の文書（オリジナル文書）又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、その管理ＩＤの来歴、すなわち始祖からその管理ＩＤまでに文書が経てきた操作の履歴（例えば誰がいつどんな操作をしたのかを示す情報のリスト）を提供するサービスもある。また、更に別の例として、管理ＩＤに対応するフォーム原本に対する、各ユーザの記入結果を回収するサービスもある。

サービス要求は、クライアント端末２０に保持されたＩＤ付き文書に基づき発せられる。例えば、ユーザがクライアント端末２０の文書操作部２００によりＩＤ付き文書を開いた場合に、文書操作部２００が、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付ける。そして、そのＩＤ付き文書の管理ＩＤと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ１０の要求処理部１４０に送信する。なお、管理ＩＤと、サービスを示すコード以外に、指示を行ったユーザの識別情報や、ユーザの入力した認証情報などといった他の情報を、クライアント端末２０から要求処理部１４０に送信するようにしてもよい。

また、別の例として、ＩＤ付き文書というオブジェクト種類に対して、そのようなサービスのメニューを対応づけてクライアント端末２０のオペレーティングシステムに登録しておいてもよい。この場合、図７に示すように、オペレーティングシステムが提供するファイル管理画面４００に表示されたＩＤ付き文書のアイコン４１０又は４１４に対し、ユーザが右ボタンクリックなどの所定の操作を行った場合、オペレーティングシステムが、ＩＤ付き文書に対応づけられたメニュー４２０を画面表示する。図示例では、ＩＤ付き文書のアイコン４１０又は４１４には、本システムのＩＤ付き文書であることを示すマーク４１１により、他の種類のファイル４１２と区別可能となっている。ユーザがメニュー４２０上の各サービス項目の中から、所望のものを選択すると、クライアント端末２０は、選択されたサービス項目の実行を文書管理サーバ１０に要求する。

また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理ＩＤを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のＩＤ付き文書の管理ＩＤを親ＩＤとして含んだＩＤ付き文書を生成し、このＩＤ付き文書をサービス要求として文書管理サーバ１０に送ってもよい。この場合、要求処理部１４０は、受け取ったＩＤ付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくＩＤ付き文書内の親ＩＤを、派生関係を遡る処理の起点とする。

要求処理部１４０は、クライアント端末２０からサービス要求を受けた場合、そのサービス要求中に指定された管理ＩＤを起点に、派生関係ＤＢ１１０に登録された管理ＩＤと親ＩＤとの派生関係が構成する木を走査（トラバース）し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。

以下、サービス要求の一例として、「記入済みフォーム回収」が要求された場合の要求処理部１４０の処理手順を、図８及び図９を参照して説明する。以下では、派生関係ＤＢ１１０内のデータ内容が図５及び図６に例示したものである時に、user1が、自分のクライアント端末２０内にあるＩＤ付き文書"Doc11"を対象として、「記入済みフォーム回収」の要求を行った場合を具体例として用いて説明する。

この手順では、要求処理部１４０は、クライアント端末２０から受け取った「記入済みフォーム回収」要求から、処理対象として含まれる管理ＩＤを取り出し、その管理ＩＤを注目ＩＤにセットする（Ｓ１）。次に、派生関係ＤＢ１１０から、注目ＩＤに対応するレコードを取得する（Ｓ２）。注目ＩＤに対応するレコードとは、注目ＩＤをレコード中の「管理ＩＤ」の項目の値として持つレコードのことである。そして、取得したレコード中の操作種別の項目の値が「登録」であるか否かを調べ（Ｓ３）、「登録」でなければ、注目ＩＤの値をそのレコード中の親ＩＤの値へと置き換え（Ｓ４）、ステップＳ２及びＳ３を実行する。このステップＳ２〜Ｓ４のループは、サービス要求中の管理ＩＤから派生関係の木構造を遡り、大本（根）であるフォーム原本の「登録」操作を見つけるための処理を表す。ステップＳ３の判定結果がＹｅｓとなった場合、そのときの注目ＩＤは、根である「登録」操作に対応する。図５の例では、管理ＩＤ"Doc11"から木構造を遡ることで、最終的に、根である管理ＩＤ"Doc1"に到達する。

根である「登録」操作に到達すると、要求処理部１４０は、そのときの注目ＩＤ（根）の子ＩＤを検索する（Ｓ５）。派生関係ＤＢ１１０のうちその注目ＩＤを「親ＩＤ」の値として持つレコードの「管理ＩＤ」が、注目ＩＤの子ＩＤである。注目ＩＤの子ＩＤがすべて求められると、要求処理部１４０は、それら子ＩＤごとに、図９に示すような子孫探索処理を実行する（Ｓ６）。

子孫探索処理（Ｓ６）では、要求処理部１４０は、当該子ＩＤを注目ＩＤとし（Ｓ１１）、その注目ＩＤに対応するレコードを派生関係ＤＢ１１０から取得する（Ｓ１２）。そして、そのレコード中の操作種別の値が「公開」であるか否かを判定し（Ｓ１３）、「公開」であれば、そのレコードを中間結果リストに入れる（Ｓ１４）。中間結果リストは、要求された処理の処理結果を求めるための材料となる情報を蓄積するためにクライアント端末２０の記憶装置上に構築されるリストである。操作種別が「公開」でなければ、ステップＳ１４はスキップされる。そして、要求処理部１４０は、注目ＩＤの子ＩＤを検索し（Ｓ１５）、子ＩＤが検索できたか否かを判定する（Ｓ１６）。子ＩＤがあれば、要求処理部１４０は、それら各子ＩＤについて、それぞれ子孫探索処理（Ｓ６）を再帰的に実行する。すべての子ＩＤについての子孫探索処理が終了すると、当該注目ＩＤについての処理が終了する。ステップＳ１６で子ＩＤがないと判定された場合も、当該注目ＩＤについての処理は終了する。

図８の手順に戻り、根のＩＤ付き文書のすべての子ＩＤについて子孫探索処理（Ｓ６）が終了すると、そのときの中間結果リストには、その根から派生するすべてのＩＤ付き文書の中で、操作種別が「公開」であるものに対応するレコードがすべて蓄積されていることになる。要求処理部１４０は、中間結果リストに蓄積されたレコード群を例えば操作時刻及び操作者の値でソートするなどにより、それらレコード群の中で、操作者ごとの最新のレコードを求める（Ｓ７）。そして、求めた操作者ごとの最新のレコードに対応するＩＤ付き文書を、要求に対する検索結果として、要求元のuser1に提供する（Ｓ８）。なお、操作者が要求元のuser1であるレコードについては、検索結果として提供しないようにしてもよい。

例えば、図６の例では、ステップＳ６の処理により、中間結果リスト中には管理ＩＤが"Doc5"、"Doc6"、"Doc9"の３つのレコードが蓄積される。そして、このうち操作者ごとの最新のレコードは、user2の"Doc9"とuser3の"Doc6"であり、これらが要求に対応する検索結果として要求元のuser1に提供される。

図１０は、文書管理サーバ１０が要求元のuser1に提供する検索結果表示画面５００の一例を示す。この例では、検索結果のリスト５１０には、検索された各レコードの操作者と、それら各レコードに対応する文書内容のサイズと、それら各レコードについての取得要否を指示するためのチェックボックス５１２とが示される。また、この例には、リスト５１０中のすべてのレコードの一括取得を指示するためのチェックボックス５１４も示されている。図１０では、操作者とサイズを表示したが、レコードに含まれる項目であればリスト５１０に表示することができる。この検索結果表示画面５００は、例えばＷｅｂページとして提供することができる。

ユーザ（この例ではuser1）は、リスト５１０に挙げられたレコード（これはＩＤ付き文書に対応する）の中で、手元に取得したいものを、チェックボックス５１４にチェックを入れることで選択する。欄５２０には、リスト５１０中で取得対象として選択されたレコードのサイズの合計が表示される。そして、ユーザが取得ボタン５３０を押下すると、クライアント端末２０は、選択されたレコードの管理ＩＤを含んだ取得要求を文書管理サーバ１０の要求処理部１４０に送信する。ユーザがキャンセルボタン５４０を押下すると、クライアント端末２０は、取得の要求を行わないまま、この画面５００を閉じる。また、取得対象として選択した文書を保存する場合の保存場所、又は保存する際のファイル名、又はその両方を指定するためのユーザインタフェース画面を提供してもよい。この場合、取得要求に応じて文書管理サーバ１０から提供されるＩＤ付き文書は、その画面に対する指定に従って保存される。

クライアント端末２０から取得要求を受けた要求処理部１４０は、その要求に含まれる各管理ＩＤに対応するレコードを派生関係ＤＢ１１０から検索し、検索された各レコードに対応する文書内容を文書ＤＢ１００から検索する。そして、検索された文書内容ごとに、その文書内容を含んだ新たなＩＤ付き文書を生成し、要求元のユーザのクライアント端末２０に提供する。新たに生成されるＩＤ付き文書は、それぞれ文書管理サーバ１０が新たに付与した管理ＩＤを持つと共に、取得要求中に含まれていた管理ＩＤを親ＩＤの値として持つ。また、そのＩＤ付き文書の操作種別は「取得」であり、操作者は要求元のユーザであり、操作時刻は、その新たなＩＤ付き文書を生成した日時である。例えば、図５に例示した状態において、user1がuser2の記入済みフォーム"Doc9"とuser3の記入済みフォーム"Doc6"を取得した場合、派生関係ＤＢ１１０のデータ内容は、例えば図１１に示すようになる。図１１の例では、図５に例示したデータ内容に対し、"Doc12"及び"Doc13"が追加されている。

なお、取得要求に対する要求処理部１４０の応答のための処理は、以上のようなものに限らない。この代わりに、要求処理部１４０は、例えば取得要求に含まれる管理ＩＤに対応するメタ情報レコード及び文書内容を含んだＩＤ付き文書を派生関係ＤＢ１１０及び文書ＤＢ１００から求め、要求元のクライアント端末に返すようにしてもよい。例えば、この例では、管理ＩＤ"Doc6"を含む取得要求に対し、要求処理部１４０はＩＤ付き文書"Doc6"を要求元に返す。取得要求に対してＩＤ付き文書を受け取ったクライアント端末２０は、そのＩＤ付き文書中の管理ＩＤを元に新たな管理ＩＤを生成し、そのＩＤ付き文書の管理ＩＤにその新たな値を上書きする。また元の管理ＩＤを、親ＩＤに上書きする。また、そのＩＤ付き文書内の操作種別の値を「取得」に書き換え、操作者をその取得要求をしたuser1に書き換え、操作時刻も書き換える。そして、そのように変更したＩＤ付き文書を指定された保存場所に保存するともに、文書管理サーバ１０に登録する。

なお、クライアント端末２０が、サービス要求をＩＤ付き文書として文書管理サーバ１０に送信する場合は、そのＩＤ付き文書も文書管理サーバ１０に登録される。例えば、上述の例では、図１２に例示するように、「記録済みフォーム回収」の操作に対応するレコード"Doc12"が登録され、更に要求元のユーザが実際に取得した記録済みフォームに対応するレコード"Doc13"及び"Doc14"が登録される。

なお、「記録済みフォーム回収」を、フォーム原本を登録したユーザにしか認めないようにする場合には、要求処理部１４０は、ユーザ認証を行えばよい。例えばクライアント端末２０がサービス要求を発する場合に、そのサービスの実行を指示したユーザの識別情報をサービス要求に含めるようにすればよい。この場合、サービス要求を受けた要求処理部１４０が、その要求に含まれる管理ＩＤから派生関係の木構造を遡り、根のレコードの操作者を求め、要求中のユーザの識別情報がその操作者に合致する場合は、正当なユーザからの要求と判定すればよい。サービス要求をＩＤ付き文書として要求処理部１４０へ送信する場合には、サービスの実行を指示したユーザの識別情報はＩＤ付き文書内に含まれる。なお、更にこの上に、パスワード等の認証情報をユーザに入力させ、この認証情報に基づきユーザ認証を行ってもよい。

次の、変形例を説明する。変形例では、フォーム原本が更新されることを考慮し、ユーザが自分の持っているＩＤ付き文書に対応する最新のフォームを取得するための仕組みを提供する。

例えば、図５及び図６に示した状態の後、user1がＩＤ付き文書"Doc11"を開いて編集を加え、更にその編集結果に対して「公開」操作を行ったとする。この場合の、ＩＤ付き文書の木構造、及びこれに対応する派生関係ＤＢ１１０のデータ内容を、図１３及び図１４に示す。図１３では、煩雑さを避けるため、"Doc2"以下の部分木と"Doc3"以下の部分木の図示を省略している。図示のように、以上のような操作の系列により、user1のクライアント端末２０内のＩＤ付き文書"Doc11"はまずＩＤ付き文書"Doc12"へと変化し、更にＩＤ付き文書"Doc13"へと変化する。この過程で、編集結果の文書内容は内容ＩＤ"Content6"と対応づけて文書ＤＢ１００に登録される。ＩＤ付き文書"Doc13"の操作種別は「公開」であり、このことは派生関係ＤＢ１１０にも登録される。これら図１３及び図１４に示した状態の時に、user3が、例えば図７に例示したようなユーザインタフェース画面を介して、ＩＤ付き文書"Doc10"を対象として「最新フォーム取得」の要求を行ったとする。このような場合を例にとって、「最新フォーム取得」の要求を受けたときの、要求処理部１４０の処理手順の例を説明する。

この場合、要求処理部１４０は、例えば図１５及び図１６に示す手順に従って、最新フォームを求める。図１５の手順では、要求処理部１４０は、まず、クライアント端末２０から受け取った要求に処理対象として含まれる管理ＩＤを注目ＩＤにセットし（Ｓ２１）、派生関係ＤＢ１１０からその注目ＩＤに対応するレコードを取得する（Ｓ２２）。次に、当該注目ＩＤに対応するレコードを第１中間リストに入れる（Ｓ２３）。次にそのレコード中の操作種別の項目の値が「登録」であるか否かを調べ（Ｓ２４）、「登録」でなければ、注目ＩＤの値をそのレコード中の親ＩＤの値へと置き換え（Ｓ２５）、ステップＳ２２〜Ｓ２５の処理を繰り返す。ステップＳ２２〜Ｓ２５のループにより、第１中間リストには、取得要求に含まれる管理ＩＤから木構造の根（「登録」操作のレコード）までの経路に存在するすべてのレコードが蓄積される。

ステップＳ２４の判定結果がＹｅｓとなった場合、要求処理部１４０は、そのときの注目ＩＤ（すなわち木構造の根）の子ＩＤを検索し（Ｓ２６）、それら子ＩＤごとに、図１６に示すような子孫探索処理を実行する（Ｓ２７）。

子孫探索処理（Ｓ２７）では、要求処理部１４０は、当該子ＩＤを注目ＩＤとし（Ｓ３１）、その注目ＩＤに対応するレコードを派生関係ＤＢ１１０から取得する（Ｓ３２）。そして、そのレコード中の操作種別の値が「公開」であるか否かを判定し（Ｓ３３）、そのレコード中の操作者の値が、ステップＳ２２〜Ｓ２５のループで特定された「登録」操作を行った操作者と同じであるか否かを判定する（Ｓ３４）。ステップＳ３３，Ｓ３４は、どの順序で実行してもよい。ステップＳ３３，Ｓ３４の判定結果がすべてＹｅｓの場合、要求処理部１４０は、そのレコードを第２中間結果リストに入れる（Ｓ３５）。ステップＳ３３及びＳ３４の判定結果のいずれか１つでもＮｏであれば、ステップＳ３５はスキップされる。そして、要求処理部１４０は、注目ＩＤの子ＩＤを検索し（Ｓ３６）、子ＩＤが検索できたか否かを判定する（Ｓ３７）。子ＩＤがあれば、要求処理部１４０は、それら各子ＩＤについて、それぞれ子孫探索処理（Ｓ２７）を再帰的に実行する。すべての子ＩＤについての子孫探索処理が終了した場合、又はステップＳ３７で子ＩＤがないと判定された場合、当該注目ＩＤについての処理が終了する。

図１５の手順に戻ると、根のＩＤ付き文書のすべての子ＩＤについて子孫探索処理（Ｓ２７）が終了すると、そのときの第２中間結果リストには、「登録」操作の操作者が公開したＩＤ付き文書がすべて蓄積されていることになる。「登録」操作の操作者が公開したＩＤ付き文書は、フォームの原本又は更新版である。要求処理部１４０は、中間結果リストに蓄積されたレコード群の中から最新のレコードを求める（Ｓ２８）。求めた最新のレコードに対応するＩＤ付き文書がフォームの最新版である。

また、要求処理部１４０は、第１中間結果リストに蓄積されたレコードの中から、レコード内の操作者の値が「登録」操作の操作者と同じであり、かつレコード内の操作種別の値が「登録」又は「公開」であるレコードを抽出し、その中から最新のレコードを求める（Ｓ２９）。ステップＳ２９で求めた最新のレコードは、要求元のユーザが取得要求の対象として指定したＩＤ付き文書（この例では"Doc10")の元になった、記入前のフォーム（オリジナルのフォームと呼ぶ）に対応する。

要求処理部１４０は、ステップＳ２８で求められた最新版のフォームと、ステップＳ２９で求められたオリジナルのフォームとを、要求に対する検索結果として要求元（この例ではuser3)に提供する（Ｓ３０）。

例えば、図１３の例では、ステップＳ２７の処理により、第２中間結果リスト中には管理ＩＤが"Doc1"、"Doc13"の２つのレコードが蓄積され、このうち最新のレコードに対応するＩＤ付き文書"Doc13"がステップＳ２８で求められる。また、ステップＳ２９では、第１中間結果リスト中の"Doc10"、"Doc6"、"Doc3"、"Doc1"（図６も参照）のうち、上述の条件に該当する"Doc1"が求められる。

図１７は、以上のような処理に基づき文書管理サーバ１０が要求元のuser3に提供する検索結果表示画面６００の一例を示す。この例では、検索結果のリスト６１０には、検索されたオリジナルのフォームと最新のフォームのそれぞれについて、そのサイズと作成又は更新の日時（すなわち「操作時刻」）とが表示される。なお、サイズ及び日時だけでなく、レコードに含まれる項目であればリスト６１０に表示することができる。ユーザは、この表示を見て、最新のフォームを取得するかどうかを判断する。取得すると判断した場合、ユーザは取得ボタン６２０を押下する。すると、クライアント端末２０は、最新のフォームに対応する管理ＩＤを含んだ取得要求を文書管理サーバ１０の要求処理部１４０に送信する。ユーザがキャンセルボタン６３０を押下すると、クライアント端末２０は、取得の要求を行わないまま、この画面６００を閉じる。

クライアント端末２０から、最新フォームの取得要求を受けた要求処理部１４０は、その要求に含まれる管理ＩＤに対応するレコードを派生関係ＤＢ１１０から検索し、検索されたレコードとそれに対応する文書内容とを含んだＩＤ付き文書（すなわち最新のフォーム）を要求元のユーザのクライアント端末２０に提供する。クライアント端末２０は、受け取ったＩＤ付き文書中の管理ＩＤを元に新たな管理ＩＤを生成し、そのＩＤ付き文書の管理ＩＤにその新たな値を上書きする。また元の管理ＩＤを、親ＩＤに上書きする。また、そのＩＤ付き文書内の操作種別の値を「取得」に書き換え、操作者をその取得要求をしたuser3に書き換え、操作時刻も書き換える。そして、そのように変更したＩＤ付き文書を保存するともに、文書管理サーバ１０に登録する。

以上に例示した実施形態及び変形例では、管理ＩＤの発行は各クライアント端末２０で行われていたが、この代わりに文書管理サーバ１０が管理ＩＤを発行してもよい。この場合、クライアント端末２０は、ＩＤ付き文書に対して操作を行った場合、操作前のＩＤ付き文書内の管理ＩＤを親ＩＤ３１４として含み、更にその操作についてのログ情報３１６と操作後の文書内容３２０とを含み、管理ＩＤ３１２は空欄の文書データを生成し、文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書データに対して新たな管理ＩＤを付与し、この管理ＩＤとその文書データとに含まれる情報を、文書ＤＢ１００及び派生関係ＤＢ１１０に登録する。また、文書管理サーバ１０は、付与した管理ＩＤを当該文書データにセットすることによりＩＤ付き文書を生成し、これをクライアント端末２０に返す。クライアント端末２０は、操作前のＩＤ付き文書を、受け取ったＩＤ付き文書に置き換える。このように、文書管理サーバ１０が管理ＩＤを付与する構成でも、上述実施形態及び変形例の処理は同様に実行できる。

また以上の実施形態及び変形例では、管理ＩＤ３１２、親ＩＤ３１４、ログ情報３１６、及び文書内容３２０を含んだＩＤ付き文書３００がクライアント端末２０に保存されたが、この代わりに、クライアント端末２０は管理ＩＤしか持たず、その他の情報は文書管理サーバ１０に保存されるようにしてもよい。この場合、クライアント端末２０で文書を操作する場合、その文書に対応する管理ＩＤを文書管理サーバ１０に送り、文書管理サーバ１０からその文書を取得する。

ここで、文書管理サーバ１０が管理ＩＤを付与する場合は、その取得の操作に対応する管理ＩＤを文書管理サーバ１０が生成し、その管理ＩＤと文書とを対応づけてクライアント２０に提供するとともに、その取得操作についてのログ情報（操作時刻や操作者など）と、元の管理ＩＤ（すなわち親ＩＤ）と、付与した管理ＩＤとを派生関係ＤＢ１１０に記録する。クライアント端末２０は、文書管理サーバ１０に送信した管理ＩＤを、受け取った管理ＩＤに置き換えると共に、受け取った文書を開く。ユーザは、開かれた文書に対して閲覧や編集などの操作を行う。クライアント端末２０は、文書に対する操作が完了すると、操作後の文書を管理ＩＤ及び当該操作についてのログ情報と共に文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書に対して新たな管理ＩＤを付与して派生関係ＤＢ１１０に登録し、受け取った管理ＩＤを親ＩＤとして派生関係ＤＢ１１０に登録する。また、受け取ったログ情報及び操作後の文書を、派生関係ＤＢ１１０及び文書ＤＢ１００に登録する。そして、文書管理サーバ１０は、新たに付与した管理ＩＤをクライアント端末２０に返す。クライアント端末２０は、元の管理ＩＤを受け取った管理ＩＤで置き換える。以上のような処理により、操作間の派生関係が文書管理サーバ１０に蓄積されることになる。

一方、クライアント端末２０が管理ＩＤを付与する構成の場合は、文書管理サーバ１０は、クライアント端末２０から受け取った管理ＩＤに対応する文書をクライアントに返せばよい。クライアント端末２０は受け取った文書を開き、ユーザがその文書を操作する。操作の完了後、クライアント端末２０はその操作結果の文書に対して新たな管理ＩＤを付与し、この管理ＩＤを含んだ前述のＩＤ付き文書と同様の情報を、文書管理サーバ１０に送る。そして、クライアント端末２０は、そのＩＤ付き文書のうち管理ＩＤのみを保存し、その他の情報を削除する。

以上では、フォーム（ひな形）文書を例にとって説明したが、フォーム文書以外の文書に対する各利用者の操作の結果を収集する場合にも、上述の実施形態の方式は適用可能である。

以上に例示したシステムにおける文書管理サーバ１０は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図１８に示すように、ＣＰＵ（中央演算装置）４０、メモリ（一次記憶）４２、各種Ｉ／Ｏ（入出力）インタフェース４４等がバス４６を介して接続された回路構成を有する。また、そのバス４６に対し、例えばＩ／Ｏインタフェース４４経由で、ハードディスクドライブ４８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ５０が接続される。このようなドライブ４８又は５０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ４８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。クライアント端末２０についても同様である。

文書利用管理システムの概略構成の例を示すブロック図である。 クライアント端末の内部構成の例を示すブロック図である。 ＩＤ付き文書のデータ構造の例を模式的に示す図である。 文書管理サーバの内部構成の例を示すブロック図である。 派生関係ＤＢのデータ内容の例を示す図である。 図５に例示したデータ内容における管理ＩＤ群がなす木構造を図式化して表す図である。 ＩＤ付き文書のアイコンを表示した表示画面の例を示す図である。 記入済みフォーム回収要求に対する要求処理部の処理手順の一例の一部を示すフローチャートである。 記入済みフォーム回収に対する要求処理部の処理手順の一例の残りの部分を示すフローチャートである。 記入済みフォーム検索結果の表示画面の例を示す図である。 記入済みフォームが取得された後の派生関係ＤＢのデータ内容の例を示す図である。 記入済みフォームが取得された後の派生関係ＤＢのデータ内容の例を示す図である。 フォーム原本が変更された場合の管理ＩＤ群がなす木構造を図式化して表す図である。 図１３の木構造に対応する派生関係ＤＢのデータ内容の例を示す図である。 最新フォーム取得要求に対する要求処理部の処理手順の一例の一部を示すフローチャートである。 最新フォーム取得要求に対する要求処理部の処理手順の一例の残りの部分を示すフローチャートである。 最新フォーム検索結果の表示画面の例を示す図である。 コンピュータのハードウエア構成の一例を示す図である。

符号の説明

１０ 文書管理サーバ、２０ クライアント端末、３０ ネットワーク、１００ 文書ＤＢ、１１０ 派生関係ＤＢ、１３０ 文書登録部、１３２ 派生関係登録部、１４０ 要求処理部、２００ 文書操作部、２０２ ＩＤ割り当て部、２０４ 派生関係組込部、２１０ 登録処理部、３００ ＩＤ付き文書。

Claims (4)

1. 第１の情報処理装置から、第１の文書に対する操作を行った操作者と、当該操作の時刻と、当該操作の結果である第２の文書と、を含んだ履歴情報を受け取って記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、
   対象文書を特定する情報を含んだ収集指示に応じて、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、各操作者の最新の文書を前記履歴情報群に基づき特定して提供する文書提供部と、
   対象文書を特定する情報を含んだ最新原本取得の指示に応じて、前記対象文書を起点として前記記憶部に記憶された派生関係群のなす木を先祖の方向に遡ることにより、前記対象文書の属する木の根に該当する文書である原本文書を特定する原本特定部と、
   特定された前記原本文書に対応する前記履歴情報から前記原本文書を登録した操作者を特定する操作者特定部と、
   前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、対応する履歴情報中の操作者が前記操作者特定手段により特定された前記操作者と同じである最新の文書を前記履歴情報群に基づき特定して提供する最新原本提供部と、
   を備える第２の情報処理装置。
2. 前記登録部は、前記操作の種類を更に含んだ前記履歴情報を前記記憶部に登録し、
   前記文書提供部は、前記対象文書の属する木に含まれる文書群のうち、対応する履歴情報中の前記操作の種類が公開操作である文書の中から、各操作者の最新の文書を特定する、
   ことを特徴とする請求項１記載の第２の情報処理装置。
3. コンピュータを、
   第１の情報処理装置から、第１の文書に対する操作を行った操作者と、当該操作の時刻と、当該操作の結果である第２の文書と、を含んだ履歴情報を受け取って記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、
   対象文書を特定する情報を含んだ収集指示に応じて、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、各操作者の最新の文書を前記履歴情報群に基づき特定して提供する文書提供部、
   対象文書を特定する情報を含んだ最新原本取得の指示に応じて、前記対象文書を起点として前記記憶部に記憶された派生関係群のなす木を先祖の方向に遡ることにより、前記対象文書の属する木の根に該当する文書である原本文書を特定する原本特定部、
   特定された前記原本文書に対応する前記履歴情報から前記原本文書を登録した操作者を特定する操作者特定部、
   前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、対応する履歴情報中の操作者が前記操作者特定手段により特定された前記操作者と同じである最新の文書を前記履歴情報群に基づき特定して提供する最新原本提供部、
   として機能させるためのプログラム。
4. 第１の情報処理装置と第２の情報処理装置とを備え、
   前記第１の情報処理装置は、
   第１の文書に対する操作を行った操作者と、当該操作の時刻と、当該操作の結果である第２の文書と、を含んだ履歴情報を送信する送信部、
   を備え、
   前記第２の情報処理装置は、
   前記第１の情報処理装置から、前記履歴情報を受け取って記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、
   対象文書を特定する情報を含んだ収集指示に応じて、前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、各操作者の最新の文書を前記履歴情報群に基づき特定して提供する文書提供部と、
   対象文書を特定する情報を含んだ最新原本取得の指示に応じて、前記対象文書を起点として前記記憶部に記憶された派生関係群のなす木を先祖の方向に遡ることにより、前記対象文書の属する木の根に該当する文書である原本文書を特定する原本特定部と、
   特定された前記原本文書に対応する前記履歴情報から前記原本文書を登録した操作者を特定する操作者特定部と、
   前記記憶部に記憶された派生関係群のなす木群の中の前記対象文書の属する木に含まれる文書のうち、対応する履歴情報中の操作者が前記操作者特定手段により特定された前記操作者と同じである最新の文書を前記履歴情報群に基づき特定して提供する最新原本提供部と、
   を備える、
   ことを特徴とする情報処理システム。

Images