JP2003249919A - 双方向通信方法 - Google Patents
双方向通信方法Info
- Publication number
- JP2003249919A JP2003249919A JP2002350379A JP2002350379A JP2003249919A JP 2003249919 A JP2003249919 A JP 2003249919A JP 2002350379 A JP2002350379 A JP 2002350379A JP 2002350379 A JP2002350379 A JP 2002350379A JP 2003249919 A JP2003249919 A JP 2003249919A
- Authority
- JP
- Japan
- Prior art keywords
- message
- reception
- request
- response
- signature
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Bidirectional Digital Transmission (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
Abstract
(57)【要約】
【課題】 片方向通信プロトコルで、双方向の送達確認
を可能にし、送受信事実の否認を防止し、メッセージの
一意性を保証する処理の自動化を容易にする。 【解決手段】 リクエスト側１１からの片方向のリクエ
スト／レスポンス型の同期通信のみを用いるシステムに
おいて、レスポンス側１２からリクエスト側１１に向け
てメッセージを送信する際は、リクエスト側がメッセー
ジの受信要求を行ない、リクエスト側がメッセージを受
信したことを、新たな通信でレスポンス側に受信通知す
るまで、レスポンス側は署名とＩＤを含む同じメッセー
ジをリクエスト側に送信し続ける。
を可能にし、送受信事実の否認を防止し、メッセージの
一意性を保証する処理の自動化を容易にする。 【解決手段】 リクエスト側１１からの片方向のリクエ
スト／レスポンス型の同期通信のみを用いるシステムに
おいて、レスポンス側１２からリクエスト側１１に向け
てメッセージを送信する際は、リクエスト側がメッセー
ジの受信要求を行ない、リクエスト側がメッセージを受
信したことを、新たな通信でレスポンス側に受信通知す
るまで、レスポンス側は署名とＩＤを含む同じメッセー
ジをリクエスト側に送信し続ける。
Description
【０００１】
【発明の属する技術分野】本発明は双方向通信方法に関
し、より詳細にはリクエスト側からレスポンス側への片
方向のリクエストとそのリクエストに対するレスポンス
側からリクエスト側へのレスポンスを行うリクエスト／
レスポンス型の同期通信のみを用いるシステムにおい
て、双方向でメッセージを送受信すること、信頼性を保
証すること、及び送受信の否認を防止することを可能に
した双方向通信手法に関する。
し、より詳細にはリクエスト側からレスポンス側への片
方向のリクエストとそのリクエストに対するレスポンス
側からリクエスト側へのレスポンスを行うリクエスト／
レスポンス型の同期通信のみを用いるシステムにおい
て、双方向でメッセージを送受信すること、信頼性を保
証すること、及び送受信の否認を防止することを可能に
した双方向通信手法に関する。
【０００２】
【従来の技術】図１はリクエスト／レスポンス型の同期
通信のみを用いる従来のシステムの構成を示すブロック
図である。図において、１１はリスエスト側であるクラ
イアント、１２はレスポンス側であるサーバ、１３はク
ライアント１１の入口に設けられたファイアウオールで
ある。このように、ファイアウオール１３が設けられて
いると、その内部とその外側との通信は、片方向のリク
エスト／レスポンス型の同期通信を用いることが多い。
通信のみを用いる従来のシステムの構成を示すブロック
図である。図において、１１はリスエスト側であるクラ
イアント、１２はレスポンス側であるサーバ、１３はク
ライアント１１の入口に設けられたファイアウオールで
ある。このように、ファイアウオール１３が設けられて
いると、その内部とその外側との通信は、片方向のリク
エスト／レスポンス型の同期通信を用いることが多い。
【０００３】
【発明が解決しようとする課題】片方向のリクエスト／
レスポンス型の同期通信のみを用いた場合、従来のＨＴ
ＴＰなどのプロトコルでは、図１に示すようにメッセー
ジ送達とその確認はリクエスト側１１からレスポンス側
１２への１方向しか実現できなかった。サーバ側１２か
らクライアント側１１にメッセージを送信しようとして
も、ファイアウオール１３によりブロックされるので、
クライアント側１１には到達しないという問題があっ
た。
レスポンス型の同期通信のみを用いた場合、従来のＨＴ
ＴＰなどのプロトコルでは、図１に示すようにメッセー
ジ送達とその確認はリクエスト側１１からレスポンス側
１２への１方向しか実現できなかった。サーバ側１２か
らクライアント側１１にメッセージを送信しようとして
も、ファイアウオール１３によりブロックされるので、
クライアント側１１には到達しないという問題があっ
た。
【０００４】また、送受信の記録を相手側に提示するだ
けでは、確かに送受信をしたという証拠とならないの
で、送信事実を受信側が否認したり、受信事実を送信側
が否認したりすることができてしまうという問題もあっ
た。このような、送信事実の否認、受信事実の否認は、
特にインターネットを介して金銭取引を行う場合等にお
いて重大である。
けでは、確かに送受信をしたという証拠とならないの
で、送信事実を受信側が否認したり、受信事実を送信側
が否認したりすることができてしまうという問題もあっ
た。このような、送信事実の否認、受信事実の否認は、
特にインターネットを介して金銭取引を行う場合等にお
いて重大である。
【０００５】本発明の目的は、上記従来技術における問
題に鑑み、片方向のリクエスト／レスポンス型の通信プ
ロトコルを用いて、後述する再送手順により双方向の送
達確認を可能にする通信方法を提供することにある。
題に鑑み、片方向のリクエスト／レスポンス型の通信プ
ロトコルを用いて、後述する再送手順により双方向の送
達確認を可能にする通信方法を提供することにある。
【０００６】本発明の他の目的は、上記通信方法におい
て、メッセージに一意の識別子を付加したり、送受信さ
れたメッセージに対して署名を作成し、これを交換する
ことにより、送受信が確かに行なわれたことを証拠とし
て残し、それにより、送信事実、受信事実の否認を防止
することにある。
て、メッセージに一意の識別子を付加したり、送受信さ
れたメッセージに対して署名を作成し、これを交換する
ことにより、送受信が確かに行なわれたことを証拠とし
て残し、それにより、送信事実、受信事実の否認を防止
することにある。
【０００７】本発明のさらに他の目的は、ＸＭＬ(Exten
sive Markup Language)を用いてメッセージを構築する
ことにより、メッセージの一意性を保証する処理の自動
化を容易にすることにある。
sive Markup Language)を用いてメッセージを構築する
ことにより、メッセージの一意性を保証する処理の自動
化を容易にすることにある。
【０００８】
【課題を解決するための手段】上記の目的を達成するた
めに、本発明の第１の態様により、レスポンス側からリ
クエスト側に向けてメッセージを送信する際は、リクエ
スト側がメッセージの受信要求を行ない、リクエスト側
がメッセージを受信したことを、新たな通信でレスポン
ス側に受信通知するまで、レスポンス側は同じメッセー
ジをリクエスト側に送信し続けることにより、双方向で
メッセージの送受信を可能にした双方向通信手法が提供
される。
めに、本発明の第１の態様により、レスポンス側からリ
クエスト側に向けてメッセージを送信する際は、リクエ
スト側がメッセージの受信要求を行ない、リクエスト側
がメッセージを受信したことを、新たな通信でレスポン
ス側に受信通知するまで、レスポンス側は同じメッセー
ジをリクエスト側に送信し続けることにより、双方向で
メッセージの送受信を可能にした双方向通信手法が提供
される。
【０００９】リクエスト側からの受信要求に応じてであ
れば、レスポンス側はメッセージをリクエスト側に送信
できるので、リクエスト側からとレスポンス側からの双
方向からメッセージの送信が可能になる。
れば、レスポンス側はメッセージをリクエスト側に送信
できるので、リクエスト側からとレスポンス側からの双
方向からメッセージの送信が可能になる。
【００１０】本発明の第２の態様により、上記第１の態
様において、送信するメッセージ内に一意の識別子を付
加し、受信側で重複チェックを行なうことにより、同じ
メッセージを重複して受信することを防ぐようにした。
様において、送信するメッセージ内に一意の識別子を付
加し、受信側で重複チェックを行なうことにより、同じ
メッセージを重複して受信することを防ぐようにした。
【００１１】本発明の第３の態様により、上記第２の態
様において、メッセージの形式にＸＭＬを利用し、メッ
セージとは異なる特定のネームスペースでメッセージ内
に識別子を付加することで、メッセージの形式を変更せ
ずに、同じメッセージを重複して受信することを防ぐよ
うにした。
様において、メッセージの形式にＸＭＬを利用し、メッ
セージとは異なる特定のネームスペースでメッセージ内
に識別子を付加することで、メッセージの形式を変更せ
ずに、同じメッセージを重複して受信することを防ぐよ
うにした。
【００１２】本発明の第４の態様により、上記第１の態
様において、メッセージの一意性は任意の形で実現し、
メッセージの一意性を検証する際に、メッセージのダイ
ジェスト値を利用することで、同じメッセージを重複し
て受信することを防ぐようにした。
様において、メッセージの一意性は任意の形で実現し、
メッセージの一意性を検証する際に、メッセージのダイ
ジェスト値を利用することで、同じメッセージを重複し
て受信することを防ぐようにした。
【００１３】上記第２から第４の態様により、同じメッ
セージを重複して受信することを防ぐことができるの
で、通信効率を向上させることができる。
セージを重複して受信することを防ぐことができるの
で、通信効率を向上させることができる。
【００１４】本発明の第５の態様により、上記第２から
第４の態様のいずれかにおいて、メッセージの送信側が
送信するメッセージに対して送信メッセージ用電子署名
を付加し、この送信メッセージ用署名を受信側が保管す
ることによって送信側による送信事実の否認を防止する
ことができるようにすることと、メッセージの受信側が
メッセージの受信に応答して送信するメッセージ受信通
知に、受信通知用電子署名を付加し、この受信通知用電
子署名を、送信側が保管することによって受信側による
受信事実の否認を防止することができるようにすること
と、の少なくとも一方を採用する。
第４の態様のいずれかにおいて、メッセージの送信側が
送信するメッセージに対して送信メッセージ用電子署名
を付加し、この送信メッセージ用署名を受信側が保管す
ることによって送信側による送信事実の否認を防止する
ことができるようにすることと、メッセージの受信側が
メッセージの受信に応答して送信するメッセージ受信通
知に、受信通知用電子署名を付加し、この受信通知用電
子署名を、送信側が保管することによって受信側による
受信事実の否認を防止することができるようにすること
と、の少なくとも一方を採用する。
【００１５】これにより、送信側による送信事実の否認
や受信側による受信事実の否認を防止することができ
る。
や受信側による受信事実の否認を防止することができ
る。
【００１６】
【発明の実施の形態】以下、本発明の実施の形態を図面
を参照しながら説明する。以下の説明で同一参照番号は
同一のものを表し、図１に示したファイアウオール１３
は図面の簡単化のために図示を省略してある。
を参照しながら説明する。以下の説明で同一参照番号は
同一のものを表し、図１に示したファイアウオール１３
は図面の簡単化のために図示を省略してある。
【００１７】図２は、本発明の第１の実施の形態により
リクエスト側１１からレスポンス側１２にメッセージの
送信する場合のデータの流れを示すブロック図である。
リクエスト側１１の例としては、商品の売主や買主等、
サーバを持たないクライアントがある。レスポンス側１
２の例としては、申し込み書等をデータベースに保管し
ているセンタの役割を果たすサーバがある。
リクエスト側１１からレスポンス側１２にメッセージの
送信する場合のデータの流れを示すブロック図である。
リクエスト側１１の例としては、商品の売主や買主等、
サーバを持たないクライアントがある。レスポンス側１
２の例としては、申し込み書等をデータベースに保管し
ているセンタの役割を果たすサーバがある。
【００１８】図３は図２に示したメッセージを送信する
場合の処理の流れを説明するフローチャートである。
場合の処理の流れを説明するフローチャートである。
【００１９】図２および図３で説明するメッセージの送
信自体は、従来の片方向通信で行われていたものであ
る。
信自体は、従来の片方向通信で行われていたものであ
る。
【００２０】図２及び図３において、リクエスト側１１
では、ステップＳ３１で１つ又は複数のメッセージを作
成し、ステップＳ３２でそのメッセージを保管し、ステ
ップＳ３３で送信したいメッセージ２１をレスポンス側
１２に送信する。メッセージ２１には受信通知の返信を
要求するリクエストが含まれている。
では、ステップＳ３１で１つ又は複数のメッセージを作
成し、ステップＳ３２でそのメッセージを保管し、ステ
ップＳ３３で送信したいメッセージ２１をレスポンス側
１２に送信する。メッセージ２１には受信通知の返信を
要求するリクエストが含まれている。
【００２１】レスポンス側１２では、ステップＳ３４で
そのメッセージを受信し、ステップＳ３５で受信したメ
ッセージ中のＩＤ（識別子）と同じＩＤがレスポンス側
１２に存在するかを検索する。その検索の結果ステップ
Ｓ３６で同じＩＤがレスポンス側１２に存在しなけれ
ば、今回受信したメッセージは新たなメッセージなの
で、ステップＳ３７にて受信メッセージを保管し、ステ
ップＳ３８で受信通知を作成する。ステップＳ３６の検
索の結果、同じＩＤがレスポンス側１２に存在すれば、
受信済みのメッセージなので、今回受信したメッセージ
は保管せずに、ステップＳ３８にて受信通知を作成す
る。次いでステップＳ３９にて受信通知２２をリクエス
ト側１１に向けて返信する。受信通知２２には、リクエ
ストに対するレスポンスである旨の情報が含まれてい
る。
そのメッセージを受信し、ステップＳ３５で受信したメ
ッセージ中のＩＤ（識別子）と同じＩＤがレスポンス側
１２に存在するかを検索する。その検索の結果ステップ
Ｓ３６で同じＩＤがレスポンス側１２に存在しなけれ
ば、今回受信したメッセージは新たなメッセージなの
で、ステップＳ３７にて受信メッセージを保管し、ステ
ップＳ３８で受信通知を作成する。ステップＳ３６の検
索の結果、同じＩＤがレスポンス側１２に存在すれば、
受信済みのメッセージなので、今回受信したメッセージ
は保管せずに、ステップＳ３８にて受信通知を作成す
る。次いでステップＳ３９にて受信通知２２をリクエス
ト側１１に向けて返信する。受信通知２２には、リクエ
ストに対するレスポンスである旨の情報が含まれてい
る。
【００２２】リクエスト側１１ではステップＳ４０にて
所定時間間隔毎に上記受信通知２２の受信を監視し、ス
テップＳ４１にて対応するメッセージを送信したか、即
ちステップＳ３３にてリクエスト側１１から送信された
メッセージがレスポンス側１２に正常に受信されたかを
受信通知２２の有無により判断し、未だ受信通知２２を
受信していない場合は対応するメッセージ２１を送信し
ていないと判断してステップＳ３３に戻りメッセージ２
１をレスポンス側１２に再送する。
所定時間間隔毎に上記受信通知２２の受信を監視し、ス
テップＳ４１にて対応するメッセージを送信したか、即
ちステップＳ３３にてリクエスト側１１から送信された
メッセージがレスポンス側１２に正常に受信されたかを
受信通知２２の有無により判断し、未だ受信通知２２を
受信していない場合は対応するメッセージ２１を送信し
ていないと判断してステップＳ３３に戻りメッセージ２
１をレスポンス側１２に再送する。
【００２３】ステップＳ４１の判断でメッセージ２１が
送信済みと判定された場合は、ステップＳ４２にてリク
エスト側１１に保管されている対応するメッセージ２１
を削除する。
送信済みと判定された場合は、ステップＳ４２にてリク
エスト側１１に保管されている対応するメッセージ２１
を削除する。
【００２４】上記図２及び図３により説明した、リクエ
スト側１１からレスポンス側１２側への片方向メッセー
ジの送信自体は従来から可能であった。
スト側１１からレスポンス側１２側への片方向メッセー
ジの送信自体は従来から可能であった。
【００２５】図４は本発明の第１の実施の形態により双
方向通信を可能にする場合のデータの流れを示すブロッ
ク図であり、図５は図４に示したメッセージを送信する
場合の処理の流れを説明するフローチャートである。
方向通信を可能にする場合のデータの流れを示すブロッ
ク図であり、図５は図４に示したメッセージを送信する
場合の処理の流れを説明するフローチャートである。
【００２６】図４及び図５において、レスポンス側１２
では、ステップＳ５１で１つ又は複数のメッセージを作
成し、ステップＳ５２でそのメッセージを保管してお
く。
では、ステップＳ５１で１つ又は複数のメッセージを作
成し、ステップＳ５２でそのメッセージを保管してお
く。
【００２７】リクエスト側１１では、ステップＳ５３に
て受信要求４１をレスポンス側１２に送信する。レスポ
ンス側１２はステップＳ５４でこの受信要求４１を受信
し、ステップＳ５５でその受信要求に応ずるメッセージ
４２を保管されているメッセージの中から検索する。受
信要求に応ずるメッセージ４２が存在すればステップＳ
５６にてそのメッセージ４２をリクエスト側１１に送信
する。
て受信要求４１をレスポンス側１２に送信する。レスポ
ンス側１２はステップＳ５４でこの受信要求４１を受信
し、ステップＳ５５でその受信要求に応ずるメッセージ
４２を保管されているメッセージの中から検索する。受
信要求に応ずるメッセージ４２が存在すればステップＳ
５６にてそのメッセージ４２をリクエスト側１１に送信
する。
【００２８】リクエスト側１１ではそのメッセージ４２
をステップＳ５７で受信し、ステップＳ５８で受信した
メッセージ中のＩＤ（識別子）と同じＩＤがリクエスト
側１１に存在するかを検索する。検索した結果、ステッ
プＳ５９で同じＩＤがリクエスト側１１に存在しなけれ
ば、今回受信したメッセージは新たなメッセージなの
で、ステップＳ６０にて受信メッセージを保管し、ステ
ップＳ６１で受信通知４３を作成する。ステップＳ５９
の検索の結果、同じＩＤがリクエスト側１１に存在すれ
ば、受信済みのメッセージなので、今回受信したメッセ
ージは保管せずに、ステップＳ６１にて受信通知４３を
作成する。次いでステップＳ６２にて受信通知４３をレ
スポンス側１２に向けて返信する。
をステップＳ５７で受信し、ステップＳ５８で受信した
メッセージ中のＩＤ（識別子）と同じＩＤがリクエスト
側１１に存在するかを検索する。検索した結果、ステッ
プＳ５９で同じＩＤがリクエスト側１１に存在しなけれ
ば、今回受信したメッセージは新たなメッセージなの
で、ステップＳ６０にて受信メッセージを保管し、ステ
ップＳ６１で受信通知４３を作成する。ステップＳ５９
の検索の結果、同じＩＤがリクエスト側１１に存在すれ
ば、受信済みのメッセージなので、今回受信したメッセ
ージは保管せずに、ステップＳ６１にて受信通知４３を
作成する。次いでステップＳ６２にて受信通知４３をレ
スポンス側１２に向けて返信する。
【００２９】レスポンス側１２ではステップＳ６３にて
所定時間間隔毎に上記受信通知４３の受信を監視し、ス
テップＳ６４にて対応するメッセージを送信したか、即
ちステップＳ６３にてレスポンス側１２から返信された
メッセージがリクエスト側１１に正常に受信されたかを
受信通知４３の有無により判断し、受信通知４３が受信
されていればメッセージ４２がリクエスト側１１からレ
スポンス側１２に送信済みと判定され、ステップＳ６５
にてレスポンス側１２に保管されている、受信要求４１
に対応するメッセージ４２を削除する。
所定時間間隔毎に上記受信通知４３の受信を監視し、ス
テップＳ６４にて対応するメッセージを送信したか、即
ちステップＳ６３にてレスポンス側１２から返信された
メッセージがリクエスト側１１に正常に受信されたかを
受信通知４３の有無により判断し、受信通知４３が受信
されていればメッセージ４２がリクエスト側１１からレ
スポンス側１２に送信済みと判定され、ステップＳ６５
にてレスポンス側１２に保管されている、受信要求４１
に対応するメッセージ４２を削除する。
【００３０】未だ受信通知４３を受信していない場合は
ステップＳ６６にて処理を終了する。
ステップＳ６６にて処理を終了する。
【００３１】リクエスト側１１からレスポンス側１２に
は受信要求４１が定期的に送信されるので、このメッセ
ージ４２の送信はリクエスト側１１から受信通知４３が
到着するまで、定期的に繰り返し行われる。受信通知４
３がリクエスト側１１から送られなければ、レスポンス
側１２ではメッセージ４２が確かにリクエスト側１１に
届いたかどうか不明であるが、本発明の実施の形態によ
り、メッセージ４２の受信に応答して受信通知４３をリ
クエスト側１１からレスポンス側１２に返信するように
したことにより、レスポンス側１２では確実にメッセー
ジ４２がリクエスト側に届いたことを認識でき、結果的
に双方向のメッセージの遣り取りが可能になる。
は受信要求４１が定期的に送信されるので、このメッセ
ージ４２の送信はリクエスト側１１から受信通知４３が
到着するまで、定期的に繰り返し行われる。受信通知４
３がリクエスト側１１から送られなければ、レスポンス
側１２ではメッセージ４２が確かにリクエスト側１１に
届いたかどうか不明であるが、本発明の実施の形態によ
り、メッセージ４２の受信に応答して受信通知４３をリ
クエスト側１１からレスポンス側１２に返信するように
したことにより、レスポンス側１２では確実にメッセー
ジ４２がリクエスト側に届いたことを認識でき、結果的
に双方向のメッセージの遣り取りが可能になる。
【００３２】このように、リクエスト側１１に設けられ
たフィアウオールでリクエスト側１１からのみ外部にメ
ッセージを送ることができるシステムにおいて、レスポ
ンス側１２からリクエスト側１１にメッセージを送信す
る必要性及びレスポンス側１２から送られたメッセージ
がリクエスト側１１に確実に受信されたことを認識でき
る必要性は、特に金融に関する通信や企業内のクライア
ントと企業外の別の企業との間の文書の通信や、レスポ
ンス側１２で発行する何らかの申し込み書等で必要にな
る。例えば、申し込み書の配信等のように、レスポンス
側１２から送られるウェブブラウザの画面中にメッセー
ジを含ませたいという要求がある。従来ではこの場合、
レスポンス側１２からリクエスト側１１へのメッセージ
の配信は不可能であったが、本発明の実施の形態によれ
ば上記のように確実にメッセージをレスポンス側１２か
らリクエスト側１１に配信することが可能になる。
たフィアウオールでリクエスト側１１からのみ外部にメ
ッセージを送ることができるシステムにおいて、レスポ
ンス側１２からリクエスト側１１にメッセージを送信す
る必要性及びレスポンス側１２から送られたメッセージ
がリクエスト側１１に確実に受信されたことを認識でき
る必要性は、特に金融に関する通信や企業内のクライア
ントと企業外の別の企業との間の文書の通信や、レスポ
ンス側１２で発行する何らかの申し込み書等で必要にな
る。例えば、申し込み書の配信等のように、レスポンス
側１２から送られるウェブブラウザの画面中にメッセー
ジを含ませたいという要求がある。従来ではこの場合、
レスポンス側１２からリクエスト側１１へのメッセージ
の配信は不可能であったが、本発明の実施の形態によれ
ば上記のように確実にメッセージをレスポンス側１２か
らリクエスト側１１に配信することが可能になる。
【００３３】尚、メッセージの送受信にはＳＯＡＰ（Si
mple Object Access Protocol）等のプロトコルを用い
て実現できる。
mple Object Access Protocol）等のプロトコルを用い
て実現できる。
【００３４】図６は本発明の第２の実施の形態によりメ
ッセージ中の定まったフォーマットの中の特定の場所に
メッセージの識別子（ＩＤ）を埋め込む方法を説明する
図である。図において、ルートタグ＜Order＞からルー
トタグ＜/Order＞までが定まったフォーマットの注文書
のメッセージであり、このメッセージ中のmessageIdと
いう２つのタグの間にＩＤとして"12345678"が埋め込ま
れている。受信側ではこのメッセージのフォーマットを
知っているので受信メッセージ中のＩＤを自分が持つＩ
Ｄと照合することにより受信済みメッセージかどうかを
判断する。図示例はＸＭＬで記載された注文書のメッセ
ージを例としてあげてあるが、定まったフォーマットの
メッセージであればどのような言語で記載されていても
よい。これにより、受信側ではプログラムが解釈可能な
フォーマットからメッセージＩＤを検索可能になる。
ッセージ中の定まったフォーマットの中の特定の場所に
メッセージの識別子（ＩＤ）を埋め込む方法を説明する
図である。図において、ルートタグ＜Order＞からルー
トタグ＜/Order＞までが定まったフォーマットの注文書
のメッセージであり、このメッセージ中のmessageIdと
いう２つのタグの間にＩＤとして"12345678"が埋め込ま
れている。受信側ではこのメッセージのフォーマットを
知っているので受信メッセージ中のＩＤを自分が持つＩ
Ｄと照合することにより受信済みメッセージかどうかを
判断する。図示例はＸＭＬで記載された注文書のメッセ
ージを例としてあげてあるが、定まったフォーマットの
メッセージであればどのような言語で記載されていても
よい。これにより、受信側ではプログラムが解釈可能な
フォーマットからメッセージＩＤを検索可能になる。
【００３５】図７は本発明の第３の実施の形態によりメ
ッセージ内にメッセージ内容とは別にネームスペースで
メッセージＩＤを埋め込む方法を説明する図である。図
において、ルートタグ＜Order＞からルートタグ＜/Orde
r＞までは図６と同じく注文書のメッセージであるが、
このメッセージ中のプレフィックスssrs：とその後の属
性名messageIdの後に="12345678"というメッセージＩＤ
を埋め込んである。これにより、受信側ではプログラム
によりプレフィックスの属性を探せば、ＩＤを見つける
ことができ、メッセージの一意性を検証することができ
る。
ッセージ内にメッセージ内容とは別にネームスペースで
メッセージＩＤを埋め込む方法を説明する図である。図
において、ルートタグ＜Order＞からルートタグ＜/Orde
r＞までは図６と同じく注文書のメッセージであるが、
このメッセージ中のプレフィックスssrs：とその後の属
性名messageIdの後に="12345678"というメッセージＩＤ
を埋め込んである。これにより、受信側ではプログラム
によりプレフィックスの属性を探せば、ＩＤを見つける
ことができ、メッセージの一意性を検証することができ
る。
【００３６】図７の例では、ルートタグとして＜Order
＞を用いているが、プレフィクスとその属性ssrs:messa
geId=の後にメッセージＩＤを埋め込めばよいので、ル
ートタグが何であってもＩＤを見つけることができる。
また、メッセージのフォーマットが何であってもよい。
＞を用いているが、プレフィクスとその属性ssrs:messa
geId=の後にメッセージＩＤを埋め込めばよいので、ル
ートタグが何であってもＩＤを見つけることができる。
また、メッセージのフォーマットが何であってもよい。
【００３７】図８は本発明の第４の実施の形態により、
メッセージのダイジェストを利用してメッセージの一意
性を検証する方法を説明する図である。この場合は、ル
ートタグ＜Order＞からルートタグ＜/Order＞までのメ
ッセージの中の任意の場所に＜orderId＞order01234567
8＜/orderId＞というＩＤを含む記号を挿入した後に、
ＳＨＡ１，ＭＤ５等のアルゴリズムに従ってこのメッセ
ージをダイジェストに圧縮して送信する。受信側でこの
ダイジェストを所定のアルゴリズムを用いて計算する。
受信メッセージの内容及びＩＤのいずれかが、既に受信
したメッセージの内容及びＩＤのいずれかと異なれば、
ダイジェストの計算値も異なる、受信メッセージの内容
及びＩＤのいずれもが、既に受信したメッセージの内容
及びＩＤのいずれもと一致していれば、ダイジェストの
計算値も一致する。これによっても、受信メッセージの
一意性の検証が可能になる。図８においても、メッセー
ジは注文書に限定されずどのような内容でもよい。ま
た、メッセージのフォーマットも任意でよい。
メッセージのダイジェストを利用してメッセージの一意
性を検証する方法を説明する図である。この場合は、ル
ートタグ＜Order＞からルートタグ＜/Order＞までのメ
ッセージの中の任意の場所に＜orderId＞order01234567
8＜/orderId＞というＩＤを含む記号を挿入した後に、
ＳＨＡ１，ＭＤ５等のアルゴリズムに従ってこのメッセ
ージをダイジェストに圧縮して送信する。受信側でこの
ダイジェストを所定のアルゴリズムを用いて計算する。
受信メッセージの内容及びＩＤのいずれかが、既に受信
したメッセージの内容及びＩＤのいずれかと異なれば、
ダイジェストの計算値も異なる、受信メッセージの内容
及びＩＤのいずれもが、既に受信したメッセージの内容
及びＩＤのいずれもと一致していれば、ダイジェストの
計算値も一致する。これによっても、受信メッセージの
一意性の検証が可能になる。図８においても、メッセー
ジは注文書に限定されずどのような内容でもよい。ま
た、メッセージのフォーマットも任意でよい。
【００３８】図９は本発明の第５の実施の形態により送
信者による送信の事実を後に送信者が否認することを防
止する方法におけるデータの流れを説明するブロック図
であり、図１０は図９に示したシステムにおいて、リク
エスト側１１からレスポンス側１２にメッセージを送信
する場合において、送信事実の送信者による否認を防止
する処理の流れを説明するフローチャートである。
信者による送信の事実を後に送信者が否認することを防
止する方法におけるデータの流れを説明するブロック図
であり、図１０は図９に示したシステムにおいて、リク
エスト側１１からレスポンス側１２にメッセージを送信
する場合において、送信事実の送信者による否認を防止
する処理の流れを説明するフローチャートである。
【００３９】図１０と図３との相違点は、図１０におい
てはリクエスト側１１でステップＳ１０２にて送信署名
を作成し、レスポンス側１２でステップＳ１０６及びス
テップＳ１０７で送信署名の検証をし、ステップＳ１１
１でメッセージの外に署名も保管し、リクエスト側１１
でステップＳ１１５にて送信署名エラーが返信されたか
を判断することが追加されていることである。
てはリクエスト側１１でステップＳ１０２にて送信署名
を作成し、レスポンス側１２でステップＳ１０６及びス
テップＳ１０７で送信署名の検証をし、ステップＳ１１
１でメッセージの外に署名も保管し、リクエスト側１１
でステップＳ１１５にて送信署名エラーが返信されたか
を判断することが追加されていることである。
【００４０】より詳細には、図９及び図１０において、
リクエスト側１１では、ステップＳ１０１で１つ又は複
数のメッセージを作成し、ステップＳ１０２で送信者だ
けが作成できる送信者署名を作成し、ステップＳ１０３
でその署名をメッセージとともに保管し、ステップＳ１
０４で送信したいメッセージ２１ａをレスポンス側１２
に送信する。メッセージ２１には受信通知の返信を要求
するリクエストと署名とが含まれている。
リクエスト側１１では、ステップＳ１０１で１つ又は複
数のメッセージを作成し、ステップＳ１０２で送信者だ
けが作成できる送信者署名を作成し、ステップＳ１０３
でその署名をメッセージとともに保管し、ステップＳ１
０４で送信したいメッセージ２１ａをレスポンス側１２
に送信する。メッセージ２１には受信通知の返信を要求
するリクエストと署名とが含まれている。
【００４１】レスポンス側１２では、ステップＳ１０５
でそのメッセージを受信し、ステップＳ１０６で送信署
名を送信者の公開鍵で検証する。ステップＳ１０７でそ
の検証結果が不正な署名であれば、ステップＳ１０８に
進んで署名検証エラーを受信通知２２に載せてリクエス
ト側１１に返信する。ステップＳ１０７で署名の検証結
果が正しければ、ステップＳ１０９にて図６から図８の
いずれかの方法により、受信したメッセージ中のＩＤ
（識別子）と同じＩＤがレスポンス側１２に存在するか
を検索する。その検索の結果ステップＳ１１０にて同じ
ＩＤがレスポンス側１２に存在しなければ、今回受信し
たメッセージは新たなメッセージなので、ステップＳ１
１１にて受信メッセージと共に送信者の署名９０をデー
タベース９１に保管し、ステップＳ１１２で受信通知を
作成する。ステップＳ１１０の検索の結果、受信メッセ
ージがレスポンス側１２に存在すれば、受信済みのメッ
セージなので、今回受信したメッセージは保管せずに、
ステップＳ１１２にて受信通知を作成する。次いでステ
ップＳ１１３にて受信通知２２をリクエスト側１１に向
けて返信する。受信通知２２には、リクエストに対する
レスポンスである旨の情報が含まれている。
でそのメッセージを受信し、ステップＳ１０６で送信署
名を送信者の公開鍵で検証する。ステップＳ１０７でそ
の検証結果が不正な署名であれば、ステップＳ１０８に
進んで署名検証エラーを受信通知２２に載せてリクエス
ト側１１に返信する。ステップＳ１０７で署名の検証結
果が正しければ、ステップＳ１０９にて図６から図８の
いずれかの方法により、受信したメッセージ中のＩＤ
（識別子）と同じＩＤがレスポンス側１２に存在するか
を検索する。その検索の結果ステップＳ１１０にて同じ
ＩＤがレスポンス側１２に存在しなければ、今回受信し
たメッセージは新たなメッセージなので、ステップＳ１
１１にて受信メッセージと共に送信者の署名９０をデー
タベース９１に保管し、ステップＳ１１２で受信通知を
作成する。ステップＳ１１０の検索の結果、受信メッセ
ージがレスポンス側１２に存在すれば、受信済みのメッ
セージなので、今回受信したメッセージは保管せずに、
ステップＳ１１２にて受信通知を作成する。次いでステ
ップＳ１１３にて受信通知２２をリクエスト側１１に向
けて返信する。受信通知２２には、リクエストに対する
レスポンスである旨の情報が含まれている。
【００４２】リクエスト側１１ではステップＳ１１４に
て所定時間間隔毎に上記受信通知２２の受信を監視し、
ステップＳ１１５にて送信署名エラーが返信されたかを
判定し、送信署名エラーが返信された場合はステップＳ
１１６にてエラー処理をする。
て所定時間間隔毎に上記受信通知２２の受信を監視し、
ステップＳ１１５にて送信署名エラーが返信されたかを
判定し、送信署名エラーが返信された場合はステップＳ
１１６にてエラー処理をする。
【００４３】ステップＳ１１５の判断で送信署名エラー
でないと判定されると、ステップＳ１１７にて対応する
メッセージを送信したかに正常に受信されたか、即ちス
テップＳ１０４にてリクエスト側１１から送信されたメ
ッセージがレスポンス側１２を受信通知２２の有無によ
り判断し、未だ受信通知２２を受信していない場合は対
応するメッセージ２１ａを送信していないと判断してス
テップＳ１０４に戻りメッセージ２１ａをレスポンス側
１２に再送する。
でないと判定されると、ステップＳ１１７にて対応する
メッセージを送信したかに正常に受信されたか、即ちス
テップＳ１０４にてリクエスト側１１から送信されたメ
ッセージがレスポンス側１２を受信通知２２の有無によ
り判断し、未だ受信通知２２を受信していない場合は対
応するメッセージ２１ａを送信していないと判断してス
テップＳ１０４に戻りメッセージ２１ａをレスポンス側
１２に再送する。
【００４４】ステップＳ１１７の判断でメッセージ２１
ａが送信済みと判定された場合は、ステップＳ１１８に
てリクエスト側１１に保管されている対応するメッセー
ジ２１を削除する。
ａが送信済みと判定された場合は、ステップＳ１１８に
てリクエスト側１１に保管されている対応するメッセー
ジ２１を削除する。
【００４５】これにより、リクエスト側１１が送信した
事実を否認しても、レスポンス側１２のデータベース９
１にはリクエスト側１１でのみ作成可能な署名が格納さ
れているので、リクエスト側１１による送信事実の否認
をレスポンス側１２は拒否できる。
事実を否認しても、レスポンス側１２のデータベース９
１にはリクエスト側１１でのみ作成可能な署名が格納さ
れているので、リクエスト側１１による送信事実の否認
をレスポンス側１２は拒否できる。
【００４６】図１１は、図９に示したシステムにおい
て、レスポンス側１２からリクエスト側１１にメッセー
ジを送信する場合において、送信事実の送信者による否
認を防止する処理の流れを説明するフローチャートであ
る。
て、レスポンス側１２からリクエスト側１１にメッセー
ジを送信する場合において、送信事実の送信者による否
認を防止する処理の流れを説明するフローチャートであ
る。
【００４７】図１１と図５との相違点は、図１１におい
ては、レスポンス側１２でステップＳ１２２にて送信署
名を作成し、リクエスト側１１ではステップＳ１２９、
ステップＳ１３０及びステップＳ１３１で送信署名検証
を行い、ステップＳ１３４でメッセージの外に署名も保
管し、レスポンス側１２ではステップＳ１３８及びステ
ップＳ１３９で送信署名エラーかを判断し処理すること
が追加されていることである。
ては、レスポンス側１２でステップＳ１２２にて送信署
名を作成し、リクエスト側１１ではステップＳ１２９、
ステップＳ１３０及びステップＳ１３１で送信署名検証
を行い、ステップＳ１３４でメッセージの外に署名も保
管し、レスポンス側１２ではステップＳ１３８及びステ
ップＳ１３９で送信署名エラーかを判断し処理すること
が追加されていることである。
【００４８】より詳細には、図９及び図１１において、
レスポンス側１２では、ステップＳ１２１で１つ又は複
数のメッセージを作成し、ステップＳ１２２で送信者の
みが作成できる送信書名を作成する。次いでステップＳ
１２３でその送信署名をメッセージとともに保管してお
く。
レスポンス側１２では、ステップＳ１２１で１つ又は複
数のメッセージを作成し、ステップＳ１２２で送信者の
みが作成できる送信書名を作成する。次いでステップＳ
１２３でその送信署名をメッセージとともに保管してお
く。
【００４９】リクエスト側１１では、ステップＳ１２４
にて受信要求４１をレスポンス側１２に送信する。レス
ポンス側１２はステップＳ１２５でこの受信要求４１を
受信し、ステップＳ１２６でその受信要求に応ずるメッ
セージ４２を保管されているメッセージの中から検索す
る。受信要求に応ずるメッセージ４２ａが存在すればス
テップＳ１２７にてそのメッセージ４２ａに署名９２を
含ませてリクエスト側１１に送信する。
にて受信要求４１をレスポンス側１２に送信する。レス
ポンス側１２はステップＳ１２５でこの受信要求４１を
受信し、ステップＳ１２６でその受信要求に応ずるメッ
セージ４２を保管されているメッセージの中から検索す
る。受信要求に応ずるメッセージ４２ａが存在すればス
テップＳ１２７にてそのメッセージ４２ａに署名９２を
含ませてリクエスト側１１に送信する。
【００５０】リクエスト側１１ではそのメッセージ４２
ａをステップＳ１２８で受信し、ステップＳ１２９で受
信したメッセージ中の送信署名が正しいかどうかを送信
者の公開鍵で検証する。正しくなければステップＳ１３
１で署名検証エラーをレスポンス側１２に返信する。正
しければステップＳ１３２及びステップＳ１３３にて受
信メッセージ中のＩＤ（識別子）と同じＩＤがリクエス
ト側１１に存在するかを検索する。検索した結果、同じ
ＩＤがレスポンス側１２に存在しなければ、今回受信し
たメッセージは新たなメッセージなので、ステップＳ１
３４にて受信メッセージを署名９２とともにデータベー
ス９３に保管し、ステップＳ１３５で受信通知４３を作
成する。ステップＳ１３３の検索の結果、同じＩＤがリ
クエスト側１１に存在すれば、受信済みのメッセージな
ので、今回受信したメッセージは保管せずに、ステップ
Ｓ１３５にて受信通知４３を作成する。次いでステップ
Ｓ１３６にてその受信通知をレスポンス側１２に向けて
返信する。
ａをステップＳ１２８で受信し、ステップＳ１２９で受
信したメッセージ中の送信署名が正しいかどうかを送信
者の公開鍵で検証する。正しくなければステップＳ１３
１で署名検証エラーをレスポンス側１２に返信する。正
しければステップＳ１３２及びステップＳ１３３にて受
信メッセージ中のＩＤ（識別子）と同じＩＤがリクエス
ト側１１に存在するかを検索する。検索した結果、同じ
ＩＤがレスポンス側１２に存在しなければ、今回受信し
たメッセージは新たなメッセージなので、ステップＳ１
３４にて受信メッセージを署名９２とともにデータベー
ス９３に保管し、ステップＳ１３５で受信通知４３を作
成する。ステップＳ１３３の検索の結果、同じＩＤがリ
クエスト側１１に存在すれば、受信済みのメッセージな
ので、今回受信したメッセージは保管せずに、ステップ
Ｓ１３５にて受信通知４３を作成する。次いでステップ
Ｓ１３６にてその受信通知をレスポンス側１２に向けて
返信する。
【００５１】レスポンス側１２ではステップＳ１３７に
て所定時間間隔毎に上記受信通知４３の受信を監視し、
ステップＳ１３８にて送信署名がエラーかを判断する。
エラーであれば、ステップＳ１３９にてエラー処理をす
る。エラーでなければステップＳ１４０にて対応するメ
ッセージを送信したか、即ちステップＳ１２７にてレス
ポンス側１２から返信されたメッセージがリクエスト側
１１に正常に受信されたかを受信通知４３の有無により
判断し、メッセージ４２ａが送信済みと判定された場合
は、ステップＳ１４１にてレスポンス側１２に保管され
ている対応するメッセージ４２ａを削除する。
て所定時間間隔毎に上記受信通知４３の受信を監視し、
ステップＳ１３８にて送信署名がエラーかを判断する。
エラーであれば、ステップＳ１３９にてエラー処理をす
る。エラーでなければステップＳ１４０にて対応するメ
ッセージを送信したか、即ちステップＳ１２７にてレス
ポンス側１２から返信されたメッセージがリクエスト側
１１に正常に受信されたかを受信通知４３の有無により
判断し、メッセージ４２ａが送信済みと判定された場合
は、ステップＳ１４１にてレスポンス側１２に保管され
ている対応するメッセージ４２ａを削除する。
【００５２】未だ受信通知４３を受信していない場合は
ステップＳ１４２にて処理を終了する。
ステップＳ１４２にて処理を終了する。
【００５３】これにより、レスポンス側１２が送信した
事実を否認しても、リクエスト側１１のデータベース９
２にはレスポンス側１２でのみ作成可能な署名９２が格
納されているので、レスポンス側１２による送信事実の
否認をリクエスト側１１は拒否できる。
事実を否認しても、リクエスト側１１のデータベース９
２にはレスポンス側１２でのみ作成可能な署名９２が格
納されているので、レスポンス側１２による送信事実の
否認をリクエスト側１１は拒否できる。
【００５４】図１２は本発明の第６の実施の形態により
受信者による受信の事実を後に受信者が否認することを
防止する方法におけるデータの流れを説明するブロック
図であり、図１３は図１２に示したシステムにおいて、
リクエスト側１１からレスポンス側１２にメッセージを
送信する場合において、受信事実の受信者による否認を
防止する処理の流れを説明するフローチャートである。
受信者による受信の事実を後に受信者が否認することを
防止する方法におけるデータの流れを説明するブロック
図であり、図１３は図１２に示したシステムにおいて、
リクエスト側１１からレスポンス側１２にメッセージを
送信する場合において、受信事実の受信者による否認を
防止する処理の流れを説明するフローチャートである。
【００５５】図１３と図３との相違点は、図１３におい
てはレスポンス側１２でステップＳ１５８にて受信署名
を作成し、リクエスト側１１でステップＳ１６３及びス
テップＳ１６４で受信署名の検証をし、ステップＳ１６
５で受信署名を保管することが追加されていることであ
る。
てはレスポンス側１２でステップＳ１５８にて受信署名
を作成し、リクエスト側１１でステップＳ１６３及びス
テップＳ１６４で受信署名の検証をし、ステップＳ１６
５で受信署名を保管することが追加されていることであ
る。
【００５６】より詳細には、図１２及び図１３におい
て、リクエスト側１１では、ステップＳ１５１で１つ又
は複数のメッセージを作成し、ステップＳ１５２でメッ
セージを保管し、ステップＳ１５３で送信したいメッセ
ージ２１をレスポンス側１２に送信する。メッセージ２
１には受信通知の返信を要求するリクエストが含まれて
いる。
て、リクエスト側１１では、ステップＳ１５１で１つ又
は複数のメッセージを作成し、ステップＳ１５２でメッ
セージを保管し、ステップＳ１５３で送信したいメッセ
ージ２１をレスポンス側１２に送信する。メッセージ２
１には受信通知の返信を要求するリクエストが含まれて
いる。
【００５７】レスポンス側１２では、ステップＳ１５４
でそのメッセージを受信し、ステップＳ１５５で図６か
ら図８のいずれかの方法により、受信したメッセージ中
のＩＤ（識別子）と同じＩＤがレスポンス側１２に存在
するかを検証する。その検証の結果ステップＳ１５６に
て同じＩＤがレスポンス側１２に存在しなければ、今回
受信したメッセージは新たなメッセージなので、ステッ
プＳ１５７にて受信メッセージを保管し、ステップＳ１
５８で受信者だけが作成できる受信署名１２０を作成す
る。ステップＳ１５６の判断の結果、同じＩＤがレスポ
ンス側１２に存在すれば、受信済みのメッセージなの
で、今回受信したメッセージは保管せずに、ステップＳ
１５９にて受信通知を作成する。次いでステップＳ１６
０にて受信通知２２ａをリクエスト側１１に向けて返信
する。受信通知２２ａには、リクエストに対するレスポ
ンスである旨の情報に加えて受信署名１２０も含まれて
いる。
でそのメッセージを受信し、ステップＳ１５５で図６か
ら図８のいずれかの方法により、受信したメッセージ中
のＩＤ（識別子）と同じＩＤがレスポンス側１２に存在
するかを検証する。その検証の結果ステップＳ１５６に
て同じＩＤがレスポンス側１２に存在しなければ、今回
受信したメッセージは新たなメッセージなので、ステッ
プＳ１５７にて受信メッセージを保管し、ステップＳ１
５８で受信者だけが作成できる受信署名１２０を作成す
る。ステップＳ１５６の判断の結果、同じＩＤがレスポ
ンス側１２に存在すれば、受信済みのメッセージなの
で、今回受信したメッセージは保管せずに、ステップＳ
１５９にて受信通知を作成する。次いでステップＳ１６
０にて受信通知２２ａをリクエスト側１１に向けて返信
する。受信通知２２ａには、リクエストに対するレスポ
ンスである旨の情報に加えて受信署名１２０も含まれて
いる。
【００５８】リクエスト側１１ではステップＳ１６１に
て所定時間間隔毎に上記受信通知２２の受信を監視し、
ステップＳ１６２にて対応するメッセージを送信した
か、即ち、ステップＳ１５３にてリクエスト側１１から
送信したメッセージがレスポンス側に正常に受信された
かを受信通知２２ａの有無により判断し、未だ受信通知
２２ａを受信していない場合は対応するメッセージ２１
を送信していないと判断してステップＳ１５３に戻りメ
ッセージ２１をレスポンス側１２に再送する。
て所定時間間隔毎に上記受信通知２２の受信を監視し、
ステップＳ１６２にて対応するメッセージを送信した
か、即ち、ステップＳ１５３にてリクエスト側１１から
送信したメッセージがレスポンス側に正常に受信された
かを受信通知２２ａの有無により判断し、未だ受信通知
２２ａを受信していない場合は対応するメッセージ２１
を送信していないと判断してステップＳ１５３に戻りメ
ッセージ２１をレスポンス側１２に再送する。
【００５９】ステップＳ１６４の判断でメッセージ２１
が送信済みと判定された場合は、ステップＳ１６５にて
受信署名をデータベース１２１に補完し、ステップＳ１
６６にてリクエスト側１１に保管されている対応するメ
ッセージ２１を削除する。
が送信済みと判定された場合は、ステップＳ１６５にて
受信署名をデータベース１２１に補完し、ステップＳ１
６６にてリクエスト側１１に保管されている対応するメ
ッセージ２１を削除する。
【００６０】これにより、レスポンス側１２が受信した
事実を否認しても、リクエスト側１１のデータベース１
２１にはレスポンス側１２でのみ作成可能な署名が格納
されているので、レスポンス側１２による受信事実の否
認をリクエスト側１１は拒否できる。
事実を否認しても、リクエスト側１１のデータベース１
２１にはレスポンス側１２でのみ作成可能な署名が格納
されているので、レスポンス側１２による受信事実の否
認をリクエスト側１１は拒否できる。
【００６１】図１４は、図１２に示したシステムにおい
て、レスポンス側１２からリクエスト側１１にメッセー
ジを送信する場合において、受信事実の受信者による否
認を防止する処理の流れを説明するフローチャートであ
る。
て、レスポンス側１２からリクエスト側１１にメッセー
ジを送信する場合において、受信事実の受信者による否
認を防止する処理の流れを説明するフローチャートであ
る。
【００６２】図１４と図５との相違点は、図１４におい
ては、リクエスト側１１でステップＳ１８１にて受信署
名を作成し、レスポンス側１２ではステップＳ１８６及
びステップＳ１８７で送信署名検証を行い、ステップＳ
１８８で受信署名を保管することである。
ては、リクエスト側１１でステップＳ１８１にて受信署
名を作成し、レスポンス側１２ではステップＳ１８６及
びステップＳ１８７で送信署名検証を行い、ステップＳ
１８８で受信署名を保管することである。
【００６３】より詳細には、図１２及び図１４におい
て、レスポンス側１２では、ステップＳ１７１で１つ又
は複数のメッセージを作成し、ステップＳ１７２でその
メッセージを保管しておく。
て、レスポンス側１２では、ステップＳ１７１で１つ又
は複数のメッセージを作成し、ステップＳ１７２でその
メッセージを保管しておく。
【００６４】リクエスト側１１では、ステップＳ１７３
にて受信要求４１をレスポンス側１２に送信する。レス
ポンス側１２はステップＳ１７４でこの受信要求４１を
受信し、ステップＳ１７５でその受信要求に応ずるメッ
セージ４２を保管されているメッセージの中から検索す
る。受信要求に応ずるメッセージ４２が存在すればステ
ップＳ１７６にてそのメッセージ４２をリクエスト側１
１に送信する。
にて受信要求４１をレスポンス側１２に送信する。レス
ポンス側１２はステップＳ１７４でこの受信要求４１を
受信し、ステップＳ１７５でその受信要求に応ずるメッ
セージ４２を保管されているメッセージの中から検索す
る。受信要求に応ずるメッセージ４２が存在すればステ
ップＳ１７６にてそのメッセージ４２をリクエスト側１
１に送信する。
【００６５】リクエスト側１１ではそのメッセージ４２
をステップＳ１７７で受信し、ステップＳ１７８で受信
したメッセージ中のＩＤ（識別子）と同じＩＤがリクエ
スト側１１に存在するかを検証する。検証した結果、ス
テップＳ１７９で同じＩＤがレスポンス側１２に存在し
なければ、今回受信したメッセージは新たなメッセージ
なので、ステップＳ１８０にて受信メッセージを保管
し、ステップＳ１８１で受信者のみが作成できる受信書
名１２２を作成し、ステップＳ１８４で受信署名１２２
を含む受信通知４３ａを作成する。ステップＳ１７９の
検索の結果、同じＩＤがリクエスト側１１に存在すれ
ば、受信済みのメッセージなので、今回受信したメッセ
ージは保管せずに、ステップＳ１８１で受信者のみが作
成できる受信書名１２２を作成し、ステップＳ１８４で
受信署名１２２を含む受信通知４３ａを作成する。次い
でステップＳ１８３にてその受信通知４３ａをレスポン
ス側１２に向けて返信する。
をステップＳ１７７で受信し、ステップＳ１７８で受信
したメッセージ中のＩＤ（識別子）と同じＩＤがリクエ
スト側１１に存在するかを検証する。検証した結果、ス
テップＳ１７９で同じＩＤがレスポンス側１２に存在し
なければ、今回受信したメッセージは新たなメッセージ
なので、ステップＳ１８０にて受信メッセージを保管
し、ステップＳ１８１で受信者のみが作成できる受信書
名１２２を作成し、ステップＳ１８４で受信署名１２２
を含む受信通知４３ａを作成する。ステップＳ１７９の
検索の結果、同じＩＤがリクエスト側１１に存在すれ
ば、受信済みのメッセージなので、今回受信したメッセ
ージは保管せずに、ステップＳ１８１で受信者のみが作
成できる受信書名１２２を作成し、ステップＳ１８４で
受信署名１２２を含む受信通知４３ａを作成する。次い
でステップＳ１８３にてその受信通知４３ａをレスポン
ス側１２に向けて返信する。
【００６６】レスポンス側１２ではステップＳ１８４に
て所定時間間隔毎に上記受信通知４３ａの受信を監視
し、ステップＳ１８５にて対応するメッセージを送信し
たか、即ち、ステップＳ１７６にてレスポンス側１２か
ら送信されたメッセージがリクエスト側１１に正常に受
信されたかを受信通知４３ａの有無により判断し、メッ
セージ４２が送信済みと判定された場合は、ステップＳ
１８６にて受信署名を受信者の公開鍵で検証する。ステ
ップＳ１８７の判断で正しい受信署名であると判定され
ると、ステップＳ１８８にて受信署名をデータベース１
２３に保管し、ステップＳ１８９にてレスポンス側１２
に保管されている対応するメッセージ４２を削除する。
て所定時間間隔毎に上記受信通知４３ａの受信を監視
し、ステップＳ１８５にて対応するメッセージを送信し
たか、即ち、ステップＳ１７６にてレスポンス側１２か
ら送信されたメッセージがリクエスト側１１に正常に受
信されたかを受信通知４３ａの有無により判断し、メッ
セージ４２が送信済みと判定された場合は、ステップＳ
１８６にて受信署名を受信者の公開鍵で検証する。ステ
ップＳ１８７の判断で正しい受信署名であると判定され
ると、ステップＳ１８８にて受信署名をデータベース１
２３に保管し、ステップＳ１８９にてレスポンス側１２
に保管されている対応するメッセージ４２を削除する。
【００６７】ステップＳ１８５の判断で未だ受信通知４
３を受信していない場合、又はステップＳ１８７の判断
で正しい受信署名ではないと判定された場合はステップ
Ｓ１９０にて処理を終了する。
３を受信していない場合、又はステップＳ１８７の判断
で正しい受信署名ではないと判定された場合はステップ
Ｓ１９０にて処理を終了する。
【００６８】これにより、リクエスト側１１が受信した
事実を否認しても、レスポンス側１２のデータベース１
２３にはリクエスト側１１でのみ作成可能な受信署名１
３２が格納されているので、リクエスト側１１による受
信事実の否認をレスポンス側１２は拒否できる。
事実を否認しても、レスポンス側１２のデータベース１
２３にはリクエスト側１１でのみ作成可能な受信署名１
３２が格納されているので、リクエスト側１１による受
信事実の否認をレスポンス側１２は拒否できる。
【００６９】図１５は本発明の第７の実施の形態により
送受信者による送受信の事実を後に送受信者が否認する
ことを防止する方法におけるデータの流れを説明するブ
ロック図であり、図１６は図１５に示したシステムにお
いて、リクエスト側１１からレスポンス側１２にメッセ
ージを送信する場合の処理の流れを説明するフローチャ
ートである。
送受信者による送受信の事実を後に送受信者が否認する
ことを防止する方法におけるデータの流れを説明するブ
ロック図であり、図１６は図１５に示したシステムにお
いて、リクエスト側１１からレスポンス側１２にメッセ
ージを送信する場合の処理の流れを説明するフローチャ
ートである。
【００７０】図１６は図１０と図１３とを融合したもの
である。
である。
【００７１】より詳細には、図１５及び図１６におい
て、リクエスト側１１では、ステップＳ１９１で１つ又
は複数のメッセージを作成し、ステップＳ１９２で送信
者だけが作成できる送信署名を作成し、ステップＳ１９
３でその送信署名をメッセージとともにを保管し、ステ
ップＳ１９４で送信したいメッセージ２１ａをレスポン
ス側１２に送信する。メッセージ２１ａには受信通知の
返信を要求するリクエストと送信署名とが含まれてい
る。
て、リクエスト側１１では、ステップＳ１９１で１つ又
は複数のメッセージを作成し、ステップＳ１９２で送信
者だけが作成できる送信署名を作成し、ステップＳ１９
３でその送信署名をメッセージとともにを保管し、ステ
ップＳ１９４で送信したいメッセージ２１ａをレスポン
ス側１２に送信する。メッセージ２１ａには受信通知の
返信を要求するリクエストと送信署名とが含まれてい
る。
【００７２】レスポンス側１２では、ステップＳ１９５
でそのメッセージを受信し、ステップＳ１９６で送信署
名を送信者の公開鍵で検証する。ステップＳ１９７でそ
の検証結果が不正な署名であれば、ステップＳ１９８に
進んで署名検証エラーを受信通知２２ａに載せてリクエ
スト側１１に返信する。ステップＳ１９７で著名の検証
結果が正しければ、ステップＳ１９９にて図６から図８
のいずれかの方法により、受信したメッセージ中のＩＤ
（識別子）と同じＩＤがレスポンス側１２に存在するか
を検索する。その検索の結果ステップＳ２００にて同じ
ＩＤがレスポンス側１２に存在しなければ、今回受信し
たメッセージは新たなメッセージなので、ステップＳ２
０１にて受信メッセージと共に送信者の署名９０をデー
タベース９１に保管し、ステップＳ２０２で受信者のみ
が作成できる受信書名１２０を作成する。次いでステッ
プＳ２０４にて受信通知２２ａをリクエスト側１１に向
けて返信する。受信通知２２ａには、リクエストに対す
るレスポンスである旨の情報と受信署名とが含まれてい
る。
でそのメッセージを受信し、ステップＳ１９６で送信署
名を送信者の公開鍵で検証する。ステップＳ１９７でそ
の検証結果が不正な署名であれば、ステップＳ１９８に
進んで署名検証エラーを受信通知２２ａに載せてリクエ
スト側１１に返信する。ステップＳ１９７で著名の検証
結果が正しければ、ステップＳ１９９にて図６から図８
のいずれかの方法により、受信したメッセージ中のＩＤ
（識別子）と同じＩＤがレスポンス側１２に存在するか
を検索する。その検索の結果ステップＳ２００にて同じ
ＩＤがレスポンス側１２に存在しなければ、今回受信し
たメッセージは新たなメッセージなので、ステップＳ２
０１にて受信メッセージと共に送信者の署名９０をデー
タベース９１に保管し、ステップＳ２０２で受信者のみ
が作成できる受信書名１２０を作成する。次いでステッ
プＳ２０４にて受信通知２２ａをリクエスト側１１に向
けて返信する。受信通知２２ａには、リクエストに対す
るレスポンスである旨の情報と受信署名とが含まれてい
る。
【００７３】リクエスト側１１ではステップＳ２０５に
て所定時間間隔毎に上記受信通知２２ａの受信を監視
し、ステップＳ２０６にて送信署名エラーが返信された
かを判定し、送信署名エラーが返信された場合はステッ
プＳ２０７にてエラー処理をする。
て所定時間間隔毎に上記受信通知２２ａの受信を監視
し、ステップＳ２０６にて送信署名エラーが返信された
かを判定し、送信署名エラーが返信された場合はステッ
プＳ２０７にてエラー処理をする。
【００７４】ステップＳ２０６の判断で送信署名エラー
でないと判定されると、ステップＳ２０８にて対応する
メッセージを送信したか、即ち、ステップＳ１９４にて
リクエスト側１１から送信したメッセージがレスポンス
側１２に正常に受信されたかを受信通知２２ａの有無に
より判断し、未だ受信通知２２ａを受信していない場合
は対応するメッセージ２１ａを送信していないと判断し
てステップＳ１９４に戻りメッセージ２１ａをレスポン
ス側１２に再送する。
でないと判定されると、ステップＳ２０８にて対応する
メッセージを送信したか、即ち、ステップＳ１９４にて
リクエスト側１１から送信したメッセージがレスポンス
側１２に正常に受信されたかを受信通知２２ａの有無に
より判断し、未だ受信通知２２ａを受信していない場合
は対応するメッセージ２１ａを送信していないと判断し
てステップＳ１９４に戻りメッセージ２１ａをレスポン
ス側１２に再送する。
【００７５】ステップＳ２０６の判断でメッセージ２１
ａが送信済みと判定された場合は、ステップＳ２０９に
て受信通知２２ａ内の受信署名を受信者の公開鍵で検証
する。この検証の結果ステップＳ２１０で正しくない受
信署名であると判定されると、リクエスト側１１からレ
スポンス側１２にメッセージ２１ａが未だ送信されてい
ないものと判断して、ステップＳ１９４に戻りメッセー
ジ２１ａをレスポンス側１２に再送する。
ａが送信済みと判定された場合は、ステップＳ２０９に
て受信通知２２ａ内の受信署名を受信者の公開鍵で検証
する。この検証の結果ステップＳ２１０で正しくない受
信署名であると判定されると、リクエスト側１１からレ
スポンス側１２にメッセージ２１ａが未だ送信されてい
ないものと判断して、ステップＳ１９４に戻りメッセー
ジ２１ａをレスポンス側１２に再送する。
【００７６】ステップＳ２１０の検証で正しい受信署名
であると判定されると、ステップＳ２１１にて受信署名
をデータベース１２１に保管し、次いでステップＳ２１
２にてリクエスト側１１に保管されている対応するメッ
セージ２１を削除する。
であると判定されると、ステップＳ２１１にて受信署名
をデータベース１２１に保管し、次いでステップＳ２１
２にてリクエスト側１１に保管されている対応するメッ
セージ２１を削除する。
【００７７】これにより、リクエスト側１１が送信した
事実を否認しても、レスポンス側１２のデータベース９
１にはリクエスト側１１でのみ作成可能な送信署名が格
納されているので、リクエスト側１１による送信事実の
否認をレスポンス側１２は拒否できるとともに、レスポ
ンス側１２が受信した事実を否認しても、リクエスト側
１１のデータベース１２１にはレスポンス側１２でのみ
作成可能な受信署名が格納されているので、レスポンス
側１２による受信事実の否認をリクエスト側１１は拒否
できる。
事実を否認しても、レスポンス側１２のデータベース９
１にはリクエスト側１１でのみ作成可能な送信署名が格
納されているので、リクエスト側１１による送信事実の
否認をレスポンス側１２は拒否できるとともに、レスポ
ンス側１２が受信した事実を否認しても、リクエスト側
１１のデータベース１２１にはレスポンス側１２でのみ
作成可能な受信署名が格納されているので、レスポンス
側１２による受信事実の否認をリクエスト側１１は拒否
できる。
【００７８】図１７は、図１５に示したシステムにおい
て、レスポンス側１２からリクエスト側１１にメッセー
ジを送信する場合において、送受信事実の送受信者によ
る否認を防止する処理の流れを説明するフローチャート
である。
て、レスポンス側１２からリクエスト側１１にメッセー
ジを送信する場合において、送受信事実の送受信者によ
る否認を防止する処理の流れを説明するフローチャート
である。
【００７９】図１７は図１１と図１１と図１４を融合し
たものである。
たものである。
【００８０】より詳細には、図１５及び図１７におい
て、レスポンス側１２では、ステップＳ２２０で１つ又
は複数のメッセージを作成し、ステップＳ２２１で送信
者のみが作成できる送信書名を作成する。次いでステッ
プＳ２２２でその送信署名をメッセージとともに保管し
ておく。
て、レスポンス側１２では、ステップＳ２２０で１つ又
は複数のメッセージを作成し、ステップＳ２２１で送信
者のみが作成できる送信書名を作成する。次いでステッ
プＳ２２２でその送信署名をメッセージとともに保管し
ておく。
【００８１】リクエスト側１１では、ステップＳ２２３
にて受信要求４１をレスポンス側１２に送信する。レス
ポンス側１２はステップＳ２２４でこの受信要求４１を
受信し、ステップＳ２２５でその要求に応ずるメッセー
ジ４２ａを保管されているメッセージの中から検索す
る。受信要求に応ずるメッセージ４２ａが存在すればス
テップＳ２２６にてそのメッセージ４２ａに署名９２を
含ませてリクエスト側１１に送信する。
にて受信要求４１をレスポンス側１２に送信する。レス
ポンス側１２はステップＳ２２４でこの受信要求４１を
受信し、ステップＳ２２５でその要求に応ずるメッセー
ジ４２ａを保管されているメッセージの中から検索す
る。受信要求に応ずるメッセージ４２ａが存在すればス
テップＳ２２６にてそのメッセージ４２ａに署名９２を
含ませてリクエスト側１１に送信する。
【００８２】リクエスト側１１ではそのメッセージ４２
ａをステップＳ２２７で受信し、ステップＳ２２８で受
信したメッセージ中の送信署名が正しいかどうかを送信
者の公開鍵で検証する。正しくなければステップＳ２３
０で署名検証エラーをレスポンス側１２に返信する。正
しければステップＳ２３１及びステップＳ２３２にてメ
ッセージ４２ａ中のＩＤ（識別子）と同じＩＤがリクエ
スト側１１に存在するかを検索する。検索した結果、同
じＩＤがレスポンス側１２に存在しなければ、今回受信
したメッセージは新たなメッセージなので、ステップＳ
２３３にて受信メッセージを署名９２とともにデータベ
ース９３に保管し、ステップＳ２３４で受信者のみが作
成できる受信署名１２２を作成し、ステップＳ２３５で
受信署名１２２を含む受信通知４３ａを作成する。次い
でステップＳ２３６で受信通知４３ａをレスポンス側１
２に送信する。
ａをステップＳ２２７で受信し、ステップＳ２２８で受
信したメッセージ中の送信署名が正しいかどうかを送信
者の公開鍵で検証する。正しくなければステップＳ２３
０で署名検証エラーをレスポンス側１２に返信する。正
しければステップＳ２３１及びステップＳ２３２にてメ
ッセージ４２ａ中のＩＤ（識別子）と同じＩＤがリクエ
スト側１１に存在するかを検索する。検索した結果、同
じＩＤがレスポンス側１２に存在しなければ、今回受信
したメッセージは新たなメッセージなので、ステップＳ
２３３にて受信メッセージを署名９２とともにデータベ
ース９３に保管し、ステップＳ２３４で受信者のみが作
成できる受信署名１２２を作成し、ステップＳ２３５で
受信署名１２２を含む受信通知４３ａを作成する。次い
でステップＳ２３６で受信通知４３ａをレスポンス側１
２に送信する。
【００８３】ステップＳ２３２の検索の結果、同じＩＤ
がリクエスト側１１に存在すれば、受信済みのメッセー
ジなので、今回受信したメッセージは保管せずに、ステ
ップＳ２３５にて受信署名を作成する。
がリクエスト側１１に存在すれば、受信済みのメッセー
ジなので、今回受信したメッセージは保管せずに、ステ
ップＳ２３５にて受信署名を作成する。
【００８４】レスポンス側１２ではステップＳ２３７に
て所定時間間隔毎に上記受信通知４３ａの受信を監視
し、ステップＳ２３８にて送信署名がエラーかを判断す
る。エラーであれば、ステップＳ２３９にてエラー処理
をする。エラーでなければステップＳ２４０にて対応す
るメッセージを送信したか、即ち、ステップＳ２２６に
てレスポンス側１２から送信したメッセージがリクエス
ト側１１に正常に受信されたかを受信通知４３ａの有無
により判断し、メッセージ４２ａが送信済みと判定され
た場合は、ステップＳ２４１にて受信者の公開鍵により
受信署名を検証し、ステップＳ２４２で正しい署名であ
ればステップＳ２４３で受信署名１２２をデータベース
１５１に保管し、ステップＳ２４４でレスポンス側１２
に保管されている対応するメッセージ４２ａを削除す
る。
て所定時間間隔毎に上記受信通知４３ａの受信を監視
し、ステップＳ２３８にて送信署名がエラーかを判断す
る。エラーであれば、ステップＳ２３９にてエラー処理
をする。エラーでなければステップＳ２４０にて対応す
るメッセージを送信したか、即ち、ステップＳ２２６に
てレスポンス側１２から送信したメッセージがリクエス
ト側１１に正常に受信されたかを受信通知４３ａの有無
により判断し、メッセージ４２ａが送信済みと判定され
た場合は、ステップＳ２４１にて受信者の公開鍵により
受信署名を検証し、ステップＳ２４２で正しい署名であ
ればステップＳ２４３で受信署名１２２をデータベース
１５１に保管し、ステップＳ２４４でレスポンス側１２
に保管されている対応するメッセージ４２ａを削除す
る。
【００８５】ステップＳ２４０にて未だ対応するメッセ
ージを送信していないと判定された場合又はステップＳ
２４２にて正しい受信署名ではないと判定された場合
は、ステップＳ２４５にて処理を終了する。
ージを送信していないと判定された場合又はステップＳ
２４２にて正しい受信署名ではないと判定された場合
は、ステップＳ２４５にて処理を終了する。
【００８６】これにより、レスポンス側１２が送信した
事実を否認しても、リクエスト側１１のデータベース９
３にはレスポンス側１２でのみ作成可能な送信署名が格
納されているので、レスポンス側１２による送信事実の
否認をリクエスト側１１は拒否できるとともに、リクエ
スト側１１が受信した事実を否認しても、レスポンス側
１２のデータベース１５１にはリクエスト側１１でのみ
作成可能な受信署名が格納されているので、リクエスト
側１１による受信事実の否認をレスポンス側１２は拒否
できる。以上に記載した各実施の形態において、受信し
たメッセージ及び署名の少なくとも一方の保管が正常に
完了しない場合がある。その原因としては、メッセージ
や署名を保管するバッファの領域が不足している場合
や、そのバッファに書き込み禁止フラグが立てられてい
る等によりそのバッファへの書き込み権がない場合や、
保存先を間違えた場合や、保存先がデータベースの場合
でそのデータベースが起動していない場合等がある。バ
ッファの領域が不足しているためにメッセージや署名の
保管ができなかった場合は、以下に記載する本発明の第
８及び第９の実施の形態により保管可能になる場合があ
る。図１８は、図３におけるステップＳ３７又は図５に
おけるステップＳ６０におけるメッセージの保管が成功
しなかった場合の本発明の第８の実施の形態によるメッ
セージ保管方法を説明するフローチャートである。同図
において、ステップＳ２５０にて署名がない受信メッセ
ージの保管動作を行う。このステップは図３におけるス
テップＳ３７又は図５におけるステップＳ６０の動作で
ある。次いでステップＳ２５１にてメッセージ保存エラ
ーかどうかを判定し、エラーであればステップＳ２５２
に進んでエラーの原因がメッセージ保存用バッファの領
域不足かどうかを判定する。領域不足であればステップ
Ｓ２５３にてそのメッセージ保存領域の中の最も古いメ
ッセージから順に少なくとも一つのメッセージを削除
し、ステップＳ２５４にて再度領域不足かを判定する。
この判定で依然として領域不足であれば、メッセージ保
存に失敗したことを示すメッセージ保存エラーをメッセ
ージの送信側に返信する。ステップＳ２５４にて領域不
足でなければステップＳ２５０に戻りメッセージを保管
する。ステップＳ２５１にてメッセージ保存エラーでな
ければステップＳ２５５にて受信通知を作成する。ステ
ップＳ２５５は図３におけるステップＳ３８又は図５に
おけるステップＳ６１に相当する。図１８に示したメッ
セージ保管エラーの救済方法は、図１３におけるステッ
プＳ１５７又は図１４におけるステップＳ１８０のメッ
セージ保管が出来なかった場合にも同様に適用できる。
また、メッセージに替えて受信した署名の保管が出来な
かった場合にも同様に適用できる。即ち、図１３のステ
ップＳ１６５、図１４のステップＳ１８８、図１６のス
テップＳ２１１、図１７のステップＳ２４３において受
信署名の保管に失敗した場合に、図１８に示したフロー
チャートにおける「メッセージ」を「署名」に変更した
フローチャート(図示省略）により、署名保管のエラー
を救済できる場合がある。図１９は、図１６におけるス
テップＳ２０１又は図１７におけるステップＳ２３３に
おけるメッセージ及び署名の保管が成功しなかった場合
の本発明の第９の実施の形態によるメッセージ及び署名
の保管方法を説明するフローチャートである。同図にお
いて、ステップＳ２６０にて受信メッセージ及び署名の
保管動作を行う。このステップは図１６におけるステッ
プＳ２０１又は図１７におけるステップＳ２３３の動作
である。次いでステップＳ２６１にてメッセージ及び署
名の少なくとも一方の保存エラーかどうかを判定し、エ
ラーであればステップＳ２６２に進んでエラーの原因が
メッセージ及び署名の保存領域の領域不足かどうかを判
定する。領域不足であればステップＳ２６３にてそのメ
ッセージ及び署名の保存領域の中の最も古いメッセージ
から順に少なくとも一つのメッセージを削除し、ステッ
プＳ２６４にて再度領域不足かを判定する。この判定で
依然として領域不足であれば、ステップＳ２６５にてそ
のメッセージ及び署名の保存領域の中の最も古い署名を
削除し、ステップＳ２６６にて再度領域不足かを判定す
る。この判定で依然として領域不足であれば、署名検証
エラーであることを示すメッセージを送信側に返信す
る。ステップＳ２６６にて領域不足でなければステップ
Ｓ２６０に戻りメッセージ及び署名を保管する。ステッ
プＳ２６１にてメッセージ又は署名の保存エラーでなけ
ればステップＳ２６８受信署名を作成し、ステップＳ２
６９にて受信通知を作成する。ステップＳ２６８及びス
テップＳ２６９は図１６におけるステップＳ２０２及び
ステップＳ２０３又は図１７におけるステップＳ２３４
及びステップＳ２３５に相当する。図１９に示した署名
付きメッセージ保管エラーの救済方法は、図１０におけ
るステップＳ１１１、図１１におけるステップＳ１３
４、図１６におけるステップＳ２０１にも同様に適用で
きる。上記のように、バッファの容量不足により受信し
たメッセージや署名の保管に失敗した場合にも、古いメ
ッセージや署名をバッファから削除することにより確実
に受信メッセージや署名を保存できる。以上に記載した
各実施の形態において用いられるメッセージの形式の一
例を以下に記載する。以下の例ではメッセージはアプリ
ケーション間通信の取り決めを定義したExtensible Mar
kup Language(XML)形式によりSOAP の標準に従って作成
されている。図２０はリクエスト側からレスポンス側に
対してメッセージの送信要求をする場合のメッセージの
内容の一例である。このメッセージではヘッダ内にメッ
セージタイプとして送信要求を示すRequestを記述す
る。このメッセージは図５のステップＳ５３、図１１の
ステップＳ１２４、図１４のステップＳ１７３又は図１
７のステップＳ２２３で使用される。図２０において、
<SOAP:Envelope と</SOAP:ENVELOPE>との間の情報の中
で、最初の行にxmls:SOAP=…と記載されているのは、こ
のメッセージが SOAP を標準とする XML 形式で記載さ
れたものであることを示している。<SOAP:Header> と <
/SOAP:Header> との間の <rm:Message Header…と</rm:
Message Header>の間がこのメッセージのヘッダであ
る。メッセージヘッダには、メッセージの送信元と、送
信先と、メッセージのサービスの種類と、メッセージの
種類とが記載されている。この例では送信元は<rm:From
>で始まる行に記載されているように requester@anyur
i.com となっておりリクエスト側である。また、送信先
は<rm:To>で始まる行に記載されているようにresponder
@someeuri.comとなっておりレスポンス側である。ま
た、サービスの種類は<rm:Service>で始まる行にItem Q
uote Service と記載されているように、問い合わせの
サービスである。さらにメッセージの種類は<rm: Messa
ge Type>で始まる行に Request と記載されているよう
に要求メッセージである。このメッセージの送信要求に
はメッセージ本体の情報がないので、<SOAP:Body>と</S
OAP:Body>との間には何も記載されていない。図２１は
署名無し送信メッセージの一例を示す図である。このメ
ッセージは図３のステップＳ３３におけるリクエスト側
からのメッセージ送信に使用される。同図において、<S
OAP:Envelope と</SOAP:ENVELOPE>との間の情報の中
で、最初の行は図２０と同じである。また、<rm:Messag
e Header…>と</rm:Message Header>との間のヘッダに
おける、送信元、送信先、サービスの種類も図２０の例
と同じである。この他にメッセージ種類、メッセージＩ
Ｄ、送信日時等が記載されている。メッセージの種類は
<rm: Message Type>で始まる行にMessage と記載されて
いるようにメッセージである。また、メッセージＩＤと
して<rm: Message Id>の行に20020907-045261-0450@any
uri.com が記載されている。さらに、送信日時として<r
m: Timestamp>の行に 2002-09-07T10:19:07 と記載され
ている。<rm:Reliable Message…>と</rm:Reliable Mes
sage>の間のヘッダには、送信メッセージの信頼性を確
保するための情報が記載されている。即ち、<rm:AckReq
uested SOAP:must understand...は確認メッセージの形
式が SOAP の標準に準拠すべきことを記述したものであ
る。また、<rm:Duplicate Elimination/>は重複受信を
したメッセージを削除するものである。<SOAP:BODY>と<
/SOAP:BODY>との間にはアプリケーションに依存する情
報本体の内容が記載される。図５におけるステップＳ５
６で送信されるメッセージも、送信元と送信先が図２２
に示したものと逆になるだけで図２２と同様の形式で作
成される。図２２は署名無し受信確認メッセージの一例
を示す図である。このメッセージは図３のステップＳ３
９で使用される。メッセージの形式は図２１に示したも
のと同様であるので詳細な説明は省略する。サービスの
種類が Item Filing Service となっていてファイルス
ルサービスであること、及びメッセージの種類が Ackno
wledgement となっていて確認のメッセージであること
に着目される。本例では送信元がレスポンス側であり送
信先がリクエスト側であるが、送信元をリクエスト側に
し送信先をレスポンス側にすれば図５のステップＳ６２
で使用するメッセージとなる。図２３から図２５は署名
有りの送信メッセージの一例を示す図である。このメッ
セージは図１０のステップＳ１０４で使用される。この
メッセージにおいて、第１行の<SOAP:Envelope>から第
１９行の</rm:Reliable Message>までは図２１に示した
署名無し送信メッセージと同じである。本例では、その
次の行に<wsse:Security xmls:wsse=”から</wsse:Bina
rySecurity Token>までのタグが存在する。ここでは、
ウェブ・サービス・セキュリティ（Web Service Securi
ty ）(wsse)によりセキュリティを確保している。次の
タグである<ds:Signature xmls…から</ds:SignatureVa
lue>までの間で、署名がXML形式で記載されている。署
名の対象は、<ds:Xpath>のタグに記載されているよう
に、メッセージヘッダと、リライアブルメッセージ(Rel
iable Message)と、情報本体(SOAP Body)である。これ
により、メッセージヘッダと、リライアブルメッセージ
と、情報本体に対する改竄を防止できる。このように、
送信メッセージに WS-Security 形式の署名を付けるこ
とにより、送信者の否認を防止できる。本例において
も、送信元をレスポンス側とし送信先をリクエスト側と
すれば、図１１のステップＳ１２６で使用するメッセー
ジとなる。図２６から図２８は署名有りの受信確認メッ
セージの一例を示す図である。このメッセージは図１０
のステップＳ１１３、図１３のステップＳ１６０、又は
図１６のステップＳ２０４で使用される。メッセージの
形式は図２３から図２５に示したものと同様であるので
詳細な説明は省略する。サービスの種類が Item Filing
Service となっていてファイルスルサービスであるこ
と、及びメッセージの種類が Acknowledgement となっ
ていて確認のメッセージであることに着目される。この
例においても、受信確認メッセージに WS-Security 形
式の署名を付けることにより、メッセージヘッダと、リ
ライアブルメッセージと、情報本体に対する改竄を防止
できる。本例においても、送信元をリクエスト側とし、
送信先をレスポンス側とすることにより図１１のステッ
プＳ１３６、図１４のステップＳ１８３、又は図１７の
ステップＳ２３６で使用するメッセージとなる。
事実を否認しても、リクエスト側１１のデータベース９
３にはレスポンス側１２でのみ作成可能な送信署名が格
納されているので、レスポンス側１２による送信事実の
否認をリクエスト側１１は拒否できるとともに、リクエ
スト側１１が受信した事実を否認しても、レスポンス側
１２のデータベース１５１にはリクエスト側１１でのみ
作成可能な受信署名が格納されているので、リクエスト
側１１による受信事実の否認をレスポンス側１２は拒否
できる。以上に記載した各実施の形態において、受信し
たメッセージ及び署名の少なくとも一方の保管が正常に
完了しない場合がある。その原因としては、メッセージ
や署名を保管するバッファの領域が不足している場合
や、そのバッファに書き込み禁止フラグが立てられてい
る等によりそのバッファへの書き込み権がない場合や、
保存先を間違えた場合や、保存先がデータベースの場合
でそのデータベースが起動していない場合等がある。バ
ッファの領域が不足しているためにメッセージや署名の
保管ができなかった場合は、以下に記載する本発明の第
８及び第９の実施の形態により保管可能になる場合があ
る。図１８は、図３におけるステップＳ３７又は図５に
おけるステップＳ６０におけるメッセージの保管が成功
しなかった場合の本発明の第８の実施の形態によるメッ
セージ保管方法を説明するフローチャートである。同図
において、ステップＳ２５０にて署名がない受信メッセ
ージの保管動作を行う。このステップは図３におけるス
テップＳ３７又は図５におけるステップＳ６０の動作で
ある。次いでステップＳ２５１にてメッセージ保存エラ
ーかどうかを判定し、エラーであればステップＳ２５２
に進んでエラーの原因がメッセージ保存用バッファの領
域不足かどうかを判定する。領域不足であればステップ
Ｓ２５３にてそのメッセージ保存領域の中の最も古いメ
ッセージから順に少なくとも一つのメッセージを削除
し、ステップＳ２５４にて再度領域不足かを判定する。
この判定で依然として領域不足であれば、メッセージ保
存に失敗したことを示すメッセージ保存エラーをメッセ
ージの送信側に返信する。ステップＳ２５４にて領域不
足でなければステップＳ２５０に戻りメッセージを保管
する。ステップＳ２５１にてメッセージ保存エラーでな
ければステップＳ２５５にて受信通知を作成する。ステ
ップＳ２５５は図３におけるステップＳ３８又は図５に
おけるステップＳ６１に相当する。図１８に示したメッ
セージ保管エラーの救済方法は、図１３におけるステッ
プＳ１５７又は図１４におけるステップＳ１８０のメッ
セージ保管が出来なかった場合にも同様に適用できる。
また、メッセージに替えて受信した署名の保管が出来な
かった場合にも同様に適用できる。即ち、図１３のステ
ップＳ１６５、図１４のステップＳ１８８、図１６のス
テップＳ２１１、図１７のステップＳ２４３において受
信署名の保管に失敗した場合に、図１８に示したフロー
チャートにおける「メッセージ」を「署名」に変更した
フローチャート(図示省略）により、署名保管のエラー
を救済できる場合がある。図１９は、図１６におけるス
テップＳ２０１又は図１７におけるステップＳ２３３に
おけるメッセージ及び署名の保管が成功しなかった場合
の本発明の第９の実施の形態によるメッセージ及び署名
の保管方法を説明するフローチャートである。同図にお
いて、ステップＳ２６０にて受信メッセージ及び署名の
保管動作を行う。このステップは図１６におけるステッ
プＳ２０１又は図１７におけるステップＳ２３３の動作
である。次いでステップＳ２６１にてメッセージ及び署
名の少なくとも一方の保存エラーかどうかを判定し、エ
ラーであればステップＳ２６２に進んでエラーの原因が
メッセージ及び署名の保存領域の領域不足かどうかを判
定する。領域不足であればステップＳ２６３にてそのメ
ッセージ及び署名の保存領域の中の最も古いメッセージ
から順に少なくとも一つのメッセージを削除し、ステッ
プＳ２６４にて再度領域不足かを判定する。この判定で
依然として領域不足であれば、ステップＳ２６５にてそ
のメッセージ及び署名の保存領域の中の最も古い署名を
削除し、ステップＳ２６６にて再度領域不足かを判定す
る。この判定で依然として領域不足であれば、署名検証
エラーであることを示すメッセージを送信側に返信す
る。ステップＳ２６６にて領域不足でなければステップ
Ｓ２６０に戻りメッセージ及び署名を保管する。ステッ
プＳ２６１にてメッセージ又は署名の保存エラーでなけ
ればステップＳ２６８受信署名を作成し、ステップＳ２
６９にて受信通知を作成する。ステップＳ２６８及びス
テップＳ２６９は図１６におけるステップＳ２０２及び
ステップＳ２０３又は図１７におけるステップＳ２３４
及びステップＳ２３５に相当する。図１９に示した署名
付きメッセージ保管エラーの救済方法は、図１０におけ
るステップＳ１１１、図１１におけるステップＳ１３
４、図１６におけるステップＳ２０１にも同様に適用で
きる。上記のように、バッファの容量不足により受信し
たメッセージや署名の保管に失敗した場合にも、古いメ
ッセージや署名をバッファから削除することにより確実
に受信メッセージや署名を保存できる。以上に記載した
各実施の形態において用いられるメッセージの形式の一
例を以下に記載する。以下の例ではメッセージはアプリ
ケーション間通信の取り決めを定義したExtensible Mar
kup Language(XML)形式によりSOAP の標準に従って作成
されている。図２０はリクエスト側からレスポンス側に
対してメッセージの送信要求をする場合のメッセージの
内容の一例である。このメッセージではヘッダ内にメッ
セージタイプとして送信要求を示すRequestを記述す
る。このメッセージは図５のステップＳ５３、図１１の
ステップＳ１２４、図１４のステップＳ１７３又は図１
７のステップＳ２２３で使用される。図２０において、
<SOAP:Envelope と</SOAP:ENVELOPE>との間の情報の中
で、最初の行にxmls:SOAP=…と記載されているのは、こ
のメッセージが SOAP を標準とする XML 形式で記載さ
れたものであることを示している。<SOAP:Header> と <
/SOAP:Header> との間の <rm:Message Header…と</rm:
Message Header>の間がこのメッセージのヘッダであ
る。メッセージヘッダには、メッセージの送信元と、送
信先と、メッセージのサービスの種類と、メッセージの
種類とが記載されている。この例では送信元は<rm:From
>で始まる行に記載されているように requester@anyur
i.com となっておりリクエスト側である。また、送信先
は<rm:To>で始まる行に記載されているようにresponder
@someeuri.comとなっておりレスポンス側である。ま
た、サービスの種類は<rm:Service>で始まる行にItem Q
uote Service と記載されているように、問い合わせの
サービスである。さらにメッセージの種類は<rm: Messa
ge Type>で始まる行に Request と記載されているよう
に要求メッセージである。このメッセージの送信要求に
はメッセージ本体の情報がないので、<SOAP:Body>と</S
OAP:Body>との間には何も記載されていない。図２１は
署名無し送信メッセージの一例を示す図である。このメ
ッセージは図３のステップＳ３３におけるリクエスト側
からのメッセージ送信に使用される。同図において、<S
OAP:Envelope と</SOAP:ENVELOPE>との間の情報の中
で、最初の行は図２０と同じである。また、<rm:Messag
e Header…>と</rm:Message Header>との間のヘッダに
おける、送信元、送信先、サービスの種類も図２０の例
と同じである。この他にメッセージ種類、メッセージＩ
Ｄ、送信日時等が記載されている。メッセージの種類は
<rm: Message Type>で始まる行にMessage と記載されて
いるようにメッセージである。また、メッセージＩＤと
して<rm: Message Id>の行に20020907-045261-0450@any
uri.com が記載されている。さらに、送信日時として<r
m: Timestamp>の行に 2002-09-07T10:19:07 と記載され
ている。<rm:Reliable Message…>と</rm:Reliable Mes
sage>の間のヘッダには、送信メッセージの信頼性を確
保するための情報が記載されている。即ち、<rm:AckReq
uested SOAP:must understand...は確認メッセージの形
式が SOAP の標準に準拠すべきことを記述したものであ
る。また、<rm:Duplicate Elimination/>は重複受信を
したメッセージを削除するものである。<SOAP:BODY>と<
/SOAP:BODY>との間にはアプリケーションに依存する情
報本体の内容が記載される。図５におけるステップＳ５
６で送信されるメッセージも、送信元と送信先が図２２
に示したものと逆になるだけで図２２と同様の形式で作
成される。図２２は署名無し受信確認メッセージの一例
を示す図である。このメッセージは図３のステップＳ３
９で使用される。メッセージの形式は図２１に示したも
のと同様であるので詳細な説明は省略する。サービスの
種類が Item Filing Service となっていてファイルス
ルサービスであること、及びメッセージの種類が Ackno
wledgement となっていて確認のメッセージであること
に着目される。本例では送信元がレスポンス側であり送
信先がリクエスト側であるが、送信元をリクエスト側に
し送信先をレスポンス側にすれば図５のステップＳ６２
で使用するメッセージとなる。図２３から図２５は署名
有りの送信メッセージの一例を示す図である。このメッ
セージは図１０のステップＳ１０４で使用される。この
メッセージにおいて、第１行の<SOAP:Envelope>から第
１９行の</rm:Reliable Message>までは図２１に示した
署名無し送信メッセージと同じである。本例では、その
次の行に<wsse:Security xmls:wsse=”から</wsse:Bina
rySecurity Token>までのタグが存在する。ここでは、
ウェブ・サービス・セキュリティ（Web Service Securi
ty ）(wsse)によりセキュリティを確保している。次の
タグである<ds:Signature xmls…から</ds:SignatureVa
lue>までの間で、署名がXML形式で記載されている。署
名の対象は、<ds:Xpath>のタグに記載されているよう
に、メッセージヘッダと、リライアブルメッセージ(Rel
iable Message)と、情報本体(SOAP Body)である。これ
により、メッセージヘッダと、リライアブルメッセージ
と、情報本体に対する改竄を防止できる。このように、
送信メッセージに WS-Security 形式の署名を付けるこ
とにより、送信者の否認を防止できる。本例において
も、送信元をレスポンス側とし送信先をリクエスト側と
すれば、図１１のステップＳ１２６で使用するメッセー
ジとなる。図２６から図２８は署名有りの受信確認メッ
セージの一例を示す図である。このメッセージは図１０
のステップＳ１１３、図１３のステップＳ１６０、又は
図１６のステップＳ２０４で使用される。メッセージの
形式は図２３から図２５に示したものと同様であるので
詳細な説明は省略する。サービスの種類が Item Filing
Service となっていてファイルスルサービスであるこ
と、及びメッセージの種類が Acknowledgement となっ
ていて確認のメッセージであることに着目される。この
例においても、受信確認メッセージに WS-Security 形
式の署名を付けることにより、メッセージヘッダと、リ
ライアブルメッセージと、情報本体に対する改竄を防止
できる。本例においても、送信元をリクエスト側とし、
送信先をレスポンス側とすることにより図１１のステッ
プＳ１３６、図１４のステップＳ１８３、又は図１７の
ステップＳ２３６で使用するメッセージとなる。
【００８７】
【発明の効果】上記の通り、本発明によれば、片方向の
リクエスト／レスポンス型の通信プロトコルを用いて、
双方向の送達確認を実現することができるという効果が
得られる。
リクエスト／レスポンス型の通信プロトコルを用いて、
双方向の送達確認を実現することができるという効果が
得られる。
【００８８】また、送受信されたメッセージに対して署
名を作成し、これを交換することで、送受信が確かに行
なわれたことを証拠として残し、送信事実、受信事実の
否認を防止することができるという効果が得られる。
名を作成し、これを交換することで、送受信が確かに行
なわれたことを証拠として残し、送信事実、受信事実の
否認を防止することができるという効果が得られる。
【００８９】さらに、ＸＭＬ を用いてメッセージを構
築することにより、メッセージの一意性を保証する処理
の自動化を容易にすることができるという効果が得られ
る。さらに、受信メッセージの保存がバッファの容量不
足によりエラーとなった場合でも、古いメッセージや古
い署名を削除することにより、エラーを回避できるとい
う利点もある。
築することにより、メッセージの一意性を保証する処理
の自動化を容易にすることができるという効果が得られ
る。さらに、受信メッセージの保存がバッファの容量不
足によりエラーとなった場合でも、古いメッセージや古
い署名を削除することにより、エラーを回避できるとい
う利点もある。
【図１】リクエスト／レスポンス型の同期通信のみを用
いる従来のシステムの構成を示すブロック図である。
いる従来のシステムの構成を示すブロック図である。
【図２】本発明の第１の実施の形態によりリクエスト側
からレスポンス側にメッセージの送信する場合のデータ
の流れを示すブロック図である。
からレスポンス側にメッセージの送信する場合のデータ
の流れを示すブロック図である。
【図３】図２に示したメッセージを送信する場合の処理
の流れを説明するフローチャートである。
の流れを説明するフローチャートである。
【図４】本発明の第１の実施の形態により双方向通信を
可能にする場合のデータの流れを示すブロック図であ
る。
可能にする場合のデータの流れを示すブロック図であ
る。
【図５】図４に示したメッセージを送信する場合の処理
の流れを説明するフローチャートである。
の流れを説明するフローチャートである。
【図６】本発明の第２の実施の形態によりメッセージ中
の定まったフォーマットの中の特定の場所にメッセージ
の識別子（ＩＤ）を埋め込む方法を説明する図である。
の定まったフォーマットの中の特定の場所にメッセージ
の識別子（ＩＤ）を埋め込む方法を説明する図である。
【図７】本発明の第３の実施の形態によりメッセージ内
にメッセージ内容とは別にネームスペースでメッセージ
ＩＤを埋め込む方法を説明する図である。
にメッセージ内容とは別にネームスペースでメッセージ
ＩＤを埋め込む方法を説明する図である。
【図８】本発明の第４の実施の形態により、メッセージ
のダイジェストを利用してメッセージの一意性を検証す
る方法を説明する図である。
のダイジェストを利用してメッセージの一意性を検証す
る方法を説明する図である。
【図９】本発明の第５の実施の形態により送信者による
送信の事実を後に送信者が否認することを防止する方法
におけるデータの流れを説明するブロック図である。
送信の事実を後に送信者が否認することを防止する方法
におけるデータの流れを説明するブロック図である。
【図１０】図９に示したシステムにおいて、リクエスト
側１１からレスポンス側１２にメッセージを送信する場
合において、送信事実の送信者による否認を防止する処
理の流れを説明するフローチャートである。
側１１からレスポンス側１２にメッセージを送信する場
合において、送信事実の送信者による否認を防止する処
理の流れを説明するフローチャートである。
【図１１】図９に示したシステムにおいて、レスポンス
側１２からリクエスト側１１にメッセージを送信する場
合において、送信事実の送信者による否認を防止する処
理の流れを説明するフローチャートである。
側１２からリクエスト側１１にメッセージを送信する場
合において、送信事実の送信者による否認を防止する処
理の流れを説明するフローチャートである。
【図１２】本発明の第６の実施の形態により受信者によ
る受信の事実を後に受信者が否認することを防止する方
法におけるデータの流れを説明するブロック図である。
る受信の事実を後に受信者が否認することを防止する方
法におけるデータの流れを説明するブロック図である。
【図１３】図１２に示したシステムにおいて、リクエス
ト側１１からレスポンス側１２にメッセージを送信する
場合において、受信事実の受信者による否認を防止する
処理の流れを説明するフローチャートである。
ト側１１からレスポンス側１２にメッセージを送信する
場合において、受信事実の受信者による否認を防止する
処理の流れを説明するフローチャートである。
【図１４】図１２に示したシステムにおいて、レスポン
ス側１２からリクエスト側１１にメッセージを送信する
場合において、受信事実の受信者による否認を防止する
処理の流れを説明するフローチャートである。
ス側１２からリクエスト側１１にメッセージを送信する
場合において、受信事実の受信者による否認を防止する
処理の流れを説明するフローチャートである。
【図１５】本発明の第７の実施の形態により送受信者に
よる送受信の事実を後に送受信者が否認することを防止
する方法におけるデータの流れを説明するブロック図で
ある。
よる送受信の事実を後に送受信者が否認することを防止
する方法におけるデータの流れを説明するブロック図で
ある。
【図１６】図１５に示したシステムにおいて、リクエス
ト側１１からレスポンス側１２にメッセージを送信する
場合の処理の流れを説明するフローチャートである。
ト側１１からレスポンス側１２にメッセージを送信する
場合の処理の流れを説明するフローチャートである。
【図１７】図１５に示したシステムにおいて、レスポン
ス側１２からリクエスト側１１にメッセージを送信する
場合において、送受信事実の送受信者による否認を防止
する処理の流れを説明するフローチャートである。
ス側１２からリクエスト側１１にメッセージを送信する
場合において、送受信事実の送受信者による否認を防止
する処理の流れを説明するフローチャートである。
【図１８】図３におけるステップＳ３７又は図５におけ
るステップＳ６０におけるメッセージの保管が成功しな
かった場合の本発明の第８の実施の形態によるメッセー
ジ保管方法を説明するフローチャートである。
るステップＳ６０におけるメッセージの保管が成功しな
かった場合の本発明の第８の実施の形態によるメッセー
ジ保管方法を説明するフローチャートである。
【図１９】図１６におけるステップＳ２０１又は図１７
におけるステップＳ２３３におけるメッセージ及び署名
の保管が成功しなかった場合の本発明の第９の実施の形
態によるメッセージ及び署名の保管方法を説明するフロ
ーチャートである。
におけるステップＳ２３３におけるメッセージ及び署名
の保管が成功しなかった場合の本発明の第９の実施の形
態によるメッセージ及び署名の保管方法を説明するフロ
ーチャートである。
【図２０】リクエスト側からレスポンス側に対してメッ
セージの送信要求をする場合のメッセージの内容の一例
である。
セージの送信要求をする場合のメッセージの内容の一例
である。
【図２１】署名無し送信メッセージの一例を示す図であ
る。
る。
【図２２】署名無し受信確認メッセージの一例を示す図
である。
である。
【図２３】署名有りの送信メッセージの一例の一部を示
す図である。
す図である。
【図２４】署名有りの送信メッセージの一例の他の一部
を示す図である。
を示す図である。
【図２５】署名有りの送信メッセージの一例の更に他の
一部を示す図である。
一部を示す図である。
【図２６】署名有りの受信確認メッセージの一例の一部
を示す図である。
を示す図である。
【図２７】署名有りの受信確認メッセージの一例の他の
一部を示す図である。
一部を示す図である。
【図２８】署名有りの受信確認メッセージの一例の更に
他の一部を示す図である。
他の一部を示す図である。
１１…リクエスト側
１２…レスポンス側
１３…ファイアウォール
２１…メッセージ
２１ａ…メッセージ
２２…受信通知
２２ａ…受信通知
４１…受信要求
４２…メッセージ
４２ａ…メッセージ
４３…受信通知
４３ａ…受信通知
９０…署名
９１…データベース
９２…署名
９３…データベース
１２０…署名
１２１…データベース
１２２…署名
１５１…データベース
─────────────────────────────────────────────────────
フロントページの続き
Ｆターム(参考） 5K018 BA03 FA02
5K034 AA06 DD01 EE10 HH01 HH02
HH11 MM05
Claims (7)
- 【請求項１】 リクエスト側からレスポンス側への片方
向のリクエストと該リクエストに対する前記レスポンス
側から前記リクエスト側へのレスポンスを行うリクエス
ト／レスポンス型の同期通信のみを用いるシステムにお
いて、 前記リクエスト側から前記レスポンス側に向けてメッセ
ージを送信する際は、前記レスポンス側がメッセージを
受信したことを、前記リクエスト側に返信するまで、同
じメッセージを前記レスポンス側に送信し続け、 前記レスポンス側から前記リクエスト側に向けてメッセ
ージを送信する際は、前記リクエスト側がメッセージの
受信要求を行ない、前記リクエスト側がメッセージを受
信したことを、新たな通信で前記レスポンス側に受信通
知するまで、前記レスポンス側は同じメッセージを前記
リクエスト側に送信し続け、 それにより、双方向でメッセージの送受信を可能にした
双方向通信手法。 - 【請求項２】 送信するメッセージ内に一意の識別子を
付加し、受信側で重複チェックを行なうことにより、同
じメッセージを重複して受信することを防ぐようにした
請求項１記載の双方向通信手法。 - 【請求項３】 前記メッセージの形式にＸＭＬを利用
し、前記メッセージとは異なる特定のネームスペースで
メッセージ内に前記識別子を付加することで、メッセー
ジの形式を変更せずに、同じメッセージを重複して受信
することを防ぐようにした請求項２記載の双方向通信手
法。 - 【請求項４】 前記メッセージの一意性は任意の形で実
現し、メッセージの一意性を検証する際に、該メッセー
ジのダイジェスト値を利用することで、同じメッセージ
を重複して受信することを防ぐようにした請求項１記載
の双方向通信手法。 - 【請求項５】 受信メッセージをバッファに保管完了し
た後にメッセージを受信したことをメッセージ送信側に
通知するようにし、前記バッファの容量不足により前記
受信メッセージの保管に失敗した場合は前記バッファ内
の古いメッセージを削除することにより受信メッセージ
を前記バッファに保管するようにした請求項１記載の双
方向通信方法。 - 【請求項６】 前記メッセージの送信側が送信するメッ
セージに送信メッセージ用電子署名を付加し、該送信メ
ッセージ用電子署名を受信側が保管することによって送
信側による送信事実の否認を防止することができるよう
にすることと、 前記メッセージの受信側が前記メッセージの受信に応答
して送信するメッセージ受信通知に、受信通知用電子署
名を付加し、該受信通知用電子署名を、送信側が保管す
ることによって受信側による受信事実の否認を防止する
ことができるようにすることと、のすくなくとも一方を
採用した請求項２から４のいずれか一項記載の双方向通
信手法。 - 【請求項７】 前記署名付きの受信メッセージを受信側
のバッファに保管完了した後にメッセージを受信したこ
とをメッセージ送信側に通知するようにし、前記バッフ
ァの容量不足により前記受信メッセージ及び前記署名の
少なくとも一方の保管に失敗した場合は前記バッファ内
の古いメッセージを削除した後に前記バッファの容量が
依然として不足の場合は前記バッファ内の古い署名を削
除することにより前記署名付きの受信メッセージを前記
バッファに保管するようにした請求項６記載の双方向通
信方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002350379A JP2003249919A (ja) | 2001-12-17 | 2002-12-02 | 双方向通信方法 |
| US10/320,347 US20030158961A1 (en) | 2001-12-17 | 2002-12-16 | Two-way communication method |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001383324 | 2001-12-17 | ||
| JP2001-383324 | 2001-12-17 | ||
| JP2002350379A JP2003249919A (ja) | 2001-12-17 | 2002-12-02 | 双方向通信方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2003249919A true JP2003249919A (ja) | 2003-09-05 |
Family
ID=27736402
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002350379A Pending JP2003249919A (ja) | 2001-12-17 | 2002-12-02 | 双方向通信方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20030158961A1 (ja) |
| JP (1) | JP2003249919A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007087171A (ja) * | 2005-09-22 | 2007-04-05 | Fuji Xerox Co Ltd | 電子メール送受信装置、プログラム、方法 |
| KR100712655B1 (ko) | 2004-04-26 | 2007-05-02 | 트렉 2000 인터네셔널 엘티디. | 암호화 시스템을 구비한 휴대용 데이터 저장 장치 |
| JP2008544713A (ja) * | 2005-06-28 | 2008-12-04 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ウェブ・サービスにおける秘密データ通信 |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8060626B2 (en) | 2008-09-22 | 2011-11-15 | Sony Computer Entertainment America Llc. | Method for host selection based on discovered NAT type |
| US8224985B2 (en) | 2005-10-04 | 2012-07-17 | Sony Computer Entertainment Inc. | Peer-to-peer communication traversing symmetric network address translators |
| US20040205770A1 (en) * | 2003-02-11 | 2004-10-14 | International Business Machines Corporation | Duplicate message elimination system for a message broker |
| US7693952B2 (en) * | 2003-03-27 | 2010-04-06 | Microsoft Corporation | Availability and scalability in a messaging system in a manner transparent to the application |
| US7685301B2 (en) * | 2003-10-20 | 2010-03-23 | Sony Computer Entertainment America Inc. | Redundancy lists in a peer-to-peer relay network |
| US8090940B1 (en) | 2004-06-01 | 2012-01-03 | Cisco Technology, Inc. | Method and system for verifying identification of an electronic message |
| US7437558B2 (en) * | 2004-06-01 | 2008-10-14 | Cisco Technology, Inc. | Method and system for verifying identification of an electronic mail message |
| US7812983B2 (en) * | 2005-03-25 | 2010-10-12 | Microsoft Corporation | Methods and systems for transferring binary data |
| US8315988B2 (en) * | 2006-08-31 | 2012-11-20 | Sap Ag | Systems and methods for verifying a data communication process |
| US7519614B2 (en) * | 2006-08-31 | 2009-04-14 | Sap Ag | Data verification systems and methods using business objects |
| US8484167B2 (en) * | 2006-08-31 | 2013-07-09 | Sap Ag | Data verification systems and methods based on messaging data |
| US7995478B2 (en) | 2007-05-30 | 2011-08-09 | Sony Computer Entertainment Inc. | Network communication with path MTU size discovery |
| US7856501B2 (en) | 2007-12-04 | 2010-12-21 | Sony Computer Entertainment Inc. | Network traffic prioritization |
| US7856506B2 (en) | 2008-03-05 | 2010-12-21 | Sony Computer Entertainment Inc. | Traversal of symmetric network address translator for multiple simultaneous connections |
| JP5341198B2 (ja) * | 2008-10-30 | 2013-11-13 | ヒューレット−パッカード デベロップメント カンパニー エル．ピー． | 通信インタフェースにおけるビット反転 |
| WO2014192419A1 (ja) * | 2013-05-28 | 2014-12-04 | ソニー株式会社 | 情報処理装置、通信システム、通信方法およびプログラム |
| SE544340C2 (en) * | 2019-11-19 | 2022-04-12 | Assa Abloy Ab | Secure configuration of a target device performed by a user device |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4807118A (en) * | 1987-01-14 | 1989-02-21 | Hewlett-Packard Company | Method for handling slot requests over a network |
| DE69535927D1 (de) * | 1994-09-01 | 2009-04-16 | Echelon Corp | Verfahren und Gerät zur Erkennung von doppelte Nachrichten |
| US5799012A (en) * | 1995-08-11 | 1998-08-25 | Motorola, Inc. | System controlled asymmetrical automatic repeat request protocol method |
| US6115744A (en) * | 1996-07-30 | 2000-09-05 | Bea Systems, Inc. | Client object API and gateway to enable OLTP via the internet |
| US6820202B1 (en) * | 1998-11-09 | 2004-11-16 | First Data Corporation | Account authority digital signature (AADS) system |
| US6473829B1 (en) * | 1999-05-28 | 2002-10-29 | International Business Machines Corporation | Data storage device providing communication between processing units |
| US6654892B1 (en) * | 1999-06-08 | 2003-11-25 | Sun Microsystems, Inc. | Methods and apparatus for permitting transactions across firewalls |
| US6757717B1 (en) * | 1999-09-16 | 2004-06-29 | Proxyconn, Inc. | System and method for data access |
| US20020055963A1 (en) * | 2000-11-06 | 2002-05-09 | Yasuhiko Kanemasa | Data interchange system, data interchange instrument and method thereof |
| EP1378092B1 (en) * | 2001-02-22 | 2008-06-25 | Bea Systems, Inc. | System and method for message encryption and signing in a transaction processingsystem |
-
2002
- 2002-12-02 JP JP2002350379A patent/JP2003249919A/ja active Pending
- 2002-12-16 US US10/320,347 patent/US20030158961A1/en not_active Abandoned
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100712655B1 (ko) | 2004-04-26 | 2007-05-02 | 트렉 2000 인터네셔널 엘티디. | 암호화 시스템을 구비한 휴대용 데이터 저장 장치 |
| US8037309B2 (en) | 2004-04-26 | 2011-10-11 | Trek 2000 International Ltd. | Portable data storage device with encryption system |
| JP2008544713A (ja) * | 2005-06-28 | 2008-12-04 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ウェブ・サービスにおける秘密データ通信 |
| JP2007087171A (ja) * | 2005-09-22 | 2007-04-05 | Fuji Xerox Co Ltd | 電子メール送受信装置、プログラム、方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20030158961A1 (en) | 2003-08-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2003249919A (ja) | 双方向通信方法 | |
| CN108681965B (zh) | 离线节点的区块链网络交易处理方法和装置 | |
| US7359920B1 (en) | Communication protocol for synchronization of personal information management databases | |
| US7895349B2 (en) | Messaging protocol in enterprise applications | |
| US9524327B2 (en) | Method and system for data synchronization, and apparatus thereof | |
| AU2003225818B2 (en) | Data replication system and method | |
| US6757717B1 (en) | System and method for data access | |
| US7359919B2 (en) | Reliable request-response messaging over a request-response transport | |
| US9143358B2 (en) | Electronic document communication system and electronic document communication method | |
| US20140279936A1 (en) | Method for data retrieval from a distributed data storage system | |
| US20040010543A1 (en) | Cached resource validation without source server contact during validation | |
| US7149898B2 (en) | Self-monitoring and trending service system with a cascaded pipeline with enhanced authentication and registration | |
| US20060239197A1 (en) | Flower-petal resolutions for PNRP | |
| US6920476B2 (en) | Messaging system for computers | |
| CN106657269B (zh) | 文件传输方法 | |
| TW200402961A (en) | Data communication method | |
| US6581175B1 (en) | Apparatus and method of requesting retransmission of a message across a network | |
| JP4765731B2 (ja) | 文書管理システム、文書管理サーバ、文書の提供方法、及びプログラム | |
| CN109688204B (zh) | 基于ndn网络的文件下载方法、节点、终端 | |
| JP6932961B2 (ja) | 電文送受信システム、電文送信装置、電文送受信方法およびプログラム | |
| JP2005109849A (ja) | 送信サーバ用データ交換処理プログラムおよび受信サーバ用データ交換処理プログラム | |
| US20230308521A1 (en) | Management device, management method, and recording medium | |
| US9781131B2 (en) | Systems and methods for securing remote configuration | |
| CN112953835B (zh) | 数据传输方法、装置及系统 | |
| CN113821710B (zh) | 全域搜索方法、装置、电子设备和计算机存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050405 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050606 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050726 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050921 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20051004 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20051209 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090420 |