(57)【要約】【課題】企業間電子商取引等の電子データ交換システムにおいて、通信代行者が通信委託者に替わって通信先へ電子データを送信する場合に、通信代行者の送信するメッセージに通信委託者の電子署名を安全に付与する。【解決手段】通信委託者計算機０１１２は、交換データの通信先計算機０１１３への転送を依頼するため、通信代行サーバ０１１１にデータ転送要求（ＭＳ１）を送信する。通信代行サーバはＭＳ１のダイジェスト値を計算し、通信委託者計算機０１１２にダイジェスト値を含む署名要求（ＭＳ２）を返信する。通信委託者計算機はダイジェスト値を用いて通信委託者の電子署名値を計算し署名データ（ＭＳ３）を通信代行サーバへ返送する。通信代行サーバは電子署名値を送信メッセージに付与し、署名付き標準形式メッセージ（Ｍα）を通信先計算機へ転送する。署名要求には通信代行者の電子署名を付与する事で、署名要求事実を通信代行者が否認出来ないようにする。【選択図】                図３
2005033396.tif 000002
【特許請求の範囲】
【請求項１】
通信代行者計算機を介して通信ネットワークで接続された通信委託者計算機と通信先計算機とが通信代行者計算機を中継して相互にデータ交換を行うデータ交換システムにおいて、通信委託者計算機と通信代行者計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第一形式とし、通信代行者計算機と通信先計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第二形式とし、
通信委託者計算機から通信代行者計算機へ第一形式のメッセージとして送信した交換データを、通信代行者計算機にて第二形式のメッセージに変換して通信先計算機へ送信する場合に、該第二形式のメッセージに公開鍵暗号に基づく通信委託者の電子署名を付与する署名生成方法であって、
通信代行者計算機にて、該第二形式のメッセージに対するダイジェスト値を求める第１のステップと、該ダイジェスト値を含む署名要求メッセージを通信委託者計算機へ送信する第２のステップと、
通信委託者計算機にて、該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する電子署名値を求める第３のステップと、該電子署名値を含む署名データメッセージを通信代行者計算機へ送信する第４のステップと、
通信代行者計算機にて、該電子署名値を用いて該第二形式のメッセージに通信委託者の電子署名を付与する第５のステップと、を含むことを特徴とする署名生成方法。
【請求項２】
請求項１記載の署名生成方法において、
前記第２のステップにおいて前記署名要求メッセージを通信委託者へ送信する前に、通信代行者の電子署名を該署名要求メッセージに付与することを特徴とする署名生成方法。
【請求項３】
請求項２記載の署名生成方法において、
前記通信代行者計算機は、前記受信した第一形式のメッセージに対するダイジェスト値を求め、該ダイジェスト値を前記署名要求メッセージに含めることを特徴とする署名生成方法。
【請求項４】
通信代行者計算機を介して通信ネットワークで接続された通信委託者計算機と通信先計算機とが通信代行者計算機を中継して相互にデータ交換を行い、通信委託者計算機と通信代行者計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第一形式とし、通信代行者計算機と通信先計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第二形式とし、
通信委託者計算機から通信代行者計算機へ第一形式のメッセージとして送信した交換データを、通信代行者計算機にて第二形式のメッセージに変換して通信先計算機へ送信する場合に、該第二形式のメッセージに公開鍵暗号に基づく通信委託者の電子署名を付与するデータ交換システムであって、
通信代行者計算機は、該第二形式のメッセージに対するダイジェスト値を求める手段と、該ダイジェスト値を含む署名要求メッセージを通信委託者計算機へ送信する手段を有し、
通信委託者計算機は、該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する電子署名値を求める手段と、該電子署名値を含む署名データメッセージを通信代行者計算機へ送信する手段を有し、
通信代行者計算機は、該電子署名値を用いて該第二形式のメッセージに通信委託者の電子署名を付与する手段を有することを特徴とするデータ交換システム。
【請求項５】
請求項４記載のデータ交換システムにおいて、
通信代行者計算機は、前記署名要求メッセージを通信委託者へ送信する前に、通信代行者の電子署名を該署名要求メッセージに付与する手段を有することを特徴とするデータ交換システム。
【請求項６】
請求項５記載のデータ交換システムにおいて、
前記通信代行者計算機は、前記受信した第一形式のメッセージに対するダイジェスト値を求め、該ダイジェスト値を前記署名要求メッセージに含める手段を有することを特徴とするデータ交換システム。
【請求項７】
交換データを第一形式のメッセージとして通信代行者計算機へ送信する手順と、
通信代行者計算機から、第一形式のメッセージを変換した第二形式のメッセージのダイジェスト値を含む署名要求メッセージを受信する手順と、
該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する通信委託者の電子署名値を求める手順と、
該電子署名値を含む署名データメッセージを通信代行者計算機へ送信する手順をコンピュータに実行させるための通信委託者計算機用プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項８】
通信委託者計算機から交換データを第一形式のメッセージとして受信する手順と、
該受信した交換データを第二形式のメッセージに変換する手順と、
変換後の第二形式のメッセージに対するダイジェスト値を求める手順と、
該ダイジェスト値を含む署名要求メッセージを作成する手順と、
該作成した署名要求メッセージを通信委託者計算機に送信する手順と、
通信委託者計算機から、該署名要求メッセージに対する応答である電子署名値を受信する手順と、
該電子署名値を用いて前記第二形式のメッセージに通信委託者の電子署名を付与する手順をコンピュータに実行させるための通信代行者計算機用プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信ネットワーク上に接続された計算機システム間でのデータ交換に関する。特に、特定の通信プロトコルに準拠したデータ交換を代行する通信代行サービスに関するもので、有効な適用分野として企業間電子商取引等が挙げられる。
【０００２】
【従来の技術】
インターネット等のオープンな通信ネットワーク上に接続された計算機システム間でのデータ交換においては、通信データの機密保護や改竄防止、通信相手の認証、通信データの送受信に関する否認防止、等のセキュリティ上の要件が重要となる。
特に、企業間電子商取引の場合、受発注取引等の重要なデータ交換される場合、これらのセキュリティ要件は必須といえる。
こうしたセキュリティ上の課題を解決する技術として、一般に公開鍵暗号（ＰＫＩ）技術が普及している。
例えば、電子署名において用いられる技術として、暗号アルゴリズムとしてはＲＳＡ暗号（例えば、非特許文献１参照）やＤＳＡ暗号等が、ダイジェスト値計算アルゴリズムとしてはＭＤ５（例えば、非特許文献２参照）やＳＨＡ−１などが一般的に普及しており、本発明においてもこれらの技術を適用可能である。
【０００３】
データ交換時のセキュリティ要件に対する公開鍵暗号の応用技術としては、ＴＬＳ（例えば、非特許文献３参照）の様に通信路に対してセキュリティ機能を提供するものや、Ｓ／ＭＩＭＥ（例えば、非特許文献４参照）や  ＸＭＬ  電子署名（例えば、非特許文献５参照）の様に通信路を通して交換されるデータを格納したメッセージに対して電子署名や暗号化を行う技術がある。
また、メッセージをパッケージするための形式としてはＭＩＭＥ形式がある（例えば、非特許文献６参照）。
特に、メッセージに対する暗号化や電子署名は、データ交換時のみでなくその後も継続的にセキュリティの効果が得られるのが特長であり、例えば、後日取引文書の内容に関して取引相手が否認出来ない様にする事が可能である。
また近年、オープンなネットワーク環境であるインターネットを利用した企業間電子商取引（Ｂ２Ｂ）の実現が進んでおり、ＲｏｓｅｔｔａＮｅｔ（例えば、非特許文献７参照）や  ｅｂＸＭＬ（例えば、非特許文献８参照）等の標準仕様が策定されて来ている。
これらの標準仕様では、データ交換における標準交換プロトコル（メッセージ形式や通信プロトコル）の標準も規定しており、更に上述した様なメッセージに対する電子署名付与の形式に関しても規定されている。
こうした標準仕様の登場に伴い、標準仕様に準拠した通信代行サービスへの期待も高まってきている。
これは、標準仕様によってはデータ交換を行う為にサーバ計算機を運用する必要があったり、企業によっては複数の標準仕様に同時に対応する必要があり運用コストが高くつくなど、対応が困難な場合があることによる。
【０００４】
図１に、標準仕様に準拠したデータ交換の通信代行を行う通信代行サービスのシステム形態の例を示す。
通信代行者０１０１、サービスの利用者である通信委託者０１０２（企業Ａ）、通信先（０１０３、０１０４）（企業Ｂ、企業Ｃ）において、各企業の計算機が設置されるサイトが存在する。
これらのサイトに、通信代行サーバ０１１１（通信代行者計算機）、通信委託者計算機０１１２、通信先計算機（０１１３、０１１４）がそれぞれ設置されており、通信ネットワーク０１３１で接続されている。
通信委託企業と通信先企業は、通信代行者を介して、標準仕様に準拠した標準交換プロトコル（標準交換プロトコルα０１２２、及び標準交換プロトコルβ０１２３）に基きデータ交換を行う。
この際、通信委託者０１０２と通信代行者０１０１間は、通信代行者０１０１の規定する通信代行サーバ固有の交換プロトコル０１２１（以後、固有交換プロトコル）に従いデータ交換を行い、通信代行者０１０１が標準交換プロトコル（０１２２、０１２３）に変換することで、通信先（０１０３、０１０４）（企業Ｂ、企業Ｃ）は通信代行者０１０１を意識する事無く通信委託者０１０２（企業Ａ）とのデータ交換を行う事が出来る。
また、この際、通信代行者０１０１は、通信先（０１０３、０１０４）（企業Ｂ、企業Ｃ）に応じて適切な標準交換プロトコルを選択し変換する為、通信委託者０１０２（企業Ａ）は通信先毎に交換プロトコルの違いを意識する事無く、データ交換を行う事が出来る。
また、秘密鍵情報の委託問題に対する公知技術があり（例えば、特許文献１参照）、また、仲介者を介したデータ通信において、電子署名を用いて受信データの正当性を確認する公知技術（例えば、特許文献２参照）がある。
【非特許文献１】
ＲＦＣ２４３７：  ”ＰＫＣＳ  ＃１：  ＲＳＡ  Ｃｒｙｐｔｏｇｒａｐｈｙ  Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ，  Ｖｅｒｓｉｏｎ  ２．０”  Ｂ．Ｋａｌｉｓｋｉ  他，  １９９８
【非特許文献２】
ＲＦＣ１３２１：  ”Ｔｈｅ  ＭＤ５  Ｍｅｓｓａｇｅ−Ｄｉｇｅｓｔ  Ａｌｇｏｒｉｔｈｍ”，  Ｒ．Ｒｉｖｅｓｔ，  １９９２
【非特許文献３】
ＲＦＣ２２４６：  ”Ｔｈｅ  ＴＬＳ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  １．０”，  Ｔ．Ｄｉｅｒｋｓ  他，  ＩＥＴＦ  Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ，  １９９９
【非特許文献４】
ＲＦＣ２３１１：  ”Ｓ／ＭＩＭＥ  Ｖｅｒｓｉｏｎ  ２  Ｍｅｓｓａｇｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ”，  Ｓ．Ｄｕｓｓｅ  他，  ＩＥＴＦ  Ｎｅｔｗｏｒｋ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ，  １９９８
【非特許文献５】
”ＸＭＬ−Ｓｉｇｎａｔｕｒｅ  Ｓｙｎｔａｘ  ａｎｄ  Ｐｒｏｃｅｓｓｉｎｇ”，  Ｗ３Ｃ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ，  ２００２
【非特許文献６】
ＲＦＣ１５２１：  ”ＭＩＭＥ  （Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎｓ）  Ｐａｒｔ  Ｏｎｅ：  Ｍｅｃｈａｎｉｓｍｓ  ｆｏｒ  Ｓｐｅｃｉｆｙｉｎｇ  ａｎｄ  Ｄｅｓｃｒｉｂｉｎｇ  ｔｈｅ  Ｆｏｒｍａｔ  ｏｆ  Ｉｎｔｅｒｎｅｔ  Ｍｅｓｓａｇｅ  Ｂｏｄｉｅｓ”，  Ｎ．  Ｂｏｒｅｎｓｔｅｉｎ  他，  １９９３
【非特許文献７】
”ＲｏｓｅｔｔａＮｅｔ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ：  Ｃｏｒｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，  Ｖｅｒｓｉｏｎ  Ｖ０２．００．０１”，  ＲｏｓｅｔｔａＮｅｔ，  ２００２
【非特許文献８】
”ｅｂＸＭＬ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，  Ｖｅｒｓｉｏｎ  ２．０”，  ＯＡＳＩＳ  ｅｂＸＭＬ  Ｍｅｓｓａｇｉｎｇ  Ｓｅｒｖｉｃｅ  Ｔｅｃｈｎｉｃａｌ  Ｃｏｍｍｉｔｔｅｅ，  ２００２
【特許文献１】
特願２００２−３１１８２９号公報「ＩＣカード」
【特許文献２】
特開２００２−２４１７６号公報「データ通信システム、送信者装置、仲介者装置、受信者装置および記録媒体」
【０００５】
【発明が解決しようとする課題】
こうした通信代行サービスでは、次の様な課題が存在する。
即ち、通信先企業に対して送信する標準形式メッセージに電子署名を付与する場合、通信代行サーバにて電子署名値の計算を行うが、これには、通信委託企業の秘密鍵情報が必要となる。
メッセージに対する電子署名は、例えば取引内容に対する否認防止の目的で行うものである為、取引当事者である通信委託企業の秘密鍵情報を用いて生成し付与しなければならない為である。
しかしながら、秘密鍵情報はＰＫＩ技術においては企業の実印に相当するものであり、通信代行者に対して秘密鍵情報を委託した場合、サービス提供者、及びサービス利用者の何れにとってもリスクが伴う。
上記特許文献１では、委託する秘密鍵情報をＩＣカード中に格納し、電子署名を行う際にはＩＣカード中に格納された制限文により署名対象データのチェックを行っている。
しかしながら、署名対象データの制限条件が複雑な場合は実施が困難となる問題がある。
上記特許文献２では、仲介者を介したデータ通信において、電子署名を用いて受信データの正当性を確認している。
然しながら、特許文献２では受信者は仲介者の存在を意識する必要があり、標準仕様に準拠した交換プロトコルに基いて透過的にサービス利用者とデータ交換を行う様な場合には適用できない。
本発明の目的は、通信委託者の依頼により通信代行者が通信先へ転送する標準形式メッセージに対して、通信委託者が通信代行者へ秘密鍵を委託することなく通信委託者の電子署名を付与することが出来るようにすることにある。
【０００６】
【課題を解決するための手段】
上記目的を達成するため、本発明は、通信代行者計算機を介して通信ネットワークで接続された通信委託者計算機と通信先計算機とが通信代行者計算機を中継して相互にデータ交換を行うデータ交換システムにおいて、通信委託者計算機と通信代行者計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第一形式とし、通信代行者計算機と通信先計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第二形式とし、
通信委託者計算機から通信代行者計算機へ第一形式のメッセージとして送信した交換データを、通信代行者計算機にて第二形式のメッセージに変換して通信先計算機へ送信する場合に、該第二形式のメッセージに公開鍵暗号に基づく通信委託者の電子署名を付与する署名生成方法であり、
通信代行者計算機にて、該第二形式のメッセージに対するダイジェスト値を求め、該ダイジェスト値を含む署名要求メッセージを通信委託者計算機へ送信し、通信委託者計算機にて、該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する電子署名値を求め、該電子署名値を含む署名データメッセージを通信代行者計算機へ送信し、
通信代行者計算機にて、該電子署名値を用いて該第二形式のメッセージに通信委託者の電子署名を付与するようにしている。
また、通信代行者計算機を介して通信ネットワークで接続された通信委託者計算機と通信先計算機とが通信代行者計算機を中継して相互にデータ交換を行い、通信委託者計算機と通信代行者計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第一形式とし、通信代行者計算機と通信先計算機との間で交換データを送受信する場合に用いる該交換データを含むメッセージ形式を第二形式とし、
通信委託者計算機から通信代行者計算機へ第一形式のメッセージとして送信した交換データを、通信代行者計算機にて第二形式のメッセージに変換して通信先計算機へ送信する場合に、該第二形式のメッセージに公開鍵暗号に基づく通信委託者の電子署名を付与するデータ交換システムであり、
通信代行者計算機は、該第二形式のメッセージに対するダイジェスト値を求める手段と、該ダイジェスト値を含む署名要求メッセージを通信委託者計算機へ送信する手段を有し、
通信委託者計算機は、該ダイジェスト値に対して該通信委託者の秘密鍵による暗号化を行い、該第二形式のメッセージに対する電子署名値を求める手段と、該電子署名値を含む署名データメッセージを通信代行者計算機へ送信する手段を有し、
通信代行者計算機は、該電子署名値を用いて該第二形式のメッセージに通信委託者の電子署名を付与する手段を有するようにしている。
【０００７】
【発明の実施の形態】
初めに、一例を挙げて、本発明の概要を説明する。
図１７は、上記一例の概略構成を示す。
通信代行者と通信先企業Ｂとの間のデータ交換は標準形式メッセージを用いて標準交換プロトコルにより行われ、通信代行者と通信委託者企業Ａとの間のデータ交換は通信代行者固有のデータ交換プロトコルを用いて行われる。
通信委託者企業Ａ（以下、Ａと省略して記す）は、交換データを通信先企業Ｂ（以下、Ｂと省略して記す）に送信するとき、通信代行者を介して送信する。
まず、Ａは、（１）送信する交換データを作成し、（２）データ転送要求を通信委託者に送る。
通信委託者は、Ａからのデータ転送要求を受信して、（３）転送データを標準形式メッセージへパッケージングして、（４）交換データ、及び標準形式メッセージのダイジェスト値を計算し、このダイジェスト値を含む署名要求を生成し、更に署名要求に対して通信代行者の秘密鍵（Ｓｃ）で署名し、（５）ダイジェスト値と署名を含む署名要求をＡに送信する。
Ａは、署名要求を受信して、（６）通信代行者の署名の検証を通信代行者の公開鍵（Ｐｃ）を用いて行い、（７）オリジナルの交換データのダイジェスト値を計算し、送られてきた書名要求内の交換データのダイジェスト値と比較して検証し、
（８）通信代行者からの署名要求を保存し、（９）標準形式メッセージに対するＡの署名値を計算し、即ち標準形式メッセージのダイジェスト値をＡの秘密鍵（ＳＡ）で暗号化し、（１０）通信代行者へ署名値の返信をする。即ち、標準形式メッセージに対するＡの署名値を返信する。
通信代行者は、（１１）標準形式メッセージにＡの署名値を埋込み、（１２）ヘッダ情報と交換データとＡの署名値を含む標準形式メッセージをＢに送信する。
Ｂでは、（１３）受信した標準形式メッセージをＡの公開鍵（ＰＡ）を用いて確認する。
以上のようにして、交換データはＡからＢに送信される。このように送信することにより、通信代行者ではＡの秘密鍵を保持・管理する必要がなく、また、通信委託者企業Ａは通信代行者にＡの秘密鍵を渡さなくても済む。これにより、鍵情報の漏洩等のリスクを回避することができる。
例えば、本例を企業間電子商取引（Ｂ２Ｂ）におけるデータ交換に当てはめると、Ｂ２Ｂ標準交換プロトコルによるデータ交換をサポートしていない企業Ａが、通信代行者に対してＢ２Ｂ標準交換プロトコルによる通信代行を委託することで、Ｂ２Ｂ標準交換プロトコルをサポートしている取引先の企業Ｂとビジネス文書等のデー交換を行うといつたケースが考えられる。
【０００８】
以下、図を用いて本発明の実施の形態の一実施例を示す。
先ず、図１〜図２を用いて、本実施例におけるシステム構成を示す。
図１に示すように、通信委託者計算機０１１２、通信代行サーバ０１１１、通信先計算機（０１１３、０１１４）（企業Ｂ、企業Ｃ）の各計算機は、ＣＰＵ０１４１、メモリ０１４２、通信装置０１４３、表示装置０１４４、入力装置０１４５、補助記憶装置０１４６とから構成される。
メモリ０１４２は後述する各プログラムを記憶し、ＣＰＵ０１４１により各プログラムの処理は実行される。
また、各計算機は、通信装置０１４３により通信ネットワーク０１３１を介して相互に接続されている。
通信代行サーバ０１１１は、通信委託者計算機０１１２から受け取った交換データを、通信先計算機（０１１３、０１１４）（企業Ｂ、企業Ｃ）へ転送する。
また逆に、通信先計算機（０１１３、０１１４）（企業Ｂ、企業Ｃ）から転送されたデータを通信委託者計算機０１１２へ送信する。
この際、通信委託者計算機０１１２と通信代行サーバ０１１１間は通信代行サーバ固有の通信プロトコル（固有通信プロトコル０１２１）に従い通信を行い、通信代行サーバ０１１１と通信先計算機（０１１３、０１１４）（企業Ｂ、企業Ｃ）との間は通信先計算機に対応した適切な標準交換プロトコル（０１２２、０１２３）（α、またはβ）を選択して通信を行う。
【０００９】
次に図２を用いて、本実施例における通信代行サーバ０１１１、及び通信委託者計算機０１１２の各計算機における処理プログラムの構成と概要を示す。
通信委託者計算機０１１２側の処理プログラムは、業務処理部０２１８、通信委託制御部０２１７、固有形式メッセージ処理部０２１３、署名生成・検証処理部０２１２、通信処理部０２１１の各処理プログラムから構成される。
業務処理部０２１８は、通信委託制御部０２１７に対して通信先への交換データの送信指示を行い、また、通信先から受信した交換データを受け取る。
通信処理部０２１１は、通信ネットワーク０１３１介して、他の計算機へメッセージの送受信処理を行う。
署名生成・検証処理部０２１２は、一般的な暗号アルゴリズムやダイジェスト値計算アルゴリズムに基づき、電子署名値の暗号化計算（ダイジェスト値の暗号化による電子署名値の生成、及びその逆変換である電子署名値の復号化によるダイジェスト値の復元）、及びバイナリデータに対するダイジェスト値計算を行う。
固有形式メッセージ処理部０２１３は、署名生成・検証処理部０２１２の処理結果を用い、固有交換プロトコルにおいて送受信する各種メッセージ形式の生成、解析、及び固有形式メッセージに対する電子署名の付与や検証とダイジェスト値計算を行う。
通信委託者計算機０１１２の補助記憶装置０１４６には、鍵情報０２２１、及び転送データ情報０２２３が格納される。
【００１０】
通信代行サーバ０１１１側の処理プログラムは、メッセージ転送制御部０２１６、標準形式メッセージ処理部、固有形式メッセージ処理部０２１３、署名生成・検証処理部０２１２、通信処理部０２１１の各処理プログラムから構成される。
ここで、固有形式メッセージ処理部０２１３、署名生成・検証処理部０２１２、通信処理部０２１１の各処理プログラムは、通信委託者計算機０１１２側と同じである。
標準形式メッセージ処理部０２１４は、通信先計算機（０１１３、０１１４）（企業Ｂ、企業Ｃ）の各標準交換プロトコル（α、β）に対する交換形式メッセージの生成、解析、及び電子署名の付与は検証とダイジェスト値計算を行う。
標準形式メッセージ処理部０２１４は、α形式メッセージ処理部０２１５等の、標準形式メッセージ毎のサブ処理プログラムを含む。
メッセージ転送制御部０２１６は、通信委託者計算機０１１２から依頼された交換データの転送処理、及び通信先計算機（０１１３、０１１４）から受信した交換データの通信委託者計算機への転送処理の全体の制御を行う。
通信代行サーバ０１１１の補助記憶装置０１４６には、鍵情報０２２１、転送メッセージ情報０２２２、及び通信委託者管理情報０２２４が格納される。
【００１１】
図５〜図８の各図に、補助記憶装置０１４６内に格納される管理情報の詳細を示す。
図５に、転送データ情報テーブル０５０１の構造を示す。
転送データ情報テーブル０５０１は、通信委託者計算機０１１２と通信代行サーバ０１１１間で行われる各データ転送処理に関する情報（転送データ情報０２２３）を保存するテーブルである。
転送識別子カラム０５１１は、実行された転送処理を一意に特定する転送識別子を格納する。
通信先識別子カラム０５１２は、各転送処理における通信先を一意に特定する企業識別子を格納する。
送受信種別カラム０５１３は、転送処理が通信先計算機（０１１３、０１１４）への送信処理か、通信先計算機からの受信処理かを示す。
送信処理か受信処理かに応じて、「送信」か「受信」かの何れかの値をとる。
転送要求メッセージカラム０５１４、署名要求メッセージカラム０５１５、署名データメッセージカラム０５１６は、通信委託者計算機０１１２が通信代行サーバ０１１１に対して交換データの送信を依頼する際に、両計算機間で交換されるデータ転送要求メッセージ０３１１、署名要求メッセージ０３３１、署名データメッセージ０３４１の各メッセージ（夫々図３参照）を夫々格納する。
最後に、受信データ転送メッセージカラム０５１７は、通信先計算機（０１１３、０１１４）からの交換データ受信時に、通信代行サーバ０１１１から転送されてきた受信データ転送メッセージ０４１１（図４参照）を格納する。
データ転送要求メッセージ０３１１、署名要求メッセージ０３３１、署名データメッセージ０３４１、受信データ転送メッセージ０４１１に関する詳細は、後述する。
【００１２】
図６に、転送メッセージ情報テーブル０６０１の構造を示す。
転送メッセージ情報テーブルは、転送メッセージ情報０２２２を格納するテーブルであり、通信代行サーバ０１１１を介して通信先計算機（０１１３、０１１４）との間で交換された標準形式メッセージが保存される。
転送識別子カラム０６１１は、上述した転送データ情報テーブル０５０１と同様、各転送処理を一意に特定する転送識別子が格納される。
通信委託者識別子カラム０６１２は、通信委託者の企業識別子を格納するカラムであり、通信代行者が複数の通信委託者を有する場合、何れの通信委託者の転送メッセージかを特定する為に用いられる。
通信先識別子カラム０６１３は、通信先を一意に特定する企業識別子である。
送受信種別カラム０６１４は、転送メッセージが通信先へ送信されたものか、通信先から受信したものかを区別する値（「送信」または「受信」の何れか）を格納する。
最後に標準形式メッセージカラム０６１５は、通信先と交換した標準形式メッセージを格納する。
【００１３】
図７に、通信委託者管理情報テーブル０７０１の構造を示す。
通信委託者管理情報テーブル０７０１は通信委託者管理情報０２２４を格納するテーブルである。
通信委託者識別子カラム０７１１は、通信委託者を一意に特定する通信委託者識別子を格納する。
通信先識別子カラム０７１３は、上記通信委託者と（通信代行者を介して）データ交換を行う通信先を示す通信先識別子を格納する。
交換プロトコルカラム０７１５は、上記通信先とデータ交換を行う際に使用する標準交換プロトコルを格納する。
通信先ネットワークアドレスカラム０７１４は、通信先計算機（０１１３、０１１４）が使用する通信ネットワーク上のアドレスを示す。
通信委託者ネットワークアドレス０７１２は、通信委託者計算機０１１２が使用するネットワークアドレスを示す。
通信委託者ネットワークアドレス０７１２は、例えば、通信代行サーバ０１１１と通信委託者計算機０１１２間での通信において、通信代行サーバ０１１１側から通信セッションを開始する必要がある場合に使用する。
【００１４】
図８に、鍵情報テーブル０８０１の構造を示す。
鍵情報テーブルは、各企業の鍵情報０２２１を格納するテーブルである。
企業識別子カラム０８１１は、通信先、通信代行者、通信委託者の各企業を一意に識別する企業識別子である。
公開鍵カラム０８１２は、当該レコードの企業の公開鍵を格納する。
秘密鍵カラム０８１３は、当該レコードの企業の秘密鍵を格納する。
【００１５】
次に、実際に通信代行サーバ０１１１にて通信代行処理を行う手順を、送信時と受信時に分けて説明する。
本手順の説明において、通信委託者の企業識別子を「Ａ」、通信先の企業識別子を「Ｂ」、通信代行者の企業識別子を「Ｚ」とする。
また、通信委託者Ａの秘密鍵をＳＡ００１１、公開鍵をＰＡ００１２、通信先Ｂの秘密鍵をＳＢ００３２、公開鍵をＰＢ００３１、通信代行者Ｚの秘密鍵をＳＺ０００１、公開鍵をＰＺ０００２とする。
各鍵情報は、図３に示すとおり、各計算機における補助記憶装置０１４６内の鍵情報テーブル０８０１に格納されている。
【００１６】
また、本明細書において、記号ｄｉｇ（ｙ）はデータｙのダイジェスト値を示す。
また、記号ｓｇｎ（ｘ，ｙ）は、ｙへのｘによる電子署名の値を表す。
即ち、ｙのダイジェスト値ｄｉｇ（ｙ）に対し、ｘの秘密鍵Ｓｘを用いて暗号化を行ったものである。
署名の検証は一般に、ｘの公開鍵Ｐｘを用いて電子書名を復号化し、ｙのダイジェスト値ｄｉｇ（ｙ）と比較することで行う。
こうしたダイジェスト値計算や暗号化処理には、一般的に知られるアルゴリズムを適用することが出来る。
また、メッセージＭに対するダイジェスト値の計算方法は個々のメッセージ形式に依存するが、同様にｄｉｇ（Ｍ）で記す。
また、メッセージＭに対する電子署名の値はｓｇｎ（ｘ，Ｍ）で表記し、上記と同様にメッセージのダイジェスト値ｄｉｇ（Ｍ）に対して、ｘの秘密鍵Ｓｘを用いて暗号化を行うことで求められる。
メッセージに対するダイジェスト値の計算方法、及び電子署名の付与方法の一例を、後ほど詳細に説明する。
【００１７】
先ず、図３、及び図１４を用いて、通信委託者計算機０１１２から通信代行サーバ０１１１へ交換データの転送依頼を行う際の処理手順を示す。
図１４は、各計算機における処理手順を示すフローチャートである。
左側の破線で囲まれた部分（１４０１）は通信代行サーバ０１１１で実行される処理ステップを、右側の破線で囲まれた部分（１４０２）は通信委託者計算機０１１２で実行される処理ステップを示している。
図３は、各計算機間でのデータの流れを示す、データフロー図である。
（ステップ１４５１）業務処理部０２１８から通信委託制御部０２１７へ交換データ（Ｄ）（０３０１）及び通信先識別子（通信先の企業識別子）を渡し、転送を依頼する。
通信委託制御部０２１７は、固有形式メッセージ処理部０２１３を呼び出し、データ転送要求メッセージ０３１１を作成する。
【００１８】
図９に、データ転送要求メッセージ（ＭＳ１）０３１１の構造を示す。
データ転送要求メッセージ０３１１は、メッセージヘッダ（ＨＳ１）０３１２、及び交換データ０３０１から構成される。
ここで、交換データ０３０１は、業務処理部０２１８から受け取った交換データである。
メッセージヘッダ（ＨＳ１）０３１２の各フィールドにおいて、メッセージ種別フィールド０９０１には固定値「データ転送要求」を、通信委託者識別子フィールド０９０２には通信委託者の企業識別子（この例では、「Ａ」）を、転送識別子フィールド０９０３にはこの転送要求を一意に特定する転送識別子（この例では、「０００１」）を、通信先識別子フィールド０９０４には業務処理部０２１８から受け取った通信先識別子（この例では、「Ｂ」）を、夫々設定する。
ここで、転送識別子は通信委託制御部０２１７にて採番する。
【００１９】
（ステップ１４５２）：通信委託制御部０２１７は、通信処理部０２１１を呼び出し、作成したデータ転送要求メッセージ０３１１を通信代行サーバ０１１１へ送信する。
（ステップ１４１１）：通信代行サーバ０１１１にて、通信処理部０２１１はデータ転送要求メッセージ０３１１を受信し、メッセージ転送制御部０２１６へ渡す。
メッセージ転送制御部０２１６は、固有形式メッセージ処理部０２１３を呼び出して受信したデータ転送要求メッセージ０３１１を解析し、メッセージヘッダ（ＨＳ１）０３１２及び交換データ０３０１を取得する。
ここで、メッセージ転送制御部０２１６は、メッセージヘッダ（ＨＳ１）０３１２中のメッセージ種別フィールド０９０１からメッセージ種別を判定し「データ転送要求」である事を確認する。
メッセージ種別が後述の「署名データ」の場合、ステップ１４１８から実行する。
（ステップ１４１２）：メッセージ転送制御部０２１６は、メッセージヘッダ（ＨＳ１）０３１２の通信委託者識別子フィールド０９０２、及び通信先識別子フィールド０９０４から、通信委託者、及び通信先を特定する。
更に、図７の通信委託者管理情報テーブル０７０１において、上記で取得した通信委託者の企業識別子と通信先の企業識別子との組み合わせから、交換プロトコルカラム０７１５と通信先ネットワークアドレスカラム０７１４を検索する。
（この例では、交換プロトコルとして「α」、通信先ネットワークアドレスとして「ｈｔｔｐ：／／ｗｗｗ．ｂｂｂ．ｃｏｍ／…」が取得される。
）
（ステップ１４１３）：メッセージ転送制御部０２１６は、上記ステップ１４１２で特定した標準交換プロトコルの標準形式メッセージを処理する標準形式メッセージ処理部０２１４のサブ処理プログラム０２１５を呼び出し、標準形式メッセージ（Ｍα）０３２１を作成する（ここでは、α形式メッセージが生成される。）。
【００２０】
図１３に、標準形式メッセージ（Ｍα）０３２１（０３５１、０４０１も同様）の構造を示す。
標準形式メッセージ（Ｍα）は、メッセージヘッダ（Ｈα）１３１１、及び交換データ１３１２とから構成される。
メッセージヘッダ（Ｈα）１３１１の各フィールドにおいて、交換識別子フィールド１３２１には個々のメッセージを一意に特定する交換識別子を、送信者識別子フィールド１３２２には本メッセージの送信者の企業識別子を、受信者識別子フィールド１３２３には本メッセージの受信者の企業識別子を、夫々設定する。
また、送信者電子署名１３１３には、本メッセージに対する送信者の電子署名の値を計算して設定する（送信者電子署名値１３１４）。
標準形式メッセージ（Ｍα）０３２１のメッセージヘッダ（Ｈα）０３２２の各フィールドは、データ転送要求メッセージ（ＭＳ１）０３１１のメッセージヘッダ（ＨＳ１）０３１２の各フィールドの値に応じて、次の様に設定する。
先ず、送信者識別子フィールド１３２２には、通信委託者識別子フィールド０９０２から取得した通信委託者の企業識別子を設定する。
受信者識別子フィールド１３２３には、通信先識別子フィールド０９０４から取得した転送先の企業識別子を設定する。
最後に、交換識別子フィールド１３２１には、転送識別子フィールド０９０３から取得した値を設定する（交換識別子と転送識別子は、その内容は同じものであるが、通信代行サーバと通信先計算機の間でのメッセージの送信の場合には交換識別子と言い、通信代行サーバと通信委託者計算機の間でのメッセージの送信の場合には転送識別子と言う。）。
また、この時点では、標準形式メッセージ（Ｍα）０３２１には送信者電子署名１３１３はまだ付与されていない事に注意する。
本実施例では、固有形式メッセージと標準形式メッセージとのヘッダフィールドの対応付けを上記の様に単純に行ったが、必ずしも両交換プロトコル間で識別子のコード体系や表現形式が一致するとは限らないため、一般には通信代行サーバ０１１１にてこれらの変換処理や対応付け管理を行う必要がある場合がある。
しかしながら、これらの詳細は本発明の実施においてなんら影響を与えるものではなく、本発明の実施範囲を制限するものではない為、説明を割愛する。
【００２１】
（ステップ１４１４）：メッセージ転送制御部０２１６は、固有形式メッセージ処理部０２１３を呼び出し、ステップ１４１１で受信したデータ転送要求メッセージのダイジェスト値（ｄｉｇ（ＭＳ１））を計算する。
（ステップ１４１５）：メッセージ転送制御部０２１６は、標準形式メッセージ処理部０２１４（α形式メッセージ処理部０２１５）を呼び出し、ステップ１４１３で生成した、標準形式メッセージ（Ｍα）１３２１のダイジェスト値（ｄｉｇ（Ｍα））を計算する。
（ステップ１４１６）：メッセージ転送制御部０２１６は、固有形式メッセージ処理部０２１３を呼び出し、署名要求メッセージ（ＭＳ２）０３３１を作成し、通信代行者Ｚの電子署名（ｓｇｎ（Ｚ，ＭＳ２））を付与する。
この際、鍵管理テーブル０８０１に格納された通信代行者Ｚの秘密鍵ＳＺ０００１を使用する。
また、固有形式メッセージ処理部０２１３は、一般的な暗号化アルゴリズムに基づく各データのダイジェスト値計算や電子署名値の計算は、署名生成・検証処理部０２１２を呼び出す事で行うことが出来る。
【００２２】
図１０に、署名要求メッセージ（ＭＳ２）０３３１の構造を示す。
署名要求メッセージ（ＭＳ２）０３３１は、メッセージヘッダ（ＨＳ２）０３３２、データ転送要求メッセージダイジェスト値０３３３、及び標準形式メッセージダイジェスト値０３３４から構成される。
また、署名要求メッセージ（ＭＳ２）０３３１には通信代行者電子署名０３３５が付与される。
データ転送要求メッセージダイジェスト値０３３３は、ステップ１４１４にて計算して得られたダイジェスト値（ｄｉｇ（ＭＳ１））を設定する。
標準形式メッセージダイジェスト値０３３４には、ステップ１４１５にて計算して得られたダイジェスト値（ｄｉｇ（Ｍα））を設定する。
メッセージヘッダ（ＨＳ２）０３３２の各フィールドにおいて、メッセージ種別フィールド１００１には固定値「署名要求」を設定し、その他のフィールドに関してはステップ１４１１で受信したデータ転送要求メッセージ（ＭＳ１）０３１１のメッセージヘッダ（ＨＳ１）０３１２の対応する各フィールドと同一の値を設定する。
【００２３】
（ステップ１４１７）：メッセージ転送制御部０２１６は、通信処理部０２１１を呼び出し、署名要求メッセージ０３３１を通信委託者計算機０１１２へ送信する。
（ステップ１４５３）：通信委託者計算機０１１２にて、通信処理部０２１１は署名要求メッセージ０３３１を受信し、通信委託制御部０２１７へ渡す。
通信委託制御部０２１７は、固有形式メッセージ処理部０２１３を呼び出して受信した署名要求メッセージ（ＭＳ２）０３３１を解析し、メッセージヘッダ（ＨＳ２）０３３２、データ転送要求メッセージダイジェスト値０３３３、標準形式メッセージダイジェスト値０３３４を取得する。
ここで、通信依頼元計算機は、メッセージヘッダ（ＨＳ２）０３３２中のメッセージ種別フィールド１００１からメッセージ種別を判定し「署名要求」である事を確認する。
（ステップ１４５４）：通信委託制御部０２１７は、固有形式メッセージ処理部０２１３を呼び出し、ステップ１４５３で受信した署名要求メッセージ（ＭＳ２）０３３１に付与された通信代行者電子署名０３３５を、通信代行者Ｚの公開鍵ＰＺ０００２を用いて検証する。
即ち、通信代行者電子署名値０３３６を通信代行者Ｚの公開鍵ＰＺ０００２で復号化し、通信委託者計算機側で再計算した署名要求メッセージ（ＭＳ２）０３３１のダイジェスト値と比較する。
この際、固有形式メッセージ処理部０２１３は、一般的な暗号化アルゴリズムに基づく各データのダイジェスト値計算や電子署名値の復号化の計算は、署名生成・検証処理部０２１２を呼び出す事で行うことが出来る。
また、通信代行者Ｚの公開鍵ＰＺ０００２は、通信委託者計算機０１１２の鍵情報テーブル０８０１に格納しておく。
【００２４】
（ステップ１４５５）通信委託制御部０２１７は、固有形式メッセージ処理部０２１３を呼び出し、ステップ１４５２で送信したデータ転送要求メッセージ（ＭＳ１）０３１１のダイジェスト値を計算する。
更に、得られたダイジェスト値とステップ１４５３で受信した署名要求メッセージ（ＭＳ２）０３３１内に格納されたデータ転送要求メッセージダイジェスト値０３３３と比較する。
（ステップ１４５６）：通信委託制御部０２１７は、署名生成・検証処理部０２１２を呼び出し、転送形式メッセージ（Ｍα）０３２１の電子署名値を計算する。
電子署名値は、ステップ１４５３で受信した署名要求メッセージ（ＭＳ２）０３３１内に格納された標準形式メッセージダイジェスト値０３３４を、通信委託者Ａの秘密鍵ＳＡ００１１で暗号化する事で得られる。
通信委託者Ａの秘密鍵ＳＡ００１１は、通信委託者計算機０１１２の鍵情報テーブル０８０１に格納しておく。
（ステップ１４５７）：通信委託制御部０２１７は、固有形式メッセージ処理部０２１３を呼び出し、署名データメッセージ（ＭＳ３）０３４１を生成する。
【００２５】
図１１に、署名データメッセージ（ＭＳ３）０３４１の構造を示す。
署名データメッセージ（ＭＳ３）０３４１は、メッセージヘッダ（ＨＳ３）０３４２、及び通信委託者電子署名値０３４３から構成される。
通信委託者電子署名値０３４３は、ステップ１４５６にて生成した、転送形式メッセージ（Ｍα）０３２１の電子署名値である。
また、メッセージヘッダ（ＨＳ３）０３４２の各フィールドにおいて、メッセージ種別フィールド１１０１には固定値「署名データ」を設定し、その他のフィールドに関してはステップ１４５３で受信した署名要求メッセージ（ＭＳ２）０３３１のメッセージヘッダ（ＨＳ２）０３３２の対応する各フィールドと同一の値を引き継ぐ。
【００２６】
（ステップ１４５８）：通信委託制御部０２１７は、データ転送要求メッセージ０３１１、署名要求メッセージ０３３１、署名データメッセージ０３４１の各固有形式メッセージを、転送データ情報テーブル０５０１の対応する各カラムへ格納する。
ここでは、併せて他の各カラムの値として転送識別子カラム０５１１に「０００１」、通信先識別子カラム０５１２に「Ｂ」、送受信種別カラム０５１３に「送信」の各値が設定される。
（ステップ１４５９）：通信委託制御部０２１７は、通信処理部０２１１を呼び出し、ステップ１４５７で作成した署名データメッセージ０３４１を通信代行サーバ０１１１へ送信する。
【００２７】
（ステップ１４１８）：通信代行サーバ０１１１にて、通信処理部０２１１は署名データメッセージ０３４１を受信し、メッセージ転送制御部０２１６へ渡す。
メッセージ転送制御部０２１６は、固有形式メッセージ処理部０２１３を呼び出して受信した署名データメッセージ０３４１を解析し、メッセージヘッダ（ＨＳ３）０３４２及び通信委託者電子署名値０３４３を取得する。
ここで、メッセージ転送制御部０２１６は、メッセージヘッダ（ＨＳ３）０３４２中のメッセージ種別フィールド１１０１からメッセージ種別を判定し「署名データ」である事を確認する。
（ステップ１４１９）：メッセージ転送制御部０２１６は、標準形式メッセージ処理部０２１４（α形式メッセージ処理部０２１５）を呼び出し、ステップ１４１８で取得した通信委託者電子署名値０３４３を用いて、標準形式メッセージ（Ｍα）０３２１に送信者電子署名１３１３を付与する。
（ステップ１４２０）：ステップ１４１９にて送信者電子署名を付与した、書名付き標準形式メッセージ（Ｍα）０３５１を、転送メッセージ情報テーブルの標準形式メッセージカラム０６１５へ保存する。
ここでは、併せて各カラムの値として転送識別子カラム０６１１に「０００１」、通信委託者識別子カラム０６１２に「Ａ」、通信先識別子カラム０６１３に「Ｂ」、送受信種別カラム０６１４に「送信」の各値が設定される。
（ステップ１４２１）：最後に、メッセージ転送制御部０２１６は通信処理部０２１１を呼び出し、ステップ１４１９で作成した書名付き標準形式メッセージ（Ｍα）０３５１を、通信先計算機０１１３へ送信する。
【００２８】
次に、図４、及び図１５を用いて、通信代行サーバ０１１１から通信委託者計算機０１１２へ、通信先計算機から受信した交換データを転送する際の処理手順を示す。
図１５は、各計算機における処理手順を示すフローチャートである。
左側の破線で囲まれた部分（１５０１）は通信代行サーバ０１１１で実行される処理ステップを、右側の破線で囲まれた部分（１５０２）は通信委託者計算機０１１２で実行される処理ステップを示している。
図４は、各計算機間でのデータの流れを示す、データフロー図である。
【００２９】
（ステップ１５１１）：通信代行サーバ０１１１にて、通信処理部０２１１は通信先計算機０１１３より標準形式メッセージ（Ｍα）０４０１を受信し、メッセージ転送制御部０２１６へ渡す。
メッセージ転送制御部０２１６は、標準形式メッセージ処理部０２１４（α形式メッセージ処理部０２１５）を呼び出し、受信した標準形式メッセージ（Ｍα）０４０１を解析し、メッセージヘッダ（Ｈα）０４０２及び交換データ（Ｄ）０４０３を取得する。
ここで、メッセージヘッダ（Ｈα）０４０２の各フィールドの値は、交換識別子１３２１が「０００２」、送信者識別子１３２２が「Ｂ」、受信者識別子１３２３が「Ａ」であったとし、以下説明を進める。
【００３０】
（ステップ１５１２）：メッセージ転送制御部０２１６は、メッセージヘッダ（Ｈα）０４０２中の送信者識別子１３２２から通信先の企業識別子を特定し（ここでは、「Ｂ」）、鍵情報テーブル０８０１の公開鍵カラム０８１２から通信先の公開鍵を取得する（ここでは、ＰＢ００３１）。
更に、メッセージ転送制御部０２１６は、標準形式メッセージ処理部０２１４（α形式メッセージ処理部０２１５）を呼び出し、取得した公開鍵ＰＢ００３１を用いて送信者電子署名０４０４（１３１３）を検証する。
（ステップ１５１３）：メッセージ転送制御部０２１６は、固有形式メッセージ処理部０２１３を呼び出し、受信データ転送メッセージ（ＭＳ４）０４１１を作成する。
更に、通信代行者（ここでは、Ｚ）の秘密鍵を用いて受信データ転送メッセージ（ＭＳ４）０４１１に対して通信代行者電子署名０４１３を付与する。
【００３１】
図１２に、受信データ転送メッセージ（ＭＳ４）０４１１の構造を示す。
受信データ転送メッセージ（ＭＳ４）０４１１は、メッセージヘッダ（ＨＳ４）０４１２、交換データ（Ｄ）０４０３、標準形式メッセージ（Ｍα）０４０１から構成される。
また、受信データ転送メッセージ（ＭＳ４）０４１１には通信代行者電子署名０４１３が付与される。
ここで、交換データ（Ｄ）０４０３は、ステップ１５１２にて取得した交換データである。
また、標準形式メッセージ（Ｍα）０４０１は、ステップ１５１１で受信した標準形式メッセージ（Ｍα）である。
また、メッセージヘッダ（ＨＳ４）０４１２の各フィールドにおいて、メッセージ種別フィールド１２０１には固定値「受信データ転送」を設定する。
また、その他のフィールドは標準形式メッセージ（Ｍα）０４０１のメッセージヘッダ（Ｈα）０４０２の各フィールドの値に応じて、次の様に設定する。
先ず、通信委託者識別子フィールド１２０２には、受信者識別子フィールド１３２３から取得した企業識別子を設定する。
通信先識別子フィールド１２０４には、送信者識別子フィールド１３２２から取得した企業識別子を設定する。
最後に、転送識別子フィールド１２０３には、交換識別子フィールド１３２１から取得した値を設定する。
ここでは、通信委託者識別子フィールド１２０２に「Ａ」、通信先識別子フィールド１２０４に「Ｂ」、転送識別子フィールド１２０３に「０００２」が設定される。
【００３２】
（ステップ１５１４）：ステップ１５１１で受信した標準形式メッセージ（Ｍα）０４０１を、転送メッセージ情報テーブル０６０１の標準形式メッセージカラム０６１５へ保存する。
ここでは、併せて各カラムの値として転送識別子カラム０６１１に「０００２」、通信依頼元識別子カラム０６１２に「Ａ」、通信先識別子カラム０６１３に「Ｂ」、送受信種別カラム０６１４に「受信」の各値が設定される。
（ステップ１５１５）：メッセージ転送制御部０２１６は、通信処理部０２１１を用いて、受信データ転送メッセージ（ＭＳ４）０４１１を通信委託者計算機０１１２へ送信する。
【００３３】
（ステップ１５５１）：通信委託者計算機０１１２にて、通信処理部０２１１は受信データ転送メッセージ（ＭＳ４）０４１１を受信し、通信委託制御部０２１７へ渡す。
通信委託制御部０２１７は、固有形式メッセージ処理部０２１３を呼び出して受信した受信データ転送メッセージ（ＭＳ４）０４１１を解析し、メッセージヘッダ（ＨＳ４）０４１２、交換データ（Ｄ）０４０３、及び標準形式メッセージ（Ｍα）０４０１を取得する。
ここで、通信委託者計算機０１１２は、メッセージヘッダ（ＨＳ４）０４１２中のメッセージ種別フィールド１２０１からメッセージ種別を取得し「受信データ転送」である事を確認する。
【００３４】
（ステップ１５５２）：通信委託制御部０２１７は、固有形式メッセージ処理部０２１３を呼び出し、ステップ１５５１で受信した受信データ転送メッセージ（ＭＳ４）０４１１に付与された通信代行者電子署名０４１３を、通信代行者Ｚの公開鍵ＰＺ０００２を用いて検証する。
即ち、通信代行者電子署名値０４１４を通信代行者Ｚの公開鍵ＰＺ０００２で復号化し、通信委託者計算機側で再計算した受信データ転送メッセージ（ＭＳ４）０４１１のダイジェスト値と比較する。
この際、固有形式メッセージ処理部０２１３は、一般的な暗号化アルゴリズムに基づく各データのダイジェスト値計算や電子署名値の復号化の計算は、署名生成・検証処理部０２１２を呼び出す事で行うことが出来る。
また、通信代行者Ｚの公開鍵ＰＺ０００２は、通信委託者計算機０１１２の鍵情報テーブル０８０１に格納しておく。
【００３５】
（ステップ１５５３）：通信委託制御部０２１７は、受信データ転送メッセージ（ＭＳ４）０４１１を、転送データ情報テーブル０５０１の対応する各カラムへ格納する。ここで、格納された受信データ転送メッセージ（ＭＳ４）０４１１は、例えば、通信委託者と通信代行者との間で、何らかのトラブルが発生したような場合に、受信データ転送メッセージ（ＭＳ４）が通信委託者に受信されていることを証明するために使用される。
ここでは、併せて他の各カラムの値として転送識別子カラム０５１１に「０００２」、通信先識別子カラム０５１２に「Ｂ」、送受信種別カラム０５１３に「送信」の各値が設定される。
（ステップ１５５４）：通信委託制御部０２１７は、ステップ１５５１で取得した交換データ（Ｄ）０４０３を業務処理部へ受け渡す。
次に、図１６を用いて、メッセージに対するダイジェスト値の計算方法、及び電子署名の付与方法の一例を説明する。
【００３６】
図１６は、例として標準形式メッセージ（Ｍα）１３０１を題材にその形式をより具体的に記述した例である。
本形式例では、標準形式メッセージ（Ｍα）１３０１は、その各構成要素をＭＩＭＥ形式（前述の非特許文献６参照）にてパッケージしている。
記号１６２１の示す行は、パッケージ全体が複数パートからなるＭＩＭＥ形式であり、各パートが境界文字列「−−ｂｏｕｎｄａｒｙ」で区切られることを示す。
記号１６２２の示す行は、各パートを区切る境界文字列を示す。
記号１６２３、及び１６２４の示す行は、各パートのヘッダ行で、行１６２３はパートの内容タイプ（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ）を、行１６２４はパッケージ内で内容を一意に示す内容識別子（Ｃｏｎｔｅｎｔ−ＩＤ）を示している。
例えば、メッセージヘッダ１３１１の内容タイプは「ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍ」、内容識別子は「ｈｅａｄｅｒ」である。
最後のパートには、送信者電子署名１３１３がＸＭＬ電子署名の形式で表現され、格納されている。
記号１６３１の示す行は、本ＸＭＬ文書がＸＭＬ電子署名（Ｓｉｇｎａｔｕｒｅ  要素）である事を表している。
【００３７】
記号１６１４の示す枠線で囲まれた部分は電子署名情報を表し、署名対象に含める各パートに対する参照情報（Ｒｅｆｅｒｅｎｃｅ  要素）を含む。
各参照情報（記号１６１５、及び１６１６の示す枠線で囲まれた部分）には、参照先のデータに対するダイジェスト値が含まれる。
ちなみに、記号１６１５で示す枠線で囲まれた部分には、メッセージヘッダ１３１１に対するダイジェスト値が格納され、記号１６１６で示す枠線で囲まれた部分には、交換データ１３１２に対するダイジェスト値が格納される。
記号１６３３の示す行は、署名対象に含めるパートの内容識別子を指定する。
記号１６３４の示す行は、ダイジェスト値を計算する際に使用するアルゴリズムを指定する。
ここでは、ＳＨＡ−１アルゴリズムが使用されている。
記号１６３５の示す行には、行１６３３により参照されるパートを対象に、行１６４４に示されるアルゴリズムで計算したダイジェスト値が格納される。
こうして、電子署名情報１６１４（記号１６１４の示す枠線で囲まれた部分）には、メッセージヘッダ１３１１と交換データ１３１２の夫々のダイジェスト値が含まれる事になる。
従って、更に電子署名情報１６１４に対するダイジェスト値を計算する事により、標準形式メッセージ（Ｍα）１３０１に対するダイジェスト値を計算した事になる。
【００３８】
記号１６３２の示す行には、電子署名情報１６１４に対するダイジェスト値を計算するアルゴリズムと、得られたダイジェスト値に対する電子署名値を生成するための暗号化アルゴリズムの組が指定されている。
ここでは、ダイジェスト値の計算アルゴリズムとしてＳＨＡ−１が、暗号化アルゴリズムとしてＤＳＡが指定されている。
即ち、電子署名情報１６１４に対してＳＨＡ−１アルゴリズムで計算したダイジェスト値が、標準形式メッセージ（Ｍα）１３０１に対するダイジェスト値（ｄｉｇ（Ｍα））となり、得られたダイジェスト値に対してＤＳＡアルゴリズムを用いて暗号化して結果が標準形式メッセージ（Ｍα）１３０１に対する電子署名値（送信者電子署名値１３１４）（ｓｇｎ（ｘ，Ｍα）、ｘは送信者を示す）となる。
送信者電子署名値１３１４は、記号１６３６で示される行に格納される。
ここで、標準形式メッセージ（Ｍα）１３０１に対するダイジェスト値は、送信者電子署名１３１３が標準形式メッセージ（Ｍα）１３０１に設定されているか否かに関わらず、同じ値となる。
【００３９】
以上に示してきた様に、本発明では以下が可能となる。
第一に、本発明によれば、通信委託者の依頼により通信代行者が通信先へ転送する標準形式メッセージに対して、通信委託者が通信代行者へ秘密鍵を委託する事無く通信委託者の電子署名を付与する事が出来る。
これにより、通信委託者は（自社の実印にあたる）秘密鍵を、第三者である通信代行者に委託するリスクを回避することが出来るとともに、通信代行者にとっても通信委託者の秘密鍵に対するセキュリティ上の管理リスクを回避する事が出来る。
また、通信先は通信代行者を意識する事無く、透過的に通信委託者とデータ交換が可能となる。
【００４０】
第二に、署名要求メッセージに対して通信代行者の電子署名を付与する事により、不適切な内容の標準形式メッセージや任意のデータに対して通信委託者が電子署名を付与させられる事を防止し、転送する標準形式メッセージに対して安全に電子署名を付与する事が出来る。
例えば、問題発生時には通信代行者と通信委託者の間で以下のように責任範囲を明確にする事が出来る。
通信委託者の電子署名が付与された不適切な内容の標準形式メッセージが見つかった場合、通信委託者は転送データ管理テーブルに格納された過去の履歴データから対応する署名要求メッセージを探す。
これは、不適切な内容の標準形式メッセージに対するダイジェスト値を含む署名要求メッセージを検索すればよい。
もし、該当する署名要求メッセージが存在すれば、通信代行者が不正な署名要求をした事になり、署名要求メッセージには通信代行者の電子署名が付与されている為、通信代行者は否認する事が出来ない。
逆に、該当する署名要求メッセージが存在しなければ、通信代行者が不正な署名要求をした事実は存在せず、問題の電子署名を生成した秘密鍵を管理する通信依頼元側に責任があることとなる。
【００４１】
第三に、署名要求メッセージ内にデータ転送要求メッセージのダイジェスト値を含めておくことで、通信代行者による署名要求が何れのデータ転送要求に対して行われたのかを確認する事ができる様になる。
転送委託元の電子署名の付与された不正な内容の標準形式メッセージが見つかる等の問題発生時には、転送委託元は自らの送信したデータ転送要求メッセージとそれに対する署名要求メッセージとの組を示す。
これにより、データ転送要求メッセージそのものに誤りがないか否かを後日確認できる。
更に、通信代行者が不正なデータ転送要求メッセージに対して誤って署名要求メッセージを送信してしまっても、不当に責任を負わせられることはない。
【００４２】
第四に、通信先へ送信する標準形式メッセージに対して付与する電子署名の署名者を、通信委託者計算機にて動的且つ柔軟に変更可能となる。
例えば、企業間電子商取引においては、交換データの内容に応じて、電子署名を付与する必要のある担当者が異なる場合が考えられる。
これらの切り替えを通信代行サーバで行った場合、通信代行サーバの処理が煩雑になる事が考えられる。
【００４３】
第五に、受信データ転送メッセージに対して通信代行者の電子署名を付与する事で、通信代行サーバにて受信した標準形式メッセージの通信委託者計算機への転送内容を保証する事が出来る。
即ち、標準形式メッセージに付与された通信先の電子署名に対する通信代行者での検証事実、及び転送された交換データの内容について、通信委託者では保証を得ることが出来る。
【００４４】
最後に、本発明は企業間電子商取引における通信代行サービス事業のみでなく、通信代行サーバを介したデータ交換において、一般的に適用可能な技術である。
【００４５】
【発明の効果】
以上に述べたように、本発明によれば、通信委託者は通信代行者に対し自らの秘密鍵を委託する事無く、通信代行者が転送する標準形式メッセージに対して安全に通信委託者の電子署名を付与する事が出来る。
【図面の簡単な説明】
【図１】本発明の一実施例におけるシステム構成を示す第一の図である。
【図２】本発明の一実施例におけるシステム構成を示す第二の図である。
【図３】本発明の一実施例において、交換データの送信時におけるデータフローを示す図である。
【図４】本発明の一実施例において、交換データの受信時におけるデータフローを示す図である。
【図５】本発明の一実施例における、転送データ情報テーブルの構造を示す図である。
【図６】本発明の一実施例における、転送メッセージ情報テーブルの構造を示す図である。
【図７】本発明の一実施例における、通信委託者管理情報テーブルの構造を示す図である。
【図８】本発明の一実施例における、鍵情報テーブルの構造を示す図である。
【図９】本発明の一実施例における、データ転送要求メッセージの構造を示す図である。
【図１０】本発明の一実施例における、署名要求メッセージの構造を示す図である。
【図１１】本発明の一実施例における、署名データメッセージの構造を示す図である。
【図１２】本発明の一実施例における、受信データ転送メッセージの構造を示す図である。
【図１３】本発明の一実施例における、標準形式メッセージの構造を示す図である。
【図１４】本発明の一実施例において、交換データの送信時における処理のフローチャートを示す図である。
【図１５】本発明の一実施例において、交換データの受信時における処理のフローチャートを示す図である。
【図１６】本発明の一実施例における、標準形式メッセージへの電子署名付与の方法を示す図である。
【図１７】本発明の概要を説明するために挙げた一例の概略構成を示す図である。
【符号の説明】
０１０１    通信代行者
０１０２    通信委託者
０１０３、０１０４    通信先
０１１１    通信代行サーバ（通信代行者計算機）
０１１２    通信委託者計算機
０１１３、０１１４    通信先計算機
０２１１    通信処理部
０２１２    署名生成・検証処理部
０２１３    固有形式メッセージ処理部
０２１４    標準形式メッセージ処理部
０２１６    メッセージ転送制御部
０２１７    通信委託制御部
０２１８    業務処理部
【図１】
2005033396.tif 000003
【図２】
2005033396.tif 000004
【図３】
2005033396.tif 000005
【図４】
2005033396.tif 000006
【図５】
2005033396.tif 000007
【図６】
2005033396.tif 000008
【図７】
2005033396.tif 000009
【図８】
2005033396.tif 000010
【図９】
2005033396.tif 000011
【図１０】
2005033396.tif 000012
【図１１】
2005033396.tif 000013
【図１２】
2005033396.tif 000014
【図１３】
2005033396.tif 000015
【図１４】
2005033396.tif 000016
【図１５】
2005033396.tif 000017
【図１６】
2005033396.tif 000018
【図１７】
2005033396.tif 000019