(57)【要約】【課題】否認防止のセキュリティー要件を損なうことなく、受領確認メッセージのメッセージ数を削減しまたビジネストランザクションの失敗時に無駄になるような受領確認メッセージを交換しないこと。【解決手段】署名側システムおよび署名要求側システムはそれぞれ取引開始時点からの送受信したビジネス文書を保存する。署名側システムは前記取引の終了時点で取引開始時点から終了時点までに保存されたビジネス文書全体に対する署名を一括して生成し、署名側システムは前記電子署名を署名要求側システムに送信する。署名要求側システムは署名側システムから受信した電子署名の正当性を保存したビジネス文書全体に基づいて一括して検証する。【選択図】  図１
2004320398.tif 000002
【特許請求の範囲】
【請求項１】
署名側システムと署名要求側システムがネットワークを介して接続され、署名側システムと署名要求側システムが取引開始時点から取引終了時点までの間に順不同に複数のビジネス文書を交換する際に、
署名側システムおよび署名要求側システムは取引開始時点からの送受信したビジネス文書を保存し、
署名側システムは前記取引を終了する時点で取引の開始時点から終了時点までに保存した全てのビジネス文書の集合に対する署名を一括して生成し、
署名側システムは前記電子署名を署名要求側システムに送信し、
署名要求側システムは署名側システムから受信した電子署名の正当性を取引の開始時点から終了時点までに保存された全てのビジネス文書の集合に基づいて一括して検証することを特徴とする電子商取引方法。
【請求項２】
前記電子商取引方法において、
署名側システムおよび署名要求側システムは取引を識別する識別子に関連付けてビジネス文書を保存し、
署名側システムは前記識別子に基づいて署名対象の文書を決定し、
署名要求側システムは前記識別子に基づいて署名検証対象の文書を決定することを特徴とする請求項１記載の電子商取引方法。
【請求項３】
前記電子商取引方法において、
署名側システムおよび署名要求側システムは取引開始タイミングと取引終了タイミングを定める定義情報を有し、
署名側システムおよび署名要求側システムは前記定義情報に基づいて送受信するビジネス文書の保存を開始し、
署名側システムは前記定義情報に基づいて電子署名の生成を開始することを特徴とする請求項２記載の電子商取引方法。
【請求項４】
前記電子商取引方法において、
署名側システムと署名要求側システムが共に署名側でかつ署名要求側であることを特徴とする請求項３記載の電子商取引方法。
【請求項５】
ネットワークを介して接続された取引相手システムと取引開始時点から取引終了時点までの間に順不同にビジネス文書を送受信する手段と、
取引開始時点から取引終了時点までの間に取引相手システムと送受信したビジネス文書を保存する手段と、
前記保存したビジネス文書全体に対する電子署名を一括して生成および検証する手段とを有することを特徴とする電子商取引システム。
【請求項６】
前記電子商取引システムにおいて、
取引を識別する識別子に関連付けてビジネス文書を保存する手段と、
前記識別子に基づいて署名対象の文書を決定する手段と、
前記識別子に基づいて署名検証対象の文書を決定する手段とを有することを特徴とする請求項５記載の電子商取引システム。
【請求項７】
前記電子商取引システムにおいて、
取引開始タイミングと取引終了タイミングを定める定義情報を保持する手段と、
前記定義情報から取引開始および取引終了のタイミングを取得する手段とを有することを特徴とする請求項６記載の電子商取引システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は電子計算機とネットワークを用いて安全なビジネス文書の交換を行う電子商取引方法及びシステムに関する。
【０００２】
【従来の技術】
一般的な企業間電子商取引においては、取引企業間で交換する各ビジネス文書に対して否認防止などのセキュリティー要件の実現が必須である。ここで述べる否認防止とはビジネス文書の送信者が当該文書を送信した事実を否認することの防止（送信否認防止）、およびビジネス文書の受信者が文書を受信した事実を否認することの防止（受信否認防止）である。否認防止のセキュリティー要件を満たす方法としては取引当事者の間で交換する各ビジネス文書に対して電子署名による内容確認を行う方法が知られている。ビジネス文書の送信者が送信するビジネス文書にその文書に対する電子署名を生成し、ビジネス文書と一緒に送信することにより送信否認防止を実現する。また、ビジネス文書の受信者が受信したビジネス文書のハッシュ値を含む受領確認メッセージを生成し、受領確認メッセージに対して署名し、ビジネス文書の送信者に対して返信することにより受信否認防止を実現する。この方式の例としては企業間電子商取引の標準仕様であるｅｂＸＭＬ仕様を挙げることができる（例えば、非特許文献１参照）。
【０００３】
さらに、企業間電子商取引ではひとつの取引が１つ以上のビジネス文書の交換によって構成される場合がある。このような取引の実現には取引のビジネス上の区切り（ビジネストランザクション）を管理が必要である。一般には取引開始時点、取引終了時点で制御メッセージを交換する方法が知られている。また必要があれば取引の途中で取引キャンセルの制御メッセージを交換することで、ビジネストランザクションをキャンセルする場合もある（例えば、特許文献１参照）。
【０００４】
また、複数の文書を署名対象として、１つの署名を生成する方式が知られている。本方式の例としてインターネット技術の標準化組織であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）が発行するＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  ｃｏｍｍｅｎｔｓ）３０７５番に規定されたＸＭＬ電子署名がある。ＸＭＬ電子署名では、個々の文書に対して文書を識別可能な識別子（文書ＩＤ）が存在する場合に、一つ以上の文書の集合を署名処理の対象とすることが可能である。つまり、一つ以上の文書の集合を指定して、それに対する署名を生成する方法が規定されている。同様に、一つの署名とそれに対する一つ以上の文書の集合を指定して署名の検証を行う方法も規定されている（例えば、非特許文献２参照）。前述のｅｂＸＭＬ仕様においても、複数の文書を同時に送信するとき、例えばカタログ文書と画像データを送る場合などに、それらを同一のメッセージにまとめる方法が規定されている。この場合、署名方法にはＸＭＬ電子署名を用い、まとめた複数の文書に対して一つの署名を生成する。
【０００５】
【非特許文献１】
菅谷久直・森田勝弘、「ｅｂＸＭＬ技術概説」、株式会社ソフトリサーチセンター、ｐｐ１８６−１８９、（２００１）
【特許文献１】
特開２００１−３３８１８５号
【非特許文献２】
Ｍａｒｋ  Ｂａｒｔｅｌ，  Ｊｏｈｎ  Ｂｏｙｅｒ，  Ｂａｒｂ  Ｆｏｘ，  Ｂｒｉａｎ  ＬａＭａｃｃｈｉａ，  Ｅｄ  Ｓｉｍｏｎ：  Ｊｏｉｎｔ  Ｗ３Ｃ／ＩＥＴＦ  ＸＭＬ−Ｓｉｇｎａｔｕｒｅ  Ｓｙｎｔａｘ  ａｎｄ  Ｐｒｏｃｅｓｓｉｎｇ  ｓｐｅｃｉｆｉｃａｔｉｏｎ，  Ｗ３Ｃ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ，  Ｆｅｂ  ２００２。
【０００６】
【発明が解決しようとする課題】
従来技術の特許文献１ではセキュリティーに関する特別な考慮はなされていない。また、ＸＭＬ電子署名では、ビジネストランザクションに対する規定はなされていない。このため従来技術では、ＸＭＬ電子署名のような署名方法を用い、ビジネストランザクションによる企業間電子商取引を行う際の署名方法が効率的でないという問題がある。つまり、ｅｂＸＭＬ仕様で規定されるように、ビジネストランザクションとは関係なく、送信否認防止および受信否認防止の署名処理がビジネス文書の送受信回数に比例して増大するという問題がある。また、受信否認防止のための受領確認メッセージがビジネス文書の送信回数に比例して増大するという問題がある。さらに、ビジネストランザクションが途中の段階で取消された場合には、それまで行った署名処理と交換した受領確認メッセージが無駄になるという問題もある。
【０００７】
本発明の目的は、商取引における否認防止のセキュリティー要件を損なうことなく署名処理回数および受領確認メッセージのメッセージ数を削減することにある。本発明のほかの目的は、商取引における否認防止のセキュリティー要件を損なうことなくビジネストランザクションがキャンセルされた場合に無駄になるような署名処理および受領確認メッセージを交換しないことである。
【０００８】
【課題を解決するための手段】
従来技術の署名処理が送信ごとでしか一括化されていないのに対し、本発明ではビジネストランザクションの単位で署名処理を一括して行う。このために、本発明ではビジネス文書の交換ごとに行っていた署名処理及び受領確認メッセージの交換を行わず、代わりにビジネストランザクションの単位で署名処理を行うことで否認防止を実現する。
【０００９】
まず、署名側システムおよび署名要求側システムはそれぞれ取引開始時点からの送受信したビジネス文書を、取引を識別する識別子（トランザクションＩＤ）に関連付けて保存する。
【００１０】
署名側システムは取引終了後で当該トランザクションＩＤに基づいてビジネス文書を取得する。これにより保存された全ビジネス文書の集合から署名対象のビジネス文書の集合を決定したことになる。次に、取得したビジネス文書の集合に対する署名を生成する。これは従来技術で示した、ＸＭＬ電子署名などの方法で行う。これにより、該当取引に属するビジネス文書の全てに一括して署名を生成したことになる。つまり、この署名は署名側システムが送信したビジネス文書に対する署名（送信否認防止）であり、なおかつ署名側システムが受信したビジネス文書に対する署名（受信否認防止）である。署名側システムは生成した前記署名を署名要求側システムに送信する。
【００１１】
署名要求側システムも同様に当該トランザクションＩＤに基づいてビジネス文書を取得することで署名対象のビジネス文書の集合を決定する。署名要求側システムは取得したビジネス文書の集合に基づいて、署名側システムから受信した署名の正当性を一括して検証する。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態を詳細に説明する。
【００１３】
図１は本発明を署名側システム・署名要求側システムによる電子商取引に適用した場合の処理手順を示すフロー図である。図２は本発明に係る署名要求側システムのシステムの構成を示すブロック図である。図３、図４、図５はシステムで管理するテーブルを示す。図６は本発明で署名対象となるビジネス文書の一例である。図７は本発明において生成される電子署名の一例である。図８、図９は図１に対するより詳細なフロー図である。
【００１４】
図２において署名要求側システム１１はインターネットなどのネットワークを介して署名側システム２５と電子商取引を行う。署名側システム側のシステムも署名側システム側のシステムと同様である。システムは業務処理１２、メッセージ管理１３、トランザクション管理１４、電子署名生成・検証１５、一括署名管理１６の各機能と定義情報テーブル１９、トランザクションテーブル２０、ビジネス文書テーブル２１を記録する補助記憶装置１８、および通信装置２２などからなる。
【００１５】
業務処理１２はビジネス文書に基づいて業務を行い、メッセージ管理１３を介してビジネス文書の送信・受信を行う。
【００１６】
トランザクション管理１４は定義情報テーブル１９から取引開始・終了のタイミングを取得する。取引開始後、メッセージ管理１３は送受信したビジネス文書を補助記憶装置１８に保存し、業務処理１２とビジネス文書を受け渡しする。
【００１７】
一括署名管理１６は取引終了のタイミングに基づいて、一括署名処理を開始する。一括署名管理１６は当該トランザクションＩＤに対応するビジネス文書をビジネス文書テーブル２１から検索して、署名処理の対象となるビジネス文書の集合を決定する。
【００１８】
電子署名生成・検証１５は従来例で示したＸＭＬ電子署名の生成及び検証を行う。入力として、一括署名管理１６からビジネス文書の集合を受取り、その集合に対するＸＭＬ電子署名を生成し一括署名管理１６返す。また、入力として一括署名管理１６からビジネス文書の集合及びＸＭＬ電子署名を受取り、その署名が有効かどうかを検証して検証結果を一括署名管理１６に返す。
【００１９】
図３は定義情報テーブル１９の構成を示しており、定義ＩＤ２００、ステップＩＤ２０１、要素種別２０２、次のステップ２０３の項目が設けられている。トランザクション管理１４は定義ＩＤ、及びステップＩＤに基づいて要素種別、次のステップを取得する。
【００２０】
図４はトランザクションテーブル２０の構成を示しており、トランザクションＩＤ２１０、定義ＩＤ２１１、ステップ２１２、状態２１３の項目が設けられている。トランザクション管理１４はトランザクションＩＤ、定義ＩＤに基づいて該当トランザクションを特定し、ステップ、状態を取得、更新する。トランザクション管理１４は該当ステップでの処理完了後、ステップを次に進めテーブルを更新する。また、取引終了段階で状態をコミットまたはキャンセルに更新する。
【００２１】
図５はビジネス文書テーブル２１の構成を示しており、文書ＩＤ２２０、トランザクションＩＤ２２１、内容２２２の項目が設けられている。一括署名管理１５はトランザクションＩＤに基づいて一括して署名処理を行うビジネス文書の内容を取得する。
【００２２】
図６に交換するビジネス文書の例を示す。ビジネス文書は、その取引内容３０３の他に、当該文書を一意に識別可能な識別子として文書ＩＤ３０２を持つ。また、そのビジネス文書がどの取引に属するかを識別する識別子としてトランザクションＩＤ３０１を持つ。
【００２３】
図７に電子署名の例としてＸＭＬ電子署名に従って作成した電子署名を模式的に表す。なお、電子署名方式についてもＸＭＬ電子署名方式だけではなく、その他の署名方式を用いてもよい。従来例に示したとおり、ＸＭＬ電子署名では、複数の文書を署名対象に含めることができる。ＸＭＬ電子署名では署名対象文書を表す識別子とそのハッシュ値を生成し、その組に対して署名値を生成する。本例では交換したビジネス文書の文書ＩＤ３５３、３５６と、その識別子が示すビジネス文書をハッシュ関数により圧縮したハッシュ値３５４、３５７に対して署名を行っている。２つの署名対象３５２、３５５に対する署名が署名値３５８である。これに、本署名がどの取引に対する署名かを表すトランザクションＩＤ３５１がある。
【００２４】
次に図１のフローに基づいて各部の動きを説明する。署名要求側システム１１は定義情報に基づきビジネストランザクションを開始する（ステップ１０１）。
【００２５】
図８はステップ１０１の詳細なフロー図である。
【００２６】
署名要求側システム１１のメッセージ管理がビジネス文書から文書ＩＤ、トランザクションＩＤを取得する（ステップ１２１）。トランザクション管理１３はトランザクションテーブル２０から該当トランザクションＩＤに対応する情報を取得する（ステップ１２２）。当該トランザクションに対応するデータがなかった場合、トランザクション管理１４は一意なトランザクションＩＤを決定し定義情報テーブル１９の次のステップをステップの値としてトランザクションテーブル２０に追加する（ステップ１２４）。次にトランザクション管理１３は定義情報１９から定義情報ＩＤ、ステップＩＤに基づいて定義情報を取得する（ステップ１２５）。定義情報の要素種別が取引開始である場合、メッセージ管理はビジネス文書の保存を開始する（ステップ１２７）。
【００２７】
メッセージ管理１３はビジネス文書をトランザクションＩＤに関連付けてビジネス文書テーブル２１に保存する（ステップ１０２）。メッセージをトランザクションＩＤに関連付けて保存することにより、後述のステップで一括署名が可能となる。
【００２８】
図９はステップ１０２の詳細なフロー図である。ビジネス文書の保存後（ステップ１３１）、トランザクション管理１４がトランザクションテーブル２０の当該トランザクションＩＤに対応するステップを更新する（ステップ１３２）。トランザクション管理１４が指定された定義ＩＤと次のステップに基づいて定義情報テーブル１９から定義情報を取得する（ステップ１３３）。取得した定義情報の要素種別が取引終了で、かつ自システムが署名側システムの場合には一括署名処理を行う。要素種別が取引終了以外か、または署名要求側システムの場合はそのまま終了する（ステップ１３４）。
【００２９】
保存後に、ビジネス文書３００は署名要求側システム１１から署名側システム２５に送信される（ステップ１０３）。ビジネス文書の受信側である署名側システム２５においても、署名要求側と同様に定義情報に基づいてビジネス文書の保存が開始される（ステップ１０１）。メッセージ管理１３ビジネス文書を受信する（ステップ１０４）。受信したビジネス文書は署名要求側システムと同様に署名側システムにおいて保存する（ステップ１０２）。
【００３０】
以上のステップ１００〜１０４までで１回のビジネス文書の送受信が行えたことになる。このビジネス文書の送受信は、署名要求者側システム、および署名者側システムのどちらから送信してもよい。それぞれ複数回行ってもよい。
【００３１】
ステップ１３４において、定義情報テーブル１９から取得した定義情報の要素種別が取引終了である場合、一括署名処理を開始する（ステップ１０５）。一括署名管理１６はビジネス文書テーブル２１から該当トランザクションＩＤに対応するビジネス文書を全て取得する（ステップ１０６）。取得したビジネス文書の集合を、署名対象として電子署名生成・検証１５に渡す。電子署名生成・検証１５では渡された署名対象の文書集合に対する署名を生成する（ステップ１０７）。図７では２つの文書交換が行われた場合を示している。これによりステップ１０１〜１０４で交換したビジネス文書の署名が生成されたことになる。生成した電子署名は署名要求側システム１１に送信する（ステップ１０８）。このとき、署名要求側システム１１もビジネス文書を保存しているので署名対象のビジネス文書は必要ない。代わりに署名対象の取引を識別するトランザクションＩＤ３５１を署名３５０に設定して送付する。
【００３２】
図１において、署名要求側システム１１の一括署名管理１６は署名を受信すると、保存文書に基づいて一括して署名検証を行う（ステップ１０９）。メッセージ管理がビジネス文書から文書ＩＤ、トランザクションＩＤを取得し、それに基づいて、一括署名管理１６はビジネス文書テーブル２１から該当トランザクションＩＤに対応するビジネス文書を全て取得する。（ステップ１１０）。一括署名管理１６は受信した電子署名と、取得したビジネス文書の集合を電子署名生成・検証１５に渡す。電子署名生成・検証１５では渡されたビジネス文書の集合を署名対象として、これ基づいて渡された署名を検証する。（ステップ１１１）。検証手順は従来知られている署名検証方法に従う。例えば、従来例に示した図７のＸＭＬ電子署名の場合、署名値３５８が署名対象３５２、および３５５の正しい署名であることを検証する。さらに、ビジネスドキュメントの文書ＩＤ３５３、３５６とそのハッシュ値３５４，３５７の組が、それぞれ指定したビジネス文書の集合中の文書と同じであることを検証する。本発明の場合、一括署名管理１６が指定した文章に基づいて検証を行う。つまり、ハッシュ値の検証は、一括署名管理１６が指定した文章のハッシュ値と、署名中の識別子によって対応づけられるハッシュ値が等しいことを検証することで行う。
【００３３】
一括署名管理１６は検証結果を判断する（ステップ１１２）。検証結果が正しかった場合、一括署名管理１６はトランザクション管理１４に対してビジネストランザクションのコミットを要求する（ステップ１１３）。検証結果が正しかった場合、署名要求側システムは署名側システムの否認防止を行えたことになる。検証結果が不正だった場合、一括署名管理１６はトランザクション管理１４に対してビジネストランザクションのキャンセルを要求する（ステップ１１４）。
【００３４】
【発明の効果】
以上述べたように、本発明によれば、企業間商取引における否認防止のセキュリティー要件を損なうことなく受領確認メッセージのメッセージ数をビジネストランザクションの決着直前の１回のみに削減できる。また、ビジネストランザクションの最後の段階まで受領確認メッセージを交換しないため、ビジネストランザクションがキャンセルされた場合に無駄になる受領確認メッセージは存在しない。
【図面の簡単な説明】
【図１】本発明の処理手順の実施の形態を示すフロー図である。
【図２】本発明に係る署名要求側システムと署名側システムのシステムブロック図である。
【図３】本発明に係る定義情報テーブルの構成図である。
【図４】本発明に係るトランザクションテーブルの構成図である。
【図５】本発明に係るビジネス文書テーブルの構成図である。
【図６】本発明に係るビジネス文書のリスト図である。
【図７】本発明に係る署名のリスト図である。
【図８】図１におけるステップ１０１の詳細なフロー図である。
【図９】図１におけるステップ１０２の詳細なフロー図である。
【符号の説明】
１０：インターネット、１１：署名要求側システム、１２：業務システム、１３：メッセージ管理、１４：トランザクション管理、１５：電子署名生成・検証、１６：一括署名管理、１９：定義情報テーブル、２１：ビジネス文書テーブル、２５：署名側システム
【図１】
2004320398.tif 000003
【図２】
2004320398.tif 000004
【図３】
2004320398.tif 000005
【図４】
2004320398.tif 000006
【図５】
2004320398.tif 000007
【図６】
2004320398.tif 000008
【図７】
2004320398.tif 000009
【図８】
2004320398.tif 000010
【図９】
2004320398.tif 000011