承認管理システム
【課題】文書の承認プロセスにおける承認の正当性チェックの厳密性を向上させる。
【解決手段】文書管理サーバ１０ａは、クライアント端末２０−Ｐ０３から電子文書２００の承認申請２０４を受けた場合、承認権限者のクライアント端末２０−Ｐ０１に対し、副本ＩＤ"ｂ"を含む承認依頼の副本ｓｃ（ショートカット）２０６を送る。承認権限者が副本ｓｃ２０６を開くと、副本ＩＤ"ｂ"を含む要求２０８が発行され、これに応じ文書管理サーバ１０ａは電子文書２００のコピーと新たな副本ＩＤ"ｃ"を含む副本ファイル２１０を返す。承認権限者がその副本ファイル２１０を閲覧して承認操作を行うと、副本ＩＤ"ｃ"を含む承認情報２１２が文書管理サーバ１０ａに送られる。文書管理サーバ１０ａは、これら各操作の際に、その操作の要求に含まれていた副本ＩＤと、その操作の結果発行した新たな副本ＩＤと、ユーザＩＤとの対応を示すログレコードを記録する。
【解決手段】文書管理サーバ１０ａは、クライアント端末２０−Ｐ０３から電子文書２００の承認申請２０４を受けた場合、承認権限者のクライアント端末２０−Ｐ０１に対し、副本ＩＤ"ｂ"を含む承認依頼の副本ｓｃ（ショートカット）２０６を送る。承認権限者が副本ｓｃ２０６を開くと、副本ＩＤ"ｂ"を含む要求２０８が発行され、これに応じ文書管理サーバ１０ａは電子文書２００のコピーと新たな副本ＩＤ"ｃ"を含む副本ファイル２１０を返す。承認権限者がその副本ファイル２１０を閲覧して承認操作を行うと、副本ＩＤ"ｃ"を含む承認情報２１２が文書管理サーバ１０ａに送られる。文書管理サーバ１０ａは、これら各操作の際に、その操作の要求に含まれていた副本ＩＤと、その操作の結果発行した新たな副本ＩＤと、ユーザＩＤとの対応を示すログレコードを記録する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子文書に対する承認、又は電子文書の閲覧申請に対する承認を、電子的に実行するためのシステムに関する。
【背景技術】
【０００２】
オフィス業務では、文書作成者が文書を作成するだけでは、その文書は業務上の正式の文書とはならず、その文書に対して所定の承認者（複数の場合もある）が承認を与えて初めてその文書が正式の文書となることが一般的である。このような承認業務を電子化するシステムとして、特許文献１に示されるシステムが知られている。このシステムでは、電子文書に対する承認操作を行おうとする者がある場合、その者を認証し、この認証によりその者がその電子文書の承認者であると判定された場合、承認許可鍵コードを生成する。そして、承認者がその承認許可鍵コードを正しく入力すると、システムはその電子文書に対して電子押印を行う。
【０００３】
【特許文献１】特開２００５−０２５５０５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記従来システムでは、第三者が承認者のユーザＩＤ、パスワードを入手し、システムにログインすれば、不正な承認が容易に実行できるという問題がある。
【課題を解決するための手段】
【０００５】
本発明の１つの側面では、文書管理サーバとクライアントとを含む承認管理システムが提供される。文書管理サーバは、管理している電子文書に対し、ユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行すると共に、その操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録する。クライアントは、電子文書に対する操作要求に応じて文書管理サーバから受け取った操作ＩＤをその電子文書に対応する操作ＩＤとして保存すると共に、保存した操作ＩＤを指定してユーザから操作指示を受けた場合に、その操作ＩＤを含んだ操作要求を文書管理サーバへと送る。また文書管理サーバは、電子文書に関する承認申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部とを備える。
【０００６】
本発明の別の側面では、電子文書が登録される文書データベースと、文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行する操作ＩＤ発行部と、ユーザからの操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部と、電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、を備える文書管理サーバが提供される。
【０００７】
本発明の更に別の側面では、コンピュータを、電子文書が登録される文書データベース、文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行する操作ＩＤ発行部、ユーザからの操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部、電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部、として機能させるためのプログラム、が提供される。
【発明を実施するための最良の形態】
【０００８】
以下、図面を参照して、本発明の実施の形態（以下「実施形態」と呼ぶ）について説明する。
【０００９】
まず、実施形態のシステムのベースとなる、副本ショートカットを用いた文書管理システムについて説明する。
【００１０】
図１は、この文書管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。
【００１１】
このシステムでは、電子文書の正本を文書管理サーバ１０で管理し、クライアント端末２０にはその電子文書を保存しないようにすることで、電子文書のセキュリティを確保する。クライアント端末２０には、電子文書そのもののファイルの代わりに、その電子文書にアクセスするための情報を含んだ副本ショートカット（以下「副本ｓｃ」と略す）と呼ぶファイルを持たせる。副本ｓｃには、例えば、副本ＩＤと呼ぶ管理用の識別情報と、文書管理サーバ１０のホスト名又は文書閲覧要求用のＵＲＬ（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"を伴った閲覧要求１１６を発行する。これに応じ文書管理サーバ１０は、その副本ＩＤ"ｃ"に対応する正本のコピーを作成するとともに、更新用の副本ＩＤ"ｄ"を生成してそのコピーのファイルの属性にセットすることで副本ファイル１１８を生成し、クライアント端末２０−Ｐ０４に返す。また、ログ管理部１９は、図４のテーブルの５行目に示すようなログレコードを記録する。
【００３６】
クライアント端末２０−Ｐ０４のビューワ２２は、その副本ファイル１１８を開いて表示すると共に、ファイルシステム２４−Ｐ０４内の副本ｓｃ１１４の副本ＩＤを副本ファイル１１８に含まれる更新用の副本ＩＤ"ｄ"へと変更する。これにより、クライアント端末２０−Ｐ０４が持つ電子文書"Ｏ"へのショートカットは副本ｓｃ１２０となる。
【００３７】
ユーザＰ０４が電子文書"Ｏ"の副本閲覧後に副本ｓｃ１２０をユーザＰ０８に送信し、ユーザＰ０８がその副本ｓｃ１２０を用いて閲覧要求１２２を行うと、文書管理サーバ１０は更新用の副本ＩＤ"ｅ"を含む副本ファイル１２４をクライアント端末２０−Ｐ０８に提供し、図４のテーブルの６行目に示すログレコードを記録する。クライアント端末２０−Ｐ０８のビューワ２２は、受け取った副本ファイル１２４を開いてユーザに提供し、ファイルシステム２４−Ｐ０８内の副本ｓｃの副本ＩＤを、その更新用の副本ＩＤ"ｅ"へと変更する。
【００３８】
図４に例示したログデータには、操作イベントにおける副本ＩＤの提供先のユーザＩＤを記録したが、これに加え、そのイベントの契機となった要求を発したユーザＩＤを合わせて記録してもよい。以上の例では、イベントの契機となる要求を発したユーザと、そのイベントにおいて新たに生成した副本ＩＤの提供先とは同一であるが、それらが異なる場合には、上述のように両者のユーザＩＤを記録することが好適である。
【００３９】
以上、実施形態のベースとなる文書管理システムの構成と処理内容について説明した。このシステムの特徴をまとめると以下のようになる。
【００４０】
・電子文書の正本が文書管理サーバに登録される。
・ユーザに対しては、電子文書の実体データの代わりに副本ｓｃが提供される。副本ｓｃには、副本ＩＤが含まれる。なお、副本ｓｃを用いて文書管理サーバ１０上の正本に関する何らかの操作を行う場合、正本を管理する文書管理サーバ１０を特定する必要がある。このために、副本ｓｃには、対応する正本を管理する文書管理サーバ１０を特定する情報を含めてもよい。
・文書管理サーバは、提供した副本ｓｃの副本ＩＤと、それに対応する正本との対応関係を管理する。（上述の例では、副本ＩＤ−正本対応関係をログ管理部１９のログレコードに含める形で管理したが、対応関係のデータは、両者の対応が分かればどのようなデータ形式であってもよい。）
・文書管理サーバ上の文書に対して何らかの操作を行う際には、操作を行う端末が持つ副本ｓｃの副本ＩＤがそのサーバに送られる。
・文書管理サーバは、端末から受け取った副本ＩＤに対応する正本を副本ＩＤ−正本対応関係に基づき特定し、正本に関して、要求された操作を行う。
・文書管理サーバは、正本に関する操作を行った場合、新たな副本ＩＤを生成し、この副本ＩＤを操作を要求したクライアント端末に送る。これを受け取ったクライアント端末は、要求に用いた副本ｓｃの副本ＩＤを、受け取った新たな副本ＩＤへと更新する。
・文書管理サーバは、クライアント端末からの要求に含まれていた副本ＩＤと、その要求に係る操作を行ったことにより生成した新たな副本ＩＤとの対応関係である、副本ＩＤ派生関係を管理する。
・文書管理サーバは、クライアント端末から電子文書の閲覧など、電子文書の実体データを必要とする操作を指示された場合、正本のコピーである副本文書データを提供する。副本文書データは、クライアント端末上で動作するビューワの管理するメモリ上の領域にのみ存在し、ディスク上には保存できない設定となっている。
【００４１】
上述の文書管理システムの例では、文書の登録や、副本ｓｃの取得、文書閲覧などといった操作を例示したが、これに限らず、正本の文書に関連する操作のうち、システムとして把握しておきたい操作の全てを、上記特徴的な処理の対象とすることができる。
【００４２】
次に、以上の文書管理システムをベースとした文書承認システムの実施形態を説明する。この文書承認システムは、あるユーザが作成した文書に対し、承認権限者が承認を行う場合の一連の流れを支援する。
【００４３】
この文書承認システムは、全体的には、図１に示したように、ネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０からなる。本実施形態の文書管理サーバ１０ａは、図３に示した文書管理サーバ１０が持つ各モジュールに加え、承認プロセス管理部３０を備えている（図７参照）。
【００４４】
承認プロセス管理部３０は、文書管理サーバ１０に登録された電子文書（正本）に対する承認プロセスを管理する。承認プロセス管理部３０は、図８に例示するような承認権限者表と、図９に例示するような承認状態表とを管理している。
【００４５】
承認権限者表は、図８に示すように、このシステムが適用される組織の部門の識別情報（「部門ＩＤ」）と、その部門に所属する人が作成した電子文書に対して承認を与える権限を持つ承認権限者のユーザＩＤ（「承認権限者ＩＤ」）との対応関係を保持する。例えば、図８の承認権限者表によれば、部門Ｓ０１のメンバが作成した文書は、ユーザＰ０１から承認を受ける必要があることがわかる。一方、承認状態表は、正本文書ＤＢ１１に登録された電子文書の承認プロセスにおける状態（例えば、未承認であるか、承認済であるかなど。「承認状態」と呼ぶ）を管理するためのテーブルである。図９の例では、承認状態表には、登録された文書の文書ＩＤに対応づけて、その文書の所属する部門の部門ＩＤと、その文書の承認状態とが登録される。承認状態表には、文書管理サーバ１０に登録された全ての文書を登録するようにしてもよいし、登録された文書のうち承認申請を受けたもののみを登録するようにしてもよい。以下では、後者の場合を例にとって説明する。
【００４６】
以下図１０を参照して、この文書承認システムにおける承認プロセスの例を説明する。
【００４７】
ユーザＰ０３がクライアント端末２０−Ｐ０３上で作成した電子文書"Ｏ"について承認を求める場合を例にとる。この例は、図１１に示したログデータに対応している。
【００４８】
この例は、ユーザＰ０３は、作成した電子文書"Ｏ"２００の登録要求を文書管理サーバ１０ａに対して送る。これを受けて文書管理サーバ１０ａは、その電子文書２００に一意な文書ＩＤ"Ｄ０１"を付与して正本文書ＤＢ１１に登録するとともに、一意な副本ＩＤ"a"（図１１の例では"a" = "B012345678"）を生成し、その副本ＩＤ"ａ"を含んだ副本ｓｃ２０２をクライアント端末２０−Ｐ０３に返す。このとき、ログ管理部１９は、図１１の２行目のようなログレコードを記録する。
【００４９】
ユーザＰ０３は、クライアント端末２０−Ｐ０３上のビューワ２２で副本ｓｃ２０２を開き、ビューワ２２の操作メニューから「承認申請」を選択する。すると、ビューワ２２は、ユーザＰ０３（承認を申請する申請者）のユーザＩＤと副本ｓｃ２０２に含まれる副本ＩＤ"ａ"とを含んだ承認申請２０４を文書管理サーバ１０ａに送る。
【００５０】
承認申請２０４を受けた文書管理サーバ１０ａでは、承認プロセス管理部４０が、図１２に示す処理を実行する。すなわち、承認プロセス管理部４０は、承認申請２０４に含まれる申請者のユーザＩＤから、その申請者の所属する部門を判定する（Ｓ１）。この判定は、ネットワーク３０上にある組織情報管理サーバ（図示省略）に問い合せることで行うことができる。すなわち、企業等の組織の部門構成や組織のメンバがどの部門に属するかなどの情報をサーバで管理することは従来より行われているので、承認プロセス管理部４０はそのようなサーバに対して申請者のユーザＩＤを送り、その申請者の属する部門ＩＤを問い合わせればよい。このようにして申請者の所属部門の部門ＩＤ"Ｓ０１"が分かると、承認プロセス管理部４０は、承認権限者表４２（図８参照）を参照して、その部門の承認権限者のユーザＩＤ"Ｐ０１"を求める（Ｓ２）。このように承認権限者が分かると、承認プロセス管理部４０は、組織情報管理サーバからその承認権限者の電子メールアドレス等の連絡先情報を取得する。また、承認プロセス管理部４０は、ステップＳ１，Ｓ２の処理と並行して、一意な副本ＩＤ"b"（図１１の例では"b" = "B564370987"）を生成し、その副本ＩＤを含んだ承認依頼用副本ｓｃ２０６を生成する（Ｓ３）。この承認依頼用副本ｓｃ２０６には、承認依頼である旨を示す属性が組み込まれる。そして、承認プロセス管理部４０は、ステップＳ２で求めた連絡先情報を用いて、承認権限者Ｐ０１に対して承認依頼用副本ｓｃ２０６を送付する（Ｓ４）。この送付は、例えば、承認依頼のメッセージを含み、副本ｓｃ２０６を添付ファイルとして含んだ電子メールを送るなどにより行うことができる。また承認プロセス管理部４０は、承認依頼２０６に含まれる副本ＩＤ"b"に対応する文書ＩＤ"Ｄ０１"をログ管理部１９のログデータ（この場合は図１１の２行目）から特定し、文書ＩＤ"Ｄ０１"を「未承認」状態として承認状態表４４に登録する（Ｓ５）。このとき、その文書Ｄ０１の所属する部門ＩＤ"Ｓ０１"の情報も承認状態表に登録する。
【００５１】
また、この承認依頼イベントでは、副本ＩＤ"a" = "B012345678"を含んだ要求に対し、ユーザＰ０１に対して副本ＩＤ"ｂ"="B564370987"を含む副本ｓｃ２０６を提供したので、ログ管理部１９はログレコードとして、図１１の３行目のようなレコードを記録する。なお、この３行目のログレコードに対し、承認申請２０４の発行者であるユーザのＩＤ"Ｐ０１"も合わせて記録するようにすれば、誰からの要求に対し誰に対し副本ＩＤを提供したのかを、後で追跡できる。
【００５２】
ユーザＰ０１が、クライアント端末２０−Ｐ０１にて、受け取った承認依頼用副本ｓｃ２０６を開くと、ビューワ２２はその副本ｓｃ２０６が承認依頼の属性を持つことを認識し、承認用の閲覧要求２０８を生成し、文書管理サーバ１０ａに送る。承認用閲覧要求２０８には、副本ｓｃ２０６に含まれていた副本ＩＤ"b"とユーザＩＤ"Ｐ０１"が含まれ、その要求２０８が承認のためであることを示す情報が含まれる。
【００５３】
承認用閲覧要求２０８を受け取った文書管理サーバ１０ａでは、承認プロセス管理部４０がその要求２０８に含まれる副本ＩＤ"b"に対応する文書ＩＤ"Ｄ０１"をログレコードから特定し、その文書ＩＤが示す電子文書を正本文書ＤＢ１１から求めてそのコピーを作成する。そして、そのコピーのファイルに対し、新たに生成した副本ＩＤ"ｃ"(= "B345654321"と、承認操作用の副本である旨を示す情報とを属性として設定することで副本ファイル２１０を生成し、それをクライアント端末２０−Ｐ０１に返す。このとき、ログ管理部１９は、図１１のテーブルの８行目（下から３行目）のようなログレコードを記録する。
【００５４】
副本ファイル２１０を受け取ったクライアント端末２０−Ｐ０１では、ビューワ２２がそのファイル２１０を開く。承認権限者Ｐ０１は、副本ファイル２１０に含まれる電子文書"Ｄ０１"のコピーをビューワ２２により閲覧し、この文書に承認を与えるかどうかを判断する。ここで、副本ファイル２１０には承認操作用の副本である旨の属性が設定されているので、ビューワ２２は、その属性を認識し、承認をするか否かを問い合わせるダイアログ画面を生成し表示する。このダイアログは、例えば、ユーザＰ０１がその副本ファイル２１０を閉じる操作をしたことをトリガとして表示すればよい。ただし、ダイアログはそのタイミングに限らず、文書を表示している間に表示してもよい。
【００５５】
なおビューワ２２は、その副本ファイル２１０をファイルシステムやローカルのハードディスク等に保存することはしない（例えば、その副本ファイル２１０については、ユーザが保存操作を選択できないようにするなど）。また、ビューワ２２は、副本ファイル２１０に含まれる副本ＩＤ"ｃ"により、要求２０８の際に用いたファイルシステム内の副本ｓｃ内の副本ＩＤを、副本ファイル２１０に含まれる副本ＩＤ"ｃ"に書き換える。
【００５６】
承認権限者Ｐ０１が、そのダイアログに対して承認の操作を行った場合、ビューワ２２は承認の旨を示すコードと副本ＩＤ"ｃ"とを含む承認情報２１２を文書管理サーバ１０ａに送る。なお、承認権限者Ｐ０１が承認しない旨を選択した場合は、承認しない旨のコードと副本ＩＤ"ｃ"とを含む承認不可情報（図示省略）を文書管理サーバ１０ａに送る。
【００５７】
文書管理サーバ１０ａの承認プロセス管理部４０は、クライアント端末２０から承認情報２１２又は承認不可情報を受け取った場合、それに含まれる副本ＩＤ"ｃ"に対応する正本の文書ＩＤ"Ｄ０１"をログ管理部１９から検索し、承認状態表４４における文書ＩＤ"Ｄ０１"の状態を、承認情報２１２の場合は「承認済み」に、承認情報の場合は「承認不可」に、それぞれ更新する。また、副本ｓｃ提供部１５は、更新用の副本ＩＤ"ｄ"(= "B787878787)を生成し、これを含んだ副本ｓｃ２１４を生成してクライアント端末２０−Ｐ０１に返す。ここでログ管理部１９は、図１１のテーブルの９行目（下から２行目）のようなログレコードを生成して記録する。
【００５８】
クライアント端末２０−Ｐ０１は、承認指示に用いた副本ｓｃ内の副本ＩＤを、受け取った副本ｓｃ２１４それに含まれる副本ＩＤ"ｄ"に更新する。
【００５９】
以上のような流れにより、文書管理サーバ１０ａに登録された電子文書"Ｄ０１"に対して適切な承認権限者Ｐ０１からの承認がなされる。なお、以上では、電子文書"Ｄ０１"に対する承認の流れを例にとって説明したが、文書管理サーバ１０ａは、複数の文書の承認プロセスを並行して管理することができ、図１１のテーブルにはそれら複数の文書についてのログレコードが示されている。
【００６０】
なお、以上の例では、承認権限者Ｐ０１は、ユーザＰ０３が承認を申請した電子文書"Ｄ０１"に対して承認を行うだけであったが、承認権限者Ｐ０１がその電子文書"Ｄ０１"に修正を加えた上で承認を行えるようにすることもできる。すなわち、この場合、クライアント端末２０−Ｐ０１のビューワ２２は、副本ファイル２１０に含まれる電子文書"Ｄ０１"の文書データを表示すると共に、承認権限者Ｐ０１からのその文書データへの編集操作を受け付ける。そして、承認権限者Ｐ０１がその文書に対する承認操作をビューワ２２に対して行うと、ビューワ２２は、副本ファイル２１０に含まれる副本ＩＤ"ｃ"と、編集後の文書データとを含んだファイル（例えばＰＤＦ形式）とユーザＩＤＰ０１とを含んだ承認情報２１２を文書管理サーバ１０ａに送る。文書管理サーバ１０ａは、承認プロセス管理部４０により上述と同様の承認のための処理を行うと共に、正本文書ＤＢ１１に登録された当該文書"Ｄ０１"の実体データを、その承認情報２１２に含まれる編集後の文書データに置き換える。ここで、置き換え前の文書データを旧バージョンとして保存してもよい。以上のような仕組みによれば承認対象の文書に対して修正を加えた上で承認を行うことができる。
【００６１】
以上、実施形態を説明した。本実施形態では、承認権限者が承認を行うには、承認依頼イベントで生成された副本ＩＤを含む副本ｓｃ２０６を取得して用いる必要がある。承認依頼のための副本ｓｃ２０６は、承認プロセス管理部４０が、承認権限者表に登録された適切な登録者に対して送信するので、第三者が承認依頼用副本ｓｃ２０６を取得することは困難である。したがって、本実施形態では、第三者が不正に承認を行うリスクが少ない。
【００６２】
また、本実施形態では、承認プロセス管理部４０が承認依頼を送った宛先の承認権限者がログレコードに記録されている。したがって、文書管理サーバ１０ａは、ユーザから承認用閲覧要求２０８を受けた段階で、その要求に含まれる副本ＩＤを「提供した副本ＩＤ」の値として持つ承認依頼イベントのログレコードにおける「宛先ユーザ」の値から正当な承認権限者を知ることができる。したがって、承認プロセス管理部４０は、承認用閲覧要求２０８をユーザから受け取った際に、ログレコードから正当な承認権限者（すなわち承認依頼の宛先ユーザ）を求め、要求２０８を送ってきたユーザのユーザＩＤと比較することで、そのユーザが正当な承認権限者か否かをチェックすることができる。これにより、仮に第三者が承認依頼用の副本ｓｃを取得し、これを用いて承認を行おうとしても、文書管理サーバ１０ａは、その第三者から承認用閲覧要求２０８を受けた段階で、その第三者の端末から送られてくるユーザＩＤがその正当な承認権限者と異なることを認識することができるので、承認対象の電子文書の写し（副本ファイル）をその第三者に提供することすらない。またこの場合、第三者は承認用副本ファイル２１０を受け取ることができないので、承認を行うこともできない。また、万が一第三者が承認用副本ファイル２１０を何らかの手段で取得して承認情報２１２を送信したとしても、承認プロセス管理部４０は、同時に送られてくるユーザＩＤが正当な承認権限者のものでないことをログレコードから判別することができるので、その承認操作を受け付けないようにすることができる。
【００６３】
また本実施形態、承認依頼の副本ｓｃ２０６を用いてユーザが承認用閲覧要求２０８を行った場合、そのユーザのユーザＩＤがその副本ｓｃ２０６の副本ＩＤと共に文書管理サーバ１０ａに送られ、ログ管理部１９に記録される。したがって、仮に正当な承認権限者でない第三者からの要求に対して文書管理サーバ１０ａが承認用副本ファイル２１０を提供したり、承認操作を受け付けたりする場合でも、それらのイベントのログがその第三者のユーザＩＤと共にログ管理部１９に残るので、第三者がそのような操作を行ったことを後でログデータから割り出すことができる。
【００６４】
このように、本実施形態によれば、承認の正当性を従来より厳密にチェックすることができる。
【００６５】
なお、本実施形態において、承認プロセス管理部４０が、電子文書の承認を申請したユーザ（図１０の例ではユーザＰ０３）に対し、その電子文書の承認プロセスの進行状況の情報を提供するようにすることもできる。この場合、例えば、承認申請者が文書登録の際に受け取った副本ｓｃ２０２（図１０参照）を開けると、ビューワ２２が副本ｓｃ２０２に含まれる副本ＩＤ"ａ"とユーザＩＤ"Ｐ０３"を文書管理サーバ１０ａに送信する。文書管理サーバ１０ａは、ログ管理部１９からその副本ＩＤ"ａ"に対応する正本の文書ＩＤ"Ｄ０１"を検索し、承認状態表４４からその文書ＩＤ"Ｄ０１"に対応する承認状態を求め、その承認状態の情報をクライアント端末２０−Ｐ０３に返す。これによりユーザＰ０３は、自分が承認申請した文書の承認状態を知ることができる。
【００６６】
ここで、文書管理サーバ１０ａは、承認状態表４４を検索するだけでなく、ログ管理部１９からその文書ＩＤ"Ｄ０１"を持つログレコードを検索し、検索したログレコードに含まれるイベントから、当該文書Ｄ０１のより詳細な状態を求めることもできる。すなわち、ログレコードのイベント情報から、承認権限者Ｐ０１について「文書取得」イベントが記録されていなければ、承認権限者が当該文書を未読であると判断でき、「文書取得」イベントは記録されているが「承認」イベントが記録されていなければ、承認権限者は当該文書を既読であるが未承認であると判断できる。また、「承認」イベントが記録されていれば、承認済みであると判断できる。このように、ログ管理部１９のログデータを参照することで、承認状態表４４に示されない未読／既読の判別を行うこともできる。文書管理サーバ１０ａは、このように判別した承認状態（未読／既読だが未承認／承認済み／承認不可）をクライアント端末２０−Ｐ０３に返す。
【００６７】
また、承認プロセスの進行状況の情報提供を、副本ｓｃを用いて行ってもよい。この場合、例えば、ユーザＰ０３から承認申請２０４を受けた際に、文書管理サーバ１０ａは、承認権限者Ｐ０１に承認依頼のための副本ｓｃ２０６を送るのと並行して、依頼元のユーザＰ０３に対し新たな副本ＩＤ"ｘ"を含んだ承認プロセス確認用の副本ｓｃ２０５を送る。ログ管理部１９はこのイベントをログに記録する。クライアント端末２０−Ｐ０３は、承認依頼に用いられた副本ｓｃ２０２をこの副本ｓｃ２０５に置き換える。そして、ユーザＰ０３がその副本ｓｃ２０５を開くと、ビューワ２２は副本ＩＤ"ｘ"を含んだ承認プロセス確認要求を文書管理サーバ１０ａに送る。すると、承認プロセス管理部４０は、その副本ＩＤ"ｘ"を「提供した副本ＩＤ」として持つログレコードから、要求元のユーザＰ０３が承認依頼を行ったことが分かるので、承認状態を調べてそのユーザＰ０３に回答する。すなわち、承認プロセス管理部４０は、その副本ＩＤに対応する正本の文書ＩＤをログから特定し、その文書ＩＤに対応する承認状態を承認状態表４４（及びログ管理部１９内のログデータ）から求め、その承認状態の情報を含んだ副本ｓｃ（新たに生成した更新用の副本ＩＤも含む）を生成してクライアント端末２０−Ｐ０３に返す。これにより、ユーザＰ０３は、自分が承認を申請した文書の状態を知ることができる。また、ユーザＰ０３は、このとき受け取った副本ｓｃを用いることで、承認状態を再度確認することもでき、この際にも同様に承認状態の情報を含んだ新たな副本ｓｃがクライアント端末２０−Ｐ０３に提供され、既存の副本ｓｃと置き換えられる。
【００６８】
なお、以上の各例では、文書管理サーバ１０ａがログ管理部１９の情報から詳細な承認状態を判別してユーザに提供したが、この代わりに、クライアント端末のビューワ２２がその判別を行ってもよい。この場合、文書管理サーバ１０ａは、ログ管理部１９から検索した文書ＩＤ"Ｄ０１"についてのイベントの情報をクライアント端末２０−Ｐ０３のビューワ２２へと送る。ビューワ２２には、イベントの情報から詳細な承認状態を判別するためのルール情報を有しており、承認状態の問合せに応じて文書管理サーバ１０ａから受け取ったイベントの情報から、そのルール情報を用いて、詳細な承認状態を求めて表示する。
【００６９】
また、文書管理サーバ１０ａが承認状態の情報（或いはログ管理部１９から求めたイベントの情報）を承認申請者Ｐ０３のクライアント端末２０−Ｐ０３に送る際に、当該電子文書の正本のコピーも併せて送ってもよい。この場合、文書管理サーバ１０ａは、例えば、正本のコピーである副本ファイルに対して、承認状態（又はイベント情報）を属性として設定したものをクライアント端末２０−Ｐ０３に提供すればよい。このようにすることで、承認申請者は、自分が登録した電子文書が、どのように修正されて（或いは修正されずに）承認されたかを知ることができる。
【００７０】
以上の実施形態において、文書管理サーバ１０ａは、承認依頼の副本ｓｃ２０６又は承認操作用の副本ファイル２１０を用いて行われた要求を受けたときに、ユーザ認証を行って、その要求を送ってきたものが正当な承認権限者であるかを判定してもよい。ユーザ認証には、例えば、承認権限者にユーザＩＤとパスワード等の認証情報との入力を求めるなどの方法で行えばよい。
【００７１】
次に、課長、部長、本部長のように、組織の階層構造に従って複数段階の承認を要する場合に上記実施形態を適用した例を説明する。この例のシステム構成、及びシステムを構成する装置構成は、上記実施形態のものと同様でよい。ただし、承認権限者表４２には、図１３に示すように、部門ごとに、第１，第２，第３というように、各段階の承認権限者のユーザＩＤが順番に列挙される。
【００７２】
この例では、各段階の承認権限者ごとに上記実施形態と同様の承認処理の流れを実行すればよい。具体的には以下のような処理の流れとなる。以下の説明では、適宜図１０を参照する。すなわち、承認プロセス管理部４０は、承認申請者から電子文書"Ｄ０１"の承認申請を受け取った場合、まずその電子文書の第１承認権限者を承認権限者表４２から求め、その第１承認権限者に対して承認依頼の副本ｓｃを送る（第１承認依頼イベント）。このイベントの後、第１承認権限者がその副本ｓｃを用いて承認用の副本ファイル２１０を文書管理サーバ１０ａから取得し、その副本ファイル２１０を用いて承認操作を行う。このようにして第１承認権限者から承認情報２１２を文書管理サーバ１０ａに送ると、承認プロセス管理部４０は、電子文書"Ｄ０１"の状態を「第１承認済み」とする。ここで、第１承認権限者が、電子文書"Ｄ０１"を修正した上で承認を行った場合は、文書管理サーバ１０ａは、正本文書ＤＢ１１内のその電子文書"Ｄ０１"のデータを修正後のものに置き換える。そして、承認プロセス管理部４０は、承認権限者表４２から第２承認権限者を求め、第２承認権限者に対して承認依頼用の副本ｓｃを送信する（第２承認依頼イベント）。第２承認権限者は、その副本ｓｃを用いて、第１承認権限者の場合の同様にして承認を行うことができる。そして、第２承認権限者から承認の旨の情報を受け取ると、承認プロセス管理部４０は、電子文書"Ｄ０１"の状態を「第２承認済み」へと変更する。以下、第３以降の承認権限者についても同様の処理を繰り返す。このような処理により、複数段階の承認を要する承認プロセスの管理が可能となる。この処理の流れにおいて、ログ管理部１９に記録されるログデータの例を図１４に示す。この例では、部門Ｓ００１に所属するユーザＰ００６が承認を申請した電子文書"Ｄ００１"に対して行われた承認プロセスを記録したものである。
【００７３】
この例でも、承認申請者は、上記実施形態と同様、自分の持つ副本ｓｃを用いることで、申請した文書の承認状態を確認することができる。
【００７４】
このように複数段階の承認に対応した例によれば、文書管理サーバ１０ａは、各段階の承認依頼イベントと各段階の承認権限者による承認操作のためのイベントとをログ管理部１９で記録しているので、各段階の正しい承認権限者により承認が行われたかをログデータから確認することができる。また、承認依頼用の副本ｓｃの送信先のユーザ（すなわち正しい承認権限者）以外の者がその副本ｓｃや、この副本ｓｃを用いて得られる副本ファイルを入手して承認操作を行おうとした場合、文書管理サーバ１０ａは、正しい承認権限者でない者からの操作と判断して、その操作を認めないようにすることができる。このように複数段階の承認を要する承認プロセスに対しても、上記実施形態の方式は適用可能である。
【００７５】
次に、文書閲覧許可のプロセスを管理するための実施形態について説明する。従来、文書データベースに保存された電子文書の閲覧管理は、電子文書のファイルやフォルダに対するアクセス管理で行われることが一般的であった。この方式では、ファイルやフォルダに対してアクセス権のあるユーザやグループを予めアクセスコントロールリストに登録しておき、ユーザから電子文書に対する閲覧要求があった場合、アクセスコントロールリストからそのユーザがそのファイルに対するアクセス権があるか否かをチェックしていた。このような従来システムでは、ユーザがアクセス権のない電子文書を閲覧しようとする場合、書面で閲覧申請を行うなどの煩瑣な作業が必要であった。本実施形態では、アクセスコントロールリスト上ではアクセス権が認められない文書の閲覧を管理するために、副本ＩＤを用いた文書管理システムを利用する。
【００７６】
この実施形態の全体的なシステム構成は図１に示したものと同様である。ただし、この実施形態では、図１５に示すように、文書管理サーバ１０ｂが承認プロセス管理部４０の代わりに、閲覧プロセス管理部５０を備える。閲覧プロセス管理部５０は、ユーザからの閲覧要求を処理する機能モジュールである。閲覧プロセス管理部５０は、図１６に示すように、文書開示許可表５２、開示許可権限者表５４、及び個別閲覧許可表５６を有する。
【００７７】
文書開示許可表５２は、正本文書ＤＢ１１に登録された各電子文書に対する閲覧アクセスの管理のためのテーブルである。図１７に示すように、文書開示許可表５２には、電子文書の各々について、文書ＩＤ、アクセス分類、部門ＩＤ、個別閲覧許可数という項目が登録される。アクセス分類は、文書ＩＤによって特定される電子文書のアクセス制限上の分類を示す。「公開」は、本システムに登録された全ユーザに公開される文書であることを示し、「部外秘」は、当該文書の属する部門以外には開示を認めない文書であることを示す。部門ＩＤは、当該電子文書の属する部門の識別情報である。これらアクセス分類と部門ＩＤは、従来型の一括的なアクセスコントロールのために用いる。個別閲覧許可数は、各電子文書の開示許可権限者が、それぞれの電子文書について申請者に個別的に与えた閲覧許可の数である。
【００７８】
開示許可権限者表５４には、正本文書ＤＢ１１内の電子文書ごとに、その電子文書についての個別的な閲覧許可を与える権限を持つユーザのユーザＩＤが登録されている。開示許可権限者表５４は、図８の承認権限者表と同様のものでよいので、図示は省略する。
【００７９】
個別閲覧許可表５６には、図１８に示すように、開示許可権限者から個別に閲覧許可が与えられたユーザ（閲覧許可対象ユーザ）のユーザＩＤと、閲覧許可の対象である電子文書の文書ＩＤとが登録されている。
【００８０】
ユーザが副本ｓｃを用いて文書管理サーバ１０ｂに閲覧要求を行った場合、閲覧プロセス管理部５０は、図１９に示すような処理を実行する。すなわち、閲覧プロセス管理部５０は、ネットワーク上にある組織情報管理サーバ（図示省略）などを参照することで、その閲覧要求に伴うユーザＩＤから要求元ユーザの所属部門を求める。また、閲覧要求に含まれる副本ＩＤに対応する正本の文書ＩＤをログデータに基づき特定し、文書開示許可表５２におけるその文書ＩＤのエントリを求める。そして、閲覧プロセス管理部５０は、そのエントリにおけるアクセス分類及び部門ＩＤと、要求元ユーザの所属部門とから、そのユーザがその電子文書に対するアクセス権を持つか否かを判定する（Ｓ１１）。アクセス権ありと判定した場合、閲覧プロセス管理部５０は、その文書ＩＤに対応する電子文書の副本ファイルを作成し、要求元のユーザに提供する（Ｓ１２）。
【００８１】
一方、アクセス権なしと判定した場合、閲覧プロセス管理部５０は、文書開示許可表５２にて、その文書ＩＤのエントリ中の個別閲覧許可数が０より大きいか否かを調べ（Ｓ１３）、０より大きければ（すなわち１以上）、更に個別閲覧許可表５６における当該文書ＩＤのエントリに、要求元ユーザのユーザＩＤが登録されているかどうかを調べる（Ｓ１４）。ステップＳ１４で、要求元ユーザのＩＤが登録されていれば、閲覧プロセス管理部５０は、要求された文書の副本ファイルを作成し、要求元に提供する（Ｓ１２）。
【００８２】
ステップＳ１３で個別閲覧許可数が０以下と判定された場合、又は、個別閲覧許可数が０より大きくても要求元ユーザが個別閲覧許可表５６に登録されていないと判定された場合、要求元ユーザはその文書に対するアクセス権を持たないと判断できる。この場合、閲覧プロセス管理部５０は、閲覧申請を行うか否かの問合せを要求元ユーザのクライアント端末に送る（Ｓ１５）。この問合せには、開示許可権限者表５４から求められた当該文書の開示許可権限者の名前が含まれる。この問合せは、例えば図１６に示す副本ｓｃ３００としてクライアント端末に提供してもよい。
【００８３】
この閲覧申請要否問合せの送信の後の処理の流れを、図１６を用いて説明する。図６では、ユーザＰ２が電子文書の閲覧を申請した者であり、ユーザＰ０がその電子文書に対する開示許可権限者であるとする。
【００８４】
クライアント端末２０−Ｐ２のビューワ２２は、文書管理サーバ１０ｂから受け取った副本ｓｃ３００（副本ＩＤ = a（図２１の例ではB789に対応））の属性を調べることで、それが閲覧申請要否の問合せであることを認識し、図２０に示すようなダイアログ画面４００を表示する。このダイアログ画面４００には、申請対象の文書名４０２，開示許可権限者の名前４０４が表示されると共に、閲覧目的の入力欄４０６が示される。ユーザＰ２は、閲覧申請を行う場合、入力欄４０６に目的を入力した上で、申請実行ボタン４０８をクリックすればよい。これに応じ、ビューワ２２は、副本ｓｃ３００に含まれた副本ＩＤ"ａ"を含んだ閲覧申請データ３０２を作成し、文書管理サーバ１０ｂに送る。これを受け取った文書管理サーバ１０ｂは、更新用の副本ＩＤ"ｂ"を生成し、これを含んだ副本ｓｃ３０４をクライアント端末２０−Ｐ２に返す。このとき、ログ管理部１９は、図２１のテーブルの上から２行目のような閲覧申請イベントのレコードを記録する。また、閲覧プロセス管理部５０は、副本ＩＤ"ｃ"を生成し、これと閲覧申請通知である旨の情報とを属性として含んだ副本ｓｃ３０６を生成し、これを開示許可権限者Ｐ０に送る。ログ管理部１９は、図２１のテーブルの３行目のような申請発信イベントのレコードを記録する。
【００８５】
ユーザＰ０がクライアント端末２０−Ｐ０のビューワ２２でこの副本ｓｃ３０６を開くと、ビューワ２２は副本ＩＤ"ｃ"を含んだ申請開封通知３０８を文書管理サーバ１０ｂに送る。この通知３０８に応じ、閲覧プロセス管理部５０は、閲覧申請対象の電子文書のコピーと、新たな副本ＩＤ"ｄ"と、閲覧申請者の情報とを含んだ副本ファイル３１０をクライアント端末２０−Ｐ０に返す。ログ管理部１０は、図２１のテーブルの４行目のような申請開封イベントのレコードを記録する。
【００８６】
副本ファイル３１０を受け取ったクライアント端末２０−Ｐ０のビューワ２２は、副本ファイル３１０に含まれる文書データを表示すると共に、図２２に示すようなダイアログ画面４１０を表示する。この画面４１０には、閲覧申請対象の文書名４１２、閲覧申請者の名前４１４が表示され、閲覧許可ボタン４１６、閲覧不可ボタン４１８及び保留ボタン４１９が示される。開示許可権限者Ｐ０は、閲覧を許可する場合にはボタン４１６を、閲覧を認めない場合はボタン４１８を、判断を保留する場合にはボタン４１９をクリックする。ボタン４１６がクリックされた場合、ビューワ２２は、副本ｓｃ３１０に含まれていた副本ＩＤ"ｄ"を含んだ閲覧許可通知３１２を作成し、文書管理サーバ１０ｂに送る。ボタン４１８が押下された場合は、副本ＩＤ"ｄ"を含んだ閲覧不許可通知を生成し、文書管理サーバ１０ｂに送る。またボタン４１９が押下された場合は、ビューワ２２は単にその副本ファイルを閉じる。
【００８７】
文書管理サーバ１０ｂは、閲覧許可通知３１２を受け取った場合、更新用の副本ＩＤを生成してクライアント端末２０−Ｐ０に返す（図示省略）。ログ管理部１９は、図２１のテーブルの５行目のような閲覧許可イベントのレコードを記録する。そして、閲覧プロセス管理部５０は、文書開示許可表５２における対象文書の個別閲覧許可数に１を加え、対象文書の文書ＩＤと閲覧申請者のユーザＩＤとのペアを個別閲覧許可表５６に追加する。そして、文書管理サーバ１０ｂは、新たな副本ＩＤ"ｅ"を生成し、これを含んだ閲覧許可用の副本ｓｃ３１４を生成し、例えば電子メールなどでクライアント端末２０−Ｐ２に送る。ログ管理部１９は、図２１のテーブルの最下行のような許可返信イベントのレコードを記録する。
【００８８】
ユーザＰ２が、この副本ｓｃ３１４を用いて閲覧要求３１６を発した場合、個別閲覧許可数は０より大きく、ユーザＰ２は対象文書の閲覧を許可されたものとして個別閲覧許可表５６に登録されているので、ユーザＰ２はその対象文書のコピー含んだ副本ファイルを得ることができる。
【００８９】
なお、文書管理サーバ１０ｂは、閲覧不許可通知を受け取った場合、閲覧申請者に対しては何も行わなくてもよいし、その旨を閲覧申請者に通知してもよい。
【００９０】
この実施形態において、文書管理サーバ１０ｂは、正当な開示許可権限者以外のユーザから申請開封通知３０８や閲覧許可通知３１２、閲覧不許可通知を受け取った場合、正当なもの以外からの通知であることをログデータから判別することができるので、そのような通知元に対してはサービスを提供しないようにすることができる。
【００９１】
以上に説明した文書閲覧許可を得るための実施形態でも、上述の文書承認の実施形態と同様の仕組みを用いているので、同様に、閲覧許可の正当性を従来よりも厳密にチェックすることができる。
【００９２】
以上の例では、個人ユーザを対象とする閲覧許可の場合を例示したが、グループに対する個別閲覧許可を設定することも可能である。例えば、閲覧申請の際にユーザが、本人のみについての申請なのか本人の属するグループについての申請なのかを指定できるようにし、その指定に応じてグループＩＤを個別閲覧許可表５６の閲覧許可対象ユーザＩＤとして登録するようにすればよい。
【００９３】
また、ユーザが、既存のグループでは括れない複数の人に対して電子文書を開示するために、開示許可権限者に閲覧許可を求める場合もありうる。このような場合に対応するために、申請者に対して電子文書の一次頒布を許可することが考えられる。このように一次頒布を許可するための変形例を以下に説明する。変形例のシステム構成は、閲覧許可の実施形態と同様でよい。
【００９４】
この例では、図２３に示すように、閲覧申請要否の問合せのためのダイアログ画面４００ａに、その閲覧申請が一次頒布を含むのか含まないのかを示すための入力部（図ではチェックボックス４２２及び４２４）が含まれる。その他の表示事項は図２０のダイアログ画面４００と同様でよい。また、個別閲覧許可表５６には、図２４に示すように、許可の種類という欄が設けられる。許可の種類には、「閲覧」と「頒布」とがある。「頒布」は一次頒布のことである。一次頒布の許可を受けた者は、自分が文書管理サーバ１０ｂに対して版部先として指定したユーザに対して電子文書の閲覧を許可できる。
【００９５】
申請者がダイアログ画面４００ａで一次頒布を含む閲覧を申請した場合、文書管理サーバ１０ｂは、副本ｓｃのシステムを用いて、開示許可権限者に対してその申請者に一次頒布を認めるか否かを問い合わせる。そして、開示許可権限者が一次頒布を許可する回答を行った場合、閲覧プロセス管理部５０は、個別閲覧許可表５６に、対象文書の頒布を閲覧申請者に許可した旨を示すレコードを登録する。そして、文書管理サーバ１０ｂは、閲覧申請者、すなわち一次頒布権者に対して副本ｓｃを提供する。
【００９６】
ユーザから副本ＩＤを提示した閲覧要求を受けた場合、文書管理サーバ１０ｂは、その副本ＩＤに対応する正本の文書ＩＤを特定し、個別閲覧許可表５６を参照して、そのユーザのその正本に対する閲覧許可の種類を調べる。その種類が頒布であった場合、文書管理サーバ１０ｂは、その正本のコピーを含み、一次頒布許可のフラグが属性にセットされた副本ファイルを作成し、そのユーザに提供する。ビューワ２２は、副本ファイルを開く際、一次頒布許可の属性を検知すると、図２５に示すような一次頒布先指定画面４５０を表示する。この画面４５０には、一次頒布先を検索するための検索欄４６０が設けられる。検索欄４６０には、ユーザの名前で検索条件を入力するための条件入力部４６２と、ユーザの所属部門で検索条件を入力するための条件入力部４６４が含まれる。入力欄４６２ａ、４６４ａには、例えば、一以上のキーワードからなる論理式を入力することができる。ビューワ２２は、入力欄４６２ａ又は４６４ａに入力された検索条件を満足するユーザを組織情報管理サーバから検索し、検索結果を結果表示欄４６６に表示する。一次頒布権者は、結果表示欄４６６に示された各ユーザの中から一次頒布先とするものを選択ボタン４６８により選択する。選択されたユーザは一次頒布先リスト４７０に列挙される。一次頒布者は、このリスト４７０から削除したいユーザがあれば、それを削除ボタン４７２により削除できる。そして、一次頒布権者が実行ボタンを４７４をクリックすると、ビューワ２２は、一次頒布先ユーザのリストを含んだ頒布要求を文書管理サーバ１０ｂに送る。
【００９７】
文書管理サーバ１０ｂは、そのリストに含まれる各ユーザを対象文書についての閲覧許可対象ユーザ（許可の種別は「許可」）として個別閲覧許可表５６に登録し、それら一次頒布先の各ユーザに対してその対象文書に対応づけられた副本ｓｃを送信する。
【００９８】
一次頒布先のユーザは、受け取った副本ｓｃを用いることで、対象文書を閲覧できる。ただし、一次頒布先のユーザは、個別閲覧許可表５６の設定により「閲覧」のみを認められるだけであり、その副本ｓｃを用いても他のユーザにその文書を頒布することはできない。すなわち、この仕組みによれば、文書の頒布許可を受けたユーザ以外のユーザが、他のユーザに対してその文書の頒布（すなわち閲覧の許可）を行うことはできない。
【００９９】
以上、文書の閲覧についての許可を例にとったが、閲覧以外の各種の操作（例えば編集など）についての許可を権限者に求める場合にも、同様の仕組みを用いることができる。
【０１００】
以上、本発明の実施形態について説明した。例示した実施形態は、いずれも、電子文書に関する承認を与えるプロセスを管理するという点で共通している。すなわち、１つの実施形態は、「文書そのもの」に対して権限者が承認を与えるものであったのに対し、別の実施形態は「文書に対する操作」に対して権限者が承認を与えるものと捉えることができる。
【０１０１】
以上の実施形態では、ログ管理部１９が記録したログデータを調べることで副本ＩＤに対応する正本を特定していたが、正本と副本ＩＤとの対応関係の情報を別途作成しておき、その情報から副本ＩＤに対応する正本を特定してもよい。
【図面の簡単な説明】
【０１０２】
【図１】副本ショートカットを用いた文書管理システムの概略構成を示すブロック図である。
【図２】クライアント端末の内部構成の例を示す図である。
【図３】文書管理サーバの内部構成の例を示す図である。
【図４】ログ管理部が生成するログデータの一例を示す図である。
【図５】図４のログデータが示す副本ＩＤの派生関係のツリーを示す図である。
【図６】図４のログデータが生成される場合のシステムの動作を説明するための図である。
【図７】文書承認システムにおける文書管理サーバの内部構成の例を示す図である。
【図８】承認権限者表の例を示す図である。
【図９】承認状態表の例を示す図である。
【図１０】承認プロセスの例を示す図である。
【図１１】承認プロセスにおいてログ管理部が生成するログデータの一例を示す図である。
【図１２】ユーザから承認依頼を受けた時の承認プロセス管理部の処理手順の例を示す図である。
【図１３】複数段階の承認を要する承認プロセスにおける承認権限者表の例を示す図である。
【図１４】複数段階の承認を要する承認プロセスにおいてログ管理部が生成するログデータの一例を示す図である。
【図１５】文書閲覧管理の実施形態における文書管理サーバの内部構成の例を示す図である。
【図１６】文書閲覧管理の実施形態における、個別閲覧申請のプロセスを説明するための図である。
【図１７】文書開示許可表の例を示す図である。
【図１８】個別閲覧許可表の例を示す図である。
【図１９】文書閲覧要求を受けた時の閲覧プロセス管理部の処理手順の例を示すフローチャートである。
【図２０】閲覧申請要否の問合せ画面の一例を示す図である。
【図２１】文書閲覧管理の実施形態においてログ管理部が記録するログデータの一例を示す図である。
【図２２】閲覧申請を認めるか否かを問い合わせるダイアログ画面の一例を示す図である。
【図２３】一次頒布の要否を含む閲覧申請要否問合せのためのダイアログ画面の一例を示す図である。
【図２４】一次頒布と通常の閲覧とを区別して登録した個別閲覧許可表の例を示す図である。
【図２５】一次頒布先の指定画面の一例を示す図である。
【符号の説明】
【０１０３】
１０ 文書管理サーバ、１１ 正本文書ＤＢ、１３ 正本文書登録部、１５ 副本ｓｃ（ショートカット）提供部、１７ 副本文書提供部、１９ ログ管理部、２０ クライアント端末、２２ ビューワ、２４ ファイルシステム、３０ ネットワーク。
【技術分野】
【０００１】
本発明は、電子文書に対する承認、又は電子文書の閲覧申請に対する承認を、電子的に実行するためのシステムに関する。
【背景技術】
【０００２】
オフィス業務では、文書作成者が文書を作成するだけでは、その文書は業務上の正式の文書とはならず、その文書に対して所定の承認者（複数の場合もある）が承認を与えて初めてその文書が正式の文書となることが一般的である。このような承認業務を電子化するシステムとして、特許文献１に示されるシステムが知られている。このシステムでは、電子文書に対する承認操作を行おうとする者がある場合、その者を認証し、この認証によりその者がその電子文書の承認者であると判定された場合、承認許可鍵コードを生成する。そして、承認者がその承認許可鍵コードを正しく入力すると、システムはその電子文書に対して電子押印を行う。
【０００３】
【特許文献１】特開２００５−０２５５０５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記従来システムでは、第三者が承認者のユーザＩＤ、パスワードを入手し、システムにログインすれば、不正な承認が容易に実行できるという問題がある。
【課題を解決するための手段】
【０００５】
本発明の１つの側面では、文書管理サーバとクライアントとを含む承認管理システムが提供される。文書管理サーバは、管理している電子文書に対し、ユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行すると共に、その操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録する。クライアントは、電子文書に対する操作要求に応じて文書管理サーバから受け取った操作ＩＤをその電子文書に対応する操作ＩＤとして保存すると共に、保存した操作ＩＤを指定してユーザから操作指示を受けた場合に、その操作ＩＤを含んだ操作要求を文書管理サーバへと送る。また文書管理サーバは、電子文書に関する承認申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部とを備える。
【０００６】
本発明の別の側面では、電子文書が登録される文書データベースと、文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行する操作ＩＤ発行部と、ユーザからの操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部と、電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、を備える文書管理サーバが提供される。
【０００７】
本発明の更に別の側面では、コンピュータを、電子文書が登録される文書データベース、文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行する操作ＩＤ発行部、ユーザからの操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部、電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部、として機能させるためのプログラム、が提供される。
【発明を実施するための最良の形態】
【０００８】
以下、図面を参照して、本発明の実施の形態（以下「実施形態」と呼ぶ）について説明する。
【０００９】
まず、実施形態のシステムのベースとなる、副本ショートカットを用いた文書管理システムについて説明する。
【００１０】
図１は、この文書管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０−１，２０−２，・・・（以下、クライアント端末２０と総称する）から構成される。
【００１１】
このシステムでは、電子文書の正本を文書管理サーバ１０で管理し、クライアント端末２０にはその電子文書を保存しないようにすることで、電子文書のセキュリティを確保する。クライアント端末２０には、電子文書そのもののファイルの代わりに、その電子文書にアクセスするための情報を含んだ副本ショートカット（以下「副本ｓｃ」と略す）と呼ぶファイルを持たせる。副本ｓｃには、例えば、副本ＩＤと呼ぶ管理用の識別情報と、文書管理サーバ１０のホスト名又は文書閲覧要求用のＵＲＬ（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"を伴った閲覧要求１１６を発行する。これに応じ文書管理サーバ１０は、その副本ＩＤ"ｃ"に対応する正本のコピーを作成するとともに、更新用の副本ＩＤ"ｄ"を生成してそのコピーのファイルの属性にセットすることで副本ファイル１１８を生成し、クライアント端末２０−Ｐ０４に返す。また、ログ管理部１９は、図４のテーブルの５行目に示すようなログレコードを記録する。
【００３６】
クライアント端末２０−Ｐ０４のビューワ２２は、その副本ファイル１１８を開いて表示すると共に、ファイルシステム２４−Ｐ０４内の副本ｓｃ１１４の副本ＩＤを副本ファイル１１８に含まれる更新用の副本ＩＤ"ｄ"へと変更する。これにより、クライアント端末２０−Ｐ０４が持つ電子文書"Ｏ"へのショートカットは副本ｓｃ１２０となる。
【００３７】
ユーザＰ０４が電子文書"Ｏ"の副本閲覧後に副本ｓｃ１２０をユーザＰ０８に送信し、ユーザＰ０８がその副本ｓｃ１２０を用いて閲覧要求１２２を行うと、文書管理サーバ１０は更新用の副本ＩＤ"ｅ"を含む副本ファイル１２４をクライアント端末２０−Ｐ０８に提供し、図４のテーブルの６行目に示すログレコードを記録する。クライアント端末２０−Ｐ０８のビューワ２２は、受け取った副本ファイル１２４を開いてユーザに提供し、ファイルシステム２４−Ｐ０８内の副本ｓｃの副本ＩＤを、その更新用の副本ＩＤ"ｅ"へと変更する。
【００３８】
図４に例示したログデータには、操作イベントにおける副本ＩＤの提供先のユーザＩＤを記録したが、これに加え、そのイベントの契機となった要求を発したユーザＩＤを合わせて記録してもよい。以上の例では、イベントの契機となる要求を発したユーザと、そのイベントにおいて新たに生成した副本ＩＤの提供先とは同一であるが、それらが異なる場合には、上述のように両者のユーザＩＤを記録することが好適である。
【００３９】
以上、実施形態のベースとなる文書管理システムの構成と処理内容について説明した。このシステムの特徴をまとめると以下のようになる。
【００４０】
・電子文書の正本が文書管理サーバに登録される。
・ユーザに対しては、電子文書の実体データの代わりに副本ｓｃが提供される。副本ｓｃには、副本ＩＤが含まれる。なお、副本ｓｃを用いて文書管理サーバ１０上の正本に関する何らかの操作を行う場合、正本を管理する文書管理サーバ１０を特定する必要がある。このために、副本ｓｃには、対応する正本を管理する文書管理サーバ１０を特定する情報を含めてもよい。
・文書管理サーバは、提供した副本ｓｃの副本ＩＤと、それに対応する正本との対応関係を管理する。（上述の例では、副本ＩＤ−正本対応関係をログ管理部１９のログレコードに含める形で管理したが、対応関係のデータは、両者の対応が分かればどのようなデータ形式であってもよい。）
・文書管理サーバ上の文書に対して何らかの操作を行う際には、操作を行う端末が持つ副本ｓｃの副本ＩＤがそのサーバに送られる。
・文書管理サーバは、端末から受け取った副本ＩＤに対応する正本を副本ＩＤ−正本対応関係に基づき特定し、正本に関して、要求された操作を行う。
・文書管理サーバは、正本に関する操作を行った場合、新たな副本ＩＤを生成し、この副本ＩＤを操作を要求したクライアント端末に送る。これを受け取ったクライアント端末は、要求に用いた副本ｓｃの副本ＩＤを、受け取った新たな副本ＩＤへと更新する。
・文書管理サーバは、クライアント端末からの要求に含まれていた副本ＩＤと、その要求に係る操作を行ったことにより生成した新たな副本ＩＤとの対応関係である、副本ＩＤ派生関係を管理する。
・文書管理サーバは、クライアント端末から電子文書の閲覧など、電子文書の実体データを必要とする操作を指示された場合、正本のコピーである副本文書データを提供する。副本文書データは、クライアント端末上で動作するビューワの管理するメモリ上の領域にのみ存在し、ディスク上には保存できない設定となっている。
【００４１】
上述の文書管理システムの例では、文書の登録や、副本ｓｃの取得、文書閲覧などといった操作を例示したが、これに限らず、正本の文書に関連する操作のうち、システムとして把握しておきたい操作の全てを、上記特徴的な処理の対象とすることができる。
【００４２】
次に、以上の文書管理システムをベースとした文書承認システムの実施形態を説明する。この文書承認システムは、あるユーザが作成した文書に対し、承認権限者が承認を行う場合の一連の流れを支援する。
【００４３】
この文書承認システムは、全体的には、図１に示したように、ネットワーク３０を介して接続された文書管理サーバ１０とクライアント端末２０からなる。本実施形態の文書管理サーバ１０ａは、図３に示した文書管理サーバ１０が持つ各モジュールに加え、承認プロセス管理部３０を備えている（図７参照）。
【００４４】
承認プロセス管理部３０は、文書管理サーバ１０に登録された電子文書（正本）に対する承認プロセスを管理する。承認プロセス管理部３０は、図８に例示するような承認権限者表と、図９に例示するような承認状態表とを管理している。
【００４５】
承認権限者表は、図８に示すように、このシステムが適用される組織の部門の識別情報（「部門ＩＤ」）と、その部門に所属する人が作成した電子文書に対して承認を与える権限を持つ承認権限者のユーザＩＤ（「承認権限者ＩＤ」）との対応関係を保持する。例えば、図８の承認権限者表によれば、部門Ｓ０１のメンバが作成した文書は、ユーザＰ０１から承認を受ける必要があることがわかる。一方、承認状態表は、正本文書ＤＢ１１に登録された電子文書の承認プロセスにおける状態（例えば、未承認であるか、承認済であるかなど。「承認状態」と呼ぶ）を管理するためのテーブルである。図９の例では、承認状態表には、登録された文書の文書ＩＤに対応づけて、その文書の所属する部門の部門ＩＤと、その文書の承認状態とが登録される。承認状態表には、文書管理サーバ１０に登録された全ての文書を登録するようにしてもよいし、登録された文書のうち承認申請を受けたもののみを登録するようにしてもよい。以下では、後者の場合を例にとって説明する。
【００４６】
以下図１０を参照して、この文書承認システムにおける承認プロセスの例を説明する。
【００４７】
ユーザＰ０３がクライアント端末２０−Ｐ０３上で作成した電子文書"Ｏ"について承認を求める場合を例にとる。この例は、図１１に示したログデータに対応している。
【００４８】
この例は、ユーザＰ０３は、作成した電子文書"Ｏ"２００の登録要求を文書管理サーバ１０ａに対して送る。これを受けて文書管理サーバ１０ａは、その電子文書２００に一意な文書ＩＤ"Ｄ０１"を付与して正本文書ＤＢ１１に登録するとともに、一意な副本ＩＤ"a"（図１１の例では"a" = "B012345678"）を生成し、その副本ＩＤ"ａ"を含んだ副本ｓｃ２０２をクライアント端末２０−Ｐ０３に返す。このとき、ログ管理部１９は、図１１の２行目のようなログレコードを記録する。
【００４９】
ユーザＰ０３は、クライアント端末２０−Ｐ０３上のビューワ２２で副本ｓｃ２０２を開き、ビューワ２２の操作メニューから「承認申請」を選択する。すると、ビューワ２２は、ユーザＰ０３（承認を申請する申請者）のユーザＩＤと副本ｓｃ２０２に含まれる副本ＩＤ"ａ"とを含んだ承認申請２０４を文書管理サーバ１０ａに送る。
【００５０】
承認申請２０４を受けた文書管理サーバ１０ａでは、承認プロセス管理部４０が、図１２に示す処理を実行する。すなわち、承認プロセス管理部４０は、承認申請２０４に含まれる申請者のユーザＩＤから、その申請者の所属する部門を判定する（Ｓ１）。この判定は、ネットワーク３０上にある組織情報管理サーバ（図示省略）に問い合せることで行うことができる。すなわち、企業等の組織の部門構成や組織のメンバがどの部門に属するかなどの情報をサーバで管理することは従来より行われているので、承認プロセス管理部４０はそのようなサーバに対して申請者のユーザＩＤを送り、その申請者の属する部門ＩＤを問い合わせればよい。このようにして申請者の所属部門の部門ＩＤ"Ｓ０１"が分かると、承認プロセス管理部４０は、承認権限者表４２（図８参照）を参照して、その部門の承認権限者のユーザＩＤ"Ｐ０１"を求める（Ｓ２）。このように承認権限者が分かると、承認プロセス管理部４０は、組織情報管理サーバからその承認権限者の電子メールアドレス等の連絡先情報を取得する。また、承認プロセス管理部４０は、ステップＳ１，Ｓ２の処理と並行して、一意な副本ＩＤ"b"（図１１の例では"b" = "B564370987"）を生成し、その副本ＩＤを含んだ承認依頼用副本ｓｃ２０６を生成する（Ｓ３）。この承認依頼用副本ｓｃ２０６には、承認依頼である旨を示す属性が組み込まれる。そして、承認プロセス管理部４０は、ステップＳ２で求めた連絡先情報を用いて、承認権限者Ｐ０１に対して承認依頼用副本ｓｃ２０６を送付する（Ｓ４）。この送付は、例えば、承認依頼のメッセージを含み、副本ｓｃ２０６を添付ファイルとして含んだ電子メールを送るなどにより行うことができる。また承認プロセス管理部４０は、承認依頼２０６に含まれる副本ＩＤ"b"に対応する文書ＩＤ"Ｄ０１"をログ管理部１９のログデータ（この場合は図１１の２行目）から特定し、文書ＩＤ"Ｄ０１"を「未承認」状態として承認状態表４４に登録する（Ｓ５）。このとき、その文書Ｄ０１の所属する部門ＩＤ"Ｓ０１"の情報も承認状態表に登録する。
【００５１】
また、この承認依頼イベントでは、副本ＩＤ"a" = "B012345678"を含んだ要求に対し、ユーザＰ０１に対して副本ＩＤ"ｂ"="B564370987"を含む副本ｓｃ２０６を提供したので、ログ管理部１９はログレコードとして、図１１の３行目のようなレコードを記録する。なお、この３行目のログレコードに対し、承認申請２０４の発行者であるユーザのＩＤ"Ｐ０１"も合わせて記録するようにすれば、誰からの要求に対し誰に対し副本ＩＤを提供したのかを、後で追跡できる。
【００５２】
ユーザＰ０１が、クライアント端末２０−Ｐ０１にて、受け取った承認依頼用副本ｓｃ２０６を開くと、ビューワ２２はその副本ｓｃ２０６が承認依頼の属性を持つことを認識し、承認用の閲覧要求２０８を生成し、文書管理サーバ１０ａに送る。承認用閲覧要求２０８には、副本ｓｃ２０６に含まれていた副本ＩＤ"b"とユーザＩＤ"Ｐ０１"が含まれ、その要求２０８が承認のためであることを示す情報が含まれる。
【００５３】
承認用閲覧要求２０８を受け取った文書管理サーバ１０ａでは、承認プロセス管理部４０がその要求２０８に含まれる副本ＩＤ"b"に対応する文書ＩＤ"Ｄ０１"をログレコードから特定し、その文書ＩＤが示す電子文書を正本文書ＤＢ１１から求めてそのコピーを作成する。そして、そのコピーのファイルに対し、新たに生成した副本ＩＤ"ｃ"(= "B345654321"と、承認操作用の副本である旨を示す情報とを属性として設定することで副本ファイル２１０を生成し、それをクライアント端末２０−Ｐ０１に返す。このとき、ログ管理部１９は、図１１のテーブルの８行目（下から３行目）のようなログレコードを記録する。
【００５４】
副本ファイル２１０を受け取ったクライアント端末２０−Ｐ０１では、ビューワ２２がそのファイル２１０を開く。承認権限者Ｐ０１は、副本ファイル２１０に含まれる電子文書"Ｄ０１"のコピーをビューワ２２により閲覧し、この文書に承認を与えるかどうかを判断する。ここで、副本ファイル２１０には承認操作用の副本である旨の属性が設定されているので、ビューワ２２は、その属性を認識し、承認をするか否かを問い合わせるダイアログ画面を生成し表示する。このダイアログは、例えば、ユーザＰ０１がその副本ファイル２１０を閉じる操作をしたことをトリガとして表示すればよい。ただし、ダイアログはそのタイミングに限らず、文書を表示している間に表示してもよい。
【００５５】
なおビューワ２２は、その副本ファイル２１０をファイルシステムやローカルのハードディスク等に保存することはしない（例えば、その副本ファイル２１０については、ユーザが保存操作を選択できないようにするなど）。また、ビューワ２２は、副本ファイル２１０に含まれる副本ＩＤ"ｃ"により、要求２０８の際に用いたファイルシステム内の副本ｓｃ内の副本ＩＤを、副本ファイル２１０に含まれる副本ＩＤ"ｃ"に書き換える。
【００５６】
承認権限者Ｐ０１が、そのダイアログに対して承認の操作を行った場合、ビューワ２２は承認の旨を示すコードと副本ＩＤ"ｃ"とを含む承認情報２１２を文書管理サーバ１０ａに送る。なお、承認権限者Ｐ０１が承認しない旨を選択した場合は、承認しない旨のコードと副本ＩＤ"ｃ"とを含む承認不可情報（図示省略）を文書管理サーバ１０ａに送る。
【００５７】
文書管理サーバ１０ａの承認プロセス管理部４０は、クライアント端末２０から承認情報２１２又は承認不可情報を受け取った場合、それに含まれる副本ＩＤ"ｃ"に対応する正本の文書ＩＤ"Ｄ０１"をログ管理部１９から検索し、承認状態表４４における文書ＩＤ"Ｄ０１"の状態を、承認情報２１２の場合は「承認済み」に、承認情報の場合は「承認不可」に、それぞれ更新する。また、副本ｓｃ提供部１５は、更新用の副本ＩＤ"ｄ"(= "B787878787)を生成し、これを含んだ副本ｓｃ２１４を生成してクライアント端末２０−Ｐ０１に返す。ここでログ管理部１９は、図１１のテーブルの９行目（下から２行目）のようなログレコードを生成して記録する。
【００５８】
クライアント端末２０−Ｐ０１は、承認指示に用いた副本ｓｃ内の副本ＩＤを、受け取った副本ｓｃ２１４それに含まれる副本ＩＤ"ｄ"に更新する。
【００５９】
以上のような流れにより、文書管理サーバ１０ａに登録された電子文書"Ｄ０１"に対して適切な承認権限者Ｐ０１からの承認がなされる。なお、以上では、電子文書"Ｄ０１"に対する承認の流れを例にとって説明したが、文書管理サーバ１０ａは、複数の文書の承認プロセスを並行して管理することができ、図１１のテーブルにはそれら複数の文書についてのログレコードが示されている。
【００６０】
なお、以上の例では、承認権限者Ｐ０１は、ユーザＰ０３が承認を申請した電子文書"Ｄ０１"に対して承認を行うだけであったが、承認権限者Ｐ０１がその電子文書"Ｄ０１"に修正を加えた上で承認を行えるようにすることもできる。すなわち、この場合、クライアント端末２０−Ｐ０１のビューワ２２は、副本ファイル２１０に含まれる電子文書"Ｄ０１"の文書データを表示すると共に、承認権限者Ｐ０１からのその文書データへの編集操作を受け付ける。そして、承認権限者Ｐ０１がその文書に対する承認操作をビューワ２２に対して行うと、ビューワ２２は、副本ファイル２１０に含まれる副本ＩＤ"ｃ"と、編集後の文書データとを含んだファイル（例えばＰＤＦ形式）とユーザＩＤＰ０１とを含んだ承認情報２１２を文書管理サーバ１０ａに送る。文書管理サーバ１０ａは、承認プロセス管理部４０により上述と同様の承認のための処理を行うと共に、正本文書ＤＢ１１に登録された当該文書"Ｄ０１"の実体データを、その承認情報２１２に含まれる編集後の文書データに置き換える。ここで、置き換え前の文書データを旧バージョンとして保存してもよい。以上のような仕組みによれば承認対象の文書に対して修正を加えた上で承認を行うことができる。
【００６１】
以上、実施形態を説明した。本実施形態では、承認権限者が承認を行うには、承認依頼イベントで生成された副本ＩＤを含む副本ｓｃ２０６を取得して用いる必要がある。承認依頼のための副本ｓｃ２０６は、承認プロセス管理部４０が、承認権限者表に登録された適切な登録者に対して送信するので、第三者が承認依頼用副本ｓｃ２０６を取得することは困難である。したがって、本実施形態では、第三者が不正に承認を行うリスクが少ない。
【００６２】
また、本実施形態では、承認プロセス管理部４０が承認依頼を送った宛先の承認権限者がログレコードに記録されている。したがって、文書管理サーバ１０ａは、ユーザから承認用閲覧要求２０８を受けた段階で、その要求に含まれる副本ＩＤを「提供した副本ＩＤ」の値として持つ承認依頼イベントのログレコードにおける「宛先ユーザ」の値から正当な承認権限者を知ることができる。したがって、承認プロセス管理部４０は、承認用閲覧要求２０８をユーザから受け取った際に、ログレコードから正当な承認権限者（すなわち承認依頼の宛先ユーザ）を求め、要求２０８を送ってきたユーザのユーザＩＤと比較することで、そのユーザが正当な承認権限者か否かをチェックすることができる。これにより、仮に第三者が承認依頼用の副本ｓｃを取得し、これを用いて承認を行おうとしても、文書管理サーバ１０ａは、その第三者から承認用閲覧要求２０８を受けた段階で、その第三者の端末から送られてくるユーザＩＤがその正当な承認権限者と異なることを認識することができるので、承認対象の電子文書の写し（副本ファイル）をその第三者に提供することすらない。またこの場合、第三者は承認用副本ファイル２１０を受け取ることができないので、承認を行うこともできない。また、万が一第三者が承認用副本ファイル２１０を何らかの手段で取得して承認情報２１２を送信したとしても、承認プロセス管理部４０は、同時に送られてくるユーザＩＤが正当な承認権限者のものでないことをログレコードから判別することができるので、その承認操作を受け付けないようにすることができる。
【００６３】
また本実施形態、承認依頼の副本ｓｃ２０６を用いてユーザが承認用閲覧要求２０８を行った場合、そのユーザのユーザＩＤがその副本ｓｃ２０６の副本ＩＤと共に文書管理サーバ１０ａに送られ、ログ管理部１９に記録される。したがって、仮に正当な承認権限者でない第三者からの要求に対して文書管理サーバ１０ａが承認用副本ファイル２１０を提供したり、承認操作を受け付けたりする場合でも、それらのイベントのログがその第三者のユーザＩＤと共にログ管理部１９に残るので、第三者がそのような操作を行ったことを後でログデータから割り出すことができる。
【００６４】
このように、本実施形態によれば、承認の正当性を従来より厳密にチェックすることができる。
【００６５】
なお、本実施形態において、承認プロセス管理部４０が、電子文書の承認を申請したユーザ（図１０の例ではユーザＰ０３）に対し、その電子文書の承認プロセスの進行状況の情報を提供するようにすることもできる。この場合、例えば、承認申請者が文書登録の際に受け取った副本ｓｃ２０２（図１０参照）を開けると、ビューワ２２が副本ｓｃ２０２に含まれる副本ＩＤ"ａ"とユーザＩＤ"Ｐ０３"を文書管理サーバ１０ａに送信する。文書管理サーバ１０ａは、ログ管理部１９からその副本ＩＤ"ａ"に対応する正本の文書ＩＤ"Ｄ０１"を検索し、承認状態表４４からその文書ＩＤ"Ｄ０１"に対応する承認状態を求め、その承認状態の情報をクライアント端末２０−Ｐ０３に返す。これによりユーザＰ０３は、自分が承認申請した文書の承認状態を知ることができる。
【００６６】
ここで、文書管理サーバ１０ａは、承認状態表４４を検索するだけでなく、ログ管理部１９からその文書ＩＤ"Ｄ０１"を持つログレコードを検索し、検索したログレコードに含まれるイベントから、当該文書Ｄ０１のより詳細な状態を求めることもできる。すなわち、ログレコードのイベント情報から、承認権限者Ｐ０１について「文書取得」イベントが記録されていなければ、承認権限者が当該文書を未読であると判断でき、「文書取得」イベントは記録されているが「承認」イベントが記録されていなければ、承認権限者は当該文書を既読であるが未承認であると判断できる。また、「承認」イベントが記録されていれば、承認済みであると判断できる。このように、ログ管理部１９のログデータを参照することで、承認状態表４４に示されない未読／既読の判別を行うこともできる。文書管理サーバ１０ａは、このように判別した承認状態（未読／既読だが未承認／承認済み／承認不可）をクライアント端末２０−Ｐ０３に返す。
【００６７】
また、承認プロセスの進行状況の情報提供を、副本ｓｃを用いて行ってもよい。この場合、例えば、ユーザＰ０３から承認申請２０４を受けた際に、文書管理サーバ１０ａは、承認権限者Ｐ０１に承認依頼のための副本ｓｃ２０６を送るのと並行して、依頼元のユーザＰ０３に対し新たな副本ＩＤ"ｘ"を含んだ承認プロセス確認用の副本ｓｃ２０５を送る。ログ管理部１９はこのイベントをログに記録する。クライアント端末２０−Ｐ０３は、承認依頼に用いられた副本ｓｃ２０２をこの副本ｓｃ２０５に置き換える。そして、ユーザＰ０３がその副本ｓｃ２０５を開くと、ビューワ２２は副本ＩＤ"ｘ"を含んだ承認プロセス確認要求を文書管理サーバ１０ａに送る。すると、承認プロセス管理部４０は、その副本ＩＤ"ｘ"を「提供した副本ＩＤ」として持つログレコードから、要求元のユーザＰ０３が承認依頼を行ったことが分かるので、承認状態を調べてそのユーザＰ０３に回答する。すなわち、承認プロセス管理部４０は、その副本ＩＤに対応する正本の文書ＩＤをログから特定し、その文書ＩＤに対応する承認状態を承認状態表４４（及びログ管理部１９内のログデータ）から求め、その承認状態の情報を含んだ副本ｓｃ（新たに生成した更新用の副本ＩＤも含む）を生成してクライアント端末２０−Ｐ０３に返す。これにより、ユーザＰ０３は、自分が承認を申請した文書の状態を知ることができる。また、ユーザＰ０３は、このとき受け取った副本ｓｃを用いることで、承認状態を再度確認することもでき、この際にも同様に承認状態の情報を含んだ新たな副本ｓｃがクライアント端末２０−Ｐ０３に提供され、既存の副本ｓｃと置き換えられる。
【００６８】
なお、以上の各例では、文書管理サーバ１０ａがログ管理部１９の情報から詳細な承認状態を判別してユーザに提供したが、この代わりに、クライアント端末のビューワ２２がその判別を行ってもよい。この場合、文書管理サーバ１０ａは、ログ管理部１９から検索した文書ＩＤ"Ｄ０１"についてのイベントの情報をクライアント端末２０−Ｐ０３のビューワ２２へと送る。ビューワ２２には、イベントの情報から詳細な承認状態を判別するためのルール情報を有しており、承認状態の問合せに応じて文書管理サーバ１０ａから受け取ったイベントの情報から、そのルール情報を用いて、詳細な承認状態を求めて表示する。
【００６９】
また、文書管理サーバ１０ａが承認状態の情報（或いはログ管理部１９から求めたイベントの情報）を承認申請者Ｐ０３のクライアント端末２０−Ｐ０３に送る際に、当該電子文書の正本のコピーも併せて送ってもよい。この場合、文書管理サーバ１０ａは、例えば、正本のコピーである副本ファイルに対して、承認状態（又はイベント情報）を属性として設定したものをクライアント端末２０−Ｐ０３に提供すればよい。このようにすることで、承認申請者は、自分が登録した電子文書が、どのように修正されて（或いは修正されずに）承認されたかを知ることができる。
【００７０】
以上の実施形態において、文書管理サーバ１０ａは、承認依頼の副本ｓｃ２０６又は承認操作用の副本ファイル２１０を用いて行われた要求を受けたときに、ユーザ認証を行って、その要求を送ってきたものが正当な承認権限者であるかを判定してもよい。ユーザ認証には、例えば、承認権限者にユーザＩＤとパスワード等の認証情報との入力を求めるなどの方法で行えばよい。
【００７１】
次に、課長、部長、本部長のように、組織の階層構造に従って複数段階の承認を要する場合に上記実施形態を適用した例を説明する。この例のシステム構成、及びシステムを構成する装置構成は、上記実施形態のものと同様でよい。ただし、承認権限者表４２には、図１３に示すように、部門ごとに、第１，第２，第３というように、各段階の承認権限者のユーザＩＤが順番に列挙される。
【００７２】
この例では、各段階の承認権限者ごとに上記実施形態と同様の承認処理の流れを実行すればよい。具体的には以下のような処理の流れとなる。以下の説明では、適宜図１０を参照する。すなわち、承認プロセス管理部４０は、承認申請者から電子文書"Ｄ０１"の承認申請を受け取った場合、まずその電子文書の第１承認権限者を承認権限者表４２から求め、その第１承認権限者に対して承認依頼の副本ｓｃを送る（第１承認依頼イベント）。このイベントの後、第１承認権限者がその副本ｓｃを用いて承認用の副本ファイル２１０を文書管理サーバ１０ａから取得し、その副本ファイル２１０を用いて承認操作を行う。このようにして第１承認権限者から承認情報２１２を文書管理サーバ１０ａに送ると、承認プロセス管理部４０は、電子文書"Ｄ０１"の状態を「第１承認済み」とする。ここで、第１承認権限者が、電子文書"Ｄ０１"を修正した上で承認を行った場合は、文書管理サーバ１０ａは、正本文書ＤＢ１１内のその電子文書"Ｄ０１"のデータを修正後のものに置き換える。そして、承認プロセス管理部４０は、承認権限者表４２から第２承認権限者を求め、第２承認権限者に対して承認依頼用の副本ｓｃを送信する（第２承認依頼イベント）。第２承認権限者は、その副本ｓｃを用いて、第１承認権限者の場合の同様にして承認を行うことができる。そして、第２承認権限者から承認の旨の情報を受け取ると、承認プロセス管理部４０は、電子文書"Ｄ０１"の状態を「第２承認済み」へと変更する。以下、第３以降の承認権限者についても同様の処理を繰り返す。このような処理により、複数段階の承認を要する承認プロセスの管理が可能となる。この処理の流れにおいて、ログ管理部１９に記録されるログデータの例を図１４に示す。この例では、部門Ｓ００１に所属するユーザＰ００６が承認を申請した電子文書"Ｄ００１"に対して行われた承認プロセスを記録したものである。
【００７３】
この例でも、承認申請者は、上記実施形態と同様、自分の持つ副本ｓｃを用いることで、申請した文書の承認状態を確認することができる。
【００７４】
このように複数段階の承認に対応した例によれば、文書管理サーバ１０ａは、各段階の承認依頼イベントと各段階の承認権限者による承認操作のためのイベントとをログ管理部１９で記録しているので、各段階の正しい承認権限者により承認が行われたかをログデータから確認することができる。また、承認依頼用の副本ｓｃの送信先のユーザ（すなわち正しい承認権限者）以外の者がその副本ｓｃや、この副本ｓｃを用いて得られる副本ファイルを入手して承認操作を行おうとした場合、文書管理サーバ１０ａは、正しい承認権限者でない者からの操作と判断して、その操作を認めないようにすることができる。このように複数段階の承認を要する承認プロセスに対しても、上記実施形態の方式は適用可能である。
【００７５】
次に、文書閲覧許可のプロセスを管理するための実施形態について説明する。従来、文書データベースに保存された電子文書の閲覧管理は、電子文書のファイルやフォルダに対するアクセス管理で行われることが一般的であった。この方式では、ファイルやフォルダに対してアクセス権のあるユーザやグループを予めアクセスコントロールリストに登録しておき、ユーザから電子文書に対する閲覧要求があった場合、アクセスコントロールリストからそのユーザがそのファイルに対するアクセス権があるか否かをチェックしていた。このような従来システムでは、ユーザがアクセス権のない電子文書を閲覧しようとする場合、書面で閲覧申請を行うなどの煩瑣な作業が必要であった。本実施形態では、アクセスコントロールリスト上ではアクセス権が認められない文書の閲覧を管理するために、副本ＩＤを用いた文書管理システムを利用する。
【００７６】
この実施形態の全体的なシステム構成は図１に示したものと同様である。ただし、この実施形態では、図１５に示すように、文書管理サーバ１０ｂが承認プロセス管理部４０の代わりに、閲覧プロセス管理部５０を備える。閲覧プロセス管理部５０は、ユーザからの閲覧要求を処理する機能モジュールである。閲覧プロセス管理部５０は、図１６に示すように、文書開示許可表５２、開示許可権限者表５４、及び個別閲覧許可表５６を有する。
【００７７】
文書開示許可表５２は、正本文書ＤＢ１１に登録された各電子文書に対する閲覧アクセスの管理のためのテーブルである。図１７に示すように、文書開示許可表５２には、電子文書の各々について、文書ＩＤ、アクセス分類、部門ＩＤ、個別閲覧許可数という項目が登録される。アクセス分類は、文書ＩＤによって特定される電子文書のアクセス制限上の分類を示す。「公開」は、本システムに登録された全ユーザに公開される文書であることを示し、「部外秘」は、当該文書の属する部門以外には開示を認めない文書であることを示す。部門ＩＤは、当該電子文書の属する部門の識別情報である。これらアクセス分類と部門ＩＤは、従来型の一括的なアクセスコントロールのために用いる。個別閲覧許可数は、各電子文書の開示許可権限者が、それぞれの電子文書について申請者に個別的に与えた閲覧許可の数である。
【００７８】
開示許可権限者表５４には、正本文書ＤＢ１１内の電子文書ごとに、その電子文書についての個別的な閲覧許可を与える権限を持つユーザのユーザＩＤが登録されている。開示許可権限者表５４は、図８の承認権限者表と同様のものでよいので、図示は省略する。
【００７９】
個別閲覧許可表５６には、図１８に示すように、開示許可権限者から個別に閲覧許可が与えられたユーザ（閲覧許可対象ユーザ）のユーザＩＤと、閲覧許可の対象である電子文書の文書ＩＤとが登録されている。
【００８０】
ユーザが副本ｓｃを用いて文書管理サーバ１０ｂに閲覧要求を行った場合、閲覧プロセス管理部５０は、図１９に示すような処理を実行する。すなわち、閲覧プロセス管理部５０は、ネットワーク上にある組織情報管理サーバ（図示省略）などを参照することで、その閲覧要求に伴うユーザＩＤから要求元ユーザの所属部門を求める。また、閲覧要求に含まれる副本ＩＤに対応する正本の文書ＩＤをログデータに基づき特定し、文書開示許可表５２におけるその文書ＩＤのエントリを求める。そして、閲覧プロセス管理部５０は、そのエントリにおけるアクセス分類及び部門ＩＤと、要求元ユーザの所属部門とから、そのユーザがその電子文書に対するアクセス権を持つか否かを判定する（Ｓ１１）。アクセス権ありと判定した場合、閲覧プロセス管理部５０は、その文書ＩＤに対応する電子文書の副本ファイルを作成し、要求元のユーザに提供する（Ｓ１２）。
【００８１】
一方、アクセス権なしと判定した場合、閲覧プロセス管理部５０は、文書開示許可表５２にて、その文書ＩＤのエントリ中の個別閲覧許可数が０より大きいか否かを調べ（Ｓ１３）、０より大きければ（すなわち１以上）、更に個別閲覧許可表５６における当該文書ＩＤのエントリに、要求元ユーザのユーザＩＤが登録されているかどうかを調べる（Ｓ１４）。ステップＳ１４で、要求元ユーザのＩＤが登録されていれば、閲覧プロセス管理部５０は、要求された文書の副本ファイルを作成し、要求元に提供する（Ｓ１２）。
【００８２】
ステップＳ１３で個別閲覧許可数が０以下と判定された場合、又は、個別閲覧許可数が０より大きくても要求元ユーザが個別閲覧許可表５６に登録されていないと判定された場合、要求元ユーザはその文書に対するアクセス権を持たないと判断できる。この場合、閲覧プロセス管理部５０は、閲覧申請を行うか否かの問合せを要求元ユーザのクライアント端末に送る（Ｓ１５）。この問合せには、開示許可権限者表５４から求められた当該文書の開示許可権限者の名前が含まれる。この問合せは、例えば図１６に示す副本ｓｃ３００としてクライアント端末に提供してもよい。
【００８３】
この閲覧申請要否問合せの送信の後の処理の流れを、図１６を用いて説明する。図６では、ユーザＰ２が電子文書の閲覧を申請した者であり、ユーザＰ０がその電子文書に対する開示許可権限者であるとする。
【００８４】
クライアント端末２０−Ｐ２のビューワ２２は、文書管理サーバ１０ｂから受け取った副本ｓｃ３００（副本ＩＤ = a（図２１の例ではB789に対応））の属性を調べることで、それが閲覧申請要否の問合せであることを認識し、図２０に示すようなダイアログ画面４００を表示する。このダイアログ画面４００には、申請対象の文書名４０２，開示許可権限者の名前４０４が表示されると共に、閲覧目的の入力欄４０６が示される。ユーザＰ２は、閲覧申請を行う場合、入力欄４０６に目的を入力した上で、申請実行ボタン４０８をクリックすればよい。これに応じ、ビューワ２２は、副本ｓｃ３００に含まれた副本ＩＤ"ａ"を含んだ閲覧申請データ３０２を作成し、文書管理サーバ１０ｂに送る。これを受け取った文書管理サーバ１０ｂは、更新用の副本ＩＤ"ｂ"を生成し、これを含んだ副本ｓｃ３０４をクライアント端末２０−Ｐ２に返す。このとき、ログ管理部１９は、図２１のテーブルの上から２行目のような閲覧申請イベントのレコードを記録する。また、閲覧プロセス管理部５０は、副本ＩＤ"ｃ"を生成し、これと閲覧申請通知である旨の情報とを属性として含んだ副本ｓｃ３０６を生成し、これを開示許可権限者Ｐ０に送る。ログ管理部１９は、図２１のテーブルの３行目のような申請発信イベントのレコードを記録する。
【００８５】
ユーザＰ０がクライアント端末２０−Ｐ０のビューワ２２でこの副本ｓｃ３０６を開くと、ビューワ２２は副本ＩＤ"ｃ"を含んだ申請開封通知３０８を文書管理サーバ１０ｂに送る。この通知３０８に応じ、閲覧プロセス管理部５０は、閲覧申請対象の電子文書のコピーと、新たな副本ＩＤ"ｄ"と、閲覧申請者の情報とを含んだ副本ファイル３１０をクライアント端末２０−Ｐ０に返す。ログ管理部１０は、図２１のテーブルの４行目のような申請開封イベントのレコードを記録する。
【００８６】
副本ファイル３１０を受け取ったクライアント端末２０−Ｐ０のビューワ２２は、副本ファイル３１０に含まれる文書データを表示すると共に、図２２に示すようなダイアログ画面４１０を表示する。この画面４１０には、閲覧申請対象の文書名４１２、閲覧申請者の名前４１４が表示され、閲覧許可ボタン４１６、閲覧不可ボタン４１８及び保留ボタン４１９が示される。開示許可権限者Ｐ０は、閲覧を許可する場合にはボタン４１６を、閲覧を認めない場合はボタン４１８を、判断を保留する場合にはボタン４１９をクリックする。ボタン４１６がクリックされた場合、ビューワ２２は、副本ｓｃ３１０に含まれていた副本ＩＤ"ｄ"を含んだ閲覧許可通知３１２を作成し、文書管理サーバ１０ｂに送る。ボタン４１８が押下された場合は、副本ＩＤ"ｄ"を含んだ閲覧不許可通知を生成し、文書管理サーバ１０ｂに送る。またボタン４１９が押下された場合は、ビューワ２２は単にその副本ファイルを閉じる。
【００８７】
文書管理サーバ１０ｂは、閲覧許可通知３１２を受け取った場合、更新用の副本ＩＤを生成してクライアント端末２０−Ｐ０に返す（図示省略）。ログ管理部１９は、図２１のテーブルの５行目のような閲覧許可イベントのレコードを記録する。そして、閲覧プロセス管理部５０は、文書開示許可表５２における対象文書の個別閲覧許可数に１を加え、対象文書の文書ＩＤと閲覧申請者のユーザＩＤとのペアを個別閲覧許可表５６に追加する。そして、文書管理サーバ１０ｂは、新たな副本ＩＤ"ｅ"を生成し、これを含んだ閲覧許可用の副本ｓｃ３１４を生成し、例えば電子メールなどでクライアント端末２０−Ｐ２に送る。ログ管理部１９は、図２１のテーブルの最下行のような許可返信イベントのレコードを記録する。
【００８８】
ユーザＰ２が、この副本ｓｃ３１４を用いて閲覧要求３１６を発した場合、個別閲覧許可数は０より大きく、ユーザＰ２は対象文書の閲覧を許可されたものとして個別閲覧許可表５６に登録されているので、ユーザＰ２はその対象文書のコピー含んだ副本ファイルを得ることができる。
【００８９】
なお、文書管理サーバ１０ｂは、閲覧不許可通知を受け取った場合、閲覧申請者に対しては何も行わなくてもよいし、その旨を閲覧申請者に通知してもよい。
【００９０】
この実施形態において、文書管理サーバ１０ｂは、正当な開示許可権限者以外のユーザから申請開封通知３０８や閲覧許可通知３１２、閲覧不許可通知を受け取った場合、正当なもの以外からの通知であることをログデータから判別することができるので、そのような通知元に対してはサービスを提供しないようにすることができる。
【００９１】
以上に説明した文書閲覧許可を得るための実施形態でも、上述の文書承認の実施形態と同様の仕組みを用いているので、同様に、閲覧許可の正当性を従来よりも厳密にチェックすることができる。
【００９２】
以上の例では、個人ユーザを対象とする閲覧許可の場合を例示したが、グループに対する個別閲覧許可を設定することも可能である。例えば、閲覧申請の際にユーザが、本人のみについての申請なのか本人の属するグループについての申請なのかを指定できるようにし、その指定に応じてグループＩＤを個別閲覧許可表５６の閲覧許可対象ユーザＩＤとして登録するようにすればよい。
【００９３】
また、ユーザが、既存のグループでは括れない複数の人に対して電子文書を開示するために、開示許可権限者に閲覧許可を求める場合もありうる。このような場合に対応するために、申請者に対して電子文書の一次頒布を許可することが考えられる。このように一次頒布を許可するための変形例を以下に説明する。変形例のシステム構成は、閲覧許可の実施形態と同様でよい。
【００９４】
この例では、図２３に示すように、閲覧申請要否の問合せのためのダイアログ画面４００ａに、その閲覧申請が一次頒布を含むのか含まないのかを示すための入力部（図ではチェックボックス４２２及び４２４）が含まれる。その他の表示事項は図２０のダイアログ画面４００と同様でよい。また、個別閲覧許可表５６には、図２４に示すように、許可の種類という欄が設けられる。許可の種類には、「閲覧」と「頒布」とがある。「頒布」は一次頒布のことである。一次頒布の許可を受けた者は、自分が文書管理サーバ１０ｂに対して版部先として指定したユーザに対して電子文書の閲覧を許可できる。
【００９５】
申請者がダイアログ画面４００ａで一次頒布を含む閲覧を申請した場合、文書管理サーバ１０ｂは、副本ｓｃのシステムを用いて、開示許可権限者に対してその申請者に一次頒布を認めるか否かを問い合わせる。そして、開示許可権限者が一次頒布を許可する回答を行った場合、閲覧プロセス管理部５０は、個別閲覧許可表５６に、対象文書の頒布を閲覧申請者に許可した旨を示すレコードを登録する。そして、文書管理サーバ１０ｂは、閲覧申請者、すなわち一次頒布権者に対して副本ｓｃを提供する。
【００９６】
ユーザから副本ＩＤを提示した閲覧要求を受けた場合、文書管理サーバ１０ｂは、その副本ＩＤに対応する正本の文書ＩＤを特定し、個別閲覧許可表５６を参照して、そのユーザのその正本に対する閲覧許可の種類を調べる。その種類が頒布であった場合、文書管理サーバ１０ｂは、その正本のコピーを含み、一次頒布許可のフラグが属性にセットされた副本ファイルを作成し、そのユーザに提供する。ビューワ２２は、副本ファイルを開く際、一次頒布許可の属性を検知すると、図２５に示すような一次頒布先指定画面４５０を表示する。この画面４５０には、一次頒布先を検索するための検索欄４６０が設けられる。検索欄４６０には、ユーザの名前で検索条件を入力するための条件入力部４６２と、ユーザの所属部門で検索条件を入力するための条件入力部４６４が含まれる。入力欄４６２ａ、４６４ａには、例えば、一以上のキーワードからなる論理式を入力することができる。ビューワ２２は、入力欄４６２ａ又は４６４ａに入力された検索条件を満足するユーザを組織情報管理サーバから検索し、検索結果を結果表示欄４６６に表示する。一次頒布権者は、結果表示欄４６６に示された各ユーザの中から一次頒布先とするものを選択ボタン４６８により選択する。選択されたユーザは一次頒布先リスト４７０に列挙される。一次頒布者は、このリスト４７０から削除したいユーザがあれば、それを削除ボタン４７２により削除できる。そして、一次頒布権者が実行ボタンを４７４をクリックすると、ビューワ２２は、一次頒布先ユーザのリストを含んだ頒布要求を文書管理サーバ１０ｂに送る。
【００９７】
文書管理サーバ１０ｂは、そのリストに含まれる各ユーザを対象文書についての閲覧許可対象ユーザ（許可の種別は「許可」）として個別閲覧許可表５６に登録し、それら一次頒布先の各ユーザに対してその対象文書に対応づけられた副本ｓｃを送信する。
【００９８】
一次頒布先のユーザは、受け取った副本ｓｃを用いることで、対象文書を閲覧できる。ただし、一次頒布先のユーザは、個別閲覧許可表５６の設定により「閲覧」のみを認められるだけであり、その副本ｓｃを用いても他のユーザにその文書を頒布することはできない。すなわち、この仕組みによれば、文書の頒布許可を受けたユーザ以外のユーザが、他のユーザに対してその文書の頒布（すなわち閲覧の許可）を行うことはできない。
【００９９】
以上、文書の閲覧についての許可を例にとったが、閲覧以外の各種の操作（例えば編集など）についての許可を権限者に求める場合にも、同様の仕組みを用いることができる。
【０１００】
以上、本発明の実施形態について説明した。例示した実施形態は、いずれも、電子文書に関する承認を与えるプロセスを管理するという点で共通している。すなわち、１つの実施形態は、「文書そのもの」に対して権限者が承認を与えるものであったのに対し、別の実施形態は「文書に対する操作」に対して権限者が承認を与えるものと捉えることができる。
【０１０１】
以上の実施形態では、ログ管理部１９が記録したログデータを調べることで副本ＩＤに対応する正本を特定していたが、正本と副本ＩＤとの対応関係の情報を別途作成しておき、その情報から副本ＩＤに対応する正本を特定してもよい。
【図面の簡単な説明】
【０１０２】
【図１】副本ショートカットを用いた文書管理システムの概略構成を示すブロック図である。
【図２】クライアント端末の内部構成の例を示す図である。
【図３】文書管理サーバの内部構成の例を示す図である。
【図４】ログ管理部が生成するログデータの一例を示す図である。
【図５】図４のログデータが示す副本ＩＤの派生関係のツリーを示す図である。
【図６】図４のログデータが生成される場合のシステムの動作を説明するための図である。
【図７】文書承認システムにおける文書管理サーバの内部構成の例を示す図である。
【図８】承認権限者表の例を示す図である。
【図９】承認状態表の例を示す図である。
【図１０】承認プロセスの例を示す図である。
【図１１】承認プロセスにおいてログ管理部が生成するログデータの一例を示す図である。
【図１２】ユーザから承認依頼を受けた時の承認プロセス管理部の処理手順の例を示す図である。
【図１３】複数段階の承認を要する承認プロセスにおける承認権限者表の例を示す図である。
【図１４】複数段階の承認を要する承認プロセスにおいてログ管理部が生成するログデータの一例を示す図である。
【図１５】文書閲覧管理の実施形態における文書管理サーバの内部構成の例を示す図である。
【図１６】文書閲覧管理の実施形態における、個別閲覧申請のプロセスを説明するための図である。
【図１７】文書開示許可表の例を示す図である。
【図１８】個別閲覧許可表の例を示す図である。
【図１９】文書閲覧要求を受けた時の閲覧プロセス管理部の処理手順の例を示すフローチャートである。
【図２０】閲覧申請要否の問合せ画面の一例を示す図である。
【図２１】文書閲覧管理の実施形態においてログ管理部が記録するログデータの一例を示す図である。
【図２２】閲覧申請を認めるか否かを問い合わせるダイアログ画面の一例を示す図である。
【図２３】一次頒布の要否を含む閲覧申請要否問合せのためのダイアログ画面の一例を示す図である。
【図２４】一次頒布と通常の閲覧とを区別して登録した個別閲覧許可表の例を示す図である。
【図２５】一次頒布先の指定画面の一例を示す図である。
【符号の説明】
【０１０３】
１０ 文書管理サーバ、１１ 正本文書ＤＢ、１３ 正本文書登録部、１５ 副本ｓｃ（ショートカット）提供部、１７ 副本文書提供部、１９ ログ管理部、２０ クライアント端末、２２ ビューワ、２４ ファイルシステム、３０ ネットワーク。
【特許請求の範囲】
【請求項１】
管理している電子文書に対し、ユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行すると共に、その操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録する文書管理サーバと、
電子文書に対する操作要求に応じて文書管理サーバから受け取った操作ＩＤをその電子文書に対応する操作ＩＤとして保存すると共に、保存した操作ＩＤを指定してユーザから操作指示を受けた場合に、その操作ＩＤを含んだ操作要求を文書管理サーバへと送るクライアントと、
を有し、
前記文書管理サーバは、
電子文書に関する承認申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、
を備える、承認管理システム。
【請求項２】
請求項１記載の承認管理システムであって、
前記承認状態管理部は、クライアントから承認結果登録を要求する操作要求を受けた場合、その操作要求を発したユーザが、正当な承認権限者であるか否かを前記ログレコードに基づき判定し、正当な承認権限者である場合にはその操作要求を実行し、そうでない場合はその操作要求を実行しない、ことを特徴とする承認管理システム。
【請求項３】
請求項１記載の承認管理システムであって、
前記文書管理サーバは、
前記電子文書に関する承認申請を行った申請者から、その電子文書に対応付けて提供した操作ＩＤを伴う状態確認のための操作要求を受け取った場合、前記承認状態管理部が管理するその電子文書の承認状態の情報を申請者に提供する状態情報提供部、
を更に備えることを特徴とする承認管理システム。
【請求項４】
請求項１記載の承認管理システムであって、
前記クライアントは、
電子文書に対する操作要求に応じて文書管理サーバから操作ＩＤを受け取ったときに、その操作ＩＤに対応する電子文書に対応した操作ＩＤがそのクライアント内に既に存在する場合には、その既存の操作ＩＤをその受け取った操作ＩＤに置き換える操作ＩＤ管理部、
を更に備える承認管理システム。
【請求項５】
請求項１記載の承認管理システムであって、
前記文書管理サーバは、
前記承認依頼に伴って承認権限者に提供した操作ＩＤを伴う操作要求を承認権限者から受け取った場合に、その操作ＩＤに対応する電子文書のコピーを含んだ副本ファイルを、その操作要求に応じて発行される新たな操作ＩＤと共に、承認権限者に提供する副本提供部、
を備えることを特徴とする承認管理システム。
【請求項６】
請求項５記載の承認管理システムであって、
前記クライアントは、
前記文書管理サーバから受け取った副本ファイルを固定記憶装置に保存しないように制御する副本制御部、
を備えることを特徴とする承認管理システム。
【請求項７】
請求項１記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の承認である、ことを特徴とする承認管理システム。
【請求項８】
請求項１記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の閲覧についての承認である、ことを特徴とする承認管理システム。
【請求項９】
請求項１記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の一次頒布についての承認であり、
前記文書管理サーバは、
電子文書の一次頒布についての承認を得たユーザから、一次頒布先ユーザの指定を受けた場合に、その一次頒布先ユーザを記憶すると共に、その一次頒布先ユーザに対してその電子文書に対応づけられた新たな操作ＩＤを送信し、その一次頒布先ユーザからその操作ＩＤを伴う要求を受けた場合に、その電子文書のコピーを含む副本ファイルを提供する閲覧管理部、
を更に備えることを特徴とする承認管理システム。
【請求項１０】
電子文書が登録される文書データベースと、
文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行する操作ＩＤ発行部と、
ユーザからの操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部と、
電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、
を備える文書管理サーバ。
【請求項１１】
コンピュータを、
電子文書が登録される文書データベースと、
文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行する操作ＩＤ発行部、
ユーザからの操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部、
電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部、
として機能させるためのプログラム。
【請求項１】
管理している電子文書に対し、ユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行すると共に、その操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録する文書管理サーバと、
電子文書に対する操作要求に応じて文書管理サーバから受け取った操作ＩＤをその電子文書に対応する操作ＩＤとして保存すると共に、保存した操作ＩＤを指定してユーザから操作指示を受けた場合に、その操作ＩＤを含んだ操作要求を文書管理サーバへと送るクライアントと、
を有し、
前記文書管理サーバは、
電子文書に関する承認申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、
を備える、承認管理システム。
【請求項２】
請求項１記載の承認管理システムであって、
前記承認状態管理部は、クライアントから承認結果登録を要求する操作要求を受けた場合、その操作要求を発したユーザが、正当な承認権限者であるか否かを前記ログレコードに基づき判定し、正当な承認権限者である場合にはその操作要求を実行し、そうでない場合はその操作要求を実行しない、ことを特徴とする承認管理システム。
【請求項３】
請求項１記載の承認管理システムであって、
前記文書管理サーバは、
前記電子文書に関する承認申請を行った申請者から、その電子文書に対応付けて提供した操作ＩＤを伴う状態確認のための操作要求を受け取った場合、前記承認状態管理部が管理するその電子文書の承認状態の情報を申請者に提供する状態情報提供部、
を更に備えることを特徴とする承認管理システム。
【請求項４】
請求項１記載の承認管理システムであって、
前記クライアントは、
電子文書に対する操作要求に応じて文書管理サーバから操作ＩＤを受け取ったときに、その操作ＩＤに対応する電子文書に対応した操作ＩＤがそのクライアント内に既に存在する場合には、その既存の操作ＩＤをその受け取った操作ＩＤに置き換える操作ＩＤ管理部、
を更に備える承認管理システム。
【請求項５】
請求項１記載の承認管理システムであって、
前記文書管理サーバは、
前記承認依頼に伴って承認権限者に提供した操作ＩＤを伴う操作要求を承認権限者から受け取った場合に、その操作ＩＤに対応する電子文書のコピーを含んだ副本ファイルを、その操作要求に応じて発行される新たな操作ＩＤと共に、承認権限者に提供する副本提供部、
を備えることを特徴とする承認管理システム。
【請求項６】
請求項５記載の承認管理システムであって、
前記クライアントは、
前記文書管理サーバから受け取った副本ファイルを固定記憶装置に保存しないように制御する副本制御部、
を備えることを特徴とする承認管理システム。
【請求項７】
請求項１記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の承認である、ことを特徴とする承認管理システム。
【請求項８】
請求項１記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の閲覧についての承認である、ことを特徴とする承認管理システム。
【請求項９】
請求項１記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の一次頒布についての承認であり、
前記文書管理サーバは、
電子文書の一次頒布についての承認を得たユーザから、一次頒布先ユーザの指定を受けた場合に、その一次頒布先ユーザを記憶すると共に、その一次頒布先ユーザに対してその電子文書に対応づけられた新たな操作ＩＤを送信し、その一次頒布先ユーザからその操作ＩＤを伴う要求を受けた場合に、その電子文書のコピーを含む副本ファイルを提供する閲覧管理部、
を更に備えることを特徴とする承認管理システム。
【請求項１０】
電子文書が登録される文書データベースと、
文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行する操作ＩＤ発行部と、
ユーザからの操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部と、
電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、
を備える文書管理サーバ。
【請求項１１】
コンピュータを、
電子文書が登録される文書データベースと、
文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作ＩＤを発行する操作ＩＤ発行部、
ユーザからの操作要求に伴って受け取った操作ＩＤと、その操作要求に応じた操作に応じて新たに発行された操作ＩＤと、その操作要求を発したユーザ又はその新たに発行された操作ＩＤの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部、
電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作ＩＤを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作ＩＤに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部、
として機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２００７−３０４８３１（Ｐ２００７−３０４８３１Ａ）
【公開日】平成１９年１１月２２日（２００７．１１．２２）
【国際特許分類】
【出願番号】特願２００６−１３２１８３（Ｐ２００６−１３２１８３）
【出願日】平成１８年５月１１日（２００６．５．１１）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
【公開日】平成１９年１１月２２日（２００７．１１．２２）
【国際特許分類】
【出願日】平成１８年５月１１日（２００６．５．１１）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】
[ Back to top ]