JP4816281B2 - 文書利用管理システム、文書管理サーバ及びそのプログラム - Google Patents

Description

本発明は、電子文書を管理する文書利用管理システムに関する。

従来より、文書データや音声データ、画像データ、マルチメディアデータ、プログラムなどの電子文書（以下単に文書とも呼ぶ）を文書管理サーバに登録し、ユーザの要求に応じてその文書を提供することが行われている。このような電子文書を管理する文書利用管理システムにおいては、文書属性の管理、アクセス管理、バージョン管理、添付文書等の付帯情報管理などのように、サーバの文書管理機能により付加価値が提供されていた。しかしながら、このような付加価値的な情報はサーバにより管理されているので、一旦サーバから取り出され配布されて流通の過程にある文書には、そのような付加価値的な情報が付随していないことが一般的である。このように流通途上のオープンな環境にある文書と、サーバ上の文書属性その他の付加価値的な情報との対応付けは、従来、一般的には、文書名などを手がかりに人手によって行われているのが実情である。

文書アクセス管理に関する従来技術として、特許文献１に示される情報処理システムがある。このシステムは、組織のセキュリティポリシーを示すポリシー記述に従って、動的にバージョン管理やアクセス制御を行う。このシステムでは、オペレーションの対象となる対象情報のセキュリティ属性と、該対象情報に対する該オペレーションを要求するユーザのセキュリティ属性とに基づいて、該オペレーションの許可又は不許可を規定し、所定の要件を処理することによって上記オペレーションを許可することを規定する。

また、特許文献２に示される情報処理システムでは、作業中のファイル群を束ねた部分単位集合をアドホックに作成し、これをスナップショットとして保持する。そして、このスナップショットを、後で閲覧したり、複数人で共有できるようにしている。

また、別の従来技術では、プリンタで電子文書を印刷し、その印刷結果に記載された識別情報または座標情報を前記電子文書と対応づけて文書管理データベースに格納し、印刷された文書に対して電子ペン等の電子情報入力インタフェースまたは座標入力装置にて加筆を行うことで得られる、識別情報や座標情報に基づく電子文書の更新情報を、前記電子文書と対応づけて、履歴管理データベースや履歴管理文書フォルダに保管・更新するシステムや装置が知られている。このようなシステムの一例として、特許文献３に示されるものがある。
このような従来システムには、紙文書に対する手書きによる編集を、直接的に電子文書に反映し、電子文書の更新された版の系列を、電子文書をノードとする木構造として保持するものがある。特許文献３では、文書やファイルをノードとし、文書やファイルの更新によって生成される版を、枝分かれした版として管理する事ができる文書履歴木の例が開示されている。このようなバージョン管理システムは、CVS（Concurrent Versions System) として広く知られている。
特許文献３は、電子文書の更新に関する履歴を、更新前の電子文書を親とし、更新後の電子文書を子とするように文書履歴木を管理する方法が開示されている。

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

企業等の組織における文書管理では、例えば組織のリーダーが組織内に戦略情報を展開する際に、リーダーがその戦略情報の文書セット（１以上の文書の集合）のコピーを組織内の各部門の部門長に渡し、各部門がそれぞれその文書セットの担当部分に編集を加えたり、副次的な文書を付加したりした上で、更に下位部門へと展開していく。このような作業が、組織階層の上位から下位へ向かって繰り返される。このような文書展開方式では、特別な場合を除き、部門のメンバには自部門の担当部分が見えたり編集できたりすればよく、隣の部門の担当部分は見える必要がない。逆に見えるとかえって邪魔になる場合も少なくない。このため、他部門の担当部分にアクセスできなくするような文書管理が求められる。
このような文書管理を従来の文書管理サーバの枠組みで実現しようとすると、上位部門から下位の複数の部門に文書セットを展開する際に、下位部門ごとに文書セットのコピーを作成し、各階部門が自分のコピーに対して編集や情報追加を行うことになる。個々の文書がバージョン管理されている場合は、下位部門への展開の際に文書セットのバージョンブランチを作成し、そのブランチに対してその下位部門がバージョン更新を行うことになる。ここで、各部門のメンバが他部門の担当部分にアクセスできなくするためには、各部門に割り当てられる文書セットのコピーやバージョンブランチに対し、その部門のメンバにのみアクセス権を設定する必要がある。組織の階層数が多くなると、コピーやバージョンブランチを階層的に作成したり、それらに対して適切にアクセス権を設定したりする作業は複雑且つ煩雑な作業となってしまう。
また、サーバから離れてオープンな環境にある文書について、そのような部門ごとのアクセス管理を実現するようなシステムは知られていない。
この特許文献１のシステムは、アクセス権を動的に変更するものではあるが、階層的な組織内での文書展開に配慮をしておらず、上述のような階層的な部門ごとのアクセス権をポリシー記述により適切に表現することは必ずしも容易ではない。
この特許文献２のシステムでは、各時点の文書群を複数人で共有することができるものの、特許文献１と同様階層的な組織内での文書展開には配慮をしていないので、組織の部門ごとに適切なスナップショットを作るなどの作業はユーザが人手で行わなければならない。
また、特許文献３には、紙文書の複写について、複写手段からの指示や入力により、文書履歴木のノードを追加・更新する具体的な手段についての説明は、何ら開示されていない。同様に紙文書を破棄した際に、破棄手段からの指示や入力により、文書履歴木のノードを追加・更新する具体的な手段についての説明は、何ら開示されていない。また、組織内での文書展開に対して特段の配慮も示されていない。

本発明に係る文書管理システムは、電子文書を管理する文書管理サーバと電子文書を利用するクライアントとを含む。ここで、文書管理サーバは、ユーザからの操作要求に応じて電子文書に操作を行った場合に、その電子文書に対応づけられた新たな操作ＩＤをそのユーザに発行すると共に、その新たな操作ＩＤをその操作要求に伴って受け取った操作ＩＤの子ノードとする派生関係を記録するＩＤ処理手段と、前記派生関係のノード群の中に、部門の基点を示す基点ノードを設定する基点設定手段と、基点ノードの子孫のノードに対応する操作により登録された前記電子文書の関連データをその基点ノードへと収集する文書収集手段と、ユーザから電子文書の利用要求を受けた場合に、その利用要求に伴う操作ＩＤから前記派生関係のルートノードへと前記派生関係を遡る過程で検出された基点ノードに収集された関連データに基づき生成した文書データをユーザに提供する文書提供手段と、を備える。また、前記クライアントは、電子文書に関する操作要求に応じて文書管理サーバから受け取った操作ＩＤをその電子文書に対応する操作ＩＤとして保存する操作ＩＤ管理手段と、前記操作ＩＤ管理手段により保存された操作ＩＤを指定してユーザから操作指示を受けた場合に、その操作ＩＤを伴った要求を前記文書管理サーバへと送る要求手段と、を備える。

以下、図面を参照して、本発明の実施の形態（以下「実施形態」と呼ぶ）について説明する。

＜副本ショートカットを用いた文書利用管理システムの概要＞
まず、実施形態のシステムのベースとなる、副本ショートカットを用いた文書利用管理システムについて説明する。

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

このシステムでは、電子文書の正本を文書管理サーバ１０で管理し、クライアント端末２０にはその電子文書を保存しないようにすることで、電子文書のセキュリティを確保する。クライアント端末２０には、電子文書そのもののファイルの代わりに、その電子文書にアクセスするための情報を含んだ副本ショートカット（以下「副本ｓｃ」と略す）と呼ぶファイルを持たせる。副本ｓｃには、例えば、副本ＩＤと呼ぶ管理用の識別情報と、文書管理サーバ１０のホスト名又は文書閲覧要求用のＵＲＬ（Uniform Resource Locator）などのアクセス情報と、副本ｓｃの属性とが含まれる。副本ｓｃの含む情報の一例を以下に示す。
"id=1234567, host=foo.fujixerox.co.jp,createDate=2005/05/24 11:12:34"

この例では、"id=1234567"が副本ＩＤを、"host=foo.fujixerox.co.jp"が文書管理サーバ１０のホスト名を、"createDate=2005/05/24 11:12:34"がその副本ｓｃの属性の１つである作成日時を示す。副本ショートカットには、漏洩防止等のために、電子文書の実体は含めない。ただし、ユーザがどの電子文書の副本ｓｃかを識別できるよう、電子文書の一部例えば１ページ目だけの情報や、電子文書の各ページのサムネイル画像などのように、その電子文書の劣化バージョンを見本として副本ｓｃに含めてもよい。

なお、副本ｓｃに組み込むアクセス情報は、副本ｓｃを利用するクライアント端末２０が、その副本ｓｃに対応する正本を管理する文書管理サーバ１０にアクセスする際に用いられる。ただし、ネットワーク上に、副本ＩＤから対応の正本を管理する文書管理サーバ１０のアクセス情報を解決するサーバを設けるならば（そしてこのサーバのアドレスが副本ｓｃに含まれるか、或いはビューワ２２にとって既知であれば）、副本ｓｃに文書管理サーバ１０のアクセス情報を含める必要はない。

図２に示すように、クライアント端末２０のファイルシステム２４には、他のアプリケーションのファイルとともに、副本ｓｃ２６のファイルも保存される。副本ｓｃ２６は、例えばアドビ社が開発したＰＤＦ(Portable Document Format)や富士ゼロックス株式会社が開発したDocuWorks文書などのように、文書の実体データに加え、属性情報を保持できる形式のファイルとして作成する。この場合、副本ｓｃ２６のファイルには副本ＩＤやアクセス情報等が属性情報として組み込まれる。ユーザは、文書管理サーバ１０上にある電子文書に対して閲覧その他の操作を行いたい場合、通常のショートカットファイルと同様の感覚で、その電子文書に対応する副本ｓｃ２６をファイルシステム２４や検索ソフトが提供するファイル一覧画面で選択し、操作を行う。すると、その副本ｓｃ２６のファイル形式に関連づけられたビューワ２２が起動し、そのビューワ２２がその副本ｓｃ２６内のアクセス情報及び副本ＩＤを用いて文書管理サーバ１０にアクセスして、その副本ＩＤに対応する電子文書のコピーである副本文書のファイルを取得する。ビューワ２２は、その副本ファイルを表示したり、ユーザの操作に応じてその副本ファイルに編集等の操作を加えたりする。ここで、副本ファイルには、そのファイルが副本であることを示す情報（例えば後述する更新用副本ＩＤ）が含まれており、ビューワ２２は、その情報からそのファイルが副本であることを認識する。ビューワ２２は、副本ファイルはファイルシステム２４には保存しない。副本ファイルは、クライアント端末２０においてビューワ２２が管理するメモリ領域の上で開かれるのみであり、ファイルシステム２４には保存されない。ビューワ２２としては例えばＰＤＦ形式に対応したアドビ社のAcrobat（登録商標）などを用いることができる。ここで、このシステム特有の副本ｓｃの取扱機能（その一部は既に説明したが、あとでも更に説明する）は、例えばプラグインの形でAcrobat等の既存ビューワに追加することができる。

このシステムでは、ユーザがクライアント端末２０上の副本ｓｃを利用して文書管理サーバ１０上の電子文書の正本に対して操作を行うたびに、文書管理サーバ１０が更新用の副本ＩＤを発行し、そのクライアント端末２０上の副本ｓｃ内の副本ＩＤを更新する。このようにすることで、このシステムでは、副本ｓｃを用いて電子文書に操作が行われるたびに、その副本ｓｃ内の副本ＩＤが更新されるようにしている。例えば、あるユーザＸが副本ｓｃを用いて電子文書の副本ファイルを文書管理サーバ１０に要求し、副本ファイルを得て閲覧した場合、そのユーザＸのクライアント端末２０にあるその副本ｓｃ内の副本ＩＤの値は、その閲覧の前後では変わってくる。したがって、そのユーザＸが副本ｓｃのコピーを電子メール等に添付して他のユーザＹに送った場合を考えると、閲覧の前に送ったのと閲覧のあとで送ったのとでは、ユーザＹが受け取る副本ｓｃの副本ＩＤが異なる。副本ｓｃを用いてユーザが電子文書の操作を要求する場合、その副本ｓｃに含まれる副本ＩＤがクライアント端末２０から文書管理サーバ１０に送られるので、文書管理サーバ１０は、その要求の元になった副本ｓｃがどの操作の段階に対応するものか（例えばユーザＸが閲覧する前のものか閲覧したあとのものか）を、受け取った副本ＩＤから識別することができる。また、副本ＩＤを、その対象となる電子文書の正本の識別情報（「文書ＩＤ」と呼ぶ）及びその副本ＩＤの発行の契機となった操作を行ったユーザのユーザＩＤ（或いはその副本ＩＤの発行先のユーザＩＤ）と対応づけて文書管理サーバ１０側で記録しておけば、その副本ＩＤからどの文書に対するどのユーザの操作かを割り出すこともでき、電子文書の流通の様子を詳細に追跡することができる。

副本ＩＤは、いわばユーザが電子文書に対して行った個々の操作に対応する、システム内で一意な識別情報である。副本ＩＤとしては、例えば操作ごとにインクリメントされる通し番号を用いてもよいが、第三者の推測による攻撃を困難にするという観点からすれば、例えば十分に長い乱数値などのように、高い一意性を確保しつつも推測が困難な生成規則を用いて生成された値を用いることが好適である。また、副本ＩＤの生成日時のように、副本ＩＤ発行の都度変化する属性情報のハッシュ値（十分に長い桁数のもの）や、そのような変化する属性情報に例えばその副本ＩＤに対応する正本の識別情報などといった固定的な属性情報を組み合わせたもの（或いはこれに更に乱数値を組み合わせてもよい）のハッシュ値を、副本ＩＤとして利用することもできる。

文書管理サーバ１０は、図３に示すように、正本文書ＤＢ１１，正本文書登録部１３，副本ｓｃ提供部１５，副本文書提供部１７及びログ管理部１９を備える。

正本文書ＤＢ１１は、クライアント端末２０からアップロードされた電子文書を、正本（原本）として保存し、管理するデータベースである。本システムの枠組みでは、正本文書ＤＢ１１に保存された電子文書のみが正本として取り扱われる。この枠組みでは、仮にその電子文書のコピーがネットワーク上に存在しても、それは正本とは関係がないものとして扱うことができる。特に、上述のようにクライアント端末２０のビューワ２２が、副本文書のファイルをファイルシステム等に保存しないようにしておけば、正本の写しがネットワーク上に出回る可能性を大幅に低減できる。

正本文書登録部１３は、クライアント端末２０から正本として登録すべくアップロードされた電子文書を、正本文書ＤＢ１１に登録する。このとき、正本文書登録部１３は、登録する正本の電子文書ファイルに対し、「文書ＩＤ」と呼ぶ一意な識別情報を付与する。文書ＩＤとしては、例えば十分に長い乱数値やその電子文書の十分に長いハッシュ値などを用いることができる。

副本ｓｃ提供部１５は、ユーザからの操作要求に応じ、正本文書ＤＢ１１内の電子文書に対する副本ｓｃをそのユーザに対して発行する。副本文書提供部１７は、ユーザからの操作要求に応じ、要求対象の電子文書の副本ファイルを作成し、そのユーザへと提供する。

ログ管理部１９は、クライアント端末２０を介したユーザからの操作要求に応じて文書管理サーバ１０が処理を行った場合に、その操作に関する情報をイベントログとして記録する。ログ管理部１９には、図４に示すように、個々の操作イベントごとに、その操作の対象となる正本電子文書の文書ＩＤ、その操作イベントにおいて副本ＩＤを提供したユーザ（この場合、その操作のために文書管理サーバ１０にアクセスしてきたユーザと同じ）のユーザＩＤ（宛先ユーザＩＤ）、そのイベントの種別、そのイベントの発生日時、そのイベントにおいてその宛先ユーザに提供した副本ＩＤ、及びそのイベントの契機となる要求に含まれていた副本ＩＤ（「旧副本ＩＤ」）を、ログレコードとして記録する。このログレコードによれば、副本ＩＤとそれに対応する正本の文書ＩＤが対応づけられる。またこのログレコードを調べれば、副本ＩＤに対し、文書の操作のためにこの旧副本ＩＤを用いたアクセスに対して文書管理サーバ１０が提供した新たな副本ＩＤが対応づけられるので、操作による副本ＩＤの変遷を把握することができる。このような副本ＩＤの変遷は、旧副本ＩＤから操作により新たな副本ＩＤが派生するという関係である。副本ＩＤの一意性から、異なる複数の旧副本ＩＤから同じ副本ＩＤが派生することはないので、この派生関係はツリー状となる。図４に例示したログデータが示す副本ＩＤの派生関係を図５に示す。

文書管理サーバ１０は、例えばウェブサーバとウェブアプリケーションを用いて構築することができる。この場合、文書管理サーバ１０は、ユーザインタフェース画面としてウェブページをクライアント端末２０に提供する。

次に、この文書利用管理システムの仕組みを具体的に示すために、図４に例示したログデータが形成された時のシステムの動作を、図６を参照して説明する。

まず、ユーザＰ０１がクライアント端末２０−Ｐ０１から文書管理サーバ１０に対し、電子文書"Ｏ"１００の登録要求を行う。電子文書１００は、クライアント端末２０−Ｐ０１のローカルのファイルシステム内にあるものでも、ネットワーク上のファイルサーバや文書サーバにあるものでもよい。この登録要求は、例えばビューワ２２が提供するユーザインタフェースを介して行う。このユーザインタフェースは、例えばファイルシステムやネットワークファイルシステムのツリー状のディレクトリを表示するディレクトリ画面を提供し、このディレクトリ画面上でユーザＰ０１から登録対象の電子文書の選択を受け付ける。また、ユーザインタフェースが検索画面を提供し、その検索画面に対しユーザが入力した検索条件に合致する電子文書をローカルのファイルシステム及び／又はネットワーク上のファイルサーバから検索してその検索結果をユーザに提示し、その中からユーザに登録対象の文書を選択させてもよい。クライアント端末２０が発する登録要求には、ユーザＰ０１を特定するユーザＩＤと、対象となる電子文書１００（実体データ又はその実体データに対するリンク情報）が含まれる。ここで登録要求に含めるユーザＩＤとしては、クライアント端末２０−Ｐ０１又は本システムに対してユーザＰ０１がログインした際に提示したユーザＩＤを用いることができる。

登録要求を受けた文書管理サーバ１０では、正本文書登録部１３が、その要求に含まれる電子文書１００の実体データを取得し（要求に実体データへのリンクが含まれる場合は、そのリンクを用いて実体データを取得し）、その電子文書に一意な文書ＩＤ"Ｄ０１"を付与して、その電子文書１００の実体データを文書ＩＤ"Ｄ０１"と対応づけて正本文書ＤＢ１１に登録する。ここで、クライアント端末２０から送られてきた電子文書１００が、このシステムの文書フォーマット（例えばＰＤＦ）でない場合は、文書管理サーバ１０がその電子文書１００をシステムの文書フォーマットに変換してから正本文書ＤＢ１１に登録してもよい。

次に副本ｓｃ提供部１５が、一意な副本ＩＤ"ａ"を生成し、その副本ＩＤ"ａ"及びその文書管理サーバ１０のホスト名などを含んだ副本ｓｃ１０２を生成し、この副本ｓｃ１０２を、例えば登録要求に対する応答に含める形で、クライアント端末２０−Ｐ０１に送信する。また、文書管理サーバ１０では、ログ管理部１９が、以上の登録イベントについてのログレコードとして、図４に示したテーブルの２行目のレコードを記録する。このレコードでは、操作イベントの対象となる正本電子文書の文書ＩＤは"Ｄ０１"であり、その操作イベントにおいて生成した新たな副本ＩＤの宛先ユーザのＩＤは"Ｐ０１"である。また、操作イベントの種類は"文書登録"であり、そのイベントの日時は"2006/03/03/10:00:00"である。また、そのイベントの結果として宛先ユーザに提供した副本ＩＤは"a"であり、旧副本ＩＤは、このケースではその操作の要求に副本ＩＤは含まれないので"NULL"（なし）である。

登録成功の応答と共に副本ｓｃ１０２を受けとったクライアント端末２０−Ｐ０１は、その副本ｓｃ１０２をファイルシステム２４−Ｐ０１に登録する。このとき、ファイルシステム２４−Ｐ０１内の元の電子文書１００を削除し、この代わりに副本ｓｃ１０２のファイルを保存するようにしても良い。このようにすれば、電子文書１００の正本の実体データは文書管理サーバ１０にしか存在しないことになり、その正本の原本性が保証しやすくなる。

なお、ユーザがネットワーク上のファイルサーバにある電子文書１００の登録を文書管理サーバ１０に要求した場合、文書管理サーバ１０は、副本ｓｃ１０２をそのファイルサーバへと送る。これを受けたファイルサーバは、自分が保持する電子文書１００を削除し、その代わりに副本ｓｃ１０２を保管するようにしてもよい。この場合、ユーザＰ０１は、ネットワークファイルシステムのディレクトリ画面などで、そのファイルサーバ上にある副本ｓｃ１０２を見ることができる。

ここで、ユーザＰ０１が、電子文書"Ｏ"１００の副本ｓｃ１０２を電子メールに添付するなどの方法でユーザＰ０３に送信したとする。すると、ユーザＰ０３のクライアント端末２０−Ｐ０３のファイルシステム２４−Ｐ０３には、電子文書"Ｏ"を指し示すショートカットとして副本ｓｃ１０２が保存される。ユーザＰ０３が電子文書"Ｏ"を閲覧するために、ビューワ２２で副本ｓｃ１０２をオープンし、閲覧の指示を入力すると、ビューワ２２がその副本ｓｃ１０２から副本ＩＤ"ａ"と文書管理サーバ１０のホスト名を取り出し、そのホスト名を用いて文書管理サーバ１０にアクセスし、副本ＩＤ"ａ"を伴った閲覧要求１０４を送信する。この閲覧要求１０４には、ユーザＰ０３のユーザＩＤが含まれる。以降の各段階でも、ユーザが文書管理サーバ１０に要求その他のデータを送信する場合には、その要求にそのユーザのＩＤが含まれるか、あるいはその送信の以前にユーザが文書管理サーバ１０にログインしているなどにより、文書管理サーバ１０はどのユーザからのアクセスなのかを把握することができる。

閲覧要求１０４を受け取った文書管理サーバ１０では、副本文書提供部１７が起動する。副本文書提供部１７は、その閲覧要求１０４に伴う副本ＩＤ"ａ"を、例えば「提供した副本ＩＤ」の値として持つレコードをログ管理部１９から求め、そのレコードの文書ＩＤ"Ｄ０１"が示す電子文書"Ｏ"の実体データを正本文書ＤＢ１１から求め、そのコピーを作成する。そして、副本文書提供部１７は、更新用の副本ＩＤ"ｂ"を生成し、これをそのコピーのファイルの副本ＩＤ属性にセットすることで副本ファイル１０６を生成し、この副本ファイル１０６を、閲覧要求１０４に対する応答としてクライアント端末２０−Ｐ０３に返す。

またログ管理部１９は、図４のテーブルの３行目のようなログレコードを作成して記録する。閲覧要求１０４には副本ＩＤ"ａ"が含まれ、それに応じて提供した副本ファイル１０６には副本ＩＤ"ｂ"が含まれるので、このログレコードでは「旧副本ＩＤ」が"ａ"となり、「提供した副本ＩＤ」が"ｂ"となる。また、ログレコードには、対象となる文書ＩＤとして"Ｄ０１"が、宛先ユーザＩＤとして"Ｐ０３"が、イベントとして"副本提供"が記録される。

クライアント端末２０−Ｐ０３のビューワ２２は、送られてきた副本ファイル１０６中の文書の実体データを開いて表示する。ここで、その副本ファイル１０６には保存不可の属性が付されているので、ビューワ２２はその副本ファイル１０６をファイルシステム２４−Ｐ０３には保存しない。例えばビューワ２２は、その副本ファイル１０６の保存が選択できないようにしたユーザインタフェース画面を提供する。またビューワ２２は、ファイルシステム２４−Ｐ０３中に保存された副本ｓｃ１０２の中の副本ＩＤ"ａ"を、その副本ファイル１０６に含まれる更新用の副本ＩＤ"ｂ"に書き換えることで、電子文書"Ｏ"を指すショートカットを更新する。これにより、ファイルシステム２４−Ｐ０３中の副本ｓｃ１０２が、副本ＩＤ"ｂ"を含んだ副本ｓｃ１０８に置き換えられる。

ユーザＰ０３電子文書"Ｏ"の副本ｓｃを他のユーザに送信する場合を考えると、その送信が副本１０６の閲覧の前であれば副本ＩＤ"ａ"の副本ｓｃ１０２が送信されるが、副本閲覧の後ならば副本ＩＤ"ｂ"の副本ｓｃ１０８が送信されることになる。

次に、ユーザＰ０４が文書管理サーバ１０で管理された電子文書を取得する場合を考える。この場合、ユーザＰ０４は、クライアント端末２０−Ｐ０４から文書管理サーバ１０に対し、ディレクトリ画面又は検索画面を要求する。文書管理サーバ１０は、正本文書ＤＢ１１内に登録された電子文書群を選択するためのそれらディレクトリ画面又は選択画面を生成し、それをクライアント端末２０−Ｐ０４に返す。ユーザＰ０４がそれらの画面を介して所望の電子文書"Ｏ"を見つけ、その取得を指示すると、クライアント端末２０は、その電子文書"Ｏ"の識別情報（例えば文書ＩＤ"Ｄ０１"）を伴う取得要求１１２を文書管理サーバ１０に送る。これを受け取った文書管理サーバ１０では、副本ｓｃ提供部１５が新たな副本ＩＤ"ｃ"を生成し、これを含んだ副本ｓｃ１１４を作成してクライアント端末２０−Ｐ０４に返す。そして、ログ管理部１９が、このショートカット提供のイベントについてのレコード（図４に示したテーブルの４行目）を作成して記録する。

クライアント端末２０−Ｐ０４は、受け取った副本ｓｃ１１４をファイルシステム２４−Ｐ０４に保存する。ユーザがこの副本ｓｃ１１４を選んで閲覧を指示すると、ビューワ２２は副本ＩＤ"c"を伴った閲覧要求１１６を発行する。これに応じ文書管理サーバ１０は、その副本ＩＤ"ｃ"に対応する正本のコピーを作成するとともに、更新用の副本ＩＤ"ｄ"を生成してそのコピーのファイルの属性にセットすることで副本ファイル１１８を生成し、クライアント端末２０−Ｐ０４に返す。また、ログ管理部１９は、図４のテーブルの５行目に示すようなログレコードを記録する。

クライアント端末２０−Ｐ０４のビューワ２２は、その副本ファイル１１８を開いて表示すると共に、ファイルシステム２４−Ｐ０４内の副本ｓｃ１１４の副本ＩＤを副本ファイル１１８に含まれる更新用の副本ＩＤ"ｄ"へと変更する。これにより、クライアント端末２０−Ｐ０４が持つ電子文書"Ｏ"へのショートカットは副本ｓｃ１２０となる。

ユーザＰ０４が電子文書"Ｏ"の副本閲覧後に副本ｓｃ１２０をユーザＰ０８に送信し、ユーザＰ０８がその副本ｓｃ１２０を用いて閲覧要求１２２を行うと、文書管理サーバ１０は更新用の副本ＩＤ"ｅ"を含む副本ファイル１２４をクライアント端末２０−Ｐ０８に提供し、図４のテーブルの６行目に示すログレコードを記録する。クライアント端末２０−Ｐ０８のビューワ２２は、受け取った副本ファイル１２４を開いてユーザに提供し、ファイルシステム２４−Ｐ０８内の副本ｓｃの副本ＩＤを、その更新用の副本ＩＤ"ｅ"へと変更する。

図４に例示したログデータには、操作イベントにおける副本ＩＤの提供先のユーザＩＤを記録したが、これに加え、そのイベントの契機となった要求を発したユーザＩＤを合わせて記録してもよい。以上の例では、イベントの契機となる要求を発したユーザと、そのイベントにおいて新たに生成した副本ＩＤの提供先とは同一であるが、それらが異なる場合には、上述のように両者のユーザＩＤを記録することが好適である。

以上、実施形態のベースとなる文書利用管理システムの構成と処理内容について説明した。このシステムの特徴をまとめると以下のようになる。
・電子文書の正本が文書管理サーバに登録される。
・ユーザに対しては、電子文書の実体データの代わりに副本ｓｃが提供される。副本ｓｃには、副本ＩＤが含まれる。なお、副本ｓｃを用いて文書管理サーバ１０上の正本に関する何らかの操作を行う場合、正本を管理する文書管理サーバ１０を特定する必要がある。このために、副本ｓｃには、対応する正本を管理する文書管理サーバ１０を特定する情報を含めてもよい。
・文書管理サーバは、提供した副本ｓｃの副本ＩＤと、それに対応する正本との対応関係を管理する。（上述の例では、副本ＩＤ−正本対応関係をログ管理部１９のログレコードに含める形で管理したが、対応関係のデータは、両者の対応が分かればどのようなデータ形式であってもよい。）
・文書管理サーバ上の文書に対して何らかの操作を行う際には、操作を行う端末が持つ副本ｓｃの副本ＩＤがそのサーバに送られる。
・文書管理サーバは、端末から受け取った副本ＩＤに対応する正本を副本ＩＤ−正本対応関係に基づき特定し、正本に関して、要求された操作を行う。
・文書管理サーバは、正本に関する操作を行った場合、新たな副本ＩＤを生成し、この副本ＩＤを操作を要求したクライアント端末に送る。これを受け取ったクライアント端末は、要求に用いた副本ｓｃの副本ＩＤを、受け取った新たな副本ＩＤへと更新する。
・文書管理サーバは、クライアント端末からの要求に含まれていた副本ＩＤと、その要求に係る操作を行ったことにより生成した新たな副本ＩＤとの対応関係である、副本ＩＤ派生関係を管理する。
・文書管理サーバは、クライアント端末から電子文書の閲覧など、電子文書の実体データを必要とする操作を指示された場合、正本のコピーである副本文書データを提供する。副本文書データは、クライアント端末上で動作するビューワの管理するメモリ上の領域にのみ存在し、ディスク上には保存できない設定となっている。

以上の例では、文書管理サーバ１０が記録するログレコードとして図４に示すものを例示したが、これは一例に過ぎない。例えば、ログレコードには、宛先ユーザＩＤに加え、又はこれに代えて、その宛先ユーザのユーザ名を記録してもよい。ユーザ名は、クライアント端末２０から得ることができる。また、宛先ユーザの所属組織名を記録してもよい。所属組織名は、例えば、宛先ユーザの所属する企業や部署などの組織の名称である。所属組織名は、例えば、本システムに接続された組織情報管理データベースから得ることができる。組織情報管理データベースは、組織の各構成員の名前、所属部署、役職、連絡先などを管理する一種のディレクトリサーバである。企業内のシステムでは、このような組織情報管理データベースを備えることが多いので、そのデータベースから情報を取得すればよい。また、ユーザ名と所属組織名の情報として、ＩＴＵ−Ｔが策定したＸ．５０９証明書の識別名（ＤＮ:Distinguished Name）を用いてもよい。ＤＮは、例えばＬＤＡＰ(Lightweight Directory Access Protocol)サーバなどから取得するようにしてもよい。また、ログレコードには、宛先ユーザが用いているクライアント端末２０のＩＰ(Internet Protocol)アドレスやＭＡＣ(Media Access Control)アドレスを記録してもよい。ＩＰアドレスやＭＡＣアドレスは、クライアント端末２０からのアクセスを受け付けるに当たって取得することができる。

また、上述の文書利用管理システムの例では、文書の登録や、副本ｓｃの取得、文書閲覧などといった操作を例示したが、これに限らず、正本の文書に関連する操作のうち、システムとして把握しておきたい操作の全てを、上記特徴的な処理の対象とすることができる。

なお、以上及び以下に示すシステムにおいて、閲覧その他の要求の際にクライアント端末２０から文書管理サーバ１０へと送るユーザＩＤその他の情報は、例えばＨＴＴＰリクエストヘッダに設定して送信してもよいし、ＸＭＬで記述したＨＴＴＰリクエストに組み込んで送信してもよい。クライアント端末２０から文書管理サーバ１０へ文書を送信する場合は、それらの送信情報は例えばその文書のメタデータの一部となる。

以下、このような副本ｓｃの枠組みを利用して、階層的な組織内での文書展開を管理するためのシステムについて説明する。以上に説明したシステムでは、文書が閲覧されるだけであったが、以下のシステムでは、文書に対して更新が加えられたり、文書に対して添付文書等の追加データが付加されたりする場合も考慮する。

このシステムでは、電子文書についての副本ＩＤの派生関係のツリーのノード（副本ＩＤ）の中に、組織の部門を代表する基点ノードを設定できるようにし、部門内で共有すべき電子文書又はそれに関連するデータをその基点ノードに対応づけて保存する。そして、部門の構成員は、基点ノードに対応づけて保存された電子文書や関連データを閲覧するようにすると共に、部門の構成員が行ったその電子文書に対する更新や追加のデータは、その基点ノードに対応づけて保存するようにする。このようにすることで、部門に属する各構成員は、その部門で共有すべき電子文書やその電子文書に対する更新や追加のデータにアクセスすることができる。

このような制御を実現するためのシステムの概略構成を図７に示す。図７のシステムは、図１に示したシステムに対し、組織情報管理データベース４０を追加したものである。組織情報管理データベース４０は、上述のように組織の各構成員の情報と、組織の階層的な部門構成の情報を保持する。例えば、組織情報管理データベース４０には、図８に示すように、各構成員ごとに、一意なユーザＩＤ、氏名、所属部門の情報項目が登録される。文書管理サーバ１０ａ又はクライアント端末２０は、必要に応じて、組織情報管理データベース４０から各ユーザの情報を取得する。

図７のシステムにおける文書管理サーバ１０ａの内部構成を図９に示す。図９に示す文書管理サーバ１０ａにおいて、文書ＤＢ１１ａには、派生関係ツリー（図４参照）のルートとなる電子文書（正本）だけでなく、その正本に対する更新又は追加のデータが蓄積される。文書登録部１３ａは、正本に対する更新又は追加のデータの登録要求に応じ、それらの情報を文書ＤＢ１１ａに登録する処理を行う。また、閲覧要求を受けた時の副本提供部１７ａの処理内容が、図３の例における副本提供部１７ａとは異なる。その他の要素は、図３に示したものと同様でよい。

文書に対して加えられる変更には、大まかに分けて、文書本体の内容を変更する「更新」と、文書本体に対して添付文書その他のデータを追加する「追加」とが考えられる。以下では、まず「更新」の場合を例にとって説明する。

文書本体の「更新」を管理する方式には、それぞれの更新後の文書の完全なデータを保持する方式（以下全体管理方式）や、更新前後の差分のみを保持する方式（以下差分管理方式）がある。差分管理方式は、オリジナルの文書に対し、更新の行われた順に各更新時の差分を反映していくことで、最新の文書を得ることができる。以下では、全体管理方式を代表例として説明する。

全体管理方式では、文書登録部１３ａは、ユーザから正本（原本）文書を登録するための文書登録要求を受けた場合、図１０に示す処理を実行する。

文書登録部１３ａは、文書登録要求に伴ってユーザから受け取った文書に対し一意な文書ＩＤを付与すると共に、原本であることを示す所定のバージョン番号を付与し、その文書をその文書ＩＤ及びバージョン番号と対応づけて文書ＤＢ１１ａに登録する（Ｓ１）。また文書登録部１３ａは、その要求を行ったユーザの部門属性を取得する（Ｓ２）。ユーザの部門属性は、ユーザが文書登録要求に伴って文書管理サーバ１０ａへと送信してもよいし、文書管理サーバ１０ａが、文書登録要求に伴って送られてきたユーザ情報を用いて、組織情報管理データベース４０から取得してもよい。また、文書登録部１３ａは、一意な副本ＩＤを生成し、この副本ＩＤを含んだ副本ｓｃを生成し、この副本ｓｃを要求元のユーザへと送信する（Ｓ３）。そして、ログレコードを作成し、派生関係の情報を登録する（Ｓ４）。ここで作成するログレコードには、図４に示すような項目に加え、イベントの契機となった要求を行ったユーザ（すなわち、宛先ユーザＩＤが示すユーザ）の部門属性の値と、文書ＤＢ１１ａに格納した文書のバージョン番号とを更に登録する（Ｓ５）。このようにして作成されるログレコード群は、例えば図１３に示すようなものとなる。なお、図１０におけるステップの実行順序は一例に過ぎず、相互に依存関係のないステップ同士なら、どのような順序で実行してもよい。

次に、全体管理方式での、ユーザから文書の閲覧要求を受けた際の副本提供部１７ａの処理手順を、図１１を参照して説明する。

閲覧要求は上述のように副本ｓｃを用いて行われる。副本ｓｃに含まれる副本ＩＤがその閲覧要求に伴ってクライアント端末２０から文書管理サーバ１０ａに送られてくる。その副本ＩＤを受け取った副本提供部１７ａは、その副本ＩＤから派生関係ツリーをルートへ１ノード（ログレコード）ずつ遡り、そのノードにバージョン属性値（バージョン番号）がセットされているかどうかを調べ、バージョン属性値がセットされているノードに行き当たるまで、この遡及を繰り返す（Ｓ１１）。このシステムでは、組織の階層的な構造における部門の基点ノードにその部門で共有すべきバージョンの値を記録し、基点ノード以外のノードにはバージョンの値は記録しない。したがって、このステップＳ１１では、閲覧要求を発したユーザに提供すべきバージョンを特定するために、基点ノードを探索するのである。そして、この探索により見つかったノードのバージョン属性値（バージョン番号）に対応する文書を文書ＤＢ１１ａから取得する（Ｓ１２）。ここで、文書管理サーバ１０ａが付与するバージョン番号が、同一の原本から派生したバージョン群の中での一意性しか持たない場合は、ステップＳ１２では、バージョン番号と原本の文書ＩＤとの組合せに対応する文書データを文書ＤＢ１１ａから検索する。そして、副本提供部１７ａは新たな副本ＩＤを生成し、この副本ＩＤとステップＳ１２で取得した文書とを含んだ副本ファイルを生成し、閲覧要求を行ったユーザに提供する（Ｓ１３）。そして、提供した副本ＩＤの情報を含むログレコードを生成し、ログ管理部１９に記録する（Ｓ１４）。ここで生成するログレコードには、部門属性やバージョン属性の値は登録しない。

また、副本提供部１７ａは、ステップＳ２と同様にして、閲覧要求を行ったユーザの部門属性の値を取得し（Ｓ１５）、ステップＳ１１で探索されたノードの部門属性値と、ステップＳ１５で取得したユーザの部門属性値とが一致するかどうかを判定する（Ｓ１６）。両者が一致すれば、それはステップＳ１１で見つかったノードが、そのユーザが属する部門の基点ノードであるということであり、この場合は何も行わずに処理を終了する。

一方、ステップＳ１６で、ノードの部門属性値がユーザの部門属性値と一致しないと判定された場合、そのノードは、ユーザが属する部門より１階層上の部門の基点ノードであるということになる。この場合、この閲覧要求に応じて生成したノード（ログレコード）が、そのユーザの属する部門における最初のノードということになる。したがって、副本提供部１７ａは、このノード（ログレコード）に対し、そのユーザの部門属性の値と、ステップＳ１２で取得したバージョン属性の値とを登録する（Ｓ１７）。これによりそのノードがその部門の基点ノードとして設定されたことになる。そして、副本提供部１７ａは処理を終了する。

次に、全体管理方式において、ユーザから文書の更新要求を受けた場合の文書登録部１３ａの処理手順を、図１２を参照して説明する。

ユーザは、閲覧要求により取得した副本ファイルをビューワ２２で開き、文書内容に編集を加えることができる。ビューワ２２は、文書更新指示を受け付けるユーザインタフェースを備え、ユーザから文書更新の指示を受けると、編集された文書（更新文書と呼ぶ）を伴った更新要求を文書管理サーバ１０ａに送る。更新要求を受け取った文書管理サーバ１０ａは、更新文書に新たなバージョン番号を付与し、文書ＤＢ１１ａに登録する（Ｓ２１）。また、文書登録部１３ａは、上述のステップＳ２と同様にしてその要求を行ったユーザの部門属性を取得し（Ｓ２２）、一意な副本ＩＤを生成し、この副本ＩＤを含んだ副本ｓｃを要求元のユーザへと送信する（Ｓ２３）。そして、ログレコードを作成し、派生関係の情報を登録する（Ｓ２４）。文書登録要求に対するログレコードには、上述のように、イベントの契機となった要求を行ったユーザの部門属性の値と、文書ＤＢ１１ａに格納した文書のバージョン番号と登録したが、更新要求に対応するログレコードには、部門属性の値もバージョン番号も登録しない。その代わりに、文書登録部１３ａは、その更新要求に伴う副本ＩＤを起点に派生関係ツリーを遡り、ユーザの部門属性値と同じ部門属性値を持つノード、すなわちユーザの属する部門の基点ノードを探索し（Ｓ２５）、その基点ノードのバージョン属性の値を、ステップＳ２１で更新文書に対して付与したバージョン番号へと変更する（Ｓ２６）。

このシステムにおける処理の流れを、具体例を用いて説明する。この具体例では、図１３に示すように、「本社」の下に「Ａ事業所」と「Ｂ事業所」という２つの部門が存在する組織構造を例にとる。そして、本社で作成された文書がＡ事業所とＢ事業所にそれぞれ渡され、Ａ事業所とＢ事業所とでそれぞれ個別に更新が加えられる場合を考える。図１３には、組織構造を示す組織図に対応付けて、派生関係ツリー２００ａが示されている。図１３では、説明が分かりやすくなるよう、派生関係ツリー２００ａの各ノード２０２，２０４，２０６には、それぞれ、そのノードに対応するイベントで発行した副本ＩＤの値、イベント名、及び副本ＩＤの発行先のユーザの部門属性の情報を「副本ＩＤ：イベント名／部門属性」という表記方式で示している。また、この例では、副本ＩＤの値は、親子関係が明確に分かるように、親の副本ＩＤの後ろに、その親から派生する子らの間で一意な値を追加したものとしている。

図１３の例は、本社に属するユーザ１が文書の原本を作成して文書管理サーバ１０ａに登録した場合を示している。その原本に対し、文書管理サーバ１０ａは、バージョン番号「Ｖ１」２０３を付与すると共に、新たに生成した副本ＩＤ「ＩＤ１」を含む副本ｓｃをユーザ１に返す。以上のイベントに関する情報が、ノード２０２として図示される。このノード２０２に対応するログ管理部１９内のログレコードは、図１４に示すテーブルの上から２行目のような「文書登録」イベントのレコードとなる。

ユーザ１が、その副本ｓｃ「ＩＤ１」を、例えば電子メールその他の伝達手段により、Ａ事業所に属するユーザ２とＢ事業所に属するユーザ３とにそれぞれ提供したとする。ここで、例えばユーザ２がその副本ｓｃ「ＩＤ１」を用いて文書管理サーバ１０ａに対して閲覧要求を発すると、文書管理サーバ１０ａの副本提供部１７ａは、図１１に示す処理を実行することで、副本ＩＤ「ＩＤ１」を「提供した副本ＩＤ」に含むレコード（ノード）を見つけ、このノードから派生関係ツリーを遡る。この場合、このノード自体が派生関係ツリーにおけるルートであり、バージョン属性値（「Ｖ１」）を含んでいるので、ステップＳ１１でこのノードが見つかる。副本提供部１７ａは、そのノードに含まれるバージョンＶ１に対応する文書データを文書ＤＢ１１ａから読み出し、その文書データを含み且つ新たに生成し副本ＩＤ「ＩＤ１１」を含んだ副本ファイルをユーザ２に提供する。ここで、ユーザ２の部門は「Ａ事業所」であるのに対し、ステップＳ１１で見つかったノードの部門属性は「本社」なので、この閲覧要求に対応するノードが、「本社」の下位部門である「Ａ事業所」の基点ノードとなり、このノードには、その閲覧の際に取得したバージョン「Ｖ１」と、部門「Ａ事業所」とが記録される（図１４のテーブルの上から３行目のレコード参照）。ユーザ３が副本ｓｃ「ＩＤ１」を用いて閲覧要求を行った場合も、同様にして副本ＩＤ「ＩＤ１２」と、バージョンＶ１の文書とを含んだ副本ファイルがユーザ３に提供され、その副本ＩＤ「ＩＤ１２」に対応するノードが「Ｂ事業所」の基点ノードに設定される（図１４のテーブルの最下行のレコード参照）。図１３に例示した派生関係ツリー２００ａは、この時点での状態を示している。

ここで、Ａ事業所のユーザ２が、閲覧要求に応じて取得した副本ファイル中の文書データに対し、ビューワ又は文書エディタなどのクライアントプログラムを用いて編集を加え、その編集結果の文書データを伴った更新要求を文書管理サーバ１０ａに送ったとする。この場合、文書管理サーバ１０ａは、図１５に示すように、その更新要求に伴った文書データに対して新たなバージョン番号「Ｖ１１１」（この例では、バージョン番号を副本ＩＤに対応づけている）を付与して文書ＤＢ１１ａに登録するとともに、その更新要求に対して新たな副本ＩＤ「ＩＤ１１１」を含んだ副本ｓｃを返す。そして、副本ＩＤ「ＩＤ１１１」のノード２０８を派生関係ツリーに追加すると共に、Ａ事業所の基点ノード２０４のバージョン属性値を、更新文書のバージョン「Ｖ１１１」へと更新する。図１５の派生関係ツリー２００ｂは、この時点での派生関係を示す（部門属性値がないノードについては"／"以降を省略している）。

次に、同じユーザ２が、副本ｓｃ「ＩＤ１１１」を用いて閲覧要求を行うと、文書管理サーバ１０ａは、派生関係ツリー２００ｂを「ＩＤ１１１」からルートへと遡り、バージョン属性値が設定されている最初のノードとしてノード２０４を見つける。そして、文書ＩＤ「Ｄ０１」のバージョン群の中で、そのノード２０４のバージョン属性値「Ｖ１１１」に対応する文書データを文書ＤＢ１１ａから検索し、新たに生成した副本ＩＤ「ＩＤ１１１１」とその文書データとを含む副本ファイルをユーザ２に提供する。この時点でのログ管理部１９のログデータは、図１６に示すようなものとなる。なお、この副本ファイルを受け取ったユーザ２のクライアント端末２０では、文書「Ｄ０１」に対応する副本ｓｃの副本ＩＤが「ＩＤ１１１１」に更新されている。

この後、Ｂ事業所のユーザ３が、閲覧要求に応じて取得した副本ファイル「ＩＤ１２」に対して更新を行ってその更新結果を文書管理サーバ１０ａに登録し、更にその更新結果を閲覧したとする。この場合、派生関係ツリーは、図１７のツリー２００ｃのようになる。この派生関係ツリーでは、Ｂ事業所の基点ノード２０６には、ユーザ３による更新イベント２１０により登録された新バージョンＶ１２１のバージョン番号が登録されており、その次のユーザ３による閲覧イベント２１２では、バージョンＶ１２１の文書データが提供される。

この後、ユーザ２が同じＡ事業部のユーザ１０に副本ｓｃ「ＩＤ１１１１」を電子メール等で送り、ユーザ１０がその副本ｓｃを用いて閲覧と更新を行ったとする。この場合、閲覧要求に応じて文書管理サーバ１０ａは、派生関係ツリー２００ｃを遡ってＡ事業部の基点Ａノード２０４に対応づけられたバージョンＶ１１１の文書データと、新たな副本ＩＤ「ＩＤ１１１１１」を含んだ副本ファイルをユーザ１０に提供する。ユーザ１０がその副本ファイルに対して編集を行い、その編集結果を伴う更新要求を発すると、文書管理サーバ１０ａは、その編集結果に新たなバージョン番号「Ｖ１１１１１１」を付与して文書サーバ１１ａに登録し、Ａ事業所の基点ノード２０４のバージョン属性値をそのバージョン番号「Ｖ１１１１１１」に更新する。そして、新たな副本ＩＤ「ＩＤ１１１１１１」を含んだ副本ｓｃをユーザ１０に返す。この時点の派生関係ツリーは図１８に示すようなものとなり、これに対応するログデータは図１９に示すようなものとなる。

またこの後、ユーザ２が副本ｓｃ「ＩＤ１１１１」を用いて再度同じ文書「Ｄ０１」の閲覧を行ったとする。この場合、文書管理サーバ１０ａは、派生関係ツリー２００ｄを「ＩＤ１１１１」から遡り、Ａ事業所の基点ノード２０４のバージョン属性値「Ｖ１１１１１１」を取得し、新たな副本ＩＤ「ＩＤ１１１１２」とそのバージョンの文書とを含む副本ファイルをユーザ２に提供する。これにより、ユーザ２は、ユーザ１０による更新の後のバージョンを閲覧することになる。この時点の派生関係ツリーは図２０に示すようなものとなる。

以上では、ユーザから文書登録要求を受けた際に、文書管理サーバ１０ａがその要求に対応するノードを基点ノードとして、部門属性値を自動設定した。また、ユーザから閲覧要求を受けた際に、その要求が下位部門での基点ノードに当たるかを、文書管理サーバ１０ａが派生関係ツリーを遡って調べることで判定し、基点ノードに対して部門属性値を設定した。しかし、このような処理は必須のことではない。この代わりに、例えば、文書登録要求や閲覧要求を行うユーザが、自分が部門の基点であることを宣言する操作をクライアント端末２０にて行い、これに応じてクライアント端末２０が文書管理サーバ１０ａに対してそのユーザの部門属性値と基点である旨を示す情報とを送り、これに応じ文書管理サーバ１０ａがその部門属性値を当該要求のノードに設定してもよい。

また、一人のユーザが複数の部門においてそれぞれの役割を持つ場合がある。例えばＡ事業所のリーダが同時に本社（経営陣）の構成員であるように、下位部門のリーダが上位部門の構成員である場合がその一例である。このような場合、ユーザは、文書管理サーバ１０ａに対して要求を行う際、自分がどちらの部門に属するかを指定するようにするようにすることも好適である。例えば、文書管理サーバ１０ａが、要求元のユーザの部門属性を組織情報管理サーバ４０から調べた際に、複数の値が存在した場合には、どの部門の構成員としてその要求を発したのかをユーザに対して問い合わせてもよい。また、ユーザが要求を発する際に、クライアント端末２０が、そのユーザの部門属性を組織情報管理サーバ４０から取得し、部門属性値が複数ある場合は、その中からユーザに選択させるようにしてもよい。この場合、選択された部門属性値が要求に伴って文書管理サーバ１０ａに送られる。

また、以上の例は、文書の更新を全体管理方式で行う場合の例であったが、文書更新は他の方式でも可能である。例えば、更新の前後の文書の差分データを記録する方式（差分管理方式）も考えられる。差分データは、クライアント端末２０上の、ビューワ２２或いは文書エディタなどのアプリケーションが作成してもよいし、文書管理サーバ１０ａが作成してもよい。以下では、前者の場合の実施例を説明する。

この実施例では、図２１に示すように、派生関係ツリーにおけるルートノード３０２、すなわち原本の文書登録を示すノードに、原本の文書ＩＤ「Ｄ０１」（又はその原本の文書データそのもの）３３２を持たせる。図２１に示す派生関係ツリー３００は、全体管理方式の実施例の図１８に示した派生関係ツリー２００ｄが示す状態を、差分管理方式で表現した場合の例である。この例では、「本社」の下位の部門「Ａ事業所」の基点ノード３０４に、その基点ノードの子孫の副本ＩＤを用いてその部門の構成員が行った更新の差分データ３３４を記録する。差分データは、クライアント端末２０上のビューワ２２等のアプリケーションが生成し、文書管理サーバ１０ａに送る。例えば、基点ノード３０４の子孫のノード３０８及び３１２で行われた更新の際の差分データ「Ｕ１１１」、「Ｕ１１１１１１」は、基点ノード３０４に対応づけて保存される。なお、差分データ「Ｕ１１１」は、原本「Ｄ０１」とノード３０８における更新結果の文書との差分であり、差分データ「Ｕ１１１１１１」は、ノード３０８における更新結果の文書とノード３１２における更新結果の文書との差分である。

この場合、例えば、ノード３１０の閲覧要求に対しては、文書管理サーバ１０ａは、ノード３０８からルートノード３０２へと順次派生関係ツリー３００を遡り、その過程で見つかる基点ノード３０４の差分データ「Ｕ１１１」（この時点では差分データ「Ｕ１１１１１１」は未登録）と、ルートノード３０２の原本「Ｄ０１」とを含んだ副本ファイルを要求元に提供する。この例では差分データは１つであるが、複数有る場合は、各差分データの時系列順の情報も含めて提供する。要求元のクライアント端末２０のビューワ２２は、原本に対し、各差分データを時系列順に適用することで、全ての更新を反映した文書を生成し、ユーザに提供する。ユーザが、提供された文書に対して更に編集を加え、更新要求の指示を行うと、ビューワ２２は、その更新内容（ビューワ２２が最初にユーザに呈示した文書と最終的な編集結果との差分）を示す差分データを伴った更新要求を文書管理サーバ１０ａに送る。

なお図２１の例では、Ｂ事業所の基点ノード３０６には、その子孫ノード３１４の更新の際の差分データ「Ｕ１２１」が登録されている。

次に、このような管理を実現するための、文書管理サーバ１０ａの処理について説明する。まず、差分管理方式において、ユーザから原本登録のための文書登録要求を受け取った場合の文書登録部１３ａの処理手順を、図２２を参照して説明する。図２２において、図１０の手順と同様のステップには同一符号を付して詳細な説明は省略する。

図２２の手順では、まず文書登録部１３ａは、文書登録要求に伴ってクライアント端末２０から送られてきた文書を原本として文書ＤＢ１１ａに登録する（Ｓ１ａ）。そして、副本ｓｃをクライアント端末２０に返し、ログレコードを生成すると共に（Ｓ３，４）、ステップＳ２で取得した要求元ユーザの部門属性を、生成したログレコード（ノード）に登録する（Ｓ５ａ）。

次に、図２３を参照して、差分管理方式において、ユーザから文書の閲覧要求を受けた際の副本提供部１７ａの処理手順を説明する。図２３において、図１１の手順と同様のステップには同一符号を付して詳細な説明は省略する。

この手順では、副本提供部１７ａは、閲覧要求に伴う副本ＩＤを起点に、派生関係ツリー３００を遡り、その遡及過程で行き当たる各基点ノードが持つ差分データを収集する（Ｓ１１ａ）。この収集の際、各差分データの時系列順の情報も求める。そして、ルートノード３０２が持つ原本を収集する（Ｓ１１ａ）。そして、原本と時系列順の差分データと、副本ＩＤとを含んだ副本ファイルを生成し、要求元のユーザに提供する（Ｓ１３）。その後、副本提供部１７ａは、ログレコードを生成し（Ｓ１４）、要求元のユーザの部門属性を求め（Ｓ１５）、求めたユーザの部門属性が、派生関係ツリー３００の遡及過程における起点からの直近の基点ノードの部門属性と一致するか否かを判定する（Ｓ１６ａ）。一致しなければ、その閲覧要求に対応するノードがそのユーザの属する部門の基点ノードとなり、そのノードに対応するログレコードに、そのユーザの部門属性値を設定し（Ｓ１７ａ）、処理を終了する。一致した場合は、処理を終了する。

次に、図２４を参照して、差分管理方式において、ユーザから文書の更新要求を受けた際の文書登録部１３ａの処理手順を説明する。図２４において、図１２の手順と同様のステップには同一符号を付して詳細な説明は省略する。

この手順では、文書登録部１３ａは、更新要求に伴って送られてきた差分データに対してＩＤ（例えば「Ｕ１１１」など）を付し、その差分データのＩＤに対応づけて、例えば文書ＤＢ１１ａなどの記憶装置に保存する（Ｓ２１ａ）。そして、要求元ユーザの部門属性の取得、副本ｓｃの提供、ログレコードの記録などの処理を行い（Ｓ２２〜Ｓ２４）、派生関係ツリーを遡ってそのユーザの部門属性と同じ部門属性を持つノードを探索し（Ｓ２５）、見つかったノードに対応するログレコードの差分ＩＤ属性の欄に、ステップＳ２１ａで付与したＩＤを追加する（Ｓ２６ａ）。

この構成では、差分データの発生時刻の情報はログレコードの日時の項目から得ることができ、この発生時刻から各差分データの時系列順序を求めることができる。

以上、差分管理方式の例を示した。以上の例では、閲覧要求があった際、文書管理サーバ１０ａは、派生関係ツリー３００をルートまで遡り、その間に現れる各基点ノードの差分データ、原本を収集した。この代わりに、基点ノードに対し、その祖先の各基点ノードの持つ差分データや原本を持たせるようにすれば、ルートまで遡る必要はなく、単に閲覧要求に伴う副本ＩＤから直近の基点ノードまで遡るだけでよい。この場合、閲覧要求に対する処理（図２３）のステップＳ１６ａで、その要求が基点ノードに対応すると判明した場合に、ステップＳ１１ａで収集した原本及び差分データを、ステップＳ１７ａでその閲覧要求のログレコードに対応づければよい。

また、以上の例では、更新前後の差分データはクライアント端末２０側で生成したが、これを文書管理サーバ１０ａで生成してももちろんよい。

以上説明した例では、部門の構成員が行った更新内容がその部門の基点ノードに集められ、閲覧要求の際にはその基点ノードにある更新内容を用いて副本ファイルが生成される。したがって、閲覧要求を行ったユーザは、自分の属する部門内での最新の更新を反映した文書を閲覧することができる。また、副本ｓｃが組織の階層構造に従って上位部門から下位部門へと伝達されていく場合、この実施例の枠組みによれば、ある部門に属するユーザに提供される文書には、その部門の直系上位の部門での更新と当該部門内での更新とが反映されるだけであり、それ以外の部門での文書の更新内容は反映されない。例えば、図２１の例でいえば、ノード３１６の閲覧要求に対しては、原本「Ｄ０１」とノード３１４での更新を示す差分データ３３６がユーザに提供され、そのノード３１６の直系上位にないノード３０４やその子孫のノードでの更新結果はユーザには提供されない。したがって、他部門の作業内容に惑わされるなどと行った弊害を低減できる。

以上の例は、文書本体を更新する場合における文書管理の例であったが、最初に登録された文書に対して、下位の部門で添付文書を順次追加していく方法で文書セット（１以上の文書からなる集合）を更新する方式にも、同様の管理が可能である。

この方式では、図２５に示すように、基点ノードに対して、その基点ノードの部門で共有する文書セットを対応づけて記録する。例えば、図２５の派生関係ツリー４００において、本社の基点ノードであるルートノード４０２には、原本である文書「Ｄ１」からなる文書セットＳ１が対応づけられている。このときユーザ１が得た副本ｓｃ「ＩＤ１」をＡ事業所のユーザ２に提供し、ユーザ２がこの副本ｓｃ「ＩＤ１」を用いて閲覧要求を行うと、文書登録部１３ａは、その副本ＩＤ「ＩＤ１」から遡った最初の基点ノードであるルートノード４０２に登録された文書セットＳ１を見つけ、そのその文書セットを含む副本ファイルをユーザ２に提供する。この閲覧イベントがノード４０４として派生関係ツリー４００に追加される。ここで、ノード４０４は、Ａ事業所の基点ノードとなり、ノード４０４から派生するノード４０８及び４１２で登録される添付文書「Ｄ１１１」、「Ｄ１１１１１１」は、このノード４０４の文書セットＳ１１に登録される。一方、ノード４１０の閲覧要求に対しては、派生関係ツリー４００を遡った際に最初に行き当たる基点ノード４０４の文書セットＳ１１がユーザに提供される。同様に、ノード４０６はＢ事業所の基点ノードとなり、ノード４１４で登録される添付文書「Ｄ１２１」はノード４０６の文書セットＳ１２に登録され、このノード４０６の子孫のノードでの閲覧要求に対しては、このノード４０６の文書セットＳ１１が提供される。

文書セットは、例えば、図２６に示すようにログレコードの一項目として登録することができる。なお、図２６は、図２５の派生関係ツリーと同じ時点のログデータを示している。

次に、このような管理を実現するための、文書管理サーバ１０ａの処理について説明する。まず、ユーザから原本文書登録要求を受け取った場合の文書登録部１３ａの処理手順を、図２７を参照して説明する。図２７において、図１０の手順と同様のステップには同一符号を付して詳細な説明は省略する。

図２７の手順では、まず文書登録部１３ａは、文書登録要求に伴ってクライアント端末２０から送られてきた文書にＩＤを付与して文書ＤＢ１１ａに登録する（Ｓ１ｂ）。そして、副本ｓｃをクライアント端末２０に返し、ログレコードを生成すると共に（Ｓ３，４）、ステップＳ２で取得した要求元ユーザの部門属性を生成したログレコード（ノード）の部門属性として登録すると共に、ステップＳ１ｂで付与したＩＤをそのログレコードの文書セット属性の欄に追加する（Ｓ５ｂ）。

次に、図２８を参照して、ユーザから文書の閲覧要求を受けた際の副本提供部１７ａの処理手順を説明する。図２８において、図１１の手順と同様のステップには同一符号を付して詳細な説明は省略する。

この手順では、副本提供部１７ａは、閲覧要求に伴う副本ＩＤを起点に、派生関係ツリー４００をルートへと遡り、文書セット属性の値を持つノード（すなわち基点ノード）を探索する（Ｓ１１ｂ）。そして、遡及過程で最初に見つけた基点ノードの文書セット属性に含まれる各文書を文書ＤＢ１１ａから取得し（Ｓ１２ｂ）、それら各文書と副本ＩＤとを含んだ副本ファイルを生成し、要求元のユーザに提供する（Ｓ１３）。その後、副本提供部１７ａは、ログレコードを生成し（Ｓ１４）、要求元のユーザの部門属性を求め（Ｓ１５）、求めたユーザの部門属性が、ステップＳ１１ｂで求めた基点ノードの部門属性と一致するか否かを判定する（Ｓ１６）。一致しなければ、その閲覧要求に対応するノードがそのユーザの属する部門の基点ノードとなり、そのノードに対応するログレコードに、そのユーザの部門属性値を設定し、更にステップＳ１２ｂで取得した文書群をそのログレコードの文書セット属性に追加して（Ｓ１７ｂ）、処理を終了する。一致した場合は、ステップＳ１７ｂはスキップして処理を終了する。

次に、図２９を参照して、ユーザから添付文書登録要求を受けた際の文書登録部１３ａの処理手順を説明する。図２９において、図１２の手順と同様のステップには同一符号を付して詳細な説明は省略する。

この手順では、文書登録部１３ａは、添付文書登録要求に伴って送られてきた添付文書に対してＩＤ（例えば「Ｄ１１１」など）を付し、添付文書をＩＤに対応づけて、例えば文書ＤＢ１１ａに保存する（Ｓ２１ｂ）。そして、要求元ユーザの部門属性の取得、副本ｓｃの提供、ログレコードの記録などの処理を行い（Ｓ２２〜Ｓ２４）、派生関係ツリーを遡ってそのユーザの部門属性と同じ部門属性を持つノードを探索し（Ｓ２５）、見つかったノードに対応するログレコードの文書セット属性の欄に、ステップＳ２１ｂで付与したＩＤを追加する（Ｓ２６ｂ）。

以上のような処理により、文書セットに対して流通過程で添付文書が追加されていくような文書展開方式でも、部門内での文書セットの共有が容易に実現できる。なお、図２５〜図２９の例では、新たに基点ノードを設定する際に、その上位の基点ノードに登録された文書セットをその新たな基点ノードに引き継いで設定したが、これは必須ではない。例えばこの代わりに、差分管理方式の更新情報管理における図２１の例のように、各基点ノードには、その基点ノードに対応する部門で新たに発生した更新情報のみを登録するようにし、閲覧要求時には派生関係ツリーをルートまで遡り、その遡及過程で行き当たる全ての基点ノードにある文書を収集してユーザに提供するようにしてもよい。この場合、上位のノードの文書セットの中に、下位のノードの文書セット内にあるのと同じファイル名の文書が存在する場合には、下位ノードの文書が選択され、上位ノードの同じファイル名の文書は無視されるようにすることもできる。こうすることで、文書セット中の文書が展開の過程で更新される場合に対応できる。

なお、文書セットに属する各文書に対しユーザにより更新が加えられる場合には、文書セット中の文書ごとに、上述の文書更新の実施例の方式による管理（全体管理方式や差分管理方式など）を行えばよい。

また、文書を構成する章や節などの論理的な構成要素をそれぞれ異なるファイル（すなわち文書部品ファイル）として用意し、１つの文書をそれら文書部品ファイルの構造化された集まりとして表現することは、従来よりよく行われている。特開２００３−０６７４０２号公報には、そのような個々の文書部品ファイルごとに、全体管理方式又は差分管理方式で更新情報を管理する方式が示される。このように、１文書を複数の文書部品ファイルからなる構造として表現し、各部品ファイルごとに更新情報を管理する方式に対しても、１つの文書を構成する文書部品ファイル群を上述の文書セットとして取り扱い（文書部品ファイル群がなす構造の情報が含まれるか否かが異なるのみ）、それら文書部品ファイルのそれぞれに上述の更新や閲覧の管理を行うことで、本実施形態の管理が実現できる。

また、以上の例では、文書の更新要求又は添付文書の登録要求があった時に、その更新の情報又は添付文書を、派生関係ツリーにおける最も近い祖先の基点ノードに登録した。しかし、更新情報や添付文書を基点ノードに収集するタイミングは、更新又は登録の時点に限らず、例えば閲覧要求を受け取った際でもよい。すなわち、この例では、更新要求又は添付文書の登録要求があった時点では、更新情報や添付文書を当該要求に対応するノードに登録する。そして、閲覧要求があった際に、その要求に対応するノードの祖先の基点ノードを見つけ、その基点ノードの子孫の各ノードに登録された更新情報又は添付文書を収集し、要求元のユーザに提供する。この管理を、差分管理方式での更新に適用した場合の処理手順を、図３０及び図３１を参照して説明する。

図３０は、更新要求を受けた場合の文書登録部１３ａの処理手順を示す。図３０において、図１２，図２４の手順と同様のステップには同一符号を付して詳細な説明は省略する。この手順では、まず文書登録部１３ａは、更新要求に伴って送られてきた差分データに対してＩＤを付し、文書ＤＢ１１ａなどの記憶装置に保存する（Ｓ２１ａ）。そして、要求元ユーザの部門属性の取得、副本ｓｃの提供を行い（Ｓ２２，Ｓ２３）、ログレコードを記録する（Ｓ２４ｃ）。ステップＳ２１ａで差分データに付与したＩＤは、このとき生成するログレコードに１属性として登録する。

図３１は、閲覧要求を受けた際の副本提供部１７ａの処理手順を示す。図３１において、図１１，図２３の手順と同様のステップには同一符号を付して詳細な説明は省略する。

この手順では、副本提供部１７ａは、閲覧要求に伴う副本ＩＤを起点に、派生関係ツリー３００を遡り、その遡及過程で行き当たる最初の基点ノードを探索する（Ｓ１１ｃ）。そして、見つかった基点ノードから今度は子孫の方向に派生関係ツリーを降り、その下降過程で行き当たる各ノードに登録された差分データを収集する（Ｓ１２ｃ）。この収集の際、差分データの属するノードの日時属性をその差分データの生成日時として取得し、それら生成日時から各差分データの時系列順を求める。以上の処理を、ルートノードに到達するまでに行き当たる全ての基点ノードについて行う。これ以降の処理は図２３の処理と同様でよい。

また、以上の例では、階層的な組織構造に従って、同一部門内へ、又は上位部門から下位部門へと文書が伝達されていくことを想定したが、そのような関係にない他の部門のユーザへ文書が伝達される場合も想定するならば、例えば、次のような制御を行えばよい。すなわち、文書管理サーバ１０ａは、ユーザから閲覧要求を受け取った場合、例えば図１１の手順のステップＳ１６で、そのユーザの属する部門がステップＳ１１で求めた直近の基点ノードの部門属性が示す部門の下位の部門であるか否かを、組織図を参照して求め、下位部門でなければ、例えば閲覧を認めないなどの制御を行えばよい。これにより、部門内での更新内容が、関係のない部門の人に見られてしまうことを防ぐことができる。

また、以上の実施形態の仕組みを用いて、下位部門で行われた文書の更新や追加の結果を、上位部門に集めることもできる。これには、例えば、上位部門にも下位部門にも属するユーザ（例えば下位部門のリーダー）が、下位部門のメンバとして下位部門での更新又は追加の結果の文書（又は文書群）を取得し、上位部門のメンバとしてその文書（又は文書群）を伴った更新又は追加の要求を文書管理サーバ１０ａに行えばよい。例えば、派生関係ツリー４００が図２５に示される状態となった時点で、Ａ事業所のリーダーであるユーザ２がノード４１０で取得した副本ｓｃを利用し、Ａ事業所のメンバとしての資格で閲覧要求を行ったとすると、Ｄ１，Ｄ１１１，Ｄ１１１１１１を含んだ副本データ（例えばフォルダ）を取得することができる。そして、ユーザ２が、（必要に応じ、この副本データに承認などの他の操作を行った上で）この副本データを伴った添付文書登録要求を行う際、自分の資格（所属）を本社のメンバに切り換える。これにより、Ｄ１，Ｄ１１１，Ｄ１１１１１１が、本社の基点ノードであるルートノード４０２へと登録されることになる。この場合、ルートノード４０２に既にある文書については、例えば追加登録は行わないようにすればよい。なお、このような処理のために、ビューワ２２に、ユーザが自分の資格（所属部門）を選択するためのユーザインタフェースを設けてもよい。

また、以上では、副本ＩＤ間の派生関係ツリーは、ログ管理部１９中のログレコード群における「旧副本ＩＤ」と「提供した副本ＩＤ」との対応関係により表現したが、派生関係ツリーのデータ構造はこれに限らず、ログレコード群とは別に作成してもよい。

以上の実施形態における「電子文書」には、ワードプロセッサや表計算プログラムで作成された文書データのみならず、音声データや画像データ、動画データ、マルチメディアデータなど、様々なデータが含まれ得る。したがって「電子文書」の「閲覧」という概念の中には、音声データや画像データ、動画データ、マルチメディアデータを再生することも含まれる。すなわち、上記実施形態における「電子文書」の「閲覧」には、電子文書の「利用」すること一般が広く含まれる。すなわち、副本ｓｃを用いるシステムでは、文書管理サーバ１０は、ユーザからの電子文書の「取得要求」に対しては、その電子文書に対応づけられた副本ｓｃをユーザに提供し、その副本ｓｃを用いた電子文書の「利用要求」に対しては、その電子文書のコピー（又はそれに対して差分データ、追加データを反映したもの）を含む副本ファイルを、その「利用」のためにユーザに提供する。

以上に説明したシステムを構成する文書管理サーバ１０，１０ａは、典型的には、汎用のコンピュータにて上述の各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図３２に示すように、ＣＰＵ（中央演算装置）５０、メモリ（一次記憶）５２、各種Ｉ／Ｏ（入出力）インタフェース５４等がバス５６を介して接続された回路構成を有する。また、そのバス５６に対し、例えばＩ／Ｏインタフェース５４経由で、ハードディスクドライブ５８やＣＤやＤＶＤ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ６０が接続される。このようなドライブ５８又は６０は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ５８等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されＣＰＵにより実行されることにより、実施形態の文書管理サーバ１０，１０ａの処理が実現される。実施形態のクライアント端末２０も、同様に、汎用のコンピュータを用いて実現することができる。

副本ショートカットを用いた文書利用管理システムの概略構成を示すブロック図である。 クライアント端末の内部構成の例を示す図である。 文書管理サーバの内部構成の例を示す図である。 ログ管理部が生成するログデータの一例を示す図である。 図４のログデータが示す副本ＩＤの派生関係のツリーを示す図である。 図４のログデータが生成される場合のシステムの動作を説明するための図である。 組織内での文書展開の管理のためのシステムの概略構成を示す図である。 組織情報管理データベースに登録されたユーザ情報の一例を示す図である。 図７のシステムにおける文書管理サーバの内部構成を示す図である。 全体管理方式において、文書登録要求を受けた場合の文書登録部の処理手順を示すフローチャートである。 全体管理方式において、閲覧要求を受けた場合の副本提供部の処理手順を示すフローチャートである。 全体管理方式において、更新要求を受けた場合の文書登録部の処理手順を示すフローチャートである。 組織内での文書展開の具体例における、ある時点での派生関係ツリーを示す図である。 図１３の派生関係ツリーに対応するログデータのデータ内容を示す図である。 図１３の状態の後、Ａ事業所に属するユーザが文書の更新を行った場合の派生関係ツリーを示す図である。 図１５の状態の後、更に同じユーザが更新後の文書を閲覧した時のログデータのデータ内容を示す図である。 更にＢ事業所に属する別のユーザが文書の更新と閲覧を行った時の派生関係ツリーを示す図である。 更にＡ事業所に属する別のユーザが文書の更新と閲覧を行った時の派生関係ツリーを示す図である。 図１８の派生関係ツリーに対応する図である。 更にＡ事業所に属するユーザが文書の閲覧を行った時の派生関係ツリーを示す図である。 差分管理方式での派生関係ツリーの例を示す図である。 差分管理方式において、文書登録要求を受けた場合の文書登録部の処理手順を示すフローチャートである。 差分管理方式において、閲覧要求を受けた場合の副本提供部の処理手順を示すフローチャートである。 差分管理方式において、更新要求を受けた場合の文書登録部の処理手順を示すフローチャートである。 添付文書追加により文書セットを更新する方式における派生関係ツリーの例を示す図である。 添付文書追加により文書セットを更新する方式におけるログデータの例を示す図である。 添付文書追加により文書セットを更新する方式において、原本文書登録要求を受けた場合の文書登録部の処理手順を示すフローチャートである。 添付文書追加により文書セットを更新する方式において、閲覧要求を受けた場合の副本提供部の処理手順を示すフローチャートである。 添付文書追加により文書セットを更新する方式において、添付文書登録要求を受けた場合の文書登録部の処理手順を示すフローチャートである。 閲覧要求の際に基点ノードに子孫の更新情報を収集する方式において、更新要求を受けた場合の文書登録部の処理手順を示すフローチャートである。 閲覧要求の際に基点ノードに子孫の更新情報を収集する方式において、閲覧要求を受けた場合の副本部の処理手順を示すフローチャートである。 実施形態の装置が実装されるコンピュータのハードウエア構成の一例を示す図である。

符号の説明

１０，１０ａ 文書管理サーバ、１１ 正本文書ＤＢ、１３ 正本文書登録部、１５ 副本ｓｃ（ショートカット）提供部、１７ 副本文書提供部、１９ ログ管理部、２０ クライアント端末、２２ ビューワ、２４ ファイルシステム、３０ ネットワーク。

Claims (10)

1. 電子文書を管理する文書管理サーバと電子文書を利用するクライアントとを含む文書利用管理システムであって、
   前記文書管理サーバは、
   ユーザからの操作要求に応じて電子文書に操作を行った場合に、その電子文書に対応づけられた新たな操作ＩＤをそのユーザに発行すると共に、その新たな操作ＩＤをその操作要求に伴って受け取った操作ＩＤの子ノードとする派生関係を記録するＩＤ処理手段と、
   前記派生関係のノード群の中に、部門の基点を示す基点ノードを設定する基点設定手段と、
   基点ノードの子孫のノードに対応する操作により登録された前記電子文書の関連データをその基点ノードへと収集する文書収集手段と、
   ユーザから電子文書の利用要求を受けた場合に、その利用要求に伴う操作ＩＤから前記派生関係のルートノードへと前記派生関係を遡る過程で検出された基点ノードに収集された関連データに基づき生成した文書データをユーザに提供する文書提供手段と、
   を備え、
   前記クライアントは、
   電子文書に関する操作要求に応じて文書管理サーバから受け取った操作ＩＤをその電子文書に対応する操作ＩＤとして保存する操作ＩＤ管理手段と、
   前記操作ＩＤ管理手段により保存された操作ＩＤを指定してユーザから操作指示を受けた場合に、その操作ＩＤを伴った要求を前記文書管理サーバへと送る要求手段と、
   を備える、
   文書利用管理システム。
2. 請求項１記載の文書利用管理システムであって、
   前記文書収集手段は、クライアントからの文書更新又は文書追加の要求に応じて、その要求に伴って受け取った操作ＩＤから前記派生関係を前記ルートノードへと遡る過程で最初に検出された基点ノードに対し、その要求に伴って受け取った前記電子文書の関連データを対応づける、
   ことを特徴とする文書利用管理システム。
3. 請求項１記載の文書利用管理システムであって、
   前記関連データは、文書更新要求に対応する更新後の電子文書であり、
   前記文書収集手段は、文書更新要求に伴って受け取った更新後の電子文書を、その要求に伴って受け取った操作ＩＤから前記派生関係を前記ルートノードへと遡る過程で最初に検出された基点ノードに対応付け、
   前記文書提供手段は、前記利用要求に伴って受け取った操作ＩＤから前記派生関係を前記ルートノードへと遡る過程で最初に検出された基点ノードに対応づけられた電子文書をユーザに提供する、
   ことを特徴とする文書利用管理システム。
4. 請求項１記載の文書利用管理システムであって、
   前記関連データは、文書更新要求に対応する更新前後の差分データであり、
   前記文書提供手段は、収集した各差分データを、その差分データが生成された時系列順の情報と共にユーザに提供する、
   ことを特徴とする文書利用管理システム。
5. 請求項１記載の文書利用管理システムであって、
   前記関連データは、添付文書登録要求に対応する添付文書のデータであり、
   前記文書提供手段は、収集した各添付文書のデータをユーザに提供する、
   ことを特徴とする文書利用管理システム。
6. 請求項１記載の文書利用管理システムであって、
   前記基点設定手段は、ユーザからの電子文書の利用要求に伴って受け取った操作ＩＤから前記派生関係を前記ルートノードへと遡る過程で最初に検出された基点ノードの部門と、そのユーザの所属する部門とが異なる場合、前記派生関係においてその利用要求に対応する操作ＩＤのノードを、そのユーザの部門に対応する基点ノードに設定する、
   ことを特徴とする文書利用管理システム。
7. 請求項６記載の文書利用管理システムであって、
   前記基点設定手段は、ユーザからの電子文書の利用要求に応じて設定した基点ノードに対し、その利用要求に応じて前記文書提供手段が収集した関連データ群を対応づける、
   ことを特徴とする文書管理システム。
8. 請求項１記載の文書利用管理システムであって、
   前記クライアントは、
   前記要求手段が前記文書管理サーバに送る要求に対応づけて、その要求を発したユーザの属する複数の部門のうち、その要求を発した時の部門を示す情報を前記文書管理サーバに通知する手段、
   を更に備えることを特徴とする文書管理システム。
9. ユーザに提供する電子文書を管理する文書管理サーバであって、
   ユーザからの操作要求に応じて電子文書に操作を行った場合に、その電子文書に対応づけられた新たな操作ＩＤをそのユーザに発行すると共に、その新たな操作ＩＤをその操作要求に伴って受け取った操作ＩＤの子ノードとする派生関係を記録するＩＤ処理手段と、
   前記派生関係のノード群の中に、部門の基点を示す基点ノードを設定する基点設定手段と、
   基点ノードの子孫のノードに対応する操作により登録された前記電子文書の関連データをその基点ノードへと収集する文書収集手段と、
   ユーザから電子文書の利用要求を受けた場合に、その利用要求に伴う操作ＩＤから前記派生関係を前記ルートノードへと遡る過程で検出された基点ノードに収集された関連データに基づき生成した文書データをユーザに提供する文書提供手段と、
   を備える文書管理サーバ。
10. コンピュータを、
    ユーザからの操作要求に応じて電子文書に操作を行った場合に、その電子文書に対応づけられた新たな操作ＩＤをそのユーザに発行すると共に、その新たな操作ＩＤをその操作要求に伴って受け取った操作ＩＤの子ノードとする派生関係を記録するＩＤ処理手段、
    前記派生関係のノード群の中に、部門の基点を示す基点ノードを設定する基点設定手段、
    基点ノードの子孫のノードに対応する操作により登録された前記電子文書の関連データをその基点ノードへと収集する文書収集手段、
    ユーザから電子文書の利用要求を受けた場合に、その利用要求に伴う操作ＩＤから前記派生関係を前記ルートノードへと遡る過程で検出された基点ノードに収集された関連データに基づき生成した文書データをユーザに提供する文書提供手段、
    として機能させるためのプログラム。
    
    

Images