(57)【要約】【課題】  ユーザがASPによって運営されるビジネスプロセスサービスシステムを利用して、ビジネス文書の作成、加工、交換などを行う場合、ユーザ端末の構成を複雑にすることなく、信頼性の高い署名の付されたビジネス文書を交換できるようにする。【解決手段】  ビジネスプロセスサービスシステム10は、ユーザ端末１からの処理要求に従って、見積依頼書等のビジネス文書を作成し、作成したビジネス文書を含む署名要求を署名復号サービスシステム100へ送信する。これにより、署名復号サービスシステム100は、ユーザ端末１に対して、秘密鍵の利用許可を求め、許可された場合のみ、ユーザ端末１の秘密鍵を用いて署名を行い、署名を付したビジネス文書をビジネスプロセスサービスシステム10に返却する。ビジネスプロセスサービスシステム10は、署名付きのビジネス文書をユーザ端末１によって指定されている送信先へ送信する。【選択図】      図１
2005057417.tif 000002
【特許請求の範囲】
【請求項１】
ビジネスプロセスサービスシステムと、署名復号サービスシステムとを含む電子文書交換システムであって、
前記ビジネスプロセスサービスシステムが、
会員ユーザからの要求に従ってビジネス文書を生成するビジネス処理部と、
該ビジネス処理部で生成されたビジネス文書と前記会員ユーザのユーザIDとを含む署名要求を前記署名復号サービスシステムに送信し、該署名要求に応答して前記署名復号サービスシステムから返信されてきた署名付きのビジネス文書を前記会員ユーザによって指定されている送信先に送信する文書交換部とを備え、
前記署名復号サービスシステムが、
前記ビジネスプロセスサービスシステムから署名要求が送られてきたとき、該署名要求中のユーザIDによって特定される秘密鍵を用いて前記署名要求中のビジネス文書に署名を行い、署名付きのビジネス文書を前記ビジネスプロセスサービスシステムに返信する要求処理部を備えたことを特徴とする電子文書交換システム。
【請求項２】
請求項１記載の電子文書交換システムにおいて、
前記文書交換部が、
前記署名復号サービスシステムから返信されてきた署名付きのビジネス文書を、その送信先の公開鍵を用いて暗号化した後、送信する構成を有することを特徴とする電子文書交換システム。
【請求項３】
請求項２記載の電子文書交換システムにおいて、
前記文書交換部が、
前記会員ユーザの公開鍵を用いて暗号化されたビジネス文書を受信したとき、該ビジネス文書と、前記会員ユーザのユーザIDとを含む復号要求を前記署名復号サービスシステムへ送信する構成を有し、
前記要求処理部が、
前記ビジネスプロセスサービスシステムから復号要求が送られてきたとき、該復号要求中のユーザIDによって特定される秘密鍵を用いて前記復号要求中の暗号化されたビジネス文書を復号し、復号済みのビジネス文書を前記ビジネスプロセスサービスシステムに返信する構成を有することを特徴とする電子文書交換システム。
【請求項４】
請求項３記載の電子文書交換システムにおいて、
前記文書交換部が、
送信元の秘密鍵を用いて署名の付されたビジネス文書を受信したとき、該ビジネス文書の送信元の公開鍵を用いて署名検証を行う構成を有することを特徴とする電子文書交換システム。
【請求項５】
請求項４記載の電子文書交換システムにおいて、
前記署名復号サービスシステムが、
前記ビジネスプロセスサービスシステムから署名要求あるいは復号要求が送られてきたとき、前記署名要求あるいは復号要求を処理するため秘密鍵を所有しているユーザに対して、秘密鍵の利用許可を求める認証要求を送信し、該認証要求に応答して前記ユーザから送られてくる認証結果を受信する承認部を備え、且つ、
前記要求処理部が、
前記承認部で受信した認証結果が秘密鍵の利用を許可していることを条件にして、前記署名要求あるいは前記復号要求に従った処理を行う構成を有することを特徴とする電子文書交換システム。
【請求項６】
請求項４記載の電子文書交換システムにおいて、
前記署名復号サービスシステムが、
前記ビジネスプロセスサービスシステムから署名要求あるいは復号要求が送られてきたとき、該署名要求あるいは該復号要求を処理するための秘密鍵を所有しているユーザによって事前に定義されている承認条件を満たしているか否かを判断すると共に、前記ユーザによって事前に定義されている拒絶条件を満たしているか否かを判断する事前承認部と、
該事前承認部において前記承認条件も前記拒絶条件も満たしていないと判断された場合、前記ユーザに対して秘密鍵の利用許可を求める認証要求を送信し、該認証要求に応答して前記ユーザから送られてくる認証結果を受信する逐次承認部とを備え、且つ、
前記要求処理部が、
前記事前承認部で承認条件が満たされていると判断された場合および前記逐次承認部で受信した認証結果が秘密鍵の使用を許可している場合、前記署名要求あるいは前記復号要求に従った処理を行う構成を有することを特徴とする電子文書交換システム。
【請求項７】
ビジネスプロセスサービスシステムと署名復号サービスシステムとを含む電子文書交換システムであって、
前記ビジネスプロセスサービスシステムが、
会員ユーザからの要求に従ってビジネス文書を生成するビジネス処理部と、
該ビジネス処理部で生成されたビジネス文書と、前記会員ユーザのユーザIDとを含む署名・暗号化要求を前記署名復号サービスシステムへ送信し、該署名・暗号化要求に応答して前記署名復号サービスシステムから返信されてきた暗号化され且つ署名の付されたビジネス文書を前記会員ユーザによって指定された送信先に送信する文書交換部とを備え、
前記署名復号サービスシステムが、
前記ビジネスプロセスサービスシステムから署名・暗号化要求が送られてきたとき、前記署名・暗号化要求中のユーザIDによって特定される秘密鍵を用いて前記署名・暗号化要求中のビジネス文書に対して署名を行うと共に、前記ビジネス文書の送信先の公開鍵を用いて暗号化を行い、その結果を前記ビジネスプロセスサービスシステムに返信する要求処理部を備えたことを特徴とする電子文書交換システム。
【請求項８】
請求項７記載の電子文書交換システムにおいて、
前記文書交換部が、
前記会員ユーザの公開鍵により暗号化され且つ送信元の秘密鍵により署名の付されたビジネス文書を受信したとき、該ビジネス文書と、前記会員ユーザのユーザIDとを含む復号・署名検証要求を前記署名復号サービスシステムへ送信する構成を有し、
前記署名復号サービスシステムが、
前記ビジネスプロセスサービスシステムから復号・署名検証要求が送られてきたとき、該復号・署名検証要求中のユーザIDによって特定される秘密鍵を用いて前記復号・署名検証要求中のビジネス文書を復号し、該ビジネス文書の送信先の公開鍵を用いて署名検証を行う構成を有することを特徴とする電子文書交換システム。
【請求項９】
会員ユーザからの要求に従ってビジネス文書を生成するビジネス処理部と、該ビジネス処理部で生成されたビジネス文書と前記会員ユーザのユーザIDとを含む署名要求を署名復号サービスシステムに送信し、該署名要求に応答して前記署名復号サービスシステムから返信されてきた署名付きのビジネス文書を前記会員ユーザによって指定されている送信先に送信する文書交換部とを備えたビジネスプロセスサービスシステムから署名要求が送られてきたとき、該署名要求中のユーザIDによって特定される秘密鍵を用いて前記署名要求中のビジネス文書に署名を行い、署名付きのビジネス文書を前記ビジネスプロセスサービスシステムに返信する要求処理部を備えたことを特徴とする署名復号サービスシステム。
【請求項１０】
コンピュータを、
会員ユーザからの要求に従ってビジネス文書を生成するビジネス処理部と、該ビジネス処理部で生成されたビジネス文書と前記会員ユーザのユーザIDとを含む署名要求を署名復号サービスシステムに送信し、該署名要求に応答して前記署名復号サービスシステムから返信されてきた署名付きのビジネス文書を前記会員ユーザによって指定されている送信先に送信する文書交換部とを備えたビジネスプロセスサービスシステムから署名要求が送られてきたとき、該署名要求中のユーザIDによって特定される秘密鍵を用いて前記署名要求中のビジネス文書に署名を行い、署名付きのビジネス文書を前記ビジネスプロセスサービスシステムに返信する要求処理部として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して電子文書を交換する技術に関し、特に、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によって特定される秘密鍵を用いて前記復号・署名検証要求中のビジネス文書を復号し、該ビジネス文書の送信先の公開鍵を用いて署名検証を行う構成を有することを特徴とする。
【発明の効果】
【００１９】
第１の効果は、ユーザ端末の構成を複雑にすることなく、信頼性の高い認証が付されたビジネス文書を交換できるということにある。その理由は、ビジネス文書の生成や加工などを行う、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…事前承認部
【図１】
2005057417.tif 000003
【図２】
2005057417.tif 000004
【図３】
2005057417.tif 000005
【図４】
2005057417.tif 000006
【図５】
2005057417.tif 000007
【図６】
2005057417.tif 000008
【図７】
2005057417.tif 000009
【図８】
2005057417.tif 000010
【図９】
2005057417.tif 000011
【図１０】
2005057417.tif 000012
【図１１】
2005057417.tif 000013
【図１２】
2005057417.tif 000014
【図１３】
2005057417.tif 000015
【図１４】
2005057417.tif 000016
【図１５】
2005057417.tif 000017
【図１６】
2005057417.tif 000018