JP4062206B2

JP4062206B2 - 署名復号サービスシステム及びプログラム

Info

Publication number: JP4062206B2
Application number: JP2003284857A
Authority: JP
Inventors: 栄島村
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2003-08-01
Filing date: 2003-08-01
Publication date: 2008-03-19
Anticipated expiration: 2023-08-01
Also published as: JP2005057417A

Description

本発明は、ネットワークを介して電子文書を交換する技術に関し、特に、ASP(Application Service Provider)が提供する文書交換サービスを利用してビジネス文書を交換する際の信頼性を高いものにする電子文書交換技術に関する。

従来、ビジネス文書の交換にはファクシミリ、郵送、手渡しなどの方法がとられてきていた。近年、インターネットの発達により、このようなビジネス文書の交換に電子的な方法がとられるようになってきている。

更に、この２〜３年はRossettaNet(http://www.rosettanet.gr.jp/)、ebXML Messaging Service(http://www.oasis-open.org/)などのビジネス間連携を目的とした信頼性の高い文書交換のための国際標準も規定されており、ビジネス文書交換のための標準化活動が盛んである。

ビジネス間連携では、単純に信頼性の高い文書交換機能を提供するだけではなく、ユーザの業種、業態に応じた文書加工や取引に伴う一連の文書交換を行うためのビジネスプロセス処理機能を持ち、より複雑な企業間連携を実現することも出来る。

一般に、このようなビジネス間連携の実現を目的としたシステムに必要な設備やそのメンテナンスにかかるコストは非常に大きく、中小のユーザにとっては大きな負担となると考えられる。このため、こういったシステムに必要な設備を用意した業者が複数の中小のユーザと契約し、ネットワークを介して会員ユーザに対して比較的安価に文書交換サービスを提供するASP形態の運用が考えられる。

このASP形態の運用では、ユーザはWebブラウザなどの簡便な装置を介してASPサーバ上のビジネスプロセスサービスシステムを利用して、ビジネス文書の生成、予め規定された手順に沿った文書交換、文書の加工、データの抽出などを行う。

一方、電子ビジネス文書の交換の際に、なりすまし、文書の改竄を防ぐために、ユーザ端末において、電子文書に電子署名を付すということが従来から行われている（例えば、特許文献１、２参照）。
特開２０００−２０７４６６号公報特開２００２−９９８４３号公報

上記した特許文献１、２に記載されている従来の技術は、ユーザ端末に署名を行うための手段を設けなければならず、ユーザ端末の構成が複雑になるという問題がある。

また、ユーザ端末の構成を簡単にするために、ビジネスプロセスサービスシステムにおいて、署名を行うということも考えられるが、この場合には次のような問題が生じる。即ち、ユーザ自身の署名を行うためには、ユーザの秘密鍵が必要になる。従って、ASP業者によって運営されているビジネスプロセスサービスシステムにおいて署名を行う場合には、本来秘密にされるべき秘密鍵をASP業者に渡さなければならず、セキュリティ上好ましくない。一旦、秘密鍵をASP業者に渡してしまうと、ASP業者が、いかなる文書に対してもユーザから預かった秘密鍵で署名できるため、署名の信頼性に影響する。このような問題は、ユーザが複数のASP業者と契約し、ユーザに秘密鍵の配布範囲が広がった場合、特に深刻になる。

〔発明の目的〕
そこで、本発明の目的は、ユーザ端末の構成を複雑にすることなく、信頼性の高い認証が付されたビジネス文書を交換できるようにすることにある。

本発明にかかる第１の署名復号サービスシステムは、上記目的を達成するため、
ユーザIDと、該ユーザIDによって特定されるユーザの秘密鍵および連絡先とが登録された記憶部と、
ビジネスプロセスサービスシステムから送られてきたユーザIDと文書とを含んだ署名要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信する承認部と、
該承認部で受信した認証結果が秘密鍵の利用を許可していることを条件にして、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記署名要求中の文書に署名を行い、署名付きの文書を前記ビジネスプロセスサービスシステムに返信する要求処理部とを備えたことを特徴とする。

本発明にかかる第２の署名復号サービスシステムは、第１の署名復号サービスシステムにおいて、
前記記憶部には、前記ユーザID、前記秘密鍵および前記連絡先に加えて前記秘密鍵の利用を許可する条件である承認条件および前記秘密鍵の利用を拒絶する条件である拒絶条件が登録され、
前記ビジネスプロセスサービスシステムから送られてきた署名要求中のユーザIDを用いて前記記憶部を検索することにより承認条件および拒絶条件を取得し、前記署名要求が前記承認条件あるいは前記拒絶条件を満たしているか否かを判断する事前承認部を備え、
前記承認部の代わりに、前記事前承認部において前記署名要求が前記承認条件も前記拒絶条件も満たしていないと判断された場合、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して前記署名要求を処理するために必要になる秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信する逐次承認部を備え、
前記要求処理部が、前記事前承認部において前記署名要求が前記承認条件を満たしていると判断された場合および前記逐次承認部で受信した認証結果が前記署名要求に対して秘密鍵の使用を許可している場合、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記署名要求中の文書に署名を行い、署名付きの文書を前記ビジネスプロセスサービスシステムに返信することを特徴とする。

本発明にかかる第３の署名復号サービスシステムは、第２の署名復号サービスシステムにおいて、
前記事前承認部が、前記ビジネスプロセスサービスシステムから送られてきた、ユーザIDと該ユーザIDによって特定されるユーザの公開鍵によって暗号化された文書とを含む復号要求中のユーザIDを用いて前記記憶部を検索することにより承認条件および拒絶条件を取得し、前記復号要求が前記承認条件あるいは前記拒絶条件を満たしているか否かを判断し、
前記逐次承認部が、前記事前承認部において前記復号要求が前記承認条件も前記拒絶条件も満たしていないと判断された場合、前記復号要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して前記復号要求を処理するために必要になる秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信し、
前記要求処理部が、前記事前承認部において前記復号要求が前記承認条件を満たしていると判断された場合および前記逐次承認部で受信した認証結果が前記復号要求に対して秘密鍵の使用を許可している場合、前記復号要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記復号要求中の暗号化された文書を復号し、復号済みの文書を前記ビジネスプロセスサービスシステムに返信することを特徴とする。

第１の効果は、ユーザ端末の構成を複雑にすることなく、信頼性の高い認証が付されたビジネス文書を交換できるということにある。その理由は、ビジネス文書の生成や加工などを行う、ASP業者によって運営されるビジネスプロセスサービスシステムとは分離された署名復号サービスシステムにおいて、ユーザの秘密鍵を用いた署名処理を行うようにしているからである。また、ユーザが多くのビジネスプロセスサービスシステムを利用する場合であっても、署名復号サービスシステムだけに秘密鍵を預けておけば良いので、各ビジネスプロセスサービスシステムにユーザの秘密鍵を預ける場合に比較して、秘密鍵が漏洩したり、悪用される危険性を少なくすることができる。

第２の効果は、極めて信頼性の高い署名が付されたビジネス文書を交換できるということにある。その理由は、署名復号サービスシステムにおいて、ユーザの秘密鍵を用いてビジネス文書に対して署名を行う場合は、ユーザに許可を貰ってから署名を行うようにしているからである。

次に本発明の実施の形態について図面を参照して詳細に説明する。

〔第１の実施の形態〕
本発明の第１の実施の形態の構成について図1のブロック図を参照して説明する。図１に示すように、本実施の形態の電子文書交換システムは、複数台のユーザ端末１〜３と、複数台のビジネスプロセスサービスシステム10、20、30と、１台の署名復号サービスシステム100とから構成されている。そして、それらはインターネットなどのネットワーク上に、相互に接続可能な状態で分散配置されている。なお、ビジネスプロセスサービスシステム、署名復号サービスシステム、ユーザ端末は、図中の存在数に限定されるものではない。

ビジネスプロセスサービスシステム10、20は、ASP業者によって運営されているシステムであり、会員契約を結んでいる会員ユーザに対して、ビジネス文書の作成、加工機能を提供すると共に、標準化された共通インタフェース部を介して他のシステムとビジネス文書を送受信する。

このような機能を有するビジネスプロセスサービスシステム10は、例えば、コンピュータによって実現されるものであり、共通インタフェース部11と、ビジネス処理部12と、ユーザアクセス部13と、ユーザデータベース（ユーザDB）14と、文書交換部15とから構成されている。コンピュータによってビジネスプロセスサービスシステム10を実現する場合は、共通インタフェース部11、ビジネス処理部12、ユーザアクセス部13、ユーザDB14、文書交換部15を実現するためのプログラムを記録したディスク、半導体メモリなどの記録媒体を用意しておく。コンピュータは、この記録媒体に記録されたプログラムを読み込み、自コンピュータの動作を制御することにより、自コンピュータ上に共通インタフェース部11、ビジネス処理部12、ユーザアクセス部13、ユーザDB14、文書交換部15を実現する。

共通インタフェース部11は、他のシステムと通信に用いられる標準化されたインタフェース部であり、例えば、SOAP、ebXML、RossettaNetなどにより実現される。ユーザアクセス部13は、ユーザ端末１〜３との間でデータをやり取りする機能を有する。ビジネス処理部12は、ユーザからの要求に応じてビジネス文書を生成する機能や、生成したビジネス文書や受信したビジネス文書に基づいてビジネス処理を行う機能を有する。文書交換部15は、ビジネス文書の送受信を行う機能や、署名復号サービスシステム100に対して署名要求や復号要求を送信する機能を有する。ユーザDB14には、ビジネス処理に必要なユーザ情報が格納されている。図２は、ユーザDB14の内容例を示した図であり、会員契約を結んだ各会員ユーザのユーザIDに対応付けてその会員ユーザの公開鍵及びパスワードが登録されている。なお、ビジネスプロセスサービスシステム20も、ビジネスプロセスサービスシステム10と同様の構成を有している。

ビジネスプロセスサービスシステム30は、ユーザ端末１〜３の会員ユーザと取り引きを行う企業のシステムであり、ビジネスプロセスサービスシステム10と同様の構成を有している。

ユーザ端末１〜３は、ASP業者と会員契約を結んでいる会員ユーザの端末であり、例えば、Webブラウザを実装したパーソナルコンピュータなどによって実現される。ネットワーク上には、業種、業態によるビジネスプロセスの違いや、地域、言語の違いにより、ASP業者によって運営されている様々なビジネスプロセスサービスシステム（図１では、ビジネスプロセスサービスシステム10、20しか図示していない）が存在しており、ユーザは用途に合わせて適当なASP業者と会員契約を結ぶ。

署名復号サービスシステム100は、公的な認証機関によって一定の信頼性が保証されている機関によって運営されているシステムであり、会員ユーザの署名・復号に用いる秘密鍵を預かり、さまざまなビジネスプロセスサービスシステムからネットワークを介して送られてくるビジネス文書に対する署名・復号要求を標準化された共通インタフェース部101で受け付ける。そして、要求に基づき会員ユーザに署名もしくは復号の許可を求め、許可が得られた段階で該当処理を行いビジネスプロセスサービスシステムへビジネス文書を返す。

このような機能を有する署名復号サービスシステム100は、例えば、コンピュータによって実現されるものであり、共通インタフェース部101と、要求受理部102と、要求処理部103と、承認部104と、ユーザDB105とから構成されている。コンピュータによって署名復号サービスシステム100を実現する場合は、共通インタフェース部101、要求受理部102、要求処理部103、承認部104、ユーザDB105を実現するためのプログラムを記録したディスク、半導体メモリなどの記録媒体を用意しておく。コンピュータは、この記録媒体に記録されているプログラムを読み込み、自コンピュータの動作を制御することにより、自コンピュータ上に共通インタフェース部101、要求受理部102、要求処理部103、承認部104、ユーザDB105を実現する。

共通インタフェース部101は、他のシステムと通信に用いられる標準化されたインタフェース部である。要求受理部102は、ビジネスプロセスサービスシステム10、20、30からの署名要求または復号要求を受け付ける。承認部104は、要求受理部102が受け付けた署名要求または復号要求に従った処理を行う際、該当するユーザに対して秘密鍵の利用許可を求める機能を有する。要求処理部103は、要求受理部102が受け付けた署名要求または復号要求に従った署名処理または復号処理を行い、処理結果を要求元のビジネスプロセスサービスシステムに返す機能を有する。ユーザDB105には、署名処理や復号処理を行う際に使用するユーザに秘密鍵や、秘密鍵の利用許可を求める際の連絡先、連絡方法が格納されている。図３はユーザDB105の内容例を示す図であり、会員ユーザのユーザIDに対応付けて、そのユーザの秘密鍵と、秘密鍵の利用許可を求める際の連絡先と、連絡方法と、パスワードとが格納されている。

次に、本実施の形態の動作について詳細に説明する。ここでは、ある製品の見積依頼から在庫確認、発注までを行う場合を例に挙げて説明する。

自身のユーザ端末１からビジネスプロセスサービスシステム10に接続した会員ユーザは、ユーザ端末１上で動作するWebブラウザから処理要求を送信する。この処理要求には、見積依頼書の送信先（例えば、ビジネスプロセスサービスシステム30を示す情報）、見積依頼書に記載すべき項目（製品名、目標価格、購入希望個数など）、会員ユーザのユーザID、パスワード、署名が必要か否かを示す署名要否情報、暗号化が必要であるか否かを示す暗号化要否情報などが含まれている。

ビジネスプロセスサービスシステム10が、ユーザ端末１からの処理要求を受信すると、見積依頼処理が開始される（図４、P41）。この見積依頼処理（P41）においては、先ず、ユーザアクセス部13がユーザ端末１から送られてきた処理要求を受け付け、それに含まれているパスワードに基づいた認証処理を行い、認証ＯＫの場合は、処理要求をビジネス処理部12に渡す。ビジネス処理部12は、ユーザアクセス部13から渡された処理要求に基づいて見積依頼書（ビジネス文書）を生成し、生成した見積依頼書およびユーザ端末１からの処理要求を文書交換部15に渡す。

文書交換部15は、ビジネス処理部12から見積依頼書および処理要求が渡されると、図５のフローチャートに示す処理を行う。先ず、処理要求中の署名要否情報に基づいて、ユーザが署名を要求しているか否かを判断する（S51）。署名が要求されていない場合（S51がＮ）は、S54以下の処理を行う。署名が要求されている場合（S51がＹ）は、処理要求から送信元（ユーザ端末１）のユーザIDを取り出す(S52)。署名には該当ユーザの秘密鍵が必要であるため、共通インタフェース部11を介して署名復号サービスシステム100に対して署名を要求する署名要求600を送信し、署名復号サービスシステム100から署名の付された見積依頼書が返信されるのを待つ（S53）。

図６は、上記署名要求600の構成例を示す図であり、ユーザID601と、処理内容602と、処理対象文書603とを含む。この例の場合、ユーザID601にはユーザ端末１のユーザIDが、処理内容602には「署名」が、処理対象文書603には、ビジネス処理部12で生成された見積依頼書が設定される。

署名復号サービスシステム100は、ビジネスプロセスサービスシステム10からの署名要求600を受信すると、図７のフローチャートに示す処理を行う。要求受理部102は、ビジネスプロセスサービスシステム10からの署名要求を受け付けると、それを承認部104に渡す。承認部104は、署名要求600に含まれるユーザIDをキーにしてユーザDB105から該当ユーザを検索する。該当ユーザが存在する場合は、会員契約時にユーザDB105に登録された連絡方法で、秘密鍵の利用許可を求める認証要求をユーザ端末１に送信する(S71)。この連絡方法には電子メール、インスタントメッセージ、電話、Faxなどを用いることができる。ユーザ端末１のユーザは、認証要求が送られてくると、署名復号サービスシステム100の承認部104へアクセスし、ユーザDB105に登録してあるパスワードを入力して、署名要求の内容を確認し、承認もしくは拒絶する(S72)。

ユーザによって承認された場合は（S73がＹ）、要求受理部102は、署名要求600を要求処理部103に渡し、要求処理部103は、該当ユーザから預かっている秘密鍵をユーザDB105から取り出し、この秘密鍵を使用して署名要求600に含まれている見積依頼書に署名を行う(S74)。そして、署名を付した見積依頼書を要求元のビジネスプロセスサービスシステム10へ返信する(S76)。これに対して、ユーザが秘密鍵の使用を拒絶した場合（S73がＮ）は、エラー通知を作成し(S75)、要求元のビジネスプロセスサービスシステム10へ返信する(S76)。

ビジネスプロセスサービスシステム10内の文書交換部15は、署名復号サービスシステム10からエラー通知を受信した場合は、処理終了となる。これに対して、署名の付された見積依頼書を受信した場合には、図５のS54以下の処理を行う。

図５のS54では、送信文書（見積依頼書）に対して暗号化が必要か判定する(S54)。この判断は、ユーザ端末１から送られてきている処理要求中の暗号要否情報に基づいて行う。暗号化が必要ない場合（S54がＮ）は、S56以下の処理を行う。暗号化が必要な場合（S54がＹ）は、見積依頼書の送信先（この例の場合は、ビジネスプロセスサービスシステム30）の公開鍵を用いて見積依頼書を暗号化し（S55）、共通インタフェース部11を介してビジネスプロセスサービスシステム30へ送信する（S56）。以上が、図４の見積依頼処理（P41）で行われる処理である。

ビジネスプロセスサービスシステム30は、見積依頼書が送られてくると、見積書を生成し、生成した見積書を含む応答情報をビジネスプロセスサービスシステム10に返信する。その際、見積書をユーザ端末１の公開鍵で暗号化しても良いし、ビジネスプロセスサービスシステム30の秘密鍵を用いて署名を行っても良い。また、上記応答情報には、送信先（この例の場合は、ユーザ端末１）を示す情報や、ユーザ端末１のユーザIDや、復号が必要であるか否かを示す復号要否情報や、署名検証が必要であるか否かを示す署名検証要否情報も含まれる。

ビジネスプロセスサービスシステム10は、ビジネスプロセスサービスシステム30から見積書を含む応答情報が返信されてくると、見積受信処理を行う（図４、P42）。見積受信処理においては、先ず、ビジネスプロセスサービスシステム10内の文書交換部15が、共通インタフェース部11を介してビジネスプロセスサービスシステム30からの応答情報を受信し、復号要否情報に基づいて、復号が必要であるか否かを判断する（図８、S81）。そして、復号が必要ない場合（S81がＮ）は、S84以下の処理を行う。これに対して、復号が必要な場合（S81がＹ）は、応答情報から送信先（ユーザ端末１）のユーザIDを取り出す(S82)。復号には、該当ユーザの秘密鍵が必要であるため、署名復号サービスシステム100に対して復号要求を送信し、復号結果が送られてくるのを待つ（S83）。なお、復号要求には、送信先ユーザ（ユーザ端末１）のユーザIDと、送信先ユーザの公開鍵で暗号化されている見積書と、処理内容が「復号」であることを示す情報が含まれている。

署名復号サービスシステム100は、ビジネスプロセスサービスシステム10から復号要求が送られてくると、署名要求が送られてきた場合とほぼ同様の処理を行う（図７のS71〜S76）。但し、復号要求が送られてきた場合には、S74で署名処理を行う代わりに、該当ユーザの秘密鍵を使用して暗号化されている見積書を復号し、復号結果をビジネスプロセスサービスシステム10に返信する。

文書交換部15は、復号結果が返信されてくると、署名検証要否情報に基づいて、署名検証が必要であるか否かを判断する（S84）。そして、署名検証が不要であると判断した場合（S84がＮ）は、見積書をビジネス処理部12に渡して処理を終了する。これに対して、署名検証が必要な場合は、送信元（ビジネスプロセスサービスシステム30）の公開鍵を用いて署名検証を行う（S85）。そして、署名検証に成功した場合（S86がＹ）は、見積書をビジネスプロセスサービスシステム処理部12に渡して処理を終了する。これに対して、検証に失敗した場合（S86がＮ）は、エラー通知を送信元へ返信する(S87)。以上が、図４の見積受信処理（P42）で行われる処理である。

ビジネス処理部12は、文書交換部15から見積書が渡されると、それに記載されている見積価格が、ユーザ端末１のユーザによって指定されている目標価格以下であるか否かを判断する（図４、P43）。そして、見積価格が目標価格を上回る場合（P43がＮ）は、処理を終了する。逆に目標価格以下であればビジネス処理部12が、在庫確認書を生成し、文書交換部15が取引先のビジネスプロセスサービスシステム30に送信する(P44)。その際、見積依頼書を送信する場合と同様にして、在庫確認書に署名を付したり、暗号化する。

ビジネスプロセスサービスシステム30は、ビジネスプロセスサービスシステム10から在庫確認書が送られてくると、在庫通知書をビジネスプロセスサービスシステム10に返信する。その際、見積書を返信する場合と同様に、在庫通知書に署名を付したり、暗号化する。

ビジネスプロセスサービスシステム10内の文書交換部15は、在庫通知書を受信すると(P45)、ユーザ端末１に対して最終確認通知を出す(P46)。ユーザが、ユーザ端末１上で動作しているWebブラウザからユーザアクセス部13をアクセスし最終確認を行うと、ビジネス処理部12は自動的に発注書を生成し、文書交換部15を通じてビジネスプロセスサービスシステム30へ送信する(P47)。その後、ビジネスプロセスサービスシステム30から送られてくる、受注確認書をユーザ端末１へ送信する（P48)。

〔第２の実施の形態〕
次に、本発明の第２の実施の形態について説明する。本実施の形態は、会員ユーザが、秘密鍵の利用を承認する承認条件や、秘密鍵の利用を拒絶する拒絶条件を事前に署名復号サービスシステムに登録しておき、署名要求や復号要求がこれらの条件を満たす場合は、ユーザに認証要求を送ることなく、秘密鍵の利用を許可あるいは拒絶することを特徴とする。

図９は本実施の形態の全体構成を示すブロック図である。本実施の形態は、署名復号サービスシステム100の代わりに署名復号サービスシステム200を備えている点が図１に示した第１の実施の形態と相違している。

署名復号サービスシステム200は、共通インタフェース部201と、要求受理部202と、要求処理部203と、逐次承認部204と、ユーザDB205と、事前承認部206とを備えている。署名復号サービスシステム200は、例えば、コンピュータによって実現されるものであり、コンピュータによって署名復号サービスシステム200を実現する場合は、共通インタフェース部201、要求受理部202、要求処理部203、逐次承認部204、ユーザDB205、事前承認部206を実現するためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意しておく。コンピュータは、この記録媒体に記録されているプログラムを読み込み、自コンピュータの動作を制御することにより、自コンピュータ上に共通インタフェース部201、要求受理部202、要求処理部203、逐次承認部204、ユーザDB205、事前承認部206を実現する。

ユーザDB205は、ユーザDB105と同様に、各会員ユーザのユーザIDに対応付けて、署名処理や復号処理を行う際に使用するユーザの秘密鍵や、秘密鍵の利用許可を求める際の連絡先、連絡方法が格納されている。更に、ユーザDB205には、各会員ユーザのユーザIDに対応付けて、承認・拒絶条件が登録されている。この承認・拒絶条件は、各会員ユーザが事前承認部206を利用してユーザDB205に登録するものである。

図１０に承認・拒絶条件1000の構成例を示す。承認・拒絶条件1000は、承認条件1001と、拒絶条件1011とから構成される。承認条件1001は、署名、復号処理を自動承認する取引先1002と、自動承認操作の有効期限1003と、自動承認するビジネス内容1004と、署名、復号の内のどれを承認するかを示す処理内容1005とから構成される。拒絶条件1011は、署名、復号処理を拒絶する取引先1012と、自動拒絶操作の有効期限1013と、自動拒絶するビジネス内容1014と、署名、復号の内のどれを拒絶するかを示す処理内容1015とから構成される。

要求処理部203は、第１の実施の形態における要求処理部103と同様の機能を有する。

要求受理部202は、ビジネスプロセスサービスシステム10から署名要求あるいは復号要求が送られてきたとき、事前承認部206を使用して、上記要求が該当ユーザによってユーザDB205に事前登録されている承認条件、拒絶条件を満たしているか否かを判定する機能や、承認条件を満たしている場合は、上記要求を要求処理部203に渡し、拒絶条件を満たしている場合は、エラー通知をビジネスプロセスサービスシステム10に返信する機能を有する。更に、要求受理部202は、事前承認部206において、承認条件も拒絶条件も満たしていないと判定された場合は、逐次承認部204（第１の実施の形態の承認部104と同様の機能を有する）を使用して、該当する会員ユーザに対して秘密鍵の利用許可を求める認証要求を送信し、ユーザによって利用が許可された場合は、要求を処理要求部203に渡し、許可されなかった場合は、ビジネスプロセスサービスシステム10にエラー通知を行う機能を有する。

次に、本実施の形態の動作について説明する。なお、以下では、第１の実施の形態と相違点についてのみ説明する。

先ず、ビジネスプロセスサービスシステム10から署名要求が送られてきたときの、署名復号サービスシステム200の動作を説明する。

署名復号サービスシステム200内の要求受理部202は、ビジネスプロセスサービスシステム10からの署名要求（図６参照）を受け付けると、その要求を事前承認部206に渡す。これにより、事前承認部206は、上記署名要求に含まれているユーザIDをキーにしてユーザDB205を検索し、上記ユーザIDに対応付けて事前登録されている承認・拒絶条件1000を確認する（図１１、S111）。そして、署名要求が承認条件1001を満たす場合はS115以下の処理を行い、拒絶条件1011を満たす場合はS116以下の処理を行う。また、承認条件1001も拒絶条件1011も満たしていない場合（承認・拒絶条件1000が登録されていない場合も含む）は、S112以下の処理を行う。

承認条件1001も拒絶条件1011も満たしていない場合は、要求受理部202は、逐次承認部204に署名要求を渡し、逐次承認部204は、ユーザDB205に登録されている方法で、秘密鍵の利用許可を求める認証要求を該当するユーザ端末（ユーザ端末１とする）へ送信する（S112）。ユーザ端末１のユーザは、認証要求が送られてくると、署名復号サービスシステム200の逐次承認部204へアクセスし、登録されているパスワードを入力して、署名要求の内容を確認し、承認もしくは拒絶する（S113）。

ユーザ端末１のユーザによって承認された場合（S114がＹ）は、要求受理部202は、署名要求を要求処理部203に渡し、要求処理部203は該当ユーザから預かっている秘密鍵をユーザDB205から取り出し、取り出した秘密鍵を用いて、署名要求に含まれているビジネス文書に対して署名を行い（S115）、署名付きの電子文書をビジネスプロセスサービスシステム10に返信する（S117）。なお、S111において、承認条件を満たしていると判定された場合も、同様の処理が行われる。

これに対して、ユーザ端末１のユーザによって拒絶された場合（S114がＮ）は、エラー通知を作成し（S116）、ビジネスプロセスサービスシステム10に返信する（S117）。なお、S111で拒絶条件を満たしていると判定された場合も、同様の処理が行われる。

次に、復号要求を受信したときの署名復号サービスシステム200の動作について説明する。署名復号サービスシステム200は、ビジネスプロセスサービスシステム10から復号要求が送られてくると、署名要求が送られてきた場合とほぼ同様の処理を行う（図１１のS111〜S117）。但し、復号要求が送られてきた場合には、S115で署名処理を行う代わりに、該当ユーザの秘密鍵を使用して暗号化されているビジネス文書を復号し、復号結果をビジネスプロセスサービスシステム10に返信する。

〔第３の実施の形態〕
次に本発明の第３の実施の形態について説明する。本実施の形態は、署名処理、署名検証処理、暗号処理、復号処理を全て署名復号サービスシステムで行うことを特徴とする。

図１２は本実施の形態の全体構成を示すブロック図である。本実施の形態は、ビジネスプロセスサービスシステム10の代わりにビジネスプロセスサービスシステム40を備えている点、および署名復号サービスシステム200の代わりにビジネスプロセスサービスシステム300を備えている点が、図９に示した第２の実施の形態と相違している。

ビジネスプロセスサービスシステム40は、共通インタフェース部41と、ビジネス処理部42と、ユーザアクセス部43と、ユーザDB44と、文書交換部45とを備えている。ビジネスプロセスサービスシステム40は、例えば、コンピュータによって実現されるものであり、ビジネスプロセスサービスシステム40をコンピュータによって実現する場合には、共通インタフェース部41、ビジネス処理部42、ユーザアクセス部43、ユーザDB44、文書交換部45を実現するためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意しておく。コンピュータは、この記録媒体に記録されているプログラムを読み取り、自コンピュータの動作を制御することで、自コンピュータ上に、共通インタフェース部41、ビジネス処理部42、ユーザアクセス部43、ユーザDB44、文書交換部45を実現する。

共通インタフェース部41、ビジネス処理部42、ユーザアクセス部43、ユーザDB44は、第２の実施の形態における共通インタフェース部11、ビジネス処理部12、ユーザアクセス部13、ユーザDB14と同様の構成、機能を有している。

文書交換部45は、署名復号サービスシステム300に対して、署名要求、復号要求だけでなく、署名検証要求、暗号要求も送信する点が第２の実施の形態における文書交換部15と相違している。

署名復号サービスシステム300は、共通インタフェース部301と、要求受理部302と、要求処理部303と、逐次承認部304と、ユーザDB305と、事前承認部306とを備えている。署名復号サービスシステム300は、例えば、コンピュータによって実現されるものであり、署名復号サービスシステム300をコンピュータによって実現する場合には、共通インタフェース部301、要求受理部302、要求処理部303、逐次承認部304、ユーザDB305、事前承認部306を実現するためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意しておく。コンピュータは、この記録媒体に記録されているプログラムを読み取り、自コンピュータの動作を制御することで、自コンピュータ上に共通インタフェース部301、要求受理部302、要求処理部303、逐次承認部304、ユーザDB305、事前承認部306を実現する。

共通インタフェース部301、逐次承認部304、ユーザDB305、および事前承認部306は、第２の実施の形態における共通インタフェース部201、逐次承認部204、ユーザDB205、および事前承認部206と同様の機能を有する。

要求受理部302は、ビジネスプロセスサービスシステム40から署名要求、復号要求が送られてきた場合は、第２の実施の形態の要求受理部202と同様の処理を行う。また、ビジネスプロセスサービスシステム40から署名検証要求あるいは暗号要求が送られてきた場合は、それらを要求処理部303に渡す。

要求処理部303は、要求受理部302から署名要求、復号要求が送られてきた場合は、第２の実施の形態の要求処理部203と同様の処理を行う。また、ビジネスプロセスサービスシステム40から署名検証要求、暗号要求が送られてきた場合は、署名検証処理、暗号化処理を行う。

次に、本実施の形態の動作について説明する。

先ず、ユーザ端末（例えば、ユーザ端末１）からの処理要求をビジネスプロセスサービスシステム40が受信したときの動作について説明する。

ビジネスプロセスサービスシステム40内のビジネス処理部42は、ユーザアクセス部43が、ユーザ端末１からの処理要求を受け付けると、その処理要求に従ったビジネス文書を生成し、生成したビジネス文書およびユーザ端末１からの処理要求を文書交換部45に渡す。

文書交換部45は、ビジネス文書および処理要求が渡されると、先ず、処理要求中の署名要否情報に基づいてビジネス文書に署名が必要であるか否かを判断する（図１３、S131）。署名が必要ない場合（S131がＮ）は、S133以下の処理を行い、署名が必要な場合（S131がＹ）、署名要求を作成する(S132)。署名要求の構成例を図１４に示す。署名要求は、ユーザドキュメントの処理主体となるユーザID1401（この例の場合は、ユーザ端末１のユーザID）と、署名復号サービスシステム300との間であらかじめ取り決めた通信規約ID1042と、処理内容1403（署名要求の場合には「署名」が設定される）と、処理の対象となるビジネス文書1404とから構成される。なお、署名検証要求、復号化要求、暗号化要求の場合には、それぞれ処理内容1403に、「署名検証」、「復号」、「暗号」が設定される。

その後、暗号要否情報に基づいて、送信するビジネス文書に対して暗号化が必要か否かを判定する(S133)。暗号化が必要ない場合（S133がＮ）は、S135以下の処理を行う。暗号化が必要な場合（S133がＹ）は、暗号化要求を作成する(S134)。このとき、既に署名要求が存在する場合、暗号要求を追加する形で処理要求を作成する。つまり、処理内容1403に「署名、暗号」を設定する。

その後、署名、暗号要求が存在するか否かを調べる(S135)。存在しない場合（S135がＮ）は、S137以下を処理し、存在する場合（S135がＹ）は、署名・暗号化処理要求を署名復号サービスシステム300に送信し、結果を受信する(S136)。最終的にビジネス文書を、ユーザ端末１のユーザによって指定されている送信先（例えば、ビジネスプロセスサービスシステム30）へ送信する(S137)。

次に、ビジネスプロセスサービスシステム30からユーザ端末１宛の応答情報（見積書などのビジネス文書を含む）を受信したときのビジネスプロセスサービスシステム40の動作を、図１５を参照して説明する。

ビジネスプロセスサービスシステム40内の文書交換部45は、ビジネスプロセスサービスシステム30からユーザ端末１宛の応答情報を受信すると、それに含まれているビジネス文書の復号化が必要か否かを判定する(図１５、S151)。復号が必要ない場合（S151がＮ）は、S153以下の処理を行い、復号が必要な場合（S151がＹ）は、復号要求を作成する(S152)。

その後、受信したビジネス文書に対して、署名検証が必要か判定する(S153)。署名検証が必要ない場合（S153がＮ）は、S155以下の処理を行う。署名検証が必要な場合（S153がＹ）は、署名検証要求を作成する(S154)。このとき、既に復号要求が存在する場合、署名検証要求を追加する形で処理要求を作成する。

その後、復号・署名検証要求が存在するか調べる(S155)。存在しない場合（S155がＮ）は、処理を終了する。存在する場合（S155がＹ）は、復号・署名検証要求を署名復号サービスシステム300に送信し、結果を受信する(S156)。続いて、署名検証が要求された場合、署名検証が成功したかを判定する(S157)。失敗した場合（S157がＮ）は、エラー通知を送信元へ返信する(S158)。成功した場合（S157がＹ）は、処理を終了する。

次に、署名復号サービスシステム300の動作を、図１６を参照して説明する。

署名復号サービスシステム300内の要求受理部302は、ビジネスプロセスサービスシステム40から署名検証要求あるいは暗号化要求を受け取った場合（S161がＹ）、それを要求処理部303に渡す。要求処理部303は、署名検証要求が渡された場合は、それに含まれている、ビジネスプロセスサービスシステム30の秘密鍵によって署名が付されているビジネス文書に対する署名検証処理を、ビジネスプロセスサービスシステム30の公開鍵を用いて行い（S166）、その結果をビジネスプロセスサービスシステム40に返信する（S168）。また、暗号化要求が渡された場合は、それに含まれている、ビジネス処理部42によって生成されたビジネス文書をユーザ端末１の公開鍵で暗号化し（S166）、暗号化したビジネス文書をビジネスプロセスサービスシステム40に返信する（S168）。

また、要求受理部302は、署名要求あるいは復号要求を受け取った場合（S161がＮ）は、その要求を事前承認部306に渡す。これにより、事前承認部306は、上記要求に含まれているユーザIDをキーにしてユーザDB305を検索し、上記ユーザIDに対応付けて事前登録されている承認・拒絶条件を確認する（S162）。そして、要求が承認条件を満たす場合はS166以下の処理を行い、拒絶条件を満たす場合はS167以下の処理を行う。また、承認条件も拒絶条件も満たしていない場合（承認・拒絶条件が登録されていない場合も含む）は、S163以下の処理を行う。

承認条件も拒絶条件も満たしていない場合は、要求受理部302は、逐次承認部304に署名要求あるいは復号要求を渡し、逐次承認部304は、ユーザDB305に登録されている方法で、秘密鍵の利用許可を求める認証要求を該当するユーザ端末（ユーザ端末１とする）へ送信する（S163）。ユーザ端末１のユーザは、認証要求が送られてくると、署名復号サービスシステム300の逐次承認部304へアクセスし、登録されているパスワードを入力して、署名要求あるいは復号要求の内容を確認し、承認もしくは拒絶する（S164）。

ユーザ端末１のユーザによって承認された場合（S165がＹ）は、要求受理部302は、署名要求あるいは復号要求を要求処理部203に渡し、要求処理部303は該当ユーザから預かっている秘密鍵をユーザDB305から取り出し、取り出した秘密鍵を用いて、署名要求あるいは復号要求に含まれているビジネス文書に対して署名処理あるいは復号処理を行い（S166）、署名付きのビジネ文書あるいは復号済みのビジネス文書をビジネスプロセスサービスシステム40に返信する（S168）。なお、S162において、承認条件を満たしていると判定された場合も、同様の処理が行われる。

これに対して、ユーザ端末１のユーザによって拒絶された場合（S165がＮ）は、エラー通知を作成し（S167）、ビジネスプロセスサービスシステム40に返信する（S168）。なお、S162で拒絶条件を満たしていると判定された場合も、同様の処理が行われる。

本発明の第１の実施の形態の全体構成例を示すブロック図である。ユーザDB14の構成例を示す図である。ユーザDB105の構成例を示す図である。第１の実施の形態の処理例を示すフローチャートである。ビジネスプロセスサービスシステム１０がユーザ端末からの処理要求を受け付けたときの処理例を示すフローチャートである。署名要求の一例を示す図である。ビジネスプロセスサービスシステム１０がユーザ端末宛のビジネス文書を含む応答情報を受信したときの処理例を示すフローチャートである。署名復号サービスシステム100の処理例を示すフローチャートである。本発明の第２の実施の形態の全体構成例を示すブロック図である。承認・拒絶条件1000の一例を示す図である。署名復号サービスシステム200の処理例を示すフローチャートである。本発明の第３の実施の形態の全体構成を示すブロック図である。ビジネスプロセスサービスシステム40がユーザ端末からの処理要求を受け付けたときの処理例を示すフローチャートである。ビジネスプロセスサービスシステム40から署名復号サービスシステム301へ送信される要求の構成例を示す図である。ビジネスプロセスサービスシステム40がユーザ端末宛のビジネス文書を含む応答情報を受信したときの処理例を示すフローチャートである。署名復号サービスシステム300の処理例を示すフローチャートである。

符号の説明

１〜３…ユーザ端末
10、20、30、40…ビジネスプロセスサービスシステム
11、21、31、41…共通インタフェース部
12、42…ビジネス処理部
13、43…ユーザアクセス部
14、44…ユーザDB
15、45…文書交換部
100、200、300…署名復号サービスシステム
101、201、301…共通インタフェース部
102、202、302…要求受理部
103、203、303…要求処理部
104…承認部
105、205、305…ユーザDB
204、304…逐次承認部
206、306…事前承認部

Claims

ユーザIDと、該ユーザIDによって特定されるユーザの秘密鍵および連絡先とが登録された記憶部と、
ビジネスプロセスサービスシステムから送られてきたユーザIDと文書とを含んだ署名要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信する承認部と、
該承認部で受信した認証結果が秘密鍵の利用を許可していることを条件にして、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記署名要求中の文書に署名を行い、署名付きの文書を前記ビジネスプロセスサービスシステムに返信する要求処理部とを備えたことを特徴とする署名復号サービスシステム。
請求項１記載の署名復号サービスシステムにおいて、
前記記憶部には、前記ユーザID、前記秘密鍵および前記連絡先に加えて前記秘密鍵の利用を許可する条件である承認条件および前記秘密鍵の利用を拒絶する条件である拒絶条件が登録され、
前記ビジネスプロセスサービスシステムから送られてきた署名要求中のユーザIDを用いて前記記憶部を検索することにより承認条件および拒絶条件を取得し、前記署名要求が前記承認条件あるいは前記拒絶条件を満たしているか否かを判断する事前承認部を備え、
前記承認部の代わりに、前記事前承認部において前記署名要求が前記承認条件も前記拒絶条件も満たしていないと判断された場合、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して前記署名要求を処理するために必要になる秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信する逐次承認部を備え、
前記要求処理部が、前記事前承認部において前記署名要求が前記承認条件を満たしていると判断された場合および前記逐次承認部で受信した認証結果が前記署名要求に対して秘密鍵の使用を許可している場合、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記署名要求中の文書に署名を行い、署名付きの文書を前記ビジネスプロセスサービスシステムに返信することを特徴とする署名復号サービスシステム。
請求項２記載の署名復号サービスシステムにおいて、
前記事前承認部が、前記ビジネスプロセスサービスシステムから送られてきた、ユーザIDと該ユーザIDによって特定されるユーザの公開鍵によって暗号化された文書とを含む復号要求中のユーザIDを用いて前記記憶部を検索することにより承認条件および拒絶条件を取得し、前記復号要求が前記承認条件あるいは前記拒絶条件を満たしているか否かを判断し、
前記逐次承認部が、前記事前承認部において前記復号要求が前記承認条件も前記拒絶条件も満たしていないと判断された場合、前記復号要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して前記復号要求を処理するために必要になる秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信し、
前記要求処理部が、前記事前承認部において前記復号要求が前記承認条件を満たしていると判断された場合および前記逐次承認部で受信した認証結果が前記復号要求に対して秘密鍵の使用を許可している場合、前記復号要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記復号要求中の暗号化された文書を復号し、復号済みの文書を前記ビジネスプロセスサービスシステムに返信することを特徴とする署名復号サービスシステム。
ユーザIDと、該ユーザIDによって特定されるユーザの秘密鍵および連絡先とが登録された記憶部を備えたコンピュータを、
ビジネスプロセスサービスシステムから送られてきたユーザIDと文書とを含んだ署名要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信する承認部、
該承認部で受信した認証結果が秘密鍵の利用を許可していることを条件にして、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記署名要求中の文書に署名を行い、署名付きの文書を前記ビジネスプロセスサービスシステムに返信する要求処理部として機能させるためのプログラム。
請求項４記載のプログラムにおいて、
前記記憶部には、前記ユーザID、前記秘密鍵および前記連絡先に加えて前記秘密鍵の利用を許可する条件である承認条件および前記秘密鍵の利用を拒絶する条件である拒絶条件が登録され、且つ、
前記コンピュータを、
前記ビジネスプロセスサービスシステムから送られてきた署名要求中のユーザIDを用いて前記記憶部を検索することにより承認条件および拒絶条件を取得し、前記署名要求が前記承認条件あるいは前記拒絶条件を満たしているか否かを判断する事前承認部として機能させると共に、
前記承認部の代わりに、前記事前承認部において前記署名要求が前記承認条件も前記拒絶条件も満たしていないと判断された場合、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して前記署名要求を処理するために必要になる秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信する逐次承認部として機能させ、
前記要求処理部が、前記事前承認部において前記署名要求が前記承認条件を満たしていると判断された場合および前記逐次承認部で受信した認証結果が前記署名要求に対して秘密鍵の使用を許可している場合、前記署名要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記署名要求中の文書に署名を行い、署名付きの文書を前記ビジネスプロセスサービスシステムに返信することを特徴とするプログラム。
請求項５記載のプログラムにおいて、
前記事前承認部が、前記ビジネスプロセスサービスシステムから送られてきた、ユーザIDと該ユーザIDによって特定されるユーザの公開鍵によって暗号化された文書とを含む復号要求中のユーザIDを用いて前記記憶部を検索することにより承認条件および拒絶条件を取得し、前記復号要求が前記承認条件あるいは前記拒絶条件を満たしているか否かを判断し、
前記逐次承認部が、前記事前承認部において前記復号要求が前記承認条件も前記拒絶条件も満たしていないと判断された場合、前記復号要求中のユーザIDを用いて前記記憶部を検索することにより連絡先を取得し、該取得した連絡先に対して前記復号要求を処理するために必要になる秘密鍵の利用許可を求める認証要求を送信し、該認証要求に対する認証結果を受信し、
前記要求処理部が、前記事前承認部において前記復号要求が前記承認条件を満たしていると判断された場合および前記逐次承認部で受信した認証結果が前記復号要求に対して秘密鍵の使用を許可している場合、前記復号要求中のユーザIDを用いて前記記憶部を検索することにより秘密鍵を取得し、該取得した秘密鍵を用いて前記復号要求中の暗号化された文書を復号し、復号済みの文書を前記ビジネスプロセスサービスシステムに返信することを特徴とするプログラム。