まず、図1を参照して、実施形態の制御方式が適用される文書利用管理システムの概略構成の一例を説明する。図1に示したシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク30を介して接続された文書管理サーバ10とクライアント端末20−1,20−2,・・・(以下、クライアント端末20と総称する)から構成される。
クライアント端末20について図2を用いて説明する。クライアント端末20は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複合機などがその一例である。クライアント端末20は、文書操作部200,登録処理部210を備える。文書操作部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は、編集完了の時刻と、その編集を指示したユーザの識別情報と、操作の種別として「更新」と、を含んだものとなる。
図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は、そのメタ情報310を操作結果の文書内容に付加することにより、操作後のID付き文書300を生成して出力する。
なお、このように生成された操作後のID付き文書300を、操作前のID付き文書300と置き換えるようにしてもよい。この場合、複製を作る操作が行われない限り、クライアント端末20中に先祖の文書とその子孫の文書とが同居することはない。これには、例えば、派生関係組込部204は、操作前のID付き文書300のファイルを開いて操作を行った場合、文書内容320の操作結果をそのファイル中に書き戻すと共に、そのファイル中のメタ情報310の各項目312〜316をその操作に応じて書き換えるようにすればよい。
登録処理部210は、文書操作部200が出力したID付き文書300を文書管理サーバ10に送信し、登録する。このように各クライアント端末20が、自ら実行した操作の結果であるID付き文書300を文書管理サーバ10に登録することにより、文書管理サーバ10は各ID付き文書300間の派生関係を把握することができる。
なお、登録処理部210がID付き文書300を文書管理サーバ10に登録しようとする際に、文書管理サーバ10と通信できない場合、登録処理部210は、そのID付き文書300を保存しておき、後で文書管理サーバ10と通信可能となったときに文書管理サーバ10に登録してもよい。
文書操作部200が操作の結果出力するID付き文書300は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。他の人からID付き文書300を受け取った人が、自分のクライアント端末20の文書操作部200を用いてそのID付き文書300を操作すると、その操作に応じて新たな管理IDを付与されたID付き文書が生成されることになる。
また、文書操作部200が電子文書を印刷する場合、管理IDを生成し、その電子文書の印刷結果にその管理IDを埋め込んでもよい。管理IDの埋め込みは、例えば電子文書の印刷画像に、管理IDを示すコード画像を重畳する等の方法で行うことができる。また、RFIDタグなどのデータ保持可能な微小デバイスが装着或いは漉き込まれた用紙を用いる場合には、管理IDを用紙中のそのデバイスに書き込んでもよい。
このように紙文書に管理IDを記録した場合、文書操作部200は、その管理IDや操作種別「印刷」等のメタ情報を含んだID付き文書を文書管理サーバ10に登録する。なお、ID付き文書を印刷した場合には、そのID付き文書の管理IDを親ID314として含んだID付き文書が生成される。印刷操作に対応するID付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データをなどの印刷データを、文書内容320として組み込んでもよい。
また、管理IDが埋め込まれた紙文書を文書操作部200が読み取った場合、文書操作部200は、その読み取り操作に対して新たな管理IDを付与し、読み取り結果の画像を文書内容320として含んだID付き文書を生成して文書管理サーバ10に登録する。このID付き文書の親ID314には、紙文書から読み取った管理IDがセットされる。管理IDが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。
このようにすることで、これにより、電子文書のみならず、紙文書の派生関係も管理されることとなる。
次に、文書管理サーバ10について図4を用いて説明する。文書管理サーバ10は、システム内の複数のクライアント端末20から送られてくるID付き文書300を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。文書管理サーバ10は、文書DB100,派生関係DB110,文書登録部130,要求処理部140及び派生関係検索部150を備える。
文書DB100は、クライアント端末20から送られてきたID付き文書300のうちの文書内容320を格納するデータベースである。文書DB100に格納された各文書内容320は、一意な内容IDにより管理される。内容IDとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末20が内容IDを付与してもよく、この場合、内容IDをメタ情報310に組み込んでもよい。
派生関係DB110は、そのようなID付き文書300のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図5に、派生関係DB110のデータ内容の一例を示す。図5に示した表における1行の情報が、1つのID付き文書300に対応するメタ情報レコードである。この例では、各ID付き文書300の管理IDに対応づけて、親ID、操作種類、操作者、操作時刻の各項目が登録されている。このうち、管理IDと親IDのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。
なお、図5は派生関係DB110が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係DB110は、一般的なリレーショナルデータベースとして構築することもできるし、管理IDを除くメタ情報を記述したXML(eXtensible Markup Language)文書を、管理IDをキーとして登録したデータベースとして構築することもできる。
なお、文書DB100に登録された文書内容と派生関係DB110に登録されたメタ情報との対応関係は、図6に示すような対応関係情報により管理される。この対応関係情報は、管理IDに対応づけて文書内容の内容IDを記録したものである。対応関係情報は、文書DB100が持っていてもよいし、派生関係DB110が持っていてもよい。
図5に示した派生関係DB110のデータ内容は、図7のような木構造を成す。これは、管理IDをノードとし、管理ID間の親子関係をエッジとする木構造である。
図5〜図7の例が示す文書の履歴を時系列順に説明すると、以下のようになる。まず、文書管理サーバ10に登録されていなかった文書の「登録」操作がuser1のクライアント端末で実行される。これに応じて管理IDが"Doc1"、親IDが空、操作種類が「登録」であるメタ情報と、その文書の文書内容とを含むID付き文書"Doc1"がuser1のクライアント端末から文書管理サーバ10に送られる。これに応じ、文書管理サーバ10は、そのID付き文書"Doc1"中の文書内容を文書DB100へ、メタ情報を派生関係DB110にそれぞれ登録する。登録された文書内容は内容ID"Content1"に対応づけて管理される。ID付き文書"Doc1"はuser2により閲覧され、その操作結果としてID付き文書"Doc2"が生成され、user2のクライアント端末から文書管理サーバ10に送られる。その後、user2が、自分のクライアント端末でID付き文書"Doc2"を操作し、その操作結果のID付き文書"Doc3"が文書管理サーバ10に登録される。次にuser3が文書"Doc3"を閲覧し、その結果である文書"Doc4"を文書管理サーバ10に登録するが、文書"Doc4"の文書内容は、文書"Doc3"の文書内容と同じである。次にuser2による文書"Doc3"の編集(「更新」)に応じて、編集結果の文書"Doc5"が文書管理サーバ10に登録される。更にその後、user1により文書"Doc1"が編集され、編集結果の文書"Doc6"が文書管理サーバ10に登録される。
なお、図5では、派生関係DB110に、管理IDの派生関係(親子関係)と共に操作種類等のログ情報を合わせて登録したが、これは一例に過ぎない。管理IDの派生関係と、ログ情報とを別々のデータベースで管理してもよい。この場合、ログ情報のデータベースは、管理IDにより検索できるようにしておけばよい。
また、文書管理サーバ10は、管理ID間の派生関係を木構造として表現する情報を作成・管理し、新たにID付き文書300を受信すると、そのID付き文書300に含まれる管理IDを、その木構造に追加してもよい。この追加は、例えば、受信したID付き文書300に含まれる親IDをその木構造の中から探し、その親IDの子としてその管理IDを木構造に追加すればよい。なお、受信したID付き文書300に含まれる親IDがその木構造の中にない場合、それはその親IDを管理IDとするID付き文書が文書管理サーバ10に未登録の場合である。この場合、受信したID付き文書300の管理IDを既存の木構造に接続することはできないが、その管理IDと親IDの関係とログ情報とをDB110に登録することはできる。この場合、例えばその管理IDを保留状態としておけばよい。その後、その親IDを管理IDとするID付き文書が文書管理サーバ10に登録された場合に、保留状態であった管理IDを木構造に組み込むことが可能になる。
もちろん、そのような木構造は、派生関係DB110内にある管理IDと親IDとのペア群から動的に構成することもできるので、上述のように予め作成しておくことは必須のことではない。
また、この例では、ID付き文書300内に管理ID312と親ID314を組み込んでいるが、これは操作後のID付き文書300を文書管理サーバ10に送ることで、文書管理サーバ10に操作により形成されたIDの親子関係を通知することとしているからである。ID付き文書10を送る代わりに親子関係(管理IDと親IDのペア等)を文書管理サーバ10に送る構成とした場合には、ID付き文書10には親ID314を含めなくてもよい。
再び図4の説明に戻ると、文書登録部130は、クライアント端末20から受信したID付き文書の中の文書内容を文書DB100に、メタ情報を派生関係DB110に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部132である。
要求処理部140は、クライアント端末20からの管理IDを含んだサービス要求に応じて、派生関係DB110を用いたサービスを提供する。要求処理部140が提供するサービスとしては、例えば、サービス要求中の管理IDに対応する文書の最新版を検索するサービスがある。また別の例として、サービス要求中の管理IDに対応する始祖の文書又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、その管理IDの来歴、すなわち始祖からその管理IDまでに文書が経てきた操作の履歴(例えば誰がいつどんな操作をしたのかを示す情報のリスト)を提供するサービスもある。
サービス要求は、クライアント端末20に保持されたID付き文書に基づき発せられる。例えば、ユーザがクライアント端末20の文書操作部200によりID付き文書を開いた場合に、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付け、そのID付き文書の管理IDと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ10の要求処理部140に送信する。
また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理IDを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のID付き文書の管理IDを親IDとして含んだID付き文書を生成し、このID付き文書をサービス要求として文書管理サーバ10に送ってもよい。この場合、要求処理部140は、受け取ったID付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくID付き文書内の親IDを、派生関係を遡る処理の起点とする。
要求処理部140は、クライアント端末20からサービス要求を受けた場合、そのサービス要求中に指定された管理IDを検索条件の少なくとも1項目として含んだ検索要求を派生関係検索部150に送る。
派生関係検索部150は、要求処理部140からの検索要求に応じて、派生関係DB110に登録された管理IDと親IDとの派生関係が構成する木を走査(トラバース)し、その走査の結果得られた情報を要求処理部140に返す。要求処理部140は、その走査結果の情報を用いて、ユーザから要求されたサービスを実行する。
以上のシステムでは、クライアント端末20はID付き文書300を文書管理サーバ10に送信し、文書管理サーバ10は受信したID付き文書300に含まれるメタ情報310及び文書内容320をそれぞれデータベースに保存したが、これは一例に過ぎない。この代わりに、例えば、文書管理サーバ10が各文書のメタ情報310のみを管理する構成としてもよく、この場合クライアント端末20での操作結果の文書内容320は文書管理サーバ10には送られず、メタ情報310のみが送られる。また、文書管理サーバ10が文書間の派生関係のみを管理する構成としてもよく、この場合クライアント端末20は文書の操作前のIDである親IDと操作結果に付与した新たな管理IDとの派生関係のみを文書管理サーバ10に送ればよい。
以上のようなシステムにおいて、文書管理サーバ10に対して通信できない状態にあるクライアント端末20にてID付き文書が操作された場合を考える。例えば、図8の例では、3つのクライアントX,Y,ZのうちクライアントYだけが文書管理サーバ10にアクセスできないとする。図に示すA〜Dの符号は、各文書(ID付き文書)の管理IDを示す。図8に示される処理の流れは以下の通りである。
(1)まずクライアントXが、管理ID Aを持つ文書に対して操作を行い、操作後の文書に対して管理ID Bを埋め込む。文書管理サーバ10に対し、派生関係A→Bとその操作についてのログ情報(或いはそれらを含んだID付き文書)が送られる。
(2)クライアントXからその文書(管理ID B)が文書管理サーバ10にアクセスできないクライアントYに送られ、クライアントYがその文書に対して操作を行い、操作後の文書に対して管理ID Cを埋め込む。文書管理サーバ10にアクセスできないので、派生関係B→Cとログ情報は文書管理サーバ10に送られない。
(3)さらにその文書(管理ID C)がクライアントYからクライアントZに送られ、クライアントZがその文書に対して操作を行い、操作後の文書に対して管理ID Dを埋め込む。クライアントZから文書管理サーバ10に派生関係C→Dとログ情報(或いはそれらを含んだID付き文書)が送られる。
この流れでは、実際の管理IDの派生関係はA→B→C→Dであるが、途中のB→Cが文書管理サーバ10に送られないため、文書管理サーバ10側ではA→BとC→Dの派生関係同士を結びつけることができない。このため、派生関係に基づくサービスが正しく提供できなくなる。
例えば、文書が指定されると、そこに埋め込まれた管理IDから派生関係を新しい方に辿り、その文書に対して最後に操作を行ったユーザを知らせるといったサービスを考える。このサービスでは、管理ID Aが埋め込まれた文書が指定された場合、本来は派生関係をAからDへと辿り、管理ID Dを埋め込んだクライアントZのユーザを返すべきである。しかし、この例では、文書管理サーバ10ではAからBまでしかたどれないため、文書Bを生成した操作を行ったクライアントXのユーザを返してしまう。
このようなことは、社外に持ち出されたノートパソコンや、FAXはつながっているが全社ネットワークにはつながっていない現場事務所のデジタル複合機(プリンタ、スキャナ、コピー機、ファクシミリ等の機能を兼ね備えた装置)等、一時的もしくは恒久的に文書管理サーバ10にアクセスできないクライアントを文書が経由する場合に生じ得る。
なお、クライアント端末20が、通信不可等により文書管理サーバ10に送信できなかったID付き文書300を、あとで通信が可能となった段階で送信する構成を取った場合でも、送信できなかった時点から後で送信する時点までの間は、上述の問題が生じ得る。
このような事態に対処するために、この実施形態では、図9に示すように、ID付き文書300のメタ情報310中に、親ID314(図3参照)の代わりに先祖ID情報350を組み込む。先祖ID情報350は、当該文書300の親IDから先祖方向に始祖(派生関係の木における根)まで遡る各世代の管理IDの順序付きのリストである。
この実施形態での操作による文書の変遷と文書管理サーバ10による派生関係の把握の様子を、図10に示すケースを例にとって説明する。この例における処理の流れは以下の通りである。この例でも、クライアントX,Zは文書管理サーバ10と通信できるが、クライアントYは文書管理サーバ10と通信できないとする。
(1)クライアントXにて新規の文書(管理ID A)が生成される。この文書は、親文書を操作したことにより派生したものではないので、管理ID Aに対する親IDはなく、この文書の先祖ID情報350(図9参照)は空である。クライアントXから文書管理サーバ10へ、管理ID312と先祖ID情報350とからなる派生関係情報とログ情報316(又はそれらを含むID付き文書300)が送信され、登録される。
(2)クライアントXにてその文書に対して操作が行われ、操作後の文書に対して新たに生成された管理ID Bが埋め込まれる。このとき、クライアントXが持つ操作後の文書(ID付き文書300)のメタ情報310には、管理ID Bと、先祖ID情報350としての親ID Aとが含まれる。クライアントXは、その操作についてのログ情報316と派生関係情報A→B(又はID付き文書300)を送る。
(3)次に、クライアントXからクライアントYにその文書(管理ID B)が渡される。そして、クライアントYにてその文書に対し、ユーザの指示に応じた操作が行われ、操作後の文書に対して新たに生成された管理ID Cが埋め込まれるとともに、操作前の文書に含まれていた管理ID Bが先祖ID情報350中のリストの末尾に追加される。これにより、操作後の文書は、先祖ID情報350としてA→Bの順序付きリストを持ち、管理IDとしてCを持つことになる。ここで、クライアントYは、文書管理サーバ10にアクセスすることができないので、操作後の文書の管理IDと先祖ID情報350とからなる派生関係情報(A→B→C)を文書管理サーバ10に送信することができない。
(4)次に、クライアントYからクライアントZにその文書(管理ID C)が渡される。そして、クライアントZにてその文書に対し、ユーザの指示に応じた操作が行われる。そして、操作後の文書に対して新たに生成された管理ID Dが埋め込まれるとともに、操作前の文書に含まれていた管理ID Cが先祖ID情報350中のリストの末尾に追加される。これにより、操作後の文書は、先祖ID情報350としてA→B→Cの順序付きリストを持ち、管理IDとしてDを持つことになる。クライアントZは、文書管理サーバ10と通信できるので、操作後の文書の管理IDと先祖ID情報350とからなる派生関係情報(A→B→C→D)を文書管理サーバ10に送信する。
(5)文書管理サーバ10は、受け取った派生関係情報を派生関係DB110に登録する。この場合、文書管理サーバ10は、その派生関係情報に含まれる管理IDの系列を先頭(すなわち始祖)から順に、派生関係DB110内に登録された管理ID群が構成する木群と照合する。例えば、受信した派生関係情報の先頭のIDと同じ管理IDが派生関係DB110から見つかると、その管理IDが既存の派生関係の木の根である。次に、その根の子のうち、派生関係情報における先頭から2番目の管理IDと一致するIDを探す。一致するIDが見つかれば、更に、見つかったIDの子の中から、派生関係情報における先頭から3番目の管理IDと一致するIDを探す。以上のような処理を繰り返すことで、派生関係情報と派生関係DB110内の木とのマッチングがなされる。そして、このマッチング処理において行き当たった派生関係情報中の管理IDが、派生関係DB110で管理されておらず、かつ派生関係DB110内に存在するノード(ID)の子である場合、その管理IDをそのノードの子としてその木に追加する。この追加を順に繰り返すことで、その派生関係情報の末尾のIDまでを木に追加する。
例えば図10の例では、文書管理サーバ10は、クライアントZから派生関係情報(A→B→C→D)を受け取るまでは、A→Bという派生関係の系列を知っているのみである。しかし、その後、クライアントZからその派生関係情報を受け取ると、クライアントYから送られなかったB→Cの派生関係も含め、A→Bの後にB→C→Dという派生関係が繋がることを知り、これを派生関係DB110に登録する。なお、このとき文書管理サーバ10は、管理ID Dについてのログ情報は(受信したID付き文書に含まれているので)派生関係DB110に登録することができるが、管理ID Cについてのログ情報は登録することができない(ただし、ID付き文書300に先祖の各IDのログ情報を残す構成の場合は、登録することができる)。
この実施形態におけるクライアント端末20の処理手順の一例を図11に示す。この例において、クライアント端末20にてID付き文書についての操作が行われると、派生関係組込部204は、新たな管理IDを生成し(S1)、そのID付き文書300中の管理ID312を先祖ID情報350のIDリストの末尾に追加すると共に、管理ID312の値を新たに生成した管理IDへと書き換える(S2)。この書き換えにより、操作の対象であったID付き文書が操作後のID付き文書へと置き換えられることとなる。なお、文書内容320については、操作が文書内容320の変更を伴うものである場合、その操作により変更されている。そして、登録処理部210は、文書管理サーバ10にアクセス可能であるかどうかを調べ(S3)、アクセス可能であれば、その操作後のID付き文書を文書管理サーバ10に送信する(S4)。なお、文書管理サーバ10が文書内容320を管理しない構成の場合は、ID付き文書ではなく、その中の派生関係情報(すなわち管理ID312と先祖ID情報350)、或いはこれにログ情報320を加えたものを送信すればよい。文書管理サーバ10にアクセスできない状態の場合は、文書管理サーバ10への送信は行わずに処理を終了する。なお、この場合に、送信できなかったID付き文書(或いは派生関係情報)を保存しておき、後で通信可能となったときに文書管理サーバ10に送信するようにしてももちろんよい。
上述の図10には、文書管理サーバ10と通信できるクライアントXとYの間に、通信できないクライアントが1つ(Y)だけ介在した場合を例示した。しかし、この実施形態によれば、通信できるクライアント同士の間に通信できないクライアントが複数介在した場合にも、それら複数のクライアントが送信できなかった派生関係の情報がその後の通信可能なクライアントから文書管理サーバ10に通知される。また、文書管理サーバ10と通信可能なクライアントXとZが同じ装置であってもよい。すなわち、クライアントXでの操作後の文書が、通信できないクライアントYで操作され、その操作結果がクライアントXに戻されて操作されるような場合にも、上述の方式は適用できる。例えば本社から文書が現場事務所(本社のサーバ10と通信不可)に送られ、そこで編集された後に本社に戻される場合などである。
このように、この実施形態では、クライアント端末20(X,Y,Z)間を流通するID付き文書300が、当該文書の親から始祖までの全ての先祖(すなわち、派生関係の木を遡って根に到達するまで)のIDの連なり(先祖ID情報350)の情報を保持している。そして、クライアント端末20は、文書管理サーバ10に対して操作結果のID付き文書(或いはログ情報316と管理ID等)を送る場合に、その文書自体の管理IDに加え、全ての先祖のIDの連なりである先祖ID情報350を送信する。文書管理サーバ10は、それら管理IDと先祖ID情報350により、始祖から最新の子孫までの一続きの派生関係を把握する。本来の派生関係の途中の部分が文書管理サーバ10に送られなくても、その後の派生関係の情報中にその部分が含まれているので、文書管理サーバ10は、後者の派生関係を受信した時点でその途中の部分も知るのである。
文書管理サーバ10は、管理IDを引数として持つサービス要求を受信した場合、その受信の時点での派生関係DB110に含まれる派生関係群がなす木群をその管理IDを起点に辿ることで、そのサービス要求に対応した回答を求める。例えば、図10の例で、クライアントZから派生関係情報(A→B→C→D)が文書管理サーバ10に登録された後、あるユーザが管理ID Aの文書を指定して、その文書に対して最後に操作を行ったユーザが知りたいという要求を入力した場合、文書管理サーバ10は、Aから子孫方向に派生関係の木を辿り、木の末端(葉)の管理ID Dに対応する操作を行った操作者の情報を特定してサービス要求元に返す。
以上に例示した方式を、ID付き文書を紙文書として出力する場合にも適用する場合には、紙文書に対し、管理IDのみならず、その先祖のID群のリストを記録すればよい。この記録は、例えばバーコード等の画像コードとして印刷してもよいし、RFIDタグ等の記憶デバイスを有する用紙の場合にはそのデバイスに書き込んでもよい。そして、クライアント端末20は、その紙文書に対して操作(例えばスキャン、複写など)を行った場合には、その紙文書が有する管理ID及び先祖のID群のリストを読み出して、上述の処理を行えばよい。
上述の図10の例では、ID付き文書300に対し、始祖までの先祖全部のIDを含んだ派生関係情報を持たせた。ところが、ID付き文書300を紙文書として出力し、その紙文書に対して派生関係情報をバーコード等の画像コード情報として印刷する場合には、派生関係情報のデータ量が多くなると、紙面のうちの画像コード情報のための領域に収まらなくなることもあり得る。
そこで、そのような場合を考慮した変形例として、派生関係情報に含めるIDの数を、例えば紙面のうちの画像コード情報のための領域に収まる範囲の数を考慮して予め定めた数に制限してもよい。すなわち、この場合、クライアント端末20の派生関係組込部204は、文書の操作に応じて操作前の文書の管理IDを先祖ID情報350に追加する際に、その追加により先祖ID情報350内のIDの数が予め定められた上限数を超える場合には、それらIDの中の先頭(すなわち最も古いもの)を削除することで、先祖ID情報350に含まれるIDの数が上限数以内となるようにすればよい。
この変形例では、文書管理サーバ10と通信できないクライアント端末20でその上限数に応じた数だけ連続して操作された場合(1台で連続して操作される場合も、そのような端末複数台で連続して操作される場合も含む)でも、その操作結果がその次に文書管理サーバ10と通信できるクライアント端末20で操作されれば、このクライアント端末20から送られる派生関係情報により、根から最新の操作結果までの一連の派生関係が文書管理サーバ10に伝達されることとなる。例えば、先祖ID情報350に含まれるID数の上限がn(自然数)であれば、連続した(n−1)個の親子関係の欠落が回復される。すなわち、文書管理サーバ10に通信できないクライアント端末20で連続して(n−1)回操作された場合でも、その次の通信可能なクライアント端末20からの派生関係情報により、それら(n−1)回の操作の派生関係とその次の操作による派生関係が文書管理サーバ10に登録される。
なお、この変形例では、クライアント端末20が文書管理サーバ10に対して操作後のID付き文書を送信する際に、操作前のID付き文書内の先祖ID情報350内の先頭のIDも合わせて送信してもよい。このようにした場合、回復できる連続した親子関係の欠落は1つ増えてn個となる。
例えば、図12に示す例は、ID付き文書に含まれる派生関係情報のID数を2個(すなわち、管理ID1個と、先祖ID情報のIDが1個)とした場合である。この例では、クライアントXにおける動作は図10と同じである。クライアントYでは、操作後の文書に管理ID Cが付与され、操作後の文書の派生関係情報には、ID数の制限に従いB→Cという2つのIDからなる派生関係が組み込まれる(すなわちA→Bの関係は欠落する)。このとき、クライアントYは文書管理サーバ10と通信できないので、B→Cという派生関係は文書管理サーバ10には伝わらない。次に、その文書がクライアントZで操作されると、操作後の文書に管理ID Dが付与され、操作後の文書の派生関係情報には、ID数の制限に従いC→Dという派生関係が組み込まれる(すなわち文書中からはB→Cの関係は欠落する)。このとき、クライアントZが、その操作の前の文書の先祖ID情報350の先頭にあったBを含めたB→C→Dという派生関係を文書管理サーバ10に送れば、当該クライアントZでの操作による派生関係C→Dだけでなく、通信不可であったYでの操作による派生関係B→Cも文書管理サーバ10に伝達されることとなる。
次に第2の変形例について説明する。第2の変形例では、クライアント端末20は、操作による派生関係の情報を文書管理サーバ10に送信・登録できる場合とできない場合とで異なる振る舞いをする。すなわち、図13に示すように、クライアント端末20は、文書管理サーバ10と通信できない場合(S10の判定結果がNo)には、図10の例と同様、操作前のID付き文書の管理IDを先祖ID情報350に追加するとともに、管理ID312の値を新たに付与した値に書き換える(S11)。一方、通信できる場合は、操作前のID付き文書に含まれていた派生関係情報(すなわち先祖ID情報350中のIDリストに管理ID312を加えたもの)と新たに付与した管理IDとを文書管理サーバ10に通知し(S12)、操作後のID付き文書の先祖ID情報350をクリアして空にする(S13)。
具体例を図14に示す。この例では、文書管理サーバ10と通信できないクライアントYが文書(管理ID B)に対して操作を行った場合、操作後の文書は先祖ID情報350に操作前の管理ID Bを含んだものとなる。すなわち、操作後の文書には、B→Cという派生関係情報が含まれることとなる。文書管理サーバ10と通信できるクライアントZがその文書を操作した場合、クライアントZは、操作前の文書が含んでいた派生関係情報B→Cに操作後の文書のために生成した管理ID Dを追加した派生関係情報B→C→Dを文書管理サーバ10に送信し、操作後の文書の先祖ID情報350をクリアする。すなわち、操作後の文書は管理ID Dを持つが、先祖ID情報350は空である。この例でも、クライアントZから送られた派生関係情報B→C→Dにより、途中で欠落した派生関係B→Cが回復される。
なお、図13の手順はあくまで一例に過ぎない。別の例として、例えばステップS10で通信できると判定した場合、クライアント端末20は、操作後のID付き文書の先祖ID情報350がその文書の親ID(すなわち操作前の文書の管理ID)だけを含むように書き換え、その操作後のID付き文書を、操作前のID付き文書が含んでいた先祖ID情報350と共に文書管理サーバ10に送信してもよい。
以上に説明した実施例及び変形例では、操作後の文書の先祖の管理IDを含む派生関係情報をクライアント端末20から文書管理サーバ10に送信したが、先祖の管理IDに対応するログ情報316については送信しなかった。ところで、派生関係を用いたサービスの中には、派生関係の他に文書の属性情報を用いるものもある。例えば、「指定した管理IDを持つ文書から派生した文書のうち、最後に編集を行ったユーザを報せる」というサービスの場合、管理IDに対応するログ情報中の操作種別が編集であるものを抽出する必要がある。このようなサービスを可能とするためには、ID付き文書には、派生関係情報のみならず、その派生関係情報中の各管理IDに対応するログ情報316を組み込んでおけばよい。ただし、ログ情報320の追加はデータ量の増大を招くため、ID付き文書のメタ情報310にデータ量の制限がある場合などには、追加するログ情報320のデータ量をその制限の範囲内に納めなければならない。例えば、ログ情報320のうちID付き文書に組み込む属性項目を限定するなどすればよい。なお、ID付き文書を紙文書として出力する場合、印刷可能なコード情報のデータ量の制限は一般に厳しいので、ログ情報320を紙文書に埋め込むことができない場合もあり得る。
更に別の例として次のような方式も考えられる。この方式では、図15に例示するように、クライアント端末20にて文書に対する操作が行われた場合に、クライアント端末20は、文書管理サーバ10と通信可能かどうかを判定する(S20)。ここで通信可能と判定した場合は、クライアント端末20は操作後の文書のための新たな管理IDを生成し(S21)、操作した文書の管理IDをその新たな管理IDに書き換える(S22)。これにより操作後の文書が生成される。そして、その新たな管理IDと親ID(すなわち操作前の文書の管理ID)とのペア(親子関係)を文書管理サーバ10に送信する(S23)。なお、その親IDを文書に組み込んでももちろんよい。ステップS20で文書管理サーバ10と通信できないと判定した場合、クライアント端末20は、操作した文書の管理IDを変更せずにそのまま維持して、処理を終了する(S24)。すなわちこの場合、操作後の文書の管理IDは操作前の文書の管理IDと同じままとなる。なお、操作後の文書の文書内容320は、その操作が文書内容320を変更するものである場合、操作前から変更されている。
このように、文書管理サーバ10と通信できないクライアント端末20では管理IDが変更されないので、文書管理サーバ10に伝達される管理ID間の派生関係はとぎれない。
ただし、この方式では、文書管理サーバ10と通信できないクライアント端末20で文書が何度操作されても管理IDが変わらないので、それら操作が記録されない。すなわち、文書管理サーバ10と通信できないクライアント端末20での操作が1つの管理IDに、いわば縮退してしまう。この縮退により、文書間の派生関係に曖昧さが生じることが考えられる。
例えば、図8のケースを例に取ると、クライアントYでの操作では文書の管理IDがBのまま維持される。したがって、クライアントYでの操作の前の文書と、操作の後の文書が同じ管理ID Bを持つこととなる。したがって、例えばクライアントXが操作後の文書BをクライアントYの他に別のクライアントWにも提供していた場合、そのクライアントWでその文書Bを操作したときの操作後の文書(例えば管理IDをEとする)と、クライアントYでの操作後の文書(管理IDはBである)を他のクライアントVが操作したときの操作後の文書は、文書管理サーバ10では共に文書Bの子と認識される。この場合、同じ管理ID Bへと縮退した複数のバージョンの区別が必要なサービスでは、正しいサービス結果が得られない。例えば、本来ならばクライアントYでの操作後の文書(管理IDはB)の子孫の中のみから条件を満たす文書を検索したい場合でも、操作前の文書(これも管理IDはB)の子孫であって操作後の文書の子孫ではない文書も検索されてしまう。
このような曖昧さによる誤りを避けるには、一例として次のような方式を採用してもよい。この方式では、図15の手順の一部を変更すればよい。すなわち、文書管理サーバ10と通信できない場合には、操作が行われてもステップS24にて管理IDを更新せずに維持すると共に、その管理IDが「縮退」したものであることを示すフラグを1にする。なお、「縮退」フラグは、初期値は0であり、ステップS24で1にセットされる。また、文書管理サーバ10と通信可能な場合に、ステップS23で親IDと管理IDのペアを文書管理サーバ10に送る際に、操作前の文書の「縮退」フラグの情報も送信する。文書管理サーバ10に親IDと管理IDのペアを送信した場合、「縮退」フラグは0にリセットされる。文書管理サーバ10は、親IDと管理IDのペアと共に受信した「縮退」フラグの値が1であれば、派生関係DB110において、その親IDの「縮退」フラグを1にセットする。そして、ユーザから派生関係を用いたサービス処理を要求された場合、その要求の引数として指定された管理IDすなわち開始ノードと、派生関係の木を辿って得た処理結果のノード、すなわち結果ノードとの間の経路内に「縮退」フラグが1になっているノード(管理ID)があれば、その結果ノードの情報は「正しくない可能性がある」という注記情報付きで要求元に提供する。これにより、要求元のユーザが、誤っている可能性がある結果を正しい結果であると誤解することが防止される。
また、次のような方式を採用してもよい。あるIDに「縮退」するということは、本来あるべきIDは「縮退」したIDの子孫のIDであるから、文書管理サーバ10は、親IDと管理IDのペアと共に受信した「縮退」フラグの値が1であれば、派生関係DB110において、親IDの子として、特定のIDを持たない、特別な「縮退」ノードを追加し、その「縮退」フラグを1にし、さらにその子として管理IDのノードを追加する。この場合、親IDよりも一つ子孫側にあるノードの「縮退」フラグがセットされているので、ユーザから派生関係を用いたサービス処理を要求された場合、その要求の引数として指定された管理IDすなわち開始ノードと、派生関係の木を辿って得た処理結果のノード、すなわち結果ノードとの間の経路内に「縮退」フラグが1になっているノード(管理ID)が出現する可能性はより低くなり、正しい結果を返す可能性が高くなる。
以上に例示したシステムにおける文書管理サーバ10は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図15に示すように、CPU(中央演算装置)40、メモリ(一次記憶)42、各種I/O(入出力)インタフェース44等がバス46を介して接続された回路構成を有する。また、そのバス46に対し、例えばI/Oインタフェース44経由で、ハードディスクドライブ48やCDやDVD、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ50が接続される。このようなドライブ48又は50は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがCDやDVD等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ48等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されCPUにより実行されることにより、実施形態の処理が実現される。クライアント端末20についても同様である。
10 文書管理サーバ、20 クライアント端末、30 ネットワーク、100 文書DB、110 派生関係DB、130 文書登録部、132 派生関係登録部、140 要求処理部、150 派生関係検索部、200 文書操作部、202 ID割り当て部、204 派生関係組込部、210 登録処理部、300 ID付き文書。