図1は、文書利用管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク30を介して接続された文書管理サーバ10とクライアント端末20−1,20−2,・・・(以下、クライアント端末20と総称する)から構成される。
クライアント端末20について図2を用いて説明する。クライアント端末は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複合機などがその一例である。クライアント端末20は、図2に示すように、文書操作部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は、編集完了の日時と、その編集を指示したユーザの識別情報と、操作の種別として「編集」と、を含んだものとなる。
ここでログ情報316に組み込まれる操作の種別は、ログ記録の目的での分類に従った種別であり、文書操作部200が実行する操作の種別そのものでなくてもよい。例えば、文書操作部200が実行する複数の操作の種別を、同じ1つのログ記録目的の操作種別に対応づけてもよい。例えば、文書編集アプリケーション上でID付きの電子文書に編集を加え操作メニュー上で「更新版として登録」を指示した場合も、スキャナで管理ID付きの紙文書を読み取り読取制御用アプリケーションの操作メニュー上で「読み取った文書を承認版として登録」を指示した場合も、ログ情報316に組み込まれる操作種別の値は「更新」となる。
また、ログ情報316の中には、当該ID付き文書300が公開(共有)対象であるか否かを示す「公開」属性を組み込むこともできる。例えば公開対象とするID付き文書の「公開」属性値を「1」とし、公開対象としないID付き文書の「公開」属性値は「0」とすると、「公開」属性が「0」であるID付き文書は、当該文書を生成するための操作を行った操作者や管理者等の特権的なユーザ以外には、公開されないようにすることができる。
なお、「公開」属性の値は、操作の種別に従って決定する。公開属性値を決める基準となる操作の種別は、文書操作部200が実行した操作の種別でも、ログ記録目的の分類に従った操作の種別でもよい。いずれを用いるかは、文書操作部200に設定されていればよい。
文書操作部200が生成するメタ情報310の具体例を以下に示す。
[例1]
<metadata sid="Doc1" date="2006-10-01T10:00" method="register" filename="aaa.doc" user="user1"/>
ここでsid属性は管理ID、date属性は操作日時、method属性は操作種別である。また、filename属性は当該ID付き文書のファイル名であり、user属性は操作を指示したユーザのユーザ識別情報である。例1のmethod属性値"register"は(文書管理サーバ100に未登録の)新規文書の登録操作を示す操作種別名である。新規文書の登録なので、親IDを示すpid属性は省略されている。省略する代わりにpid="null"などと、親IDがないことを示す属性を明示的に組み込んでもよい。また、この例では、新規文書登録により登録された文書は公開対象としないので、公開対象か否かを示すshared属性は省略されている。省略する代わりにshared="0"などと、公開対象でないことを示す属性を明示的に組み込んでもよい。
また、以下に示す例2は、ユーザ識別情報が"user4"であるユーザが、管理ID"Doc2"が埋め込まれた紙文書をスキャナで読み込んで「承認版として登録」する操作を行った場合に生成されるメタ情報310である。
[例2]
<metadata sid="Doc4" pid="Doc2" date="2006-10-01T11:28" method="update" filename="200610011128.jpg" user="user4" shared="1"/>
ここで、method属性値"update"は更新操作を示している。この例では、スキャン画像のファイル名は操作日時を元に自動生成された値である。この例は、更新操作により登録された文書は公開対象とする場合の例であり、shared属性値は公開対象であることを示す値「1」となっている。
なお、文書操作部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は、操作種別ごとに当該種別の操作の結果である文書を公開対象とするか否かを示す情報を保持しており、この情報に基づきshared属性値を決定する。そして、派生関係組込部204は、そのメタ情報310を操作結果の文書内容に付加することにより、操作後のID付き文書300を生成して出力する。
文書操作部200がアプリケーションソフトウエアである場合、ID割り当て部202及び派生関係組込部204は、そのソフトウエアに対して追加される、いわゆるプラグイン(plug-in)プログラムとして実現してもよい。
登録処理部210は、文書操作部200が出力したID付き文書300を文書管理サーバ10に登録するための処理を実行する。このように各クライアント端末20が、自ら実行した操作の結果であるID付き文書300を文書管理サーバ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は、文書DB100,派生関係DB110,文書登録部130,要求処理部140を備える。
文書DB100は、クライアント端末20から送られてきたID付き文書300のうちの文書内容320を格納するデータベースである。文書DB100に格納された各文書内容320は、一意な内容IDにより管理してもよい。内容IDとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末20が内容IDを付与してもよく、この場合、内容IDをメタ情報320に組み込んでもよい。また、内容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のペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。また、操作種別、操作者、操作日時、及び公開属性については既に説明した。ノードアドレスは、ID付き文書間の派生関係が構成する木において、当該管理ID(ID付き文書)に対応するノードの位置を示している。ノードアドレスの表記において「/」が木の深さ階層の区切りを示し、番号が同じ親から派生した兄弟同士の間での順番を示す。例えばノード「/1」は新規文書登録の操作により登録された文書に対応する根ノードを示す。また、ノード「/1/1」は根ノード「/1」の1番目の子、ノード「/1/2」は根ノード「/1」の2番目の子を示す。なお、煩雑さを避けるため、図5には、1つの根ノード「/1」から派生した1つの木に属するメタ情報レコード群しか示していないが、文書管理サーバ10には、例えば根「/1」から派生する木と根「/2」から派生する木のように、複数の木のメタ情報レコード群が登録され得る。文書格納パスは、文書内容320の文書DB100内での格納場所を示すパス名である。図5の例では、文書内容は、Eドライブの「\doc」というフォルダに、date属性(操作日時)の後にfilename属性(ファイル名)を続けたファイル名で登録されている。なお、文書DB100が、内容IDで文書内容320を検索する機能を持つものであれば、文書格納パスの代わりに内容IDをメタ情報レコードに登録しておけばよい。
なお、図5は派生関係DB110が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係DB110は、一般的なリレーショナルデータベースとして構築することもできるし、管理IDを除くメタ情報を記述したXML(eXtensible Markup Language)文書を、管理IDをキーとして登録したデータベースとして構築することもできる。
図5に示した派生関係DB110のデータ内容は、図6のような木構造を成す。これは、管理IDをノードとし、管理ID間の親子関係をエッジとする木構造である。
図5〜図6の例が示す文書の履歴を時系列順に説明すると、以下のようになる。この例は、あるユーザが申請書等のフォーム(ひな形文書)を本システムに登録し、他のユーザがそのフォームに対して記入を行い、記入済みフォームを本システムに登録する業務の流れを表している。
この例ではまず、文書(フォーム)の「登録」操作がuser1のクライアント端末で実行される。「登録」操作は、文書管理サーバ10に未登録の文書(すなわち、管理IDを有していない文書)を当該サーバ10に登録するための操作である。この操作に応じて管理IDが"Doc1"、親IDが空、操作種別が「登録」であるメタ情報と、その文書の文書内容とを含むID付き文書"Doc1"がuser1のクライアント端末から文書管理サーバ10に送られる。ここで、「登録」操作は、「公開」の対象にはなっていないので、メタ情報中には「公開」属性の値は含まれない。これに応じ、文書管理サーバ10は、そのID付き文書"Doc1"中の文書内容を文書DB100へ、メタ情報を派生関係DB110にそれぞれ登録する。ここで、文書管理サーバ10は、操作種別が「登録」であり、親IDが空なので、当該ID付き文書が、文書管理サーバ10内に既に登録済みのID付き文書の子ではなく、新たな木の根(始祖)であると判断し、それに従ってノードアドレスの値(この例では「/1」)を設定する。なお、以下では、識別のために、登録された文書内容を"Content1"で表すことにする。その後、user1は、登録したID付き文書を他のユーザuser2,user3,・・・に配布する。この配布は、例えば、電子メールにそのID付き文書を添付して各ユーザに送信することにより、行うことができる。
その後、他のユーザuser2が自分のクライアント端末の文書操作部200でID付き文書"Doc1"を印刷する。印刷されるのは文書内容"Content1"、又はそれに編集を加えた結果の文書内容である。このとき文書操作部200は、印刷結果の紙文書に対して新たに付与した管理ID"Doc2"を埋め込む。このように管理IDが埋め込まれた紙文書をID付きの紙文書と呼ぶことにする。また、クライアント端末は、印刷の結果としてID付き文書"Doc2"を生成し、文書管理サーバ10に登録する。このID付き文書のメタ情報における管理IDは"Doc2"であり親IDは"Doc1"である。また操作者はuser2であり。操作種別は印刷である。また、「印刷」操作は、「公開」の対象にはなっていないので、そのID付き文書のメタ情報中には「公開」属性の値は含まれない。文書管理サーバ10は、受け取ったID付き文書の親IDの値から、当該文書"Doc2"が文書"Doc1"の子であることを認識し、しかも最初の子であるので、文書"Doc2"のノードアドレスを「/1/1」とする。
なお、この操作の前にuser2のクライアント端末20内にあったID付き文書"Doc1"は、この操作に伴い、派生関係組込部204によりID付き文書"Doc2"に置き換えられる。この置き換え処理では、派生関係組込部204は、元のID付き文書"Doc1"のうち、メタ情報310の管理ID312を新たに発行したID"Doc2"へ変更すると共に、元の文書"Doc1"の管理ID"Doc1"を親ID314の値にセットする。また、派生関係組込部204は、ログ情報316中の操作種別の値を今回の操作の種別である「印刷」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser2に変更する。また、文書内容320は、印刷指示をされた時点の文書内容を示す印刷データ又は文書ファイルとなる。
このようにID付き文書"Doc1"は、閲覧されると、閲覧後のID付き文書"Doc2"に置き換えられる。したがって、その置き換えの後は、ID付き文書"Doc1"自体はそのクライアント端末20には存在せず、その代わりにID付き文書"Doc2"が存在することとなる。なお、user2は、印刷結果の紙文書"Doc2"を、他のユーザであるuser4に渡す。
その後、更に別のユーザuser3が自分のクライアント端末の文書操作部200でID付き文書"Doc1"を閲覧する。閲覧されるのは内容ID"Content1"の文書内容である。クライアント端末は、閲覧の結果としてID付き文書"Doc3"を生成し、文書管理サーバ10に登録する。ここで、「閲覧」操作は、「公開」の対象にはなっていないので、そのID付き文書のメタ情報中には「公開」属性の値は含まれない。「閲覧」操作では、文書内容は変更されないので、文書内容は"Content1"のままである。なお、このように文書内容が変更されない操作を行った場合、クライアント端末20は、文書内容を省略したID付き文書を文書管理サーバ10に送ってもよい。なお、この操作の前にuser3のクライアント端末20内にあったID付き文書"Doc1"は、この操作に伴い、派生関係組込部204によりID付き文書"Doc3"に置き換えられる。この置き換え処理では、派生関係組込部204は、元のID付き文書"Doc1"のうち、メタ情報310の管理ID312を新たに発行したID"Doc2"へ変更すると共に、元の文書"Doc1"の管理ID"Doc1"を親ID314の値にセットする。また、派生関係組込部204は、ログ情報316中の操作種別の値を今回の操作の種類である「閲覧」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser3に変更する。なお、今回の操作は閲覧なので、文書内容320は変化しない。
次に、user4が、user2から受け取ったID付きの紙文書"Doc2"に対して書き込みを行い、書き込み済みの紙文書をスキャナにセットし、クライアント端末20上の読取制御ソフトウエアの操作メニューから「承認版として登録」の操作を選んだとする。すると読取制御ソフトウエアは、スキャナを制御して紙文書を読み取り、その読取結果の画像データを文書内容(以下、識別のためにこの文書内容を"Content2"と名付ける)として含むID付き文書"Doc4"を生成し、文書管理サーバ10に送ると共に、当該クライアント端末20内に保存する。このID付き文書"Doc4"内のメタ情報310に含まれる管理IDは"Doc4"であり、親IDは"Doc2"である。この親ID"Doc2"は、紙文書から読み取った管理IDである。またuser属性はuser4である。また、文書操作部200での「承認版として登録」という操作は、ログ記録目的上での「更新」という操作種別に分類されるので、メタ情報中のmethod属性は「更新」となる。また、この例では、「更新」という操作種別が「公開」の対象に設定されているので、メタ情報中のshared属性の値は「1」(この値は「公開対象である」ことを意味する)となる。
次に、user4がID付き文書"Doc4"を文書操作部200により編集する。これにより、編集結果の文書内容"Content3"を含み、"Doc4"を親IDとして含む新たなID付き文書"Doc5"が生成され、文書管理サーバ10に登録される。user4のクライアント端末20内のID付き文書"Doc4"はこのID付き文書"Doc5"に置き換えられる。
次に、user3が自分のクライアント端末内のID付き文書"Doc3"に対し文書操作部200にて編集を加え、操作メニュー上で「更新版として登録」を指示すると、クライアント端末は、管理ID312の値が"Doc6"、親ID314の値が"Doc3"、操作種別の値が「更新」であるID付き文書"Doc6"を生成して、これをID付き文書"Doc3"と置き換えると共に、そのID付き文書"Doc6"を文書管理サーバ10に登録する。編集により、文書内容は"Content3"から"Content4"へと変化している。「更新」操作は公開対象なので、そのID付き文書"Doc6"のshared属性は「1」である。文書管理サーバ10の派生関係DB110には、管理ID"Doc6"のレコードが登録される。
図5及び図6は、この時点での派生関係DB110内の、"Doc1"から派生する文書或いは操作の様子を示している。
以上、派生関係DB110のデータ内容を例に取り、本システムにおける文書操作の情報の登録の様子を説明した。
図4の説明に戻り、要求処理部140は、クライアント端末20からの管理IDを含んだサービス要求に応じて、派生関係DB110を用いたサービスを提供する。要求処理部140が提供するサービスとしては、例えば、サービス要求中の管理IDに対応する文書の最新版を検索するサービスがある。また別の例として、サービス要求中の管理IDに対応する始祖(根)の文書又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、その管理IDの来歴、すなわち始祖からその管理IDまでに文書が経てきた操作の履歴(例えば誰がいつどんな操作をしたのかを示す情報のリスト)を提供するサービスもある。また、派生関係DB110に登録された属性項目についての検索条件の指定を受け付け、その検索条件を満足するID付き文書のリストを提供するサービスもある。なお、上述の最新版を検索するサービスは、「操作日時が最新である」という検索条件についての検索結果を提供するサービスと捉えることもできる。また、上述の始祖の文書の情報を提供するサービスは、「ノードアドレスが根を示す文書」という条件についての検索結果を提供するサービスと捉えることができる。
サービス要求は、クライアント端末20に保持されたID付き文書に基づき発せられる。例えば、ユーザがクライアント端末20の文書操作部200によりID付き文書を開いた場合に、文書操作部200が、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付ける。そして、そのID付き文書の管理IDと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ10の要求処理部140に送信する。このとき、ユーザ識別情報や操作日時などの属性項目についての検索条件を指定するユーザインタフェース画面を提供し、この画面を介して入力された検索条件を併せて要求処理部140に送信してもよい。また、管理IDと、サービスを示すコード、検索条件以外に、指示を行ったユーザの識別情報や、ユーザの入力した認証情報などといった他の情報を、クライアント端末20から要求処理部140に送信するようにしてもよい。
また、別の例として、ID付き文書というオブジェクト種類に対して、そのようなサービスのメニューを対応づけてクライアント端末20のオペレーティングシステムに登録しておいてもよい。この場合、図7に示すように、オペレーティングシステムが提供するファイル管理画面400に表示されたID付き文書のアイコン410又は414に対し、ユーザが右ボタンクリックなどの所定の操作を行った場合、オペレーティングシステムが、ID付き文書に対応づけられたメニュー420を画面表示する。図示例では、ID付き文書のアイコン410又は414には、本システムのID付き文書であることを示すマーク411により、他の種類のファイル412と区別可能となっている。ユーザがメニュー420上の各サービス項目の中から、所望のものを選択すると、クライアント端末20は、選択されたサービス項目の実行を文書管理サーバ10に要求する。
また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理IDを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のID付き文書の管理IDを親IDとして含んだID付き文書を生成し、このID付き文書をサービス要求として文書管理サーバ10に送ってもよい。この場合、要求処理部140は、受け取ったID付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくID付き文書内の親IDを、派生関係を遡る処理の起点とする。
要求処理部140は、クライアント端末20からサービス要求を受けた場合、そのサービス要求中に指定された管理IDを起点に、派生関係DB110に登録された管理IDと親IDとの派生関係が構成する木を走査(トラバース)し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。
以下、サービス要求を受け取った場合の要求処理部140の処理手順を、図8及び図9を参照して説明する。以下では、派生関係DB110内のデータ内容が図5及び図6に例示したものである時に、user2が、自分のクライアント端末20内にあるID付き文書"Doc2"を対象として、当該ユーザが指定した検索条件を満たす文書の要求を行った場合を具体例として用いて説明する。
この手順では、要求処理部140は、クライアント端末20から受け取ったサービス要求から、処理対象として含まれる管理IDを取り出し、その管理IDを注目IDにセットする(S1)。次に、派生関係DB110から、注目IDに対応するレコードを取得する(S2)。注目IDに対応するレコードとは、注目IDをレコード中の「管理ID」の項目の値として持つレコードのことである。そして、取得したレコード中の操作種別の項目の値が「登録」であるか否かを調べ(S3)、「登録」でなければ、注目IDの値をそのレコード中の親IDの値へと置き換え(S4)、ステップS2及びS3を実行する。このステップS2〜S4のループは、サービス要求中の管理IDから派生関係の木構造を遡り、大本(根)であるフォーム原本の「登録」操作を見つけるための処理を表す。ステップS3の判定結果がYesとなった場合、そのときの注目IDは、根である「登録」操作に対応する。図5の例では、管理ID"Doc2"から木構造を遡ることで、最終的に、根である管理ID"Doc1"に到達する。
根である「登録」操作に到達すると、要求処理部140は、そのときの注目ID(根)の子IDを検索する(S5)。派生関係DB110のうちその注目IDを「親ID」の値として持つレコードの「管理ID」が、注目IDの子IDである。注目IDの子IDがすべて求められると、要求処理部140は、それら子IDごとに、図9に示すような子孫探索処理を実行する(S6)。
子孫探索処理(S6)では、要求処理部140は、当該子IDを注目IDとし(S11)、その注目IDに対応するレコードを派生関係DB110から取得する(S12)。そして、そのレコード中の「公開」属性の値が「1」であるか否かを判定し(S13)、「1」であれば、そのレコードを中間結果リストに入れる(S14)。中間結果リストは、要求された処理の処理結果を求めるための材料となる情報を蓄積するためにクライアント端末20の記憶装置上に構築されるリストである。「公開」属性が「1」でなければ、ステップS14はスキップされる。そして、要求処理部140は、注目IDの子IDを検索し(S15)、子IDが検索できたか否かを判定する(S16)。子IDがあれば、要求処理部140は、それら各子IDについて、それぞれ子孫探索処理(S6)を再帰的に実行する。すべての子IDについての子孫探索処理が終了すると、当該注目IDについての処理が終了する。ステップS16で子IDがないと判定された場合も、当該注目IDについての処理は終了する。
図8の手順に戻り、根のID付き文書のすべての子IDについて子孫探索処理(S6)が終了すると、そのときの中間結果リストには、その根から派生するすべてのID付き文書の中で、「公開」属性が「1」であるものに対応するレコードがすべて蓄積されていることになる。要求処理部140は、中間結果リストに蓄積されたレコード群の中から、検索条件を満足するレコードを求める(S7)。そして、求めたレコードに対応するID付き文書を、要求に対する検索結果として、要求元のユーザ(この例ではuser2)に提供する(S8)。
例えば、図6の例では、ステップS6の処理により、中間結果リスト中には管理IDが"Doc4"、"Doc6"の2つのレコードが蓄積される。そして、例えば、検索条件が「操作日時が最新の文書」という条件であれば、中間結果リストの中で操作日時が最新である文書"Doc6"が検索結果として要求元のuser2に提供される。
ステップS7で、検索結果として複数のID付き文書が得られた場合、それら複数の文書すべてを要求元のユーザに返せばよい。またこの代わりに、検索結果のID付き文書のリストをユーザに返し、ユーザがその中から所望のものを選択して取得するようにしてもよい。
以上に説明したように、本実施形態では、特定の操作種別に該当する操作の結果の文書しか公開されない。また、どの操作種別の操作結果を公開対象とするかは、各クライアント端末20の各文書操作部200ごとに個別に設定できるので、各クライアント端末又は各文書操作部200の事情に応じて操作結果の公開・非公開を制御できる。
次の、変形例を説明する。上記実施形態では、要求処理部140は、サービス要求中の管理IDが所属する木全体に対して検索を行った。これに対し、この変形例では、文書操作部200が行った操作の種別に応じて検索の境界を設定し、それら境界で区切られた範囲内で検索を行う。
説明のための事例として、図10及び図11に示すような派生関係を考える。この派生関係は、図5及び図6に示した状態の後、更に以下のような操作が加えられたときの状態を示している。
すなわち、図5及び図6に示された状態の後、user3がID付き文書"Doc6"を印刷して印刷結果の紙文書をuser5に配布する。この印刷により、ID付き文書"Doc7"が生成され、文書管理サーバ10に登録される。次にuser5がuser3から受け取った紙文書の内容を確認してスキャナにセットし、「承認版として登録」の操作を行う。これによりスキャン結果の画像を含むID付き文書"Doc8"が生成され、文書管理サーバ10に登録される。そしてuser5がそのID付き文書"Doc8"を開いて編集を加え、「更新版として登録」操作を行うと、ID付き文書"Doc9"が生成され、文書管理サーバ10に登録される。図10及び図11に示す派生関係は、この時点の状態である。この例では、図5及び図6の例と同様、スキャンした画像を「承認版として登録」する操作、及び電子文書の編集結果を「更新版」として登録する操作は、共に「公開」属性の値が「1」となる操作であるとする。
また、この例では、派生関係の木構造の中に検索境界を設定可能としている。要求処理部140は、受け取ったサービス要求中の管理IDを起点に木を走査する際、検索境界より先祖にも子孫にも走査は進めない。このように、この変形例では、検索範囲をサービス要求中の管理IDを含んだ木全体とするのではなく、その木を検索境界によって区切ってできる各部分木のうち、その管理IDを含んだ部分木のみを検索範囲とする。この変形例では、文書に対して特定の種別の操作が行われた場合に、操作前の文書と操作結果の文書との間を検索境界に設定する。
検索境界を表すため、図示例では、ID付き文書のメタ情報に「境界」属性を組み込んでいる。ある文書の「境界」属性の値が「1」であれば、その文書とその親との間が検索境界であることを示す。ある文書の「境界」属性の値が「0」であれば、その文書とその親とは同じ検索範囲に属する。どのような種別の操作の結果を検索境界とするかは、文書操作部200にあらかじめ登録されている。図10及び図11の例では、「登録」操作と(電子的なID付き文書に対する)「更新版として登録」操作が、検索境界を生み出す操作種別として設定されており、文書"Doc1"、"Doc6"及び"Doc9"の「境界」属性が「1」となっている。そのように登録された種別の操作を行った場合、文書操作部200は、その操作結果のID付き文書の「境界」属性を「1」にセットする。そうでなければ、「境界」属性の値を「0」とするか、又は「境界」属性自体を省略する。
例えば、ID付き文書"Doc9"のメタ情報レコードは、以下の例3に示すようなものとなる。
[例3]
<metadata sid="Doc9" pid="Doc8" date="2006-10-03T14:34" method="update" filename="aaa_v2.doc" user="user5" shared="1" unrelated="1"/>
この例において、unrelated属性が「境界」属性である。なお、紙文書を読み取って「承認版として登録」する操作と、電子的なID付き文書を「更新版として登録」する操作は、上記実施形態の例では、ログ記録上の操作種別では同じ「更新」に分類されているが、この変形例では、そのような分類の操作でも、「境界」属性の判別においては区別している。すなわち、この例では、紙文書を読み取って「承認版として登録」する操作に対応する「境界」属性の値は「0」である。例えば、ID付き文書"Doc8"の「境界」属性値は「0」となっている。この変形例では、「境界」属性の判定は、文書操作部200での操作の種別に基づき行っているといえる。なお、これはあくまで一例であり、ログ記録上の操作種別に従って判定してもよい。
これら図10及び図11に示した状態の時に、user3が、例えば図7に例示したようなユーザインタフェース画面を介して、ID付き文書"Doc7"を対象として「最新フォーム取得」の要求を行ったとする。このような場合を例にとって、「最新フォーム取得」の要求を受けたときの、要求処理部140の処理手順の例を説明する。
この場合、要求処理部140は、例えば図12及び図13に示す手順に従って、最新フォームを求める。図12の手順では、要求処理部140は、まず、クライアント端末20から受け取った要求に処理対象として含まれる管理IDを注目IDにセットし(S1)、派生関係DB110からその注目IDに対応するレコードを取得する(S2)。次にそのレコード中の「境界」属性の値が「1」であるか否かを調べ(S3A)、「1」でなければ、注目IDの値をそのレコード中の親IDの値へと置き換え(S4)、ステップS1〜S3Aの処理を繰り返す。
ステップS3Aの判定結果がYesとなった場合、要求中の管理IDから派生関係を遡り、直近の検索境界のノードにたどり着いたことになる。このノードが、今回の検索の範囲である部分木の根である。要求処理部140は、そのときの注目ID(すなわち部分木の根)の公開属性を調べ(S9)、公開属性の値が「1」であればその注目IDに対応するレコードを中間結果リストに入れ(S10)、ステップS5に進む。ステップS9で注目IDに対応する公開属性が「1」でなければ、ステップS10を飛ばしてステップS5に進む。ステップS5では、注目IDの子IDを検索する。そして、要求処理部140は、それら子IDごとに、図13に示すような子孫探索処理を実行する(S6)。
子孫探索処理(S6)では、要求処理部140は、当該子IDを注目IDとし(S11)、その注目IDに対応するレコードを派生関係DB110から取得する(S12)。そして、そのレコード中の「境界」属性の値が「1」であるか否かを判定する(S20)。その「境界」属性の値が「1」であれば、部分木の走査において子孫方向の検索境界に達したことになるので、当該注目IDについての図13の処理を終了する。「境界」属性の値が「1」でなければ、更に「公開」属性の値が「1」であるか否かを判定する(S13)。ステップS13の判定結果がYesの場合、要求処理部140は、そのレコードを中間結果リストに入れる(S14)。ステップS13の判定結果がNoであれば、ステップS14はスキップされる。そして、要求処理部140は、注目IDの子IDを検索し(S15)、子IDが検索できたか否かを判定する(S16)。子IDがあれば、要求処理部140は、それら各子IDについて、それぞれ子孫探索処理(S6)を再帰的に実行する。すべての子IDについての子孫探索処理が終了した場合、又はステップS16で子IDがないと判定された場合、当該注目IDについての処理が終了する。
図12の手順に戻ると、ステップS3Aで特定された部分木の根のすべての子IDについて子孫探索処理(S6)が終了すると、そのときの中間結果リストには、その部分木に属し、「公開」属性が「1」であるID付き文書がすべて蓄積されていることになる。要求処理部140は、中間結果リストに蓄積されたレコード群の中から、検索条件である「最新の」レコードを求め(S7)、このレコードに対応するID付き文書を検索結果として要求元のユーザに返す(S8)。
例えば、図10の例において、ID付き文書"Doc7"を対象として「最新フォーム取得」の要求がなされた場合、ステップS1〜S4のループにより、検索範囲の部分木の根となる"Doc6"が特定される。更にステップS9以下の処理により、中間結果リスト中には管理IDが"Doc6"、"Doc8"の2つのレコードが蓄積される。ID付き文書"Doc9"は、「公開」属性値は「1」であるが、「境界」属性値も「1」なので、ステップS20により、中間結果リストには蓄積されない。中間結果リストに蓄積されたレコードのうち最新のレコードに対応するID付き文書"Doc8"がステップS8で検索結果として求められる。
以上に説明した変形例によれば、文書に対する操作に応じて、操作前の文書と操作結果の文書との間に検索境界を設定することができる。検索境界を設定するということは、操作前の文書と操作結果の文書とを、別系統の文書として取り扱うことと捉えることもできる。また、上記変形例では、また、どの操作種別の操作に応じて検索境界を設定するか否かを、各クライアント端末20の各文書操作部200ごとに個別に設定できるので、各クライアント端末又は各文書操作部200の事情に応じて検索境界を制御できる。
以上に例示した実施形態及び変形例では、管理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は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図14に示すように、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 要求処理部、200 文書操作部、202 ID割り当て部、204 派生関係組込部、210 登録処理部、300 ID付き文書。