図1は、文書管理システムの概略構成の例を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク30を介して接続された文書管理サーバ10とクライアント端末20−1,20−2,・・・(以下、クライアント端末20と総称する)から構成される。
クライアント端末20について図2を用いて説明する。クライアント端末は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複写機などがその一例である。クライアント端末20は、図2に示すように、文書操作部200、登録処理部210、及び強制登録指示受付部220を備える。
文書操作部200は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示(ユーザから見れば「閲覧」)、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図では、文書操作部200を1つだけ示したが、それら個々の操作を別々の操作部(例えば、編集用のアプリケーション、読取制御用のアプリケーションなど)が担当してもよい。例えば、文書操作部200がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部200は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部200は、文書に対して操作を行った場合、その操作の結果を表すID付き文書300を出力する。
ID付き文書300は、図3に示すように、メタ情報310と文書内容320を含んだ電子文書である。文書内容320は、文書操作部200の操作の結果生成された文書の内容データである。文書操作部200が電子文書を作成・編集するためのソフトウエアであれば、文書内容320はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部200が電子文書を印刷する装置であれば、文書内容320は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部200が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容320は、例えば、その紙文書を読み取って得られる画像データとすればよい。
メタ情報310は、文書管理のための情報であり、管理ID312,親ID314,及びログ情報316を含む。
管理ID312は、当該ID付き文書300自体の一意な識別情報である。親ID314は、当該ID付き文書300の親のID付き文書の管理IDである。すなわち、本実施形態では、あるID付き文書と、このID付き文書に対して操作を加えた結果得られる新たなID付き文書とを、親と子の関係として取り扱う。第1のID付き文書を操作して第2のID付き文書が得られた場合、第1のID付き文書は第2のID付き文書の親であり、第2のID付き文書は第1のID付き文書の子である。したがって、例えば、管理ID「A」のID付き文書を文書操作部200で操作して、その結果得られた新たなID付き文書の管理IDが「B」である場合、後者のメタ情報310における管理ID312は「B」であり、親ID314は「A」である。このような親子の関係を、以下では「(管理IDの)派生関係」という。
なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合(この場合、紙文書を読み取った画像を文書内容とするID付き文書が生成され、本システムに登録される)に生成されるID付き文書300では、親ID314は空(すなわち、親は存在しない)となる。
ログ情報316は、当該ID付き文書が生成された際の操作についての、各種のログ項目の情報である。ログ項目には、例えばその操作が行われた日時、その操作の種別、その操作を指示したユーザ(操作者)などがあるが、もちろんこれに限るものではない。操作の種別には、例えば登録(本システムに新規の文書を登録すること)、閲覧、編集、更新(更新版の登録)、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部200を用いて第1のID付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第2のID付き文書のログ情報316は、編集完了の日時と、その編集を指示したユーザの識別情報と、操作の種別として「編集」と、を含んだものとなる。
ここでログ情報316に組み込まれる操作の種別は、ログ記録の目的での分類に従った種別であり、文書操作部200が実行する操作の種別そのものでなくてもよい。例えば、文書操作部200が実行する複数の操作の種別を、同じ1つのログ記録目的の操作種別に対応づけてもよい。例えば、文書編集アプリケーション上でID付きの電子文書に編集を加え操作メニュー上で「更新版として登録」を指示した場合も、スキャナで管理ID付きの紙文書を読み取り読取制御用アプリケーションの操作メニュー上で「読み取った文書を承認版として登録」を指示した場合も、ログ情報316に組み込まれる操作種別の値は「更新」となる。
なお、文書操作部200が、操作した文書を暗号化してもよい。この暗号化は、本システムに準拠した文書操作部200ならば、復号できるようなものとする。この場合、文書操作部200が出力するID付き文書300の文書内容320は、暗号化されることにより、本システムに準拠した文書操作部200でないと復号できなくなる。したがって、ID付き文書300が操作される場合には文書操作部200が用いられるので、文書操作部200がその操作を検知し、その操作の内容が文書操作部200から文書管理サーバ10に通知される。なお、文書内容320だけでなく、後述するメタ情報310(またはその一部)に対しても暗号化を施してもよい。
図2の説明に戻り、文書操作部200は、操作結果として上述のようなID付き文書300を作成するために、ID割り当て部202及び派生関係組込部204を備える。ID割り当て部202は、操作結果のID付き文書300に一意な管理IDを付与する手段である。管理IDは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するID付き文書300(ただし管理ID312を除いたもの)のハッシュ値を求め、このハッシュ値をその文書300のID付き文書とすればよい。ハッシュ関数としてSHA-256(SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である)などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ管理IDを生成することができる。もちろん、システム内で一意な管理IDを各クライアント端末20で生成する方法は、これに限らない。管理IDを、クライアント端末20固有の識別情報を含むものとすれば、システム内で一意な管理IDを各クライアント端末20で生成することができる。
派生関係組込部204は、操作結果の文書に対しID割り当て部202が割り当てた新たな管理ID312と、その操作の元になった親文書の管理IDである親ID314(新規登録の場合は、親IDは無し)と、その操作についてのログ情報316と、を含むメタ情報310を生成する。ここで、派生関係組込部204は、文書操作部200が実行する個々の操作の種別が、ログ記録目的上の操作種別のどれに対応するかを表す対応関係の情報を保持しており、この情報を用いることでログ情報316に組み込む操作種別の値を求める。そして、派生関係組込部204は、そのメタ情報310を操作結果の文書内容に付加することにより、操作後のID付き文書300を生成して出力する。
文書操作部200がアプリケーションソフトウエアである場合、ID割り当て部202及び派生関係組込部204は、そのソフトウエアに対して追加される、いわゆるプラグイン(plug-in)プログラムとして実現してもよい。
登録処理部210は、文書操作部200が出力したID付き文書300を文書管理サーバ10に登録するための処理を実行する。このように各クライアント端末20が、自ら実行した操作の結果であるID付き文書300を文書管理サーバ10に登録することにより、文書管理サーバ10は各ID付き文書300間の派生関係を把握することができる。
強制登録指示受付部220は、特定のID付き文書300を文書管理サーバ10に強制的に登録させる指示(以下、「強制登録指示」とも言う)を受け付ける。後述するように、文書管理サーバ10は、ID付き文書300のログ情報316に含まれる操作種別に応じて文書管理サーバ10への登録を制限する場合がある。強制登録指示受付部220は、強制登録指示を受け付けると、登録処理部210を介して当該指示を文書管理サーバ10へ送信する。この指示を受けた文書管理サーバ10は、登録対象とする操作種別の制限にかかわらず、指示されたID付き文書300を登録する。
文書操作部200が操作の結果出力するID付き文書300は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。電子メール送信用のソフトウエアは、この例では本システムに準拠していないので、この送信操作はID付き文書には反映されず、したがって文書管理サーバ10にも記録されない。他の人からID付き文書300を受け取った人が、自分のクライアント端末20の文書操作部200を用いてそのID付き文書300を操作すると、その操作に応じて新たな管理IDを付与されたID付き文書が生成されることになる。
また、文書操作部200が電子文書を印刷する場合、管理IDを生成し、その電子文書の印刷結果にその管理IDを埋め込んでもよい。管理IDの埋め込みは、例えば電子文書の印刷画像に、管理IDを示すコード画像を重畳する等の方法で行うことができる。また、用紙がRFID(Radio Frequency Identifier)タグを備えている場合、そのRFIDタグに管理IDを書き込んでもよい。このように印刷を行った場合、文書操作部200は、その管理IDや操作種別「印刷」等のメタ情報を含んだID付き文書を文書管理サーバ10に登録する。なお、ID付き文書を印刷した場合には、そのID付き文書の管理IDを親ID314として含んだID付き文書が生成される。印刷操作に対応するID付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データをなどの印刷データ、又は印刷された文書ファイルを、文書内容320として組み込んでもよい。
また、管理IDが埋め込まれた紙文書を文書操作部200が読み取った場合、文書操作部200は、その読み取り操作に対して新たな管理IDを付与し、読み取り結果の画像を文書内容320として含んだID付き文書を生成して文書管理サーバ10に登録する。このID付き文書の親ID314には、紙文書から読み取った管理IDがセットされる。管理IDが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。
次に、文書管理サーバ10について説明する。文書管理サーバ10は、システム内の複数のクライアント端末20から送られてくるID付き文書300を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。図4に示すように、文書管理サーバ10は、文書DB(データベース)100,派生関係DB110,文書登録部130,要求処理部140,操作種別限定部150を備える。
文書DB100は、クライアント端末20から送られてきたID付き文書300のうちの文書内容320を格納するデータベースである。文書DB100に格納された各文書内容320は、一意な内容IDにより管理してもよい。内容IDとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末20が内容IDを付与してもよく、この場合、内容IDをメタ情報310に組み込んでもよい。また、内容IDの代わりに、その文書内容320を、当該文書内容に対応するID付き文書300の管理IDと対応づけて文書DB100に格納してもよい。
文書登録部130は、クライアント端末20から受信したID付き文書の中の文書内容を文書DB100に、メタ情報を派生関係DB110に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部132である。
派生関係DB110は、そのようなID付き文書300のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図5に、派生関係DB110のデータ内容の一例を示す。図5に示した表における1行の情報が、1つのID付き文書300に対応するメタ情報レコードである。この例では、各ID付き文書300の管理IDに対応づけて、親ID、操作種別、操作者、操作日時の各項目が登録されている。このうち、管理IDと親IDのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。また、操作種別、操作者、操作日時については既に説明した。
なお、図5に例示したメタ情報の項目は一例に過ぎない。例えば、この他にも、ID付き文書内の文書内容320を格納した、文書DB100内での格納場所を示すパス名を派生関係DB110に登録してもよい。文書DB100が、内容IDで文書内容320を検索する機能を持つものであれば、文書格納パスの代わりに内容IDをメタ情報レコードに登録してもよい。
なお、図5は派生関係DB110が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係DB110は、一般的なリレーショナルデータベースとして構築することもできるし、管理IDを除くメタ情報を記述したXML(eXtensible Markup Language)文書を、管理IDをキーとして登録したデータベースとして構築することもできる。
図5に示した派生関係DB110のデータ内容は、図6のような木構造を成す。これは、管理IDをノードとし、管理ID間の親子関係をエッジとする木構造である。
以下、図5〜図6の例が示す文書の履歴について時系列順に説明する。図5〜図6は、あるユーザが特定の形式のフォーム文書(例えば、アンケートフォーム、各種申請書フォームなど)を登録し、このフォーム文書に対して他のユーザが記入を行ない、記入済みの文書を登録する場合の文書の履歴の例を示す。
まず、文書(フォーム文書)の「新規登録」操作がuserAのクライアント端末で実行される。「新規登録」操作は、文書管理サーバ10に未登録の文書(すなわち、管理IDを有していない文書)を当該サーバ10に登録するための操作である。この操作に応じて管理IDが"Doc1"、親IDが空、操作種別が「新規登録」であるメタ情報と、その文書の文書内容とを含むID付き文書"Doc1"がuserAのクライアント端末から文書管理サーバ10に送られる。これに応じ、文書管理サーバ10は、そのID付き文書"Doc1"中の文書内容を文書DB100へ、メタ情報を派生関係DB110にそれぞれ登録する。なお、以下では、識別のために、登録された文書内容を"Content1"で表すことにする。その後、userAは、登録したID付き文書を他のユーザuserB,userC,userDに配布する。この配布は、例えば、電子メールにそのID付き文書を添付して各ユーザに送信することにより、行うことができる。
その後、他のユーザuserBが自分のクライアント端末の文書操作部200でID付き文書"Doc1"に対して編集(フォームに対する記入)を行い、操作メニュー上で「応答(記入済み文書として登録)」を指示する。クライアント端末20は、この「応答」操作の結果としてID付き文書"Doc2"を生成し、このID付き文書"Doc2"が文書管理サーバ10に登録される。このID付き文書のメタ情報における管理IDは"Doc2"であり親IDは"Doc1"である。また操作者はuserBであり、操作種別は「応答」である。また、ID付き文書"Doc1"に対して編集を加えたことにより、文書内容320は、"Content1"から"Content2"に変更される。文書管理サーバ10は、受け取ったID付き文書の親IDの値から、当該文書"Doc2"が文書"Doc1"の子であることを認識する。
なお、この操作の前にuserBのクライアント端末20内にあったID付き文書"Doc1"は、この操作に伴い、派生関係組込部204によりID付き文書"Doc2"に置き換えられる。この置き換え処理では、派生関係組込部204は、元のID付き文書"Doc1"のうち、メタ情報310の管理ID312を新たに発行したID"Doc2"へ変更すると共に、元の文書"Doc1"の管理ID"Doc1"を親ID314の値にセットする。また、派生関係組込部204は、ログ情報316中の操作種別の値を今回の操作の種別である「応答」に変更し、操作時刻の値をその応答の日時に変更し、操作者の値をuserBに変更する。さらに、文書内容320を"Content2"に変更する。
このようにID付き文書"Doc1"に対する操作が実行されると、ID付き文書"Doc1"は、操作後のID付き文書"Doc2"に置き換えられる。したがって、その置き換えの後は、ID付き文書"Doc1"自体はそのクライアント端末20には存在せず、その代わりにID付き文書"Doc2"が存在することとなる。
その後、userCが自分のクライアント端末20の文書操作部200によってID付き文書"Doc1"に対して編集を加え、操作メニュー上で「応答」を指示すると、クライアント端末20は、管理ID312の値が"Doc3"、親ID314の値が"Doc1"、操作種別の値が「応答」であるID付き文書"Doc3"を生成する。そして、クライアント端末20は、生成したID付き文書"Doc3"を「応答」操作の前のID付き文書"Doc1"と置き換えると共に、ID付き文書"Doc3"を文書管理サーバ10に登録する。編集により、文書内容は"Content1"から"Content3"に変化している。文書管理サーバ10の派生関係DB110には、管理ID"Doc3"のレコードが登録される。
その後、userAは、ID付き文書"Doc1"を指定して、文書管理サーバ10に対して、指定文書"Doc1"に対する「応答」操作の結果として登録されたID付き文書を提示させる利用要求を行う。この要求に応じた処理により、文書管理サーバ10は、ID付き文書"Doc1"に対する「応答」操作により生成されたID付き文書"Doc2","Doc3"をuserAのクライアント端末20に返す。すなわち、ID付き文書"Doc2","Doc3"は、クライアント端末20にダウンロードされる。指定文書を特定した利用要求に応じて文書管理サーバ10が行う一連の処理の詳細は後述する。クライアント端末20の文書操作部200は、各ID付き文書"Doc2","Doc3"に対するダウンロード操作の結果に対応する新たなID付き文書を生成する。例えば、各ID付き文書"Doc2","Doc3"のダウンロードの結果の文書それぞれに対して新たな管理ID"Doc4","Doc5"を付与する。そして、クライアント端末20にダウンロードされた各ID付き文書"Doc2","Doc3"のメタ情報中の管理IDの値を、それぞれ、"Doc4","Doc5"に置き換え、親IDの値を、それぞれ、"Doc2","Doc3"に置き換える。また、操作種別の値を「回収」に、操作者の値を「userA」に置き換える。また、操作日時の値を、各ID付き文書"Doc2","Doc3"がダウンロードされた時刻に置き換える。なお、各ID付き文書"Doc4","Doc5"の文書内容320は、ダウンロードされたID付き文書"Doc2","Doc3"の文書内容"Content2","Content3"から変更されない。クライアント端末20の登録処理部210は、文書操作部200が生成したID付き文書"Doc4","Doc5"を文書管理サーバ10へ送信する。このとき、ID付き文書"Doc4","Doc5"の文書内容はそれぞれの親文書"Doc2","Doc3"と同一であるため、クライアント端末20は、文書内容を省略したID付き文書"Doc4","Doc5"を文書管理サーバ10に送信してもよい。文書管理サーバ10の派生関係DB110には、管理ID"Doc4","Doc5"のレコードが登録される。
さらに、userDが、ID付き文書"Doc1"に対して「応答」操作を行い、管理IDの値が"Doc6"、親ID314の値が"Doc1"、操作種別の値が「応答」であるID付き文書"Doc6"に対応するレコードが文書管理サーバ10の派生関係DB110に登録される。userDのクライアント端末20において、「応答」操作の前のID付き文書"Doc1"はID付き文書"Doc6"に置き換えられる。また、「応答」操作に伴う編集により、文書内容は"Content1"から"Content4"に変化している。
以上、派生関係DB110のデータ内容を例に取り、本システムにおける文書操作の情報の登録の様子を説明した。
図4の説明に戻り、要求処理部140は、クライアント端末20からの管理IDを含んだサービス要求に応じて、派生関係DB110を用いたサービスを提供する。要求処理部140が提供するサービスとしては、例えば、サービス要求中の管理IDに対応する文書の最新版を検索するサービスがある。また別の例として、サービス要求中の管理IDに対応する始祖(根)の文書又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、その管理IDの来歴、すなわち始祖からその管理IDまでに文書が経てきた操作の履歴(例えば誰がいつどんな操作をしたのかを示す情報のリスト)を提供するサービスもある。また、派生関係DB110に登録された属性項目についての検索条件の指定を受け付け、その検索条件を満足するID付き文書のリストを提供するサービスもある。このサービスに付随して、要求処理部140は、そのリストの中からユーザの所望するID付き文書の選択を受け付け、選択されたID付き文書を提供してもよい。なお、上述の最新版を検索するサービスは、「操作日時が最新である」という検索条件についての検索結果を提供するサービスと捉えることもできる。また、上述の始祖の文書の情報を提供するサービスは、「木構造の根に該当する文書」という条件についての検索結果を提供するサービスと捉えることができる。また、別の例として、派生関係DB110に基づきID付き文書群の派生関係を表す木構造の表示画面を提供し、その表示画面上でユーザの所望するID付き文書の選択を受け付け、選択されたID付き文書を提供するサービスもある。
サービス要求は、クライアント端末20に保持されたID付き文書に基づき発せられる。例えば、ユーザがクライアント端末20の文書操作部200によりID付き文書を開いた場合に、文書操作部200が、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付ける。そして、そのID付き文書の管理IDと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ10の要求処理部140に送信する。このとき、ユーザ識別情報や操作日時などの属性項目についての検索条件を指定するユーザインタフェース画面を提供し、この画面を介して入力された検索条件を併せて要求処理部140に送信してもよい。また、管理IDと、サービスを示すコード、検索条件以外に、指示を行ったユーザの識別情報や、ユーザの入力した認証情報などといった他の情報を、クライアント端末20から要求処理部140に送信するようにしてもよい。
図5及び図6を参照して説明した文書の履歴の例において、ID付き文書"Doc1"を指定して、この指定文書に対する「応答」操作の結果のID付き文書を提示させる利用要求は、サービス要求の一例である。上述のとおり、この利用要求の結果として各ID付き文書"Doc2","Doc3"が文書管理サーバ10からクライアント端末20にダウンロードされる操作にそれぞれ対応する管理ID"Doc4","Doc5"のレコードが派生関係DB110に登録される。
また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理IDを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のID付き文書の管理IDを親IDとして含んだID付き文書を生成し、このID付き文書をサービス要求として文書管理サーバ10に送ってもよい。この場合、要求処理部140は、受け取ったID付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくID付き文書内の親IDを、派生関係を遡る処理の起点とする。
要求処理部140は、クライアント端末20からサービス要求を受けた場合、そのサービス要求中に指定された管理IDを起点に、派生関係DB110に登録された管理IDと親IDとの派生関係が構成する木を走査(トラバース)し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。
操作種別限定部150は、文書登録部130が派生関係DB110に登録する文書の操作種別を制限する。操作種別限定部150は、派生関係DB110への登録対象となる文書の操作種別を特定する情報を文書登録部130に通知する。文書登録部130は、クライアント端末20からID付き文書を受け取った場合に、当該ID付き文書の操作種別が操作種別限定部150から登録対象として通知された操作種別に含まれていれば、当該ID付き文書に対応するレコードを派生関係DB110に登録する。クライアント端末20から受け取ったID付き文書の操作種別が操作種別限定部150から登録対象として通知された操作種別に含まれていなければ、文書登録部130は、そのID付き文書に対応するレコードを派生関係DB110に登録しない。なお、操作種別限定部150は、登録対象とする操作種別を限定しない旨を文書登録部130に通知する場合もある。操作種別を限定しない場合、文書登録部130は、操作種別を確認することなく、クライアント端末20から受け取ったID付き文書のすべてについて、対応するレコードを派生関係DB110に登録する。図5及び図6を参照して上記で説明した文書登録部130の処理の例は、操作種別の限定が行われない場合の処理の例である。
以下、図7及び図8を参照し、指定文書の管理IDを含むサービス要求をクライアント端末20から受け取った場合の要求処理部140の処理手順の例を説明する。以下では、「指定文書の子孫に該当する文書のうち操作種別が「応答」である文書」を検索条件として検索した結果の文書を提供することを要求するサービス要求を受け取った場合を例に説明する。この検索条件を指定するサービス要求は、例えば、クライアント端末20において特定のID付き文書を指定し、文書操作部200の操作メニュー上で、「応答文書一覧の表示」コマンドの実行をユーザが指示した場合にクライアント端末20から文書管理サーバ10へ送信される。
図7を参照し、まず、要求処理部140は、クライアント端末20から受け取ったサービス要求(検索要求)から、指定文書の管理IDを取り出し、その管理IDを注目IDにセットする(ステップS1)。次に、要求処理部140は、派生関係DB110を参照し、注目IDの子IDを検索する(ステップS2)。派生関係DB110のうちその注目IDを「親ID」の値として持つレコードの「管理ID」が、注目IDの子IDである。そして、注目IDの子IDが存在するか否かを判定する(ステップS3)。注目IDの子IDが存在しない場合(ステップS3でNO)、要求処理部140は、「検索結果なし」を表す情報をサービス実行の結果としてクライアント端末20に返す(ステップS7)。注目IDの子IDが存在する場合(ステップS3でYES)、要求処理部140は、それら子IDごとに、図8に例示する子孫探索処理を実行する。
ステップS4の子孫探索処理が開始されると、図8の例の手順の処理が開始される。まず、要求処理部140は、当該子IDを注目IDとする(ステップS11)。次に、要求処理部140は、その注目IDに対応するレコードを派生関係DB110から取得し(ステップS12)、取得したレコードを中間結果リストに入れる(ステップS13)。中間結果リストは、要求された処理の処理結果を求めるための材料となる情報を蓄積するために構築されるリストである。
その後、要求処理部140は、注目IDの子IDを検索し(ステップS14)、子IDが検索できたか否かを判定する(ステップS15)。子IDがあれば(ステップS15でYES)、要求処理部140は、それら各子IDについて、それぞれ、子孫探索処理(ステップS4)を再帰的に実行する。すべての子IDについての子孫探索処理が終了すると、当該注目IDについての処理が終了する。ステップS15で子IDがないと判定された場合も、当該注目IDについての処理は終了する。
再び図7を参照し、注目IDのすべての子IDについてステップS4の子孫探索処理が終了すると、中間結果リストには、注目IDに対応する文書から派生した文書に対応するレコードが蓄積されていることになる。例えば、図5を参照し、派生関係DB110に管理ID"Doc1"、"Doc2"、及び"Doc3"のレコードが登録されている状態で、注目IDが"Doc1"である場合、中間結果リストには、管理ID"Doc2"及び"Doc3"のレコードが蓄積される。次に、要求処理部140は、中間結果リストから検索条件を満たすレコードの有無を判定する(ステップS5)。例えば、検索条件として「操作種別が「応答」である」という条件が設定されている場合に、中間結果リストに管理ID"Doc2"及び"Doc3"のレコード(操作種別はすべて「応答」)が蓄積されていると、中間結果リスト内に検索条件を満たすレコードが存在すると判定される。中間結果リスト内に検索条件を満たすレコードが存在する場合(ステップS5でYES)、要求処理部140は、検索条件を満たすレコードに対応する文書についての情報を検索結果として提供する(ステップS6)。ここで、要求処理部140は、対応する文書の内容を提供してもいいし、対応する文書のレコードの特定の項目の内容を提供してもよい。対応する文書のレコードの内容をすべてクライアント端末20へ送ってもよい。中間結果リスト内に検索条件を満たすレコードが存在しなかった場合(ステップS5でNO)、検索条件を満たす文書が見つからなかった旨を表す情報をクライアント端末20へ送る(ステップS7)。
図9は、クライアント端末20からの検索要求に応じて文書管理サーバ10の要求処理部140が図7及び図8の例の手順の処理を行った結果、図7のステップS6でクライアント端末20の表示装置に表示される表示画面の一例である。図9は、図5及び図6を参照して説明した操作履歴において、管理ID"Doc1"〜"Doc3"までのレコードが登録されている時点で、ID付き文書"Doc1"を指定文書として検索要求(検索条件:指定文書の子孫に該当する文書のうち操作種別が「応答」である文書)がなされた場合の表示画面の例である。図9を参照し、ID付き文書"Doc1"の子であって操作種別が「応答」であるID付き文書"Doc2","Doc3"のそれぞれについて、応答日時(操作日時)及び応答者(操作者)が表示される。図9では、各文書の管理IDは図示していないが、図9の表示画面中の表における行60a及び行60bが、それぞれID付き文書"Doc2","Doc3"に対応する。この表示画面において、マウスなどの入力装置を用いてuserAがチェックボックスにチェックを入れ(文書の選択)、「チェックした文書をダウンロード」ボタンを押下する(例えば、マウスによる「クリック」操作、又は当該ボタンを選択した上でのキーボードの「リターンキー」の入力操作などを行う)と、その旨を表す情報を受け取った文書管理サーバ10の要求処理部140は、選択されたID付き文書をuserAのクライアント端末20へ送信する。すなわち、選択されたID付き文書は、userAのクライアント端末20にダウンロードされる。クライアント端末20の文書操作部200は、このダウンロード操作の結果として新たなID付き文書300を生成し、この新たなID付き文書300は、文書管理サーバ10に登録される。
例えば、図9の例の表示画面において、ID付き文書"Doc2","Doc3"の両方が選択され(チェックボックスにチェック)て「チェックした文書をダウンロード」ボタンが押下されると、ID付き文書"Doc2","Doc3"が文書管理サーバ10からクライアント端末20にダウンロードされる。クライアント端末20の文書操作部200は、このダウンロード操作の結果の文書に対して新たな管理ID"Doc4","Doc5"を付与する。そして、親IDがそれぞれ"Doc2","Doc3"であり、操作種別が「回収」であるID付き文書"Doc4","Doc5"が生成され、登録処理部210により文書管理サーバ10に登録される。このときのクライアント端末20における処理の詳細は、図5及び図6を参照して上記で説明した。
図10は、図7のステップS6でクライアント端末20の表示装置に表示される表示画面の他の一例を示す。図10は、図5及び図6を参照して説明した文書の履歴において、ID付き文書"Doc1"〜"Doc6"のレコードが派生関係DB110に登録されている時点で、ID付き文書"Doc1"を指定文書としてクライアント端末20からの検索要求(検索条件:指定文書の子孫に該当する文書のうち操作種別が「応答」である文書)を受けて要求処理部140が図7及び図8の例の処理を行った結果として表示される表示画面の例である。図10の例の表示画面中の表において、行70a,70b,70cは、それぞれ、検索条件を満たすID付き文書"Doc2","Doc3","Doc6"に対応する。図10では、ID付き文書"Doc2","Doc3","Doc6"のうち、操作種別が「回収」である文書を子として有するID付き文書"Doc2","Doc3"と、操作種別が「回収」である文書を子として有しないID付き文書"Doc6"と、が互いに異なる態様で表示される。具体的には、すでに「回収」操作が実行されているID付き文書"Doc2","Doc3"については、ダウンロードを選択するチェックボックスが表示されず、かつ、各文書に対して「回収」操作が行われた日時である「回収日時」及びその操作者である「回収者」が表示される。未だ「回収」操作が実行されていないID付き文書"Doc6"については、ダウンロードを選択するチェックボックスが表示され、「回収日時」及び「回収者」は表示されない。
図10の例のような表示画面をクライアント端末20に表示させる場合、要求処理部140は、図7のステップS6で、例えば以下の手順の処理を行う。まず、検索条件を満たす検索結果文書のそれぞれについて、操作種別が「回収」である文書を子として有するか否かを判定する。この判定は、派生関係DB110において、検索条件を満たす各文書の管理IDを親IDとして有するレコードの操作種別を確認することで行う。そして、操作種別が「回収」である文書を子として有する検索結果文書について、その子である「回収」操作に対応するレコードの操作日時及び操作者の値を、それぞれ、クライアント端末20の表示画面に表示させる「回収日時」及び「回収者」の値とする。その後、要求処理部140は、操作種別が「回収」である文書を子として有する検索結果文書については、ダウンロードを選択するチェックボックスを非表示にし、かつ、「回収日時」及び「回収者」を表示させ、操作種別が「回収」である文書を子として有しない検索結果文書については、ダウンロードを選択するチェックボックスを表示させ、かつ、「回収日時」及び「回収者」を表示させないことを指示する表示情報をクライアント端末20に対して送信する。以上の例の処理によると、検索結果文書のいずれも操作種別が「回収」である子文書を有しない場合、図9の例のような表示画面がクライアント端末20の表示装置に表示され、検索結果文書のいずれかが操作種別が「回収」である子文書を有する場合、図10の例のような表示画面がクライアント端末20の表示装置に表示される。
以上では、サービス要求において特定される検索条件が「指定文書の子孫に該当する文書のうち操作種別が「応答」である文書」である場合の例を説明した。他の例では、検索条件を「指定文書の子孫に該当する文書のうち操作種別が「応答」であり、かつ、操作種別が「回収」である子文書を有しない文書」としてもよい。例えば、クライアント端末20の文書操作部200において、「応答文書一覧の表示」コマンドの実行を指示する操作メニュー上で、「回収済みの文書は表示しない」とするオプションをユーザが選択した場合に、本例の検索条件を指定するサービス要求が文書管理サーバ10へ送信される。本例の検索条件を用いる場合、文書管理サーバ10の要求処理部140は、図7のステップS5において、中間結果リスト中のID付き文書のレコードのうち、操作種別が「応答」であって、かつ、当該レコードの管理IDを親IDとして有するレコードの中に操作種別が「回収」であるものが存在しないレコードを、検索条件を満たすレコードとして判定する。図5の例の内容のデータを派生関係DB110が有する場合に、指定文書"Doc1"として本例の検索条件によって要求処理部140が図7及び図8の例の手順の処理を行うと、ID付き文書"Doc6"(指定文書"Doc1"の子孫に該当し、操作種別が「応答」であり、かつ、操作種別が「回収」である子文書を有しない文書である)に関する情報が検索結果として提供される。
また、以上で説明した例では、検索要求に応じて、まず、検索結果を満たす文書のリストを表示させ、そのリスト中で選択された文書に対して「回収」操作が行われる。他の例では、検索結果を満たす文書のリストの中から「回収」操作の対象となる文書の選択を受け付ける代わりに、文書管理サーバ10は、検索結果を満たす文書のすべてについて、文書内容を含むID付き文書をクライアント端末20に送信してもよい。この例の場合、クライアント端末20は、検索結果を満たすID付き文書を受け取ると、受け取ったID付き文書の管理IDを親IDとし、操作種別が「回収」である新たなID付き文書を生成し、生成した新たなID付き文書を文書管理サーバ10に登録する。
以上で説明した処理の例では、新規登録されたフォーム文書に対する記入は行なわれるが、フォーム文書自体が更新されることはない。他の例では、フォーム文書自体が更新されて文書管理サーバ10に登録される(フォーム文書の改訂版の登録)こともある。フォーム文書の改訂版が登録される場合、文書管理サーバ10は、フォーム文書のバージョンを管理してもよい。
図11に、文書管理サーバ10がID付き文書のバージョン管理を行う場合の派生関係DB110のデータ内容の例を示す。図11を参照し、各管理IDに対応づけて、図5で例示した項目(親ID、操作種別、操作者、操作日時)に加えて、「文書バージョン」の項目が登録される。図11の例で、ID付き文書"Doc1"〜"Doc6"までの操作の履歴は、図5及び図6を参照して説明した履歴と同様である。文書管理サーバ10の派生関係登録部132は、ID付き文書をクライアント端末20から受け取った場合に、操作種別を確認し、「新規登録」であれば、派生関係DB110において対応するレコードの「文書バージョン」の項目の値を、最初のバージョンであることを表す情報(図11の例では、「ver1」)に設定する。また、クライアント端末20から受け取ったID付き文書の操作種別が「改訂」であれば、そのID付き文書の親IDのバージョンの1つ後のバージョンであることを表す情報を文書バージョンとして設定する。操作種別が「新規登録」及び「改訂」のいずれでもない場合、親IDのレコードの文書バージョンの値と同じ値を文書バージョンとして設定する。
例えば、図11を参照し、管理ID"Doc6"のレコードが派生関係DB110に登録された後、新規登録されたフォーム文書であるID付き文書"Doc1"に対して、userAが自己のクライアント端末20の文書操作部200を用いて編集を加え、操作メニュー上で「改訂(フォーム文書の改訂版として登録)」を指示すると、新たなID付き文書"Doc7"が生成されて文書管理サーバ10の派生関係DB110に登録される。ID付き文書"Doc7"の親IDは"Doc1"、操作種別は「改訂」、操作者はuserAである。ID付き文書"Doc7"を受け取った文書管理サーバ10において、派生関係登録部132は、ID付き文書"Doc7"の操作種別が「改訂」であることから、ID付き文書"Doc7"の親ID"Doc1"を管理IDとするレコードを派生関係DB110から検索する。そして、管理ID"Doc1"のレコードの文書バージョン「ver1」の1つ後のバージョンであることを表す情報である「ver2」を、ID付き文書"Doc7"に対応する派生関係DB110のレコードの文書バージョンの値として登録する。ID付き文書"Doc7"のレコードが派生関係DB110に登録された後、改訂版のフォーム文書であるID付き文書"Doc7"に対してuserEが「応答」操作を行うと、ID付き文書"Doc7"の子としてID付き文書"Doc8"のレコードが派生関係DB110に登録される。ID付き文書"Doc8"をクライアント端末20から受け取ったとき、文書管理サーバ10の派生関係登録部132は、ID付き文書"Doc8"の操作種別が「応答」であって、「新規登録」及び「改訂」のいずれでもないので、ID付き文書"Doc8"の親文書"Doc7"と同じ文書バージョン「ver2」をID付き文書"Doc8"の文書バージョンとして登録する。
図12は、"Doc8"が登録された時点での、図11の例の派生関係DB110内の派生関係が成す木構造を示す。
図13は、派生関係DB110が図11に例示するデータ内容を有する場合に、文書管理サーバ10がクライアント端末20からID付き文書"Doc1"を指定文書とする検索要求(検索条件:指定文書の子孫に該当する文書のうち操作種別が「応答」である文書)を受けたときに、要求処理部140による図7の例の手順の処理の結果としてクライアント端末20の表示装置に表示される表示画面の一例である。図13の例の表示画面では、検索条件を満たす文書"Doc2","Doc3","Doc6","Doc8"のそれぞれについて、図10の例の表示画面で表示される項目に加えて、文書バージョンが表示される。図13の例の表示画面中の表における行80a,80b,80c,80dが、それぞれ、文書"Doc2","Doc3","Doc6","Doc8"に対応する。図13の例の表示画面により、フォーム文書の文書バージョンとともに、「応答」操作に対応する文書に対する「回収」操作の実行状況がユーザに提示される。
以上で説明した実施形態の処理の例では、操作種別限定部150は、派生関係DB110への登録対象のID付き文書300の操作種別を限定しない旨を文書登録部130に通知し、文書登録部130は、クライアント端末20から受け取ったID付き文書300を、その操作種別にかかわらず派生関係DB110に登録する。以下、操作種別限定部150が派生関係DB110への登録対象のID付き文書300の操作種別を限定する場合の文書登録部130の処理の例を説明する。一例として、操作種別限定部150が、操作種別が「新規登録」又は「応答」であるID付き文書のみを登録対象として派生関係DB110に登録することを文書登録部130に指示する場合の処理を説明する。文書管理サーバ10の文書登録部130は、クライアント端末20からID付き文書300を受け取ると、そのログ情報316から操作種別を抽出し、抽出した操作種別が「新規登録」又は「応答」であるか否かを判定する。当該ID付き文書300の操作種別が「新規登録」又は「応答」であれば、文書登録部130は、その文書内容320を文書DB100に登録し、派生関係登録部132は、そのメタ情報310を派生関係DB110に登録する。当該ID付き文書300の操作種別が「新規登録」及び「応答」のいずれにも該当しない場合、文書登録部130は、当該ID付き文書300の文書内容320及びメタ情報310の文書DB100及び派生関係DB110への登録を行わない。この場合、クライアント端末20で保持しているID付き文書300のIDを操作前のIDに戻す処理が行われる。
また、以上で説明した実施形態の例では、文書管理サーバ10は、各ID付き文書の管理IDに対応づけて、その親ID及びログ情報(操作種別、操作者、及び操作日時など)を派生関係DB110に登録する。他の実施形態の例では、親ID及びログ情報だけでなく、ID付き文書300の文書内容320から抽出される情報を、そのID付き文書300の管理IDに対応づけて派生関係DB110に登録してもよい。例えば、ID付き文書300の文書内容320について、テキスト抽出処理やOCR(Optical Character Reader)処理などを施すことで文書内容320に含まれるテキスト情報を抽出し、抽出したテキスト情報を属性情報として管理IDに対応づけて派生関係DB110に登録してもよい。
図14に、ID付き文書300の文書内容320から抽出した情報をメタ情報310とともに派生関係DB110に登録する場合の派生関係DB110のデータ内容の一例を示す。図14は、物品の購入の申請書フォームであるID付き文書"Doc11"(操作種別は「新規登録」)から派生する文書の操作履歴の例を示す。図14の例の派生関係DB110には、各管理IDに対応づけて、図5の例と同様の項目(親ID、操作種別、及び操作日時)に加えて、「金額」、「数量」、及び「品目」の各項目が登録される。図14を参照し、ID付き文書"Doc11"に対して、各userB、userC、及びuserDが記入を行って「応答」操作をすることで、それぞれの「応答」操作の結果のID付き文書"Doc12","Doc13",及び"Doc14"に対応するレコードが派生関係DB110に登録される。文書管理サーバ10の文書登録部130は、操作種別が「応答」であるID付き文書300をクライアント端末20から受け取った場合、そのID付き文書300の文書内容320に対してテキスト抽出処理やOCR処理を行うことで、「金額」、「数量」、及び「品目」の各項目の値に対応する情報を抽出する。ここで抽出する項目は、例えば文書管理サーバ10の管理者などによって、フォーム文書の形式に従って予め設定される。なお、図14の例では、操作種別が「応答」である文書についてのみ文書内容320からの情報の抽出が行われるとする。
また、図14の表は、文書管理サーバ10の操作種別限定部150が登録対象のID付き文書の操作種別を「新規登録」及び「応答」に限定する場合の派生関係DB110のデータ内容の一例でもある。
図14の例の表において、管理ID"Doc11"〜"Doc14"のレコードが派生関係DB110に登録された時点で、userAのクライアント端末20から管理ID"Doc11"を指定文書とする検索要求(検索条件:指定文書の子孫に該当する文書のうち操作種別が「応答」である文書)が出されると、文書管理サーバ10の要求処理部140は、図7及び図8の例の手順の処理を行って、図15に例示する表示画面をクライアント端末20の表示画面に表示させる。図15を参照すると、ID付き文書"Doc11"に対する「応答」操作に対応するID付き文書"Doc12","Doc13","Doc14"のそれぞれについて、応答日時(操作日時)、応答者(操作者)、金額、数量、及び品目の各項目の内容が表示される。図15の例の表示画面中の表において、行90a、90b、90cは、それぞれ、ID付き文書"Doc12","Doc13","Doc14"に対応する。図15の例の表示画面により、各ID付き文書"Doc12","Doc13","Doc14"の文書内容の一部がuserAに提示されることになる。
図15の例の表示画面において各ID付き文書に対応づけられるチェックボックス及び「チェックした文書を回収済みにする」ボタンに対する入力は、クライアント端末20の強制登録指示受付部220によって強制登録指示として受け付けられる。例えば、userAが、図15の例の表示画面において、ID付き文書"Doc12","Doc13"に対応するチェックボックスにチェックを入れた上で、「チェックした文書を回収済みにする」ボタンに対してクリック操作を行ったとする。この場合、強制登録指示受付部220は、userAによる前述の入力を、各ID付き文書"Doc12","Doc13"に対する「回収」操作の結果のID付き文書についての強制登録指示として受け付ける。そして、強制登録指示受付部220は、文書操作部200に対し、各ID付き文書"Doc12","Doc13"に対する「回収」操作の結果のID付き文書300の生成を依頼する。強制登録指示受付部220からの依頼に応じて、文書操作部200は、強制登録指示があった旨を表す情報をメタ情報310のログ情報316中に含むID付き文書300を生成する。例えば、ID割り当て部202において、各ID付き文書"Doc12","Doc13"に対する「回収」操作の結果の文書に対して新たな管理ID"Doc15","Doc16"を付与する。派生関係組込部204において、ID割り当て部202が付与した新たな管理ID"Doc15","Doc16"のそれぞれに対応するメタ情報310を2つ生成する。派生関係組込部204は、管理ID"Doc15"のメタ情報310中の親IDを"Doc12"とし、管理ID"Doc16"のメタ情報310中の親IDを"Doc13"に設定する。また、各管理ID"Doc15","Doc16"のメタ情報310中のログ情報316において、操作種別をいずれも「回収」に設定する。さらに、派生関係組込部204は、ログ情報316において、強制登録指示があった旨を表す情報を設定する。
図16は、管理ID"Doc15","Doc16"のそれぞれについて、派生関係組込部204が生成するメタ情報310の内容の例を示す。図16の例の表の1行の内容が各管理IDのメタ情報の内容を示す。図16に例示する各管理ID"Doc15","Doc16"のメタ情報は、すでに説明した親ID、操作種別、操作者、及び操作日時の各項目に加えて、「強制登録」の項目を含む。図16を参照すると、強制登録の項目の値は、いずれも「yes」に設定されている。これは、ID付き文書"Doc15","Doc16"についてユーザからの強制登録指示があった旨を表す。文書操作部200は、図16に例示する内容のメタ情報を含むID付き文書"Doc15","Doc16"を生成し、登録処理部210に対して出力する。登録処理部210は、これらのID付き文書"Doc15","Doc16"を文書管理サーバ10へ送信する。なお、ID付き文書"Doc15","Doc16"の文書内容320は空である。
文書管理サーバ10の文書登録部130は、クライアント端末20から受け取ったID付き文書300のログ情報316中に、強制登録指示があった旨を表す情報が含まれる場合、操作種別限定部150が登録対象として指定した操作種別に当該ID付き文書300の操作種別が含まれているか否かにかかわらず、当該ID付き文書300に対応するレコードを派生関係DB110に登録する。したがって、例えば、操作種別限定部150において操作種別が「新規登録」又は「応答」であるID付き文書に対応するレコードのみを派生関係DB110に登録するよう文書登録部130に指示している場合であっても、「強制登録」の項目の値が「yes」であるID付き文書"Doc15","Doc16"(操作種別は「回収」)については、文書登録部130は、各文書に対応するレコードを派生関係DB110に登録する。図14の例の派生関係DB110のデータ内容において、管理ID"Doc15","Doc16"のレコードは、強制登録指示に関する以上の処理の例により、操作種別限定部150による指示内容を無視して登録されたレコードである。
再び図15を参照し、「内容確認」ボタンは、対応するID付き文書をクライアント端末20にダウンロードすることを指示するボタンである。クライアント端末20の表示画面において「内容確認」ボタンが押下されると、文書管理サーバ10からクライアント端末20に対して、対応するID付き文書がダウンロードされる。クライアント端末20の文書操作部200は、このダウンロード操作に対応するID付き文書を生成する(操作種別は「ダウンロード」)。このとき生成されるID付き文書は、そのログ情報中に強制登録指示があった旨の情報を含まない。例えば、ログ情報中の「強制登録」の項目の値を「yes」と異なる値(例えば、「no」又は「空(null)」など)に設定する。あるいは、ログ情報中に「強制登録」の項目自体を含まないものとしてもよい。クライアント端末20は、図15の例の「内容確認」ボタンの押下によるダウンロード操作の結果として生成されるID付き文書を文書管理サーバ10へ送信する。文書管理サーバ10において操作種別限定部150により登録対象の操作種別が「新規登録」又は「応答」に制限されている場合、上述のダウンロード操作の結果のID付き文書を受け取った文書管理サーバ10は、その操作種別が「ダウンロード」であり、かつ、強制登録指示があった旨を表す情報がログ情報中に含まれないことから、当該ID付き文書に関して派生関係DB110への登録を行わない。この場合、クライアント端末20で保持しているID付き文書のIDを操作前のIDに戻す処理が行われる。
以上、文書管理サーバ10の操作種別限定部150及びクライアント端末20の強制登録指示受付部220に関連する処理の一例を説明した。上述の例では、クライアント端末20は、ID付き文書に対して行なわれた操作の操作種別が文書管理サーバ10の操作種別限定部150によって登録対象として設定されているか否かにかかわらず、操作結果のID付き文書を文書管理サーバ10に対して送信する。他の例では、クライアント端末20において、文書管理サーバ10の操作種別限定部150の設定内容を表す情報を記憶装置(図示しない)に記憶させ、登録対象である操作種別の操作が実行された場合のみ、ID付き文書を文書管理サーバ10に送信してもよい。クライアント端末20において、操作種別限定部150の設定内容に従って文書管理サーバ10へのID付き文書の送信の有無を決定する例の場合、強制登録指示受付部220が特定のID付き文書について強制登録指示を受け付けると、操作種別限定部150の設定内容にかかわらず当該ID付き文書を文書管理サーバ10へ送信する構成とすることで、強制登録指示のあったID付き文書は文書管理サーバ10に登録される。
以上で説明した各種の処理の例では、文書管理サーバ10に対する検索要求の結果としてID付き文書をクライアント端末20に提供することを1つの「操作」として捉える。そして、当該操作(上述の例では、操作種別は「回答」)に対応するID付き文書は、検索結果としてクライアント端末20に提供されたID付き文書の子文書として文書管理サーバ10に登録される。
以上に例示した例では、管理IDの発行は主に各クライアント端末20で行われていたが、この代わりに文書管理サーバ10がすべての管理IDを発行してもよい。この場合、クライアント端末20は、ID付き文書に対して操作を行った場合、操作前のID付き文書内の管理IDを親ID314として含み、更にその操作についてのログ情報316と操作後の文書内容320とを含み、管理ID312は空欄の文書データを生成し、文書管理サーバ10に送る。文書管理サーバ10は、受け取った文書データに対して新たな管理IDを付与し、この管理IDとその文書データとに含まれる情報を、文書DB100及び派生関係DB110に登録する。また、文書管理サーバ10は、付与した管理IDを当該文書データにセットすることによりID付き文書を生成し、これをクライアント端末20に返す。クライアント端末20は、操作前のID付き文書を、受け取ったID付き文書に置き換える。このように、文書管理サーバ10が管理IDを付与する構成でも、上述の各例の処理は同様に実行できる。
また以上の例では、管理ID312、親ID314、ログ情報316、及び文書内容320を含んだID付き文書300がクライアント端末20に保存されたが、この代わりに、クライアント端末20は管理IDしか持たず、その他の情報は文書管理サーバ10に保存されるようにしてもよい。この場合、クライアント端末20で文書を操作する場合、その文書に対応する管理IDを文書管理サーバ10に送り、文書管理サーバ10からその文書を取得する。また、別の例として、クライアント端末20が保持するID付き文書300の中には管理ID312と文書内容320とが含まれ、親ID314及びログ情報316は含まれないようにしても良い。この場合、サーバがその管理ID312に対応づけて親ID314とログ情報316を持つようにすれば良い。
ここで、文書管理サーバ10が管理IDを付与する場合は、その取得の操作に対応する管理IDを文書管理サーバ10が生成し、その管理IDと文書とを対応づけてクライアント端末20に提供するとともに、その取得操作についてのログ情報(操作時刻や操作者など)と、元の管理ID(すなわち親ID)と、付与した管理IDとを派生関係DB110に記録する。クライアント端末20は、文書管理サーバ10に送信した管理IDを、受け取った管理IDに置き換えるとともに、受け取った文書を開く。ユーザは、開かれた文書に対して閲覧や編集などの操作を行う。クライアント端末20は、文書に対する操作が完了すると、操作後の文書を管理ID及び当該操作についてのログ情報とともに文書管理サーバ10に送る。文書管理サーバ10は、受け取った文書に対して新たな管理IDを付与して派生関係DB110に登録し、受け取った管理IDを親IDとして派生関係DB110に登録する。また、受け取ったログ情報及び操作後の文書を、派生関係DB110及び文書DB100に登録する。そして、文書管理サーバ10は、新たに付与した管理IDをクライアント端末20に返す。クライアント端末20は、元の管理IDを受け取った管理IDで置き換える。以上のような処理により、操作間の派生関係が文書管理サーバ10に蓄積されることになる。
一方、クライアント端末20が管理IDを付与する構成の場合は、文書管理サーバ10は、クライアント端末20から受け取った管理IDに対応する文書をクライアントに返せばよい。クライアント端末20は受け取った文書を開き、ユーザがその文書を操作する。操作の完了後、クライアント端末20はその操作結果の文書に対して新たな管理IDを付与し、この管理IDを含んだ前述のID付き文書と同様の情報を、文書管理サーバ10に送る。そして、クライアント端末20は、そのID付き文書のうち管理IDのみを保存し、その他の情報を削除する。
以上に例示したシステムにおける文書管理サーバ10は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図17に示すように、CPU(中央演算装置)40、メモリ(一次記憶)42、各種I/O(入出力)インタフェース44等がバス46を介して接続された回路構成を有する。また、そのバス46に対し、例えばI/Oインタフェース44経由で、HDD(ハードディスクドライブ)48やCDやDVD、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ50が接続される。このようなドライブ48又は50は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがCDやDVD等の記録媒体を経由して、又はネットワーク経由で、HDD48等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されCPUにより実行されることにより、実施形態の処理が実現される。クライアント端末20についても同様である。
10 文書管理サーバ、20 クライアント端末、30 ネットワーク、40 CPU、42 メモリ、44 I/Oインタフェース、46 バス、48 HDD、50 ディスクドライブ、100 文書DB、110 派生関係DB、130 文書登録部、132 派生関係登録部、140 要求処理部、150 操作種別限定部、200 文書操作部、202 ID割り当て部、204 派生関係組込部、210 登録処理部、220 強制登録指示受付部、300 文書、310 メタ情報、320 文書内容。