JP5082455B2

JP5082455B2 - 文書管理サーバ及びプログラム

Info

Publication number: JP5082455B2
Application number: JP2007006988A
Authority: JP
Inventors: 節國武
Original assignee: Fuji Xerox Co Ltd; Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2007-01-16
Filing date: 2007-01-16
Publication date: 2012-11-28
Anticipated expiration: 2027-01-16
Also published as: JP2008176387A

Description

本発明は、文書管理サーバに関する。

文書に対する操作記録（ログ）データを記録する文書管理装置においては、時間の経過と共に、保持している操作記録データの量が増えていく。一般に、このような装置では、記録された日時が古い操作記録データから順に削除することで、装置内の操作記録データの量を所定値以下に抑えている。また、操作記録データを完全に削除してしまうことが許されないシステムの場合は、通常運用するデータベースと、テープや光ディスクなどといった蓄積用の記憶装置乃至媒体との２段階の記憶を設け、データベースに記録された操作記録データのうち古いものから順に蓄積用の記憶装置乃至媒体に退避することが行われている。

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

ところで、文書に対して操作が行われ、その操作結果に対して更に操作が行われるような場合のように、操作の間に派生関係（親子関係といってもよい）がある場合がある。そのような場合に、操作記録情報の派生関係の情報を記録して、文書がどのように操作されていったのかをその派生関係の記録から追跡するシステムや、その派生関係の情報を用いて利用者に情報提供を行ったりすることを可能とするシステムなども考えられる。そのようなシステムにおいては、データベースから操作記録情報を単にその登録日時の古い順に削除したのでは、同一の文書から派生する操作の派生関係の系列のうちの一部のみが削除される場合がある。そのように１つの文書についての派生関係の系列の一部のみ削除されると、その文書に関する派生関係の情報を用いた各種の処理（派生関係の追跡も含む）を実行する際に、正しい処理結果が得られない場合がある。なお、登録日時の古い順だけでなく、削除する操作記録情報をその他の基準に従って選択する場合にも、単にその基準を満たす操作記録情報を個別に削除したのでは、同様の問題が生じる。

請求項１に記載の発明は、文書に対して行われた操作に関する操作記録情報を当該文書と対応づけて記憶するとともに、操作記録情報同士の間の派生関係を記憶する操作記録記憶部と、前記操作記録記憶部に記憶された前記操作記録情報同士の間の派生関係を順に辿る処理を実行する処理実行部と、対応する第１の操作記録情報が前記操作記録記憶部に登録されている文書に対してクライアントが操作を行った場合に、その操作に関する第２の操作記録情報を前記操作記録記憶部に登録すると共に、前記第１の操作記録情報の子が前記第２の操作記録情報であるという派生関係を前記操作記録記憶部に登録する登録部と、文書に対応する操作記録情報及びこの操作記録情報の子孫のすべての操作記録情報からなるグループが所定の削除条件を満足する場合に、当該グループに含まれるすべての操作記録情報を一括して前記操作記録記憶部から削除し、前記グループが前記削除条件を満足しない場合には前記グループに含まれるすべての操作記録情報を前記操作記録記憶部に残す削除部と、を備える文書管理サーバ、を提供する。

請求項２に記載の発明は、請求項１に記載の発明において、各文書についての最新の操作の時刻を表す情報を記憶する操作時刻記憶部を更に備え、前記削除条件は、操作の時刻に関する条件であり、前記登録部は、前記第２の操作記録情報を前記操作記録記憶部に登録する際に、前記操作時刻記憶部における前記第２の操作記録情報に対応する文書の最新の操作の時刻を表す情報を、前記第２の操作記録情報における操作の時刻を表す情報に書き換え、前記削除部は、前記操作時刻記憶部に記憶された文書の最新の操作の時刻を表す情報が前記削除条件を満足する場合に、当該文書に対応する操作記録情報及びこの操作記録情報の子孫のすべての操作記録情報からなるグループを一括して前記操作記録記憶部から削除する、ことを特徴とする。

請求項３に記載の発明は、請求項１に記載の発明において、各文書について、前記削除条件が成立するか否かの判定に用いられる要約情報を記憶する要約情報記憶部を更に備え、前記登録部は、前記第２の操作記録情報を前記操作記録記憶部に登録する際に、前記要約情報記憶部における前記第２の操作記録情報に対応する文書に対応する要約情報を、前記第２の操作記録情報に応じて更新し、前記削除部は、前記要約情報記憶部に記憶された文書の要約情報が前記削除条件を満足する場合に、当該文書に対応する操作記録情報及びこの操作記録情報の子孫のすべての操作記録情報からなるグループを一括して前記操作記録記憶部から削除する、ことを特徴とする。

請求項４に記載の発明は、請求項１に記載の発明において、前記登録部は、前記クライアントから、前記文書に対して実行された操作に関する情報に関連づけて削除条件指定情報を取得した場合に、取得した前記削除条件指定情報に対応する削除条件を個別削除条件として、当該操作に関する操作記録情報に対応づけて前記操作記録記憶部に登録し、前記削除部は、文書に対応する操作記録情報及びその子孫の操作記録情報からなるグループについて、当該グループに属する各操作記録情報に対応づけてそれぞれ登録された個別削除条件から１つの統合削除条件を求め、当該グループが統合削除条件を満足する場合に、当該グループを一括して削除する、ことを特徴とする。

参考例の構成は、文書に対して行われた操作に関する操作記録情報を当該文書と対応づけて記憶するとともに、操作記録情報同士の間の派生関係を記憶する操作記録記憶部と、前記操作記録記憶部に記憶された前記操作記録情報同士の間の派生関係を順に辿る処理を実行する処理実行部と、対応する第１の操作記録情報が前記操作記録記憶部に登録されている文書に対してクライアントが操作を行った場合に、その操作に関する第２の操作記録情報を前記操作記録記憶部に登録すると共に、前記第１の操作記録情報の子が前記第２の操作記録情報であるという派生関係を前記操作記録記憶部に登録する登録部と、文書の登録操作の操作記録情報以外の操作履歴情報の中で所定の削除条件に満足する操作記録情報を前記操作記録記憶部から削除する削除部と、前記操作記録記憶部から、前記削除部により削除された操作記録情報を親又は子とする親子関係を、当該削除された操作記録情報の親と子を直接の親子とする派生関係と置き換える派生関係置き換え部と、を備える文書管理サーバ、を提供する。

請求項５に記載の発明は、文書に対して行われた操作に関する操作記録情報を当該文書と対応づけて記憶するとともに、操作記録情報同士の間の派生関係を操作記録記憶部に格納するステップと、前記操作記録記憶部に記憶された前記操作記録情報同士の間の派生関係を順に辿る処理を実行するステップと、対応する第１の操作記録情報が前記操作記録記憶部に登録されている文書に対してクライアントが操作を行った場合に、その操作に関する第２の操作記録情報を前記操作記録記憶部に登録すると共に、前記第１の操作記録情報の子が前記第２の操作記録情報であるという派生関係を前記操作記録記憶部に登録するステップと、文書に対応する操作記録情報及びこの操作記録情報の子孫のすべての操作記録情報からなるグループが所定の削除条件を満足する場合に、当該グループに含まれるすべての操作記録情報を一括して前記操作記録記憶部から削除し、前記グループが前記削除条件を満足しない場合には前記グループに含まれるすべての操作記録情報を前記操作記録記憶部に残すステップと、をコンピュータに実行させるためのプログラム、を提供する。

参考例の構成は、文書に対して行われた操作に関する操作記録情報を当該文書と対応づけて記憶するとともに、操作記録情報同士の間の派生関係を操作記録記憶部に格納するステップと、前記操作記録記憶部に記憶された前記操作記録情報同士の間の派生関係を順に辿る処理を実行するステップと、対応する第１の操作記録情報が前記操作記録記憶部に登録されている文書に対してクライアントが操作を行った場合に、その操作に関する第２の操作記録情報を前記操作記録記憶部に登録すると共に、前記第１の操作記録情報の子が前記第２の操作記録情報であるという派生関係を前記操作記録記憶部に登録するステップと、文書の登録操作の操作記録情報以外の操作履歴情報の中で所定の削除条件に満足する操作記録情報を前記操作記録記憶部から削除するステップと、前記操作記録記憶部から、前記削除部により削除された操作記録情報を親又は子とする派生関係を、当該削除された操作記録情報の親と子を直接の親子とする派生関係と置き換えるステップと、をコンピュータに実行させるためのプログラムを提供する。

請求項１及び５に係る発明によれば、１つの文書から派生する複数の操作についての操作記録情報のうち、一部のみが削除されるということがなくなる。

請求項２に係る発明によれば、各文書に対応するグループが操作の時刻に関する削除条件を満足するか否かを判定する場合に、各操作記録情報に含まれる操作の時刻を表す情報を調べる必要がない。

請求項３に係る発明によれば、各文書に対応するグループが削除条件を満足するか否かを判定する場合に、個々の操作記録情報をいちいち参照しなくて済む。

請求項４に係る発明によれば、文書ごとに削除条件を指定することができる。

参考例の構成によれば、１つの文書から派生する複数の操作についての操作記録情報のうち一部のみが削除されたとしても、残った操作記録情報からその文書に辿り着くことができる。

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

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

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

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

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

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

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

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

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

正本文書ＤＢ１１は、クライアント端末２０からアップロードされた電子文書を、正本（原本）として保存し、管理するデータベースである。本システムの枠組みでは、正本文書ＤＢ１１に保存された電子文書のみが正本として取り扱われる。この枠組みでは、仮にその電子文書のコピーがネットワーク上に存在しても、それは正本とは関係がないものとして扱うことができる。

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

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

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

ここで、ログレコード中の「新副本ＩＤ」を、当該ログレコード自体の識別子として用いてもよい。１つのログレコード内の「旧副本ＩＤ」と「新副本ＩＤ」とのペアは、ログレコード同士の派生関係（親子関係とも呼ぶ）を表す。例えば、ログ番号４のレコードには、旧副本ＩＤ"c"と新副本ＩＤ"d"のペアが登録されているが、このペアは、ログ番号３のレコードが親で、ログ番号４のレコードが子である派生関係を表す。このような派生関係を遡ることにより、副本ＩＤに対応する正本の電子文書を特定することができる。例えば、副本ＩＤ"e"が入力された場合、ログ番号５から４，４から３と順に派生関係を遡ることにより、その副本ＩＤ"e"に対応する正本の電子文書のＩＤ"a"が求められる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上、実施形態のベースとなる文書利用管理システムの構成と処理内容について説明した。このシステムの特徴をまとめると以下のようになる。

・電子文書の正本が文書管理サーバに登録される。
・ユーザに対しては、電子文書の実体データの代わりに副本ｓｃが提供される。副本ｓｃには、副本ＩＤが含まれる。
・文書管理サーバは、提供した副本ｓｃの副本ＩＤと、それに対応する正本との対応関係を管理する。（上述の例では、副本ＩＤから派生関係を遡ることにより、正本が文書管理サーバ１０に登録されたことを示すログレコードに到達し、そのログレコードの新副本ＩＤに対応づけて登録された電子ファイルを、正本として求めた。）
・文書管理サーバ上の文書に対して何らかの操作を行う際には、操作を行う端末が持つ副本ｓｃの副本ＩＤがそのサーバに送られる。
・文書管理サーバは、端末から受け取った副本ＩＤに対応する正本を副本ＩＤ−正本対応関係に基づき特定し、正本のコピーと新たな副本ＩＤとを含んだ副本ファイルを提供する。副本ファイルを受け取ったクライアント端末は、副本ｓｃ内の副本ＩＤを、受け取った副本ファイル内の新たな副本ＩＤへと書き換える。
・文書管理サーバは、クライアント端末からの要求に含まれていた副本ＩＤと、その要求に対して提供した副本ファイルに組み込んだ新たな副本ＩＤとの対応関係を、副本ＩＤ間の派生関係として記録する。
・文書管理サーバは、クライアント端末から電子文書の閲覧など、電子文書の実体データを必要とする操作を指示された場合、正本のコピーである副本文書データを提供する。

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

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

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

このようなシステムにおいて、また、クライアント端末２０が、副本ｓｃを用いて操作を行った場合に、その操作についてのログレコードを生成し、文書管理サーバ１０へこのログレコードを送信して登録してもよい。また、操作に対応する新副本ＩＤをクライアント端末２０が付与してもよい。

また、操作に対応するログレコード（ただし、「新副本ＩＤ」を除いたもの）に対し、ＳＨＡ−２５６などの衝突耐性の高い暗号学的ハッシュ関数を適用して得られるハッシュ値を、当該操作に対応する「新副本ＩＤ」としてもよい。この場合、例えば、「新副本ＩＤ」を除くログレコードの内容を、「新副本ＩＤ」をキーとして、ログ管理部１９に登録してもよい。すなわち、この場合、操作についてのログレコードには、例えば、その操作の種別、操作の日時、操作を指示したユーザに識別情報、その操作のためにユーザが提示した副本ＩＤ（旧副本ＩＤ）等の項目が含まれ、そのログレコードが、当該ログレコードのハッシュ値である新副本ＩＤに対応づけて、ログ管理部１９に保存される。クライアント端末２０が、電子文書に対して操作を行った場合に、その操作についてのログレコードを生成し、そのログレコードのハッシュ値を新副本ＩＤとして生成し、新副本ＩＤとログレコードと操作結果の電子文書（もしあれば）とを文書管理サーバ１０に送信して登録してもよい。

また、以上に例示したシステムでは、クライアント端末２０が保持する副本ｓｃには、副本ＩＤは含まれるが、電子文書の実体が含まれなかった。しかし、このかわりに、副本ＩＤと電子文書の実体のコピーとを含んだ副本ファイルを、クライアント端末２０に提供してもよい。この場合、クライアント端末２０は、その副本ファイルをファイルシステムに保存したり、それを他のクライアント端末２０に送信したりすることができる。また、その副本ファイルをクライアント端末２０上のビューワ２２で開き、編集などの操作を加えることができる。この場合、クライアント端末２０が、その操作についてのログレコードと当該ログレコードのハッシュ値（新副本ＩＤ）を生成し、それらをその操作結果の電子文書とともに、文書管理サーバ１０に送って登録してもよい。

また、以上の例では電子文書の管理を示したが、電子文書を印刷した場合に、その印刷についてのログレコードを生成し、ログ管理部１９に登録すると共に、印刷結果の紙文書に対してそのログレコードの識別子（すなわち「新副本ＩＤ」）を埋め込んでもよい。識別子の埋め込みは、識別子をバーコード等のコード画像の形でその紙文書に印刷すればよい。また、ＲＦＩＤ(Radio Frequency Identifier)タグなどように、情報の読み書きができる媒体を備えた用紙を用いる場合には、印刷結果の紙文書が備えるそのような媒体に対し、ログレコードの識別子を書き込んでもよい。例えば、ユーザがクライアント端末２０で、ある副本ｓｃを用いて、その副本ｓｃに対応する電子文書のコピーをクライアント端末２０上で開いた場合に、開いているコピー（或いはそれに対する編集を加えたもの）に対する印刷を指示したとする。この場合、その副本ｓｃ内の副本ＩＤが、その印刷についてのログレコードの「旧副本ＩＤ」として記録される。これにより、印刷結果の紙文書が、正本文書についての操作の系譜に組み込まれることとなる。実際に印刷された文書の画像を表す、ページ記述言語等で表現された印刷データを、当該印刷操作のログレコードの一属性として記録してもよい。

また、識別子が埋め込まれた紙文書をスキャナで読み取った場合に、その読み取りについてのログレコードを記録してもよい。このログレコードの「旧副本ＩＤ」には、その紙文書から読み取られた識別子がセットされる。これにより、紙文書の読み取りが、正本から派生する操作の系譜に組み込まれる。読み取られた画像を、その読み取り操作のログレコードの一属性として記録してもよい。識別子が埋め込まれた紙文書を複写した場合も、同様に、その識別子を旧副本ＩＤとして含んだログレコードを、複写操作のログレコードとして記録してもよい。この場合も、複写の際に読み取られた画像を、その複写操作のログレコードの一属性として記録してもよい。

また、識別子が埋め込まれていない紙文書をスキャナで読み取った場合に、その読み取りについてのログレコードを記録してもよい。この場合、読み取られた画像を、正本文書として文書管理サーバ１０に登録すればよい。この場合、読み取りの操作が、その正本文書に関連する操作の木の根となる。識別子が埋め込まれていない紙文書を複写した場合も同様である。

以上の文書利用管理システムにおいて、文書管理サーバ１０に登録された正本文書に対して、クライアント２０のビューワ２２にて編集を加え、編集結果の文書を、元の正本文書の更新版として文書管理サーバ１０に登録することも可能である。この場合、ビューワ２２は、ユーザが開いた副本ｓｃの副本ＩＤ"a"を文書管理サーバ１０に送って副本ファイルを要求する。文書管理サーバ１０は、その要求に応じ、その副本ＩＤに対応する電子文書（正本）を特定し、その電子文書と更新用の副本ＩＤ"b"を含む副本ファイルをビューワ２２に送る。ビューワ２２では、その副本ファイルを開いてユーザから編集操作を受け付ける。そして、ユーザの編集が完了すると、ビューワ２２は、編集結果の電子文書を、その副本ファイルに含まれていた副本ＩＤ"b"と対応づけて文書管理サーバ１０に送る。文書管理サーバ１０は、新たに生成した副本ＩＤ"c"を更新用の副本ＩＤとしてビューワ２２に返すと共に、この副本ＩＤ"c"を「新副本ＩＤ」とし、ビューワ２２から受け取った副本ＩＤ"b"を「旧副本ＩＤ」とするログレコードを記録する。このログレコードには、操作イベントの種別として「文書更新」が登録される。また、このログレコードには、ビューワ２２から受け取った更新版の電子文書（又はその電子文書を指す参照情報）が登録される。

また、ログ管理部１９は、ログレコード群を、ＳＧＭＬ文書やＸＭＬ文書などの構造化文書として管理してもよい。この場合、個々のログレコードが１つの要素となり、ログレコード間の派生関係は、要素の入れ子構造により表現すればよい。

例えば図７に、ＸＭＬ文書として表現されたログレコード群の例を示す。この例では、操作の種類を要素名として用いている。例えば"archive"は文書管理サーバ１０へ正本文書を新規に登録する操作を示し、"issue"は登録された正本に対応する副本ｓｃの発行を示す。また"retrieve"は、閲覧等の操作のためにサーバ１０から副本ファイルを取得する操作（サーバから見れば副本ファイルの提供）を示し、"revise"は取得した副本ファイルに対する編集結果を更新版として文書管理サーバ１０に登録する操作を示す。また、操作に応じて発行した新副本ＩＤは、要素内の"documentID"属性の値として表され、その操作が行われた日時は要素内の"date"属性の値として表される。正本文書の新規登録操作の場合、正本文書ＤＢ１１内のその正本文書を指し示す参照情報が"filename"属性の値として、当該操作のログレコードに組み込まれる。この例の場合、ログレコード内に「旧副本ＩＤ」の値は含まれない。この代わりに、当該ログレコードを、旧副本ＩＤを"documentID"の値として持つログレコードの子として、ＸＭＬ文書内に組み込む。例えば、３行目の"retrieve"要素は２行目の"issue"要素の子であり、これは副本ＩＤ"elef4"のログレコードの子が副本ＩＤ"83690"のログレコードであることを表す。図７のＸＭＬ文書のうち１行目から１２行目までがＩＤ"elef4"の正本文書から派生するログレコード群を表す。この例は、２人のユーザが、副本ＩＤ"elef4"を持つ副本ｓｃを用いて、それぞれ副本ファイルを取得したことを示す。それぞれの取得操作には、新たな副本ＩＤ"83690"と"5b225"が付与されている。また、副本ＩＤ"5b225"に対応する取得操作で取得された副本ファイルに対してユーザが編集を行った結果が、更新版として文書管理サーバ１０に登録され、その更新版登録に対して新たな副本ＩＤ"c2875"が付与されている。このように、文書管理サーバ１０に登録された１つの正本文書から派生する各操作のログレコードは、正本登録という操作を表す"archive"要素の中に含まれることになる。図７に例示したＸＭＬ文書は、この他にＩＤ"037cf"の正本文書から派生するログレコード群も含んでいる。

なお、以上の例では文書管理サーバ１０が副本ＩＤを発行すると説明したが、クライアント端末２０が副本ＩＤを発行してもよい。この場合、クライアント端末２０が、発行した副本ＩＤを文書管理サーバ１０に送信し、文書管理サーバ１０がそれを記録すればよい。またこの場合、その副本ＩＤを含む副本ｓｃをクライアント端末２０が生成してもよい。また、クライアント端末２０が実行した操作についてのログレコードをクライアント端末２０が生成し、文書管理サーバ１０に登録するようにしてもよい。

以上のような文書利用管理システムでは、時間の経過に伴い、様々な操作についてのログレコードがログ管理部１９に記録されるので、ログ管理部１９の容量不足が生じる可能性がある。そこで、本システムでは、容量不足が生じる前に、ログレコードをログ管理部１９から削除するか、或いは光ディスクなどの別の記憶装置に退避する。別の記憶装置に退避したログレコードは、ログ管理部１９内に残っている場合よりも時間は掛かるものの、アクセスは可能である。ログレコードを単に削除する場合も、別の記憶装置に退避する場合も、退避したログレコードがログ管理部１９から無くなる点では変わりがないので、以下ではそれら両者を「削除」と総称する。

このようなログ管理部１９からのログレコードの削除を、従来一般的に行われている「古いレコードから順に削除する」という手順に従って削除した場合、副本ＩＤから派生関係を親の方に遡ることができなくなる可能性がある。派生関係を遡れなくなる場合、その副本ＩＤに対応する正本文書を特定できなくなる可能性がある。例えば、図４のログレコード群において、２００６年３月３日１０時３０分以前のログレコードを削除した場合、ログ番号１〜４のログレコードが無くなる。この場合、ユーザが副本ＩＤ"e"に対応する正本のコピーを要求したとしても、ログ番号４，３，１のログレコードがないため、正本文書の登録イベントに到達することができず、副本ＩＤ"e"に対応する正本文書を特定することができない。

このような問題に対する文書管理サーバ１０のログ保守について、以下に説明する。まず、ログ管理部１９の内部構成について、図８を参照して説明する。ログＤＢ（データベース）１９０は、図４又は図７に例示したようなログレコード群を記憶するデータベースであり、文書管理サーバ１０がクライアント端末２０からの要求を処理する際に参照されたり、その処理に伴って生成された新たなログレコードが登録されたりする。旧ログ保存部１９１は、ログＤＢ１９０の容量確保等のために、ログＤＢ１９０中の古いログレコードを退避する記憶装置である。旧ログ保存部１９１は、例えば光ディスクなどの大容量記憶媒体である。ログ登録部１９２は、ログレコードを生成し、ログＤＢ１９０に登録する。ログ検索部１９３は、クライアント端末２０からの要求を処理するために、ログＤＢ１９０の検索を行う。例えば、要求に含まれる副本ＩＤに対応する正本のコピーを含んだ副本ファイルをクライアント端末２０に提供する場合、ログ検索部１９３は、ログＤＢ１９０中の派生関係の情報を参照することで、その副本ＩＤに対応する正本を特定する。ＤＢ保守部１９４は、ログＤＢ１９０の応答性能の確保などのために、古いログレコードをログＤＢ１９０から削除して、旧ログ保存部１９１へ移動させる処理を行う。ＤＢ保守部１９４は、定期的な処理タイミングや、ユーザ（典型的にはサーバ１０の管理者）から明示的な保守実行を受けたときなど、所定のタイミングで、そのようなログレコードの削除・移動処理を実行する。ＤＢ保守部１９４は、個々のログレコードではなく、１つの正本から派生するログレコードの木全体を単位として、ログレコードの削除・移動を行う。条件設定部１９５は、ＤＢ保守部１９４がログＤＢ１９０から削除対象とするログレコードを判定するための条件（以下、「削除条件」と呼ぶ）を設定するためのユーザインタフェース部である。削除条件は、正本の登録操作のログレコードを根とするログレコードの木を対象とする。なお、以下、このような木のことを、「正本を根とする木」または「正本から派生する木」などと略称する場合もある。正本の登録操作のログレコードには、正本文書自体が対応づけられているので、木をたどって正本登録のログレコードにたどり着けば、正本文書にもアクセスできる。

例えば、「最後にアクセスされてから所定日数が経過した文書（から派生したログレコードを削除対象とする）」という削除条件は、正本を根とする木に属するログレコード群の「日時」属性の値がすべて現在時刻より所定日数以上前であれば、その木に属するログレコード全体を一括削除する、という条件を表す。同様に「最終更新日時から所定日数が経過した文書」という条件は、正本を根とする木に属するログレコードのうち、「イベント（操作種別）」属性の値が「更新」であるレコードの「日時」属性値がすべて現在時刻より所定日数以上前であれば、その木に属するログレコード全体を一括削除する、という条件を表す。また、「最後にアクセスされた日時が最も古い文書」という削除条件は、正本を根とする木に属するログレコードの「日時」属性値のうち最も新しい日時をその正本文書の最新アクセス日時とした場合に、その最新アクセス日時が最も古い正本から派生する木を一括削除するという条件を表す。もちろん、最も古い文書１つについてのレコード群だけでなく、最も古いものから順に所定数の正本文書についてのレコード群を一括削除してもよい。同様に、「最終更新日時が最も古い文書」という削除条件も考えられる。また、「ログのサイズが所定サイズを超える文書」という削除条件は、正本を根とする木全体のログレコードの総データ量が所定サイズを超える場合に、その木全体を一括削除するという条件を表す。同様に、「ログのサイズが最大の文書」という削除条件も考えられる。また、「文書のアクセス回数が制限値を上回る文書」という削除条件は、正本を根とする木に属するログレコードのうちクライアント端末２０が副本ファイルを取得したことを表すものが制限値を上回る場合に、その木全体を削除するという条件を表す。また「文書に対して指定された全ユーザが取得済みの文書」という削除条件は、正本に対して予め指定された配布対象ユーザのすべてが副本ファイルを取得した場合に、その正本を根とするログレコードの木を一括して削除するという条件を示す。この条件の判定には、ユーザが副本ファイルを取得したことを示すログレコードのユーザ属性を調べればよい。以上、削除条件の例をいくつか挙げたが、これらはあくまで例に過ぎない。

ユーザは、条件設定部１９５を用いて、これら複数の削除条件の中から所望のものを選択することができる。また、上に例示した削除条件におけるパラメータ（例えば古さの判定基準となる「所定日数」や、アクセス回数の制限値、配布対象のユーザなど）についても、条件設定部１９５から設定可能である。

ここでは、条件設定部１９５によりユーザが削除条件の種類やパラメータを選択する例を示したが、このような条件設定部１９５を設けず、ＤＢ保守部１９４が固定の削除条件に従ってログレコードの削除を行う構成であってももちろんよい。

ＤＢ保守部１９４の処理手順の一例を、図９に示す。この手順では、ＤＢ保守部１９４は、保守処理の実行タイミングが到来すると、文書管理サーバ１０に登録された正本文書毎に、以下のステップＳ１〜Ｓ４の処理を行う。ログＤＢ１９０中では、正本文書は、操作イベントの種別が文書登録であるログレコードに対応する。ＤＢ保守部１９４は、ログレコード群のうち、イベント属性が文書登録であるものを、正本に対応するログレコードとして検出することができる。ステップＳ１では、ログＤＢ１９０を参照して、その正本から派生する木に属するすべてのログレコードを特定する。これは、正本文書ＤＢ１１に登録された正本文書のＩＤを起点に、ログレコードの「旧副本ＩＤ」と「新副本ＩＤ」のペアが示す親子関係を順に下っていくことで実現できる。これにより、その正本を根とするログレコードの木が特定される。ステップＳ２でＤＢ保守部１９４は、その木に属するログレコード群の内容を調べることで、それらレコード群が全体として削除条件を満足するか否かを判定する。満足すると判定されれば、ステップＳ３でＤＢ保守部１９４は、ステップＳ３で、その木に属するすべてのログレコードを一括してログＤＢ１９０から削除し、旧ログ保存部１９１に保存する。満足しないと判定された場合は、ステップＳ３はスキップされ、別の正本についての処理が行われる。

例えば、ログＤＢ１９０が図１０に示すようなログレコード群を記憶しており、削除条件が「２００５年１０月３１日以前のログを削除する」ことを表していた場合を例に取る。このＸＭＬ記述の１〜７行目の"archive"要素は、ＩＤが"efe45"の正本から派生するログレコードの木全体を示しているが、この中に含まれるログレコードの中には"date"属性が２００５年１０月３１日より後のものが存在するので、この"archive"要素は削除されない。一方、８〜１２行目の"archive"要素は、ＩＤが"037cf"の正本から派生するログレコードの木全体を示しているが、この木に属するログレコードの"date"属性はすべて２００５年１０月３１日以前なので、この"archive"要素は削除条件を満足し、削除される。

以上の処理例では、木に属する各ログレコードの日時属性をすべて調べていたが、この処理を簡略化することも可能である。簡略化の１つの手法として、正本文書に対して最新操作日時の属性を持たせる手法がある。この手法では、副本ＩＤを用いた操作が行われる毎に、その副本ＩＤに対応する正本文書の最新操作日時属性をその操作の日時へと更新する。ログＤＢ１９０において、その副本ＩＤから派生関係を遡って到達する根に対応する文書が、その副本ＩＤに対応する正本文書である。正本文書の最新操作日時属性は、例えば図１１に示す例では、"archive"要素内の"lastAccessedDate"属性として表されている。この例では、ＤＢ保守部１９４は、保守処理の実行タイミングが到来すると、正本文書ＤＢ１１に登録された各正本文書について、図１２に示すステップＳ１１〜Ｓ１３を実行する。ステップＳ１１では、ＤＢ保守部１９４は、当該正本文書の最新操作日時を取得する。次にステップＳ１２では、取得した最新操作日時が削除条件を満たすか否かを判定する。満たす場合は、ステップＳ１３にてその正本文書から派生するログレコードの木全体をログＤＢ１９０から削除する。満たさない場合は、ステップＳ１３はスキップする。以上、正本文書の最新操作日時を削除条件とする例を示したが、最終更新日時に関する削除条件についても、同様の処理が可能である。

また、以上の例では、日時に関する条件についての処理例を示したが、他の削除条件についても同様の処理が可能である。この場合、正本を根とする木に含まれるログレコード群についての要約情報を、その正本に対応づけて記憶する。この要約情報は、その正本を根とする木に属するログレコード群について、削除条件が成立するか否かの判定に用いる情報を集計した情報である。ログ登録部１９２がログＤＢ１９０にログレコードを登録する際に、そのログレコードの属する木の根である正本文書に対応する要約情報を、そのログレコードに応じて更新する。これにより、正本に対応する要約情報は、その正本から派生する操作についてのログレコードを反映したものとなる。ＤＢ保守部１９４は、ＤＢ保守の実行タイミングが到来した場合、各正本について、要約情報が削除条件を満足するか否かを判定すればよい。例えば、ログサイズに関する削除条件を用いる場合は、正本文書に対してログサイズ属性を持たせ、副本ＩＤを用いた操作が行われる毎に、その副本ＩＤに対応する正本文書のログサイズ属性の値を、当該操作に対応して新たに追加したログレコードのサイズ分増加させればよい。また、削除条件が文書のアクセス回数に関する条件である場合、正本文書に対してアクセス回数属性を持たせ、副本ＩＤを用いた操作が行われる毎に、その副本ＩＤに対応する正本文書のアクセス回数属性の値を、当該操作に対応して１増加させればよい。また、「文書に対して指定された全ユーザが取得済みの文書」という削除条件の場合、正本文書に対してアクセス済みユーザリスト属性を持たせ、副本ＩＤを用いた操作が行われる毎に、その副本ＩＤに対応する正本文書のアクセス済みユーザリスト属性に対し、当該操作を行ったユーザの識別子を追加すればよい。

以上の例では、すべての正本文書に対して同一の削除条件が適用されたが、これは一例にすぎない。この代わりに、例えば、文書に対する操作を行うユーザに、当該文書に対する削除条件を指定させてもよい。この例では、ユーザから副本ＩＤを含む要求を受けた場合、文書管理サーバ１０は、その副本ＩＤに対応する副本ファイルを提供すると共に、削除条件の設定用ＵＩ情報を提供する。クライアント端末２０のビューワ２２は、設定用ＵＩ情報を用いて削除条件設定用の画面を表示し、ユーザはその画面に対して、削除条件の種類又はパラメータを入力する。入力された削除条件に関する指定情報は文書管理サーバ１０に渡され、文書管理サーバ１０はその指定情報を、当該操作についてのログレコードの一項目（削除条件属性）としてログＤＢ１９０に記録する。ＤＢ保守部１９４は、保守処理の実行タイミングが到来した場合、図１３のような処理を行えばよい。図１３の手順は、図９の手順に対応するものである。図１３の手順では、ステップＳ１で正本文書から派生するログレコードの木を特定した後、ステップＳ２１でその木に属する各ログレコードの削除条件属性を求める。木の中の複数のログレコードが削除条件属性値を有していた場合、ＤＢ保守部１９４は、それら複数の削除条件属性値を総合して、木全体に適用する削除条件を決定する（Ｓ２２）。例えば、複数の削除条件属性値のうち、もっとも緩い条件を採用してもよい。削除条件属性値として文書の有効期限が設定される場合は、複数の有効期限のうちもっとも後のものを、木全体の削除条件として採用するなどである。この例では、ログ管理部１９は、正本文書に対応する木全体の削除条件として採用した有効期限より、現在時刻の方が後であれば、その木全体のログレコード群を一括してログＤＢ１９０から削除する。ＤＢ保守部１９４は、ステップＳ２２のあとステップＳ２，及びＳ３を実行する。

また、実施形態の変形例として、以下のようなものもある。この変形例では、正本から派生する副本ＩＤの値として、その正本のＩＤが一意に特定できるような値を与える。例えば、副本ＩＤを、正本のＩＤの値を含んだものとするなどである。具体例を挙げると、正本のＩＤが"aaaa"である場合に、これから派生する副本ＩＤを"aaaa-000001"とするなどである。この変形例では、ログ管理部１９は、図１４に示すように、ログ削除情報記憶部１９６を備える。ＤＢ保守部１９４は、正本を根とするログレコードの木全体を一括してログＤＢ１９０から削除した場合、その正本のＩＤをログ削除情報記憶部１９６に登録する。そして、クライアント端末２０から副本ＩＤを含む要求を受けた場合、ログ検索部１９３は、図１５に示すように、その副本ＩＤの中から、対応する正本のＩＤを抽出する（Ｓ３１）。そして、ログ検索部１９３は、その正本ＩＤがログ削除情報記憶部１９６に記憶されているか否かを判定し（Ｓ３２）、記憶されていれば、対象の文書が利用禁止であることを示す情報をクライアント端末２０に返す（Ｓ３３）。また、その正本ＩＤがログ削除情報記憶部１９６に記憶されていなければ、正本文書ＤＢ１１からその正本ＩＤに対応する文書を検索し（Ｓ３４）、見つかればその正本文書をクライアント端末２０に提供する（Ｓ３５）。ここで、正本文書ＤＢ１１に、正本文書から派生した更新版の文書を、その正本文書のＩＤと対応づけて登録しておけば、正本文書の代わりに、あるいは正本文書と共に、これに対応する更新版の文書をクライアント端末２０に提供することもできる。なお、ステップＳ３４で、正本ＩＤに対応する文書が検索できなければ、エラーコード（例えば不正なＩＤによるアクセスを示すコード）をクライアント端末２０に返す（Ｓ３６）。

この例では、ログ削除情報を記憶・管理することにより、クライアント端末２０から提示された副本ＩＤに対応する正本が元々存在しないものであるか、削除されたものであるかを判別することができる。これにより、ログ管理部１９からログの削除を行った場合でも、不正なアクセスを検出することが可能になる。

以上では、正本を根とする派生関係の木に属するログレコードを一括して削除する例を示した。次に、ログレコードを単位として削除する場合の変形例を説明する。この例では、ログＤＢ１９０内に残る他のログレコードの派生関係の情報を書き換えることにより、ログＤＢ１９０内で派生関係がつながるようにする。

すなわち、この変形例では、削除条件は個々のログレコード単位に適用される内容の条件であり、ＤＢ保守部１９４は、ログＤＢ１９０内のログレコードのうち、その削除条件を満たすものをログＤＢ１９０から削除し、旧ログ保存部１９１に移動する。ただし、文書登録イベントのログレコードはログＤＢ１９０内に残す。この削除・移動の際、ＤＢ保守部１９４は、ＩＤすなわちログレコードの派生関係の木を生成し、その木の中で削除されるノード（ログレコード）と、削除されずに残る残留ノードを特定する。そして、残留ノードのうち最も根に近い各ノードについて、当該ノードの「旧副本ＩＤ」の値を、当該ノードから前述の木を遡っていったときに最初に到達する残留ノードの「新副本ＩＤ」に書き換える。

以下、具体例を用いて説明する。例えば、ログＤＢ１９０のデータ内容が図１６に示すようなものであったとする。このような状態で、操作の日時が２００５年１０月３１日より古いログレコードをログＤＢ１９０から旧ログ保存部１９１に移動するとする。図１６の例では、ログ番号２，３，４が移動することになる。移動の結果、旧ログ保存部１９１のデータ内容は、図１８に示すようなものとなる。一方、移動後のログＤＢ１９０は、図１７に示すようなものとなる。この例では、ログＤＢ１９０に残るログ番号５と６のレコードは親と子の関係である。そのログ番号５のレコードの直系の先祖であるログ番号４，３，２のレコードが削除され、ログ番号２の親であるログ番号１のレコード（文書の登録イベント）が残るので、ログ番号５のレコードの旧副本ＩＤを、ログ番号１のレコードの新副本ＩＤの値へと書き換えられている。この書き換えにより、ログ番号５のレコードの親がログ番号１のレコードとなり、文書管理サーバ１０は、ログ番号５，６に対応する操作で発行した新副本ＩＤを含む副本ｓｃを用いた要求をクライアント端末２０から受けた場合に、対応する正本を特定し、クライアント端末２０に提供することができる。

なお、図１９に示すように、正本文書の更新版の文書を当該正本文書の正本ＩＤと対応づけて正本文書ＤＢ１１に登録しておけば、クライアント端末２０からの要求中の副本ＩＤに対応する正本に対応する更新版を求め、その更新版をクライアント端末２０に提供することもできる。図１９に示すデータベース内容において、「登録ＩＤ」は、文書の新規登録（すなわち正本の登録）、又は更新版文書の登録に応じて発行された副本ＩＤであり、「バージョン」は登録された正本又は更新版のバージョン番号（これは例えば登録したユーザが指定する）である。また「ファイル名」は、登録された正本又は更新版の文書のファイル名である。「ファイル名」の欄の値は、ファイル名そのものでなくても、その値を用いて当該文書の実体データにアクセス可能なものであれば、どのようなものでもよい。図１９の例で、要求に対応する正本ＩＤが例えば"efe45"と特定されたとすると、文書管理サーバ１０は、その正本ＩＤに対応する文書のエントリとして番号１，３，４のエントリを見つけ、その中で例えば最新の版であるバージョン１．２の文書「整備マニュアル1_2.pdf」を提供することができる。

なお、この変形例において、ログ検索部１９３が、クライアント端末２０からの要求に含まれる副本ＩＤに対応するログレコード（すなわちその副本ＩＤを「新副本ＩＤ」の値として持つレコード）をログＤＢ１９０から見つけることができなかった場合、ログ検索部１９３が更に旧ログ保存部１９１を検索してもよい。例えば要求に含まれる副本ＩＤが"83690"であったとすると、ログ検索部１９３はその副本ＩＤに対応するログレコードを図１７の内容を持つログＤＢ１９０から得ることはできない。そこでログ検索部１９３は更に図１８に示す内容の旧ログ保存部１９１を検索する。これにより、旧ログ保存部１９１におけるログ番号２のレコードを得ることができる。ログ検索部１９３は、このレコードから旧ログ保存部１９１内で親子関係を先祖へと遡ることで、図１８のログ番号１のレコードに到達する。ただし、このレコードは正本文書登録についてのものではないので、ログ検索部１９３は、更にログＤＢ１９０において、そのレコードの先祖を探すことで、図１７のログ番号１のレコードに到達する。このレコードに示される新副本ＩＤが、この例では正本文書の正本ＩＤである。

更に別の変形例を説明する。この変形例は、ログレコード群を図７の例のようにＸＭＬで記述する例に関するものである。この変形例では、旧ログ保存部１９１に移動させたログレコードに含まれる副本ＩＤは利用禁止とし、旧ログ保存部１９１へ格納したログレコードが移動前に存在していた位置（ログＤＢ１９０内での位置）、および、ログレコードの内容に改ざんがないことを保証する。

ログＤＢ１９０に記録するログレコードの例を図２０に示す。この例において、"folder"要素はログレコードを「正本登録が行われた日時」で分類するための構造である。すなわち、この変形例では、ログ登録部１９２は、ログＤＢ１９０内に日付ごとに"folder"要素を作成し、正本文書がサーバ１０に登録されたときに、その登録を示す"archive"要素を、その登録時点の属する日付の"folder"要素内に追加する。"folder"要素の属性"g_date"は、当該"folder"要素の作成日を表す。"title"属性は、作成日を表す人間向けの表示などに用いることができる。もちろん、"folder"要素の単位は日に限らない。また、日単位及び月単位など、複数階層の"folder"要素を作成してもよい。

ここでは一例として、最終操作日時が「2005年10月31日」より古いログレコードを、旧ログ保存部１９１へ移動させるとする。正本に関係する全てのログレコードを一括して移動させる。図２０の例では"documentId"属性値が "037cf" である"archive"要素（及びその要素内の子孫要素）が移動対象に該当する。

また、ＤＢ保守部１９４は、ログレコードの移動操作を行う前に以下の処理を実施する。すなわち、移動させるログレコードの先祖に位置する全ての"folder"要素について、ハッシュ値の算出をおこなう。例えば、「日」による分類を行う"folder"要素のハッシュ値は、以下の手順で得る。
Ｓ４１： "folder"のn番目の子要素である"archive"要素を根とするＸＭＬサブツリーのハッシュ値h_nを計算する。
Ｓ４２： "folder"直下の全ての"archive"要素についてＳ４１の計算を行う。
Ｓ４３：Ｓ４２で計算された全てのh_nを各"archive"要素の"hash"属性値として追加し、その結果得られる"folder"要素のＸＭＬサブツリーのハッシュ値を計算する。計算結果のハッシュ値を、当該"folder"要素に"hash"属性値として追加する。

例えば、図２０の例における最初の"archive"要素に対しこの手順により"hash"属性値を追加した結果を、図２１に例示する。

"folder"要素が階層的に存在する場合は、最下位の"folder"要素に対して上述のステップＳ４１〜Ｓ４３の処理を実行する。この処理の後、その最下位の"folder"要素を含む１つ上位の"folder"要素のＸＭＬサブツリーのハッシュ値を計算し、その計算結果を当該"folder"要素に"hash"属性値として追加する。下位から上位へと再帰的に以上の処理を繰り返す。

以上の処理は、ＤＢ保守部１９４がログレコードの一部を旧ログ保存部１９１へ移動させる直前に実行し、その処理結果を図２２のように記録する。すなわち、ある正本に対する"archive"要素を一括して移動する場合、その移動の日時を「記録日時」の値として図２２に例示したような削除記録テーブルに記録する。そして、移動対象の"archive"要素の上位の各"folder"要素のハッシュ値と、移動対象の"archive"要素以外の"archive"要素（移動対象の"archive"要素と同じ"folder"要素に属する兄弟の"archive"要素）のハッシュ値とを、その記録日時と対応づけて削除記録テーブルに記録する。そして、移動対象の"archive"要素については、タイムスタンプを付与してから旧ログ保存部１９１へ移動する。タイムスタンプは、例えばRFC3161(Time-Stamp Protocol)に示される方式を用いて付与すればよい。

このような削除記録を残しておくことで、旧ログ保存部１９１へ移動させた"archive"要素（正本を根とするログレコード群）が、移動前は確かにtitle属性値が「2005年1月10日」であるfolder要素の下位要素であり、移動させた後に改ざんがないことを示すことができる。

以上に説明した各例では、ログレコードをログＤＢ１９０から旧ログ保存部１９１に移動させる処理について説明したが、正本を根とするログレコード群を一括して移動させる場合には、その正本自身を正本文書ＤＢ１１から削除し、保存用の記憶装置（例えば旧ログ保存部１９１）に格納してもよい。

また以上の各例では、ログレコードをログＤＢ１９０から旧ログ保存部１９１に移動させるとしたが、ログレコードをログＤＢ１９０から単に削除してしまう場合にも、上記各例の手法は適用可能である。

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

副本ショートカットを用いた文書利用管理システムの概略構成を示すブロック図である。クライアント端末の内部構成の例を示す図である。文書管理サーバの内部構成の例を示す図である。ログ管理部が生成するログデータの一例を示す図である。図４のログデータが示す副本ＩＤの派生関係のツリーを示す図である。図４のログデータが生成される場合のシステムの動作を説明するための図である。ログデータ群をＸＭＬ文書で表現した例を示す図である。ログ管理部の内部構成の一例を示す図である。ＤＢ保守部の処理手順の一例を示すフローチャートである。ＸＭＬで表現されたログレコード群の例を示す図である。正本の最終アクセス日時属性を含んだログレコード群の例を示す図である。正本の最終アクセス日時属性を利用したＤＢ保守部の処理手順の例を示す図である。ＤＢ保守部の処理手順の別の例を示すフローチャートである。変形例のログ管理部の内部構成の例を示す図である。変形例におけるログ検索部の手順の例を示すフローチャートである。ログＤＢ内のデータ内容の例を示す図である。変形例において、図１６に例示したログＤＢから、ログレコードを旧ログ保管部に移動した後の、ログＤＢのデータ内容の例を示す図である。変形例において、図１６に例示したログＤＢから、旧ログ保管部に移動されたログレコードのデータ内容の例を示す図である。正本文書ＤＢのデータ内容の一例を示す図である。正本の登録日による分類のための"folder"要素を含んだ、ＸＭＬで記述されたログの例を示す図である。 "hash"属性値を追加した"archive"要素の例を示す図である。削除記録テーブルの持つデータ内容の例を示す図である。コンピュータのハードウエア構成の一例を示す図である。

符号の説明

１０文書管理サーバ、１１正本文書ＤＢ、１３正本文書登録部、１５副本ショートカット提供部、１７副本文書提供部、１９ログ管理部、２０クライアント端末、２２ビューワ、２４ファイルシステム、２６副本ショートカット、３０ネットワーク、１９０ログＤＢ、１９１旧ログ保存部、１９２ログ登録部、１９３ログ検索部、１９４ＤＢ保守部、１９５条件設定部。

Claims

文書に対して行われた操作に関する操作記録情報を当該文書と対応づけて記憶するとともに、操作記録情報同士の間の派生関係を記憶する操作記録記憶部と、
前記操作記録記憶部に記憶された前記操作記録情報同士の間の派生関係を順に辿る処理を実行する処理実行部と、
対応する第１の操作記録情報が前記操作記録記憶部に登録されている文書に対してクライアントが操作を行った場合に、その操作に関する第２の操作記録情報を前記操作記録記憶部に登録すると共に、前記第１の操作記録情報の子が前記第２の操作記録情報であるという派生関係を前記操作記録記憶部に登録する登録部と、
文書に対応する操作記録情報及びこの操作記録情報の子孫のすべての操作記録情報からなるグループが所定の削除条件を満足する場合に、当該グループに含まれるすべての操作記録情報を一括して前記操作記録記憶部から削除し、前記グループが前記削除条件を満足しない場合には前記グループに含まれるすべての操作記録情報を前記操作記録記憶部に残す削除部と、
を備える文書管理サーバ。
各文書についての最新の操作の時刻を表す情報を記憶する操作時刻記憶部を更に備え、
前記削除条件は、操作の時刻に関する条件であり、
前記登録部は、前記第２の操作記録情報を前記操作記録記憶部に登録する際に、前記操作時刻記憶部における前記第２の操作記録情報に対応する文書の最新の操作の時刻を表す情報を、前記第２の操作記録情報における操作の時刻を表す情報に書き換え、
前記削除部は、前記操作時刻記憶部に記憶された文書の最新の操作の時刻を表す情報が前記削除条件を満足する場合に、当該文書に対応する操作記録情報及びこの操作記録情報の子孫のすべての操作記録情報からなるグループを一括して前記操作記録記憶部から削除する、
ことを特徴とする請求項１記載の文書管理サーバ。
各文書について、前記削除条件が成立するか否かの判定に用いられる要約情報を記憶する要約情報記憶部を更に備え、
前記登録部は、前記第２の操作記録情報を前記操作記録記憶部に登録する際に、前記要約情報記憶部における前記第２の操作記録情報に対応する文書に対応する要約情報を、前記第２の操作記録情報に応じて更新し、
前記削除部は、前記要約情報記憶部に記憶された文書の要約情報が前記削除条件を満足する場合に、当該文書に対応する操作記録情報及びこの操作記録情報の子孫のすべての操作記録情報からなるグループを一括して前記操作記録記憶部から削除する、
ことを特徴とする請求項１記載の文書管理サーバ。
前記登録部は、前記クライアントから、前記文書に対して実行された操作に関する情報に関連づけて削除条件指定情報を取得した場合に、取得した前記削除条件指定情報に対応する削除条件を個別削除条件として、当該操作に関する操作記録情報に対応づけて前記操作記録記憶部に登録し、
前記削除部は、文書に対応する操作記録情報及びその子孫の操作記録情報からなるグループについて、当該グループに属する各操作記録情報に対応づけてそれぞれ登録された個別削除条件から１つの統合削除条件を求め、当該グループが統合削除条件を満足する場合に、当該グループを一括して削除する、
ことを特徴とする請求項１記載の文書管理サーバ。
文書に対して行われた操作に関する操作記録情報を当該文書と対応づけて記憶するとともに、操作記録情報同士の間の派生関係を操作記録記憶部に格納するステップと、
前記操作記録記憶部に記憶された前記操作記録情報同士の間の派生関係を順に辿る処理を実行するステップと、
対応する第１の操作記録情報が前記操作記録記憶部に登録されている文書に対してクライアントが操作を行った場合に、その操作に関する第２の操作記録情報を前記操作記録記憶部に登録すると共に、前記第１の操作記録情報の子が前記第２の操作記録情報であるという派生関係を前記操作記録記憶部に登録するステップと、
文書に対応する操作記録情報及びこの操作記録情報の子孫のすべての操作記録情報からなるグループが所定の削除条件を満足する場合に、当該グループに含まれるすべての操作記録情報を一括して前記操作記録記憶部から削除し、前記グループが前記削除条件を満足しない場合には前記グループに含まれるすべての操作記録情報を前記操作記録記憶部に残すステップと、
をコンピュータに実行させるためのプログラム。