JP2011039586A - 文書管理装置及びプログラム - Google Patents

Abstract

【課題】文書に対して行われた操作の属性値に応じて派生関係を記録できるようにする。
【解決手段】派生関係登録部１３２は、クライアントから受信した文書を基本派生関係ＤＢ１１０及び部門別派生関係ＤＢ１２０に登録する。基本派生関係ＤＢ１１０へは、その文書を、その文書が生成される元となった親文書の子として登録する。部門別派生関係ＤＢ１２０への登録処理では、その文書の部門属性と、その文書の親文書の部門属性とを比較する。そして、両者が一致していればその文書をその親文書の子として部門別派生関係ＤＢ１２０に登録し、不一致であればその文書を新たなルート（根）として部門別派生関係ＤＢ１２０に登録する。
【選択図】図４

Description

本発明は、文書管理装置及びプログラムに関する。

特許文献１に開示された装置では、第１の電子文書の更新版である第２の電子文書が文書データベースに登録された場合、派生関係登録部は、第１の電子文書から第２の電子文書が派生したことを表す派生関係情報を派生関係データベースに登録する。また、提供関係登録部は、その第２の電子文書の先祖に該当する電子文書を派生関係データベースから求め、当該先祖の電子文書が要求されると第２の電子文書を提供する旨を示す提供関係情報を提供関係データベースに登録する。文書提供部は、ユーザから電子文書を要求された場合、提供関係データベースを参照することで、その要求に対して提供すべき電子文書を特定する。

特許文献２に開示された装置は、プログラムの走行状態の解析を補助するために、事象を複数のレベルに分け、レベルごとに独立したスタック上にトレース情報を記録し、スタックごとにトレース情報を結合して編集する機能を備える。

特開２００８−１４０２７３号公報 特開平３−２８２８３３号公報

本発明は、文書に対して行われた操作の属性値に応じて派生関係を記録できるようにすることを目的とする。

請求項１に係る発明は、第１の文書に対する操作により第２の文書が生成された場合に、第２の文書が第１の文書から派生したという基本派生関係と、当該操作についての属性値と、を対応づけて記憶する基本派生関係記憶手段と、第１の文書が操作を受けて第２の文書が生成された場合に、当該操作についての属性値が、第１の文書が第０の文書から派生したという基本派生関係に対応づけて前記基本派生関係記憶手段に記憶されている属性値と同じである場合には第１の文書から第２の文書が派生したという属性値別派生関係を記憶し、異なる場合には第１の文書から第２の文書が派生したという属性値別派生関係を記憶しない属性値別派生関係記憶手段と、前記属性値別派生関係記憶手段に記憶された属性値別派生関係を介して一続きに繋がっている文書群を単位として処理を行う処理手段と、を備える文書管理装置である。

請求項２に係る発明は、前記属性値別派生関係記憶手段は、前記第１の文書が前記操作を受けて前記第２の文書が生成された場合に、当該操作についての前記属性値が、前記第１の文書が前記第０の文書から派生したという基本派生関係に対応づけて前記基本派生関係記憶手段に記憶されている属性値と異なる場合に、前記基本派生関係記憶手段に記憶されている基本派生関係を前記第０文書から派生元の方向へと順次遡る過程で最初に見つかる、前記属性値と同じ属性値に対応づけられた基本派生関係の派生先側の文書から、前記第１の文書が派生したという属性値別派生関係を記憶する、ことを特徴とする請求項１記載の文書管理装置である。

請求項３に係る発明は、コンピュータを、第１の文書に対する操作により第２の文書が生成された場合に、第２の文書が第１の文書から派生したという基本派生関係と、当該操作についての属性値と、を対応づけて記憶する基本派生関係記憶手段、第１の文書が操作を受けて第２の文書が生成された場合に、当該操作についての属性値が、第１の文書が第０の文書から派生したという基本派生関係に対応づけて前記基本派生関係記憶手段に記憶されている属性値と同じである場合には第１の文書から第２の文書が派生したという属性値別派生関係を記憶し、異なる場合には第１の文書から第２の文書が派生したという属性値別派生関係を記憶しない属性値別派生関係記憶手段、前記属性値別派生関係記憶手段に記憶された属性値別派生関係を介して一続きに繋がっている文書群を単位として処理を行う処理手段、として機能させるためのプログラムである。

請求項１又は３に係る発明によれば、文書に対して行われた操作の属性値に応じて派生関係を記録できる。

請求項２に係る発明によれば、別の属性値に係る操作を間に挟んだ同一属性値の操作による派生関係同士を繋げて記録することができる。

文書利用管理システムの概略構成の例を示すブロック図である。 クライアント端末の内部構成の例を示すブロック図である。 ＩＤ付き文書のデータ構造の例を模式的に示す図である。 文書管理サーバの内部構成の例を示すブロック図である。 基本派生関係ＤＢのデータ内容の例を示す図である。 図５の基本派生関係がなす木構造を図式化して表す図である。 部門別派生関係ＤＢのデータ内容の例を示す図である。 図７の部門別派生関係がなす木構造を図式化して表す図である。 派生関係登録部が部門別派生関係ＤＢに情報を登録する処理の一例を示すフローチャートである。 派生関係登録部が部門別派生関係ＤＢに情報を登録する処理の別の例を示すフローチャートである。 図１０の手順で形成される部門別派生関係ＤＢのデータ内容の例を示す図である。 図１１の部門別派生関係がなす木構造を図式化して表す図である。

図１は、文書利用管理システムの概略構成の例を示すブロック図である。このシステムは、テキスト文書データや音声データ、マルチメディアデータ等といった様々な形態の電子文書や、紙文書を管理する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基本派生関係ＤＢ１１０は、そのようなＩＤ付き文書３００のうち、文書間の基本派生関係の情報を主としたメタ情報を蓄積するデータベースである。基本派生関係とは、これまでに説明してきた、親文書により操作が行われて子文書が生成されたという派生関係そのもののことである。後述するように、本実施形態では、操作者の所属部門等、操作に関する属性値ごとに派生関係を区別して管理するので、そのような属性値ごとに区別をしない派生関係のことを、区別を明確にするために基本派生関係と呼ぶこととする。

図５に、基本派生関係ＤＢ１１０のデータ内容の一例を示す。図５に示した表における１行の情報が、１つのＩＤ付き文書３００に対応するメタ情報レコードである。この例では、各レコードに対して、対応するＩＤ付き文書３００を受信した順序を示す連続番号（受信番号）が付与されている。ただし、これは必須ではない。図示例では、各レコードには、当該ＩＤ付き文書３００の自文書ＩＤ、親文書ＩＤ、操作種類、操作者の所属部門が含まれているが、この他にも、操作者のＩＤや、操作時刻、文書内容の内容ＩＤなどといった他の属性項目が登録されていてももちろんよい。なお、以上に挙げた項目のうち、自文書ＩＤと親文書ＩＤのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。

図５に例示した基本派生関係のレコード群は、図６に例示するワークフロー、すなわち文書操作の流れを表している。すなわち、この流れは、Ａ部門で物品を購入する業務に関するものであり、まずＡ部門内のある担当者が部内で定められた購買業務の手続きに従って、見積もり依頼書を作成し、文書管理サーバ１０に登録する（受信番号１）。すると、その見積依頼書をルート（根）とする、新たな業務が開始される。次のステップでは、部内の承認権限者がその見積依頼書を閲覧し、承認手続き（例えば押印や電子署名など）を行う。承認済みの見積依頼書が、「承認」などの操作種類を含む、操作に関する各属性項目の値と対応づけて文書管理サーバ１０に登録される（受信番号２）。次に、承認権限者が、承認済みの見積もり依頼書を購買部門へ送付する操作と、依頼書を作成した担当者へと戻す操作を行うと、それら操作の属性情報と操作の対象となった文書とが文書管理サーバ１０に登録される（受信番号３及び４）。購買部門の担当者は、送付された見積もり依頼書に対する受付操作を行うと、受け付けた依頼書とその受付操作の属性情報（ログ）とが文書管理サーバ１０に登録される（受信番号５）。そして、購買部門の担当者は、定められた見積もり取得業務の手続きに従い、物品の種類に応じて購買先を複数選択し、それぞれから見積もり書を取得し、見積もり依頼書に見積もり書を添付する操作を行う。この操作に応じ、見積もり書が添付された見積もり依頼書と、見積書添付という操作種類を含んだ属性情報とを文書管理サーバ１０に登録する（受信番号６）。次に、購買部門の承認権限者が、見積もり書が添付された見積もり依頼書に対して承認操作を行い、その結果が文書管理サーバ１０に登録される（受信番号７）。承認者が、その承認結果の見積もり依頼書（見積もり書添付）をＡ部門に返却すると、その旨が文書管理サーバ１０に登録される（受信番号８）。Ａ部門の担当者が購買部門の承認結果（見積もり依頼書及び見積もり書）に対して受付操作を行うと、その旨が文書管理サーバ１０に登録される（受信番号９）。この後、Ａ部門では、その見積もり承認結果を元に、購買業務を引き続き行う。

この例では、見積もり依頼書という文書が、Ａ部門から購買部門へ、そして購買部門からＡ部門へと流通し、その中でＡ部門では購買業務が、購買部門では見積もり取得業務がそれぞれ遂行されている。

部門別派生関係ＤＢ１２０は、属性値別の派生関係の一種として、部門別の派生関係を記憶するデータベースである。すなわち、このＤＢ１２０には、操作の履歴（ログ）が持つ各属性項目のうち、部門という属性項目の各属性値、すなわち個別部門ごと区分された派生関係が登録される。すなわち、この実施形態では、部門間を跨いだ基本派生関係が切断される。例えば、図５に例示した基本派生関係群は、部門別に区分すると、例えば図７に示すようなものとなる。図５と図７との比較から分かるように、図７に例示した部門別派生関係では、Ａ部門から購買部門に跨る操作に対応する受信番号５の基本派生関係（ID3からID4が派生）が切断され、ID4の文書が新規登録された文書（すなわち、親が無い文書）として扱われている。同様に、図７の例では、購買部門からＡ部門に跨る操作に対応する受信番号９の基本派生関係が切断され、ID8の文書が新規登録された文書として扱われている。

図７に例示した部門別派生関係群は、図８に示すように、受信番号１，５，９の操作（すなわちID0, ID4, ID8の文書）をルートとする３つのツリー（木構造）を表している。このように、基本派生関係では受信番号１（ID0）に対応するルート文書から順次派生する１つのツリーが、図８の例では部門の区切りでの切断により３つのツリーに分けられている。

このような基本派生関係ＤＢ１１０及び部門別派生関係ＤＢ１２０を構築するために、派生関係登録部１３２は基本派生関係の登録処理と、図９に例示する部門別派生関係の登録処理とを実行する。

基本派生関係の登録処理は、文書管理サーバ１０がクライアント端末２０からＩＤ付き文書３００を受信するごとに実行される。すなわち、ＩＤ付き文書３００を受信すると、派生関係登録部１３２は、そのＩＤ付き文書３００のメタ情報３１０内の親文書ＩＤ３１４，自文書ＩＤ３１２，及びログ情報３１６に含まれる部門などの各属性項目の値を基本派生関係ＤＢ１１０に登録する。

また、部門別派生関係の登録処理も、基本派生関係の登録処理と同様、文書管理サーバ１０がクライアント端末２０からＩＤ付き文書３００を受信するごとに行われる。ＩＤ付き文書３００を受信すると、派生関係登録部１３２は、図９に示すように、そのＩＤ付き文書３００に親文書があるか（すなわち親文書ＩＤの値がセットされているか）否かを判定する（Ｓ１０）。

親文書がない場合は、当該ＩＤ付き文書３００の自文書ＩＤ３１２をルート（根）として、すなわち親文書ＩＤの値を「無し」として、部門別派生関係ＤＢ１２０に登録する（Ｓ１６）。

一方、親文書がある場合は、当該ＩＤ付き文書３００のログ情報３１６に含まれる操作者の部門の値と、その親文書に対応する部門の値とが同じであるかどうかを判定する（Ｓ１２）。ここでは、例えば、受信したＩＤ付き文書３００内の親文書ＩＤ３１４の値を自文書ＩＤとして持つレコードを基本派生関係ＤＢ１１０から探し、そのレコード中の部門属性の値を親文書に対応する部門とすればよい。

ステップＳ１２の判定の結果、当該ＩＤ付き文書３００のログ情報３１６に含まれる操作者の部門の値と、その親文書に対応する部門の値とが同じであれば、部門別派生関係ＤＢ１２０に対し、その親文書が親で当該ＩＤ付き文書３００が子であるという派生関係（すなわち当該ＩＤ付き文書３００に含まれる親文書ＩＤと自文書ＩＤとのペア）を登録する（Ｓ１４）。

一方、ステップＳ１２の判定で、当該ＩＤ付き文書３００のログ情報３１６に含まれる操作者の部門の値と、その親文書に対応する部門の値とが異なっていれば、当該ＩＤ付き文書３００の自文書ＩＤ３１２をルート（根）として、すなわち親文書ＩＤの値を「無し」として、部門別派生関係ＤＢ１２０に登録する（Ｓ１６）。このように、この実施形態では、自文書を生成した操作者の部門が親文書を生成した操作者の部門と異なる場合に、自文書を親文書の子とせずに、新規なツリーのルートとする。

図４の説明に戻り、要求処理部１４０は、クライアント端末２０からの自文書ＩＤを含んだサービス要求に応じて、基本派生関係ＤＢ１１０又は部門別派生関係ＤＢ１２０を用いたサービスを提供する。

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

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

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

なお、要求されたサービスを行う際に辿る派生関係として、基本派生関係ＤＢ１１０又は部門別派生関係ＤＢ１２０のいずれの派生関係を用いるかは、例えばサービスの種類に応じて決めておけばよい。

これまで例示した各サービスは、基本派生関係ＤＢ１１０に登録された派生関係を参照するサービスである。

一方、部門別派生関係ＤＢ１２０の派生関係を辿って行うサービスの一例としては、ある文書を部門内および部門外の各ユーザに配布した配布者からの指示に従い、部門内のみの各配布先ユーザに閲覧を促す通知を行うサービスが考えられる。すなわち、ある部門の配布者が文書管理サーバ１０に登録した文書（すなわちＩＤ付き文書）を、当該部門内および部門外の各配布先ユーザに配布し、その後しばらくしてから、部門内の未閲覧の配布先ユーザに閲覧を促す場合、例えば配布者は登録したＩＤ付き文書と閲覧を促す対象となる部門内の配布先ユーザの所属部門を指定して閲覧通知サービスを指示する。文書管理サーバ１０は、配布者から文書の配布指示を受けた場合、配布先ユーザ（例えばそのユーザＩＤ）と配布先ユーザのそれぞれが所属する部門のリストをその文書（或いは「配布」操作の操作結果の文書）の属性情報として記憶しておく。そして、配布者からＩＤ付き文書と閲覧を促す対象となる部門内の配布先ユーザの所属部門が指定されて閲覧通知サービスの指示を受けた場合、文書管理サーバ１０（要求処理部１４０）は、指定された所属部門に対応する部門別派生関係ＤＢ１２０にてそのＩＤ付き文書の子孫の中から「閲覧」操作を行ったユーザを特定し、そのＩＤ付き文書の配布先のリストに含まれているにもかかわらず、閲覧操作を行っていないユーザに対して閲覧を促す通知を、例えば電子メールで送信する。

以上、ＩＤ付き文書を処理対象の特定のためのキー情報として指定したサービス要求の処理について説明したが、文書管理サーバ１０（又は要求処理部１４０）は、この他の形でサービス要求を受け付け、その要求に対応する処理を実行する機能を備える。

そのような処理機能の一種として、文書管理サーバ１０内の保存データの削除管理がある。すなわち、文書管理サーバ１０内には、文書ＤＢ１００，基本派生関係ＤＢ１１０，及び部門別派生関係ＤＢ１２０というデータベースが存在するが、それらデータベースを記憶するための記憶容量にも限界があるので、古くなったデータをそれらデータベースから削除することが必要になる。例えば、文書に係る業務が終了した時点や、あらかじめ定めた保存期間が過ぎた時点で、文書についての派生関係情報やログ情報（場合によっては文書自体）を削除することになる。

ここで、派生関係の情報（又はこれを含んだログ情報）は、先祖や子孫を辿ることができることに大きな意味がある。このため、個々の文書の単位でその情報を削除するよりも、１つの根の文書から派生した木全体の文書群など、派生関係で結ばれたひとかたまりの文書群の派生関係やログ情報をまとめて削除した方が運用しやすい場合がある。例えば、派生関係が構成する木の中の基準となるＩＤ付き文書（例えば、根の文書、又は登録日時が最も新しい文書）の登録日時からみて、あらかじめ定められた保存期間が経過した場合に、その木に属する各文書の派生関係やログ情報をまとめて削除するなどである。このように、木全体の情報をまとめて削除する場合には、基本派生関係ＤＢ１１０を参照すればよい。

また、業務の終了時期や保存期間等の規則は部門ごとに異なる場合があり、基本派生関係ＤＢ１１０及び部門別派生関係ＤＢ１２０に記憶されたレコード群を、部門ごとの規則に従って部門単位で削除することも考えられる。すなわち、基本派生関係ＤＢ１１０及び部門別派生関係ＤＢ１２０に記憶されたレコード群を、基本派生関係ＤＢ１１０に登録された派生関係による木単位で削除する代わりに、部門別派生関係ＤＢ１２０に登録された派生関係による木単位で削除するのである。このために、文書管理サーバ１０に対して、データの保存期間などの規則を部門ごとに登録しておく。文書管理サーバ１０は、例えば、定期的に基本派生関係ＤＢ１１０に登録された各文書の登録日時属性と所属部門属性を調べ、所属部門に対応する保存期間が過ぎた文書を検出する。そして、保存期間が経過した文書を見つけると、その文書から部門派生関係ＤＢ１２０の派生関係を先祖方向及び子孫方向に辿ることで、その文書の（操作者の）所属部門におけるその文書の先祖及び子孫を特定し、その文書と、特定した先祖及び子孫とのレコードを部門別派生関係ＤＢ１２０及び基本派生関係ＤＢ１１０から削除する。この例は、所属部門内での文書の派生関係の木の中に保存期間を経過した文書が１つでもあったら、その木に属するレコード群を削除するというものであったが、このような処理に限るものではない。例えばこの他に、部門別派生関係ＤＢ１２０における派生関係からなる各々の木ごとに、その木の中での最新登録の文書の登録日時からみて保存期間が経過している場合に、その木全体のレコード群を削除するようにしてもよい。

また、文書管理サーバ１０が提供する別のサービス機能として文書を配布してから定められた期間を過ぎてもその文書を閲覧していないユーザを特定し、閲覧を促す通知（例えば閲覧を求めるメール）を送るサービスがある。このようなサービスにおいて、文書を配布してから未閲覧者に閲覧を促すまでの期間（判定期間と呼ぶ）を、部門ごとに定める場合が考えられる。例えば、企業のトップが作成した文書を複数の部門の部門長に配布し、更にそれら部門長からそれぞれ部門内の各スタッフにその文書を配布した場合に、各部門のスタッフが当該部門で定められた期間内にその文書を閲覧していなければ、閲覧を促す通知を送ることになる。この処理のためには例えば、部門ごとの判定期間を文書管理サーバ１０に登録しておく。また、「配布」操作が行われると、文書管理サーバ１０は、配布先ユーザのリストを基本派生関係ＤＢ１１０又は部門別派生関係ＤＢ１２０におけるその配布操作に係る文書のレコードに登録しておく。そして、文書管理サーバ１０は、例えば定期的に、「配布」操作に係る文書の中から、その文書の登録日時からその文書の所属部門属性に対応する判定期間が過ぎたものを求める。そして、判定期間が過ぎた文書が見つかると、部門別派生関係ＤＢ１２０の派生関係におけるその文書の子孫を求め、その子孫の中から「閲覧」操作を行ったユーザを特定する。そして、そのＩＤ付き文書の配布先のリストに含まれているにもかかわらず、閲覧操作を行っていないユーザに対して閲覧を促す通知を、例えば電子メールで送信する。

この他に、派生関係やログ情報を閲覧する権限をどのユーザに与えるかを部門ごとに設定したり、派生関係やログ情報のバックアップの頻度を部門ごとに設定したりして、文書管理サーバ１０が閲覧制御やバックアップ制御をその設定に従って行うようにしてもよい。

さて、以上の例では、派生関係登録部１３２は、受信したＩＤ付き文書の部門属性とその親の部門属性が異なっている場合には、部門派生関係ＤＢ１２０に対し当該ＩＤ付き文書を根として（すなわち、その親の子としてではなく）登録した。このようにすると、図８に例示したように、受信番号９の「受付」操作は、Ａ部門に属する操作者によりなされたものであるにもかかわらず、その先祖で同じくＡ部門の操作者によりなされた受信番号１〜４の操作からなる木とは別の木の根となってしまう。このように、別の部門での操作を間に挟んだ同一部門の操作が一連の派生関係と捉えられるようにすると便利な場合がある。そのための処理の一例を、図１０を参照して説明する。図１０において、図９に示したステップと同様の処理を行うステップには同一符号を付して説明を省略する。

この処理手順では、派生関係登録部１３２は、ステップＳ１２で、注目するＩＤ付き文書３００のログ情報３１６に含まれる操作者の部門の値と、その親文書に対応する部門の値とが異なっていると判定した場合、基本派生関係ＤＢ１１０を参照してその親文書から１つ派生関係を先祖方向に遡る（Ｓ１８）。ここで、親文書から先祖に遡ることができない場合、すなわち親文書がルート（根）である場合（Ｓ２０の判定結果がＹｅｓ）には、当該ＩＤ付き文書３００の自文書ＩＤ３１２をルート（根）として、部門別派生関係ＤＢ１２０に登録する（Ｓ２２）。

一方、ステップＳ１２で、親文書から１つ先祖に遡れた場合（判定結果がＮｏ）、遡った先である先祖の文書の部門属性と、注目するＩＤ付き文書３００と部門属性とを比較し（Ｓ２４）、両者が異なっていればステップＳ１８に戻る。ステップＳ２４の判定にて両者の部門属性が一致していれば、注目するＩＤ付き文書３００がその先祖の文書の子であることを示す派生関係を部門別派生関係ＤＢ１２０に登録する（Ｓ２６）。

このような処理によれば、図６に例示した文書の流れから、図１１に例示する部門別派生関係ＤＢ１２０の内容が形成される。図１１では、受信番号９の文書の親文書として、同一部門（Ａ部門）の直近の先祖である受信番号３の文書（ID2）が登録されている点が、図７の場合と異なる点である。図１１の部分派生関係の情報は、図１２に示すような２つの木（ａ１）と（ｂ）を表す。この例から判るように、受信番号９の文書が、受信番号３の文書の子となっている。

このようにして形成された部門別派生関係ＤＢ１２０を用いることで、文書管理サーバ１０は、同一文書から派生した同一部門の操作に係る文書を一括して処理する。

以上に説明した実施形態はあくまで一例に過ぎない。例えば、図４の例では、文書管理サーバ１０が持つデータベースが文書ＤＢ１００、基本派生関係ＤＢ１１０及び部門別派生関係ＤＢ１２０の３つに分かれているが、これはあくまで一例に過ぎない。上述の例と同等のデータ内容を記憶可能なものであれば、どのようなデータベース構成をとってもよい。例えば基本派生関係ＤＢ１１０と部門別派生関係ＤＢ１２０のデータ内容を１つのデータベースにまとめてもよい。

以上の例では、派生関係を操作者の所属部門別に分割したが、派生関係の分割のキーとして部門以外の別の属性を用いてもよい。例えば、操作者、操作が行われた場所（例えば複数のオフィスがある組織の場合における、操作が行われたオフィス）、業務名等といった各種の属性項目をキーとしてもよい。ある属性項目を派生関係分割のキーとする場合、その属性項目がとり得る複数の属性値のそれぞれごとに派生関係を分割する。例えば、図１０の手順では、ステップＳ１２とＳ２４において、キーとする属性項目の属性値が同一かどうかを判定する。このようにして図１０（又は図９）の処理により、属性値別の派生関係がデータベース上に登録されることとなる。

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

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

以上に例示した文書管理サーバ１０及びクライアント端末２０は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカル・エリア・ネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。なお、それら機能モジュール群のうちの一部又は全部を、専用ＬＳＩ(Large Scale Integration)、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）又はＦＰＧＡ（Field Programmable Gate Array）等のハードウエア回路として構成してもよい。

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

Claims (3)

1. 第１の文書に対する操作により第２の文書が生成された場合に、第２の文書が第１の文書から派生したという基本派生関係と、当該操作についての属性値と、を対応づけて記憶する基本派生関係記憶手段と、
   第１の文書が操作を受けて第２の文書が生成された場合に、当該操作についての属性値が、第１の文書が第０の文書から派生したという基本派生関係に対応づけて前記基本派生関係記憶手段に記憶されている属性値と同じである場合には第１の文書から第２の文書が派生したという属性値別派生関係を記憶し、異なる場合には第１の文書から第２の文書が派生したという属性値別派生関係を記憶しない属性値別派生関係記憶手段と、
   前記属性値別派生関係記憶手段に記憶された属性値別派生関係を介して一続きに繋がっている文書群を単位として処理を行う処理手段と、
   を備える文書管理装置。
2. 前記属性値別派生関係記憶手段は、前記第１の文書が前記操作を受けて前記第２の文書が生成された場合に、当該操作についての前記属性値が、前記第１の文書が前記第０の文書から派生したという基本派生関係に対応づけて前記基本派生関係記憶手段に記憶されている属性値と異なる場合に、前記基本派生関係記憶手段に記憶されている基本派生関係を前記第０文書から派生元の方向へと順次遡る過程で最初に見つかる、前記属性値と同じ属性値に対応づけられた基本派生関係の派生先側の文書から、前記第１の文書が派生したという属性値別派生関係を記憶する、ことを特徴とする請求項１記載の文書管理装置。
3. コンピュータを、
   第１の文書に対する操作により第２の文書が生成された場合に、第２の文書が第１の文書から派生したという基本派生関係と、当該操作についての属性値と、を対応づけて記憶する基本派生関係記憶手段、
   第１の文書が操作を受けて第２の文書が生成された場合に、当該操作についての属性値が、第１の文書が第０の文書から派生したという基本派生関係に対応づけて前記基本派生関係記憶手段に記憶されている属性値と同じである場合には第１の文書から第２の文書が派生したという属性値別派生関係を記憶し、異なる場合には第１の文書から第２の文書が派生したという属性値別派生関係を記憶しない属性値別派生関係記憶手段、
   前記属性値別派生関係記憶手段に記憶された属性値別派生関係を介して一続きに繋がっている文書群を単位として処理を行う処理手段、
   として機能させるためのプログラム。

Images