JP2007304831A - 承認管理システム - Google Patents
承認管理システム Download PDFInfo
- Publication number
- JP2007304831A JP2007304831A JP2006132183A JP2006132183A JP2007304831A JP 2007304831 A JP2007304831 A JP 2007304831A JP 2006132183 A JP2006132183 A JP 2006132183A JP 2006132183 A JP2006132183 A JP 2006132183A JP 2007304831 A JP2007304831 A JP 2007304831A
- Authority
- JP
- Japan
- Prior art keywords
- approval
- document
- duplicate
- electronic document
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000004044 response Effects 0.000 claims abstract description 29
- 238000013475 authorization Methods 0.000 claims description 4
- 238000012790 confirmation Methods 0.000 claims description 2
- 238000000034 method Methods 0.000 abstract description 72
- 230000008569 process Effects 0.000 abstract description 68
- 238000012545 processing Methods 0.000 description 10
- 230000008520 organization Effects 0.000 description 7
- 230000007246 mechanism Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000009795 derivation Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 235000010724 Wisteria floribunda Nutrition 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
Images
Landscapes
- Document Processing Apparatus (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
Abstract
【課題】文書の承認プロセスにおける承認の正当性チェックの厳密性を向上させる。
【解決手段】文書管理サーバ10aは、クライアント端末20−P03から電子文書200の承認申請204を受けた場合、承認権限者のクライアント端末20−P01に対し、副本ID"b"を含む承認依頼の副本sc(ショートカット)206を送る。承認権限者が副本sc206を開くと、副本ID"b"を含む要求208が発行され、これに応じ文書管理サーバ10aは電子文書200のコピーと新たな副本ID"c"を含む副本ファイル210を返す。承認権限者がその副本ファイル210を閲覧して承認操作を行うと、副本ID"c"を含む承認情報212が文書管理サーバ10aに送られる。文書管理サーバ10aは、これら各操作の際に、その操作の要求に含まれていた副本IDと、その操作の結果発行した新たな副本IDと、ユーザIDとの対応を示すログレコードを記録する。
【選択図】図10
【解決手段】文書管理サーバ10aは、クライアント端末20−P03から電子文書200の承認申請204を受けた場合、承認権限者のクライアント端末20−P01に対し、副本ID"b"を含む承認依頼の副本sc(ショートカット)206を送る。承認権限者が副本sc206を開くと、副本ID"b"を含む要求208が発行され、これに応じ文書管理サーバ10aは電子文書200のコピーと新たな副本ID"c"を含む副本ファイル210を返す。承認権限者がその副本ファイル210を閲覧して承認操作を行うと、副本ID"c"を含む承認情報212が文書管理サーバ10aに送られる。文書管理サーバ10aは、これら各操作の際に、その操作の要求に含まれていた副本IDと、その操作の結果発行した新たな副本IDと、ユーザIDとの対応を示すログレコードを記録する。
【選択図】図10
Description
本発明は、電子文書に対する承認、又は電子文書の閲覧申請に対する承認を、電子的に実行するためのシステムに関する。
オフィス業務では、文書作成者が文書を作成するだけでは、その文書は業務上の正式の文書とはならず、その文書に対して所定の承認者(複数の場合もある)が承認を与えて初めてその文書が正式の文書となることが一般的である。このような承認業務を電子化するシステムとして、特許文献1に示されるシステムが知られている。このシステムでは、電子文書に対する承認操作を行おうとする者がある場合、その者を認証し、この認証によりその者がその電子文書の承認者であると判定された場合、承認許可鍵コードを生成する。そして、承認者がその承認許可鍵コードを正しく入力すると、システムはその電子文書に対して電子押印を行う。
上記従来システムでは、第三者が承認者のユーザID、パスワードを入手し、システムにログインすれば、不正な承認が容易に実行できるという問題がある。
本発明の1つの側面では、文書管理サーバとクライアントとを含む承認管理システムが提供される。文書管理サーバは、管理している電子文書に対し、ユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作IDを発行すると共に、その操作要求に伴って受け取った操作IDと、その操作要求に応じた操作に応じて新たに発行された操作IDと、その操作要求を発したユーザ又はその新たに発行された操作IDの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録する。クライアントは、電子文書に対する操作要求に応じて文書管理サーバから受け取った操作IDをその電子文書に対応する操作IDとして保存すると共に、保存した操作IDを指定してユーザから操作指示を受けた場合に、その操作IDを含んだ操作要求を文書管理サーバへと送る。また文書管理サーバは、電子文書に関する承認申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作IDを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作IDに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部とを備える。
本発明の別の側面では、電子文書が登録される文書データベースと、文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作IDを発行する操作ID発行部と、ユーザからの操作要求に伴って受け取った操作IDと、その操作要求に応じた操作に応じて新たに発行された操作IDと、その操作要求を発したユーザ又はその新たに発行された操作IDの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部と、電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作IDを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作IDに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、を備える文書管理サーバが提供される。
本発明の更に別の側面では、コンピュータを、電子文書が登録される文書データベース、文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作IDを発行する操作ID発行部、ユーザからの操作要求に伴って受け取った操作IDと、その操作要求に応じた操作に応じて新たに発行された操作IDと、その操作要求を発したユーザ又はその新たに発行された操作IDの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部、電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作IDを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部、承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作IDに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部、として機能させるためのプログラム、が提供される。
以下、図面を参照して、本発明の実施の形態(以下「実施形態」と呼ぶ)について説明する。
まず、実施形態のシステムのベースとなる、副本ショートカットを用いた文書管理システムについて説明する。
図1は、この文書管理システムの概略構成を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク30を介して接続された文書管理サーバ10とクライアント端末20−1,20−2,・・・(以下、クライアント端末20と総称する)から構成される。
このシステムでは、電子文書の正本を文書管理サーバ10で管理し、クライアント端末20にはその電子文書を保存しないようにすることで、電子文書のセキュリティを確保する。クライアント端末20には、電子文書そのもののファイルの代わりに、その電子文書にアクセスするための情報を含んだ副本ショートカット(以下「副本sc」と略す)と呼ぶファイルを持たせる。副本scには、例えば、副本IDと呼ぶ管理用の識別情報と、文書管理サーバ10のホスト名又は文書閲覧要求用のURL(Uniform Resource Locator)などのアクセス情報と、副本scの属性とが含まれる。副本scの含む情報の一例を以下に示す。
"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"
この例では、"id=1234567"が副本IDを、"host=foo.fujixerox.co.jp"が文書管理サーバ10のホスト名を、"createDate=2005/05/24 11:12:34"がその副本scの属性の1つである作成日時を示す。副本ショートカットには、漏洩防止等のために、電子文書の実体は含めない。ただし、ユーザがどの電子文書の副本scかを識別できるよう、電子文書の一部例えば1ページ目だけの情報や、電子文書の各ページのサムネイル画像などのように、その電子文書の劣化バージョンを見本として副本scに含めてもよい。
なお、副本scに組み込むアクセス情報は、副本scを利用するクライアント端末20が、その副本scに対応する正本を管理する文書管理サーバ10にアクセスする際に用いられる。ただし、ネットワーク上に、副本IDから対応の正本を管理する文書管理サーバ10のアクセス情報を解決するサーバを設けるならば(そしてこのサーバのアドレスが副本scに含まれるか、或いはビューワ22にとって既知であれば)、副本scに文書管理サーバ10のアクセス情報を含める必要はない。
図2に示すように、クライアント端末20のファイルシステム24には、他のアプリケーションのファイルとともに、副本sc26のファイルも保存される。副本sc26は、例えばアドビ社が開発したPDF(Portable Document Format)や富士ゼロックス株式会社が開発したDocuworks文書などのように、文書の実体データに加え、属性情報を保持できる形式のファイルとして作成する。この場合、副本sc26のファイルには副本IDやアクセス情報等が属性情報として組み込まれる。ユーザは、文書管理サーバ10上にある電子文書に対して閲覧その他の操作を行いたい場合、通常のショートカットファイルと同様の感覚で、その電子文書に対応する副本sc26をファイルシステム24や検索ソフトが提供するファイル一覧画面の選択し、操作を行う。すると、その副本sc26のファイル形式に関連づけられたビューワ22が起動し、そのビューワ22がその副本sc26内のアクセス情報及び副本IDを用いて文書管理サーバ10にアクセスして、その副本IDに対応する電子文書のコピーである副本文書のファイルを取得する。ビューワ22は、その副本ファイルを表示したり、ユーザの操作に応じてその副本ファイルに編集等の操作を加えたりする。ここで、副本ファイルには、そのファイルが副本であることを示す情報(例えば後述する更新用副本ID)が含まれており、ビューワ22は、その情報からそのファイルが副本であることを認識する。ビューワ22は、副本ファイルはファイルシステム24には保存しない。副本ファイルは、クライアント端末20においてビューワ22が管理するメモリ領域の上で開かれるのみであり、ファイルシステム24には保存されない。ビューワ22としては例えばPDF形式に対応したアドビ社のAcrobat(登録商標)などを用いることができる。ここで、このシステム特有の副本scの取扱機能(その一部は既に説明したが、あとでも更に説明する)は、例えばプラグインの形でAcrobat等の既存ビューワに追加することができる。
このシステムでは、ユーザがクライアント端末20上の副本scを利用して文書管理サーバ10上の電子文書の正本に対して操作を行うたびに、文書管理サーバ10が更新用の副本IDを発行し、そのクライアント端末20上の副本sc内の副本IDを更新する。このようにすることで、このシステムでは、副本scを用いて電子文書に操作が行われるたびに、その副本sc内の副本IDが更新されるようにしている。例えば、あるユーザXが副本scを用いて電子文書の副本ファイルを文書管理サーバ10に要求し、副本ファイルを得て閲覧した場合、そのユーザXのクライアント端末20にあるその副本sc内の副本IDの値は、その閲覧の前後では変わってくる。したがって、そのユーザXが副本scのコピーを電子メール等に添付して他のユーザYに送った場合を考えると、閲覧の前に送ったのと閲覧のあとで送ったのとでは、ユーザYが受け取る副本scの副本IDが異なる。副本scを用いてユーザが電子文書の操作を要求する場合、その副本scに含まれる副本IDがクライアント端末20から文書管理サーバ10に送られるので、文書管理サーバ10は、その要求の元になった副本scがどの操作の段階に対応するものか(例えばユーザXが閲覧する前のものか閲覧したあとのものか)を、受け取った副本IDから識別することができる。また、副本IDを、その対象となる電子文書の正本の識別情報(「文書ID」と呼ぶ)及びその副本IDの発行の契機となった操作を行ったユーザのユーザID(或いはその副本IDの発行先のユーザID)と対応づけて文書管理サーバ10側で記録しておけば、その副本IDからどの文書に対するどのユーザの操作かを割り出すこともでき、電子文書の流通の様子を詳細に追跡することができる。
副本IDは、いわばユーザが電子文書に対して行った個々の操作に対応する、システム内で一意な識別情報である。副本IDとしては、例えば操作ごとにインクリメントされる通し番号を用いてもよいが、第三者の推測による攻撃を困難にするという観点からすれば、例えば十分に長い乱数値などのように、高い一意性を確保しつつも推測が困難な生成規則を用いて生成された値を用いることが好適である。また、副本IDの生成日時のように、副本ID発行の都度変化する属性情報のハッシュ値(十分に長い桁数のもの)や、そのような変化する属性情報に例えばその副本IDに対応する正本の識別情報などといった固定的な属性情報を組み合わせたもの(或いはこれに更に乱数値を組み合わせてもよい)のハッシュ値を、副本IDとして利用することもできる。
文書管理サーバ10は、図3に示すように、正本文書DB11,正本文書登録部13,副本sc提供部15,副本文書提供部17及びログ管理部19を備える。
正本文書DB11は、クライアント端末20からアップロードされた電子文書を、正本(原本)として保存し、管理するデータベースである。本システムの枠組みでは、正本文書DB11に保存された電子文書のみが正本として取り扱われる。この枠組みでは、仮にその電子文書のコピーがネットワーク上に存在しても、それは正本とは関係がないものとして扱うことができる。特に、上述のようにクライアント端末20のビューワ22が、副本文書のファイルをファイルシステム等に保存しないようにしておけば、正本の写しがネットワーク上に出回る可能性を大幅に低減できる。
正本文書登録部13は、クライアント端末20から正本として登録すべくアップロードされた電子文書を、正本文書DB11に登録する。このとき、正本文書登録部13は、登録する正本の電子文書ファイルに対し、「文書ID」と呼ぶ一意な識別情報を付与する。文書IDとしては、例えば十分に長い乱数値やその電子文書の十分に長いハッシュ値などを用いることができる。
副本sc提供部15は、ユーザからの操作要求に応じ、正本文書DB11内の電子文書に対する副本scをそのユーザに対して発行する。副本文書提供部17は、ユーザからの操作要求に応じ、要求対象の電子文書の副本ファイルを作成し、そのユーザへと提供する。
ログ管理部19は、クライアント端末20を介したユーザからの操作要求に応じて文書管理サーバ10が処理を行った場合に、その操作に関する情報をイベントログとして記録する。ログ管理部19には、図4に示すように、個々の操作イベントごとに、その操作の対象となる正本電子文書の文書ID、その操作イベントにおいて副本IDを提供したユーザ(この場合、その操作のために文書管理サーバ10にアクセスしてきたユーザと同じ)のユーザID(宛先ユーザID)、そのイベントの種別、そのイベントの発生日時、そのイベントにおいてその宛先ユーザに提供した副本ID、及びそのイベントの契機となる要求に含まれていた副本ID(「旧副本ID」)を、ログレコードとして記録する。このログレコードによれば、副本IDとそれに対応する正本の文書IDが対応づけられる。またこのログレコードを調べれば、副本IDに対し、文書の操作のためにこの旧副本IDを用いたアクセスに対して文書管理サーバ10が提供した新たな副本IDが対応づけられるので、操作による副本IDの変遷を把握することができる。このような副本IDの変遷は、旧副本IDから操作により新たな副本IDが派生するという関係である。副本IDの一意性から、異なる複数の旧副本IDから同じ副本IDが派生することはないので、この派生関係はツリー状となる。図4に例示したログデータが示す副本IDの派生関係を図5に示す。
文書管理サーバ10は、例えばウェブサーバとウェブアプリケーションを用いて構築することができる。この場合、文書管理サーバ10は、ユーザインタフェース画面としてウェブページをクライアント端末20に提供する。
次に、この文書管理システムの仕組みを具体的に示すために、図4に例示したログデータが形成された時のシステムの動作を、図6を参照して説明する。
まず、ユーザP01がクライアント端末20−P01から文書管理サーバ10に対し、電子文書"O"100の登録要求を行う。電子文書100は、クライアント端末20−P01のローカルのファイルシステム内にあるものでも、ネットワーク上のファイルサーバや文書サーバにあるものでもよい。この登録要求は、例えばビューワ22が提供するユーザインタフェースを介して行う。このユーザインタフェースは、例えばファイルシステムやネットワークファイルシステムのツリー状のディレクトリを表示するディレクトリ画面を提供し、このディレクトリ画面上でユーザP01から登録対象の電子文書の選択を受け付ける。また、ユーザインタフェースが検索画面を提供し、その検索画面に対しユーザが入力した検索条件に合致する電子文書をローカルのファイルシステム及び/又はネットワーク上のファイルサーバから検索してその検索結果をユーザに提示し、その中からユーザに登録対象の文書を選択させてもよい。クライアント端末20が発する登録要求には、ユーザP01を特定するユーザIDと、対象となる電子文書100(実体データ又はその実体データに対するリンク情報)が含まれる。ここで登録要求に含めるユーザIDとしては、クライアント端末20−P01又は本システムに対してユーザP01がログインした際に提示したユーザIDを用いることができる。
登録要求を受けた文書管理サーバ10では、正本文書登録部13が、その要求に含まれる電子文書100の実体データを取得し(要求に実体データへのリンクが含まれる場合は、そのリンクを用いて実体データを取得し)、その電子文書に一意な文書ID"D01"を付与して、その電子文書100の実体データを文書ID"D01"と対応づけて正本文書DB11に登録する。ここで、クライアント端末20から送られてきた電子文書100が、このシステムの文書フォーマット(例えばPDF)でない場合は、文書管理サーバ10がその電子文書100をシステムの文書フォーマットに変換してから正本文書DB11に登録してもよい。
次に副本sc提供部15が、一意な副本ID"a"を生成し、その副本ID"a"及びその文書管理サーバ10のホスト名などを含んだ副本sc102を生成し、この副本sc102を、例えば登録要求に対する応答に含める形で、クライアント端末20−P01に送信する。また、文書管理サーバ10では、ログ管理部19が、以上の登録イベントについてのログレコードとして、図4に示したテーブルの2行目のレコードを記録する。このレコードでは、操作イベントの対象となる正本電子文書の文書IDは"D01"であり、その操作イベントにおいて生成した新たな副本IDの宛先ユーザのIDは"P01"である。また、操作イベントの種類は"文書登録"であり、そのイベントの日時は"2006/03/03/10:00:00"である。また、そのイベントの結果として宛先ユーザに提供した副本IDは"a"であり、旧副本IDは、このケースではその操作の要求に副本IDは含まれないので"NULL"(なし)である。
登録成功の応答と共に副本sc104を受けとったクライアント端末20−P01は、その副本sc104をファイルシステム24−P01に登録する。このとき、ファイルシステム24−P01内の元の電子文書100を削除し、この代わりに副本sc104のファイルを保存するようにしても良い。このようにすれば、電子文書100の正本の実体データは文書管理サーバ10にしか存在しないことになり、その正本の原本性が保証しやすくなる。
なお、ユーザがネットワーク上のファイルサーバにある電子文書100の登録を文書管理サーバ10に要求した場合、文書管理サーバ10は、副本sc102をそのファイルサーバへと送る。これを受けたファイルサーバは、自分が保持する電子文書100を削除し、その代わりに副本sc102を保管するようにしてもよい。この場合、ユーザP01は、ネットワークファイルシステムのディレクトリ画面などで、そのファイルサーバ上にある副本sc102を見ることができる。
ここで、ユーザP01が、電子文書"O"100の副本sc102を電子メールに添付するなどの方法でユーザP03に送信したとする。すると、ユーザP03のクライアント端末20−P03のファイルシステム24−P03には、電子文書"O"を指し示すショートカットとして副本sc102が保存される。ユーザP03が電子文書"O"を閲覧するために、ビューワ22で副本sc102をオープンし、閲覧の指示を入力すると、ビューワ22がその副本sc102から副本ID"a"と文書管理サーバ10のホスト名を取り出し、そのホスト名を用いて文書管理サーバ10にアクセスし、副本ID"a"を伴った閲覧要求104を送信する。この閲覧要求104には、ユーザP03のユーザIDが含まれる。以降の各段階でも、ユーザが文書管理サーバ10に要求その他のデータを送信する場合には、その要求にそのユーザのIDが含まれるか、あるいはその送信の以前にユーザが文書管理サーバ10にログインしているなどにより、文書管理サーバ10はどのユーザからのアクセスなのかを把握することができる。
閲覧要求104を受け取った文書管理サーバ10では、副本文書提供部17が起動する。副本文書提供部17は、その閲覧要求104に伴う副本ID"a"を、例えば「提供した副本ID」の値として持つレコードをログ管理部19から求め、そのレコードの文書ID"D01"が示す電子文書"O"の実体データを正本文書DB11から求め、そのコピーを作成する。そして、副本文書提供部17は、更新用の副本ID"b"を生成し、これをそのコピーのファイルの副本ID属性にセットすることで副本ファイル106を生成し、この副本ファイル106を、閲覧要求104に対する応答としてクライアント端末20−P03に返す。
またログ管理部19は、図4のテーブルの3行目のようなログレコードを作成して記録する。閲覧要求104には副本ID"a"が含まれ、それに応じて提供した副本ファイル106には副本ID"b"が含まれるので、このログレコードでは「旧副本ID」が"a"となり、「提供した副本ID」が"b"となる。また、ログレコードには、対象となる文書IDとして"D01"が、宛先ユーザIDとして"P03"が、イベントとして"副本提供"が記録される。
クライアント端末20−P03のビューワ22は、送られてきた副本ファイル106中の文書の実体データを開いて表示する。ここで、その副本ファイル106には保存不可の属性が付されているので、ビューワ22はその副本ファイル106をファイルシステム24−P03には保存しない。例えばビューワ22は、その副本ファイル106の保存が選択できないようにしたユーザインタフェース画面を提供する。またビューワ22は、ファイルシステム24−P03中に保存された副本sc102の中の副本ID"a"を、その副本ファイル106に含まれる更新用の副本ID"b"に書き換えることで、電子文書"O"を指すショートカットを更新する。これにより、ファイルシステム24−P03中の副本sc102が、副本ID"b"を含んだ副本sc108に置き換えられる。
ユーザP03電子文書"O"の副本scを他のユーザに送信する場合を考えると、その送信が副本106の閲覧の前であれば副本ID"a"の副本sc102が送信されるが、副本閲覧の後ならば副本ID"b"の副本sc108が送信されることになる。
次に、ユーザP04が文書管理サーバ10で管理された電子文書を取得する場合を考える。この場合、ユーザP04は、クライアント端末20−P04から文書管理サーバ10に対し、ディレクトリ画面又は検索画面を要求する。文書管理サーバ10は、正本文書DB11内に登録された電子文書群を選択するためのそれらディレクトリ画面又は選択画面を生成し、それをクライアント端末20−P04に返す。ユーザP04がそれらの画面を介して所望の電子文書"O"を見つけ、その取得を指示すると、クライアント端末20は、その電子文書"O"の識別情報(例えば文書ID"D01")を伴う取得要求112を文書管理サーバ10に送る。これを受け取った文書管理サーバ10では、副本sc提供部15が新たな副本ID"c"を生成し、これを含んだ副本sc114を作成してクライアント端末20−P04に返す。そして、ログ管理部19が、このショートカット提供のイベントについてのレコード(図4に示したテーブルの4行目)を作成して記録する。
クライアント端末20−P04は、受け取った副本sc114をファイルシステム24−P04に保存する。ユーザがこの副本sc114を選んで閲覧を指示すると、ビューワ22は副本ID"c"を伴った閲覧要求116を発行する。これに応じ文書管理サーバ10は、その副本ID"c"に対応する正本のコピーを作成するとともに、更新用の副本ID"d"を生成してそのコピーのファイルの属性にセットすることで副本ファイル118を生成し、クライアント端末20−P04に返す。また、ログ管理部19は、図4のテーブルの5行目に示すようなログレコードを記録する。
クライアント端末20−P04のビューワ22は、その副本ファイル118を開いて表示すると共に、ファイルシステム24−P04内の副本sc114の副本IDを副本ファイル118に含まれる更新用の副本ID"d"へと変更する。これにより、クライアント端末20−P04が持つ電子文書"O"へのショートカットは副本sc120となる。
ユーザP04が電子文書"O"の副本閲覧後に副本sc120をユーザP08に送信し、ユーザP08がその副本sc120を用いて閲覧要求122を行うと、文書管理サーバ10は更新用の副本ID"e"を含む副本ファイル124をクライアント端末20−P08に提供し、図4のテーブルの6行目に示すログレコードを記録する。クライアント端末20−P08のビューワ22は、受け取った副本ファイル124を開いてユーザに提供し、ファイルシステム24−P08内の副本scの副本IDを、その更新用の副本ID"e"へと変更する。
図4に例示したログデータには、操作イベントにおける副本IDの提供先のユーザIDを記録したが、これに加え、そのイベントの契機となった要求を発したユーザIDを合わせて記録してもよい。以上の例では、イベントの契機となる要求を発したユーザと、そのイベントにおいて新たに生成した副本IDの提供先とは同一であるが、それらが異なる場合には、上述のように両者のユーザIDを記録することが好適である。
以上、実施形態のベースとなる文書管理システムの構成と処理内容について説明した。このシステムの特徴をまとめると以下のようになる。
・電子文書の正本が文書管理サーバに登録される。
・ユーザに対しては、電子文書の実体データの代わりに副本scが提供される。副本scには、副本IDが含まれる。なお、副本scを用いて文書管理サーバ10上の正本に関する何らかの操作を行う場合、正本を管理する文書管理サーバ10を特定する必要がある。このために、副本scには、対応する正本を管理する文書管理サーバ10を特定する情報を含めてもよい。
・文書管理サーバは、提供した副本scの副本IDと、それに対応する正本との対応関係を管理する。(上述の例では、副本ID−正本対応関係をログ管理部19のログレコードに含める形で管理したが、対応関係のデータは、両者の対応が分かればどのようなデータ形式であってもよい。)
・文書管理サーバ上の文書に対して何らかの操作を行う際には、操作を行う端末が持つ副本scの副本IDがそのサーバに送られる。
・文書管理サーバは、端末から受け取った副本IDに対応する正本を副本ID−正本対応関係に基づき特定し、正本に関して、要求された操作を行う。
・文書管理サーバは、正本に関する操作を行った場合、新たな副本IDを生成し、この副本IDを操作を要求したクライアント端末に送る。これを受け取ったクライアント端末は、要求に用いた副本scの副本IDを、受け取った新たな副本IDへと更新する。
・文書管理サーバは、クライアント端末からの要求に含まれていた副本IDと、その要求に係る操作を行ったことにより生成した新たな副本IDとの対応関係である、副本ID派生関係を管理する。
・文書管理サーバは、クライアント端末から電子文書の閲覧など、電子文書の実体データを必要とする操作を指示された場合、正本のコピーである副本文書データを提供する。副本文書データは、クライアント端末上で動作するビューワの管理するメモリ上の領域にのみ存在し、ディスク上には保存できない設定となっている。
・ユーザに対しては、電子文書の実体データの代わりに副本scが提供される。副本scには、副本IDが含まれる。なお、副本scを用いて文書管理サーバ10上の正本に関する何らかの操作を行う場合、正本を管理する文書管理サーバ10を特定する必要がある。このために、副本scには、対応する正本を管理する文書管理サーバ10を特定する情報を含めてもよい。
・文書管理サーバは、提供した副本scの副本IDと、それに対応する正本との対応関係を管理する。(上述の例では、副本ID−正本対応関係をログ管理部19のログレコードに含める形で管理したが、対応関係のデータは、両者の対応が分かればどのようなデータ形式であってもよい。)
・文書管理サーバ上の文書に対して何らかの操作を行う際には、操作を行う端末が持つ副本scの副本IDがそのサーバに送られる。
・文書管理サーバは、端末から受け取った副本IDに対応する正本を副本ID−正本対応関係に基づき特定し、正本に関して、要求された操作を行う。
・文書管理サーバは、正本に関する操作を行った場合、新たな副本IDを生成し、この副本IDを操作を要求したクライアント端末に送る。これを受け取ったクライアント端末は、要求に用いた副本scの副本IDを、受け取った新たな副本IDへと更新する。
・文書管理サーバは、クライアント端末からの要求に含まれていた副本IDと、その要求に係る操作を行ったことにより生成した新たな副本IDとの対応関係である、副本ID派生関係を管理する。
・文書管理サーバは、クライアント端末から電子文書の閲覧など、電子文書の実体データを必要とする操作を指示された場合、正本のコピーである副本文書データを提供する。副本文書データは、クライアント端末上で動作するビューワの管理するメモリ上の領域にのみ存在し、ディスク上には保存できない設定となっている。
上述の文書管理システムの例では、文書の登録や、副本scの取得、文書閲覧などといった操作を例示したが、これに限らず、正本の文書に関連する操作のうち、システムとして把握しておきたい操作の全てを、上記特徴的な処理の対象とすることができる。
次に、以上の文書管理システムをベースとした文書承認システムの実施形態を説明する。この文書承認システムは、あるユーザが作成した文書に対し、承認権限者が承認を行う場合の一連の流れを支援する。
この文書承認システムは、全体的には、図1に示したように、ネットワーク30を介して接続された文書管理サーバ10とクライアント端末20からなる。本実施形態の文書管理サーバ10aは、図3に示した文書管理サーバ10が持つ各モジュールに加え、承認プロセス管理部30を備えている(図7参照)。
承認プロセス管理部30は、文書管理サーバ10に登録された電子文書(正本)に対する承認プロセスを管理する。承認プロセス管理部30は、図8に例示するような承認権限者表と、図9に例示するような承認状態表とを管理している。
承認権限者表は、図8に示すように、このシステムが適用される組織の部門の識別情報(「部門ID」)と、その部門に所属する人が作成した電子文書に対して承認を与える権限を持つ承認権限者のユーザID(「承認権限者ID」)との対応関係を保持する。例えば、図8の承認権限者表によれば、部門S01のメンバが作成した文書は、ユーザP01から承認を受ける必要があることがわかる。一方、承認状態表は、正本文書DB11に登録された電子文書の承認プロセスにおける状態(例えば、未承認であるか、承認済であるかなど。「承認状態」と呼ぶ)を管理するためのテーブルである。図9の例では、承認状態表には、登録された文書の文書IDに対応づけて、その文書の所属する部門の部門IDと、その文書の承認状態とが登録される。承認状態表には、文書管理サーバ10に登録された全ての文書を登録するようにしてもよいし、登録された文書のうち承認申請を受けたもののみを登録するようにしてもよい。以下では、後者の場合を例にとって説明する。
以下図10を参照して、この文書承認システムにおける承認プロセスの例を説明する。
ユーザP03がクライアント端末20−P03上で作成した電子文書"O"について承認を求める場合を例にとる。この例は、図11に示したログデータに対応している。
この例は、ユーザP03は、作成した電子文書"O"200の登録要求を文書管理サーバ10aに対して送る。これを受けて文書管理サーバ10aは、その電子文書200に一意な文書ID"D01"を付与して正本文書DB11に登録するとともに、一意な副本ID"a"(図11の例では"a" = "B012345678")を生成し、その副本ID"a"を含んだ副本sc202をクライアント端末20−P03に返す。このとき、ログ管理部19は、図11の2行目のようなログレコードを記録する。
ユーザP03は、クライアント端末20−P03上のビューワ22で副本sc202を開き、ビューワ22の操作メニューから「承認申請」を選択する。すると、ビューワ22は、ユーザP03(承認を申請する申請者)のユーザIDと副本sc202に含まれる副本ID"a"とを含んだ承認申請204を文書管理サーバ10aに送る。
承認申請204を受けた文書管理サーバ10aでは、承認プロセス管理部40が、図12に示す処理を実行する。すなわち、承認プロセス管理部40は、承認申請204に含まれる申請者のユーザIDから、その申請者の所属する部門を判定する(S1)。この判定は、ネットワーク30上にある組織情報管理サーバ(図示省略)に問い合せることで行うことができる。すなわち、企業等の組織の部門構成や組織のメンバがどの部門に属するかなどの情報をサーバで管理することは従来より行われているので、承認プロセス管理部40はそのようなサーバに対して申請者のユーザIDを送り、その申請者の属する部門IDを問い合わせればよい。このようにして申請者の所属部門の部門ID"S01"が分かると、承認プロセス管理部40は、承認権限者表42(図8参照)を参照して、その部門の承認権限者のユーザID"P01"を求める(S2)。このように承認権限者が分かると、承認プロセス管理部40は、組織情報管理サーバからその承認権限者の電子メールアドレス等の連絡先情報を取得する。また、承認プロセス管理部40は、ステップS1,S2の処理と並行して、一意な副本ID"b"(図11の例では"b" = "B564370987")を生成し、その副本IDを含んだ承認依頼用副本sc206を生成する(S3)。この承認依頼用副本sc206には、承認依頼である旨を示す属性が組み込まれる。そして、承認プロセス管理部40は、ステップS2で求めた連絡先情報を用いて、承認権限者P01に対して承認依頼用副本sc206を送付する(S4)。この送付は、例えば、承認依頼のメッセージを含み、副本sc206を添付ファイルとして含んだ電子メールを送るなどにより行うことができる。また承認プロセス管理部40は、承認依頼206に含まれる副本ID"b"に対応する文書ID"D01"をログ管理部19のログデータ(この場合は図11の2行目)から特定し、文書ID"D01"を「未承認」状態として承認状態表44に登録する(S5)。このとき、その文書D01の所属する部門ID"S01"の情報も承認状態表に登録する。
また、この承認依頼イベントでは、副本ID"a" = "B012345678"を含んだ要求に対し、ユーザP01に対して副本ID"b"="B564370987"を含む副本sc206を提供したので、ログ管理部19はログレコードとして、図11の3行目のようなレコードを記録する。なお、この3行目のログレコードに対し、承認申請204の発行者であるユーザのID"P01"も合わせて記録するようにすれば、誰からの要求に対し誰に対し副本IDを提供したのかを、後で追跡できる。
ユーザP01が、クライアント端末20−P01にて、受け取った承認依頼用副本sc206を開くと、ビューワ22はその副本sc206が承認依頼の属性を持つことを認識し、承認用の閲覧要求208を生成し、文書管理サーバ10aに送る。承認用閲覧要求208には、副本sc206に含まれていた副本ID"b"とユーザID"P01"が含まれ、その要求208が承認のためであることを示す情報が含まれる。
承認用閲覧要求208を受け取った文書管理サーバ10aでは、承認プロセス管理部40がその要求208に含まれる副本ID"b"に対応する文書ID"D01"をログレコードから特定し、その文書IDが示す電子文書を正本文書DB11から求めてそのコピーを作成する。そして、そのコピーのファイルに対し、新たに生成した副本ID"c"(= "B345654321"と、承認操作用の副本である旨を示す情報とを属性として設定することで副本ファイル210を生成し、それをクライアント端末20−P01に返す。このとき、ログ管理部19は、図11のテーブルの8行目(下から3行目)のようなログレコードを記録する。
副本ファイル210を受け取ったクライアント端末20−P01では、ビューワ22がそのファイル210を開く。承認権限者P01は、副本ファイル210に含まれる電子文書"D01"のコピーをビューワ22により閲覧し、この文書に承認を与えるかどうかを判断する。ここで、副本ファイル210には承認操作用の副本である旨の属性が設定されているので、ビューワ22は、その属性を認識し、承認をするか否かを問い合わせるダイアログ画面を生成し表示する。このダイアログは、例えば、ユーザP01がその副本ファイル210を閉じる操作をしたことをトリガとして表示すればよい。ただし、ダイアログはそのタイミングに限らず、文書を表示している間に表示してもよい。
なおビューワ22は、その副本ファイル210をファイルシステムやローカルのハードディスク等に保存することはしない(例えば、その副本ファイル210については、ユーザが保存操作を選択できないようにするなど)。また、ビューワ22は、副本ファイル210に含まれる副本ID"c"により、要求208の際に用いたファイルシステム内の副本sc内の副本IDを、副本ファイル210に含まれる副本ID"c"に書き換える。
承認権限者P01が、そのダイアログに対して承認の操作を行った場合、ビューワ22は承認の旨を示すコードと副本ID"c"とを含む承認情報212を文書管理サーバ10aに送る。なお、承認権限者P01が承認しない旨を選択した場合は、承認しない旨のコードと副本ID"c"とを含む承認不可情報(図示省略)を文書管理サーバ10aに送る。
文書管理サーバ10aの承認プロセス管理部40は、クライアント端末20から承認情報212又は承認不可情報を受け取った場合、それに含まれる副本ID"c"に対応する正本の文書ID"D01"をログ管理部19から検索し、承認状態表44における文書ID"D01"の状態を、承認情報212の場合は「承認済み」に、承認情報の場合は「承認不可」に、それぞれ更新する。また、副本sc提供部15は、更新用の副本ID"d"(= "B787878787)を生成し、これを含んだ副本sc214を生成してクライアント端末20−P01に返す。ここでログ管理部19は、図11のテーブルの9行目(下から2行目)のようなログレコードを生成して記録する。
クライアント端末20−P01は、承認指示に用いた副本sc内の副本IDを、受け取った副本sc214それに含まれる副本ID"d"に更新する。
以上のような流れにより、文書管理サーバ10aに登録された電子文書"D01"に対して適切な承認権限者P01からの承認がなされる。なお、以上では、電子文書"D01"に対する承認の流れを例にとって説明したが、文書管理サーバ10aは、複数の文書の承認プロセスを並行して管理することができ、図11のテーブルにはそれら複数の文書についてのログレコードが示されている。
なお、以上の例では、承認権限者P01は、ユーザP03が承認を申請した電子文書"D01"に対して承認を行うだけであったが、承認権限者P01がその電子文書"D01"に修正を加えた上で承認を行えるようにすることもできる。すなわち、この場合、クライアント端末20−P01のビューワ22は、副本ファイル210に含まれる電子文書"D01"の文書データを表示すると共に、承認権限者P01からのその文書データへの編集操作を受け付ける。そして、承認権限者P01がその文書に対する承認操作をビューワ22に対して行うと、ビューワ22は、副本ファイル210に含まれる副本ID"c"と、編集後の文書データとを含んだファイル(例えばPDF形式)とユーザIDP01とを含んだ承認情報212を文書管理サーバ10aに送る。文書管理サーバ10aは、承認プロセス管理部40により上述と同様の承認のための処理を行うと共に、正本文書DB11に登録された当該文書"D01"の実体データを、その承認情報212に含まれる編集後の文書データに置き換える。ここで、置き換え前の文書データを旧バージョンとして保存してもよい。以上のような仕組みによれば承認対象の文書に対して修正を加えた上で承認を行うことができる。
以上、実施形態を説明した。本実施形態では、承認権限者が承認を行うには、承認依頼イベントで生成された副本IDを含む副本sc206を取得して用いる必要がある。承認依頼のための副本sc206は、承認プロセス管理部40が、承認権限者表に登録された適切な登録者に対して送信するので、第三者が承認依頼用副本sc206を取得することは困難である。したがって、本実施形態では、第三者が不正に承認を行うリスクが少ない。
また、本実施形態では、承認プロセス管理部40が承認依頼を送った宛先の承認権限者がログレコードに記録されている。したがって、文書管理サーバ10aは、ユーザから承認用閲覧要求208を受けた段階で、その要求に含まれる副本IDを「提供した副本ID」の値として持つ承認依頼イベントのログレコードにおける「宛先ユーザ」の値から正当な承認権限者を知ることができる。したがって、承認プロセス管理部40は、承認用閲覧要求208をユーザから受け取った際に、ログレコードから正当な承認権限者(すなわち承認依頼の宛先ユーザ)を求め、要求208を送ってきたユーザのユーザIDと比較することで、そのユーザが正当な承認権限者か否かをチェックすることができる。これにより、仮に第三者が承認依頼用の副本scを取得し、これを用いて承認を行おうとしても、文書管理サーバ10aは、その第三者から承認用閲覧要求208を受けた段階で、その第三者の端末から送られてくるユーザIDがその正当な承認権限者と異なることを認識することができるので、承認対象の電子文書の写し(副本ファイル)をその第三者に提供することすらない。またこの場合、第三者は承認用副本ファイル210を受け取ることができないので、承認を行うこともできない。また、万が一第三者が承認用副本ファイル210を何らかの手段で取得して承認情報212を送信したとしても、承認プロセス管理部40は、同時に送られてくるユーザIDが正当な承認権限者のものでないことをログレコードから判別することができるので、その承認操作を受け付けないようにすることができる。
また本実施形態、承認依頼の副本sc206を用いてユーザが承認用閲覧要求208を行った場合、そのユーザのユーザIDがその副本sc206の副本IDと共に文書管理サーバ10aに送られ、ログ管理部19に記録される。したがって、仮に正当な承認権限者でない第三者からの要求に対して文書管理サーバ10aが承認用副本ファイル210を提供したり、承認操作を受け付けたりする場合でも、それらのイベントのログがその第三者のユーザIDと共にログ管理部19に残るので、第三者がそのような操作を行ったことを後でログデータから割り出すことができる。
このように、本実施形態によれば、承認の正当性を従来より厳密にチェックすることができる。
なお、本実施形態において、承認プロセス管理部40が、電子文書の承認を申請したユーザ(図10の例ではユーザP03)に対し、その電子文書の承認プロセスの進行状況の情報を提供するようにすることもできる。この場合、例えば、承認申請者が文書登録の際に受け取った副本sc202(図10参照)を開けると、ビューワ22が副本sc202に含まれる副本ID"a"とユーザID"P03"を文書管理サーバ10aに送信する。文書管理サーバ10aは、ログ管理部19からその副本ID"a"に対応する正本の文書ID"D01"を検索し、承認状態表44からその文書ID"D01"に対応する承認状態を求め、その承認状態の情報をクライアント端末20−P03に返す。これによりユーザP03は、自分が承認申請した文書の承認状態を知ることができる。
ここで、文書管理サーバ10aは、承認状態表44を検索するだけでなく、ログ管理部19からその文書ID"D01"を持つログレコードを検索し、検索したログレコードに含まれるイベントから、当該文書D01のより詳細な状態を求めることもできる。すなわち、ログレコードのイベント情報から、承認権限者P01について「文書取得」イベントが記録されていなければ、承認権限者が当該文書を未読であると判断でき、「文書取得」イベントは記録されているが「承認」イベントが記録されていなければ、承認権限者は当該文書を既読であるが未承認であると判断できる。また、「承認」イベントが記録されていれば、承認済みであると判断できる。このように、ログ管理部19のログデータを参照することで、承認状態表44に示されない未読/既読の判別を行うこともできる。文書管理サーバ10aは、このように判別した承認状態(未読/既読だが未承認/承認済み/承認不可)をクライアント端末20−P03に返す。
また、承認プロセスの進行状況の情報提供を、副本scを用いて行ってもよい。この場合、例えば、ユーザP03から承認申請204を受けた際に、文書管理サーバ10aは、承認権限者P01に承認依頼のための副本sc206を送るのと並行して、依頼元のユーザP03に対し新たな副本ID"x"を含んだ承認プロセス確認用の副本sc205を送る。ログ管理部19はこのイベントをログに記録する。クライアント端末20−P03は、承認依頼に用いられた副本sc202をこの副本sc205に置き換える。そして、ユーザP03がその副本sc205を開くと、ビューワ22は副本ID"x"を含んだ承認プロセス確認要求を文書管理サーバ10aに送る。すると、承認プロセス管理部40は、その副本ID"x"を「提供した副本ID」として持つログレコードから、要求元のユーザP03が承認依頼を行ったことが分かるので、承認状態を調べてそのユーザP03に回答する。すなわち、承認プロセス管理部40は、その副本IDに対応する正本の文書IDをログから特定し、その文書IDに対応する承認状態を承認状態表44(及びログ管理部19内のログデータ)から求め、その承認状態の情報を含んだ副本sc(新たに生成した更新用の副本IDも含む)を生成してクライアント端末20−P03に返す。これにより、ユーザP03は、自分が承認を申請した文書の状態を知ることができる。また、ユーザP03は、このとき受け取った副本scを用いることで、承認状態を再度確認することもでき、この際にも同様に承認状態の情報を含んだ新たな副本scがクライアント端末20−P03に提供され、既存の副本scと置き換えられる。
なお、以上の各例では、文書管理サーバ10aがログ管理部19の情報から詳細な承認状態を判別してユーザに提供したが、この代わりに、クライアント端末のビューワ22がその判別を行ってもよい。この場合、文書管理サーバ10aは、ログ管理部19から検索した文書ID"D01"についてのイベントの情報をクライアント端末20−P03のビューワ22へと送る。ビューワ22には、イベントの情報から詳細な承認状態を判別するためのルール情報を有しており、承認状態の問合せに応じて文書管理サーバ10aから受け取ったイベントの情報から、そのルール情報を用いて、詳細な承認状態を求めて表示する。
また、文書管理サーバ10aが承認状態の情報(或いはログ管理部19から求めたイベントの情報)を承認申請者P03のクライアント端末20−P03に送る際に、当該電子文書の正本のコピーも併せて送ってもよい。この場合、文書管理サーバ10aは、例えば、正本のコピーである副本ファイルに対して、承認状態(又はイベント情報)を属性として設定したものをクライアント端末20−P03に提供すればよい。このようにすることで、承認申請者は、自分が登録した電子文書が、どのように修正されて(或いは修正されずに)承認されたかを知ることができる。
以上の実施形態において、文書管理サーバ10aは、承認依頼の副本sc206又は承認操作用の副本ファイル210を用いて行われた要求を受けたときに、ユーザ認証を行って、その要求を送ってきたものが正当な承認権限者であるかを判定してもよい。ユーザ認証には、例えば、承認権限者にユーザIDとパスワード等の認証情報との入力を求めるなどの方法で行えばよい。
次に、課長、部長、本部長のように、組織の階層構造に従って複数段階の承認を要する場合に上記実施形態を適用した例を説明する。この例のシステム構成、及びシステムを構成する装置構成は、上記実施形態のものと同様でよい。ただし、承認権限者表42には、図13に示すように、部門ごとに、第1,第2,第3というように、各段階の承認権限者のユーザIDが順番に列挙される。
この例では、各段階の承認権限者ごとに上記実施形態と同様の承認処理の流れを実行すればよい。具体的には以下のような処理の流れとなる。以下の説明では、適宜図10を参照する。すなわち、承認プロセス管理部40は、承認申請者から電子文書"D01"の承認申請を受け取った場合、まずその電子文書の第1承認権限者を承認権限者表42から求め、その第1承認権限者に対して承認依頼の副本scを送る(第1承認依頼イベント)。このイベントの後、第1承認権限者がその副本scを用いて承認用の副本ファイル210を文書管理サーバ10aから取得し、その副本ファイル210を用いて承認操作を行う。このようにして第1承認権限者から承認情報212を文書管理サーバ10aに送ると、承認プロセス管理部40は、電子文書"D01"の状態を「第1承認済み」とする。ここで、第1承認権限者が、電子文書"D01"を修正した上で承認を行った場合は、文書管理サーバ10aは、正本文書DB11内のその電子文書"D01"のデータを修正後のものに置き換える。そして、承認プロセス管理部40は、承認権限者表42から第2承認権限者を求め、第2承認権限者に対して承認依頼用の副本scを送信する(第2承認依頼イベント)。第2承認権限者は、その副本scを用いて、第1承認権限者の場合の同様にして承認を行うことができる。そして、第2承認権限者から承認の旨の情報を受け取ると、承認プロセス管理部40は、電子文書"D01"の状態を「第2承認済み」へと変更する。以下、第3以降の承認権限者についても同様の処理を繰り返す。このような処理により、複数段階の承認を要する承認プロセスの管理が可能となる。この処理の流れにおいて、ログ管理部19に記録されるログデータの例を図14に示す。この例では、部門S001に所属するユーザP006が承認を申請した電子文書"D001"に対して行われた承認プロセスを記録したものである。
この例でも、承認申請者は、上記実施形態と同様、自分の持つ副本scを用いることで、申請した文書の承認状態を確認することができる。
このように複数段階の承認に対応した例によれば、文書管理サーバ10aは、各段階の承認依頼イベントと各段階の承認権限者による承認操作のためのイベントとをログ管理部19で記録しているので、各段階の正しい承認権限者により承認が行われたかをログデータから確認することができる。また、承認依頼用の副本scの送信先のユーザ(すなわち正しい承認権限者)以外の者がその副本scや、この副本scを用いて得られる副本ファイルを入手して承認操作を行おうとした場合、文書管理サーバ10aは、正しい承認権限者でない者からの操作と判断して、その操作を認めないようにすることができる。このように複数段階の承認を要する承認プロセスに対しても、上記実施形態の方式は適用可能である。
次に、文書閲覧許可のプロセスを管理するための実施形態について説明する。従来、文書データベースに保存された電子文書の閲覧管理は、電子文書のファイルやフォルダに対するアクセス管理で行われることが一般的であった。この方式では、ファイルやフォルダに対してアクセス権のあるユーザやグループを予めアクセスコントロールリストに登録しておき、ユーザから電子文書に対する閲覧要求があった場合、アクセスコントロールリストからそのユーザがそのファイルに対するアクセス権があるか否かをチェックしていた。このような従来システムでは、ユーザがアクセス権のない電子文書を閲覧しようとする場合、書面で閲覧申請を行うなどの煩瑣な作業が必要であった。本実施形態では、アクセスコントロールリスト上ではアクセス権が認められない文書の閲覧を管理するために、副本IDを用いた文書管理システムを利用する。
この実施形態の全体的なシステム構成は図1に示したものと同様である。ただし、この実施形態では、図15に示すように、文書管理サーバ10bが承認プロセス管理部40の代わりに、閲覧プロセス管理部50を備える。閲覧プロセス管理部50は、ユーザからの閲覧要求を処理する機能モジュールである。閲覧プロセス管理部50は、図16に示すように、文書開示許可表52、開示許可権限者表54、及び個別閲覧許可表56を有する。
文書開示許可表52は、正本文書DB11に登録された各電子文書に対する閲覧アクセスの管理のためのテーブルである。図17に示すように、文書開示許可表52には、電子文書の各々について、文書ID、アクセス分類、部門ID、個別閲覧許可数という項目が登録される。アクセス分類は、文書IDによって特定される電子文書のアクセス制限上の分類を示す。「公開」は、本システムに登録された全ユーザに公開される文書であることを示し、「部外秘」は、当該文書の属する部門以外には開示を認めない文書であることを示す。部門IDは、当該電子文書の属する部門の識別情報である。これらアクセス分類と部門IDは、従来型の一括的なアクセスコントロールのために用いる。個別閲覧許可数は、各電子文書の開示許可権限者が、それぞれの電子文書について申請者に個別的に与えた閲覧許可の数である。
開示許可権限者表54には、正本文書DB11内の電子文書ごとに、その電子文書についての個別的な閲覧許可を与える権限を持つユーザのユーザIDが登録されている。開示許可権限者表54は、図8の承認権限者表と同様のものでよいので、図示は省略する。
個別閲覧許可表56には、図18に示すように、開示許可権限者から個別に閲覧許可が与えられたユーザ(閲覧許可対象ユーザ)のユーザIDと、閲覧許可の対象である電子文書の文書IDとが登録されている。
ユーザが副本scを用いて文書管理サーバ10bに閲覧要求を行った場合、閲覧プロセス管理部50は、図19に示すような処理を実行する。すなわち、閲覧プロセス管理部50は、ネットワーク上にある組織情報管理サーバ(図示省略)などを参照することで、その閲覧要求に伴うユーザIDから要求元ユーザの所属部門を求める。また、閲覧要求に含まれる副本IDに対応する正本の文書IDをログデータに基づき特定し、文書開示許可表52におけるその文書IDのエントリを求める。そして、閲覧プロセス管理部50は、そのエントリにおけるアクセス分類及び部門IDと、要求元ユーザの所属部門とから、そのユーザがその電子文書に対するアクセス権を持つか否かを判定する(S11)。アクセス権ありと判定した場合、閲覧プロセス管理部50は、その文書IDに対応する電子文書の副本ファイルを作成し、要求元のユーザに提供する(S12)。
一方、アクセス権なしと判定した場合、閲覧プロセス管理部50は、文書開示許可表52にて、その文書IDのエントリ中の個別閲覧許可数が0より大きいか否かを調べ(S13)、0より大きければ(すなわち1以上)、更に個別閲覧許可表56における当該文書IDのエントリに、要求元ユーザのユーザIDが登録されているかどうかを調べる(S14)。ステップS14で、要求元ユーザのIDが登録されていれば、閲覧プロセス管理部50は、要求された文書の副本ファイルを作成し、要求元に提供する(S12)。
ステップS13で個別閲覧許可数が0以下と判定された場合、又は、個別閲覧許可数が0より大きくても要求元ユーザが個別閲覧許可表56に登録されていないと判定された場合、要求元ユーザはその文書に対するアクセス権を持たないと判断できる。この場合、閲覧プロセス管理部50は、閲覧申請を行うか否かの問合せを要求元ユーザのクライアント端末に送る(S15)。この問合せには、開示許可権限者表54から求められた当該文書の開示許可権限者の名前が含まれる。この問合せは、例えば図16に示す副本sc300としてクライアント端末に提供してもよい。
この閲覧申請要否問合せの送信の後の処理の流れを、図16を用いて説明する。図6では、ユーザP2が電子文書の閲覧を申請した者であり、ユーザP0がその電子文書に対する開示許可権限者であるとする。
クライアント端末20−P2のビューワ22は、文書管理サーバ10bから受け取った副本sc300(副本ID = a(図21の例ではB789に対応))の属性を調べることで、それが閲覧申請要否の問合せであることを認識し、図20に示すようなダイアログ画面400を表示する。このダイアログ画面400には、申請対象の文書名402,開示許可権限者の名前404が表示されると共に、閲覧目的の入力欄406が示される。ユーザP2は、閲覧申請を行う場合、入力欄406に目的を入力した上で、申請実行ボタン408をクリックすればよい。これに応じ、ビューワ22は、副本sc300に含まれた副本ID"a"を含んだ閲覧申請データ302を作成し、文書管理サーバ10bに送る。これを受け取った文書管理サーバ10bは、更新用の副本ID"b"を生成し、これを含んだ副本sc304をクライアント端末20−P2に返す。このとき、ログ管理部19は、図21のテーブルの上から2行目のような閲覧申請イベントのレコードを記録する。また、閲覧プロセス管理部50は、副本ID"c"を生成し、これと閲覧申請通知である旨の情報とを属性として含んだ副本sc306を生成し、これを開示許可権限者P0に送る。ログ管理部19は、図21のテーブルの3行目のような申請発信イベントのレコードを記録する。
ユーザP0がクライアント端末20−P0のビューワ22でこの副本sc306を開くと、ビューワ22は副本ID"c"を含んだ申請開封通知308を文書管理サーバ10bに送る。この通知308に応じ、閲覧プロセス管理部50は、閲覧申請対象の電子文書のコピーと、新たな副本ID"d"と、閲覧申請者の情報とを含んだ副本ファイル310をクライアント端末20−P0に返す。ログ管理部10は、図21のテーブルの4行目のような申請開封イベントのレコードを記録する。
副本ファイル310を受け取ったクライアント端末20−P0のビューワ22は、副本ファイル310に含まれる文書データを表示すると共に、図22に示すようなダイアログ画面410を表示する。この画面410には、閲覧申請対象の文書名412、閲覧申請者の名前414が表示され、閲覧許可ボタン416、閲覧不可ボタン418及び保留ボタン419が示される。開示許可権限者P0は、閲覧を許可する場合にはボタン416を、閲覧を認めない場合はボタン418を、判断を保留する場合にはボタン419をクリックする。ボタン416がクリックされた場合、ビューワ22は、副本sc310に含まれていた副本ID"d"を含んだ閲覧許可通知312を作成し、文書管理サーバ10bに送る。ボタン418が押下された場合は、副本ID"d"を含んだ閲覧不許可通知を生成し、文書管理サーバ10bに送る。またボタン419が押下された場合は、ビューワ22は単にその副本ファイルを閉じる。
文書管理サーバ10bは、閲覧許可通知312を受け取った場合、更新用の副本IDを生成してクライアント端末20−P0に返す(図示省略)。ログ管理部19は、図21のテーブルの5行目のような閲覧許可イベントのレコードを記録する。そして、閲覧プロセス管理部50は、文書開示許可表52における対象文書の個別閲覧許可数に1を加え、対象文書の文書IDと閲覧申請者のユーザIDとのペアを個別閲覧許可表56に追加する。そして、文書管理サーバ10bは、新たな副本ID"e"を生成し、これを含んだ閲覧許可用の副本sc314を生成し、例えば電子メールなどでクライアント端末20−P2に送る。ログ管理部19は、図21のテーブルの最下行のような許可返信イベントのレコードを記録する。
ユーザP2が、この副本sc314を用いて閲覧要求316を発した場合、個別閲覧許可数は0より大きく、ユーザP2は対象文書の閲覧を許可されたものとして個別閲覧許可表56に登録されているので、ユーザP2はその対象文書のコピー含んだ副本ファイルを得ることができる。
なお、文書管理サーバ10bは、閲覧不許可通知を受け取った場合、閲覧申請者に対しては何も行わなくてもよいし、その旨を閲覧申請者に通知してもよい。
この実施形態において、文書管理サーバ10bは、正当な開示許可権限者以外のユーザから申請開封通知308や閲覧許可通知312、閲覧不許可通知を受け取った場合、正当なもの以外からの通知であることをログデータから判別することができるので、そのような通知元に対してはサービスを提供しないようにすることができる。
以上に説明した文書閲覧許可を得るための実施形態でも、上述の文書承認の実施形態と同様の仕組みを用いているので、同様に、閲覧許可の正当性を従来よりも厳密にチェックすることができる。
以上の例では、個人ユーザを対象とする閲覧許可の場合を例示したが、グループに対する個別閲覧許可を設定することも可能である。例えば、閲覧申請の際にユーザが、本人のみについての申請なのか本人の属するグループについての申請なのかを指定できるようにし、その指定に応じてグループIDを個別閲覧許可表56の閲覧許可対象ユーザIDとして登録するようにすればよい。
また、ユーザが、既存のグループでは括れない複数の人に対して電子文書を開示するために、開示許可権限者に閲覧許可を求める場合もありうる。このような場合に対応するために、申請者に対して電子文書の一次頒布を許可することが考えられる。このように一次頒布を許可するための変形例を以下に説明する。変形例のシステム構成は、閲覧許可の実施形態と同様でよい。
この例では、図23に示すように、閲覧申請要否の問合せのためのダイアログ画面400aに、その閲覧申請が一次頒布を含むのか含まないのかを示すための入力部(図ではチェックボックス422及び424)が含まれる。その他の表示事項は図20のダイアログ画面400と同様でよい。また、個別閲覧許可表56には、図24に示すように、許可の種類という欄が設けられる。許可の種類には、「閲覧」と「頒布」とがある。「頒布」は一次頒布のことである。一次頒布の許可を受けた者は、自分が文書管理サーバ10bに対して版部先として指定したユーザに対して電子文書の閲覧を許可できる。
申請者がダイアログ画面400aで一次頒布を含む閲覧を申請した場合、文書管理サーバ10bは、副本scのシステムを用いて、開示許可権限者に対してその申請者に一次頒布を認めるか否かを問い合わせる。そして、開示許可権限者が一次頒布を許可する回答を行った場合、閲覧プロセス管理部50は、個別閲覧許可表56に、対象文書の頒布を閲覧申請者に許可した旨を示すレコードを登録する。そして、文書管理サーバ10bは、閲覧申請者、すなわち一次頒布権者に対して副本scを提供する。
ユーザから副本IDを提示した閲覧要求を受けた場合、文書管理サーバ10bは、その副本IDに対応する正本の文書IDを特定し、個別閲覧許可表56を参照して、そのユーザのその正本に対する閲覧許可の種類を調べる。その種類が頒布であった場合、文書管理サーバ10bは、その正本のコピーを含み、一次頒布許可のフラグが属性にセットされた副本ファイルを作成し、そのユーザに提供する。ビューワ22は、副本ファイルを開く際、一次頒布許可の属性を検知すると、図25に示すような一次頒布先指定画面450を表示する。この画面450には、一次頒布先を検索するための検索欄460が設けられる。検索欄460には、ユーザの名前で検索条件を入力するための条件入力部462と、ユーザの所属部門で検索条件を入力するための条件入力部464が含まれる。入力欄462a、464aには、例えば、一以上のキーワードからなる論理式を入力することができる。ビューワ22は、入力欄462a又は464aに入力された検索条件を満足するユーザを組織情報管理サーバから検索し、検索結果を結果表示欄466に表示する。一次頒布権者は、結果表示欄466に示された各ユーザの中から一次頒布先とするものを選択ボタン468により選択する。選択されたユーザは一次頒布先リスト470に列挙される。一次頒布者は、このリスト470から削除したいユーザがあれば、それを削除ボタン472により削除できる。そして、一次頒布権者が実行ボタンを474をクリックすると、ビューワ22は、一次頒布先ユーザのリストを含んだ頒布要求を文書管理サーバ10bに送る。
文書管理サーバ10bは、そのリストに含まれる各ユーザを対象文書についての閲覧許可対象ユーザ(許可の種別は「許可」)として個別閲覧許可表56に登録し、それら一次頒布先の各ユーザに対してその対象文書に対応づけられた副本scを送信する。
一次頒布先のユーザは、受け取った副本scを用いることで、対象文書を閲覧できる。ただし、一次頒布先のユーザは、個別閲覧許可表56の設定により「閲覧」のみを認められるだけであり、その副本scを用いても他のユーザにその文書を頒布することはできない。すなわち、この仕組みによれば、文書の頒布許可を受けたユーザ以外のユーザが、他のユーザに対してその文書の頒布(すなわち閲覧の許可)を行うことはできない。
以上、文書の閲覧についての許可を例にとったが、閲覧以外の各種の操作(例えば編集など)についての許可を権限者に求める場合にも、同様の仕組みを用いることができる。
以上、本発明の実施形態について説明した。例示した実施形態は、いずれも、電子文書に関する承認を与えるプロセスを管理するという点で共通している。すなわち、1つの実施形態は、「文書そのもの」に対して権限者が承認を与えるものであったのに対し、別の実施形態は「文書に対する操作」に対して権限者が承認を与えるものと捉えることができる。
以上の実施形態では、ログ管理部19が記録したログデータを調べることで副本IDに対応する正本を特定していたが、正本と副本IDとの対応関係の情報を別途作成しておき、その情報から副本IDに対応する正本を特定してもよい。
10 文書管理サーバ、11 正本文書DB、13 正本文書登録部、15 副本sc(ショートカット)提供部、17 副本文書提供部、19 ログ管理部、20 クライアント端末、22 ビューワ、24 ファイルシステム、30 ネットワーク。
Claims (11)
- 管理している電子文書に対し、ユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作IDを発行すると共に、その操作要求に伴って受け取った操作IDと、その操作要求に応じた操作に応じて新たに発行された操作IDと、その操作要求を発したユーザ又はその新たに発行された操作IDの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録する文書管理サーバと、
電子文書に対する操作要求に応じて文書管理サーバから受け取った操作IDをその電子文書に対応する操作IDとして保存すると共に、保存した操作IDを指定してユーザから操作指示を受けた場合に、その操作IDを含んだ操作要求を文書管理サーバへと送るクライアントと、
を有し、
前記文書管理サーバは、
電子文書に関する承認申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作IDを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作IDに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、
を備える、承認管理システム。 - 請求項1記載の承認管理システムであって、
前記承認状態管理部は、クライアントから承認結果登録を要求する操作要求を受けた場合、その操作要求を発したユーザが、正当な承認権限者であるか否かを前記ログレコードに基づき判定し、正当な承認権限者である場合にはその操作要求を実行し、そうでない場合はその操作要求を実行しない、ことを特徴とする承認管理システム。 - 請求項1記載の承認管理システムであって、
前記文書管理サーバは、
前記電子文書に関する承認申請を行った申請者から、その電子文書に対応付けて提供した操作IDを伴う状態確認のための操作要求を受け取った場合、前記承認状態管理部が管理するその電子文書の承認状態の情報を申請者に提供する状態情報提供部、
を更に備えることを特徴とする承認管理システム。 - 請求項1記載の承認管理システムであって、
前記クライアントは、
電子文書に対する操作要求に応じて文書管理サーバから操作IDを受け取ったときに、その操作IDに対応する電子文書に対応した操作IDがそのクライアント内に既に存在する場合には、その既存の操作IDをその受け取った操作IDに置き換える操作ID管理部、
を更に備える承認管理システム。 - 請求項1記載の承認管理システムであって、
前記文書管理サーバは、
前記承認依頼に伴って承認権限者に提供した操作IDを伴う操作要求を承認権限者から受け取った場合に、その操作IDに対応する電子文書のコピーを含んだ副本ファイルを、その操作要求に応じて発行される新たな操作IDと共に、承認権限者に提供する副本提供部、
を備えることを特徴とする承認管理システム。 - 請求項5記載の承認管理システムであって、
前記クライアントは、
前記文書管理サーバから受け取った副本ファイルを固定記憶装置に保存しないように制御する副本制御部、
を備えることを特徴とする承認管理システム。 - 請求項1記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の承認である、ことを特徴とする承認管理システム。 - 請求項1記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の閲覧についての承認である、ことを特徴とする承認管理システム。 - 請求項1記載の承認管理システムであって、
前記電子文書に関する承認はその電子文書の一次頒布についての承認であり、
前記文書管理サーバは、
電子文書の一次頒布についての承認を得たユーザから、一次頒布先ユーザの指定を受けた場合に、その一次頒布先ユーザを記憶すると共に、その一次頒布先ユーザに対してその電子文書に対応づけられた新たな操作IDを送信し、その一次頒布先ユーザからその操作IDを伴う要求を受けた場合に、その電子文書のコピーを含む副本ファイルを提供する閲覧管理部、
を更に備えることを特徴とする承認管理システム。 - 電子文書が登録される文書データベースと、
文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作IDを発行する操作ID発行部と、
ユーザからの操作要求に伴って受け取った操作IDと、その操作要求に応じた操作に応じて新たに発行された操作IDと、その操作要求を発したユーザ又はその新たに発行された操作IDの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部と、
電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作IDを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部と、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作IDに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部と、
を備える文書管理サーバ。 - コンピュータを、
電子文書が登録される文書データベースと、
文書データベースに登録された電子文書に対しユーザからの操作要求に応じて操作を行うごとに、その電子文書に対応づけた新たな操作IDを発行する操作ID発行部、
ユーザからの操作要求に伴って受け取った操作IDと、その操作要求に応じた操作に応じて新たに発行された操作IDと、その操作要求を発したユーザ又はその新たに発行された操作IDの提供先であるユーザのうちの少なくとも一方と、の対応関係を示すログレコードを記録するログ管理部、
電子文書に関する承認の申請を要求する操作要求を受けた場合に、その電子文書に対応づけて発行された新たな操作IDを伴う承認依頼をその電子文書の承認権限者に対して送信する承認依頼部、
承認権限者の使用するクライアントから承認結果登録を要求する操作要求を受けた場合に、その操作要求に伴う操作IDに対応する電子文書に関する承認の状態を、その操作要求に応じて更新する承認状態管理部、
として機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006132183A JP2007304831A (ja) | 2006-05-11 | 2006-05-11 | 承認管理システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006132183A JP2007304831A (ja) | 2006-05-11 | 2006-05-11 | 承認管理システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007304831A true JP2007304831A (ja) | 2007-11-22 |
Family
ID=38838708
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006132183A Pending JP2007304831A (ja) | 2006-05-11 | 2006-05-11 | 承認管理システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007304831A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010204915A (ja) * | 2009-03-03 | 2010-09-16 | Nec Corp | 電子文書開示システム、電子文書の開示方法およびプログラム |
JP2019071055A (ja) * | 2017-10-06 | 2019-05-09 | 株式会社リコー | 文書状態管理システム、文書状態管理方法、プログラム |
WO2022074757A1 (ja) * | 2020-10-07 | 2022-04-14 | 富士通株式会社 | 制御方法、制御プログラム、および情報処理装置 |
US11863615B2 (en) | 2022-03-18 | 2024-01-02 | T-Mobile Usa, Inc. | Content management systems providing zero recovery time objective |
-
2006
- 2006-05-11 JP JP2006132183A patent/JP2007304831A/ja active Pending
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010204915A (ja) * | 2009-03-03 | 2010-09-16 | Nec Corp | 電子文書開示システム、電子文書の開示方法およびプログラム |
JP2019071055A (ja) * | 2017-10-06 | 2019-05-09 | 株式会社リコー | 文書状態管理システム、文書状態管理方法、プログラム |
JP7159765B2 (ja) | 2017-10-06 | 2022-10-25 | 株式会社リコー | 文書状態管理システム、文書状態管理方法、プログラム |
WO2022074757A1 (ja) * | 2020-10-07 | 2022-04-14 | 富士通株式会社 | 制御方法、制御プログラム、および情報処理装置 |
US11863615B2 (en) | 2022-03-18 | 2024-01-02 | T-Mobile Usa, Inc. | Content management systems providing zero recovery time objective |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4876734B2 (ja) | 文書利用管理システム及び方法、文書管理サーバ及びそのプログラム | |
JP4602769B2 (ja) | 文書セットのコンテンツ空間のナビゲーション | |
JP4816281B2 (ja) | 文書利用管理システム、文書管理サーバ及びそのプログラム | |
US7827156B2 (en) | Issuing a digital rights management (DRM) license for content based on cross-forest directory information | |
EP1460511B1 (en) | Reviewing cached user-group information in connection with issuing a digital rights management (DRM) license for content | |
CN100399788C (zh) | 文档集合处理 | |
JP4838610B2 (ja) | 文書管理装置、文書管理方法、プログラム | |
CN101364221B (zh) | 文档管理装置、文档管理系统和方法 | |
JP6204900B2 (ja) | 文書の電子メール送信と一体化された権限管理システムおよび方法 | |
US20070208665A1 (en) | Electronic document creating device, storage medium storing electronic document creating program, electronic document creating method, and storage medium storing electronic form | |
JP2005242586A (ja) | 文書ビュー提供のためのプログラム、装置、システム及び方法 | |
US20080133618A1 (en) | Document providing system and computer-readable storage medium | |
US8042146B2 (en) | Apparatus and method for generating an electronic document, and storage medium | |
JP5560691B2 (ja) | 文書利用管理システム、文書処理装置、操作権限管理装置、文書管理装置及びプログラム | |
JP2009163525A (ja) | 電子メール送信方法 | |
JP5012525B2 (ja) | セキュリティポリシーサーバ、セキュリティポリシー管理システム及びセキュリティポリシー管理プログラム | |
JP5119840B2 (ja) | 情報処理装置、情報処理システム、及びプログラム | |
JP2002117215A (ja) | 特許管理システム | |
JP2018156410A (ja) | 情報処理装置及びプログラム | |
JP2007304831A (ja) | 承認管理システム | |
JP4266897B2 (ja) | ライセンス管理システム、ライセンス管理方法、ライセンス管理サーバ、及びライセンス管理ソフトウェア | |
JP2000305834A (ja) | データアクセス制御装置 | |
JP2020047222A (ja) | ドキュメント管理システム | |
JP6777213B2 (ja) | 情報処理装置及びプログラム | |
JP7418238B2 (ja) | 情報処理装置、情報処理方法、及びプログラム |