JPH08287147A

JPH08287147A - ペーパーレス公文書管理システム

Info

Publication number: JPH08287147A
Application number: JP8508595A
Authority: JP
Inventors: Yoko Saito; 洋子齋藤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1995-04-11
Filing date: 1995-04-11
Publication date: 1996-11-01

Abstract

(57)【要約】【目的】利用者の身分証明書ファイルを管理する身分証
明書発行／管理サーバと、利用者情報ファイルの指定条
件に応じて公文書保管ファイル中の公文書を公開、破棄
する公文書業務管理サーバで、公文書をペーパーレス管
理する。【構成】ネットワークシステムＮ上の身分証明書発行サ
ーバＳ１／管理サーバＳ２は利用者Ｕ１に身分証明書を
発行／配布する。Ｕ１は身分証明書をもとに，公文書業
務管理サーバＳ３に対して、業務条件を提示し、メッセ
ージの保管、公開、及び破棄を要求する。Ｕ１は簡易な
ＡＰＩを利用してメッセージの公文書登録及び保護を要
求でき、身分証明書及びメッセージの送受信には、Ｕ１
に意識させない形で暗号化機能が適用され、証拠情報が
添付される。Ｓ３は、利用者間に発生した紛争の調停、
セキュリティに関する履歴情報の取得及び監査を行うこ
とにより、取扱に機密性を要するメッセージの送受信を
保証する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ペーパーレス公文書管
理システムに関し、特にネットワークシステムを介して
接続された端末間で、取扱いに機密性を要する公文書を
ペーパーレスの形態で送受信し、利用者からの依頼通り
に公文書管理業務を遂行するペーパーレス公文書管理シ
ステムに関する。

【０００２】

【従来の技術】従来から、例えば遺言状業務のような、
公文書業務を依頼し、ある一定の条件のもとで対象者に
情報を公開させるサービスが法律事務所で行われてい
る。

【０００３】このサービスをペーパーレスで行うために
は、情報の機密性を十分考慮した電子メールシステムが
必要である。機密性を考慮した電子メールシステムを提
供する基盤技術として、身分証明書サーバ、身分証明書
管理サーバを用いて利用者の管理を行い，及びセキュリ
ティ業務管理サーバで利用者の機密業務を実現する一シ
ステムを、「メッセージの信託システム」（特願平６−
３２７２６７号）で既に出願している。

【０００４】しかしながら、前記システムを利用する具
体的な業務アプリケーションは提案されていない。従っ
て、法律事務所で行われている公文書業務そのもののシ
ステムの提案が重要である。

【０００５】

【発明が解決しようとする課題】例えば、法律事務所に
対して公文書業務を依頼し、ある一定の条件のもとで対
象者に情報を公開させるサービスをペーパーレスで実現
したい場合、現状の電子メールシステムに対してさらに
次の要件が必要となる。

【０００６】（１）文書が公文書として認められるこ
と。

【０００７】作成された文書は決められた形式に従い、
必要であればシステム管理者や管轄省庁の承認を得るこ
と、文書は業務依頼者本人が作成したものであること、
原本であること、何者によっても改ざんされていないこ
とが保証されていなければならない。

【０００８】（２）文書をきちんと管理できること。

【０００９】文書の管理者が業務依頼者の依頼条件通り
に文書を管理する。そのためには、第三者に見せないこ
と、当該文書にアクセスを許さないために監視すること
が必要である。

【００１０】既に、前記「メッセージの信託システム」
（特願平６−３２７２６７号）で身分証明書サーバ、身
分証明書管理サーバ，及びセキュリティ業務管理サーバ
からなるセキュリティ製品の基盤技術を提案している。

【００１１】従って、前記サーバ上にどのようなファイ
ルを持たせ、利用者のアプリケーションにどのようなア
プリケーションインタフェースで公文書管理業務を実現
させるかというシステムを提案することが、本発明が解
決しようとする課題である。

【００１２】

【課題を解決するための手段】本発明は、上述の目的を
達成するために以下のようなシステムにしている。

【００１３】ネットワーク上に接続された公文書情報の
送受信を行う複数の端末を有するシステムにおいて、身
分証明書発行サーバを設けることにより、公文書業務の
利用者に対して身分証明書を発行し、前記身分証明書の
情報を身分証明書ファイルに登録及び管理する手段と、
公文書業務管理サーバを設けることにより、前記利用者
からの要求を利用者ファイルで管理し、前記利用者から
のメッセージを公文書として登録し、前記利用者ファイ
ルの指定どおりに公文書管理業務を遂行する手段と、前
記利用者の端末から送信されてきた公文書に関する情報
について生成／送受信が行われたことを示す証拠情報を
作成する手段と、前記公文書を他の何者にも見られない
ように秘匿する手段と、前記公文書を他の何者にもねつ
造されないような形式に変換する変換手段と、前記複数
の端末の利用者間での紛争発生時には、前記証拠情報の
真偽を判定する判定手段と、前記システム内の事象につ
いて履歴を取得する手段と、前記履歴に基づいてセキュ
リティ侵害について監査する手段と、さらに、前記身分
証明書発行サーバ及び前記公文書業務管理サーバによ
り、前記利用者に対して、前記身分証明書発行業務と前
記公文書業務を利用させるアプリケーションインタフェ
ースを提供する手段と、を備える。

【００１４】

【作用】本発明によれば、身分証明書を発行／登録／管
理する手段は、公文書業務の利用者の身元を保証し、公
文書業務を管理／登録／遂行する手段は、前記身元の保
証が完了した利用者に対して、公文書業務を提供する。

【００１５】また、証拠情報を作成する手段は、前記公
文書業務の利用者の端末から送信されてきた公文書に関
する情報について生成及び送受信が行われた事実を証明
するための証拠情報を作成するので、端末の公文書業務
利用者間で紛争が発生した時には、証拠情報判定手段が
前記証拠情報を調べることにより、その真偽を判定する
ことができる。

【００１６】前記公文書については、他の何者もその内
容を見ることができないように、秘匿手段がメッセージ
を暗号化し、さらに、他の何者もその内容をねつ造でき
ないように、変換手段がメッセージの内容を変換するこ
とができる。

【００１７】また、ネットワークシステムに接続された
端末からは、不正な悪意を持った第三者が侵入する可能
性があるため、履歴の取得手段により、前記システム内
の事象について絶えず記録を取る。そして、監査手段に
より、取得した履歴を分析することによりネットワーク
システム内のセキュリティ侵害を検出することができ
る。

【００１８】さらに、利用者に対して、アプリケーショ
ンインタフェースを提供することにより、利用者のアプ
リケーションから容易に、前記身分証明書発行業務と前
記公文書業務を利用させることが可能になる。

【００１９】

【実施例】以下、本発明の一実施例を図面を用いて詳細
に説明する。

【００２０】図１は本発明の一実施例を示す法律事務所
システム及びネットワークシステムの構成図である。当
ネットワークシステムＮには複数の身分証明書発行サー
バＳ１、身分証明書管理サーバＳ２、及び公文書業務管
理サーバＳ３が存在しており、ネットワークを介して接
続されたＷＳ１０〜３０から公文書業務の要求ができ
る。また、公的機関サーバＳ４は、利用者のメッセー
ジを公文書として承認する機関であり、信頼できる第三
者機関や管轄省庁の機構に相当する。

【００２１】一方、Ｓ１，Ｓ２及びＳ３は法律事務所シ
ステムの一部であり、公文書管理業務の利用者は、ＷＳ
１０〜３０を利用する。以降の例では、ＷＳ１０の利用
者Ｕ１が公文書業務管理サーバＳ３に公文書業務を依頼
する場合について説明する。

【００２２】利用者Ｕ１は公文書業務管理サーバＳ３に
メッセ−ジの信託を要求する前に、身分証明書発行サー
バＳ１に、身分証明書ＰＵ１の発行を要求する必要があ
る。図２により、Ｕ１がＰＵ１の発行を要求する処理20
1及びＳ１がＵ１に対して身分証明書ＰＵ１の引替え証
ＰＵ１’を渡す処理202を説明する。

【００２３】処理201のアプリケーションインタフェー
スとしては、X/Openで規定されているＧＳＳ−ＡＰＩ(G
eneric Security Service -Application Program Inter
face)を採用しているために、第三者のアプリケーショ
ンにも適用可能である。ＧＳＳ−ＡＰＩ自体はアプリケ
ーションインタフェースであるが、利用者Ｕ１の端末に
は、予め法律事務所システム側から配布されたセキュリ
ティ管理プログラムＳＰ_U1をインストールしておくため
に、利用者Ｕ１は通信に必要なセキュリティ機能（ｅ
ｘ．暗号化や鍵管理等）を全く意識する必要はない。

【００２４】図２において、利用者Ｕ１は201の処理(GS
S_Acquire_cred要求)で、自分がＵ１であることを示す
識別情報、パスワード等の情報Ｉ_U1を指定する。さら
に、必要であれば有効期間、オブジェクト識別子情報，
通信形態（双方向／一方向）を指定することが可能であ
る。

【００２５】前記利用者Ｕ１に対して、Ｓ１は201の処
理要求を確認し、Ｕ１に対してＰＵ１’を202の処理に
より発行する。このＰＵ１’の情報は、身分証明書情報
を身分証明書管理サーバＳ２から取得する時に必要な情
報なので、Ｕ１は大切に保管しておく必要がある。ま
た、当然のことながら、Ｕ１は自分であることを示す情
報Ｉ_U1を他人に知られてはならない。セキュリティ管理
プログラムＳＰ_U1は、必要であれば、Ｓ１からの応答を
Ｕ１に通知する。

【００２６】ここで、法律事務所システムとして考慮し
なければならない点は、処理201及び202のやり取りをネ
ットワークシステムＮ内に介在する可能性のある悪意を
持った第三者Ｕ２に見せないということである。そのた
めには、前記処理201及び202のやり取りを暗号化するこ
とが有効である。例えば、ネットワークシステムＮ内に
公開鍵暗号方式を採用することにより、全ての利用者Ｕ
ｉの公開鍵ＰＫ_Uiと身分証明書発行サーバＳ１の公開鍵
ＰＫ_S1，身分証明書管理サーバＳ２の公開鍵ＰＫ_S2、及
びセキュリティ業務管理サーバＳ３の公開鍵ＰＫ_S3を公
開しておく公開鍵ＤＢ（データベース）を用意する。

【００２７】そして、各利用者Ｕｉは予め情報Ｉ_Uiとは
別に秘密鍵ＳＫ_Uiを保管しておく。利用者Ｕ１は自分以
外の鍵情報は管理する必要はなく、前記セキュリティ管
理プログラムＳＰ_U1が管理する。

【００２８】具体的には、図３に示すように、ＳＰ_U1が
処理201の情報を暗号化してＳ１に送り、Ｓ１は暗号化
された情報を復号化する。Ｓ１からＳＰ_U1に送る時も同
様で、Ｓ１が処理202の情報を暗号化してＳＰ_U1に送
り、ＳＰ_U1は暗号化された情報を復号化した後、Ｕ１に
渡す。従って、Ｕ１はＳＰ_U1とＳ１間の暗号化通信につ
いて意識する必要はない。

【００２９】図３に、ＳＰ_U1が秘密鍵ＳＫ_U1と前記Ｓ１
の公開鍵処理ＰＫ_S1を用い処理201の通信を暗号化する
一例を示す。ＳＰ_U1は、利用者Ｕ１からの処理201の情
報を、処理301によりＳＫ_U1で暗号化し、ＰＫ_S1で暗号
化して送信する(処理302)。すると、Ｓ１では、この暗
号化された処理201のメッセージＭ，すなわちENC_PKS1(E
NC_SKU1(I_U1))を、処理303により秘密鍵ＳＫ_S1で解読
し、さらに、Ｕ１の公開鍵ＰＫ_U1により解読する。秘密
鍵ＳＫ_S1を持つＳ１だけがENC_SKU1(I_U1)の内容を確認で
き、さらに公開鍵ＰＫ_U1により復号化して得た情報Ｉの
内容を調べることにより、前記メッセージＭがＵ１から
送信されてきたものであることが確認できる(処理30
4)。同様に、処理202についても、処理305により、Ｓ１
はメッセージを自分の秘密鍵ＳＫ_S1で暗号化してから、
さらに、ＰＫ_U1で暗号化してＳＰ_U1に送信する(処理30
6)。

【００３０】すると、この暗号化されたメッセージＭ，
すなわちENC_PKU1(ENC_SKS1(PU1',SSK1,CU1))を解読でき
るのは秘密鍵ＳＫ_U1を持つＳＰ_U1（及びＵ１）だけであ
り、さらに、処理307により、Ｓ１の公開鍵ＰＫ_S1で解
読することにより、前記処理202のメッセージＭはＳ１
から送信されてきたものであることを確認できる。前記
処理202の指定では、以降の通信で用いるセション鍵Ｓ
ＳＫ１や身分証明書ＰＵ１の取得要求をＳ２に行うアク
セス条件ＣＵ１を付加する(処理305)ことにより、身分
証明書発行業務を確実にしている。

【００３１】例えば、条件ＣＵ１により、指定された期
間内に指定された経路でＳ２に前記取得要求をすること
という条件をつけることにより、悪意のある利用者Ｕ２
の介入を阻むことができる。

【００３２】201及び202の処理でやりとりする情報、情
報の保護のレベル、及び利用者の資格審査の方法は、当
公文書業務管理システムの機密度に応じて決められる。

【００３３】身分証明書発行サーバＳ１は、利用者Ｕ１
の身分証明書の発行要求を受付けるが、実際にＰＵ１を
配布するのは身分証明書管理サーバＳ２の役割である。
これは、身分証明書の発行に時間がかかることが予想さ
れることから、身分証明書発行サーバＳ１の証明書発行
業務が集中した場合のトラフィック量を考慮しているた
めである。

【００３４】また、利用者Ｕ１が身分証明書管理サーバ
Ｓ２にＰＵ１’を提示し、身分証明書の取得を要求する
ことにより、利用者Ｕ１の身元を２回確認することがで
きる。身分証明書管理サーバＳ２は、身分証明書を取得
要求してきた利用者が本当に身分証明書発行サーバＳ１
に身分証明書の発行を要求した利用者Ｕ１であることを
確認する必要がある。図３のシーケンスで示したアクセ
ス条件でＣＵ１を確認することも必要であり、前記条件
を満たさない利用者の身分証明書取得要求は拒否するよ
うにしてもよい。

【００３５】図４では、身分証明書発行サーバＳ１が利
用者Ｕ１に関する情報を身分証明書管理サーバＳ２に登
録する処理401，利用者Ｕ１がＳ２に対して身分証明書
ＰＵ１を取得要求する処理402、及びＳ２がＵ１に対し
て身分証明書ＰＵ１を配布する処理403を示している。
ここで、処理401では、図２の処理202でＳ１がＵ１に対
して発行した引替え証ＰＵ１’の情報をＳ２に対して渡
す。セション鍵ＳＳＫ１や身分証明書ＰＵ１の取得に関
するアクセス条件ＣＵ１が指定されていれば、それらも
渡す必要がある。

【００３６】Ｓ１とＳ２の間では、処理401に代表され
るような、取扱いに機密性を要する情報が交換されるた
めに、Ｓ１とＳ２の間の通信路は十分保護されていなけ
ればならない。例えば、特殊な保護チャネルを使用する
こと、Ｓ１及びＳ２に対するアクセス管理をきちんと行
うこと、Ｓ１とＳ２しか知らない暗号鍵を設定すること
等によりデータを暗号化して通信する必要がある。

【００３７】また、処理402では、利用者Ｕ１は、身分
証明書管理サーバＳ２に対して、自分がＵ１本人である
ことを示す識別情報（処理201で提示した情報）、及び
身分証明書ＰＵ１の引替え証ＰＵ１’を提示する。処理
403では、Ｕ１から入力された前記情報を確認し、問題
がなければ、身分証明書ＰＵ１を配布する。この処理40
3により、利用者Ｕ１に身分証明書情報の取得の意志が
あることを確認できるが、身分証明書の取得が前提であ
るような実装のシステムでは、図２の応答処理及び図４
の配布要求を省略することができる。

【００３８】この場合には、利用者Ｕ１は図２でGSS_Ac
quire_credを発行した後、図４でGSS_Acquire_cred応答
により身分証明書ＰＵ１を得るため、利用者Ｕ１で引替
え証ＰＵ１’の情報を管理する必要がなくなる。このよ
うにして、発行された利用者の身分証明書情報は、身分
証明書管理サ−バＳ２の管理する身分証明書ファイルＦ
１に格納される。

【００３９】ここで、注意しなければならないのは、身
分証明書情報が悪意のある第三者の手に渡った場合であ
る。例えば、正しい利用者Ｕ１に発行された身分証明書
ＰＵ１を悪意のある第三者Ｕ２が盗み見るというケース
について考える。もちろん、利用者Ｕ１には身分証明書
ＰＵ１をきちんと管理することが義務づけられているた
め、ＷＳ１０からＰＵ１が盗まれた場合にはＵ１に責任
がある。しかし、ネットワークシステム内の通信の過程
でＰＵ１が盗まれた場合には、法律事務所システム側の
責任になる。

【００４０】従って、図５に示すように、セキュリティ
管理プログラムＳＰ_U1と身分証明書管理サーバＳ２の間
の通信の保護が必要になる。ＳＰ_U1は処理402のメッセ
ージ（情報Ｉ_U1及びＰＵ１’等）を、処理501によりＳ
Ｋ_U1で暗号化し、さらにＰＫ_S2で暗号化して送信する
(処理502)。セション鍵ＳＳＫ１が指定されている場合
には、前記暗号化した処理402のメッセージを、さらに
前記ＳＳＫ１で暗号化して送信することにより、Ｕ１と
Ｓ２の間の処理の機密性を上げることができる。

【００４１】この暗号化されたメッセージＭ，すなわち
ENC_PKS2(ENC_SKU1(PU1',...))を解読できるのはＳＳＫ
１、秘密鍵ＳＫ_S2を持つＳ２だけであり、処理503によ
り、さらにＵ１の公開鍵ＰＫ_U1で解読することにより、
前記処理402のメッセージがＵ１から送信されてきたも
のであることが確認できる。

【００４２】また、処理503の結果、アクセス条件ＣＵ
１が満たされていない場合には、処理504により処理402
は拒否される。同様に、処理403のメッセージ（身分証
明書ＰＵ１及び必要であれば新しいセション鍵ＳＳＫ２
等）について、Ｓ２はメッセージを処理505により自分
の秘密鍵ＳＫ_S2で暗号化してから、さらにＰＫ_U1で暗号
化してＵ１に送信する。

【００４３】すると、この暗号化されたメッセージＭ，
すなわちENC_PKU1(ENC_SKS2(PU1,SSK_i))を解読できるのは
ＳＳＫ１、秘密鍵ＳＫ_U1を持つＳＰ_U1（又はＵ１）だけ
であり、処理507によりさらにＳ２の公開鍵ＰＫ_S2で解
読することにより、前記処理403のメッセージはＳ２か
ら送信されてきたものであることを確認できる。ここ
で、ＳＳＫ_iは以降の通信処理で用いるセション鍵を想
定している。

【００４４】一旦、身分証明書ＰＵ１が発行されると、
この情報を用いて利用者Ｕ１は、公文書業務管理サーバ
Ｓ３に公文書管理業務を依頼することができる。図６に
より公文書管理業務処理の概要を説明する。利用者Ｕ１
は、公文書業務管理サーバＳ３に対して、どのようなメ
ッセージをどのような形式で業務依頼するかの業務条件
ＣＵ２を処理602で伝える。処理602のアプリケーション
インタフェースとしては、ＧＳＳ−ＡＰＩ(Generic Sec
urity Serv-ice -Application Program Interface)を採
用している。

【００４５】そのため、図６において、利用者Ｕ１は60
2の処理(GSS_Init_sec_context要求)で、業務条件ＣＵ
２を指定する。公文書業務管理サーバＳ３では、ＣＵ２
の内容を確認し業務条件について合意が取れれば、処理
603（GSS_Accept_sec_context要求)により回答／指示を
返す。このGSS_Accept_sec_contextの出力パラメータ
で、前記業務条件を受付けるか拒否するか指定する。処
理603で業務条件を受付けた場合には、公文書業務管理
サーバ内の利用者情報ファイルＦ２にＣＵ２を格納す
る。

【００４６】また、この時に、前記業務依頼についての
証拠情報を作成するために図５の処理505で与えられる
セション鍵ＳＳＫ３を使用することが可能である。さら
に、ＳＰ_U1とＳ３の間の通信を保護するために、図３及
び図５で示したような暗号化通信を行う（図８を参
照)。

【００４７】公文書業務管理サーバＳ３は、身分証明書
管理サーバＳ２から利用者Ｕ１に関する情報を受け取っ
ている（処理601）。従って、不正な利用者Ｕ２が利用
者Ｕ１であると偽って業務依頼してきても拒否すること
ができる。

【００４８】Ｓ２とＳ３の間では、処理601に代表され
るように、取扱いに機密性を要する情報が交換されるた
めに、Ｓ２とＳ３の間の通信路は十分保護されていなけ
ればならない。例えば、特殊な保護チャネルを使用する
こと、Ｓ２及びＳ３に対するアクセス管理をきちんと行
うこと、Ｓ２とＳ３しか知らない暗号鍵を設定すること
によりデータを暗号化して通信することなどが必要であ
る。

【００４９】次に、業務条件ＣＵ２の一例を示す。例え
ば、利用者Ｕ１は自分のメッセージ情報Ｍ１を、公開指
定日時情報Ｔ１に、利用者Ｕ３に公開するという条件で
あるとする。また、利用者Ｕ１はＳ３に保管依頼するメ
ッセージＭ１の保護手段についてもＣＵ２で規定するも
のとする。ＣＵ２では、図７に示すように、Ｍ１に対し
てどのような機密性，完全性，アクセス制御，否認不可
及び監査機能を提供するかを規定している。

【００５０】例えば、図７の例では、機密性のレベル(C
n)は２、完全性のレベル(In)は１となっているので、メ
ッセージＭ１のデータ全体を暗号化し改ざん検出のため
のコードを付加することが義務づけられる。また、破棄
指定日時Ｔ３が指定されているので、前記Ｔ３の時刻を
過ぎたら、前記メッセージＭ１は破棄されなければなら
ない。また、公的機関の名称がＳ４と指定されているた
め、メッセージＭ１を公文書としてＳ４に対して登録す
る必要がある。前記登録処理については、図１３に示
す。

【００５１】業務条件について合意が取れた後、図６の
処理604に示すように、利用者Ｕ１は管理依頼したいメ
ッセージＭ１を公文書業務管理サーバＳ３に送る。この
際、本当にＭ１が利用者Ｕ１が作成した情報であり、第
三者によって改ざんされていないことを保証したい場合
に、Ｕ１はGSS_signを利用して署名情報を作成すること
ができる。この署名情報は、Ｕ１とＳ３だけが解読でき
る情報であり、ＳＰ_U1は関知しない点で図８に示す証拠
情報Ｅ１，Ｅ２と異なる。Ｕ１がGSS_signを利用する場
合、公文書業務管理サーバＳ３はGSS_Verifyにより(処
理605)Ｕ１から受け取った処理604の内容を確認する。

【００５２】また、同様に、利用者Ｕ１の意志により、
メッセージＭ１の内容を暗号化したい時には、GSS_Seal
を利用でき、受け取り側のＳ３ではGSS_Unsealにより暗
号化された内容を解読可能である。この場合もGSS_Seal
で暗号化された内容については、ＳＰ_U1は関知しない。
このように、GSS_signとGSS_Sealというアプリケーショ
ンインタフェースを利用者に提供することにより、容易
に利用者にセキュリティ機能を提供している。また、先
に述べたように、セキュリティ管理プログラムＳＰ_U1と
Ｓ３との間で暗号化通信も行っており、証拠情報の作成
による送受信されるデータの保証を行なう。

【００５３】図８に示すように、セキュリティ管理プロ
グラムＳＰ_U1は、利用者Ｕ１の秘密鍵ＳＫ_U1と公文書業
務管理サーバＳ３の公開鍵ＰＫ_S3、及び指定されていれ
ばセション鍵ＳＳＫ２を用いて利用者Ｕ１のメッセージ
の内容を暗号化する。原則として、前記の暗号鍵を用い
てメッセージを暗号化してあれば、内容は悪意を持った
利用者Ｕ２によって見られないと期待されるが、ＳＰ_U1
が送る情報が本当に利用者Ｕ１が作成したという事実を
保証するための証拠情報Ｅ１と、送信するメッセージ情
報Ｍ１が原本であることを保証する証拠情報Ｅ２をメッ
セージＭ１に付加しておくことが有効である。証拠情報
Ｅ１及びＥ２の作成処理を、信頼できる第三者機関に依
頼する場合も考えられる。

【００５４】図８の例では、ＳＰ_U1が依頼するメッセー
ジＭ１に作成日時情報Ｔ０を入力情報として、秘密鍵Ｓ
Ｋ_U1で暗号化することにより完全性のためのコードＥ１
を作成しメッセージＭ１に付加する。また、処理801で
は、原本性を保証する目的で公文書業務管理サーバから
与えられたセション鍵ＳＳＫ３を用いて、Ｅ１を付加し
たメッセージＭ１を変換することにより作成したＥ２を
メッセージＭ１に付加する。このようにして作成したメ
ッセージＭ２（メッセージＭ１にＥ１とＥ２を付加した
もの）を、自分の秘密鍵ＳＫ_U1と公文書業務管理サーバ
Ｓ３の公開鍵ＰＫ_S3、及び指定されていれば処理802に
よりセション鍵ＳＳＫ２を用いて暗号化した後Ｓ３に送
る。

【００５５】一方、公文書業務管理サーバＳ３は、前記
メッセージＭ２を受信すると、処理803でセション鍵Ｓ
ＳＫ２及び公開鍵ＰＫ_U1により解読し、さらに自分の秘
密鍵ＳＫ_S3により解読することにより得たメッセージＭ
２を業務条件ＣＵ２の条件に基づきＳ３の公文書保管フ
ァイルＦ３の中に安全に保管する(処理805)。公文書保
管ファイルＦ３は、図９のフローチャートに従い、業務
条件ＣＵ２の条件が満たされなければ、誰にも見せない
しかけになっている。

【００５６】ここで、図８の処理804では、公文書業務
管理サーバＳ３がＳＰ_U1から受信した証拠情報をＥ１’
とＥ２’、受信したメッセージをＭ１’、受信した作成
日時情報をＴ０’と区別して呼ぶことにする。実際にＳ
Ｐ_U1が作成した情報は、Ｅ１，Ｅ２であるが（処理801)
途中で何者かによって改ざんされている可能性があるた
めである。Ｓ３は、受信した情報が正しいかどうか(処
理804の判定)を図１０の処理のフローチャートに従い確
認する。

【００５７】Ｓ３は、処理1001により受信したＥ１’を
Ｕ１の公開鍵ＰＫ_U1で復号化し、それにより得られた情
報Ｉ，すなわち（Ｍ１”、Ｔ０”）のＭ１”が受信した
メッセージＭ１’と等しいかどうかを調べる(処理100
2)。この時、必要であれば、受信した作成日時情報Ｔ
０’を確認する。メッセージが等しい場合には、確か
に、Ｍ１’がＵ１によって作成されたものであることが
確認できる。

【００５８】次に、処理1004により受信したメッセージ
Ｍ１’とＥ１’をセション鍵ＳＳＫ３を入力パラメタと
してハッシュ関数をかけることによりＥ２”を作成す
る。ここでは、あらかじめＳＰ_U1とＳ３の間では、同一
の前記ハッシュ関数を秘密に持ち合っているものとす
る。作成したＥ２”が受信したＥ２’と等しいかどうか
を処理1005により確認し、等しい場合には、メッセージ
が途中で変更されていないことが確認できる。

【００５９】このようにして、受信した情報の正当性が
確認された後、Ｓ３はメッセージＭ２（すなわちＭ１’
とＥ１’とＥ２’）の内容をＦ３に保管する(処理80
5)。

【００６０】ＣＵ２の条件で公的機関の名称Ｓ４が指定
されている場合には、図１３に従って、公文書業務管理
サーバＳ３によるメッセージ登録が必要になる。これ
は、利用者Ｕ１のメッセージＭ２を公文書として公的機
関に登録する処理であリ、一般的には、公的機関に証明
証を発行してもらう形態が考えられる。

【００６１】図１３の例では、Ｓ３がＳ４に対して証明
書発行要求(処理1301)を出し、それに対しＳ４ではＳ３
からの処理要求の内容を確認して、問題なければ前記証
明証を発行する(処理1302)シーケンスとなっている。Ｓ
３とＳ４の間のプロトコル及び証明証の形式について
は、説明を省略する。

【００６２】利用者Ｕ１が指定した業務条件ＣＵ２が満
たされた時に、公文書業務管理サーバＳ３は、業務条件
ＣＵ２に基づき、利用者Ｕ３に対してメッセージＭ１を
公開する。今まで、Ｓ３はメッセージＭ２の内容を身分
証明書保管ファイルＦ３に保管していたが(処理805)、
Ｍ２を取り出し、その内容を確認し、メッセージＭ１’
がＵ１によって作成されたものであること（すなわちＭ
１であること）、及びＭ１が原本であることを確認する
のはＳ３の役目である。これは、身分証明書保管ファイ
ルＦ３に格納されている間にＭ１’，Ｅ１’，Ｅ２’が
変更されていないことを保証するためである。この目的
で、Ｓ３は証拠情報Ｅ１’とＥ２’を確認する。確認方
法は、図１０の処理と同様である。

【００６３】図１０の確認処理が終了した後、公文書業
務管理サーバＳ３は図１１のフローチャートにより、メ
ッセージＭ１を利用者Ｕ３に送信する。この時も、処理
1101により、Ｓ３の秘密鍵ＳＫ_S3及び利用者Ｕ３の公開
鍵ＰＫ_U3によりＭ１を暗号化して送る(処理1102)必要が
ある。本物の利用者Ｕ３であれば、秘密鍵ＳＫ_U3により
受信したメッセージを解読できるはずであるし、公開鍵
ＰＫ_S3により解読(処理1103)することにより、前記受信
したメッセージが確かにＳ３によって保証されているも
のであることが確認できる。また、ここでＳ３が添付す
るメッセージがあれば処理1101でメッセージＭ３として
送信する。前記シーケンスを図１１に示す。この処理
が、図６の処理606に相当する。

【００６４】ここで、考慮しなければならないのは、利
用者Ｕ１と利用者Ｕ３との間で業務依頼されたメッセー
ジの送受信について紛争が発生した場合に、公文書業務
管理サーバＳ３が果たさなければならない役目について
である。メッセージを依頼する側のＵ１とＳ３の間で
は、証拠情報Ｅ１，Ｅ２の作成によって、処理にかなり
の機密度が保証されていると考えられる。しかし、利用
者Ｕ３については、偽りの申告をしてくる可能性があ
る。考えられるケースとしては、次のものがある。

【００６５】（１）利用者Ｕ３がメッセージＭ１に対す
る応答をしない。

【００６６】（２）利用者Ｕ３が受信したメッセージと
別のものを受信したと言い張る。

【００６７】（３）利用者Ｕ３の管理が悪かったため
に、悪意を持った利用者Ｕ２にメッセージＭ１が利用さ
れる。

【００６８】まず、（１）のような可能性がある場合、
業務条件ＣＵ２の中でメッセージの渡し方について規定
しておく必要がある。例えば、リトライ回数の指定、及
び義務付けた応答を利用者Ｕ３が返してこない時には受
信したと解釈する等である。ここで、信頼できる配送サ
ーバを設けて配送の証拠情報Ｅ３を作成しておくことも
有効である。

【００６９】また、（２）のケースについては、証拠情
報Ｅ１，及びＥ２とＥ３を提示することが有効である。
Ｅ１により、メッセージＭ１が確かにＵ１によって作成
されたこと、Ｅ２により前記Ｍ１の原本性（修正されず
に保管されていたこと）、さらにＥ３により前記Ｍ１が
依頼されたままの状態で利用者Ｕ３に渡されたことが証
明される。

【００７０】前記（３）については、明らかに、利用者
Ｕ３の責任が明確であるが、Ｓ３はＵ３にメッセージＭ
１を送るより前に、前記Ｍ１が漏洩したのではないこと
を、次に示すセキュリティ監査機能によって証明しなけ
ればならない。

【００７１】ネットワークシステムのセキュリティ監査
機能の詳細については、先に出願した「セキュリティ管
理装置」（特願平６−４７１９４号）の発明を参照され
たい。原則として、セキュリティ監査機能としては、
セキュリティ関連の事象についてのメッセージの収集手
段(処理1201)、メッセージ分析手段(処理1202)、メッセ
ージ記録手段(処理1204)、メッセージ選択手段(処理120
3)、及びセキュリティレポート作成手段(処理1205)を備
えている。

【００７２】ここで処理1206により作成されたセキュリ
ティレポートの情報を分析し、処理1207によりネットワ
ークシステム全体の弱点を診断する手段が提供されてい
るので、本発明の監査手段の目的でも利用することがで
きる。図１２にセキュリティ監査機能の概要を示す。

【００７３】最後に、実際の法律事務所での公文書業務
の流れを図１４で説明する。法律事務所のシステム構成
は、図１に示す通りである。法律事務所では身分証明書
発行サーバＳ１内に身分証明書ファイルＦ１、身分証明
書管理サーバＳ２内に利用者情報ファイルＦ２，公文書
業務管理サーバＳ３内に公文書保管ファイルＦ３を持
つ。その他に顧客管理ファイルＦ４を使用するが、顧客
管理ファイルＦ４には顧客を識別する情報（Ｕ１，
Ｉ_U1，ＰＵ１’，ＣＵ１，ＳＳＫ１：具体的には、顧客
氏名、住所、依頼日時、アクセス条件等）を格納し、身
分証明書ファイルＦ１には実際に公文書業務を行なうこ
とになった顧客を識別する身分証明書情報（Ｕ１，
Ｉ_U1，ＰＵ１，ＣＵ２，ＳＳＫ２，ＳＳＫ３：具体的に
は、顧客氏名、身分証明書、業務条件等）を格納する。
また、実際に顧客から預かる情報（Ｍ１’，Ｅ１’，Ｅ
２’：具体的には公文書、証拠情報）を格納するのが公
文書保管ファイルＦ３である。

【００７４】法律事務所では、図１４に示すように、顧
客からの業務依頼の受付と分析（処理1401)、顧客への
業務提案(処理1402)、顧客の意志の確認(処理1403)、顧
客の業務の遂行(処理1404)から構成される。実際に顧客
の公文書業務を受けるかどうかの分析は、業務内容、業
務の委託報酬等の条件から決めることになるが、この点
については法律事務所のポリシーによるためここでは説
明しない。

【００７５】処理1401は図２での身分証明書の引替え証
の発行処理(処理202)、処理1402は図４の身分証明書の
配布処理(処理403)と図６の公文書管理業務の受付処理
(処理603)に対応し、顧客が業務条件ＣＵ２を受理した
段階で処理1403が完了する。そして、処理1404は図６の
公文書の受付と保管（処理605)から業務条件ＣＵ２に従
った公文書業務の遂行(処理606)に対応している。

【００７６】法律事務所システム内でのアクセス制御を
管理するためには、担当者を明確にすること、及び公文
書保管ファイルＦ３に保管した公文書へのアクセスを限
定することが特に重要である。

【００７７】

【発明の効果】以上説明したように、本発明の公文書管
理システムによれば、利用者の業務条件に合わせて、利
用者のメッセージを公文書業務管理サーバに保管、公
開、及び破棄するペーパーレスなサービスを提供できる
という効果がある。

【図面の簡単な説明】

【図１】本発明の一実施例を示す法律事務所システム及
びネットワークシステム構成を示す図である。

【図２】利用者Ｕ１が身分証明書発行サーバＳ１に対し
て、身分証明書ＰＵ１の発行を要求する処理のシーケン
スを示す図である。

【図３】セキュリティ管理プログラムＳＰ_U1がＵ１の秘
密鍵と身分証明書発行サーバＳ１の公開鍵を用いて、身
分証明書の発行要求を暗号化することにより、ＳＰ_U1と
Ｓ１の間の通信を保護する処理のフローチャートであ
る。

【図４】身分証明書発行サーバＳ１が身分証明書管理サ
ーバＳ２に対して利用者Ｕ１の身分証明書発行要求を登
録する処理，Ｕ１がＳ２に対して身分証明書ＰＵ１を取
得要求する処理、及びＳ２がＵ１に対してＰＵ１を配布
する処理のシーケンスを示す図である。

【図５】セキュリティ管理プログラムＳＰ_U1がＵ１の秘
密鍵と身分証明書管理サーバＳ２の公開鍵を用いて、身
分証明書の取得要求を暗号化することにより、ＳＰ_U1と
Ｓ２の間の通信を保護する処理のフローチャートであ
る。

【図６】利用者Ｕ１が公文書業務管理サーバＳ３に対し
て、公文書管理業務を要求する処理のシーケンスを示す
図である。

【図７】利用者Ｕ１から公文書業務管理サーバＳ３に対
する、メッセージＭ１の業務条件ＣＵ２の一例を示す図
である。

【図８】セキュリティ管理プログラムＳＰ_U1が公文書業
務管理サーバＳ３に対して、送信するメッセージＭ２を
作成する処理、Ｓ３で受信したメッセージ及び証拠情報
を確認する処理のフローチャートである。

【図９】公文書業務管理サーバＳ３が利用者Ｕ１から受
信したメッセージＭ２を公文書保管ファイルＦ３に保管
し、業務条件ＣＵ２に基づき公開又は破棄する処理のフ
ローチャートである。

【図１０】公文書業務管理サーバＳ３が証拠情報Ｅ１及
びＥ２を確認する処理のフローチャートである。

【図１１】公文書業務管理サーバＳ３が利用者Ｕ３に対
して、業務依頼されていたメッセージＭ１を公開する処
理のフローチャートである。

【図１２】公文書業務管理サーバＳ３によるセキュリテ
ィ監査機能の処理を示す図である。

【図１３】公文書業務管理サーバＳ３による公的機関サ
ーバへのメッセージを登録する処理のシーケンスを示す
図である。

【図１４】実際の法律事務所での公文書業務の流れを法
律事務所のサーバの処理と対応させたフローチャートで
ある。

【符号の説明】

ＮネットワークシステムＳ１，Ｓ２，Ｓ３，Ｓ４サーバＷＳ１０，ＷＳ２０，ＷＳ３０端末Ｕ１，Ｕ２，Ｕ３利用者ＳＰ_U1 セキュリティ管理プログラムＰＵ１利用者Ｕ１の身分証明書ＰＵ１’ ＰＵ１の引替え証Ｉ，Ｉ_U1 情報ＰＫ_U1，ＰＫ_U3，ＰＫ_S1，ＰＫ_S2，ＰＫ_S3 公開鍵ＳＫ_U1，ＳＫ_U3，ＳＫ_S1，ＳＫ_S2，ＳＫ_S3 秘密鍵公開鍵ＤＢデータベースＦ１身分証明書ファイルＦ２利用者情報ファイルＦ３公文書保管ファイルＳＳＫ１，ＳＳＫ２，ＳＳＫ３セション鍵ＣＵ１，ＣＵ２条件Ａｕ，Ａｃ，Ｉｎ，Ｃｎ，Ｎｒ，Ａｄメッセ−ジ保護
レベルＥＮＣ暗号化関数ＤＥＣ復号化関数Ｈハッシュ関数Ｅ１，Ｅ２，Ｅ１’，Ｅ２’，Ｅ２” 証拠情報Ｍ，Ｍ１，Ｍ２，Ｍ３，Ｍ１’，Ｍ１” メッセ−ジＴ０，Ｔ１，Ｔ２，Ｔ３，Ｔ４，Ｔ０” 日時情報

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号庁内整理番号ＦＩ技術表示箇所Ｈ０４Ｌ 9/12

Claims

【特許請求の範囲】

【請求項１】公文書保管ファイルと利用者情報ファイル
を含み、前記利用者情報ファイルに指定された条件に応
じて前記公文書保管ファイルの公文書を公開及び破棄す
る管理手段を有する公文書業務管理サーバと、前記公文
書保管ファイルの公文書に関する情報を前記公文書業務
管理サーバとの間で送受信する端末と前記端末の利用者
の身分証明書ファイルを含み、前記利用者の身元を管理
する身分証明書発行／管理サーバを備えることを特徴と
するペーパーレス公文書管理システム。
【請求項２】請求項１において、前記利用者のメッセー
ジを公文書として第三者機関に登録する手段と、前記公
文書を他の何者にも見られないように秘匿する手段と、
前記公文書を他の何者にもねつ造されないような形式に
変換する手段と、前記公文書に関する取引の証拠情報を
作成する手段と、システム内の事象について履歴を取得
する手段と、前記履歴に基づいてセキュリティ侵害につ
いて監査する手段を含む公文書業務管理サーバを備える
ことを特徴とするペーパーレス公文書管理システム。
【請求項３】請求項１において、公文書業務の利用者の
身元を管理するために、前記利用者に対して身分証明書
を発行する手段と、前記身分証明書の内容の正当性を管
理する手段と、前記公文書業務管理サーバとの間で安全
に通信を行う手段を含む身分証明書発行／管理サーバを
備えることを特徴とするペーパーレス公文書管理システ
ム。
【請求項４】請求項１において、前記利用者が身分証明
書の発行を要求する手段と、前記利用者のメッセージを
前記公文書として第三者機関に登録することを要求する
手段と、前記公文書を他の何者にも見られないように秘
匿することを要求する手段と、前記公文書を他の何者に
もねつ造されないような形式に変換することを要求する
手段と、前記公文書に関する業務を要求する手段を実現
するアプリケーションインタフェースを前記利用者のア
プリケーションに提供することを特徴とするペーパーレ
ス公文書管理システム。