文書管理装置、情報処理装置、文書管理システム及びプログラム
【課題】派生関係に基づき文書を検索し提供する場合に、提供する文書を制限するための技術を提供する。
【解決手段】クライアントは、管理ＩＤを含んだＩＤ付き文書を操作すると、新たに生成した管理ＩＤと、元の管理ＩＤ（親ＩＤ）と、その操作のログ情報と、操作後の文書内容とを含んだ新たなＩＤ付き文書を生成してサーバに送る。ここで、その操作の種別があらかじめ登録された種別に該当する場合、ログ情報の中に「公開」属性を組み込む。サーバの文書登録部１３０は、送られてきた管理ＩＤ、親ＩＤ、ログ情報、文書内容を派生関係ＤＢ１１０、文書ＤＢ１００に登録する。ユーザがあるＩＤ付き文書を用いて検索要求を行った場合、要求処理部１４０は、派生関係ＤＢ１１０中の派生関係群をその文書を起点として辿り、「公開」属性の設定された文書の中から、検索条件を満たすものを提供する。
【解決手段】クライアントは、管理ＩＤを含んだＩＤ付き文書を操作すると、新たに生成した管理ＩＤと、元の管理ＩＤ（親ＩＤ）と、その操作のログ情報と、操作後の文書内容とを含んだ新たなＩＤ付き文書を生成してサーバに送る。ここで、その操作の種別があらかじめ登録された種別に該当する場合、ログ情報の中に「公開」属性を組み込む。サーバの文書登録部１３０は、送られてきた管理ＩＤ、親ＩＤ、ログ情報、文書内容を派生関係ＤＢ１１０、文書ＤＢ１００に登録する。ユーザがあるＩＤ付き文書を用いて検索要求を行った場合、要求処理部１４０は、派生関係ＤＢ１１０中の派生関係群をその文書を起点として辿り、「公開」属性の設定された文書の中から、検索条件を満たすものを提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
文書管理装置、情報処理装置、文書管理システム及びプログラムに関する。
【背景技術】
【０００２】
テキスト文書データや音声データ、マルチメディアデータなどの電子文書（以下単に文書とも呼ぶ）をサーバに登録し、ユーザの要求に応じてその文書を提供することが行われている。また、電子文書に対して一意な識別子を付与し、ユーザが入力した識別子に対応する電子文書を提供するシステムも知られている。また、別の公知のシステムでは、電子文書を紙に印刷する場合に、電子文書の識別子をコード化して紙文書に埋め込み、紙文書を複写する際にその紙文書に埋め込まれた識別子を認識し、その識別子に対応した電子文書を取得し、紙に印刷する。
【０００３】
特許文献１に開示されたシステムは、コンテンツコピー機は、コンテンツＩＤが埋め込まれたコンテンツのコピー原稿からコンテンツＩＤを読み取り、読み取ったコンテンツＩＤとコピーイベント属性の情報とをネットワークを介してコンテンツＩＤ管理センタへ送信する。コンテンツＩＤ管理センタは、受信したコンテンツＩＤからそのコンテンツの原本を取得し、新しいコンテンツＩＤを付与して、そのコンテンツＩＤとコピーイベント属性の情報とを記録し、その新しいコンテンツＩＤをコンテンツの原本に対して埋め込んでコピー要求元へ返す。コンテンツコピー機は、それをコピー結果として出力する。このシステムにおいて、コンテンツＩＤ管理センタは、コンテンツコピー機から受信したコンテンツＩＤに応じて、新たなコンテンツＩＤを発行した場合、その新しいコンテンツＩＤコピー元が前述の受信したコンテンツＩＤであることを記録する（例えば特許文献１の第４１段落末尾）。
【０００４】
特許文献２に開示されたシステムでは、電子文書を紙に印刷する場合、電子文書の文書識別子を埋め込んで印刷する。そして、紙文書が入力された場合、システムはその紙文書から文書識別子を抽出し、その文書識別子に対応する電子文書をダウンロードして印刷する。また、このシステムでは、ダウンロードされた電子文書が更新された場合、更新された電子文書を新しい文書識別子に対応づけて登録し、その新しい文書識別子を埋め込んだ紙文書を印刷する。
【０００５】
特許文献３に開示されたシステムでは、紙文書に対する手書きによる編集を、直接的に電子文書に反映し、電子文書の更新された版の系列を、電子文書をノードとする木構造として保持する。文書やファイルをノードとし、文書やファイルの更新によって生成される版を、枝分かれした版として管理する事ができる文書履歴木の例も開示されている。このようなバージョン管理システムは、CVS（Concurrent Versions System)として広く知られている。また、特許文献３には、電子文書の更新に関する履歴を、更新前の電子文書を親とし、更新後の電子文書を子とするように文書履歴木を管理する方法が開示されている。
【０００６】
特許文献４に開示されたシステムでは、端末装置は、コンテンツＩＤが埋め込まれたコンテンツの複製物またはその一部から、コンテンツＩＤを読み取り、そのコンテンツＩＤと検索補助情報とをコンテンツＩＤ管理センタへ送信する。コンテンツＩＤ管理センタは、コンテンツＩＤと検索補助情報とを受け取ると、そのコンテンツＩＤに対応するコンテンツの原本もしくはそれに関連するコンテンツを端末装置へ返送する。
【０００７】
【特許文献１】特許第３３８３７９３号明細書
【特許文献２】特開２００６−０５３６８６号公報
【特許文献３】特開２００５−１３５２１１号公報
【特許文献４】特開２００２−０１４９７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、文書に対して操作が行われた場合に操作前の文書から操作後の文書が派生したことを示す派生関係を記録し、指定された文書に対して派生関係のある文書をその記録に基づき求めて提供するサービスが考えられる。しかしながら、派生関係に従って導き出される文書を無制限に提供したのでは、不都合な文書まで開示される可能性がある。
【０００９】
本発明は、派生関係に基づき文書を検索し提供する場合に、提供する文書を制限するための技術を提供する。
【課題を解決するための手段】
【００１０】
請求項１に係る発明は、情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する検索結果提供部と、を備える文書管理装置である。
【００１１】
請求項２に係る発明は、請求項１に係る発明において、前記登録部は、更に前記第２の文書と前記第１の文書との間が検索境界であるか否かを示す検索境界情報を前記情報処理装置から受け取って前記第２の文書と対応づけて前記記憶部に登録し、前記検索結果提供部は、前記派生関係群がなす木群の中の前記検索境界で区切られる部分木群のうち前記対象文書の属する部分木に属する文書の中で、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する、ことを特徴とする。
【００１２】
請求項３に係る発明は、情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録するステップであって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録するステップと、対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供するステップと、をコンピュータに実行させるためのプログラムである。
【００１３】
請求項４に係る発明は、文書に対する操作を実行する操作実行部と、操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、を備える情報処理装置である。
【００１４】
請求項５に係る発明は、文書に対する操作を実行する操作実行部と、操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、してコンピュータを機能させるためのプログラムである。
【００１５】
請求項６に係る発明は、情報処理装置と文書管理装置とを備え、前記情報処理装置は、文書に対する操作を実行する操作実行部と、操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、を備え、前記文書管理装置は、前記情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録する登録部であって、前記第１の文書が前記記憶部既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する検索結果提供部と、を備える。
【発明の効果】
【００１６】
請求項１に係る発明によれば、情報処理装置からの開示属性情報に応じて、操作の結果の文書を検索結果として提供するか否かを制御することができる。
【００１７】
請求項２に係る発明によれば、更に、情報処理装置からの検索境界情報に応じて、検索指示に対する検索範囲を限定することができる。
【００１８】
請求項３に係る発明によれば、情報処理装置からの開示属性情報に応じて、操作の結果の文書を検索結果として提供するか否かを制御することができる。
【００１９】
請求項４に係る発明によれば、文書に対して実行した操作に応じて、その操作結果の文書を開示して良いか否かを文書管理装置に指示することができる。
【００２０】
請求項５に係る発明によれば、文書に対して実行した操作に応じて、その操作結果の文書を開示して良いか否かを文書管理装置に指示することができる。
【００２１】
請求項６に係る発明によれば、情報処理装置からの開示属性情報に応じて、操作の結果の文書を検索結果として提供するか否かを制御することができる。
【発明を実施するための最良の形態】
【００２２】
図１は、文書利用管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。
【００２３】
クライアント端末２０について図２を用いて説明する。クライアント端末は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複合機などがその一例である。クライアント端末２０は、図２に示すように、文書操作部２００及び登録処理部２１０を備える。
【００２４】
文書操作部２００は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示（ユーザから見れば「閲覧」）、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図では、文書操作部２００を１つだけ示したが、それら個々の操作を別々の操作部（例えば、編集用のアプリケーション、読取制御用のアプリケーションなど）が担当してもよい。例えば、文書操作部２００がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部２００は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部２００は、文書に対して操作を行った場合、その操作の結果を表すＩＤ付き文書３００を出力する。
【００２５】
ＩＤ付き文書３００は、図３に示すように、メタ情報３１０と文書内容３２０を含んだ電子文書である。文書内容３２０は、文書操作部２００の操作の結果生成された文書の内容データである。文書操作部２００が電子文書を作成・編集するためのソフトウエアであれば、文書内容３２０はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部２００が電子文書を印刷する装置であれば、文書内容３２０は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部２００が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容３２０は、例えば、その紙文書を読み取って得られる画像データとすればよい。
【００２６】
メタ情報３１０は、文書管理のための情報であり、管理ＩＤ３１２，親ＩＤ３１４，及びログ情報３１６を含む。
【００２７】
管理ＩＤ３１２は、当該ＩＤ付き文書３００自体の一意な識別情報である。親ＩＤ３１４は、当該ＩＤ付き文書３００の親のＩＤ付き文書の管理ＩＤである。すなわち、本実施形態では、あるＩＤ付き文書と、このＩＤ付き文書に対して操作を加えた結果得られる新たなＩＤ付き文書とを、親と子の関係として取り扱う。第１のＩＤ付き文書を操作して第２のＩＤ付き文書が得られた場合、第１のＩＤ付き文書は第２のＩＤ付き文書の親であり、第２のＩＤ付き文書は第１のＩＤ付き文書の子である。したがって、例えば、管理ＩＤ「Ａ」のＩＤ付き文書を文書操作部２００で操作して、その結果得られた新たなＩＤ付き文書の管理ＩＤが「Ｂ」である場合、後者のメタ情報３１０における管理ＩＤ３１２は「Ｂ」であり、親ＩＤ３１４は「Ａ」である。このような親子の関係を、以下では「（管理ＩＤの）派生関係」という。
【００２８】
なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合（この場合、紙文書を読み取った画像を文書内容とするＩＤ付き文書が生成され、本システムに登録される）に生成されるＩＤ付き文書３００では、親ＩＤ３１４は空（すなわち、親は存在しない）となる。
【００２９】
ログ情報３１６は、当該ＩＤ付き文書が生成された際の操作についての、各種のログ項目の情報である。ログ項目には、例えばその操作が行われた日時、その操作の種別、その操作を指示したユーザ（操作者）などがあるが、もちろんこれに限るものではない。操作の種別には、例えば登録（本システムに新規の文書を登録すること）、閲覧、編集、更新（更新版の登録）、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部２００を用いて第１のＩＤ付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第２のＩＤ付き文書のログ情報３１６は、編集完了の日時と、その編集を指示したユーザの識別情報と、操作の種別として「編集」と、を含んだものとなる。
【００３０】
ここでログ情報３１６に組み込まれる操作の種別は、ログ記録の目的での分類に従った種別であり、文書操作部２００が実行する操作の種別そのものでなくてもよい。例えば、文書操作部２００が実行する複数の操作の種別を、同じ１つのログ記録目的の操作種別に対応づけてもよい。例えば、文書編集アプリケーション上でＩＤ付きの電子文書に編集を加え操作メニュー上で「更新版として登録」を指示した場合も、スキャナで管理ＩＤ付きの紙文書を読み取り読取制御用アプリケーションの操作メニュー上で「読み取った文書を承認版として登録」を指示した場合も、ログ情報３１６に組み込まれる操作種別の値は「更新」となる。
【００３１】
また、ログ情報３１６の中には、当該ＩＤ付き文書３００が公開（共有）対象であるか否かを示す「公開」属性を組み込むこともできる。例えば公開対象とするＩＤ付き文書の「公開」属性値を「１」とし、公開対象としないＩＤ付き文書の「公開」属性値は「０」とすると、「公開」属性が「０」であるＩＤ付き文書は、当該文書を生成するための操作を行った操作者や管理者等の特権的なユーザ以外には、公開されないようにすることができる。
【００３２】
なお、「公開」属性の値は、操作の種別に従って決定する。公開属性値を決める基準となる操作の種別は、文書操作部２００が実行した操作の種別でも、ログ記録目的の分類に従った操作の種別でもよい。いずれを用いるかは、文書操作部２００に設定されていればよい。
【００３３】
文書操作部２００が生成するメタ情報３１０の具体例を以下に示す。
【００３４】
[例１]
<metadata sid="Doc1" date="2006-10-01T10:00" method="register" filename="aaa.doc" user="user1"/>
【００３５】
ここでsid属性は管理ＩＤ、date属性は操作日時、method属性は操作種別である。また、filename属性は当該ＩＤ付き文書のファイル名であり、user属性は操作を指示したユーザのユーザ識別情報である。例１のmethod属性値"register"は（文書管理サーバ１００に未登録の）新規文書の登録操作を示す操作種別名である。新規文書の登録なので、親ＩＤを示すpid属性は省略されている。省略する代わりにpid="null"などと、親ＩＤがないことを示す属性を明示的に組み込んでもよい。また、この例では、新規文書登録により登録された文書は公開対象としないので、公開対象か否かを示すshared属性は省略されている。省略する代わりにshared="0"などと、公開対象でないことを示す属性を明示的に組み込んでもよい。
【００３６】
また、以下に示す例２は、ユーザ識別情報が"user4"であるユーザが、管理ＩＤ"Doc2"が埋め込まれた紙文書をスキャナで読み込んで「承認版として登録」する操作を行った場合に生成されるメタ情報３１０である。
【００３７】
[例２]
<metadata sid="Doc4" pid="Doc2" date="2006-10-01T11:28" method="update" filename="200610011128.jpg" user="user4" shared="1"/>
【００３８】
ここで、method属性値"update"は更新操作を示している。この例では、スキャン画像のファイル名は操作日時を元に自動生成された値である。この例は、更新操作により登録された文書は公開対象とする場合の例であり、shared属性値は公開対象であることを示す値「１」となっている。
【００３９】
なお、文書操作部２００が、操作した文書を暗号化してもよい。この暗号化は、本システムに準拠した文書操作部２００ならば、復号できるようなものとする。この場合、文書操作部２００が出力するＩＤ付き文書３００の文書内容３２０は、暗号化されることにより、本システムに準拠した文書操作部２００でないと復号できなくなる。したがって、ＩＤ付き文書３００が操作される場合には文書操作部２００が用いられるので、文書操作部２００がその操作を検知し、その操作の内容が文書操作部２００から文書管理サーバ１０に通知される。なお、文書内容３２０だけでなく、後述するメタ情報３１０（またはその一部）に対しても暗号化を施してもよい。
【００４０】
図２の説明に戻り、文書操作部２００は、操作結果として上述のようなＩＤ付き文書３００を作成するために、ＩＤ割り当て部２０２及び派生関係組込部２０４を備える。ＩＤ割り当て部２０２は、操作結果のＩＤ付き文書３００に一意な管理ＩＤを付与する手段である。管理ＩＤは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するＩＤ付き文書３００（ただし管理ＩＤ３１２を除いたもの）のハッシュ値を求め、このハッシュ値をその文書３００のＩＤ付き文書とすればよい。ハッシュ関数としてSHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ管理ＩＤを生成することができる。もちろん、システム内で一意な管理ＩＤを各クライアント端末２０で生成する方法は、これに限らない。管理ＩＤを、クライアント端末２０固有の識別情報を含むものとすれば、システム内で一意な管理ＩＤを各クライアント端末２０で生成することができる。
【００４１】
派生関係組込部２０４は、操作結果の文書に対しＩＤ割り当て部２０２が割り当てた新たな管理ＩＤ３１２と、その操作の元になった親文書の管理ＩＤである親ＩＤ３１４（新規登録の場合は、親ＩＤは無し）と、その操作についてのログ情報３１６と、を含むメタ情報３１０を生成する。ここで、派生関係組込部２０４は、文書操作部２００が実行する個々の操作の種別が、ログ記録目的上の操作種別のどれに対応するかを表す対応関係の情報を保持しており、この情報を用いることでログ情報３１６に組み込む操作種別の値を求める。また、派生関係組込部２０４は、操作種別ごとに当該種別の操作の結果である文書を公開対象とするか否かを示す情報を保持しており、この情報に基づきshared属性値を決定する。そして、派生関係組込部２０４は、そのメタ情報３１０を操作結果の文書内容に付加することにより、操作後のＩＤ付き文書３００を生成して出力する。
【００４２】
文書操作部２００がアプリケーションソフトウエアである場合、ＩＤ割り当て部２０２及び派生関係組込部２０４は、そのソフトウエアに対して追加される、いわゆるプラグイン(plug-in)プログラムとして実現してもよい。
【００４３】
登録処理部２１０は、文書操作部２００が出力したＩＤ付き文書３００を文書管理サーバ１０に登録するための処理を実行する。このように各クライアント端末２０が、自ら実行した操作の結果であるＩＤ付き文書３００を文書管理サーバ１０に登録することにより、文書管理サーバ１０は各ＩＤ付き文書３００間の派生関係を把握することができる。
【００４４】
文書操作部２００が操作の結果出力するＩＤ付き文書３００は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。電子メール送信用のソフトウエアは、この例では本システムに準拠していないので、この送信操作はＩＤ付き文書には反映されず、したがって文書管理サーバ１０にも記録されない。他の人からＩＤ付き文書３００を受け取った人が、自分のクライアント端末２０の文書操作部２００を用いてそのＩＤ付き文書３００を操作すると、その操作に応じて新たな管理ＩＤを付与されたＩＤ付き文書が生成されることになる。
【００４５】
また、文書操作部２００が電子文書を印刷する場合、管理ＩＤを生成し、その電子文書の印刷結果にその管理ＩＤを埋め込んでもよい。管理ＩＤの埋め込みは、例えば電子文書の印刷画像に、管理ＩＤを示すコード画像を重畳する等の方法で行うことができる。また、用紙がＲＦＩＤ(Radio Frequency Identifier)タグを備えている場合、そのＲＦＩＤタグに管理ＩＤを書き込んでもよい。このように印刷を行った場合、文書操作部２００は、その管理ＩＤや操作種別「印刷」等のメタ情報を含んだＩＤ付き文書を文書管理サーバ１０に登録する。なお、ＩＤ付き文書を印刷した場合には、そのＩＤ付き文書の管理ＩＤを親ＩＤ３１４として含んだＩＤ付き文書が生成される。印刷操作に対応するＩＤ付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データをなどの印刷データ、又は印刷された文書ファイルを、文書内容３２０として組み込んでもよい。
【００４６】
また、管理ＩＤが埋め込まれた紙文書を文書操作部２００が読み取った場合、文書操作部２００は、その読み取り操作に対して新たな管理ＩＤを付与し、読み取り結果の画像を文書内容３２０として含んだＩＤ付き文書を生成して文書管理サーバ１０に登録する。このＩＤ付き文書の親ＩＤ３１４には、紙文書から読み取った管理ＩＤがセットされる。管理ＩＤが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。
【００４７】
次に、文書管理サーバ１０について説明する。文書管理サーバ１０は、システム内の複数のクライアント端末２０から送られてくるＩＤ付き文書３００を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。図４に示すように、文書管理サーバ１０は、文書ＤＢ１００，派生関係ＤＢ１１０，文書登録部１３０，要求処理部１４０を備える。
【００４８】
文書ＤＢ１００は、クライアント端末２０から送られてきたＩＤ付き文書３００のうちの文書内容３２０を格納するデータベースである。文書ＤＢ１００に格納された各文書内容３２０は、一意な内容ＩＤにより管理してもよい。内容ＩＤとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末２０が内容ＩＤを付与してもよく、この場合、内容ＩＤをメタ情報３２０に組み込んでもよい。また、内容ＩＤの代わりに、その文書内容３２０を、当該文書内容に対応するＩＤ付き文書３００の管理ＩＤと対応づけて文書ＤＢ１００に格納してもよい。
【００４９】
文書登録部１３０は、クライアント端末２０から受信したＩＤ付き文書の中の文書内容を文書ＤＢ１００に、メタ情報を派生関係ＤＢ１１０に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部１３２である。
【００５０】
派生関係ＤＢ１１０は、そのようなＩＤ付き文書３００のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図５に、派生関係ＤＢ１１０のデータ内容の一例を示す。図５に示した表における１行の情報が、１つのＩＤ付き文書３００に対応するメタ情報レコードである。この例では、各ＩＤ付き文書３００の管理ＩＤに対応づけて、親ＩＤ、ノードアドレス、操作種別、操作者、操作日時、「公開」属性及び、文書格納パス、の各項目が登録されている。このうち、管理ＩＤと親ＩＤのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。また、操作種別、操作者、操作日時、及び公開属性については既に説明した。ノードアドレスは、ＩＤ付き文書間の派生関係が構成する木において、当該管理ＩＤ（ＩＤ付き文書）に対応するノードの位置を示している。ノードアドレスの表記において「／」が木の深さ階層の区切りを示し、番号が同じ親から派生した兄弟同士の間での順番を示す。例えばノード「／１」は新規文書登録の操作により登録された文書に対応する根ノードを示す。また、ノード「／１／１」は根ノード「／１」の１番目の子、ノード「／１／２」は根ノード「／１」の２番目の子を示す。なお、煩雑さを避けるため、図５には、１つの根ノード「／１」から派生した１つの木に属するメタ情報レコード群しか示していないが、文書管理サーバ１０には、例えば根「／１」から派生する木と根「／２」から派生する木のように、複数の木のメタ情報レコード群が登録され得る。文書格納パスは、文書内容３２０の文書ＤＢ１００内での格納場所を示すパス名である。図５の例では、文書内容は、Ｅドライブの「\doc」というフォルダに、date属性（操作日時）の後にfilename属性（ファイル名）を続けたファイル名で登録されている。なお、文書ＤＢ１００が、内容ＩＤで文書内容３２０を検索する機能を持つものであれば、文書格納パスの代わりに内容ＩＤをメタ情報レコードに登録しておけばよい。
【００５１】
なお、図５は派生関係ＤＢ１１０が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係ＤＢ１１０は、一般的なリレーショナルデータベースとして構築することもできるし、管理ＩＤを除くメタ情報を記述したＸＭＬ(eXtensible Markup Language)文書を、管理ＩＤをキーとして登録したデータベースとして構築することもできる。
【００５２】
図５に示した派生関係ＤＢ１１０のデータ内容は、図６のような木構造を成す。これは、管理ＩＤをノードとし、管理ＩＤ間の親子関係をエッジとする木構造である。
【００５３】
図５〜図６の例が示す文書の履歴を時系列順に説明すると、以下のようになる。この例は、あるユーザが申請書等のフォーム（ひな形文書）を本システムに登録し、他のユーザがそのフォームに対して記入を行い、記入済みフォームを本システムに登録する業務の流れを表している。
【００５４】
この例ではまず、文書（フォーム）の「登録」操作がuser1のクライアント端末で実行される。「登録」操作は、文書管理サーバ１０に未登録の文書（すなわち、管理ＩＤを有していない文書）を当該サーバ１０に登録するための操作である。この操作に応じて管理ＩＤが"Doc1"、親ＩＤが空、操作種別が「登録」であるメタ情報と、その文書の文書内容とを含むＩＤ付き文書"Doc1"がuser1のクライアント端末から文書管理サーバ１０に送られる。ここで、「登録」操作は、「公開」の対象にはなっていないので、メタ情報中には「公開」属性の値は含まれない。これに応じ、文書管理サーバ１０は、そのＩＤ付き文書"Doc1"中の文書内容を文書ＤＢ１００へ、メタ情報を派生関係ＤＢ１１０にそれぞれ登録する。ここで、文書管理サーバ１０は、操作種別が「登録」であり、親ＩＤが空なので、当該ＩＤ付き文書が、文書管理サーバ１０内に既に登録済みのＩＤ付き文書の子ではなく、新たな木の根（始祖）であると判断し、それに従ってノードアドレスの値（この例では「／１」）を設定する。なお、以下では、識別のために、登録された文書内容を"Content1"で表すことにする。その後、user1は、登録したＩＤ付き文書を他のユーザuser2，user3，・・・に配布する。この配布は、例えば、電子メールにそのＩＤ付き文書を添付して各ユーザに送信することにより、行うことができる。
【００５５】
その後、他のユーザuser2が自分のクライアント端末の文書操作部２００でＩＤ付き文書"Doc1"を印刷する。印刷されるのは文書内容"Content1"、又はそれに編集を加えた結果の文書内容である。このとき文書操作部２００は、印刷結果の紙文書に対して新たに付与した管理ＩＤ"Doc2"を埋め込む。このように管理ＩＤが埋め込まれた紙文書をＩＤ付きの紙文書と呼ぶことにする。また、クライアント端末は、印刷の結果としてＩＤ付き文書"Doc2"を生成し、文書管理サーバ１０に登録する。このＩＤ付き文書のメタ情報における管理ＩＤは"Doc2"であり親ＩＤは"Doc1"である。また操作者はuser2であり。操作種別は印刷である。また、「印刷」操作は、「公開」の対象にはなっていないので、そのＩＤ付き文書のメタ情報中には「公開」属性の値は含まれない。文書管理サーバ１０は、受け取ったＩＤ付き文書の親ＩＤの値から、当該文書"Doc2"が文書"Doc1"の子であることを認識し、しかも最初の子であるので、文書"Doc2"のノードアドレスを「／１／１」とする。
【００５６】
なお、この操作の前にuser2のクライアント端末２０内にあったＩＤ付き文書"Doc1"は、この操作に伴い、派生関係組込部２０４によりＩＤ付き文書"Doc2"に置き換えられる。この置き換え処理では、派生関係組込部２０４は、元のＩＤ付き文書"Doc1"のうち、メタ情報３１０の管理ＩＤ３１２を新たに発行したＩＤ"Doc2"へ変更すると共に、元の文書"Doc1"の管理ＩＤ"Doc1"を親ＩＤ３１４の値にセットする。また、派生関係組込部２０４は、ログ情報３１６中の操作種別の値を今回の操作の種別である「印刷」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser2に変更する。また、文書内容３２０は、印刷指示をされた時点の文書内容を示す印刷データ又は文書ファイルとなる。
【００５７】
このようにＩＤ付き文書"Doc1"は、閲覧されると、閲覧後のＩＤ付き文書"Doc2"に置き換えられる。したがって、その置き換えの後は、ＩＤ付き文書"Doc1"自体はそのクライアント端末２０には存在せず、その代わりにＩＤ付き文書"Doc2"が存在することとなる。なお、user2は、印刷結果の紙文書"Doc2"を、他のユーザであるuser4に渡す。
【００５８】
その後、更に別のユーザuser3が自分のクライアント端末の文書操作部２００でＩＤ付き文書"Doc1"を閲覧する。閲覧されるのは内容ＩＤ"Content1"の文書内容である。クライアント端末は、閲覧の結果としてＩＤ付き文書"Doc3"を生成し、文書管理サーバ１０に登録する。ここで、「閲覧」操作は、「公開」の対象にはなっていないので、そのＩＤ付き文書のメタ情報中には「公開」属性の値は含まれない。「閲覧」操作では、文書内容は変更されないので、文書内容は"Content1"のままである。なお、このように文書内容が変更されない操作を行った場合、クライアント端末２０は、文書内容を省略したＩＤ付き文書を文書管理サーバ１０に送ってもよい。なお、この操作の前にuser3のクライアント端末２０内にあったＩＤ付き文書"Doc1"は、この操作に伴い、派生関係組込部２０４によりＩＤ付き文書"Doc3"に置き換えられる。この置き換え処理では、派生関係組込部２０４は、元のＩＤ付き文書"Doc1"のうち、メタ情報３１０の管理ＩＤ３１２を新たに発行したＩＤ"Doc2"へ変更すると共に、元の文書"Doc1"の管理ＩＤ"Doc1"を親ＩＤ３１４の値にセットする。また、派生関係組込部２０４は、ログ情報３１６中の操作種別の値を今回の操作の種類である「閲覧」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser3に変更する。なお、今回の操作は閲覧なので、文書内容３２０は変化しない。
【００５９】
次に、user4が、user2から受け取ったＩＤ付きの紙文書"Doc2"に対して書き込みを行い、書き込み済みの紙文書をスキャナにセットし、クライアント端末２０上の読取制御ソフトウエアの操作メニューから「承認版として登録」の操作を選んだとする。すると読取制御ソフトウエアは、スキャナを制御して紙文書を読み取り、その読取結果の画像データを文書内容（以下、識別のためにこの文書内容を"Content2"と名付ける）として含むＩＤ付き文書"Doc4"を生成し、文書管理サーバ１０に送ると共に、当該クライアント端末２０内に保存する。このＩＤ付き文書"Doc4"内のメタ情報３１０に含まれる管理ＩＤは"Doc4"であり、親ＩＤは"Doc2"である。この親ＩＤ"Doc2"は、紙文書から読み取った管理ＩＤである。またuser属性はuser4である。また、文書操作部２００での「承認版として登録」という操作は、ログ記録目的上での「更新」という操作種別に分類されるので、メタ情報中のmethod属性は「更新」となる。また、この例では、「更新」という操作種別が「公開」の対象に設定されているので、メタ情報中のshared属性の値は「１」（この値は「公開対象である」ことを意味する）となる。
【００６０】
次に、user4がＩＤ付き文書"Doc4"を文書操作部２００により編集する。これにより、編集結果の文書内容"Content3"を含み、"Doc4"を親ＩＤとして含む新たなＩＤ付き文書"Doc5"が生成され、文書管理サーバ１０に登録される。user4のクライアント端末２０内のＩＤ付き文書"Doc4"はこのＩＤ付き文書"Doc5"に置き換えられる。
【００６１】
次に、user3が自分のクライアント端末内のＩＤ付き文書"Doc3"に対し文書操作部２００にて編集を加え、操作メニュー上で「更新版として登録」を指示すると、クライアント端末は、管理ＩＤ３１２の値が"Doc6"、親ＩＤ３１４の値が"Doc3"、操作種別の値が「更新」であるＩＤ付き文書"Doc6"を生成して、これをＩＤ付き文書"Doc3"と置き換えると共に、そのＩＤ付き文書"Doc6"を文書管理サーバ１０に登録する。編集により、文書内容は"Content3"から"Content4"へと変化している。「更新」操作は公開対象なので、そのＩＤ付き文書"Doc6"のshared属性は「１」である。文書管理サーバ１０の派生関係ＤＢ１１０には、管理ＩＤ"Doc6"のレコードが登録される。
【００６２】
図５及び図６は、この時点での派生関係ＤＢ１１０内の、"Doc1"から派生する文書或いは操作の様子を示している。
【００６３】
以上、派生関係ＤＢ１１０のデータ内容を例に取り、本システムにおける文書操作の情報の登録の様子を説明した。
【００６４】
図４の説明に戻り、要求処理部１４０は、クライアント端末２０からの管理ＩＤを含んだサービス要求に応じて、派生関係ＤＢ１１０を用いたサービスを提供する。要求処理部１４０が提供するサービスとしては、例えば、サービス要求中の管理ＩＤに対応する文書の最新版を検索するサービスがある。また別の例として、サービス要求中の管理ＩＤに対応する始祖（根）の文書又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、その管理ＩＤの来歴、すなわち始祖からその管理ＩＤまでに文書が経てきた操作の履歴（例えば誰がいつどんな操作をしたのかを示す情報のリスト）を提供するサービスもある。また、派生関係ＤＢ１１０に登録された属性項目についての検索条件の指定を受け付け、その検索条件を満足するＩＤ付き文書のリストを提供するサービスもある。なお、上述の最新版を検索するサービスは、「操作日時が最新である」という検索条件についての検索結果を提供するサービスと捉えることもできる。また、上述の始祖の文書の情報を提供するサービスは、「ノードアドレスが根を示す文書」という条件についての検索結果を提供するサービスと捉えることができる。
【００６５】
サービス要求は、クライアント端末２０に保持されたＩＤ付き文書に基づき発せられる。例えば、ユーザがクライアント端末２０の文書操作部２００によりＩＤ付き文書を開いた場合に、文書操作部２００が、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付ける。そして、そのＩＤ付き文書の管理ＩＤと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ１０の要求処理部１４０に送信する。このとき、ユーザ識別情報や操作日時などの属性項目についての検索条件を指定するユーザインタフェース画面を提供し、この画面を介して入力された検索条件を併せて要求処理部１４０に送信してもよい。また、管理ＩＤと、サービスを示すコード、検索条件以外に、指示を行ったユーザの識別情報や、ユーザの入力した認証情報などといった他の情報を、クライアント端末２０から要求処理部１４０に送信するようにしてもよい。
【００６６】
また、別の例として、ＩＤ付き文書というオブジェクト種類に対して、そのようなサービスのメニューを対応づけてクライアント端末２０のオペレーティングシステムに登録しておいてもよい。この場合、図７に示すように、オペレーティングシステムが提供するファイル管理画面４００に表示されたＩＤ付き文書のアイコン４１０又は４１４に対し、ユーザが右ボタンクリックなどの所定の操作を行った場合、オペレーティングシステムが、ＩＤ付き文書に対応づけられたメニュー４２０を画面表示する。図示例では、ＩＤ付き文書のアイコン４１０又は４１４には、本システムのＩＤ付き文書であることを示すマーク４１１により、他の種類のファイル４１２と区別可能となっている。ユーザがメニュー４２０上の各サービス項目の中から、所望のものを選択すると、クライアント端末２０は、選択されたサービス項目の実行を文書管理サーバ１０に要求する。
【００６７】
また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理ＩＤを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のＩＤ付き文書の管理ＩＤを親ＩＤとして含んだＩＤ付き文書を生成し、このＩＤ付き文書をサービス要求として文書管理サーバ１０に送ってもよい。この場合、要求処理部１４０は、受け取ったＩＤ付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくＩＤ付き文書内の親ＩＤを、派生関係を遡る処理の起点とする。
【００６８】
要求処理部１４０は、クライアント端末２０からサービス要求を受けた場合、そのサービス要求中に指定された管理ＩＤを起点に、派生関係ＤＢ１１０に登録された管理ＩＤと親ＩＤとの派生関係が構成する木を走査（トラバース）し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。
【００６９】
以下、サービス要求を受け取った場合の要求処理部１４０の処理手順を、図８及び図９を参照して説明する。以下では、派生関係ＤＢ１１０内のデータ内容が図５及び図６に例示したものである時に、user2が、自分のクライアント端末２０内にあるＩＤ付き文書"Doc2"を対象として、当該ユーザが指定した検索条件を満たす文書の要求を行った場合を具体例として用いて説明する。
【００７０】
この手順では、要求処理部１４０は、クライアント端末２０から受け取ったサービス要求から、処理対象として含まれる管理ＩＤを取り出し、その管理ＩＤを注目ＩＤにセットする（Ｓ１）。次に、派生関係ＤＢ１１０から、注目ＩＤに対応するレコードを取得する（Ｓ２）。注目ＩＤに対応するレコードとは、注目ＩＤをレコード中の「管理ＩＤ」の項目の値として持つレコードのことである。そして、取得したレコード中の操作種別の項目の値が「登録」であるか否かを調べ（Ｓ３）、「登録」でなければ、注目ＩＤの値をそのレコード中の親ＩＤの値へと置き換え（Ｓ４）、ステップＳ２及びＳ３を実行する。このステップＳ２〜Ｓ４のループは、サービス要求中の管理ＩＤから派生関係の木構造を遡り、大本（根）であるフォーム原本の「登録」操作を見つけるための処理を表す。ステップＳ３の判定結果がＹｅｓとなった場合、そのときの注目ＩＤは、根である「登録」操作に対応する。図５の例では、管理ＩＤ"Doc2"から木構造を遡ることで、最終的に、根である管理ＩＤ"Doc1"に到達する。
【００７１】
根である「登録」操作に到達すると、要求処理部１４０は、そのときの注目ＩＤ（根）の子ＩＤを検索する（Ｓ５）。派生関係ＤＢ１１０のうちその注目ＩＤを「親ＩＤ」の値として持つレコードの「管理ＩＤ」が、注目ＩＤの子ＩＤである。注目ＩＤの子ＩＤがすべて求められると、要求処理部１４０は、それら子ＩＤごとに、図９に示すような子孫探索処理を実行する（Ｓ６）。
【００７２】
子孫探索処理（Ｓ６）では、要求処理部１４０は、当該子ＩＤを注目ＩＤとし（Ｓ１１）、その注目ＩＤに対応するレコードを派生関係ＤＢ１１０から取得する（Ｓ１２）。そして、そのレコード中の「公開」属性の値が「１」であるか否かを判定し（Ｓ１３）、「１」であれば、そのレコードを中間結果リストに入れる（Ｓ１４）。中間結果リストは、要求された処理の処理結果を求めるための材料となる情報を蓄積するためにクライアント端末２０の記憶装置上に構築されるリストである。「公開」属性が「１」でなければ、ステップＳ１４はスキップされる。そして、要求処理部１４０は、注目ＩＤの子ＩＤを検索し（Ｓ１５）、子ＩＤが検索できたか否かを判定する（Ｓ１６）。子ＩＤがあれば、要求処理部１４０は、それら各子ＩＤについて、それぞれ子孫探索処理（Ｓ６）を再帰的に実行する。すべての子ＩＤについての子孫探索処理が終了すると、当該注目ＩＤについての処理が終了する。ステップＳ１６で子ＩＤがないと判定された場合も、当該注目ＩＤについての処理は終了する。
【００７３】
図８の手順に戻り、根のＩＤ付き文書のすべての子ＩＤについて子孫探索処理（Ｓ６）が終了すると、そのときの中間結果リストには、その根から派生するすべてのＩＤ付き文書の中で、「公開」属性が「１」であるものに対応するレコードがすべて蓄積されていることになる。要求処理部１４０は、中間結果リストに蓄積されたレコード群の中から、検索条件を満足するレコードを求める（Ｓ７）。そして、求めたレコードに対応するＩＤ付き文書を、要求に対する検索結果として、要求元のユーザ（この例ではuser2）に提供する（Ｓ８）。
【００７４】
例えば、図６の例では、ステップＳ６の処理により、中間結果リスト中には管理ＩＤが"Doc4"、"Doc6"の２つのレコードが蓄積される。そして、例えば、検索条件が「操作日時が最新の文書」という条件であれば、中間結果リストの中で操作日時が最新である文書"Doc6"が検索結果として要求元のuser2に提供される。
【００７５】
ステップＳ７で、検索結果として複数のＩＤ付き文書が得られた場合、それら複数の文書すべてを要求元のユーザに返せばよい。またこの代わりに、検索結果のＩＤ付き文書のリストをユーザに返し、ユーザがその中から所望のものを選択して取得するようにしてもよい。
【００７６】
以上に説明したように、本実施形態では、特定の操作種別に該当する操作の結果の文書しか公開されない。また、どの操作種別の操作結果を公開対象とするかは、各クライアント端末２０の各文書操作部２００ごとに個別に設定できるので、各クライアント端末又は各文書操作部２００の事情に応じて操作結果の公開・非公開を制御できる。
【００７７】
次の、変形例を説明する。上記実施形態では、要求処理部１４０は、サービス要求中の管理ＩＤが所属する木全体に対して検索を行った。これに対し、この変形例では、文書操作部２００が行った操作の種別に応じて検索の境界を設定し、それら境界で区切られた範囲内で検索を行う。
【００７８】
説明のための事例として、図１０及び図１１に示すような派生関係を考える。この派生関係は、図５及び図６に示した状態の後、更に以下のような操作が加えられたときの状態を示している。
【００７９】
すなわち、図５及び図６に示された状態の後、user3がＩＤ付き文書"Doc6"を印刷して印刷結果の紙文書をuser5に配布する。この印刷により、ＩＤ付き文書"Doc7"が生成され、文書管理サーバ１０に登録される。次にuser5がuser3から受け取った紙文書の内容を確認してスキャナにセットし、「承認版として登録」の操作を行う。これによりスキャン結果の画像を含むＩＤ付き文書"Doc8"が生成され、文書管理サーバ１０に登録される。そしてuser5がそのＩＤ付き文書"Doc8"を開いて編集を加え、「更新版として登録」操作を行うと、ＩＤ付き文書"Doc9"が生成され、文書管理サーバ１０に登録される。図１０及び図１１に示す派生関係は、この時点の状態である。この例では、図５及び図６の例と同様、スキャンした画像を「承認版として登録」する操作、及び電子文書の編集結果を「更新版」として登録する操作は、共に「公開」属性の値が「１」となる操作であるとする。
【００８０】
また、この例では、派生関係の木構造の中に検索境界を設定可能としている。要求処理部１４０は、受け取ったサービス要求中の管理ＩＤを起点に木を走査する際、検索境界より先祖にも子孫にも走査は進めない。このように、この変形例では、検索範囲をサービス要求中の管理ＩＤを含んだ木全体とするのではなく、その木を検索境界によって区切ってできる各部分木のうち、その管理ＩＤを含んだ部分木のみを検索範囲とする。この変形例では、文書に対して特定の種別の操作が行われた場合に、操作前の文書と操作結果の文書との間を検索境界に設定する。
【００８１】
検索境界を表すため、図示例では、ＩＤ付き文書のメタ情報に「境界」属性を組み込んでいる。ある文書の「境界」属性の値が「１」であれば、その文書とその親との間が検索境界であることを示す。ある文書の「境界」属性の値が「０」であれば、その文書とその親とは同じ検索範囲に属する。どのような種別の操作の結果を検索境界とするかは、文書操作部２００にあらかじめ登録されている。図１０及び図１１の例では、「登録」操作と（電子的なＩＤ付き文書に対する）「更新版として登録」操作が、検索境界を生み出す操作種別として設定されており、文書"Doc1"、"Doc6"及び"Doc9"の「境界」属性が「１」となっている。そのように登録された種別の操作を行った場合、文書操作部２００は、その操作結果のＩＤ付き文書の「境界」属性を「１」にセットする。そうでなければ、「境界」属性の値を「０」とするか、又は「境界」属性自体を省略する。
【００８２】
例えば、ＩＤ付き文書"Doc9"のメタ情報レコードは、以下の例３に示すようなものとなる。
【００８３】
[例３]
<metadata sid="Doc9" pid="Doc8" date="2006-10-03T14:34" method="update" filename="aaa_v2.doc" user="user5" shared="1" unrelated="1"/>
【００８４】
この例において、unrelated属性が「境界」属性である。なお、紙文書を読み取って「承認版として登録」する操作と、電子的なＩＤ付き文書を「更新版として登録」する操作は、上記実施形態の例では、ログ記録上の操作種別では同じ「更新」に分類されているが、この変形例では、そのような分類の操作でも、「境界」属性の判別においては区別している。すなわち、この例では、紙文書を読み取って「承認版として登録」する操作に対応する「境界」属性の値は「０」である。例えば、ＩＤ付き文書"Doc8"の「境界」属性値は「０」となっている。この変形例では、「境界」属性の判定は、文書操作部２００での操作の種別に基づき行っているといえる。なお、これはあくまで一例であり、ログ記録上の操作種別に従って判定してもよい。
【００８５】
これら図１０及び図１１に示した状態の時に、user3が、例えば図７に例示したようなユーザインタフェース画面を介して、ＩＤ付き文書"Doc7"を対象として「最新フォーム取得」の要求を行ったとする。このような場合を例にとって、「最新フォーム取得」の要求を受けたときの、要求処理部１４０の処理手順の例を説明する。
【００８６】
この場合、要求処理部１４０は、例えば図１２及び図１３に示す手順に従って、最新フォームを求める。図１２の手順では、要求処理部１４０は、まず、クライアント端末２０から受け取った要求に処理対象として含まれる管理ＩＤを注目ＩＤにセットし（Ｓ１）、派生関係ＤＢ１１０からその注目ＩＤに対応するレコードを取得する（Ｓ２）。次にそのレコード中の「境界」属性の値が「１」であるか否かを調べ（Ｓ３Ａ）、「１」でなければ、注目ＩＤの値をそのレコード中の親ＩＤの値へと置き換え（Ｓ４）、ステップＳ１〜Ｓ３Ａの処理を繰り返す。
【００８７】
ステップＳ３Ａの判定結果がＹｅｓとなった場合、要求中の管理ＩＤから派生関係を遡り、直近の検索境界のノードにたどり着いたことになる。このノードが、今回の検索の範囲である部分木の根である。要求処理部１４０は、そのときの注目ＩＤ（すなわち部分木の根）の公開属性を調べ（Ｓ９）、公開属性の値が「１」であればその注目ＩＤに対応するレコードを中間結果リストに入れ（Ｓ１０）、ステップＳ５に進む。ステップＳ９で注目ＩＤに対応する公開属性が「１」でなければ、ステップＳ１０を飛ばしてステップＳ５に進む。ステップＳ５では、注目ＩＤの子ＩＤを検索する。そして、要求処理部１４０は、それら子ＩＤごとに、図１３に示すような子孫探索処理を実行する（Ｓ６）。
【００８８】
子孫探索処理（Ｓ６）では、要求処理部１４０は、当該子ＩＤを注目ＩＤとし（Ｓ１１）、その注目ＩＤに対応するレコードを派生関係ＤＢ１１０から取得する（Ｓ１２）。そして、そのレコード中の「境界」属性の値が「１」であるか否かを判定する（Ｓ２０）。その「境界」属性の値が「１」であれば、部分木の走査において子孫方向の検索境界に達したことになるので、当該注目ＩＤについての図１３の処理を終了する。「境界」属性の値が「１」でなければ、更に「公開」属性の値が「１」であるか否かを判定する（Ｓ１３）。ステップＳ１３の判定結果がＹｅｓの場合、要求処理部１４０は、そのレコードを中間結果リストに入れる（Ｓ１４）。ステップＳ１３の判定結果がＮｏであれば、ステップＳ１４はスキップされる。そして、要求処理部１４０は、注目ＩＤの子ＩＤを検索し（Ｓ１５）、子ＩＤが検索できたか否かを判定する（Ｓ１６）。子ＩＤがあれば、要求処理部１４０は、それら各子ＩＤについて、それぞれ子孫探索処理（Ｓ６）を再帰的に実行する。すべての子ＩＤについての子孫探索処理が終了した場合、又はステップＳ１６で子ＩＤがないと判定された場合、当該注目ＩＤについての処理が終了する。
【００８９】
図１２の手順に戻ると、ステップＳ３Ａで特定された部分木の根のすべての子ＩＤについて子孫探索処理（Ｓ６）が終了すると、そのときの中間結果リストには、その部分木に属し、「公開」属性が「１」であるＩＤ付き文書がすべて蓄積されていることになる。要求処理部１４０は、中間結果リストに蓄積されたレコード群の中から、検索条件である「最新の」レコードを求め（Ｓ７）、このレコードに対応するＩＤ付き文書を検索結果として要求元のユーザに返す（Ｓ８）。
【００９０】
例えば、図１０の例において、ＩＤ付き文書"Doc7"を対象として「最新フォーム取得」の要求がなされた場合、ステップＳ１〜Ｓ４のループにより、検索範囲の部分木の根となる"Doc6"が特定される。更にステップＳ９以下の処理により、中間結果リスト中には管理ＩＤが"Doc6"、"Doc8"の２つのレコードが蓄積される。ＩＤ付き文書"Doc9"は、「公開」属性値は「１」であるが、「境界」属性値も「１」なので、ステップＳ２０により、中間結果リストには蓄積されない。中間結果リストに蓄積されたレコードのうち最新のレコードに対応するＩＤ付き文書"Doc8"がステップＳ８で検索結果として求められる。
【００９１】
以上に説明した変形例によれば、文書に対する操作に応じて、操作前の文書と操作結果の文書との間に検索境界を設定することができる。検索境界を設定するということは、操作前の文書と操作結果の文書とを、別系統の文書として取り扱うことと捉えることもできる。また、上記変形例では、また、どの操作種別の操作に応じて検索境界を設定するか否かを、各クライアント端末２０の各文書操作部２００ごとに個別に設定できるので、各クライアント端末又は各文書操作部２００の事情に応じて検索境界を制御できる。
【００９２】
以上に例示した実施形態及び変形例では、管理ＩＤの発行は各クライアント端末２０で行われていたが、この代わりに文書管理サーバ１０が管理ＩＤを発行してもよい。この場合、クライアント端末２０は、ＩＤ付き文書に対して操作を行った場合、操作前のＩＤ付き文書内の管理ＩＤを親ＩＤ３１４として含み、更にその操作についてのログ情報３１６と操作後の文書内容３２０とを含み、管理ＩＤ３１２は空欄の文書データを生成し、文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書データに対して新たな管理ＩＤを付与し、この管理ＩＤとその文書データとに含まれる情報を、文書ＤＢ１００及び派生関係ＤＢ１１０に登録する。また、文書管理サーバ１０は、付与した管理ＩＤを当該文書データにセットすることによりＩＤ付き文書を生成し、これをクライアント端末２０に返す。クライアント端末２０は、操作前のＩＤ付き文書を、受け取ったＩＤ付き文書に置き換える。このように、文書管理サーバ１０が管理ＩＤを付与する構成でも、上述実施形態及び変形例の処理は同様に実行できる。
【００９３】
また以上の実施形態及び変形例では、管理ＩＤ３１２、親ＩＤ３１４、ログ情報３１６、及び文書内容３２０を含んだＩＤ付き文書３００がクライアント端末２０に保存されたが、この代わりに、クライアント端末２０は管理ＩＤしか持たず、その他の情報は文書管理サーバ１０に保存されるようにしてもよい。この場合、クライアント端末２０で文書を操作する場合、その文書に対応する管理ＩＤを文書管理サーバ１０に送り、文書管理サーバ１０からその文書を取得する。また、別の例として、クライアント端末２０が保持するＩＤ付き文書３００の中には管理ＩＤ３１２と文書内容３２０とが含まれ、親ＩＤ３１４及びログ情報３１６は含まれないようにしても良い。この場合、サーバがその管理ＩＤ３１２に対応づけて親ＩＤ３１４とログ情報３１６を持つようにすれば良い。
【００９４】
ここで、文書管理サーバ１０が管理ＩＤを付与する場合は、その取得の操作に対応する管理ＩＤを文書管理サーバ１０が生成し、その管理ＩＤと文書とを対応づけてクライアント２０に提供するとともに、その取得操作についてのログ情報（操作時刻や操作者など）と、元の管理ＩＤ（すなわち親ＩＤ）と、付与した管理ＩＤとを派生関係ＤＢ１１０に記録する。クライアント端末２０は、文書管理サーバ１０に送信した管理ＩＤを、受け取った管理ＩＤに置き換えると共に、受け取った文書を開く。ユーザは、開かれた文書に対して閲覧や編集などの操作を行う。クライアント端末２０は、文書に対する操作が完了すると、操作後の文書を管理ＩＤ及び当該操作についてのログ情報と共に文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書に対して新たな管理ＩＤを付与して派生関係ＤＢ１１０に登録し、受け取った管理ＩＤを親ＩＤとして派生関係ＤＢ１１０に登録する。また、受け取ったログ情報及び操作後の文書を、派生関係ＤＢ１１０及び文書ＤＢ１００に登録する。そして、文書管理サーバ１０は、新たに付与した管理ＩＤをクライアント端末２０に返す。クライアント端末２０は、元の管理ＩＤを受け取った管理ＩＤで置き換える。以上のような処理により、操作間の派生関係が文書管理サーバ１０に蓄積されることになる。
【００９５】
一方、クライアント端末２０が管理ＩＤを付与する構成の場合は、文書管理サーバ１０は、クライアント端末２０から受け取った管理ＩＤに対応する文書をクライアントに返せばよい。クライアント端末２０は受け取った文書を開き、ユーザがその文書を操作する。操作の完了後、クライアント端末２０はその操作結果の文書に対して新たな管理ＩＤを付与し、この管理ＩＤを含んだ前述のＩＤ付き文書と同様の情報を、文書管理サーバ１０に送る。そして、クライアント端末２０は、そのＩＤ付き文書のうち管理ＩＤのみを保存し、その他の情報を削除する。
【００９６】
以上に例示したシステムにおける文書管理サーバ１０は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図１４に示すように、ＣＰＵ（中央演算装置）４０、メモリ（一次記憶）４２、各種Ｉ／Ｏ（入出力）インタフェース４４等がバス４６を介して接続された回路構成を有する。また、そのバス４６に対し、例えばＩ／Ｏインタフェース４４経由で、ハードディスクドライブ４８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ５０が接続される。このようなドライブ４８又は５０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ４８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。クライアント端末２０についても同様である。
【図面の簡単な説明】
【００９７】
【図１】文書利用管理システムの概略構成の例を示すブロック図である。
【図２】クライアント端末の内部構成の例を示すブロック図である。
【図３】ＩＤ付き文書のデータ構造の例を模式的に示す図である。
【図４】文書管理サーバの内部構成の例を示すブロック図である。
【図５】派生関係ＤＢのデータ内容の例を示す図である。
【図６】図５に例示したデータ内容における管理ＩＤ群がなす木構造を図式化して表す図である。
【図７】ＩＤ付き文書のアイコンを表示した表示画面の例を示す図である。
【図８】サービス要求に対する要求処理部の処理手順の一例の一部を示すフローチャートである。
【図９】サービス要求に対する要求処理部の処理手順の一例の残りの部分を示すフローチャートである。
【図１０】変形例における派生関係ＤＢのデータ内容の例を示す図である。
【図１１】図１０に例示したデータ内容における管理ＩＤ群がなす木構造を図式化して表す図である。
【図１２】最新フォーム取得要求に対する要求処理部の処理手順の一例の一部を示すフローチャートである。
【図１３】最新フォーム取得要求に対する要求処理部の処理手順の一例の残りの部分を示すフローチャートである。
【図１４】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【００９８】
１０ 文書管理サーバ、２０ クライアント端末、３０ ネットワーク、１００ 文書ＤＢ、１１０ 派生関係ＤＢ、１３０ 文書登録部、１３２ 派生関係登録部、１４０ 要求処理部、２００ 文書操作部、２０２ ＩＤ割り当て部、２０４ 派生関係組込部、２１０ 登録処理部、３００ ＩＤ付き文書。
【技術分野】
【０００１】
文書管理装置、情報処理装置、文書管理システム及びプログラムに関する。
【背景技術】
【０００２】
テキスト文書データや音声データ、マルチメディアデータなどの電子文書（以下単に文書とも呼ぶ）をサーバに登録し、ユーザの要求に応じてその文書を提供することが行われている。また、電子文書に対して一意な識別子を付与し、ユーザが入力した識別子に対応する電子文書を提供するシステムも知られている。また、別の公知のシステムでは、電子文書を紙に印刷する場合に、電子文書の識別子をコード化して紙文書に埋め込み、紙文書を複写する際にその紙文書に埋め込まれた識別子を認識し、その識別子に対応した電子文書を取得し、紙に印刷する。
【０００３】
特許文献１に開示されたシステムは、コンテンツコピー機は、コンテンツＩＤが埋め込まれたコンテンツのコピー原稿からコンテンツＩＤを読み取り、読み取ったコンテンツＩＤとコピーイベント属性の情報とをネットワークを介してコンテンツＩＤ管理センタへ送信する。コンテンツＩＤ管理センタは、受信したコンテンツＩＤからそのコンテンツの原本を取得し、新しいコンテンツＩＤを付与して、そのコンテンツＩＤとコピーイベント属性の情報とを記録し、その新しいコンテンツＩＤをコンテンツの原本に対して埋め込んでコピー要求元へ返す。コンテンツコピー機は、それをコピー結果として出力する。このシステムにおいて、コンテンツＩＤ管理センタは、コンテンツコピー機から受信したコンテンツＩＤに応じて、新たなコンテンツＩＤを発行した場合、その新しいコンテンツＩＤコピー元が前述の受信したコンテンツＩＤであることを記録する（例えば特許文献１の第４１段落末尾）。
【０００４】
特許文献２に開示されたシステムでは、電子文書を紙に印刷する場合、電子文書の文書識別子を埋め込んで印刷する。そして、紙文書が入力された場合、システムはその紙文書から文書識別子を抽出し、その文書識別子に対応する電子文書をダウンロードして印刷する。また、このシステムでは、ダウンロードされた電子文書が更新された場合、更新された電子文書を新しい文書識別子に対応づけて登録し、その新しい文書識別子を埋め込んだ紙文書を印刷する。
【０００５】
特許文献３に開示されたシステムでは、紙文書に対する手書きによる編集を、直接的に電子文書に反映し、電子文書の更新された版の系列を、電子文書をノードとする木構造として保持する。文書やファイルをノードとし、文書やファイルの更新によって生成される版を、枝分かれした版として管理する事ができる文書履歴木の例も開示されている。このようなバージョン管理システムは、CVS（Concurrent Versions System)として広く知られている。また、特許文献３には、電子文書の更新に関する履歴を、更新前の電子文書を親とし、更新後の電子文書を子とするように文書履歴木を管理する方法が開示されている。
【０００６】
特許文献４に開示されたシステムでは、端末装置は、コンテンツＩＤが埋め込まれたコンテンツの複製物またはその一部から、コンテンツＩＤを読み取り、そのコンテンツＩＤと検索補助情報とをコンテンツＩＤ管理センタへ送信する。コンテンツＩＤ管理センタは、コンテンツＩＤと検索補助情報とを受け取ると、そのコンテンツＩＤに対応するコンテンツの原本もしくはそれに関連するコンテンツを端末装置へ返送する。
【０００７】
【特許文献１】特許第３３８３７９３号明細書
【特許文献２】特開２００６−０５３６８６号公報
【特許文献３】特開２００５−１３５２１１号公報
【特許文献４】特開２００２−０１４９７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、文書に対して操作が行われた場合に操作前の文書から操作後の文書が派生したことを示す派生関係を記録し、指定された文書に対して派生関係のある文書をその記録に基づき求めて提供するサービスが考えられる。しかしながら、派生関係に従って導き出される文書を無制限に提供したのでは、不都合な文書まで開示される可能性がある。
【０００９】
本発明は、派生関係に基づき文書を検索し提供する場合に、提供する文書を制限するための技術を提供する。
【課題を解決するための手段】
【００１０】
請求項１に係る発明は、情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する検索結果提供部と、を備える文書管理装置である。
【００１１】
請求項２に係る発明は、請求項１に係る発明において、前記登録部は、更に前記第２の文書と前記第１の文書との間が検索境界であるか否かを示す検索境界情報を前記情報処理装置から受け取って前記第２の文書と対応づけて前記記憶部に登録し、前記検索結果提供部は、前記派生関係群がなす木群の中の前記検索境界で区切られる部分木群のうち前記対象文書の属する部分木に属する文書の中で、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する、ことを特徴とする。
【００１２】
請求項３に係る発明は、情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録するステップであって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録するステップと、対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供するステップと、をコンピュータに実行させるためのプログラムである。
【００１３】
請求項４に係る発明は、文書に対する操作を実行する操作実行部と、操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、を備える情報処理装置である。
【００１４】
請求項５に係る発明は、文書に対する操作を実行する操作実行部と、操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、してコンピュータを機能させるためのプログラムである。
【００１５】
請求項６に係る発明は、情報処理装置と文書管理装置とを備え、前記情報処理装置は、文書に対する操作を実行する操作実行部と、操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、を備え、前記文書管理装置は、前記情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録する登録部であって、前記第１の文書が前記記憶部既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する検索結果提供部と、を備える。
【発明の効果】
【００１６】
請求項１に係る発明によれば、情報処理装置からの開示属性情報に応じて、操作の結果の文書を検索結果として提供するか否かを制御することができる。
【００１７】
請求項２に係る発明によれば、更に、情報処理装置からの検索境界情報に応じて、検索指示に対する検索範囲を限定することができる。
【００１８】
請求項３に係る発明によれば、情報処理装置からの開示属性情報に応じて、操作の結果の文書を検索結果として提供するか否かを制御することができる。
【００１９】
請求項４に係る発明によれば、文書に対して実行した操作に応じて、その操作結果の文書を開示して良いか否かを文書管理装置に指示することができる。
【００２０】
請求項５に係る発明によれば、文書に対して実行した操作に応じて、その操作結果の文書を開示して良いか否かを文書管理装置に指示することができる。
【００２１】
請求項６に係る発明によれば、情報処理装置からの開示属性情報に応じて、操作の結果の文書を検索結果として提供するか否かを制御することができる。
【発明を実施するための最良の形態】
【００２２】
図１は、文書利用管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。
【００２３】
クライアント端末２０について図２を用いて説明する。クライアント端末は、ユーザが文書を操作するために用いる端末であり、パーソナルコンピュータ、デジタル複合機などがその一例である。クライアント端末２０は、図２に示すように、文書操作部２００及び登録処理部２１０を備える。
【００２４】
文書操作部２００は、文書に対する操作を実行する手段である。文書に対する操作には、例えば、文書の表示（ユーザから見れば「閲覧」）、編集、印刷出力、紙文書の読み取り、紙文書の複写、等がある。図では、文書操作部２００を１つだけ示したが、それら個々の操作を別々の操作部（例えば、編集用のアプリケーション、読取制御用のアプリケーションなど）が担当してもよい。例えば、文書操作部２００がワードプロセッサ等の電子文書を作成・編集するためのソフトウエアであれば、文書操作部２００は、ユーザの指示に応じて電子文書を表示したり、電子文書に編集を加えたりする。文書操作部２００は、文書に対して操作を行った場合、その操作の結果を表すＩＤ付き文書３００を出力する。
【００２５】
ＩＤ付き文書３００は、図３に示すように、メタ情報３１０と文書内容３２０を含んだ電子文書である。文書内容３２０は、文書操作部２００の操作の結果生成された文書の内容データである。文書操作部２００が電子文書を作成・編集するためのソフトウエアであれば、文書内容３２０はそのソフトウエアによる編集の結果生成される文書ファイルである。また、文書操作部２００が電子文書を印刷する装置であれば、文書内容３２０は、例えば、印刷される電子文書の内容データとすればよい。また、文書操作部２００が紙文書をスキャンする装置又は紙文書を複写する装置であれば、文書内容３２０は、例えば、その紙文書を読み取って得られる画像データとすればよい。
【００２６】
メタ情報３１０は、文書管理のための情報であり、管理ＩＤ３１２，親ＩＤ３１４，及びログ情報３１６を含む。
【００２７】
管理ＩＤ３１２は、当該ＩＤ付き文書３００自体の一意な識別情報である。親ＩＤ３１４は、当該ＩＤ付き文書３００の親のＩＤ付き文書の管理ＩＤである。すなわち、本実施形態では、あるＩＤ付き文書と、このＩＤ付き文書に対して操作を加えた結果得られる新たなＩＤ付き文書とを、親と子の関係として取り扱う。第１のＩＤ付き文書を操作して第２のＩＤ付き文書が得られた場合、第１のＩＤ付き文書は第２のＩＤ付き文書の親であり、第２のＩＤ付き文書は第１のＩＤ付き文書の子である。したがって、例えば、管理ＩＤ「Ａ」のＩＤ付き文書を文書操作部２００で操作して、その結果得られた新たなＩＤ付き文書の管理ＩＤが「Ｂ」である場合、後者のメタ情報３１０における管理ＩＤ３１２は「Ｂ」であり、親ＩＤ３１４は「Ａ」である。このような親子の関係を、以下では「（管理ＩＤの）派生関係」という。
【００２８】
なお、本システムに未登録の電子文書を新たに登録する操作を実行した場合や、未登録の紙文書をスキャン又は複写する操作を実行した場合（この場合、紙文書を読み取った画像を文書内容とするＩＤ付き文書が生成され、本システムに登録される）に生成されるＩＤ付き文書３００では、親ＩＤ３１４は空（すなわち、親は存在しない）となる。
【００２９】
ログ情報３１６は、当該ＩＤ付き文書が生成された際の操作についての、各種のログ項目の情報である。ログ項目には、例えばその操作が行われた日時、その操作の種別、その操作を指示したユーザ（操作者）などがあるが、もちろんこれに限るものではない。操作の種別には、例えば登録（本システムに新規の文書を登録すること）、閲覧、編集、更新（更新版の登録）、印刷、スキャン、紙文書の複写、等がある。例えば、ユーザが文書操作部２００を用いて第１のＩＤ付き文書に対して編集を加え、編集完了の指示を行った場合、その結果生成される第２のＩＤ付き文書のログ情報３１６は、編集完了の日時と、その編集を指示したユーザの識別情報と、操作の種別として「編集」と、を含んだものとなる。
【００３０】
ここでログ情報３１６に組み込まれる操作の種別は、ログ記録の目的での分類に従った種別であり、文書操作部２００が実行する操作の種別そのものでなくてもよい。例えば、文書操作部２００が実行する複数の操作の種別を、同じ１つのログ記録目的の操作種別に対応づけてもよい。例えば、文書編集アプリケーション上でＩＤ付きの電子文書に編集を加え操作メニュー上で「更新版として登録」を指示した場合も、スキャナで管理ＩＤ付きの紙文書を読み取り読取制御用アプリケーションの操作メニュー上で「読み取った文書を承認版として登録」を指示した場合も、ログ情報３１６に組み込まれる操作種別の値は「更新」となる。
【００３１】
また、ログ情報３１６の中には、当該ＩＤ付き文書３００が公開（共有）対象であるか否かを示す「公開」属性を組み込むこともできる。例えば公開対象とするＩＤ付き文書の「公開」属性値を「１」とし、公開対象としないＩＤ付き文書の「公開」属性値は「０」とすると、「公開」属性が「０」であるＩＤ付き文書は、当該文書を生成するための操作を行った操作者や管理者等の特権的なユーザ以外には、公開されないようにすることができる。
【００３２】
なお、「公開」属性の値は、操作の種別に従って決定する。公開属性値を決める基準となる操作の種別は、文書操作部２００が実行した操作の種別でも、ログ記録目的の分類に従った操作の種別でもよい。いずれを用いるかは、文書操作部２００に設定されていればよい。
【００３３】
文書操作部２００が生成するメタ情報３１０の具体例を以下に示す。
【００３４】
[例１]
<metadata sid="Doc1" date="2006-10-01T10:00" method="register" filename="aaa.doc" user="user1"/>
【００３５】
ここでsid属性は管理ＩＤ、date属性は操作日時、method属性は操作種別である。また、filename属性は当該ＩＤ付き文書のファイル名であり、user属性は操作を指示したユーザのユーザ識別情報である。例１のmethod属性値"register"は（文書管理サーバ１００に未登録の）新規文書の登録操作を示す操作種別名である。新規文書の登録なので、親ＩＤを示すpid属性は省略されている。省略する代わりにpid="null"などと、親ＩＤがないことを示す属性を明示的に組み込んでもよい。また、この例では、新規文書登録により登録された文書は公開対象としないので、公開対象か否かを示すshared属性は省略されている。省略する代わりにshared="0"などと、公開対象でないことを示す属性を明示的に組み込んでもよい。
【００３６】
また、以下に示す例２は、ユーザ識別情報が"user4"であるユーザが、管理ＩＤ"Doc2"が埋め込まれた紙文書をスキャナで読み込んで「承認版として登録」する操作を行った場合に生成されるメタ情報３１０である。
【００３７】
[例２]
<metadata sid="Doc4" pid="Doc2" date="2006-10-01T11:28" method="update" filename="200610011128.jpg" user="user4" shared="1"/>
【００３８】
ここで、method属性値"update"は更新操作を示している。この例では、スキャン画像のファイル名は操作日時を元に自動生成された値である。この例は、更新操作により登録された文書は公開対象とする場合の例であり、shared属性値は公開対象であることを示す値「１」となっている。
【００３９】
なお、文書操作部２００が、操作した文書を暗号化してもよい。この暗号化は、本システムに準拠した文書操作部２００ならば、復号できるようなものとする。この場合、文書操作部２００が出力するＩＤ付き文書３００の文書内容３２０は、暗号化されることにより、本システムに準拠した文書操作部２００でないと復号できなくなる。したがって、ＩＤ付き文書３００が操作される場合には文書操作部２００が用いられるので、文書操作部２００がその操作を検知し、その操作の内容が文書操作部２００から文書管理サーバ１０に通知される。なお、文書内容３２０だけでなく、後述するメタ情報３１０（またはその一部）に対しても暗号化を施してもよい。
【００４０】
図２の説明に戻り、文書操作部２００は、操作結果として上述のようなＩＤ付き文書３００を作成するために、ＩＤ割り当て部２０２及び派生関係組込部２０４を備える。ＩＤ割り当て部２０２は、操作結果のＩＤ付き文書３００に一意な管理ＩＤを付与する手段である。管理ＩＤは、少なくとも本システム内で一意な識別情報である必要がある。例えば、操作の結果生成するＩＤ付き文書３００（ただし管理ＩＤ３１２を除いたもの）のハッシュ値を求め、このハッシュ値をその文書３００のＩＤ付き文書とすればよい。ハッシュ関数としてSHA-256（SHA-256はNISTがFIPS180-2で定めた256ビットのハッシュ値を持つ暗号学的ハッシュ関数である）などのような耐衝突性を持つ暗号学的ハッシュ関数を用いれば、実用上十分な一意性を持つ管理ＩＤを生成することができる。もちろん、システム内で一意な管理ＩＤを各クライアント端末２０で生成する方法は、これに限らない。管理ＩＤを、クライアント端末２０固有の識別情報を含むものとすれば、システム内で一意な管理ＩＤを各クライアント端末２０で生成することができる。
【００４１】
派生関係組込部２０４は、操作結果の文書に対しＩＤ割り当て部２０２が割り当てた新たな管理ＩＤ３１２と、その操作の元になった親文書の管理ＩＤである親ＩＤ３１４（新規登録の場合は、親ＩＤは無し）と、その操作についてのログ情報３１６と、を含むメタ情報３１０を生成する。ここで、派生関係組込部２０４は、文書操作部２００が実行する個々の操作の種別が、ログ記録目的上の操作種別のどれに対応するかを表す対応関係の情報を保持しており、この情報を用いることでログ情報３１６に組み込む操作種別の値を求める。また、派生関係組込部２０４は、操作種別ごとに当該種別の操作の結果である文書を公開対象とするか否かを示す情報を保持しており、この情報に基づきshared属性値を決定する。そして、派生関係組込部２０４は、そのメタ情報３１０を操作結果の文書内容に付加することにより、操作後のＩＤ付き文書３００を生成して出力する。
【００４２】
文書操作部２００がアプリケーションソフトウエアである場合、ＩＤ割り当て部２０２及び派生関係組込部２０４は、そのソフトウエアに対して追加される、いわゆるプラグイン(plug-in)プログラムとして実現してもよい。
【００４３】
登録処理部２１０は、文書操作部２００が出力したＩＤ付き文書３００を文書管理サーバ１０に登録するための処理を実行する。このように各クライアント端末２０が、自ら実行した操作の結果であるＩＤ付き文書３００を文書管理サーバ１０に登録することにより、文書管理サーバ１０は各ＩＤ付き文書３００間の派生関係を把握することができる。
【００４４】
文書操作部２００が操作の結果出力するＩＤ付き文書３００は、通常の文書ファイルと同様、電子的にコピーしたり、電子メールに添付するなどの方法で他の人宛に送信したりすることができる。電子メール送信用のソフトウエアは、この例では本システムに準拠していないので、この送信操作はＩＤ付き文書には反映されず、したがって文書管理サーバ１０にも記録されない。他の人からＩＤ付き文書３００を受け取った人が、自分のクライアント端末２０の文書操作部２００を用いてそのＩＤ付き文書３００を操作すると、その操作に応じて新たな管理ＩＤを付与されたＩＤ付き文書が生成されることになる。
【００４５】
また、文書操作部２００が電子文書を印刷する場合、管理ＩＤを生成し、その電子文書の印刷結果にその管理ＩＤを埋め込んでもよい。管理ＩＤの埋め込みは、例えば電子文書の印刷画像に、管理ＩＤを示すコード画像を重畳する等の方法で行うことができる。また、用紙がＲＦＩＤ(Radio Frequency Identifier)タグを備えている場合、そのＲＦＩＤタグに管理ＩＤを書き込んでもよい。このように印刷を行った場合、文書操作部２００は、その管理ＩＤや操作種別「印刷」等のメタ情報を含んだＩＤ付き文書を文書管理サーバ１０に登録する。なお、ＩＤ付き文書を印刷した場合には、そのＩＤ付き文書の管理ＩＤを親ＩＤ３１４として含んだＩＤ付き文書が生成される。印刷操作に対応するＩＤ付き文書には、印刷された画像を示すページ記述言語データやビットマップ画像データをなどの印刷データ、又は印刷された文書ファイルを、文書内容３２０として組み込んでもよい。
【００４６】
また、管理ＩＤが埋め込まれた紙文書を文書操作部２００が読み取った場合、文書操作部２００は、その読み取り操作に対して新たな管理ＩＤを付与し、読み取り結果の画像を文書内容３２０として含んだＩＤ付き文書を生成して文書管理サーバ１０に登録する。このＩＤ付き文書の親ＩＤ３１４には、紙文書から読み取った管理ＩＤがセットされる。管理ＩＤが埋め込まれた紙文書の複写の際には、上述した読み取り時と印刷時の処理が実行される。
【００４７】
次に、文書管理サーバ１０について説明する。文書管理サーバ１０は、システム内の複数のクライアント端末２０から送られてくるＩＤ付き文書３００を蓄積し、蓄積した情報に基づきユーザに各種のサービスを提供する。図４に示すように、文書管理サーバ１０は、文書ＤＢ１００，派生関係ＤＢ１１０，文書登録部１３０，要求処理部１４０を備える。
【００４８】
文書ＤＢ１００は、クライアント端末２０から送られてきたＩＤ付き文書３００のうちの文書内容３２０を格納するデータベースである。文書ＤＢ１００に格納された各文書内容３２０は、一意な内容ＩＤにより管理してもよい。内容ＩＤとしては、例えば当該文書内容の暗号学的ハッシュ関数によるハッシュ値を用いてもよいが、これに限定されるものではない。クライアント端末２０が内容ＩＤを付与してもよく、この場合、内容ＩＤをメタ情報３２０に組み込んでもよい。また、内容ＩＤの代わりに、その文書内容３２０を、当該文書内容に対応するＩＤ付き文書３００の管理ＩＤと対応づけて文書ＤＢ１００に格納してもよい。
【００４９】
文書登録部１３０は、クライアント端末２０から受信したＩＤ付き文書の中の文書内容を文書ＤＢ１００に、メタ情報を派生関係ＤＢ１１０に、それぞれ登録する。そのうち、メタ情報の登録を担当するのが派生関係登録部１３２である。
【００５０】
派生関係ＤＢ１１０は、そのようなＩＤ付き文書３００のうち、派生関係の情報を主としたメタ情報を蓄積するデータベースである。図５に、派生関係ＤＢ１１０のデータ内容の一例を示す。図５に示した表における１行の情報が、１つのＩＤ付き文書３００に対応するメタ情報レコードである。この例では、各ＩＤ付き文書３００の管理ＩＤに対応づけて、親ＩＤ、ノードアドレス、操作種別、操作者、操作日時、「公開」属性及び、文書格納パス、の各項目が登録されている。このうち、管理ＩＤと親ＩＤのペア以外の項目は、例示したものに限られない。管理目的上必要な項目を記録すればよい。また、操作種別、操作者、操作日時、及び公開属性については既に説明した。ノードアドレスは、ＩＤ付き文書間の派生関係が構成する木において、当該管理ＩＤ（ＩＤ付き文書）に対応するノードの位置を示している。ノードアドレスの表記において「／」が木の深さ階層の区切りを示し、番号が同じ親から派生した兄弟同士の間での順番を示す。例えばノード「／１」は新規文書登録の操作により登録された文書に対応する根ノードを示す。また、ノード「／１／１」は根ノード「／１」の１番目の子、ノード「／１／２」は根ノード「／１」の２番目の子を示す。なお、煩雑さを避けるため、図５には、１つの根ノード「／１」から派生した１つの木に属するメタ情報レコード群しか示していないが、文書管理サーバ１０には、例えば根「／１」から派生する木と根「／２」から派生する木のように、複数の木のメタ情報レコード群が登録され得る。文書格納パスは、文書内容３２０の文書ＤＢ１００内での格納場所を示すパス名である。図５の例では、文書内容は、Ｅドライブの「\doc」というフォルダに、date属性（操作日時）の後にfilename属性（ファイル名）を続けたファイル名で登録されている。なお、文書ＤＢ１００が、内容ＩＤで文書内容３２０を検索する機能を持つものであれば、文書格納パスの代わりに内容ＩＤをメタ情報レコードに登録しておけばよい。
【００５１】
なお、図５は派生関係ＤＢ１１０が管理するデータを内容の観点から表現したものにすぎず、具体的な表現形式或いはデータベース形式を規定するものではない。例えば、派生関係ＤＢ１１０は、一般的なリレーショナルデータベースとして構築することもできるし、管理ＩＤを除くメタ情報を記述したＸＭＬ(eXtensible Markup Language)文書を、管理ＩＤをキーとして登録したデータベースとして構築することもできる。
【００５２】
図５に示した派生関係ＤＢ１１０のデータ内容は、図６のような木構造を成す。これは、管理ＩＤをノードとし、管理ＩＤ間の親子関係をエッジとする木構造である。
【００５３】
図５〜図６の例が示す文書の履歴を時系列順に説明すると、以下のようになる。この例は、あるユーザが申請書等のフォーム（ひな形文書）を本システムに登録し、他のユーザがそのフォームに対して記入を行い、記入済みフォームを本システムに登録する業務の流れを表している。
【００５４】
この例ではまず、文書（フォーム）の「登録」操作がuser1のクライアント端末で実行される。「登録」操作は、文書管理サーバ１０に未登録の文書（すなわち、管理ＩＤを有していない文書）を当該サーバ１０に登録するための操作である。この操作に応じて管理ＩＤが"Doc1"、親ＩＤが空、操作種別が「登録」であるメタ情報と、その文書の文書内容とを含むＩＤ付き文書"Doc1"がuser1のクライアント端末から文書管理サーバ１０に送られる。ここで、「登録」操作は、「公開」の対象にはなっていないので、メタ情報中には「公開」属性の値は含まれない。これに応じ、文書管理サーバ１０は、そのＩＤ付き文書"Doc1"中の文書内容を文書ＤＢ１００へ、メタ情報を派生関係ＤＢ１１０にそれぞれ登録する。ここで、文書管理サーバ１０は、操作種別が「登録」であり、親ＩＤが空なので、当該ＩＤ付き文書が、文書管理サーバ１０内に既に登録済みのＩＤ付き文書の子ではなく、新たな木の根（始祖）であると判断し、それに従ってノードアドレスの値（この例では「／１」）を設定する。なお、以下では、識別のために、登録された文書内容を"Content1"で表すことにする。その後、user1は、登録したＩＤ付き文書を他のユーザuser2，user3，・・・に配布する。この配布は、例えば、電子メールにそのＩＤ付き文書を添付して各ユーザに送信することにより、行うことができる。
【００５５】
その後、他のユーザuser2が自分のクライアント端末の文書操作部２００でＩＤ付き文書"Doc1"を印刷する。印刷されるのは文書内容"Content1"、又はそれに編集を加えた結果の文書内容である。このとき文書操作部２００は、印刷結果の紙文書に対して新たに付与した管理ＩＤ"Doc2"を埋め込む。このように管理ＩＤが埋め込まれた紙文書をＩＤ付きの紙文書と呼ぶことにする。また、クライアント端末は、印刷の結果としてＩＤ付き文書"Doc2"を生成し、文書管理サーバ１０に登録する。このＩＤ付き文書のメタ情報における管理ＩＤは"Doc2"であり親ＩＤは"Doc1"である。また操作者はuser2であり。操作種別は印刷である。また、「印刷」操作は、「公開」の対象にはなっていないので、そのＩＤ付き文書のメタ情報中には「公開」属性の値は含まれない。文書管理サーバ１０は、受け取ったＩＤ付き文書の親ＩＤの値から、当該文書"Doc2"が文書"Doc1"の子であることを認識し、しかも最初の子であるので、文書"Doc2"のノードアドレスを「／１／１」とする。
【００５６】
なお、この操作の前にuser2のクライアント端末２０内にあったＩＤ付き文書"Doc1"は、この操作に伴い、派生関係組込部２０４によりＩＤ付き文書"Doc2"に置き換えられる。この置き換え処理では、派生関係組込部２０４は、元のＩＤ付き文書"Doc1"のうち、メタ情報３１０の管理ＩＤ３１２を新たに発行したＩＤ"Doc2"へ変更すると共に、元の文書"Doc1"の管理ＩＤ"Doc1"を親ＩＤ３１４の値にセットする。また、派生関係組込部２０４は、ログ情報３１６中の操作種別の値を今回の操作の種別である「印刷」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser2に変更する。また、文書内容３２０は、印刷指示をされた時点の文書内容を示す印刷データ又は文書ファイルとなる。
【００５７】
このようにＩＤ付き文書"Doc1"は、閲覧されると、閲覧後のＩＤ付き文書"Doc2"に置き換えられる。したがって、その置き換えの後は、ＩＤ付き文書"Doc1"自体はそのクライアント端末２０には存在せず、その代わりにＩＤ付き文書"Doc2"が存在することとなる。なお、user2は、印刷結果の紙文書"Doc2"を、他のユーザであるuser4に渡す。
【００５８】
その後、更に別のユーザuser3が自分のクライアント端末の文書操作部２００でＩＤ付き文書"Doc1"を閲覧する。閲覧されるのは内容ＩＤ"Content1"の文書内容である。クライアント端末は、閲覧の結果としてＩＤ付き文書"Doc3"を生成し、文書管理サーバ１０に登録する。ここで、「閲覧」操作は、「公開」の対象にはなっていないので、そのＩＤ付き文書のメタ情報中には「公開」属性の値は含まれない。「閲覧」操作では、文書内容は変更されないので、文書内容は"Content1"のままである。なお、このように文書内容が変更されない操作を行った場合、クライアント端末２０は、文書内容を省略したＩＤ付き文書を文書管理サーバ１０に送ってもよい。なお、この操作の前にuser3のクライアント端末２０内にあったＩＤ付き文書"Doc1"は、この操作に伴い、派生関係組込部２０４によりＩＤ付き文書"Doc3"に置き換えられる。この置き換え処理では、派生関係組込部２０４は、元のＩＤ付き文書"Doc1"のうち、メタ情報３１０の管理ＩＤ３１２を新たに発行したＩＤ"Doc2"へ変更すると共に、元の文書"Doc1"の管理ＩＤ"Doc1"を親ＩＤ３１４の値にセットする。また、派生関係組込部２０４は、ログ情報３１６中の操作種別の値を今回の操作の種類である「閲覧」に変更し、操作時刻の値をその閲覧の日時に変更し、操作者の値をuser3に変更する。なお、今回の操作は閲覧なので、文書内容３２０は変化しない。
【００５９】
次に、user4が、user2から受け取ったＩＤ付きの紙文書"Doc2"に対して書き込みを行い、書き込み済みの紙文書をスキャナにセットし、クライアント端末２０上の読取制御ソフトウエアの操作メニューから「承認版として登録」の操作を選んだとする。すると読取制御ソフトウエアは、スキャナを制御して紙文書を読み取り、その読取結果の画像データを文書内容（以下、識別のためにこの文書内容を"Content2"と名付ける）として含むＩＤ付き文書"Doc4"を生成し、文書管理サーバ１０に送ると共に、当該クライアント端末２０内に保存する。このＩＤ付き文書"Doc4"内のメタ情報３１０に含まれる管理ＩＤは"Doc4"であり、親ＩＤは"Doc2"である。この親ＩＤ"Doc2"は、紙文書から読み取った管理ＩＤである。またuser属性はuser4である。また、文書操作部２００での「承認版として登録」という操作は、ログ記録目的上での「更新」という操作種別に分類されるので、メタ情報中のmethod属性は「更新」となる。また、この例では、「更新」という操作種別が「公開」の対象に設定されているので、メタ情報中のshared属性の値は「１」（この値は「公開対象である」ことを意味する）となる。
【００６０】
次に、user4がＩＤ付き文書"Doc4"を文書操作部２００により編集する。これにより、編集結果の文書内容"Content3"を含み、"Doc4"を親ＩＤとして含む新たなＩＤ付き文書"Doc5"が生成され、文書管理サーバ１０に登録される。user4のクライアント端末２０内のＩＤ付き文書"Doc4"はこのＩＤ付き文書"Doc5"に置き換えられる。
【００６１】
次に、user3が自分のクライアント端末内のＩＤ付き文書"Doc3"に対し文書操作部２００にて編集を加え、操作メニュー上で「更新版として登録」を指示すると、クライアント端末は、管理ＩＤ３１２の値が"Doc6"、親ＩＤ３１４の値が"Doc3"、操作種別の値が「更新」であるＩＤ付き文書"Doc6"を生成して、これをＩＤ付き文書"Doc3"と置き換えると共に、そのＩＤ付き文書"Doc6"を文書管理サーバ１０に登録する。編集により、文書内容は"Content3"から"Content4"へと変化している。「更新」操作は公開対象なので、そのＩＤ付き文書"Doc6"のshared属性は「１」である。文書管理サーバ１０の派生関係ＤＢ１１０には、管理ＩＤ"Doc6"のレコードが登録される。
【００６２】
図５及び図６は、この時点での派生関係ＤＢ１１０内の、"Doc1"から派生する文書或いは操作の様子を示している。
【００６３】
以上、派生関係ＤＢ１１０のデータ内容を例に取り、本システムにおける文書操作の情報の登録の様子を説明した。
【００６４】
図４の説明に戻り、要求処理部１４０は、クライアント端末２０からの管理ＩＤを含んだサービス要求に応じて、派生関係ＤＢ１１０を用いたサービスを提供する。要求処理部１４０が提供するサービスとしては、例えば、サービス要求中の管理ＩＤに対応する文書の最新版を検索するサービスがある。また別の例として、サービス要求中の管理ＩＤに対応する始祖（根）の文書又はその始祖についてのログ情報を提供するサービスを挙げることができる。また、別の例として、その管理ＩＤの来歴、すなわち始祖からその管理ＩＤまでに文書が経てきた操作の履歴（例えば誰がいつどんな操作をしたのかを示す情報のリスト）を提供するサービスもある。また、派生関係ＤＢ１１０に登録された属性項目についての検索条件の指定を受け付け、その検索条件を満足するＩＤ付き文書のリストを提供するサービスもある。なお、上述の最新版を検索するサービスは、「操作日時が最新である」という検索条件についての検索結果を提供するサービスと捉えることもできる。また、上述の始祖の文書の情報を提供するサービスは、「ノードアドレスが根を示す文書」という条件についての検索結果を提供するサービスと捉えることができる。
【００６５】
サービス要求は、クライアント端末２０に保持されたＩＤ付き文書に基づき発せられる。例えば、ユーザがクライアント端末２０の文書操作部２００によりＩＤ付き文書を開いた場合に、文書操作部２００が、派生関係を用いたサービスのメニューを提供し、そのメニューの中からユーザが所望するサービスの指定を受け付ける。そして、そのＩＤ付き文書の管理ＩＤと指定されたサービスを示すコードとを含むサービス要求を文書管理サーバ１０の要求処理部１４０に送信する。このとき、ユーザ識別情報や操作日時などの属性項目についての検索条件を指定するユーザインタフェース画面を提供し、この画面を介して入力された検索条件を併せて要求処理部１４０に送信してもよい。また、管理ＩＤと、サービスを示すコード、検索条件以外に、指示を行ったユーザの識別情報や、ユーザの入力した認証情報などといった他の情報を、クライアント端末２０から要求処理部１４０に送信するようにしてもよい。
【００６６】
また、別の例として、ＩＤ付き文書というオブジェクト種類に対して、そのようなサービスのメニューを対応づけてクライアント端末２０のオペレーティングシステムに登録しておいてもよい。この場合、図７に示すように、オペレーティングシステムが提供するファイル管理画面４００に表示されたＩＤ付き文書のアイコン４１０又は４１４に対し、ユーザが右ボタンクリックなどの所定の操作を行った場合、オペレーティングシステムが、ＩＤ付き文書に対応づけられたメニュー４２０を画面表示する。図示例では、ＩＤ付き文書のアイコン４１０又は４１４には、本システムのＩＤ付き文書であることを示すマーク４１１により、他の種類のファイル４１２と区別可能となっている。ユーザがメニュー４２０上の各サービス項目の中から、所望のものを選択すると、クライアント端末２０は、選択されたサービス項目の実行を文書管理サーバ１０に要求する。
【００６７】
また別の例として、ユーザによるサービスの指定を一つの「操作」と捉え、その「操作」に対して新たに管理ＩＤを付与することも考えられる。この場合、指定されたサービスのコードを操作種別として含み、指定の際に用いられた元のＩＤ付き文書の管理ＩＤを親ＩＤとして含んだＩＤ付き文書を生成し、このＩＤ付き文書をサービス要求として文書管理サーバ１０に送ってもよい。この場合、要求処理部１４０は、受け取ったＩＤ付き文書内の操作種別の情報に基づき提供すべきサービスを判定し、同じくＩＤ付き文書内の親ＩＤを、派生関係を遡る処理の起点とする。
【００６８】
要求処理部１４０は、クライアント端末２０からサービス要求を受けた場合、そのサービス要求中に指定された管理ＩＤを起点に、派生関係ＤＢ１１０に登録された管理ＩＤと親ＩＤとの派生関係が構成する木を走査（トラバース）し、その走査の結果得られた情報を用いて、ユーザから要求されたサービスを実行する。
【００６９】
以下、サービス要求を受け取った場合の要求処理部１４０の処理手順を、図８及び図９を参照して説明する。以下では、派生関係ＤＢ１１０内のデータ内容が図５及び図６に例示したものである時に、user2が、自分のクライアント端末２０内にあるＩＤ付き文書"Doc2"を対象として、当該ユーザが指定した検索条件を満たす文書の要求を行った場合を具体例として用いて説明する。
【００７０】
この手順では、要求処理部１４０は、クライアント端末２０から受け取ったサービス要求から、処理対象として含まれる管理ＩＤを取り出し、その管理ＩＤを注目ＩＤにセットする（Ｓ１）。次に、派生関係ＤＢ１１０から、注目ＩＤに対応するレコードを取得する（Ｓ２）。注目ＩＤに対応するレコードとは、注目ＩＤをレコード中の「管理ＩＤ」の項目の値として持つレコードのことである。そして、取得したレコード中の操作種別の項目の値が「登録」であるか否かを調べ（Ｓ３）、「登録」でなければ、注目ＩＤの値をそのレコード中の親ＩＤの値へと置き換え（Ｓ４）、ステップＳ２及びＳ３を実行する。このステップＳ２〜Ｓ４のループは、サービス要求中の管理ＩＤから派生関係の木構造を遡り、大本（根）であるフォーム原本の「登録」操作を見つけるための処理を表す。ステップＳ３の判定結果がＹｅｓとなった場合、そのときの注目ＩＤは、根である「登録」操作に対応する。図５の例では、管理ＩＤ"Doc2"から木構造を遡ることで、最終的に、根である管理ＩＤ"Doc1"に到達する。
【００７１】
根である「登録」操作に到達すると、要求処理部１４０は、そのときの注目ＩＤ（根）の子ＩＤを検索する（Ｓ５）。派生関係ＤＢ１１０のうちその注目ＩＤを「親ＩＤ」の値として持つレコードの「管理ＩＤ」が、注目ＩＤの子ＩＤである。注目ＩＤの子ＩＤがすべて求められると、要求処理部１４０は、それら子ＩＤごとに、図９に示すような子孫探索処理を実行する（Ｓ６）。
【００７２】
子孫探索処理（Ｓ６）では、要求処理部１４０は、当該子ＩＤを注目ＩＤとし（Ｓ１１）、その注目ＩＤに対応するレコードを派生関係ＤＢ１１０から取得する（Ｓ１２）。そして、そのレコード中の「公開」属性の値が「１」であるか否かを判定し（Ｓ１３）、「１」であれば、そのレコードを中間結果リストに入れる（Ｓ１４）。中間結果リストは、要求された処理の処理結果を求めるための材料となる情報を蓄積するためにクライアント端末２０の記憶装置上に構築されるリストである。「公開」属性が「１」でなければ、ステップＳ１４はスキップされる。そして、要求処理部１４０は、注目ＩＤの子ＩＤを検索し（Ｓ１５）、子ＩＤが検索できたか否かを判定する（Ｓ１６）。子ＩＤがあれば、要求処理部１４０は、それら各子ＩＤについて、それぞれ子孫探索処理（Ｓ６）を再帰的に実行する。すべての子ＩＤについての子孫探索処理が終了すると、当該注目ＩＤについての処理が終了する。ステップＳ１６で子ＩＤがないと判定された場合も、当該注目ＩＤについての処理は終了する。
【００７３】
図８の手順に戻り、根のＩＤ付き文書のすべての子ＩＤについて子孫探索処理（Ｓ６）が終了すると、そのときの中間結果リストには、その根から派生するすべてのＩＤ付き文書の中で、「公開」属性が「１」であるものに対応するレコードがすべて蓄積されていることになる。要求処理部１４０は、中間結果リストに蓄積されたレコード群の中から、検索条件を満足するレコードを求める（Ｓ７）。そして、求めたレコードに対応するＩＤ付き文書を、要求に対する検索結果として、要求元のユーザ（この例ではuser2）に提供する（Ｓ８）。
【００７４】
例えば、図６の例では、ステップＳ６の処理により、中間結果リスト中には管理ＩＤが"Doc4"、"Doc6"の２つのレコードが蓄積される。そして、例えば、検索条件が「操作日時が最新の文書」という条件であれば、中間結果リストの中で操作日時が最新である文書"Doc6"が検索結果として要求元のuser2に提供される。
【００７５】
ステップＳ７で、検索結果として複数のＩＤ付き文書が得られた場合、それら複数の文書すべてを要求元のユーザに返せばよい。またこの代わりに、検索結果のＩＤ付き文書のリストをユーザに返し、ユーザがその中から所望のものを選択して取得するようにしてもよい。
【００７６】
以上に説明したように、本実施形態では、特定の操作種別に該当する操作の結果の文書しか公開されない。また、どの操作種別の操作結果を公開対象とするかは、各クライアント端末２０の各文書操作部２００ごとに個別に設定できるので、各クライアント端末又は各文書操作部２００の事情に応じて操作結果の公開・非公開を制御できる。
【００７７】
次の、変形例を説明する。上記実施形態では、要求処理部１４０は、サービス要求中の管理ＩＤが所属する木全体に対して検索を行った。これに対し、この変形例では、文書操作部２００が行った操作の種別に応じて検索の境界を設定し、それら境界で区切られた範囲内で検索を行う。
【００７８】
説明のための事例として、図１０及び図１１に示すような派生関係を考える。この派生関係は、図５及び図６に示した状態の後、更に以下のような操作が加えられたときの状態を示している。
【００７９】
すなわち、図５及び図６に示された状態の後、user3がＩＤ付き文書"Doc6"を印刷して印刷結果の紙文書をuser5に配布する。この印刷により、ＩＤ付き文書"Doc7"が生成され、文書管理サーバ１０に登録される。次にuser5がuser3から受け取った紙文書の内容を確認してスキャナにセットし、「承認版として登録」の操作を行う。これによりスキャン結果の画像を含むＩＤ付き文書"Doc8"が生成され、文書管理サーバ１０に登録される。そしてuser5がそのＩＤ付き文書"Doc8"を開いて編集を加え、「更新版として登録」操作を行うと、ＩＤ付き文書"Doc9"が生成され、文書管理サーバ１０に登録される。図１０及び図１１に示す派生関係は、この時点の状態である。この例では、図５及び図６の例と同様、スキャンした画像を「承認版として登録」する操作、及び電子文書の編集結果を「更新版」として登録する操作は、共に「公開」属性の値が「１」となる操作であるとする。
【００８０】
また、この例では、派生関係の木構造の中に検索境界を設定可能としている。要求処理部１４０は、受け取ったサービス要求中の管理ＩＤを起点に木を走査する際、検索境界より先祖にも子孫にも走査は進めない。このように、この変形例では、検索範囲をサービス要求中の管理ＩＤを含んだ木全体とするのではなく、その木を検索境界によって区切ってできる各部分木のうち、その管理ＩＤを含んだ部分木のみを検索範囲とする。この変形例では、文書に対して特定の種別の操作が行われた場合に、操作前の文書と操作結果の文書との間を検索境界に設定する。
【００８１】
検索境界を表すため、図示例では、ＩＤ付き文書のメタ情報に「境界」属性を組み込んでいる。ある文書の「境界」属性の値が「１」であれば、その文書とその親との間が検索境界であることを示す。ある文書の「境界」属性の値が「０」であれば、その文書とその親とは同じ検索範囲に属する。どのような種別の操作の結果を検索境界とするかは、文書操作部２００にあらかじめ登録されている。図１０及び図１１の例では、「登録」操作と（電子的なＩＤ付き文書に対する）「更新版として登録」操作が、検索境界を生み出す操作種別として設定されており、文書"Doc1"、"Doc6"及び"Doc9"の「境界」属性が「１」となっている。そのように登録された種別の操作を行った場合、文書操作部２００は、その操作結果のＩＤ付き文書の「境界」属性を「１」にセットする。そうでなければ、「境界」属性の値を「０」とするか、又は「境界」属性自体を省略する。
【００８２】
例えば、ＩＤ付き文書"Doc9"のメタ情報レコードは、以下の例３に示すようなものとなる。
【００８３】
[例３]
<metadata sid="Doc9" pid="Doc8" date="2006-10-03T14:34" method="update" filename="aaa_v2.doc" user="user5" shared="1" unrelated="1"/>
【００８４】
この例において、unrelated属性が「境界」属性である。なお、紙文書を読み取って「承認版として登録」する操作と、電子的なＩＤ付き文書を「更新版として登録」する操作は、上記実施形態の例では、ログ記録上の操作種別では同じ「更新」に分類されているが、この変形例では、そのような分類の操作でも、「境界」属性の判別においては区別している。すなわち、この例では、紙文書を読み取って「承認版として登録」する操作に対応する「境界」属性の値は「０」である。例えば、ＩＤ付き文書"Doc8"の「境界」属性値は「０」となっている。この変形例では、「境界」属性の判定は、文書操作部２００での操作の種別に基づき行っているといえる。なお、これはあくまで一例であり、ログ記録上の操作種別に従って判定してもよい。
【００８５】
これら図１０及び図１１に示した状態の時に、user3が、例えば図７に例示したようなユーザインタフェース画面を介して、ＩＤ付き文書"Doc7"を対象として「最新フォーム取得」の要求を行ったとする。このような場合を例にとって、「最新フォーム取得」の要求を受けたときの、要求処理部１４０の処理手順の例を説明する。
【００８６】
この場合、要求処理部１４０は、例えば図１２及び図１３に示す手順に従って、最新フォームを求める。図１２の手順では、要求処理部１４０は、まず、クライアント端末２０から受け取った要求に処理対象として含まれる管理ＩＤを注目ＩＤにセットし（Ｓ１）、派生関係ＤＢ１１０からその注目ＩＤに対応するレコードを取得する（Ｓ２）。次にそのレコード中の「境界」属性の値が「１」であるか否かを調べ（Ｓ３Ａ）、「１」でなければ、注目ＩＤの値をそのレコード中の親ＩＤの値へと置き換え（Ｓ４）、ステップＳ１〜Ｓ３Ａの処理を繰り返す。
【００８７】
ステップＳ３Ａの判定結果がＹｅｓとなった場合、要求中の管理ＩＤから派生関係を遡り、直近の検索境界のノードにたどり着いたことになる。このノードが、今回の検索の範囲である部分木の根である。要求処理部１４０は、そのときの注目ＩＤ（すなわち部分木の根）の公開属性を調べ（Ｓ９）、公開属性の値が「１」であればその注目ＩＤに対応するレコードを中間結果リストに入れ（Ｓ１０）、ステップＳ５に進む。ステップＳ９で注目ＩＤに対応する公開属性が「１」でなければ、ステップＳ１０を飛ばしてステップＳ５に進む。ステップＳ５では、注目ＩＤの子ＩＤを検索する。そして、要求処理部１４０は、それら子ＩＤごとに、図１３に示すような子孫探索処理を実行する（Ｓ６）。
【００８８】
子孫探索処理（Ｓ６）では、要求処理部１４０は、当該子ＩＤを注目ＩＤとし（Ｓ１１）、その注目ＩＤに対応するレコードを派生関係ＤＢ１１０から取得する（Ｓ１２）。そして、そのレコード中の「境界」属性の値が「１」であるか否かを判定する（Ｓ２０）。その「境界」属性の値が「１」であれば、部分木の走査において子孫方向の検索境界に達したことになるので、当該注目ＩＤについての図１３の処理を終了する。「境界」属性の値が「１」でなければ、更に「公開」属性の値が「１」であるか否かを判定する（Ｓ１３）。ステップＳ１３の判定結果がＹｅｓの場合、要求処理部１４０は、そのレコードを中間結果リストに入れる（Ｓ１４）。ステップＳ１３の判定結果がＮｏであれば、ステップＳ１４はスキップされる。そして、要求処理部１４０は、注目ＩＤの子ＩＤを検索し（Ｓ１５）、子ＩＤが検索できたか否かを判定する（Ｓ１６）。子ＩＤがあれば、要求処理部１４０は、それら各子ＩＤについて、それぞれ子孫探索処理（Ｓ６）を再帰的に実行する。すべての子ＩＤについての子孫探索処理が終了した場合、又はステップＳ１６で子ＩＤがないと判定された場合、当該注目ＩＤについての処理が終了する。
【００８９】
図１２の手順に戻ると、ステップＳ３Ａで特定された部分木の根のすべての子ＩＤについて子孫探索処理（Ｓ６）が終了すると、そのときの中間結果リストには、その部分木に属し、「公開」属性が「１」であるＩＤ付き文書がすべて蓄積されていることになる。要求処理部１４０は、中間結果リストに蓄積されたレコード群の中から、検索条件である「最新の」レコードを求め（Ｓ７）、このレコードに対応するＩＤ付き文書を検索結果として要求元のユーザに返す（Ｓ８）。
【００９０】
例えば、図１０の例において、ＩＤ付き文書"Doc7"を対象として「最新フォーム取得」の要求がなされた場合、ステップＳ１〜Ｓ４のループにより、検索範囲の部分木の根となる"Doc6"が特定される。更にステップＳ９以下の処理により、中間結果リスト中には管理ＩＤが"Doc6"、"Doc8"の２つのレコードが蓄積される。ＩＤ付き文書"Doc9"は、「公開」属性値は「１」であるが、「境界」属性値も「１」なので、ステップＳ２０により、中間結果リストには蓄積されない。中間結果リストに蓄積されたレコードのうち最新のレコードに対応するＩＤ付き文書"Doc8"がステップＳ８で検索結果として求められる。
【００９１】
以上に説明した変形例によれば、文書に対する操作に応じて、操作前の文書と操作結果の文書との間に検索境界を設定することができる。検索境界を設定するということは、操作前の文書と操作結果の文書とを、別系統の文書として取り扱うことと捉えることもできる。また、上記変形例では、また、どの操作種別の操作に応じて検索境界を設定するか否かを、各クライアント端末２０の各文書操作部２００ごとに個別に設定できるので、各クライアント端末又は各文書操作部２００の事情に応じて検索境界を制御できる。
【００９２】
以上に例示した実施形態及び変形例では、管理ＩＤの発行は各クライアント端末２０で行われていたが、この代わりに文書管理サーバ１０が管理ＩＤを発行してもよい。この場合、クライアント端末２０は、ＩＤ付き文書に対して操作を行った場合、操作前のＩＤ付き文書内の管理ＩＤを親ＩＤ３１４として含み、更にその操作についてのログ情報３１６と操作後の文書内容３２０とを含み、管理ＩＤ３１２は空欄の文書データを生成し、文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書データに対して新たな管理ＩＤを付与し、この管理ＩＤとその文書データとに含まれる情報を、文書ＤＢ１００及び派生関係ＤＢ１１０に登録する。また、文書管理サーバ１０は、付与した管理ＩＤを当該文書データにセットすることによりＩＤ付き文書を生成し、これをクライアント端末２０に返す。クライアント端末２０は、操作前のＩＤ付き文書を、受け取ったＩＤ付き文書に置き換える。このように、文書管理サーバ１０が管理ＩＤを付与する構成でも、上述実施形態及び変形例の処理は同様に実行できる。
【００９３】
また以上の実施形態及び変形例では、管理ＩＤ３１２、親ＩＤ３１４、ログ情報３１６、及び文書内容３２０を含んだＩＤ付き文書３００がクライアント端末２０に保存されたが、この代わりに、クライアント端末２０は管理ＩＤしか持たず、その他の情報は文書管理サーバ１０に保存されるようにしてもよい。この場合、クライアント端末２０で文書を操作する場合、その文書に対応する管理ＩＤを文書管理サーバ１０に送り、文書管理サーバ１０からその文書を取得する。また、別の例として、クライアント端末２０が保持するＩＤ付き文書３００の中には管理ＩＤ３１２と文書内容３２０とが含まれ、親ＩＤ３１４及びログ情報３１６は含まれないようにしても良い。この場合、サーバがその管理ＩＤ３１２に対応づけて親ＩＤ３１４とログ情報３１６を持つようにすれば良い。
【００９４】
ここで、文書管理サーバ１０が管理ＩＤを付与する場合は、その取得の操作に対応する管理ＩＤを文書管理サーバ１０が生成し、その管理ＩＤと文書とを対応づけてクライアント２０に提供するとともに、その取得操作についてのログ情報（操作時刻や操作者など）と、元の管理ＩＤ（すなわち親ＩＤ）と、付与した管理ＩＤとを派生関係ＤＢ１１０に記録する。クライアント端末２０は、文書管理サーバ１０に送信した管理ＩＤを、受け取った管理ＩＤに置き換えると共に、受け取った文書を開く。ユーザは、開かれた文書に対して閲覧や編集などの操作を行う。クライアント端末２０は、文書に対する操作が完了すると、操作後の文書を管理ＩＤ及び当該操作についてのログ情報と共に文書管理サーバ１０に送る。文書管理サーバ１０は、受け取った文書に対して新たな管理ＩＤを付与して派生関係ＤＢ１１０に登録し、受け取った管理ＩＤを親ＩＤとして派生関係ＤＢ１１０に登録する。また、受け取ったログ情報及び操作後の文書を、派生関係ＤＢ１１０及び文書ＤＢ１００に登録する。そして、文書管理サーバ１０は、新たに付与した管理ＩＤをクライアント端末２０に返す。クライアント端末２０は、元の管理ＩＤを受け取った管理ＩＤで置き換える。以上のような処理により、操作間の派生関係が文書管理サーバ１０に蓄積されることになる。
【００９５】
一方、クライアント端末２０が管理ＩＤを付与する構成の場合は、文書管理サーバ１０は、クライアント端末２０から受け取った管理ＩＤに対応する文書をクライアントに返せばよい。クライアント端末２０は受け取った文書を開き、ユーザがその文書を操作する。操作の完了後、クライアント端末２０はその操作結果の文書に対して新たな管理ＩＤを付与し、この管理ＩＤを含んだ前述のＩＤ付き文書と同様の情報を、文書管理サーバ１０に送る。そして、クライアント端末２０は、そのＩＤ付き文書のうち管理ＩＤのみを保存し、その他の情報を削除する。
【００９６】
以上に例示したシステムにおける文書管理サーバ１０は、典型的には、汎用のコンピュータにて上述の文書管理サーバの各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図１４に示すように、ＣＰＵ（中央演算装置）４０、メモリ（一次記憶）４２、各種Ｉ／Ｏ（入出力）インタフェース４４等がバス４６を介して接続された回路構成を有する。また、そのバス４６に対し、例えばＩ／Ｏインタフェース４４経由で、ハードディスクドライブ４８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ５０が接続される。このようなドライブ４８又は５０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ４８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の処理が実現される。クライアント端末２０についても同様である。
【図面の簡単な説明】
【００９７】
【図１】文書利用管理システムの概略構成の例を示すブロック図である。
【図２】クライアント端末の内部構成の例を示すブロック図である。
【図３】ＩＤ付き文書のデータ構造の例を模式的に示す図である。
【図４】文書管理サーバの内部構成の例を示すブロック図である。
【図５】派生関係ＤＢのデータ内容の例を示す図である。
【図６】図５に例示したデータ内容における管理ＩＤ群がなす木構造を図式化して表す図である。
【図７】ＩＤ付き文書のアイコンを表示した表示画面の例を示す図である。
【図８】サービス要求に対する要求処理部の処理手順の一例の一部を示すフローチャートである。
【図９】サービス要求に対する要求処理部の処理手順の一例の残りの部分を示すフローチャートである。
【図１０】変形例における派生関係ＤＢのデータ内容の例を示す図である。
【図１１】図１０に例示したデータ内容における管理ＩＤ群がなす木構造を図式化して表す図である。
【図１２】最新フォーム取得要求に対する要求処理部の処理手順の一例の一部を示すフローチャートである。
【図１３】最新フォーム取得要求に対する要求処理部の処理手順の一例の残りの部分を示すフローチャートである。
【図１４】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【００９８】
１０ 文書管理サーバ、２０ クライアント端末、３０ ネットワーク、１００ 文書ＤＢ、１１０ 派生関係ＤＢ、１３０ 文書登録部、１３２ 派生関係登録部、１４０ 要求処理部、２００ 文書操作部、２０２ ＩＤ割り当て部、２０４ 派生関係組込部、２１０ 登録処理部、３００ ＩＤ付き文書。
【特許請求の範囲】
【請求項１】
情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、
対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する検索結果提供部と、
を備える文書管理装置。
【請求項２】
前記登録部は、更に前記第２の文書と前記第１の文書との間が検索境界であるか否かを示す検索境界情報を前記情報処理装置から受け取って前記第２の文書と対応づけて前記記憶部に登録し、
前記検索結果提供部は、前記派生関係群がなす木群の中の前記検索境界で区切られる部分木群のうち前記対象文書の属する部分木に属する文書の中で、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する、
ことを特徴とする文書管理装置。
【請求項３】
情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録するステップであって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録するステップと、
対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供するステップと、
をコンピュータに実行させるためのプログラム。
【請求項４】
文書に対する操作を実行する操作実行部と、
操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、
前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、
を備える情報処理装置。
【請求項５】
文書に対する操作を実行する操作実行部と、
操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、
前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、
してコンピュータを機能させるためのプログラム。
【請求項６】
情報処理装置と文書管理装置とを備え、
前記情報処理装置は、
文書に対する操作を実行する操作実行部と、
操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、
前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、
を備え、
前記文書管理装置は、
前記情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、
対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する検索結果提供部と、
を備える、
ことを特徴とする文書管理システム。
【請求項１】
情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、
対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する検索結果提供部と、
を備える文書管理装置。
【請求項２】
前記登録部は、更に前記第２の文書と前記第１の文書との間が検索境界であるか否かを示す検索境界情報を前記情報処理装置から受け取って前記第２の文書と対応づけて前記記憶部に登録し、
前記検索結果提供部は、前記派生関係群がなす木群の中の前記検索境界で区切られる部分木群のうち前記対象文書の属する部分木に属する文書の中で、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する、
ことを特徴とする文書管理装置。
【請求項３】
情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録するステップであって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録するステップと、
対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供するステップと、
をコンピュータに実行させるためのプログラム。
【請求項４】
文書に対する操作を実行する操作実行部と、
操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、
前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、
を備える情報処理装置。
【請求項５】
文書に対する操作を実行する操作実行部と、
操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、
前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、
してコンピュータを機能させるためのプログラム。
【請求項６】
情報処理装置と文書管理装置とを備え、
前記情報処理装置は、
文書に対する操作を実行する操作実行部と、
操作ごとに、当該操作の結果得られた文書を開示対象とするか否かを規定する判定情報を記憶した判定情報記憶部と、
前記操作実行部により第１の文書に対して操作が実行された場合に、当該操作の結果得られた第２の文書を開示対象とするか否かを示す開示属性情報を前記判定情報に基づき生成し、当該開示属性情報を前記第２の文書と対応づけて前記文書管理装置に送信する送信部と、
を備え、
前記文書管理装置は、
前記情報処理装置から、第１の文書の操作の結果得られた第２の文書と、当該第２の文書が開示対象であるか否かを示す開示属性情報と、を受け取って互いに対応づけて記憶部に登録する登録部であって、前記第１の文書が前記記憶部に既に登録されている場合には、前記第２の文書の親が前記第１の文書であることを示す派生関係を更に前記記憶部に登録する登録部と、
対象文書と検索条件とを指定した検索指示に応じて、前記記憶部に記憶された派生関係群がなす木群の中の前記対象文書が属する木に含まれる文書のうち、前記検索条件を満たし且つ開示対象であることを示す開示属性情報に対応する文書を検索結果として提供する検索結果提供部と、
を備える、
ことを特徴とする文書管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２００８−１８１４４６（Ｐ２００８−１８１４４６Ａ）
【公開日】平成２０年８月７日（２００８．８．７）
【国際特許分類】
【出願番号】特願２００７−１５９１６（Ｐ２００７−１５９１６）
【出願日】平成１９年１月２６日（２００７．１．２６）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
【公開日】平成２０年８月７日（２００８．８．７）
【国際特許分類】
【出願日】平成１９年１月２６日（２００７．１．２６）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
[ Back to top ]