(57)【要約】      （修正有）【課題】複数の決済サービスを提供し電子商取引を促進させるためのシステム及び方法を提供する。【解決手段】サービスは、オンライン取引を行う買手１０６及び売手１０８を含む４コーナーモデルと関連して提供される。買手１０６は、第１金融機関１０２の顧客である。第１金融機関１０２は、買手１０６の認証局としての機能を果たし、秘密鍵と第１金融機関１０２が署名したデジタル証明書とを含むハードウェアのトークンを売手１０８に発行する。実行に際し、買手１０６は、自分の秘密鍵を使用して、第１金融機関１０２又は第２金融機関１０４に送る支払指図書に署名する。この指図メッセージは、売手１０８又は第２金融機関１０４を介して間接的に第１の金融機関１０２に転送される。システムによってサポートされる支払指図として、支払要求、支払債務、保証付き支払債務、及び条件付き支払を挙げることができる。【選択図】図１
2011118898.tif 000002
【特許請求の範囲】
【請求項１】
ルート実体と第１参加者と第２参加者と前記第１参加者の顧客である第１顧客と前記第２参加者の顧客である第２顧客とを含み、各々がデジタル証明書及びこれに関連する秘密鍵を備えた複数の実体で構成された４コーナーモデルにおいて決済サービスを提供する方法であって、
前記第１顧客が、支払期日を指定する支払指図書の買手欄に記入する段階、
前記第１顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、
前記第１顧客が、前記支払指図書を前記第２顧客に送信する段階、
前記第２顧客が、前記支払指図書の売手欄に記入する段階、
前記第２顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、
前記第２顧客が、前記支払指図書を第２参加者に送信する段階、
前記第２参加者が、前記支払指図書の第２参加者欄に記入する段階、
前記第２参加者が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、
前記第２参加者が、前記支払指図書を第１参加者に送信する段階、及び
前記第１参加者が、前記支払期日に、前記支払指図書の指図を実行する段階を含むことを特徴とする方法。
【請求項２】
前記支払指図書は、支払要求指図書であることを特徴とする請求項１に記載の方法。
【請求項３】
前記支払指図書は、支払債務指図書であることを特徴とする請求項１に記載の方法。
【請求項４】
前記支払指図書は、条件付き支払要求指図書であることを特徴とする請求項１に記載の方法。
【請求項５】
前記支払指図書は、条件付き支払債務指図書であることを特徴とする請求項１に記載の方法。
【請求項６】
前記支払指図書は、保証付き支払債務指図書であることを特徴とする請求項１に記載の方法。
【請求項７】
前記支払指図書は、保証付き／条件付き支払債務指図書であることを特徴とする請求項１に記載の方法。
【請求項８】
前記第１顧客は、決済サービスに関する役割及び責任を規定する第１参加者との契約を履行することを特徴とする請求項１に記載の方法。
【請求項９】
前記第２顧客は、決済サービスに関する役割及び責任を規定する第２参加者との契約を履行することを特徴とする請求項１に記載の方法。
【請求項１０】
決済サービスを提供する方法であって、
買手に、各々が関連を持つ支払指示書である複数の支払手段を提供する段階、
前記買手が、前記複数の支払手段の１つを選択する段階、
前記買手によって選択された前記支払手段に関連するとともに支払期日を指定する支払指図メッセージの少なくとも第１欄に前記買手が記入する段階、
前記第１顧客が、前記買手のデジタル証明書に対応する秘密鍵を用いて、前記支払指図メッセージに署名する段階、
前記署名された支払指図メッセージが、銀行によって受信される段階、及び
前記銀行が、支払期日に、前記支払指図メッセージの指図を実行する段階を含むことを特徴とする方法。
【請求項１１】
前記選択された支払手段は、支払要求であることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記選択された支払手段は、支払債務であることを特徴とする請求項１０に記載の方法。
【請求項１３】
前記選択された支払手段は、条件付き支払要求であることを特徴とする請求項１０に記載の方法。
【請求項１４】
前記選択された支払手段は、条件付き支払債務であることを特徴とする請求項１０に記載の方法。
【請求項１５】
前記選択された支払手段は、保証付き支払債務であることを特徴とする請求項１０に記載の方法。
【請求項１６】
前記選択された支払手段は、保証付き／条件付き支払債務であることを特徴とする請求項１０に記載の方法。
【請求項１７】
前記支払手段は、譲渡可能であることを特徴とする請求項１０に記載の方法。
【請求項１８】
参加者と前記参加者の顧客である顧客とを含み、各々がデジタル証明書及びこれに関連する秘密鍵を備えた複数の実体で構成される買手対参加者モデルにおいて決済サービスを提供する方法であって、
前記顧客が、支払期日を指定する支払指図書の買手欄に記入する段階、
前記顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、
前記顧客が、前記支払指図書を前記参加者に送信する段階、
前記参加者が、前記支払指図書の参加者欄に記入する段階、
前記参加者が、自分の秘密鍵で、前記支払指図書に署名する段階、及び
前記参加者が、支払期日に、前記支払指図書の指図を実行する段階を含むことを特徴とする方法。
【請求項１９】
参加者と第１顧客と前記参加者の顧客である第２顧客とを含み、各々がデジタル証明書及びこれに関連する秘密鍵を備えた複数の実体で構成される口座振替モデルにおいて決済サービスを提供する方法であって、
前記第１顧客が、支払期日を指定する支払指図書の買手欄に記入する段階、
前記第１顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、
前記第１顧客が、前記支払指図書を第２顧客に送信する段階、
前記第２顧客が、前記支払指図書の売手欄に記入する段階、
前記第２顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、
前記第２顧客が、前記支払指図書を前記参加者に送信する段階、
前記参加者が、前記支払指図書の参加者欄に記入する段階、
前記参加者が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、及び
前記参加者が、支払期日に、前記支払指図書の指図を実行する段階を含むことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
(関連出願）
本出願は、「決済サービスのためのシステム及び方法」と題する１９９９年９月２４日出願の米国仮特許出願番号第６０／１５５，８４１号に基づく優先権を主張するものである。尚、この米国仮特許出願を本出願の参考文献とする。
【０００２】
本発明は、全体的には、公開鍵暗号基盤を介してサービスを提供することにより電子商取引を促進する分野に関する。
【背景技術】
【０００３】
電子商取引の世界では、契約当事者間の関係構築についての新たな課題が生じている。これら課題の１つは、取引当事者が互いに会ったり話し合ったりすることができず、さもなければ互いの身元及び行為権限を容易には確認できないということに起因する。
この問題に関する１つの対処方法は、送信メッセージに署名するための秘密鍵を取引当事者の各々が提供し合うことである。署名する側が、彼の秘密鍵で署名したメッセージを解読する関連の公開鍵を提供することによって、受信側は送信者の身元を確認することが可能となる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、送信者の公開鍵が、事前に受信者に知らされていないことがある。その場合には、送信者は、認証局によって発行されたデジタル証明書を、彼の署名入りメッセージとともに送信することができる。この証明書自体が、特定の公開鍵が送信者の公開鍵であることを証明する（認証局の秘密鍵で署名された）署名付き電子文書となる。
【０００５】
また、時には、受信者が認証局の公開鍵に不案内であったり、証明書が現在も有効であるかどうか識別できなかったりすることもある。この場合には、受信者は、自身が信頼する実体（実体）によってその証明書の信憑性及び有効性を調査することを望むであろう。証明書のステータスを調査するための公知プロトコルの１つに、オンライン証明書ステータスプロトコル（ＯＣＳＰ）がある。
電子商取引が直面するもう１つの課題は、決済及び決済システムの確立に関係する。時として、購入者は、販売業者にクレジットカード番号を送信することによって、インターネットを介して購入した商品の代金を支払う。この方法は、その手法に関連した機密上のリスク等の難点があり、対消費者取引でさえ不都合が多く、まして対事業所取引に適応するものではない。
【０００６】
また、これまでに幾つかの電子決済システムが提案されおり、デジタル証明書を用いて支払人の身元を認証する方式もその１つである。しかしながら、これらのシステムは、今日の電子商取引、特に、対事業所電子商取引に必要とされる一連の決済証書を提供するものではなく、電子決済を確実に且つ検証し得るに足る基盤を提供できない場合が多い。
【課題を解決するための手段】
【０００７】
電子商取引を促進する複数の決済システム（ｐａｙｍｅｎｔ  ｓｅｒｖｉｃｅ）を提供するためのシステム及び方法が開示される。好ましい実施形態において、これらサービスは、４コーナー信頼モデル（ｆｏｕｒ−ｃｏｒｎｅｒ  ｔｒｕｓｔ  ｍｏｄｅｌ）との関連において提供される。４コーナーモデルは、オンライン取引に参加する、加入顧客（Ｓｕｂｓｃｒｉｂｉｎｇ  Ｃｕｓｔｏｍｅｒ）とも呼ばれる買手及び信頼顧客（Ｒｅｌｙｉｎｇ  Ｃｕｓｔｏｍｅｒ）とも呼ばれる売手を含む。買手は、発行参加者（Ｉｓｓｕｉｎｇ  Ｐａｒｔｉｃｉｐａｎｔ）と呼ばれる第１の金融機関の顧客である。発行参加者は、買手のための認証局の役割を果たし、秘密鍵と発行参加者によって署名されたデジタル証明書とを含むハードウェアのトークンを買手に発行する。売手は、信頼参加者（Ｒｅｌｙｉｎｇ  ｐａｒｔｉｃｉｐａｎｔ）と呼ばれる第２の金融機関の顧客である。信頼参加者は、売手のための認証局（ｃｅｒｔｉｆｉｃａｔ  ａｕｔｈｏｒｉｔｙ）の役割を果たし、秘密鍵と信頼参加者によって署名されたデジタル証明書とを含むハードウェアのトークンを売手に発行する。また、このシステムには、発行参加者及び信頼参加者に対してデジタル証明書（ｄｉｇｉｔａｌ  ｃｅｒｔｉｆｉｃａｔｅ）を発行するルート認証局（ｒｏｏｔ  ｃｅｒｔｉｆｉｃａｔｅ  ａｕｔｈｏｒｉｔｙ）も含まれる。
【０００８】
４コーナーモデルの１つの利点は、売手と買手との間の信頼が、各当事者が同じ認証局を使って互いのデジタル証明書又は身元を検証することによって決定されるのではない点にある。そうではなくて、売手及び買手は、最初に各自の取引銀行にこの検証を求める。次に、売手と買手の取引銀行は、売手及び買手の相互の身元と両者が交換するメッセージの完全性とを高い信頼性を持って検証するために必要な橋渡しをするようルート実体に求める。
【０００９】
本システム及び方法は、この信頼モデルを活用して買手及び売手に対する決済サービス機能を向上する。４コーナー信頼モデルと、両当事者及びそれぞれの取引銀行の間で既に確立されている銀行取引関係とによって、これら両当事者は、オンラインでの購買又は売買を完結し、それと同時に、確実で効率が良く且つ場合によっては保証付きの支払の取り決めをすることが可能となる。更に、本システムにおいて、デジタル署名した支払指図書を使用することにより、認証、メッセージの完全性、否認防止性、及び機密性を確保することができる。
【００１０】
好ましい実施形態において、本システムにおける支払メッセージング（ｐａｙｍｅｎｔ  ｍｅｓｓａｇｉｎｇ）は、買手から売手、売手の取引銀行、買手の取引銀行へと進められる。従って、例えば、買手が支払指図書に署名してこれを売手に送ると、売手は、それを売手の取引銀行に転送し、売手の取引銀行がそれを最終的に買手の取引銀行に配信することにより買手の取引銀行が支払を行う。
両当事者は、各々の取引銀行との間で決済認可、作業手順、及び清算指図を既に確立しており、これによって両当事者が個別のオフライン手続きではなく取引と並行したオンライン決済を開始できる状態にあるということもあり、本システム及び方法は効果的に機能する。銀行での標準化された決済処理手順により、効率は更に向上する。
【発明の効果】
【００１１】
本システム及び方法は、買手に多くの利点を与える。特に、本システム及び方法によれば、買手は、様々な決済方式を選択、利用して売手の要求を満たすことができる。また、買手は、よりタイミング良くしかも更に多くの情報を持って資金繰りを行うことができる。更に、本システム及び方法によれば、買手は、条件付き支払を利用することにより、売買に内在するリスクを補うことができる。更に、買手には、支払と購入とが１つのプロセスにまとめられたような効率的な仕事の流れが約束される。本システム及び方法を長年使用されている既存システムと調和させることにより、取引全体を完全に電子処理化することが可能となる。
【００１２】
更に、本システム及び方法は、売手にも多くの利点を与える。特に、本システム及び方法によれば、売手は、大切な得意先に合わせた支払条件を提案することができる。また、保証付き支払によって、売手は、自身の信用取引リスクを軽減することもできる。加えて、本システム及び方法によれば、売手は、よりタイミング良くしかも更に多くの情報を持って資金繰りを行うことができる。更に、売手にも、支払と購入とが１つのプロセスにまとめられたような効率的な仕事の流れが約束される。また、売手が支払債券を所有している場合には、売手は彼の取引銀行に債券を割引して売手に資金融資するよう依頼することができる。本システム及び方法を長年使用されている既存システムと調和させることにより、取引全体を完全に電子処理化することが可能となる。
【００１３】
好ましい実施形態において、本システム及び方法により、複数の決済手段が円滑に活用される。これら決済手段には、支払要求（ｐａｙｍｅｎｔ  ｏｒｄｅｒ）、支払債務（ｐａｙｍｅｎｔ  ｏｂｌｉｇａｔｉｏｎ）、保証付き支払債務（ｃｅｒｔｉｆｉｅｄ  ｐａｙｍｅｎｔ  ｏｂｌｉｇａｔｉｏｎ）、及び条件付き支払（ｃｏｎｄｉｔｉｏｎａｌ  ｐａｙｍｅｎｔ）が含まれる。これらの決済手段の各々については、以下でより詳細に説明する。
好ましい実施形態において、本システムにより、売買可能な電子決済手段の作成及び譲渡が促進される。例えば、本システムは、好ましくは流通市場で売却できる支払債券（ｐａｙｍｅｎｔ  ｏｂｌｉｇａｔｉｏｎ）を含む。これら支払債券の所有者の変更は、好ましくは所有者登録サービス（ｈｏｌｄｅｒ  ｒｅｇｉｓｔｒｙ  ｓｅｒｖｉｃｅ）によって行うことができる。
上述した本発明の概要は、以下の詳細な説明及び添付図面を併せて把握することによって一層良く理解されると考える。
【図面の簡単な説明】
【００１４】
【図１】本システムに用いる４コーナーモデルの好ましい実施形態のブロック図である。
【図２】好ましくは４コーナーモデルにおける各実体に設けられる構成要素を示すブロック図である。
【図３】第１の決済シナリオの構成及び流れの総合図である。
【図４】第２の決済シナリオの構成及び流れの総合図である。
【図５】第３の決済シナリオの構成及び流れの総合図である。
【図６】支払指図書を処理するためのメッセージの流れに関する好ましい実施形態を示す図である。
【図７】支払債務を処理するためのメッセージの流れに関する好ましい実施形態を示す図である。
【図８】支払条件を処理するためのメッセージの流れに関する好ましい実施形態を示す図である。
【発明を実施するための形態】
【００１５】
システムアーキテクチャと技術特性
本明細書は、各金融機関がそれぞれの顧客に対して決済サービスを安全に提供できるようにするシステムに関する。好ましい実施形態において、これらのサービスは、４コーナー信頼モデルとの関連において提供することができる。本発明に用いられる４コーナーモデルの好ましい実施形態を図１に示す。
【００１６】
図１に示すように、４コーナーモデルは、第１の金融機関１０２と第２の金融機関１０４とを含む。第１金融機関１０２は、本システムへの参加者であり、後述するように、その顧客に対してデジタル証明書を発行するということから、「発行参加者（ｉｓｓｕｉｎｇ  ｐａｒｔｉｃｉｐａｎｔ）」と呼ばれる。第２金融機関１０４は、本システムへの参加者であり、後述するように、第２金融機関１０４によって、その顧客が発行参加者１０２及び発行参加者１０２の顧客によって作成された表示に頼るということから、「信頼参加者（ｒｅｌｙｉｎｇ  ｐａｒｔｉｃｉｐａｎｔ）」と呼ばれる。参加者１０２、１０４とは、典型的には銀行又はその他の金融機関である。
【００１７】
図１には、第１の顧客１０６及び第２の顧客１０８も示されている。好ましくは、第１顧客１０６及び第２顧客１０８は、それぞれ、発行参加者１０２の顧客及び信頼参加者１０４の顧客である。
第１顧客１０６は、参加者１０２によって提供されるサービスに加入しているということから、「加入顧客（ｓｕｂｓｃｒｉｂｉｎｇ  ｃｕｓｔｏｍｅｒ）」と呼ばれることもある。第１顧客１０６は、４コーナーモデルでの取引において典型的には買手の役割を果たすということから、「買手（ｂｕｙｅｒ）」と呼ばれることもある。
【００１８】
第２顧客１０８は、発行参加者１０２及び加入顧客１０６の双方によって作られる表示に頼るということから、「信頼顧客（ｒｅｌｙｉｎｇ  ｃｕｓｔｏｍｅｒ）」と呼ばれることがある。また、第２顧客１０８は、４コーナーモデルでの取引において典型的には売手の役割を果たすということから、「売手（ｓｅｌｌｅｒ）」と呼ばれることもある。以下の記述においては、主として、売手１０６及び買手１０８として説明するが、その代わりに、特定の取引において第１顧客１０６及び第２顧客１０８が異なる役割を果たすこともあるということは理解されるべきである。例えば、第１顧客１０６が第２顧客１０８に貸付金を返済する借手となる場合もあろう。
【００１９】
図１にはルート実体（ｒｏｏｔ  ｅｎｔｉｔｙ）１１０も示されている。ルート実体１１０は、典型的には、電子商取引及び電子通信を促進するための一連の共通運用ルールを設定し実施する組織である。ルート実体１１０は、これらの運用ルールに従うことに合意した複数の銀行及び／又はその他の金融機関によって共同で所有される。このようなルート実体の一例は、「証明に関するサービス及びその他のサービスを提供するためのシステム及び方法」と題する２０００年２月１１日に出願され審査過程にある米国特許出願第０９／５０２，４５０号に記載されている。尚、この出願を本明細書の参考文献とされたい。
【００２０】
図２は、好ましくは４コーナーモデルの各実体に設けられる構成要素を示すブロック図である。図２に示すように、好ましくは、参加者１０２、１０４及びルート実体１１０の各々は、本システムによって提供されるサービスに関係する全ての実体相互のメッセージを送受信するためのゲートウェイとしの機能を果たす取引調整装置（ｔｒａｎｓａｃｔｉｏｎ  ｃｏｏｒｄｉｎａｔｏｒ）２０２を備えている。取引調整装置２０２は、発行参加者１０２のオンラインサービス及び信頼参加者１０４のオンラインサービスに対する単一のインターフェースを備えており、取引調整装置２０２と４コーナーモデルの他の実体との間の安全な電子通信の確保に必要な防護対策を行なう。本システムの使用に適した取引調整装置２０２の好ましい実施形態は、「証明書検証等のサービスのためのシステム及び方法」と題する本件特許と同日に出願され審査過程にある米国特許出願第  ／      号に記載されている。尚、この出願を本明細書の参考文献とされたい。
【００２１】
好ましくは、参加者１０２、１０４及びルート実体１１０の各々は、オンライン証明書ステータスプロトコル（ＯＣＳＰ）応答装置２０４及びハードウェア機密保護モジュール（ｈａｒｄｗａｒｅ  ｓｅｃｕｒｉｔｙ  ｍｏｄｕｌｅ，ＨＳＭ）２０６を更に備える。ハードウェア機密保護モジュール（即ち、ハードウェア暗号モジュール）２０６は、メッセージに署名するとともに、メッセージに付けられた署名を検証するよう構成される。
また、好ましくは、各参加者１０２、１０４及びルート実体１１０は、（参加者１０２、１０４の場合、銀行の支払請求アプリケーション２１０に接続された）支払請求データのデータベース２０８と、生の取引記録２１２と、顧客データのデータベース２１４と、（顧客データデータベース２１４に接続された）リスクマネージャ２１６と、ハードウェア機密保護モジュール２１８とを備えており、これらの各々は、取引調整装置２０２に接続されている。
【００２２】
更に、図２に示すように、信頼顧客１０８は、インターネットを介して情報を送受信するように構成されたウェブサーバを備えるのが好ましい。また、信頼顧客１０８は、信頼参加者１０４と通信するための銀行インターフェース２２２を備えるのが好ましい。銀行インターフェース２２２の好ましい一実施形態（及び、信頼顧客１０８が備えるのが好ましいその他の構成要素）は、「証明書関連等のサービスに関する売手の利用を促進するためのシステム及び方法」と題する本件特許と同日に出願され審査過程の米国特許出願第  ／    号に記載されており、この出願を本明細書の参考文献とされたい。信頼顧客１０８は、システムメッセージに署名するとともに、システムメッセージを検証するためのハードウェア暗号モジュール２３０を更に備えるのが好ましい。
また、図２に示すように、加入顧客１０６は、インターネットを閲覧するためのウェブブラウザ２２４と、後述するように、メッセージに署名するためのスマートカード２２６（及び、関連する読取装置）とを備えるのが好ましい。
【００２３】
好ましい実施形態において、各システム実体は、認証を容易にするために、２つのデジタル証明書、即ち、身元証明書（場合によっては、保証証明書と呼ばれる）及びユーティリティ証明書（及び、対応する秘密鍵）を備えている。更に、好ましい実施形態においては、各取引調整装置２０２は、それ自身の身元証明書、ユーティリティ証明書、及び、対応する秘密鍵を備えるのが好ましい。
【００２４】
この身元証明用秘密鍵は、電子商取引のコンテンツに対する実体の契約における責任の証拠としてルート実体１１０から要求されるデジタル署名を作成するために使用される。この鍵を使用してオペレーションをサポートするためには、証明書チェーンが必要である。例えば、「証明書検証等のサービスのためのシステム及び方法」と題する本件特許と同日に出願され審査過程の米国特許出願第  ／    号に記載されているように、身元証明書のステータスは公認された実体から入手することができる。尚、この出願を本明細書の参考文献とされたい。
【００２５】
特別な取引上の機密保護を行うことができるデジタル署名を作成するために、ユーティリティ秘密鍵が使用される。通常、ユーティリティ証明書は、セキュアソケット層（ＳＳＬ）セッション（暗号化機能）をサポートするとともに、Ｓ／ＭＩＭＥ（セキュア／多目的インターネットメール拡張仕様）のメッセージに署名するために使用され、更に、その他のユーティリティアプリケーションのためにも使用される。また、証明書チェーンは、ユーティリティ鍵を使用してオペレーションをサポートする上でも必要となる。しかし、ユーティリティ証明書のステータスは、依頼者に公開されていない場合もある。本明細書の全体を通して、「証明書」という用語は、他に特記しない限り、身元証明書のことをいう。
【００２６】
好ましい実施形態において、加入顧客１０６のデジタル証明書及びこれに対応する秘密鍵は、発行参加者１０２によって加入顧客１０６に提供される。発行参加者１０２は、少なくとも加入顧客１０６の身元証明書に対応する秘密鍵を含むスマートカード又はその他の適切な証書を、加入顧客１０６に発行するのが好ましい。必要であれば、スマートカードは、加入顧客の身元証明書を含むこともできる。スマートカードの好ましい仕様、その製造元、及びそのコンテンツは、「署名インターフェース要件、スマートカード順守要件、保証サービス、機能要件、及び追加的開示」と題する２０００年８月１４日に出願された米国仮特許出願第  ／    号に記載されている。尚、この出願を本明細書の参考文献とされたい。
【００２７】
好ましい実施形態において、本システムは、少なくとも、ハイパーテキスト伝送プロトコル（ＨＴＴＰ）、多目的インターネットメール拡張仕様（ＭＩＭＥ）、シンプルメール伝送プロトコル（ＳＭＴＰ）、及びインターネットＯＲＢ間プロトコル等のインターネット伝送プロトコルをサポートするのが好ましい。更に、本システムは、少なくとも、セキュアソケット層（ＳＳＬ）、セキュア／多目的インターネットメール拡張仕様（Ｓ／ＭＩＭＥ）、トランスポート層セキュリティ（ＴＬＳ）、及びセキュアインターネットＯＲＢ間プロトコル（Ｓ−ＩＩＯＰ）等のインターネット伝送機密保護プロトコル
好ましい実施形態において、本システムにおける支払手段は、秘密の金融情報を保護するために暗号化される。全ての参加者間で交換される情報は機密性を有するものであるため、高度な暗号化が好ましい。好ましくは、この暗号化は、伝送レベルの暗号化に加えて、メッセージレベルの暗号化とすべきである。
【００２８】
自動処理を可能にするために、本システムにおける支払メッセージは、本システム及び本システムに外付けされる従来システムのような他のシステムによって提供される証明書管理サービス（例えば、証明書検証）による高速オンライン処理を最適化するように構成するのが好ましい。本システムに組み込むものとして、一連のＭＩＭＥベースのメッセージを含むことができる。他のシステムに組み込むものとして、ＥＤＩＦＡＣＴ、ＸＭＬ／ＢｉｚＴａｌｋ、及びＥｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（登録商標）  Ｂｅａｎｓを含むことができる。これらは、既存の支払メッセージフォーマットにそのまま変換可能であるという点で好ましい。
【００２９】
好ましくは、本システムの決済サービスメッセージは、それらの身元証明書に対応した秘密鍵を用いて各システム実体によって署名される。決済サービスメッセージは、証明書管理サービスメッセージのコンテンツに同封されるか又は参照される、或いは、同封且つ参照される。
【００３０】
以下で説明する支払メッセージの多くは、完成されたメッセージが最終受信者に送信される前に、２人以上の当事者による貢献を必要とする。従って、本システムにおけるメッセージは、各署名当事者及び最終受信者の否認防止機能を保持した状態で、原本のコンテンツに署名付きの追加を加えることをサポートするように構成されるのが好ましい。
まさに下位層側において、通常、買手１０６は、本システムに関係するアプリケーションをサポートするいくらかの方式に加えて、Ｎｅｔｓｃａｐｅ  Ｎａｖｉｇａｔｏｒ（商標）又はＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標）等の標準的インターネットブラウザを使用することができる。上記方式として、ブラウザプラグイン、ジャバアプレット方式等の技術を挙げることができる。拡張マークアップ言語（ＸＭＬ）等の技術オプションも使用することができる。
【００３１】
実施可能なものとして、買手１０６と売手１０８との間の取引条件に関する交渉結果の情報を持つ売手側サーバから、ＨＴＭＬページをブラウザ２２４にロードすることが考えられる。署名付きジャバアプレットをダウンロードしたＨＴＭＬページの一部として使用すれば、スマートカード２２６を使用して情報を構成するとともにデジタル署名することができる。次に、作成したメッセージは、更に処理するために、サーバに転送することができる。この代わりとして実施できる手法としては、決済サービスメッセージを構成し署名するプラグイン又はヘルパーアプリケーションを用いる方法がある。これらを実施するための好ましい実施形態は、「署名インターフェース要件、スマートカード順守要件、保証サービス、機能要件、及び追加的開示」と題する２０００年８月１４日に出願された米国仮特許出願第  ／    号に記載されている。尚、この出願を本明細書の参考文献とされたい。
【００３２】
この同期通信モデルに加え、買手１０６と売手１０８との間で情報交換する他のモデルもサポートすることができる。例えば、非同期電子メール交換も本システムでサポートできる。
典型的には、売手は、標準ＨＴＴＰウェブサーバ（例えば、Ａｐａｃｈｅ）を使ってＨＴＭＬページを呼び出し、アプリケーションサーバを作動して買手に特定の取引機能（例えば、ショッピングシステム）を提供する。例えば「証明書検証等のサービスのためのシステム及び方法」と題する本特許と同日に出願され審査中の米国特許出願第  ／    号に記載された検証及び保証サービスを含むシステムサービスの利用を促進にする他のソフトウェア構成要素が、このアプリケーションと統合される。尚、この出願を本明細書の参考文献とされたい。また、この出願には、決済サービスについても記載されている。
好ましい実施形態において、上記統合は、「証明書関連等のサービスに関する売手の利用を促進するためのシステム及び方法」と題する本件特許と同日に出願され審査過程の米国特許出願第  ／    号に記載された能動的統合である。尚、この出願を本明細書の参考文献とされたい。買手１０６に提示するための支払手段に関する売手１０８の決定を行ないそれにより購買条件を設定するのは、売手のアプリケーションの不可欠な役割である。
【００３３】
一例として、売手１０８のアプリケーションは、買手１０６の証明書を使って顧客を識別し、その顧客に特別の条件を適用することができる。更に、決済サービスの利用方法は、対象商品、及び、顧客の売手１０８との取引履歴に応じて変えることができる。例えば、特定上限を超える注文に関しては、売手１０８は、銀行が提供する保証付き支払債務を受け入れることのみに同意することかできる。これとは対照的に、特定閾値を下回る場合には、各支払要求を受け入れるよう決定することができる。更に、売手は、ダンアンドブラッドストリート社の評価サービスのような第三者サービスを利用して、特定の取引についてどの支払手段が受け入れ可能かを判断することもできる。
【００３４】
売手１０８側で実行しているアプリケーションは、例えば、「証明書関連等のサービスに関する売手の利用を促進するためのシステム及び方法」と題する本件特許と同日に出願され審査過程の米国特許出願第  ／    号に記載されたように、メッセージに署名するとともに、メッセージに付けられた署名を検証したり証明書のステータスを調査したりして、本明細書に述べられている決済サービスを提供するよう構成するのが好ましい。尚、この出願を本明細書の参考文献とされたい。
また、ウェブを基盤とした実施に加え、対サーバ通信又は自動電子メール処理ツールも売手側で使用することができる。
【００３５】
本システムにおける各参加者は、状況に応じて、信頼参加者になったり発行参加者になったりする。従って、例えば、第１の参加者の顧客が特定取引において買手となり、第２の参加者の顧客がその取引における売手となる場合には、第１参加者は、その取引に関して発行参加者となり、第２参加者は、その取引に関して信頼参加者となる。各参加者は、その顧客に対する認証局の機能を果たしたり（証明書の発行、更新、及び取消のサポート）、その顧客に検証サービス及び保証サービスを提供したり、他のシステム参加者からのＯＣＳＰ依頼に応答したり（証明書検証のサポート）、その顧客に対して決済サービス（例えば、本明細書で説明する決済サービス）を提供したりすることを含む数多くのサービスを提供するのが好ましい。
【００３６】
好ましい実施形態において、取引調整装置２０２は、参加者が提供する証明書に基づくサービスの主要インターフェースとなる。「証明書検証等のサービスのためのシステム及び方法」と題する本件特許と同日に出願され審査過程にある米国特許出願第  ／    号に記載されたように、取引調整装置２０２は、メッセージ確認、ロギング、請求書発送、及び証明書に基づく全てのサービスに関する認可等のシステム機能を円滑化する。尚、上記出願を本明細書の参考文献とされたい。
【００３７】
各顧客証明書は、発行参加者１０２及び信頼参加者１０４側にあるエンドユーザ認可システムに関連付けられるのが好ましい。認可システムの構成要素は、各参加者によって決定されるが、典型的には、取引形式に関する情報、額的上限、取扱手数料、各顧客証明書に許された承認を含む。好ましい認可手法は、「認可／認証認定サービス及び認可／認証認定サービス提案」と題する本件特許と同日に出願され審査過程にある米国特許出願第  ／    号に記載されている。尚、この出願を本明細書の参考文献とされたい。
【００３８】
各顧客証明書は、買手銀行１０２及び売手銀行１０４側にある決済テンプレートシステムに関連付けられるのが好ましい。決済テンプレートには、買手１０６、売手１０８、及び、売手銀行１０４のためのディフォルト形式の支払指図書を記憶しており、決済認可メッセージを実行するために買手銀行１０２によって使用される。決済認可メッセージの設計によって、その指図の一部を、正式に認可された買手又は売手エンドユーザが優先させることが可能となる。
好ましい実施形態において、各銀行は、自由裁量により、それぞれの顧客に付加的機能を提供することができる。この付加的機能としては、買手企業に対する上限の運用、又は、特定顧客による決済サービス利用に関する一括管理情報の提供等を挙げることができる。
【００３９】
好ましい実施形態において、本明細書に開示した決済サービスでは、実際の支払のために既存の銀行ネットワークが使用される。それら銀行ネットワークは、将来の期限付き支払のための支払入庫システムのような銀行で利用可能な既存機能を使用することもできる。これら既存システムへの接続の一部は、リアルタイムでオンラインであるのが好ましい。これらシステムには、支払要求を作成し、保管し、発信するための支払開始システムに対するリアルタイムでオンラインのインターフェース、昼間及び夜間の上限を監視する支払リスクシステムに対するリアルタイムでオンラインのインターフェース、支払開始受領を発生するためのリアルタイムでオンラインの構成要素、デジタル署名及び身元保証を処理するシステム身元サーバに対するリアルタイムでオンラインのインターフェース、アプリケーション認可システムに対するリアルタイムでオンラインのインターフェース、及び、買手銀行１０２が支払要求を受け取る前に、買手１０６が送った支払要求取消依頼の倉庫（支払取消リスト）に対するリアルタイムでオンラインのインターフェースが含まれる。
【００４０】
決済手段及びシナリオ
本システムによって提供される決済手段には、支払要求、支払債務、保証付き支払債務と、条件付き支払が含まれる。各決済手段の簡単な説明をこれまでに行ったが、以下、各々の決済手段についてより詳細に説明する。
【００４１】
支払要求
支払要求（ＰＯｒ）は、買手１０６が、売手１０８に対する特定金額の信用支払を特定日に開始するよう、買手銀行１０２に依頼する取消可能で無条件の電子的指図である。支払要求は、普通買手と売手との取引関係が確立されている場合に使用される。
【００４２】
支払債務及び保証付き支払債務
支払債務（ＰＯｂ）は、買手銀行１０２で特定日に特定金額を、債券を持つ売手１０８即ち債券の所有者に支払うという、買手１０６の取消不能な無条件の約束である。それは売手に対する買手の負債の証拠となる。買手１０６は、買手銀行１０２に対し、売手１０８に支払債務を引き受ける即ち保証するよう依頼することができる。この場合、支払債務は、保証付き支払債務（Ｃｅｒｔｉｆｉｅｄ  ＰＯｂ）となる。
通常、保証付き支払債務は、期日通りに支払うという買手１０６の意図に、売手１０８が確信を持てない場合に使用される。
【００４３】
条件付き支払
条件付き支払は、予め合意された条件を満たしていることを証明する特定当事者間で署名された特定の電子メッセージが買手銀行１０２に示された時に買手銀行１０２で支払可能な、特定の売手に有利な支払要求又は支払債務である。買手１０６は、売手１０８に支払債務を引き受ける即ち保証することを買手銀行１０２に依頼することができるが、この場合、この支払手段は、保証された条件付き支払債務（Ｃｅｒｔｉｆｉｅｄ  ＣＰＯｂ）となる。
条件付き支払は、買手１０６又は売手１０８の一方、又はそれら双方が、特定の規定が満たされて初めてその支払が行なわれると合意した場合に使用される。
条件付き支払は、支払のタイミング及び発生を引き起こすために使用される。保証された条件付き支払債務には、指定の規定が満たされるとその支払が行なわれるという保証が付加される。
【００４４】
決済のシナリオ及びモデル
好ましい実施形態において、買手１０６は、様々な商業的及び金融的シナリオを想定して、支払要求及び支払債務の使用を考えることができる。これは商業取引又は金融取引のほとんどの段階で両当事者を識別する図２のシステム２００の能力によるものであって、これにより、買手が支払を考える際に大きな自由度を提供する。後述するシナリオはこの柔軟性を例示している。
【００４５】
売手の決済サーバを介したオンライン決済の開始
第１の決済シナリオにおいて、売手１０８の決済サーバは、買手１０６に対して支払要求又は支払債務の選択肢を用意する。図３に示すように、この第１シナリオでは、買手１０６は、支払要求又は支払債務の指図書を作成して、この指図書を、売手銀行１０４を介して買手銀行１０２に転送することを売手１０８に許可する。買手１０６及び売手１０８、場合によっては売手銀行１０４も、決済を開始する即ちその債券を作成する上で必要な情報を交換する。好ましい実施形態においては、買手銀行１０２は、４コーナー取引モデルを用いて、買手１０６の署名に基づいて決済を開始する即ち支払債券を作成する。
【００４６】
売手決済サーバを介してのオンライン口座引落し認可
第２の支払シナリオにおいて、売手１０８の決済サーバは、図４に示すように、口座振替（ｄｉｒｅｃｔ  ｄｅｂｉｔ）の選択肢を買手１０６に用意する。図４に示すように、この第２シナリオでは、買手１０６は売手１０８に対し、買手１０６の口座からの自動引落しの指図書を売手銀行１０４に転送することを許可する。好ましい実施形態において、買手１０６及び売手１０８は、決済を開始する上で必要な情報を交換する。売手銀行１０４は、売手１０８の署名に基づいて口座振替手続きを開始する。これは口座振替取引モデルと呼ばれる。買手１０６と売手１０８とが異なる国で事業運営されている場合には、このシナリオは成り立たないということに留意されたい。
【００４７】
買手の決済サーバを介しての決済の開始
第３の支払シナリオにおいて、図５に示すように、買手１０６の決済サーバが、買手銀行１０２に、直接、支払要求又は支払債務の指図書を送る。図５に示すように、この第３支払シナリオでは、買手１０６は、決済の開始即ち債券作成に必要な情報を与える。買手銀行１０２は、買手１０６の署名に基づいて決済を開始する即ち債券を作成する。これは、買手対買手銀行取引モデルと呼ばれる。
【００４８】
システム実体間の法的関係
好ましい実施形態においては、銀行とその顧客とは、契約合意によって法的に拘束される。特に、システムサービスの利用方法は、一連の運用規則、及び、後でより詳細に説明するような、各システム実体を法的に拘束するこれら規則に基づいて作成された１つ又はそれ以上の契約によって規定するのが好ましい。
好ましい実施形態においては、本明細書に開示された決済サービスの運用手順及び規則によって、参加者の権利及び義務が規定される。これら規則を作成する際、（諸外国の管轄下のものも含む）様々な電子決済共同体の規則を指針として活用することができる。更に、それらの共同体規約によって、新しい規則に特定の要件を強いる可能性もある。例えば、取引の取消及び決済の終結の問題に関する共同体規則には特に注意するのが好ましい。
【００４９】
その代わりに、支払要求又は支払債務を既存の決済規則と調和できない場合、又は、オンライン決済開始の特殊性を考慮してこのような規則を（それらの既存の枠組み範囲外で）補足する必要がある場合には、取引の様々な関係者を、ルート実体１１０によって課せられる他の一連の規則により拘束することができる。
好ましい実施形態においては、本システムのための運用規則は、国際商工会議所（ＩＣＣ）によって承認されると、電子通商及び決済に関する統一規則（ＵＲＥＴＳ）に組み込まれる。
【００５０】
好ましい実施形態においては、本システムにおける支払債務及び保証付き支払債務の全ては、帳簿記入形式で作成され記録される。為替手形の場合のように、支払債券及び保証付き支払債券は、流通市場で売却できるのが好ましい。これら債券の所有者の変更は、所有者登録サービスにより行うことができるのが好ましい。買手銀行１０２は、正確な債券所有者を登録する責任を持つようにするのが好ましい。
【００５１】
好ましい実施形態において、決済サービスが利用される前に、買手１０６及び売手１０８の各々は、自身の参加者１０２、１０４との関係を確立しておくのが好ましい。このため、好ましい実施形態においては次のような段階が含まれる。
−各顧客及びそれぞれの参加者は、決済サービスに関する各自の役割及び義務を規定した契約を結ぶ。この契約は、通常、それぞれの顧客と銀行との関係以外の側面を対象とする両当事者間の他の契約とは別のものである。契約の締結によって、顧客は決済サービスの運用規則を受諾する。
−各参加者の各々は、自身の顧客のために決済サービスを設定する。この設定には、多くの銀行部門に関連する与信監査プロセスを必要とされる可能性がある。決済保証口座の設定には、時間もかかるであろうし、両当事者間の既存の信用関係にも関係するであろう。また、決済サービスの設定には、好ましくは、決済サービスの利用を許可され、顧客との一連の信用を確立する従業員の登録も含まれる。更に、買手１０６のための標準清算指図書（例えば、通貨に応じた引落し口座、利用する決済システム）の設定を含むのが好ましい。加えて、各銀行は、顧客に提供する特定のサービスに応じた付加な設定手続きも必要となるであろう。
【００５２】
好ましい実施形態において、各システム実体間における紛争の解決は、参考のために本明細書に組み込まれた、「証明に関するサービス及びその他のサービスを提供するためのシステム及び方法」と題する２０００年２月１１日に出願され審査過程にある米国特許出願第０９／５０２，４５０号に記載されている。尚、この出願を本明細書の参考文献とされたい。
【００５３】
決済サービスプロダクトの概要
好ましい実施形態において、本システムにおける支払債務、又は、取消可能性、及び荷為替条件との組合せによって、対事業所電子商取引の信用・リスク管理ニーズに適合する様々な支払手段を提供するいくつかの手段形式が作り出される。これら手段の形式を下表に要約する。
表１
2011118898.tif 000003
【００５４】
好ましい実施形態では、支払要求によって、買手及び売手は、自動オンライン決済を開始しワールドワイドウェブを介して電子商取引を行うことができる。
支払要求は、信用状又は支払伝票とすることができる。支払伝票は、買手１０６が作成しても(よって、買手の発行した認可証書となる)、（買手の認可なしに、売手１０８が作成した）代金取立書（注：これは全ての国で許されるものではない）とすることも可能である。
【００５５】
買手銀行１０２が売手１０８に支払う義務を負う信用度の高い決済サービスには、保証付き支払債務を含むことができる。保証付き支払債務は、購入商品についての売手１０８に対する支払を買手銀行１０２が無条件で保証するものであることが好ましい。
好ましい実施形態において、条件付き支払要求は、売手１０８が取引対象の品物を出荷したことを証明する、売手１０８からの文書を受け取るまで、買手銀行１０２が支払を求めないという点を除けば、上記の支払要求と同様である。保証付きで条件付きの支払債務は、契約義務の実行を証明するために、売手１０８又は第三者が荷為替信用状に指定された文書を買手銀行１０２に提出することを条件に、売手１０８への支払を買手銀行１０２が保証するものとするのが好ましい。
【００５６】
本システム及び方法は、上記の認定された支払手段を実施するために、複数の依頼メッセージ及び応答メッセージを用いる。これらは、概ね以下のものを含む。
表２
１）依頼メッセージ
2011118898.tif 000004
【００５７】
表３
２）応答メッセージ
2011118898.tif 000005
【００５８】
上記メッセージの分類は一般的なものであって、これらメッセージ及びその他の関連メッセージのより具体的な分類及び機能内容は、本発明のシステムが具体的にどのように実施されるかによって変えることができる点に注目されたい。拡張可能なマークアップ言語（ＸＭＬ）を使用するシステムメッセージの好ましい実施については、後に詳しく説明する。
【００５９】
好ましい実施形態において、各メッセージは、各署名当事者及び最終受信者の否認防止機能を保持した状態で、原本のコンテンツ及び添付書類に署名付きの追加（これには、各追加に対する１つ又はそれ以上の署名／証明書が含まれる）を付加することをサポートするように構成される。更に、好ましい実施形態において、システムは、以下の要件を厳守する。
１．各依頼メッセージは、対象とする最終当事者によって受け取られた時、サービス受領（Ｓｒｖ  Ａｃｋ）メッセージを返信する。
２．金融機関が支払を実行する時、その金融機関は、この行為についての確認メッセージ（Ｐａｙ  Ｃｏｎｆ）を適切な当事者に送る。
３．金融機関が支払債務指図書を受け取った時、その金融機関は、その債務が履行されるか否かを示すメッセージの発信者に、確認メッセージ（ＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）を送る。保証付きであることを依頼された支払債務メッセージに応答して、ＣｅＰＯｂ  Ａｃｐｔ  Ｃｏｎｆメッセージが送られるのが好ましい。
４．金融機関が支払要求取消メッセージ（ＰＯｒ  Ｃｎｃｌ）を受け取った時、その金融機関は、この取消が受諾されたか拒否されたかを確認するメッセージ（ＰＯｒ  Ｃｎｃｌ  Ｃｏｎｆ）で応答する。
５．第三者のサービス提供者（ＴＰＳＰ）実体が条件通知メッセージ（Ｃｎｄ  Ａｄｖ）を受け取った時、条件が満足される場合又はこの条件は満足される可能性がないと確信した場合には、その第三者のサービス提供者実体は、条件告知メッセージ（Ｃｎｄ  Ｄｅｃｌ）で応答する。
６．支払指図メッセージには、買手１０６組織の複数の当事者が署名できる。
７．全ての支払メッセージには、信頼当事者の各々が署名する。
８．買手１０６及び売手１０８は、（買手及び売手の銀行が同一である場合、即ち４コーナー取引ではなく３コーナー取引の場合を除き）、銀行の証明書を用いて、支払メッセージにおいて自身の身元を識別する。
【００６０】
各システムメッセージのコンテンツを説明する表を以下に示す。各表において、第１欄は、メッセージ部分の名称を識別し、第２欄は、好ましい実施形態において、そのメッセージ部分が義務的なものか選択的なものかそれとも条件的なものか（即ち、状況によってはそれが義務的なものになるか否か）を特定し、第３欄は、そのメッセージ部分のコンテンツを提供する実体を識別し、更に、第４欄には、そのメッセージ部分に関する付加的コメントが記載されている。
【００６１】
好ましい実施形態においては、支払要求指図書は、下記のデータを含む。
表４
2011118898.tif 000006
2011118898.tif 000007
【００６２】
好ましい実施形態においては、支払債務指図書は、下表に挙げた変更を除き支払要求指図書の上記表に挙げたデータを含む。
表５
2011118898.tif 000008
【００６３】
好ましい実施形態において、保証付き支払債務指図書は、支払要求指図書の上記表に挙げたものと同じデータを含む。
好ましい実施形態において、（１）条件付き支払要求指図書は、下表に挙げた変更を除き、支払要求指図書の上記データを含み、（２）条件付き支払債務指図書は、下表に挙げた変更を除き、支払債務指図書の上記データを含み、（３）保証付き／条件付き支払債務指図書は、下表に挙げた変更を除き、保証付き支払債務指図書の上記データを含む。
表６
2011118898.tif 000009
【００６４】
好ましい実施形態において、支払条件は、条件テンプレート群から選択される。更に、各条件は、真偽を明白に確認できるよう構成するのが好ましい。
好ましい実施形態において、ＴＰＳＰは、これら条件下で必要とされてもされなくてもよい情報提供を目的とし、確認メッセージに追加される購入品詳細又は電子文書／ファイルを添付又は付け加えることができる。
好ましい実施形態において、支払要求取消メッセージ（ＰＯｒ  Ｃｎｃｌ）には、買手１０６組織の複数当事者が署名することができる。
【００６５】
好ましい実施形態において、支払要求取消メッセージは、下記データを含む。
表７
2011118898.tif 000010
【００６６】
好ましい実施形態において、条件通知（Ｃｎｄ  Ａｄｖ）メッセージは、信頼できるサービス提供（ＴＳＳ）組織から送られるが、買手銀行１０２は、この組織としての役割を果たすことができる。これらメッセージは、決済実行を円滑化する上で満足しなくてはならない条件を設定するために使用される。好ましい実施形態において、全ての条件通知メッセージ（Ｃｎｄ  Ａｄｖ）は、ＴＰＳＰに送られ、このメッセージに応答してＴＰＳＰがサービス受領（Ｓｒｖ  Ａｃｋ）メッセージを送る。好ましい実施形態において、条件通知メッセージは、以下のデータを含む。
表８
2011118898.tif 000011
【００６７】
好ましい実施形態においては、各当事者は、ステータス照会メッセージを使用して、支払開始システムの他の関係者から特定の取引に関する情報を入手する。
好ましい実施形態においては、どの形式の依頼メッセージを受け取った時でも応答メッセージが作成される。各応答メッセージは、受け取った依頼メッセージに対して肯定的応答が返信されるのか否定的な応答が返信されるのかを示すのが好ましい。
好ましい実施形態においては、すべての依頼メッセージに応答してサービス受領（Ｓｒｖ  Ａｃｋ）メッセージが送られる。好ましくは、下記メッセージの全ては、サービス受領（Ｓｒｖ  Ａｃｋ）メッセージで応答される。
−ＰＯｒ  Ｉｎｓｔ（支払要求指図）
−ＰＯｂ  Ｉｎｓｔ（支払債務指図）
−ＣＰＯｒ  Ｉｎｓｔ（条件付き支払要求指図）
−ＣＰＯｂ  Ｉｎｓｔ（条件付き支払債務指図）
−ＣｅＰＯｂ  Ｉｎｓｔ（保証付き支払債務指図）
−ＣｅＣＰＯｂ  Ｉｎｓｔ（保証付き／条件付き支払債務指図）
−ＰＯｒ  Ｃｎｃｌ（支払要求の取消）
−Ｃｎｄ  Ａｄｖ（条件通知）
−Ｃｎｄ  Ｕｐｄａｔｅ（条件通知メッセージに応答した中間更新）
−Ｃｎｄ  Ｄｅｃｌ（条件通知メッセージに応答した条件告知）
【００６８】
好ましい実施形態においては、対象とする最終受信者によってメッセージに含まれた構文、署名、証明書、及びユーザー許可が検証された時、サービス受領（Ｓｒｖ  Ａｃｋ）メッセージが送られる。この対象最終受信者は、決済シナリオの機能に応じて変えることができる。例えば、４コーナーモデルにおいて、支払要求／支払債務依頼メッセージの対象最終受信者は、買手銀行１０２である。これに対して、口座振替モデルにおいては、支払要求／支払債務依頼メッセージの対象最終受信者は、売手銀行１０４となる。好ましい実施形態においては、支払指図メッセージの対象最終受信者によって受け取られてから１分以内に、受け取られた支払指図メッセージに応答して、サービス受領（Ｓｒｖ  Ａｃｋ）メッセージが送られる。
【００６９】
好ましい実施形態においては、サービス受領（Ｓｒｖ  Ａｃｋ）メッセージは、下表に記されたデータを含む。
表９
2011118898.tif 000012
【００７０】
好ましい実施形態においては、対象とする最終受信者ではない実体がサービス受領（Ｓｒｖ  Ａｃｋ）メッセージを受け取ると、如何なる場合でも、その実体は、この情報を同封し、このサービス受領（Ｓｒｖ  Ａｃｋ）情報を添付して該メッセージを対象最終受信者に回送する。例えば、４コーナーモデルで運用される場合、売手銀行１０４が買手銀行１０２からサービス受領（Ｓｒｖ  Ａｃｋ）メッセージを受け取った場合には、売手銀行１０４は、このサービス受領（Ｓｒｖ  Ａｃｋ）メッセージをその売手１０８に回送する。
【００７１】
好ましい実施形態においては、このサービス受領（Ｓｒｖ  Ａｃｋ）メッセージは、表９に挙げたデータ及び下表に挙げたデータを含む。
表１０
2011118898.tif 000013
【００７２】
好ましい実施形態においては、金融機関が関連する支払指図書に指定された支払方法の実行を完了した時、支払実行確認（Ｐａｙ  Ｃｏｎｆ）メッセージが送られる。支払実行確認（Ｐａｙ  Ｃｏｎｆ）メッセージは、翌日の営業日最終時刻までに適切な受信者に送られるのが好ましい。好ましくは、この支払実行確認（Ｐａｙ  Ｃｏｎｆ）メッセージは次のデータを含む。
表１１
2011118898.tif 000014
【００７３】
好ましい実施形態においては、実体が支払実行確認（Ｐａｙ  Ｃｏｎｆ）メッセージを受け取った時、その実体は、この情報を同封し、その支払実行確認（Ｐａｙ  Ｃｏｎｆ）情報を添付したメッセージを対象とする最終受信者に回送する。例えば、４コーナーモデルで運用される場合、売手銀行１０４が買手銀行１０２から支払実行確認（Ｐａｙ  Ｃｏｎｆ）を受け取った時、売手銀行１０４は、この支払実行確認（Ｐａｙ  Ｃｏｎｆ）メッセージをその売手１０８に回送する。
好ましい実施形態においては、この支払実行確認（Ｐａｙ  Ｃｏｎｆ）メッセージは表１１に挙げたデータ及び以下のデータを含む。
表１２
2011118898.tif 000015
【００７４】
好ましい実施形態においては、翌日の就業日最終時刻までに、支払債務依頼メッセージに応答して支払債務受諾確認（ＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）メッセージが送られる。好ましくは、支払債務受諾確認（ＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）メッセージは以下に挙げるデータを含む。
表１３
2011118898.tif 000016
【００７５】
好ましい実施形態においては、対象となる最終受信者ではない実体が支払債務受諾確認（ＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）メッセージを受け取った時、その実体は、この情報を同封し、その支払債務受諾確認（ＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）情報を添付したメッセージを対象最終受信者に回送する。例えば、４コーナーモデルで運用される場合、売手銀行１０４が買手銀行１０２から支払債務受諾確認（ＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）を受け取った時、売手銀行１０４は、この支払債務受諾確認（ＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）をその売手１０８に回送する。好ましくは、この支払債務受諾確認（ＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）メッセージは、上記表１３に挙げたデータ及び以下のデータを含む。
表１４
2011118898.tif 000017
【００７６】
好ましい実施形態においては、翌日の就業日最終時刻までに、保証付き支払債務依頼メッセージに応答して、保証付き支払債務受諾確認（ＣｅＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）メッセージが送られる。好ましくは、保証付き支払債務受諾確認（ＣｅＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ）メッセージは、表１３のデータを含む。
【００７７】
好ましい実施形態においては、翌日の就業日最終時刻までに、支払要求取消指図メッセージ（ＰＯｒ  Ｃｎｃｌ  Ｃｏｎｆ）に応答して、支払要求取消確認（ＰＯｒ  Ｃｎｃｌ  Ｃｏｎｆ）メッセージが送られる。好ましくは、支払要求取消確認（ＰＯｒ  Ｃｎｃｌ  Ｃｏｎｆ）メッセージは以下のデータを含む。
表１５
2011118898.tif 000018
【００７８】
好ましい実施形態においては、条件通知メッセージに関連して条件更新（Ｃｎｄ  Ｕｐｄａｔｅ）メッセージが送られる。これらのメッセージは、条件通知メッセージによって指定された条件を満足する形で行われた進捗状況の更新情報を提供するために、好ましくはＴＰＳＰ関係者から送られる。
好ましい実施形態においては、ＴＰＳＰ関係者による条件通知メッセージに応答して、条件告知（Ｃｎｄ  Ｄｅｃｌ）メッセージが送られる。好ましくは、条件告知（Ｃｎｄ  Ｄｅｃｌ）メッセージは、条件通知（Ｃｎｄ  Ａｄｖ）メッセージの原本に概要が示された条件が満足された場合、又は、この条件が満足される可能性がない場合に送られる。例えば、ある商品が指定期日までに出荷されるというのが条件であったが、その商品が発送されないままこの指定期日が過ぎてしまったという状況であれば、否定的応答が送られる。
【００７９】
好ましくは、条件告知（Ｃｎｄ  Ｄｅｃｌ）メッセージは以下のデータを含む。
表１６
2011118898.tif 000019
2011118898.tif 000020
【００８０】
好ましい実施形態においては、ステータス照会応答メッセージ（Ｓｔｓ  Ｉｎｑ  Ｒｅｓｐ）は、ステータス照会依頼で指定された取引の履歴を含む。
【００８１】
通信プロトコル
好ましい実施形態においては、以下のプロトコル及びフォーマットが、署名して署名データをフォーマットする際に使用される。
１．ＸＭＬＤＳｉｇ（ＸＭＬ−署名構文及び処理）−取引調整装置や商人の署名及びフォーマット化のために使用される
２．ＰＫＣＳ＃７−データ要素のブラウザを基盤とした記入のために使用される
３．Ｓ／ＭＩＭＥｖ３（セキュア／多目的インターネットメール拡張バージョン３）−当事者間の非同期通信のために使用される
４．ＳＳＬｖ３（セキュアソケット層バージョン３．０）又はＴＬＳｖ１．０（トランスポート層機密保護バージョン１．０）−同期メッセージのために使用される
【００８２】
特に、好ましくは、以下の規則は、本発明のシステム及び方法を使用した取引における支払当事者間で交信したり署名したりするためのフォーマットを規定する。
−全ての同期交信は、後述するシステム規則に従って、ＨＴＴＰによる安全なＳＳＬｖ３．０又はＴＬＳｖ１．０インターネット機密保護プロトコルを使用して行うのが好ましい。
−エンドユーザは、受諾されたフォーマットで署名することのできるブラウザ及びメールクライアントよりも高度なシステムは持たなくてよい。例えば、受諾のために買手１０６及びＴＰＳＰに送られる文書は、この範疇に入る。このブラウザは、ＰＫＣＳ＃７で包装されたメッセージを提供すると考えられる。ＰＫＣＳ＃７は、デジタル署名のような暗号化することができるデータのための一般的構文を記述した暗号メッセージ構文標準である。買手１０６が署名するデータは、後述するように適切なブロックで表される。
−好ましくは、後述する標準システムＸＭＬメッセージングは、当事者間で通信するために使用されるため、売手１０８、売手銀行１０４、及び、買手銀行１０２は、このようなメッセージを作成したり受信したりすることができる必要がある。
−また、買手１０６及びＴＰＳＰが、本発明のシステムメッセージングをサポートするサーバを基盤とするシステムを有する場合、各銀行又は各参加者は、それら組織をサポートするために、後述するＸＭＬ  ＤＴＤを使用することができる。
−好ましくは、全ての受領は、Ｓ／ＭＩＭＥｖ３プロトコルを使用して暗号化される。この受領が、未知のサーバにサポートされて買手又はＴＰＳＰに送られている場合、署名は、Ｓ／ＭＩＭＥｖ３標準の部分であり、後述するＸＭＬＤＳｉｇ署名ではない。
−選択的に、実施を容易にするために、各買手及び各ＴＰＳＰとの全ての非同期通信は、Ｓ／ＭＩＭＥ標準の部分として非同期通信を行なう金融機関の署名付きＳ／ＭＩＭＥｖ３メッセージとして送ることができる。
−しかし、非同期通信は、包装され、好ましくは、後述するＮＩＢ(ネットワーク情報ブロック)アプリケーションブロック及びＸＭＬメッセージングからの応答を含むが、ＣｅｒｔＢｕｎｄｌｅ即ち非同期包装構造内で複製されている各署名ブロックは必ずしも含まない。
−システム応答メッセージは、ＴＰＳＰ対ＴＳＳの通信のために設定されるが、各ＴＰＳＰは、ウェブインターフェースを介して条件を解除することができる。後者の場合には、ＴＰＳＰは、条件を解除するために、ＰＫＣＳ＃７署名を使用してメッセージに署名することになる。
【００８３】
データ形式の定義
好ましい実施形態において、技術的実施及び統合による選択肢を制限しないために、システムメッセージは、常に適切な対応データ形式の定義を持つ拡張可能なマークアップ言語（ＸＭＬ）を使用して構成される。以下、いくつかのデータ形式定義（ＤＴＤ）の好ましい実施形態について説明する。
【００８４】
このシステムでは、全ての支払固有メッセージが、支払メッセージとして一意に識別可能であること、及び、メッセージ識別子（タグ）が曖昧さのない形で定義されることが必要である。ＸＭＬ文書により、本発明のシステムは、ＸＭＬネームスペースを使用してこれらの要件を満たすのが好ましい。ＸＭＬネームスペースは、ＸＭＬ文書に使用される要素名称及び各属性名称を、ＵＲＩ（統一的資源識別子）参照符によって識別されるネームスペースと関係付けることによって、それら要素名称及び各属性名称を特定する簡易な手段を提供する。各トップレベルのＸＭＬ支払文書においては、各データ要素が発生するＸＭＬネームスペースが明示される。例えば、ＸＭＬ文書には、表１７に記載したようなネームスペースが参照符として付けられる。
【００８５】
表１７
2011118898.tif 000021
【００８６】
支払請求書のＤＴＤ
好ましい実施形態において、支払請求書のＤＴＤのコンテンツを以下の表１８に示す（また、支払請求書のＤＴＤは、後述する、「条件群」や「証明書ステータス調査」等の特定のＤＴＤをインポートしてもよい）。
表１８
2011118898.tif 000022
【００８７】
本システムでは、「Ｍｓｇｇｒｐｉｄ」及びＮＩＢ（ネットワーク情報ブロック）の「ＭｓｇＩＤ」属性が特定され、この値を取引のメッセージ毎に一意に特定することが要求される。Ｍｓｇｇｒｐｉｄは、一回の交信における全ての文書に共通な一意の識別子（ＩＤ）である。多数の交信を、１つの支払取引に関連させることができる点に注目されたい。各々の交信（例えば、支払請求−サービス受領の交信、又は、取消依頼−サービス受領の交信）では、Ｍｓｇｇｒｐｉｄは同一のものとなる。非同期通信は、小さな交信として処理されことになる。Ｍｓｇｉｄは、交信における文書毎のシーケンシャルカウンタとして使用される。しかし、交信が複雑になると、ＭｓｇｇｒｐｉｄとＭｓｇｉｄとの組合せによって確実に交信中の文書を一意に識別できるようにするため、発信者のロールは、連番を付けて使用されるのが好ましい。
【００８８】
Ｍｓｇｉｄの好ましい構造は、「ｘｘ：ｎｎ」であって、ここで、ｘｘは、ロール識別子、ｎｎは、現在の交信におけるそのロールによって送られた文書の連番である。取引調整装置がシステム支払メッセージを識別できるようにするために、ＨＴＴＰコンテンツ形式かどうかを適切に特定する必要がある。
上記システム支払依頼文書は、前述し表２に挙げた支払指図メッセージ、即ちＰＯｒ  Ｉｎｓｔ、ＰＯｂ  Ｉｎｓｔ、ＣＰＯｒ  Ｉｎｓｔ、ＣＰＯｂ  Ｉｎｓｔ、ＣｅＰＯＢ  Ｉｎｓｔ、及びＣｅＣＰＯｂ  Ｉｎｓｔ、を特定するために使用することができる。好ましい実施形態におけるシステム支払依頼のＤＴＤを表１９に示す。
【００８９】
表１９
2011118898.tif 000023
【００９０】
上記システムヘッダーは、全ての取引に対する一意の取引参照符を提供し、プロダクト属性により、特定の支払プロダクト指図メッセージを特定できるようにする。このヘッダーは、全てのメッセージに共通の構成要素であって、好ましい実施形態においては以下の属性（表２０）を含む。
表２０
2011118898.tif 000024
【００９１】
好ましい実施形態においては、以下の表２１の検証規則は、システムヘッダーの属性に適用される。
表２１
2011118898.tif 000025
【００９２】
システム支払依頼（ＳｙｓｔｅｍＰａｙＲｅｑｕｅｓｔ）ＤＴＤの買手署名データ（ＢｕｙｅｒＳｉｇｎｅｄＤａｔａ）ＤＴＤは、好ましい実施形態においては、以下のデータブロック（表２２）を含む。
表２２
2011118898.tif 000026
【００９３】
上記交渉データブロックは、取引の過程で交渉されたデータ要素を搬送し、好ましくは以下の属性（表２３）を有する。
表２３
2011118898.tif 000027
【００９４】
以下の表２４の検証規則は、交渉日の属性に適用される。
表２４
2011118898.tif 000028
2011118898.tif 000029
【００９５】
（買手署名データＤＴＤの）買手データブロックは、取引過程で買手１０６によって提供される情報を含み、取引過程で交渉されたデータ要素を搬送する。好ましくは、買手データブロックは、（例えば、接触（ｃｏｎｔａｃｔ）サブブロック内に）その取引に関するあらゆる課題の詳細を提供する接触データを含む。買手データブロックは、好ましい実施形態においては、以下の属性（表２５）を有する。
表２５
2011118898.tif 000030
【００９６】
以下の表２６の検証規則は、買手データの属性に適用される。
表２６
2011118898.tif 000031
【００９７】
（買手署名データＤＴＤの）売手公開データブロックは、取引において売手１０８によって提供された情報を含み、好ましくは、その取引に関して生じたあらゆる課題についての接触の詳細も含む。売手公開データブロックは、好ましい実施形態においては、以下の表２７に挙げた属性を有する。
表２７
2011118898.tif 000032
2011118898.tif 000033
【００９８】
以下の表２８の検証規則は、好ましくは、売手公開データの属性に適用される。
表２８
2011118898.tif 000034
【００９９】
（買手署名データ（ＢｕｙｅｒＳｉｇｎｅｄＤａｔａ）ＤＴＤにおける）債務ブロックは、取引の結果生じるあらゆる債務の詳細を含む。債務が引き受けられる予定のない場合、そのブロックは、債務形式が「ＮＯＮＥ」に設定されるという点に留意されたい。債務ブロックは、好ましい実施形態においては、以下の属性を有する（表２９）。
表２９
2011118898.tif 000035
【０１００】
以下の検証規則は、好ましくは、債務ブロックの属性に適用される（表３０）。
表３０
2011118898.tif 000036
【０１０１】
（買手署名データＤＴＤの）条件群ブロックは、支払に関連する諸条件の記述を含む（このブロックは、前述し表２に挙げた条件通知依頼メッセージに対応する）。条件群ブロックは、インポートされた要素であって、別途説明するように、このシステムにおける多くの支払ブロックにおいて使用される。
（買手署名データＤＴＤの）買手署名詳細ブロックには、買手組織の関係者によって作成される署名が含まれる。承認サイクルでは、後でより詳細に説明するように、どの指図書に対しても多くの署名を求めることができる。よって、買手署名詳細ブロックを、複数の買手署名詳細ブロックとすることが可能である。買手署名詳細ブロックは、以下の表３１のように、買手１０６によって作成された署名に関する情報を含むのが好ましい。
【０１０２】
表３１
2011118898.tif 000037
【０１０３】
下記の検証規則は、好ましくは、買手署名詳細の属性に適用される（表３２）。
表３２
2011118898.tif 000038
【０１０４】
システム支払請求ＤＴＤは、買手組織の関係者によって作成された署名を入れた買手署名ブロックも含む。承認サイクルでは、どの指図書に対しても多くの署名を求めることができる。好ましい実施形態において、買手署名ブロックは、以下の表３３のブロックを含む。
表３３
2011118898.tif 000039
【０１０５】
以下の表３４の検証規則は、好ましくは、買手署名ブロックに適用される。
表３４
2011118898.tif 000040
【０１０６】
買手署名ブロックは、好ましくは、以下の表３５の属性も含む。
表３５
2011118898.tif 000041
【０１０７】
好ましい実施形態において、表３６の検証規則は、連番の属性に適用される。
表３６
2011118898.tif 000042
【０１０８】
システム支払請求ＤＴＤの売手私的データブロックは、売手１０８から売手銀行１０４に送られる私的データを含む。売手私的データブロックは、売手銀行１０４によって除去され、買手銀行１０２に送られるデータブロックには含まれない。好ましい実施形態において、売手私的データブロックは、以下の属性（表３７）を含む。
【０１０９】
表３７
2011118898.tif 000043
【０１１０】
以下の表３８の検証規則は、売手私的データの属性に適用される。
表３８
2011118898.tif 000044
【０１１１】
システム支払請求ＤＴＤの売手銀行データブロックは、取引において売手銀行１０４から買手銀行１０２に情報を搬送する。売手銀行１０４は、必要に応じ、（後述する）接触ブロックの関連接触詳細を提供することができる。好ましい実施形態において、売手銀行データブロックは、表３９の属性を含む。
表３９
2011118898.tif 000045
【０１１２】
以下の検証規則(表４０)は、好ましくは、売手銀行データの属性に適用される。
表４０
2011118898.tif 000046
【０１１３】
支払応答
好ましい実施形態における支払応答（ＰａｙｍｅｎｔＲｅｓｐｏｎｓｅ）ＤＴＤのコンテンツを、以下の表４１に示す（支払応答ＤＴＤは、証明書ステータス調査及び接触要素等の特定ＤＴＤをインポートすることもできる）。
表４１
2011118898.tif 000047
【０１１４】
好ましい実施形態におけるシステム支払応答（ＳｙｓｔｅｍＰａｙＲｅｓｐｏｎｓｅ）ＤＴＤを、以下の表４２に示す。
表４２
2011118898.tif 000048
【０１１５】
前述したように、システムヘッダーは、全ての取引に対して一意の取引参照符を提供し、且つ、全てのメッセージに共通の構成要素である。システムヘッダーの属性は、表２０に示す通りで、好ましい実施形態における対応する検証規則は表２１に示す通りである。
システム支払応答ＤＴＤの参照符（Ｒｅｆｅｒｅｎｃｅｓ）ＤＴＤは、好ましくは、以下の属性を含む（表４３）。
表４３
2011118898.tif 000049
【０１１６】
以下の表４４の検証規則は、好ましくは、参照符の属性に適用される。
表４４
2011118898.tif 000050
【０１１７】
精査依頼に応答して、精査受領（ＣｈａｌｌｅｎｇｅＡｃｋ）ＤＴＤが返送される。精査依頼は、金融機関によって選択的に使用され、対応する金融機関に支払詳細を回送する前にその金融機関の身元を検証するためのものである。受領を行う金融機関が、（ａ）発信者の身元を確実に認証できる場合、及び（ｂ）依頼を行なっているプロダクトをサポートできる場合には、精査受領は順調に行なわれる。接触情報は、この対応する金融機関によって精査受領データに含ませることができる。好ましい実施形態においては、精査受領データは、以下の属性を含む（表４５）。
【０１１８】
表４５
2011118898.tif 000051
【０１１９】
表４６の検証規則は、精査受領の属性に適用される。
表４６
2011118898.tif 000052
【０１２０】
以下の理由コード（表４７）は、精査受領とともに使用することができる。
表４７
2011118898.tif 000053
【０１２１】
サービス受領（ＳｅｒｖｉｃｅＡｃｋ）ＤＴＤ（上記した表３のサービス受領応答メッセージに対応する）は、応答する金融機関による接触情報をサービス受領データに含むことができる。それは、好ましくは、以下の表４８の属性を有する。
表４８
2011118898.tif 000054
【０１２２】
以下の検証規則（表４９）は、サービス受領の属性に適用される。
表４９
2011118898.tif 000055
【０１２３】
好ましい実施形態においては、以下の理由コードがサービス受領とともに使用される（表５０）。
表５０
2011118898.tif 000056
【０１２４】
支払指図受領（ＰａｙＩｎｓｔＡｃｋ）ＤＴＤは、銀行決済システムにおける取引情報の検証結果として送られる肯定的又は否定的な受領である。支払指図受領は、好ましくは、処理のために買手銀行１０２（口座振替取引モデルでは売手銀行１０４）によって処理されているデータを確認する交渉データブロックを含む。交渉データブロックは、上記表２３に挙げた属性を含む。システム支払応答との関連において、下表５１に記した検証規則は、好ましくは、交渉データブロックの属性に適用される。
表５１
2011118898.tif 000057
【０１２５】
支払指図受領は、好ましくは、以下の表５２の属性を含む。
表５２
2011118898.tif 000058
【０１２６】
以下の検証規則は、好ましくは、支払指図受領の属性に適用される（表５３）。
表５３
2011118898.tif 000059
【０１２７】
表５４の理由コードは、好ましい実施形態においては、支払指図受領とともに使用される。
表５４
2011118898.tif 000060
2011118898.tif 000061
2011118898.tif 000062
【０１２８】
支払確認（ＰａｙＣｏｎｆ）ＤＴＤは、支払を実行している銀行によって顧客及びコルレス銀行に送られるとともに、システム支払指図の実行の成否、決済ネットワークによる処理の不履行、及び受益銀行による支払の受け取り完了について知らせるために、買手銀行１０２及び売手銀行１０４双方が使用できる。成功の支払確認についての理由コード及び理由テキストは、成功件であることを明確にする。支払確認は、好ましい実施形態においては、以下の属性を含む（表５５）。
【０１２９】
表５５
2011118898.tif 000063
【０１３０】
以下の表５６の検証規則は、好ましくは、支払確認の属性に適用される。
表５６
2011118898.tif 000064
【０１３１】
以下の理由コードは、好ましくは、支払確認とともに使用される（表５７）。
表５７
2011118898.tif 000065
【０１３２】
債務確認（ＯｂｌｉｇａｔｉｏｎＣｏｎｆ）ＤＴＤブロックは、債務依頼の成否を確認する。債務確認は、（条件付き）支払債務又は（条件付き）保証付き支払債務が依頼された時のみに返信される。システムヘッダーに応じて、このブロックは、表３に挙げたＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ応答メッセージ又はＣｅＰＯｂ  Ａｃｐｔ  Ｃｏｎｆ応答メッセージに対応する。債務確認は、好ましくは、以下の表５８に挙げた属性を有する。
【０１３３】
表５８
2011118898.tif 000066
【０１３４】
以下の表５９の検証規則は、好ましくは、債務確認の属性に適用される。
表５９
2011118898.tif 000067
【０１３５】
また、以下の理由コード（表６０）は、好ましくは債務確認とともに使用される。
表６０
2011118898.tif 000068
【０１３６】
取消確認（ＣａｎｃｅｌｌａｔｉｏｎＣｏｎｆ）ＤＴＤブロックは、取消要求の肯定的又は否定的な確認を提供する。
このブロックは、上述した支払要求取消確認応答メッセージを実施するために使用することができる。好ましい実施形態においては、取消確認は、表６１に挙げた属性を有する。
表６１
2011118898.tif 000069
【０１３７】
以下の検証規則（表６２）は、好ましくは、取消確認の属性に適用される。
表６２
2011118898.tif 000070
【０１３８】
また、以下の理由コード（表６３）は、好ましくは、取消確認とともに使用することができる。
表６３
2011118898.tif 000071
【０１３９】
条件設定確認（ＣｏｎｄｉｔｉｏｎＳｅｔＵｐＣｏｎｆ）ＤＴＤブロックは、支払に関する条件を確認する要求に対する肯定的又は否定的な確認を提供する。条件設定確認は、上記した表３に挙げた条件更新応答メッセージに対応する。この応答は、現在その条件がＴＳＳ領域にあるということのみを表す。条件に関する他の全ての通信は、（後述する）支払条件（ＰａｙＣｏｎｄｉｔｉｏｎ）ＤＴＤにおいて定義される文書を使用する。条件確認は、好ましくは、以下の表６４に挙げた属性を含む。
表６４
2011118898.tif 000072
【０１４０】
以下の検証規則は、好ましくは、要素に含まれた条件確認の属性とともに使用される（表６５）。
表６５
2011118898.tif 000073
【０１４１】
以下の表６６の理由コードは、好ましくは、条件確認とともに使用される。
表６６
2011118898.tif 000074
【０１４２】
関係する受領（ＲｅｌａｔｅｄＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）ＤＴＤ要素は、取引に関係するその他の受領をサポートし搬送するために選択的に使用することができる。例えば、関係する受領ＤＴＤ要素は、売手銀行１０４対売手１０８の通信において、買手銀行１０２によって売手銀行１０４に提供される受領を搬送するために使用することができる。関係する受領ＤＴＤ要素は、コンテンツの識別、暗号解読、及び解釈を可能にする３つの標準化された属性を有する。好ましい実施形態においては、それら属性は、以下の表６７に挙げた通りである。
【０１４３】
表６７
2011118898.tif 000075
2011118898.tif 000076
関連受領属性に相応しい検証規則を、適切に実施することができる。
【０１４４】
支払条件
支払条件文書は、条件のステータスに関する情報を、取引に関連する各関係者の間で受け渡すために使用される（上記表３に挙げた条件告知応答メッセージは、支払条件文書に対応する）。この文書は、各条件がＴＳＳにおいてうまく作り出された時のみに使用される点に留意されたい。
支払条件文書は、好ましくは、以下の場合に使用される。
１．解除する必要のある条件が発生したことをＴＰＳＰに知らせるために、ＴＳＳによって使用される。
２．解除のために、指定条件のステータスに変化が生じたことをＴＳＳに知らせるために、ＴＰＳＰによって使用される。
３．買手１０６が行う支払に付随する条件のステータスに変化が生じたことを、買手銀行１０２に知らせるために、ＴＳＳによって使用される（この買手銀行１０２は、ＴＳＳとして働く、即ちＴＳＳの役割を果たすことができるという点に留意）。
４．条件のステータスに変化が生じたことを買手１０６又は売手銀行１０４に（必要に応じ）知らせるために、ＴＳＳによって使用される。
５．条件のステータスに変化が生じたことを売手１０８に知らせるために、売手銀行１０４によって使用される。
【０１４５】
支払条件（ＰａｙｍｅｎｔＣｏｎｄｉｔｉｏｎ）ＤＴＤのコンテンツは、好ましくは、以下の表６８に示す通りである。
表６８
2011118898.tif 000077
【０１４６】
好ましい実施形態におけるシステム支払条件（ＳｙｓｔｅｍＰａｙＣｏｎｄｉｔｉｏｎ）ＤＴＤは、（表６９に示すような）以下の要素又はブロックを含む。
表６９
2011118898.tif 000078
【０１４７】
条件付き支払プロダクトのための、好ましい実施形態におけるシステムヘッダーの属性は、上記した表２０に含まれている。好ましい関連の検証規則は、上記した表２１に示されており、好ましくは表７０のプロダクト属性のための検証規則も含む。
表７０
2011118898.tif 000079
【０１４８】
この参照符ブロックは、条件付の商業的支払取引を識別するために使用される。好ましい実施形態における参照符ブロックの属性及び関連検証規則は、それぞれ上記した表４３及び表４４に示される。
条件群ブロックは、支払の付随する条件の記述を含む。条件群ブロックは、インポート要素であり、前述したように、多くのシステム支払ブロックで使用される。このブロックの好ましい記述は、後でより詳細に示す。
また、前述したように、接触ブロックは、取引に関連する各関係者に接触情報を提供するために使用できる接触詳細を含む。好ましくは、接触ブロックは、インポート要素であって、それをインポートする多くのシステム支払ブロックにおいても使用される（また、前述したように条件群も含む）。好ましい実施形態における接触データブロックも、後でより詳細に説明する。
【０１４９】
支払取消
支払取消文書は、支払の取消を依頼するために使用される。前述し表２に挙げた支払要求取消依頼メッセージは、支払取消文書で実施される。通常、−買手又は銀行の債務が保証された「取消不能な」支払は、売手１０８の同意を得て初めて取消すことができる。好ましい実施形態においては、支払取消ＤＴＤのコンテンツは表７１のように定義される。
表７１
2011118898.tif 000080
【０１５０】
システム支払取消（ＳｙｓｔｅｍＰａｙＣａｎｃｅｌｌａｔｉｏｎ）ＤＴＤは、好ましくは、以下の表７２に挙げたブロックを含む。
表７２
2011118898.tif 000081
【０１５１】
システムヘッダーブロックは、前述したように、全てのメッセージに共通の構成要素である。上記した表２０及び表２１は、好ましい実施形態によるこのブロックの属性及び検証規則となる。更に、支払取消に関連して、メッセージ形式に関し、依頼構造での有効値は、「取消依頼」及び「照会」である。
取消買手署名データブロックは、好ましくは、以下の要素を含む（表７３）。
表７３
2011118898.tif 000082
【０１５２】
参照符ブロックは、取消を依頼されている取引の参照符を含む。好ましい実施形態における参照符ブロックの属性及び関連する検証規則は、それぞれ上記した表４３及び表４４に示される。取消データブロックは、買手１０６が提供した追加データを含み、取消に関係する買手銀行１０２に受け渡される。好ましくは、このブロックは、取消指図書を実行するための属性及び関連検証規則を有する。
【０１５３】
（取消買手署名データブロックの）買手署名ブロックは、取引取消を許可する買手組織の関係者によって作成される署名を含む。承認サイクルでは、どの指図書に対しても多くの署名を求めることができる。よって、買手署名詳細ブロックを、複数の買手署名詳細ブロックとすることができる。買手署名詳細ブロックは、買手１０６が作成した署名に関する情報を含み、好ましい実施形態において、その属性は表３１に、関連検証規則は表３２に示される。また、前述したように、（システム支払取消ＤＴＤに含まれる）関連する買手署名ブロックは、好ましくは、署名がＰＣＤＡＴＡとして買手署名要素に含まれるＰＣＤＡＴＡブロックを含む（表３３参照）。好ましい実施形態に関し、そのブロックの属性及び関連検証規則は表３４に記されている。
【０１５４】
支払精査
支払精査文書は、申請データを交換するに先立って、第三者金融機関の身元の裏付けを必要とする金融機関が、その第三者金融機関の身元を確証するとともに支払プロダクトがサポートされていることを確認することを可能とする。支払精査に対する応答は、精査受領を含む支払応答である。支払精査（ＰａｙｍｅｎｔＣｈａｌｌｅｎｇｅ）ＤＴＤは、好ましい実施形態においては、以下の要素を有する（表７４）。
表７４
2011118898.tif 000083
【０１５５】
条件群
条件群要素（ＣｏｎｄｉｔｉｏｎｓＳｅｔ  ｅｌｅｍｅｎｔ）ＤＴＤは、支払に付随できる条件に関する情報を搬送するために、多くの取引において使用される。条件群（ＣｏｎｄｉｔｉｏｎｓＳｅｔ）ＤＴＤは、好ましくは、以下の表７５に挙げた要素を含む。
表７５
2011118898.tif 000084
【０１５６】
条件群は、好ましくは、以下の表７６に挙げた属性を有する。
表７６
2011118898.tif 000085
相応しい検証規則が、条件群属性に適用される。
【０１５７】
条件ブロックは、接触ブロックを含む。支払の条件が、異なるＴＰＳＰによって解除される場合には、接触情報は、条件群に対してではなく各条件に個別に添付するのが好ましい。この要素は、買手１０６又は売手１０８が支払依頼文書の条件を金融機関に知らせる場合のみに存在するのが好ましい。条件ブロックは、好ましい実施形態においては、以下の属性を有する（表７７）。
表７７
2011118898.tif 000086
【０１５８】
以下の表７８に挙げた検証規則は、好ましくは、条件ブロックの属性に適用される。
表７８
2011118898.tif 000087
このシステムは、支払プロダクトとともに使用されるべき条件を定義することができる。
【０１５９】
支払条件に関連して使用できる他の要素は、パッケージコンテンツである。パッケージコンテンツ要素は、置換えシステムによってそれを誤解釈しないようにしつつＸＭＬ互換性を保証するように変形された埋め込みデータストリームの概念をサポートする。それをシステムで使用するにより、ＴＰＳＰは、条件を解除する時にサポート文書を提供することができる。全条件の解除が完了すると、支払確認データとして搬送される文書が売手に転送されるのが好ましい。パッケージコンテンツデータストリームは、好ましくは、そのコンテンツの識別、解読、及び解釈を可能とする３つの標準属性を有しており、これら属性は、好ましくは以下の表７９のように定義される。
表７９
2011118898.tif 000088
2011118898.tif 000089
2011118898.tif 000090
ここでも、相応しい検証規則を、パッケージコンテンツの属性に適用することができる。
【０１６０】
接触
接触（Ｃｏｎｔａｃｔ）ＤＴＤは、多くの文書定義において使用されるため、好ましくは、再利用のために個別のＤＴＤで定義される。この構造は、これとともに使用されている要素に関連した包括的な接触データを含む。通常、このデータは、所定取引を扱う複数の個人に関する名前及び接触詳細を含む。従って、接触ブロックは、以下の属性を有する（その内容は、表８０で明らかである）。
表８０
2011118898.tif 000091
【０１６１】
相応しい検証規則を、接触の属性に適用することができる。接触データブロックは、以下の属性も含むことができる（ここでも、これらの属性に関する内容は、表８１から明らかである）。
表８１
2011118898.tif 000092
また、検証規則を、これら属性に適切に適用することができる。
【０１６２】
フィールド長とフォーマット
表８２は、好ましい実施形態における大部分の決済システムのデータフィールドに関するフィールド長及びフォーマットを要約したものである。
表８２
2011118898.tif 000093
2011118898.tif 000094
【０１６３】
エラーコード及びエラーテキスト
理由コードを決済システムで使用して、特定件の成否理由についても詳細を更に提供することができる。理由コードの好ましい構造は、ｓｓｂｂｎｎである。
ここで、
ｓｓ＝エラーコード（例えば、００）を有するスキームの識別子、
ｂｂ＝そのスキーム内のＤＴＤブロック、
ｎｎ＝エラーの数
を示す。
【０１６４】
例えば、以下の表８３のｂｂブロックコードは、上記ＤＴＤに対して使用することができる。
表８３
2011118898.tif 000095
【０１６５】
また、以下の表８４は、理由コード群を要約したものである。
表８４
2011118898.tif 000096
2011118898.tif 000097
2011118898.tif 000098
2011118898.tif 000099
2011118898.tif 000100
【０１６６】
以下、特定の支払プロセスの好ましい全体メッセージフロー、及び、他の取引モデルにおけるそれらのメッセージフローを例示する取引ステップを、図６乃至図８を参照して説明する。
【０１６７】
支払要求メッセージフロー
支払要求を処理するための好ましい全体的メッセージフローを図６に示す。
このプロセスにおける最初のメッセージに先立って、買手１０６及び売手１０８は、それぞれの証明書を介してお互いを識別し、売買契約を結ぶ。買手１０６は、買手１０６から買手銀行１０２への支払要求によってこの取引に関する支払を行うことに合意する。
次に、買手１０６は、支払要求の容認可能性を検討し、支払要求指図書の買手欄に記入して（表４参照）、その支払要求指図書に署名する。次に、図６のメッセージ１に示すように、買手１０６は、支払要求指図書を売手１０８に送る。
【０１６８】
売手１０８は、受け取った支払要求指図書の容認可能性を検討し、支払要求指図書の売手欄に記入し（表４参照）、補充された支払要求指図書に署名する。次に、図６のメッセージ２に示すように、売手１０８は、その支払要求指図書を売手銀行１０４に送る。
売手銀行１０４は、支払要求指図書の容認可能性を検討し、売手の証明書を検証し、その要求指図書の売手銀行欄に記入し（表４参照）、補充された支払要求指図書に署名する。次に、図６のメッセージ３に示すように、売手銀行１０４はその支払要求指図書を買手銀行１０２に送る。
【０１６９】
買手銀行１０２は、支払要求指図書の容認可能性を検討し、メッセージ構文、証明書と署名の有効性、及び、署名者の認証を検証する。次に、買手銀行１０２は、これらの調査結果を付したサービス受領メッセージ（表９参照）を作成し、このサービス受領に署名して、図６のメッセージ４に示すように売手銀行１０４に送る。
売手銀行１０４は、サービス受領認書を検討し、必要に応じ、その詳細を補充して、補充したメッセージに署名する。次に、このメッセージは、図６のメッセージ５に示すように売手１０８に送られる。
【０１７０】
売手１０８は、サービス受領書を検討し、必要に応じその詳細を補充して、それに署名する。次に、補充されたメッセージは、図６のメッセージ６に示すように買手１０６に送られる。
好ましくは、支払要求指図書に特定された支払実行日時になった時、支払要求指図は、銀行の既存支払設備を使用して実行される。
買手銀行１０２は、支払要求が実行されたことを示すために、支払実行の確認書を作成する（表１１参照）。次に、買手銀行１０２は、このメッセージに署名して、図６のメッセージ７に示すように売手銀行１０４に送る。支払実行の確認書は、支払要求が成功裏に実行されたか否かを示す。支払実行の確認メッセージは、好ましくは、翌日の就業日最終時刻までに送られる。
【０１７１】
売手銀行１０４は、支払実行の確認書を検討し、必要に応じ、その詳細欄で支払実行の確認書を補充し、補充されたメッセージに署名し、それを図６のメッセージ８に示すように売手１０８に送る。
買手銀行１０２は、支払要求が成功裏に実行されたか否かを示すために、支払実行の確認書を作成する。次に、買手銀行１０２は、このメッセージに署名して、それを図６のメッセージ９に示すように買手１０６に送る。支払実行が不成功であった場合には、売手１０８及び売手銀行１０４に送られたものより更に詳細なその理由の説明書が買手に送られる。支払実行の確認メッセージは、少なくとも翌日の営業日最終時刻までに送られるのが好ましい。
【０１７２】
好ましい実施形態においては、支払要求が実行されて銀行の支払設備に渡されたことを明示する支払実行の確認メッセージを、買手銀行１０２がまだ送っていないのであれば、買手１０６は、その支払要求を取消すことができる。支払要求を取消すためには、買手１０６は、支払要求取消書を作成する（表７参照）。買手は、支払要求取消書に署名し、それを図６のメッセージ１０に示すように買手銀行１０２に送る。
好ましい実施形態においては、買手１０６による支払依頼の取消は認められているので、好ましくは、決済サービスは、対応する支払依頼がまだ入手されていない場合でも、全ての取消依頼を記憶している。これにより、既に無効とされた遅延した支払依頼が識別されて実行されるのを阻止することができる。
【０１７３】
買手銀行１０２は、支払要求取消書の容認可能性を検討し、メッセージ構文、証明書と署名の有効性、及び、署名者の認証を検証する。次に、買手銀行１０２は、これらの調査結果を付したサービス受領メッセージ（表９参照）を作成する。次に、買手銀行１０２は、サービス受領書に署名し、これを図６のメッセージ１１に示すように買手１０６に送る。
買手銀行１０２は、支払要求取消依頼が受諾されたことを示すために、支払要求取消の確認書を作成する（表１５参照）。次に、買手銀行１０２は、支払要求取消書に署名し、これを図６のメッセージ１２に示すように買手１０６に送る。
支払要求取消メッセージの確認書は、好ましくは、翌日の営業日最終時刻までに送られるべきである。
【０１７４】
買手銀行１０２は、支払要求取消依頼が承認されたことを示すために、支払要求取消の確認書を作成する。買手銀行１０２は、図６のメッセージ１３に示すように支払要求取消の確認書に署名し、これを売手銀行１０４に送る。支払要求取消メッセージは、好ましくは、翌日の営業日最終時刻までに送られるべきである。
支払要求は、前述した３つのモデルで表すことができる。即ち、４コーナーモデルでは、買手から買手銀行への指図として、或いは、売手銀行によって決済システムに組み込まれる口座振替形式の指図として表すことができる。  
【０１７５】
４コーナーモデルにおける支払要求取引
４コーナーモデルにおける典型的な支払要求取引は、以下のように発生する。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する。
２．購買時点において、売手のソフトウェアは、買手１０６が記入するための支払フォーマットを提示する。
３．買手１０６は、買手署名データブロックに署名する。このブロックは、買手データブロック、売手公開データブロック、交渉データブロック、及び、買手署名詳細ブロックを含む。支払要求のために、買手署名データブロックは、債務形式が「ＮＯＮＥ」に設定された債務ブロックを含むこともできる。（内部的又は売手１０８のシステムを介して提供される設備による）買手の役割として、支払を認証するために多くの署名を求めることができるという点に注目されたい。よって、それ以降の署名は、上記のデータブロックのみに署名するか、又は、既に作成されている買手署名ブロックに追加して署名することができる。
４．選択的に、売手１０８は、買手からのＰＫＣＳ＃７パッケージに含まれた買手１０６の署名を調査することができる。通常、買手の指令を処理する前に買手の署名を調査するのは買手銀行１０２の要件であるため、この段階は選択的なものである。
５．適切な場合には、売手１０８は売手私有データを添付して、メッセージに署名し、署名されたメッセージを売手銀行１０４に送る。
６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、売手１０８の証明書に示された認証及び権利を調査する。これらの調査が不成功に終わった場合には、売手１０８に対して否定的なサービス受領書を送る。
７．売手１０８が、売手公開データ又は売手私有データブロックのいずれかの口座詳細を提供した場合には、売手銀行１０４は、これら口座詳細を検証する。売手銀行１０４は、売手銀行データブロックのメッセージに口座詳細を添付することができる。売手銀行１０４は、取引の通貨に基づくコルレス銀行コードを添付することもできる。売手銀行１０４は、メッセージから売手私有データブロックを除去する。
８．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて、買手銀行１０２との精査応答取引を始めることを希望することができる。精査応答取引を選択した場合には、売手銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセージに署名する。
次に、買手銀行１０２は、売手銀行１０４の信任状を調査するとともに、依頼されている支払プロダクトを処理できるかどうかを調査し、買手銀行１０２の検証された信用状を含む売手に対する応答書に署名する。
売手銀行１０４は、買手銀行１０２によって提示される信任状を検証する。検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサービス受領書を売手１０８に送る。
９．売手銀行１０４は、そのメッセージに署名し、これを買手銀行１０２に送る。
１０．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータスと、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ていることを裏付ける必要がある。これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４に対して否定的なサービス受領書を送る。これらの調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送る。売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送る。全ての受領書は、受領する組織の署名付き証明書という新しい証拠を含む。
１１．買手銀行１０２は、口座関連の詳細も検証する。この検証は同時に行うことができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は、否定的な支払指図受領書を送る。口座関連詳細を同時に検証する場合には、支払指図受領書は、サービス受領書と同じ文書で返信することができる。
１２．支払実行時には、買手銀行１０２は、買手１０６及び売手銀行１０４に、その支払が実行されたことを通知する支払確認書を送る。決済システムが、支払取引をうまく処理できない場合には、否定的な支払確認が作成される。売手銀行１０４は、買手銀行１０２から資金が順調に入金されたことを確認するために、支払確認書を送ることができる。
【０１７６】
４コーナーモデルを使用した支払要求の取消
取消可能な支払要求に対しては、４コーナーモデルを使用して、支払を取消すことができる。買手銀行１０２は、取消依頼の成功について、買手１０６に対して同時に知らせるべきである。この形式の取引における支払要求の典型的な取消は、以下の通りである。
１．買手１０６及び売手１０８は、売手１０８のシステムを介して取消を調整する。
２．購買時点において、売手１０８は、買手１０６が記入するための取消フォーマットを提示する。
３．買手１０６、取消買手署名データブロックに署名する。（内部的又は売手１０８のシステムを介して提供される設備による）買手の役割として、支払を取消すために多くの署名を求めることができるという点に注目されたい。よって、それ以降の署名は、上記のデータブロックに署名するとともに、選択的に以前の即ち先行の買手署名ブロックに署名することができる。
５．選択的に、売手１０８は、買手１０６の署名を調査することができる。
６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、及び、売手１０８の証明書に示された認証及び権利を調査する。これらの調査が不成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサービス受領書を送る。
７．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて、買手銀行１０２との精査応答取引を始めることを希望することができる。売手銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセージに署名する。
買手銀行１０２は、売手銀行１０４の信任状を調査するとともに、依頼されている支払プロダクトを処理できるかどうかを調査し、買手銀行１０２の検証信任状を含む売手１０８に対する応答書に署名する。
売手銀行１０４は、買手銀行１０２によって提示された信任状を検証する。検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサービス受領書を売手１０８に送る。
８．売手銀行１０４は、取消メッセージに署名し、これを買手銀行１０２に送る。
９．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ていることの裏付けを行なう。
これらの調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４に対して否定的なサービス受領書を送る。これらの調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送る。売手銀行１０４はそのサービス受領書に再度署名し、これを売手１０８に送る。全ての受領書は、受領する組織の署名付き証明書という新しい証拠を含む。
１０．次に、買手銀行１０２は、取消依頼を処理することになる。取消が成功裏に実行された場合には、買手銀行１０２は、肯定的な取消確認書を売手銀行１０４及び売手１０８に送る。取消が実行できない場合には、否定的な取消確認書が発せられることになる。取消依頼が同時に処理できる場合には、取消確認書は、サービス受領書でまかなうことができる。
【０１７７】
買手対買手銀行モデルにおける支払要求処理
買手対買手銀行取引では、購買技術又は他の買手技術で支払プロダクトを確実に配信できる。支払要求のための典型的な買手対買手銀行取引は、以下のように行われる。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する。
２．買手１０６が、買手銀行１０２に支払要求を直接行う。
３．買手１０６は、買手署名データブロックに署名する。このブロックは、買手データブロック、売手公開データブロック、交渉データブロック、及び、買手署名詳細ブロックを含む。支払要求の際、買手署名データブロックは、債務形式が「ＮＯＮＥ」に設定された債務ブロックも含むことになる。
（内部的又は売手１０８のシステムを介して提供される設備による）買手の役割として、支払を認証するために多くの署名を求めることができるという点に注目されたい。よって、それ以降の署名は、上記のデータブロックのみに署名するか、又は、既に作成されている買手署名ブロックに追加して署名することができる。
４．買手１０６は、この文書に署名し、それを買手銀行１０２に送る。
５．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、買手１０６に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送る。
６．買手銀行１０２は、口座関連詳細も検証する。この検証は同時に行うことができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は、否定的な支払指図受領書を送る。口座関連詳細が同時に検証される場合には、支払指図受領書は、サービス受領書と同じ文書で送り返すことができる。
７．支払実行時には、買手銀行１０２は、支払が実行されたことを通知する支払確認書を買手１０６に送る。決済システムが支払取引をうまく処理できない場合には、否定的な支払確認を発することができる。
【０１７８】
買手対買手銀行モデルを使用しての支払要求の取消
取消可能な支払要求に関しては、買手対買手銀行モデルを使用して、支払を取消すことができる。このモデルを使用した場合における、典型的な支払要求取消は、以下の通りである。
１．買手１０６は、それ自身の内部システムを介して又はその金融機関のシステムを介して支払要求の取消を試みる。
２．買手１０６は、システムヘッダーと参照符ブロックとに署名する。買手の役割として、支払を取消すために多くの署名を必要とするという点に注目されたい。よって、それ以降の署名は、上記のデータブロックに署名するとともに、選択的に以前の買手署名ブロックに署名することができる。
３．買手１０６は、それを買手銀行１０２に送る。
４．買手銀行１０８は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、買手１０６に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用される参照符の表示を含む肯定的なサービス受領書を送る。
５．次に、買手銀行１０２は、取消依頼を処理することになる。取消が成功裏に実行された場合には、買手銀行１０２は、肯定的な取消確認書を買手１０６に送る。取消が実行できない場合には、否定的な取消確認書が発せられることになる。取消依頼が同時に処理できる場合には、取消確認書は、サービス受領書でまかなうことができる。
【０１７９】
口座振替モデルにおける支払要求取引
本発明における口座振替モデルの使用により、支払プロダクトを、口座振替形式の支払を実現にする決済システムとともに使用することが可能となる。この形式の取引は、個々の清算機関の規則に基づいて使用することができる。口座振替モデルを使用した典型的な支払要求取引は、以下のように発生する。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する。商業取引は、売手銀行１０４が指図書を決済システムに受け渡すことによって、口座振替形のネットワークを介して決済されることになる。
２．買手１０６は、買手の口座から引き落とすことを売手に認証する指令を構成する買手署名データブロックに署名する。この買手署名データブロックには、買手データ、売手公開データ、及び、交渉データが含まれる。
３．売手１０８は、選択的に、買手１０６の署名を調査する。これは推奨されるが義務的なものではない。買手１０６の口座からの引落しを認証するに先立ち、買手銀行１０２は、買手１０６の署名を調査するのが好ましい。
４．売手１０８は、必要に応じ、買手署名データに売手私有データブロックを添付して署名し、これを売手銀行１０４に送る。
５．売手銀行１０４は、売手の署名、メッセージの構文、及び、売手１０８の認証を調査する。これら調査のいずれかが不成功に終わった場合には、売手銀行１０４は、否定的なサービス受領書を売手１０８に送る。
６．売手銀行１０４は、買手の署名付き指令書に署名し、これを買手銀行１０２に送る。要求データを提出するに先立ち、対応する金融機関の身元を厳格に検証する必要がある場合、売手銀行１０４は、選択的に、システム精査応答を開始できるという点に注目されたい。
買手銀行１０２は、買手１０６の署名、メッセージの構文、買手１０６の認証を調査する。これら調査のいずれかが不成功に終わった場合には、買手銀行１０２は、関連する売手銀行１０４に対し、売手に対するサービス受領書の関連受領書として否定的なサービス受領書を送る。買手銀行１０２は、買手の指令を確認して、買手１０６の口座からの引落しを認証する。
７．肯定的なサービス受領書を受け取ると、売手銀行１０４は、適当なバックエンド決済システムで支払（口座引落し）指図書を作成する。肯定的なサービス受領書が売手１０８に送られる。
８．支払指図を実行すると、売手銀行１０４は、選択的に、口座引落し指図が実行されたことを売手１０８及び買手銀行１０２に知らせることができる。
９．売手１０８の口座に資金を受け取ると、売手銀行１０４は、選択的に、資金の受領を通知する支払確認書を売手１０８及び売手銀行１０４に送ることができる。
【０１８０】
口座振替モデルを使用した支払要求の取消
口座振替ネットワークの規則及び／又は加盟銀行の方針に応じて、口座振替指図書は、２当事者モデル（買手対買手銀行、及び、売手対売手銀行）又は４当事者モデルにおいても取消すことができる。以下は、４当事者モデルにおける典型的な取消を説明したものである。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して取消を進める。
２．購買時点において、売手１０８は、買手１０６が記入するための取消フォーマットを提供する。
３．買手１０６は、取消し対象の商業取引の参照符情報を含む取消買手署名データブロックに署名する。（内部的又は売手１０８のシステムを介して提供される設備による）買手の役割として、支払を取消すために多くの署名を必要とするという点に注目されたい。よって、それ以降の署名は、上記のデータブロックに署名するとともに、選択的に、以前の買手署名ブロックに署名することができる。
４．選択的に、売手１０８は、買手１０６の署名を調査することができる。
５．売手１０８は、署名された文書を売手銀行１０４に送る。
６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、及び、売手１０８の証明書に示された認証及び権利を調査する。これら調査が不成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサービス受領書を送る。
７．このしくみの規則により、売手銀行１０４が、支払を取消す前に買手１０６の署名の有効性を調査する必要がある場合には、さもなければ売り手銀行が支払の取消しを行なう下記段階８において、売手銀行１０４は、選択的に、取消確認を買手銀行１０２及び売手に通知する。
８．売手銀行１０４は、取消メッセージに署名し、それを買手銀行１０２に送る。
９．買手銀行１０８は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、取消依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送ることになる。そして、売手１０８は支払を取消す。この例では、買手銀行１０２からの取消依頼に対応する応答がサービス受領メッセージである点に注目されたい。取消確認を開始するのは売手銀行１０４である。
売手銀行１０４は、サービス受領書に再度署名し、それを売手１０８に送る。
全ての受領書は、証明書に署名する受領組織の新しい証拠を含む。
【０１８１】
支払債務メッセージフロー
支払債務を処理するための好ましい全体的メッセージフローを図７に示す。このプロセスにおける最初のメッセージに先立ち、買手１０６及び売手１０８は、それぞれの証明書を介して互いに身元確認し、売買契約を結ぶ。次に、買手１０６は、買手１０６から売手銀行１０４への支払債務（表４及び表５参照）を利用してその取引の支払を行うことに合意する。
買手１０６は、支払方法を受諾し、支払債務指図書の容認可能性を検討し、支払債務指図書の買手欄に記入した後に、この支払債務指図書に署名する。次に、この支払債務指図書は、図７のメッセージ１に示すように、売手１０８に送られる。
【０１８２】
売手１０８は、支払債務指図書の容認可能性を検討し、その要求欄（表４及び表５参照）に記入した後に、この補充メッセージに署名して、これを図７のメッセージ２に示すように売手銀行１０４に送る。
売手銀行１０４は、この支払債務指図書の容認可能性を検討するとともに、売手１０８の証明書を検証し、その要求欄（表４及び表５参照）に記入した後に、この補充したメッセージに署名する。次に、このメッセージは、図７のメッセージ３に示すように買手銀行１０２へ送られる。
【０１８３】
買手銀行１０２は支払債務指図書の容認可能性を検討するとともに、メッセージ構文、証明書と署名の有効性、及び、署名者の認証を検証する。次に、買手銀行１０２は、これら調査結果を備えたサービス承認メッセージ（表９を参照のこと）を生成する。次に、買手銀行１０２は、図７のメッセージ４に示すように、サービス受領書に署名してこれを売手銀行１０４に送る。
【０１８４】
売手銀行１０４は、サービス受領書を検討し、必要に応じ、その詳細欄を使用してこれを補充した後に、この補充したメッセージに署名する。次に、図７のメッセージ５に示すように、補充されたサービス承認メッセージは、売手１０８に送られる。
売手は、サービス受領書を検討し、必要に応じ、その詳細欄を使用してこれを補充した後に、この補充したメッセージに署名する。次に、図７のメッセージ６に示すように、補充されたサービス承認は、買手１０６に送られる。
買手銀行１０２は、支払債務が受諾されたか否かを示すために、支払債務受諾確認メッセージ（表１３を参照のこと）を作成する。次に、買手銀行１０２は、支払債務受諾確認書に署名し、図７のメッセージ７に示すように、これを売手銀行１０４に送る。
【０１８５】
売手銀行１０４は、支払債務受諾確認書を検討し、必要に応じ、その詳細欄を使用してそれを補充した後に、補充したメッセージに署名して、それを図７のメッセージ８に示すように売手１０８に送る。
買手銀行１０２は、支払実行に関するこの確認書を検討し、必要に応じ、その詳細欄を使用してこれを補充した後に、補充したメッセージに署名して、図７のメッセージ９に示すようにこれを売手１０８に送る。
支払債務指図書に指定された日時になった時、支払債務は、銀行の既存支払施設を利用して実行されるのが好ましい。
【０１８６】
買手銀行１０２は、この支払債務が履行されたことを示すために、支払実行確認書（表１１参照）を作成する。次に、買手銀行１０２は、このメッセージに署名し、図７のメッセージ１０に示すようにこれを売手銀行１０４に送る。支払実行確認書は、この支払債務が成功裏に履行されたか否かを表す。少なくとも、支払実行確認メッセージは、翌日の営業日最終時刻までに送られるのが好ましい。
【０１８７】
売手銀行１０４は、この支払実行確認メッセージを検討し、その詳細欄を使用して支払実行確認情報を補充した後に、この補充したメッセージに署名してそれを図７のメッセージ１１に示すように売手１０８に送る。
買手銀行１０２は、支払要求が実行されたことを示す支払実行確認メッセージを作成する。次に、買手銀行１０２は、このメッセージに署名し、図７のメッセージ１２に示すようにこれを買手１０６に送る。支払実行確認メッセージは、この支払債務が成功裏に履行されたか否かを表す。支払実行が不成功に終わった場合には、売手１０８及び売手銀行１０４に送られたものより詳細なその理由の説明が買手１０６に送られる。少なくとも、支払実行確認メッセージは、翌日の営業日最終時刻までに送られるのが好ましい。
【０１８８】
４コーナーモデルにおける支払債務取引
支払債務は、４コーナーモデル又は買手対買手銀行モデルにおいて使用することができる。４コーナーモデルにおける典型的な支払債務取引は、以下の通りである。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する。
２．購買時点において、売手のソフトウェアは、買手１０６が記入するための支払フォーマットを提供する。
３．買手１０６は、買手署名データブロックに署名する。このブロックは、買手データブロック、売手公開データブロック、交渉データブロック、及び、買手署名詳細ブロックを含む。支払債務に関して、買手署名データブロックは、「買手」に設定された債務形式の債務ブロックも含むことになる。
（内部的又は売手１０８のシステムにより提供される設備を介しての）買手の役割として、支払いを認証するために多くの署名を求めることができるという点に注目されたい。よって、それ以降の署名は、上記のデータブロックにのみ署名するか又は既に作成されている買手署名ブロックに追加して署名することができる。選択的に、売手１０８は、買手１０６の署名を調査することができる。支払処理において買手銀行１０２が買手１０６の証明書を検証する要件は、一般的なものである。
４．適切な場合には、売手１０８は、売手私有データを添付した後に、メッセージに署名し、この署名付きメッセージを売手銀行１０４に送る。
５．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、売手１０８の証明書に示された認証及び権利を調査する。これらの調査が不成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサービス受領書を送る。
６．売手１０８が、売手公開データブロック又は売手私有データブロックに口座詳細を提供した場合には、売手銀行１０４は、これら口座詳細を検証することになる。売手銀行１０４は、売手銀行データブロックのメッセージに口座詳細を添付する。また、売手銀行１０４は、取引の通貨に基づくコルレス銀行コードを添付する。売手銀行１０４は、このメッセージから売手私有データブロックを除去する。
７．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて、買手銀行１０２との精査応答取引を始めることを希望することができる。売手銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセージに署名することになる。
買手銀行１０２は、売手銀行１０４の信任状を調査し、依頼されている支払プロダクトを処理できるか否かを調査し、買手銀行１０２の検証された信任状を含む売手１０８への応答に署名することになる。
売手銀行１０４は、買手銀行１０２が提示した信任状を検証することになる。
検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサービス受領メッセージを売手１０８に送ることになる。
８．売手銀行１０４は、そのメッセージに署名し、これを買手銀行１０２に送る。
９．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送ることになる。
売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送る。全ての受領書は、受領組織の署名付き証明書という新しい証拠を含む。
１０．買手銀行１０２は、口座関連詳細も検証する。この検証は同時に行うことができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は、否定的な支払指図受領書を送ることになる。口座関連詳細が同時に検証される場合には、支払指図受領書は、サービス受領書と同じ文書で返送することができる。
１１．支払実行時には、買手銀行１０２は、支払が行なわれたことを通知する支払確認書を買手１０６及び売手銀行１０４に送ることができる。決済システムが支払取引を成功裏に処理することができない場合には、否定的な支払確認書を発することができる。売手銀行１０４は、買手銀行１０２から資金の受け取りが成功裏に完了したことを確認するために支払確認書を送ることができる。
【０１８９】
４コーナーモデルを使用した支払債務の取消
支払債務に関しては、以下の４コーナーモデルプロセス又は売手による取消に対する積極的な同意を含む拘束のないプロセスを使用して支払取消しを行なうことができる。
１．買手１０６及び売手１０８は、売手のシステムを介して取消を進める。
２．購買時点において、売手１０８は、買手１０６が記入するための支払フォーマットを提供する。
３．買手１０６は、取消買手署名データブロックに署名する。（内部的又は売手のシステムを介して提供される設備による）買手の役割として、支払を取消すために多くの署名を求めることができるという点に注目されたい。よって、それ以降の署名は、上記のデータブロックに署名するとともに、選択的に、以前の買手署名ブロックに署名することができる。
４．選択的に、売手１０８は、買手１０６の署名を調査することができる。
５．売手１０８は、署名した文書を売手銀行１０４に送る。
６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、及び、売手１０８の証明書に示された認証及び権利を調査する。これら調査が不成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサービス受領書を送る。
７．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて、買手銀行１０２との精査応答取引を始めることを希望することができる。精査応答取引を選択した場合には、売手銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセージに署名することになる。
買手銀行１０２は、売手銀行１０４の信任状を調査し、依頼されている支払プロダクトを処理できるか否かを調査し、買手銀行１０２の検証された信任状を含む売手１０８への応答に署名する。
売手銀行１０４は、買手銀行１０２によって提示された信任状を検証することになる。検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサービス受領書を売手１０８に送る。
８．売手銀行１０４は、取消メッセージに署名し、これを買手銀行１０２に送る。
９．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、その取消依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送ることになる。
売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送る。全ての受領書は、受領組織の署名付き証明書という新しい証拠を含む。
１０．次に、買手銀行１０２は、取消依頼を処理することになる。取消が成功裏に実行された場合には、買手銀行１０２は、肯定的な取消確認書を売手銀行１０４及び売手１０８に送ることができる。取消が実行できない場合には、否定的な取消確認書が発せられることになる。取消依頼が同時に処理できる場合には、取消確認書は、サービス受領書でまかなうことができる。
取引が識別できない場合には、否定的な取消依頼文書が作成されることになる。
【０１９０】
買手対買手銀行モデルにおける支払債務取引
買手対買手銀行モデルにおける典型的な支払債務取引は、以下のように行われる。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する。
２．買手１０６は、支払債務を直接買手銀行１０２に依頼する。
３．買手１０６は、買手署名データブロックに署名する。買手１０６は、売手１０８の口座詳細の欄を含み、且つ、売手１０８の同意を得て初めて取消すことができる売手１０８に対する債務を買手１０６が引き受けることを示す売手公開データを記入することになる。支払債務に関して、債務ブロックの債務形式属性は、「買手」に設定される。
買手の役割として、支払を認証するために多くの署名を求めることができるという点に注目されたい。それ以降の署名は、上記のデータブロックのみに署名するか、又は既に作成されている買手署名ブロックに追加して署名することができる。
４．買手１０６は、文書に署名し、これを買手銀行１０２に送る。
５．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付いた支払債務依頼書に関して、買手銀行１０２は、その依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、否定的なサービス受領書を買手１０６に送る。これら調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送ることになる。
支払債務に関し、買手銀行１０２は、買手１０６がその債務を引き受けたことを示すサービス受領書の入った債務確認ブロックを含むことになる。
６．買手銀行１０２は、口座関連詳細も検証する。この検証は同時に行うことができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は、否定的な支払指図受領書を送る。口座関連詳細が同時に検証される場合には、支払指図受領書は、サービス受領書と同じ文書で返送することができる。
７．支払実行時には、買手銀行１０２は、支払が行なわれたことを通知する支払確認書を買手１０６に送ることができる。決済システムが支払取引を成功裏に処理することができない場合には、否定的な支払確認書を発することができる。
通常、支払債務は、買手対買手銀行モデルを使用して取消すことはできない。
【０１９１】
保証付き支払債務メッセージフロー
好ましい実施形態において、保証付き支払債務プロダクトは、保証付き支払債務指図メッセージが支払債務指図書の代わりとなるとともに、保証付き支払債務受諾確認メッセージが支払債務受諾確認の代わりとなる点を除けば、図７に示したものと同じ全体メッセージフローを用いることができる。
【０１９２】
４コーナーモデルにおける保証付き支払債務取引
４コーナーモデルにおいて、典型的な保証付き支払債務処理は、以下のように行われる。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する。
２．購買時点において、売手のソフトウェアは、買手１０６が記入するための支払フォーマットを提供する。これは、保証付き支払債務が適切に売手に申請されるという要件を含む。
３．買手１０６は、買手署名データブロックに署名する。（内部的又は売手１０８のシステムを介して提供される設備による）買手の役割として、支払を認証するために多くの署名を求めることができる点に注目されたい。保証付き支払債務に関して、債務ブロックの債務形式属性は、「銀行」に設定される。
４．選択的に、売手１０８は、買手１０６の署名を調査することができる。通常、支払処理においては、買手銀行１０２が買手１０６の証明書を検証することは、重要な要件である。
５．適切な場合には、売手１０８は、売手私有データを添付した後に、メッセージに署名し、この署名付きメッセージを売手銀行１０４に送る。
６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、及び、売手１０８の証明書に示された認証及び権利を調査する。これらの調査が不成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサービス受領書を送る。
７．売手１０８が、売手公開データデータブロック又は売手私有データブロックで口座詳細を提供した場合、売手銀行１０４は、これらの口座詳細を検証することになる。売手銀行１０４は、売手銀行データブロックにおいてメッセージに口座詳細を添付することができる。売手銀行１０４は、取引の通貨に基づくコルレス銀行コードを添付することもできる。売手銀行１０４は、メッセージから売手私有データブロックを除去する。
８．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて、買手銀行１０２との精査応答取引を始めることを希望することができる。精査応答取引を選択した場合には、売手銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセージに署名する。
買手銀行１０２は、売手銀行１０４の信任状を調査し、依頼されている支払プロダクトを処理できるか否かを調査するとともに、買手銀行１０２の検証された信任状を含む売手への応答に署名することになる。
売手銀行１０４は、買手銀行１０２によって提示された信任状を検証することになる。検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサービス受領書を売手１０８に送る。
９．売手銀行１０４は、このメッセージに署名し、これを買手銀行１０２に送る。
１０．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送る。
売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送る。全ての受領書は、受領組織の署名付き証明書という新しい証拠を含む。
１１．買手銀行１０２は、口座関連詳細も検証する。この検証は同時に行うことができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は、否定的な支払指図受領書を送ることになる。口座関連詳細が同時に検証される場合、支払指図受領書は、サービス受領書と同じ文書で返送することができる。
１２．買手銀行１０２は、内部リスク方針に沿って、カード／法人に対して現在指定された上限額を調査することになる。買手銀行１０２が、債務責任を受諾し、債務を保証する場合には、肯定的な債務確認が買手銀行１０２から売手銀行１０４に送られる。買手銀行１０２が債務に同意しない場合には、否定的な債務確認応答が買手銀行１０２から売手銀行１０４に送られる。この応答は、翌日の営業日最終時刻めでに送られるべきであり、このようなリスクの同時的受諾をサポートする金融機関システムにおいて、サービス受領書と同時に送ることができる。
１３．支払実行時には、買手銀行１０２は、支払が行なわれたことを通知する支払確認書を買手１０６及び売手銀行１０４に送ることができる。決済システムが支払処置を成功裏に処理できない場合には、否定的な支払確認を発することができる。売手銀行１０４は、買手銀行１０２から資金が成功裏に受領されたことを確認するために、支払確認書を送ることができる。
【０１９３】
４コーナーモデルを使用した保証付き支払債務の取消
保証付き支払債務に関し、以下の４コーナーモデルプロセス又は売手による取消に対する積極的な同意を含む拘束のないプロセス使用して、支払の取消を行なうことができる。
１．買手１０６及び売手１０８は、売手のシステムを介して取消を進める。
２．購買時点において、売手１０８は、買手１０６が記入するための支払フォーマットを提供する。
３．買手１０６は、取消買手署名データブロックに署名する。（内部的又は売手のシステムを介して提供される設備による）買手の役割として、支払を取消すために多くの署名を求めることができるという点に注目されたい。よって、それ以降の署名は、上記のデータブロックに署名するとともに、選択的に、先行する買手署名ブロックに署名することができる。
４．選択的に、売手１０８は、買手１０６の署名を調査することができる。
５．売手１０８は、署名された文書を売手銀行１０４に送る。
６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、及び、売手１０８の証明書に示された認証及び権利を調査する。これら調査が不成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサービス受領書を送る。
７．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて、買手銀行１０２との精査応答取引を始めることを希望することができる。売手銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセージに署名することになる。買手銀行１０２は、売手銀行１０４の信任状を調査し、依頼されている支払プロダクトを処理できるか否かを調査する。売手銀行１０４は、買手銀行１０２によって提示された信任状を検証するであろう。検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサービス受領書を売手１０８に送る。
８．売手銀行１０４は、取消メッセージに署名し、これを買手銀行１０２に送る。
９．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支払依頼書に対しては、買手銀行１０２は、その取消依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４に対して否定的なサービス受領書を送る。これらの調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送ることになる。
売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送る。全ての受領書は、受領組織の署名付き証明書という新しい証拠を含む。
１０．次に、買手銀行１０２は、取消依頼を処理することになる。取消が成功裏に実行された場合には、買手銀行１０２は、肯定的な取消確認書を売手銀行１０４及び買手１０６に送る。取消が実行できない場合には、否定的な取消確認書が発せられることになる。取消依頼が同時に処理できる場合には、取消確認書は、サービス受領書でまかなうことができる。
取引が識別できない場合には、否定的な取消依頼文書が発せられることになる。
【０１９４】
買手対買手銀行モデルにおける保証付き支払債務取引
買手対買手銀行モデルにおける典型的な保証付き支払債務取引は、以下ように行われる。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する。
２．買手１０６は、支払債務を、直接、買手銀行１０２に依頼する。
３．買手１０６は、買手署名データブロックに署名する。買手１０６は、売手１０８の口座詳細情報の項目を含み、且つ、売手１０８の同意を得て初めて取消すことができる売手１０８に対する債務を買手１０６が引き受けることを示す売手公開データを記入することになる。保証付き支払債務に関し、債務要素の債務形式属性は、「銀行」に設定される。
買手の役割として、支払を認証するために多くの署名を求めることができるという点に注目されたい。よって、それ以降の署名は、上記のデータブロックのみに署名するか、又は、既に作成されている買手署名ブロックに追加して署名することができる。
４．買手１０６は、文書に署名し、これを買手銀行１０２に送る。
５．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付いた支払債務依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ていることを裏付ける必要がある。
これら調査が不成功に終わった場合には、買手銀行１０２は、否定的なサービス受領書を買手１０６に送る。これら調査が成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受領書を送ることになる。
支払債務に関し、買手銀行１０２は、買手１０６がその債務を引き受けたことを示す債務確認ブロックを提供することになる。金融機関が債務依頼を同時的に処理できる場合、債務確認は、サービス承認に含めることができる。また、債務確認も、翌日の就業日最終時刻までに提供されるべきである。
６．買手銀行１０２は、口座関連詳細を検証する。この検証は同時に行うことができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は、否定的な支払指図受領書を送る。口座関連詳細が同時に検証される場合には、支払指図受領書は、サービス受領書と同じ文書で返送することができる。
７．支払実行時には、買手銀行１０２は、支払が行なわれたことを通知する支払確認書を買手１０６に送る。決済システムが支払取引を成功裏に処理できなかった場合には、否定的な支払確認書を作成することができる。
通常、保証付き支払債務は、買手対買手銀行モデルを使用して取消すことはできない。
【０１９５】
条件付き支払
前にも説明したように、３つの条件付き支払プロダクトを形成するために、前述の３つの支払プロダクト全てに条件を付すことができる。  
【０１９６】
条件付き支払における条件の管理
条件及び債務の設定と管理との関係を規定するために、基本原則を本発明に適用することができる。好ましい実施形態においては、支払指図書に条件を使用するための以下の基本原則を適用する。
１．先ず、全ての条件は、主として、支払グループによって定義され公開される。好ましい条件コード群とその記述は、前に述べた通りである。
２．各条件は、信頼できるサービス提供者（ＴＳＳ）によって管理される。
３．第三者のサービス提供者は、条件を解除する、即ち、その条件が満たされたという記述にシステムトークンを使用して署名することになる。支払に付随する諸条件が解除されると、その指図が実行されることになる。
４．各条件は、売手１０８によって提示されるか、又は、買手１０６によって入力される。
５．この条件は、２つの部分を有する。即ち、（システムによって定義されるような）条件の包括的な記述、及び、特定取引に関する詳細である。
６．支払における各条件は、その条件が解除されたことを確認するために署名することになる機関である第三者のサービス提供者に割り振る必要がある。この機関は、企業体、その企業体内部のグループ、又は、個人とすることができる。ＴＳＰＳ組織は、その機関が署名することに対して適切な規制を実施するのが好ましい。ＴＰＳＰは、少なくとも電子メールアドレスによって識別されるべきである。
７．条件管理は、取引と独立した状態に維持される。
８．ＴＰＳＰ証明書の検証は、ＴＰＳＰからの応答を処理する過程に含む必要がある。ＴＰＳＰは、第三者機関によって証明書を発行してもらうことができる。
９．ＴＰＳＰは、自分の金融機関によって、金融機関により提出された証明書のステータス調査を行なえるようにすべきである。
１０．条件を解除する時、ＴＰＳＰによって添付文書を付けることができる。これは、買手銀行１０２によって処理されず、買手１０６のシステムに対する受領書に含まれるべきである。支払に適用する全ての条件（条件群）が解除されると、全ての添付文書が転送される。
１１．支払と条件との関係は、１対多数の関係である。１つの支払は、これが実行される前に満たされるべき多数の条件を持つことができる。それら条件は、単一の支払以外に適用されることはない。
１２．条件付き支払プロダクトの取消のための規則は、非条件付き支払の取消のための規則に従う。条件管理システムは、条件付き支払が取消されるか否かを知らされるべきである。ＴＰＳＰは、条件が取消されたことを示すメッセージを、金融機関から受け取ることになる。
【０１９７】
条件付き支払における条件のライフサイクル
好ましくは、条件のライフスタイルは以下のように決定される。
１．支払に付随する条件は、支払交渉の一部として、買手１０６と売手１０８との間で合意される。条件管理システム（ＴＳＳ）に受諾される前の各条件及び条件群のステータスは「依頼受」となる。
２．４コーナーモデルにおいては、各条件は、買手１０６によって署名され、売手１０８によって再署名される。買手対買手銀行モデルにおいては、買手１０６が、適用する条件の詳細を売手１０８に提供する。
３．売手銀行１０４は、文書の処理に先立って、各条件を局所的に記録する。
４．支払に付随する各条件は、買手銀行１０２の条件管理システムに記録される。
５．条件設定確認文書が作成され、売手銀行１０４に（又は、買手対買手銀行モデルにおいては買手１０６に）送られ、条件管理システム（ＴＳＳ）に各条件が存在することを確認する。この条件ステータスは、「未完了」である。
６．条件管理システムは、支払に付随する条件が存在することを第三者のサービス提供者（ＴＰＳＰ）に知らせる。
７．ＴＰＳＰは、条件管理システムに更新メッセージを送り、支払に付随する条件の中でそのＴＰＳＰに割り振られ終了した１つの条件のステータスを更新することができる。支払条件文書が、条件のステータスの変化を、その取引の全関係者に知らせるために使用される。
８．終了すると、支払に付随する条件のステータスは、「解除」となる。全ての条件が解除されると、条件群ステータスは、「解除済」となる。
９．ＴＰＳＰによる解除に関する条件に付けられたいずれの添付文書も、全ての条件が解除されてその支払指図が解かれるまでは、売手１０８に送られるべきではない。
１０．各条件は有効期間を有する。条件の有効期間が満了した場合には、条件群を解除することはできず、「有効期間満了」とマークされるべきである。支払条件文書は、条件の有効期間が満了したことを知らせるために、取引の各参加者に送られるべきである。
１１．条件付き支払が取消された場合には、支払に付随する全ての条件は取消されたとマークされる。ＴＰＳＰには、全てのステータスフィールドを「取消済」と設定した支払条件文書を使用して知らせる必要がある。
【０１９８】
条件付き支払における条件を規制する規則
更に、以下の規則が、本発明の条件付き債務の処理を規制するのが好ましい。
１．債務は、条件が付されている場合でも受諾しなくてはならない。
２．条件は、債務が成功裏に登録されるまで、登録されるべきではない。債務が拒否される場合には、否定的な条件設定確認書を買手１０６（買手対買手銀行モデルの場合）又は売手銀行１０４（４コーナーモデルの場合）に送らなくてはならない。
３．債券の所有権は、各条件が解除されるまでは移転できない。
４．各条件の有効期限が満了するか又は取消された場合には、債務管理機能に、その条件付き支払に対して保留された制限を解くことを知らせなくてはならない。
【０１９９】
条件付き支払要求メッセージフロー
好ましい実施形態においては、条件付き支払要求プロダクトのためのメッセージフローの多くは、条件付き支払要求指図書を図６のメッセージ１に示す支払要求指図書の代わりとする点を除けば、上述した支払要求プロダクトのためのメッセージフローと同じである。しかし、追加的な処理が、ある条件発生に対してこれを支払要求の実行を反映させるために付加される。好ましくは、各条件は、ＴＳＳによって設定され、支払が行われる前に複数のＴＰＳＰによってこれら条件が満たされなくてはならない。これらの追加的処理の一実施形態が、図８に示されている。 
【０２００】
条件詳細は、買手銀行１０２によってＴＳＳに供給される。この場合、トラスＴＳＳは、条件が何時満たされたかを買手銀行１０２に知らせるため、買手銀行１０２はそれに応答することができる。その代わりに、買手銀行１０２がＴＳＳとして機能することもできる。
図８に戻って説明すると、信頼できるサービス提供者は、支払が実行できる前に、第三者のサービス提供者が満す必要のある条件を示す条件通知メッセージ（上記表８参照）を作成する。次に、信頼できるサービス提供者は、条件通知メッセージに署名し、図８のメッセージ１に示すように、これを第三者のサービス提供者に送る。
【０２０１】
第三者のサービス提供者は、条件通知メッセージの容認可能性を検討し、メッセージ構文、証明書と署名の有効性、及び、署名者の認証を検証する。次に、第三者のサービス提供者は、これらの調査の結果によりサービス受領メッセージを作成する。次に、第三者のサービス提供者は、サービス受領書に署名し、図８のメッセージ２に示すように、信頼できるサービス提供者に送る。
第三者のサービス提供者は、条件履行プロセスにおける完了した段階について、信頼できるサービス提供者に知らせるために、条件更新メッセージを作成する。第三者のサービス提供者は、このメッセージに署名し、これを図８のメッセージ３に示すように、信頼できるサービス提供者に送る。各条件に対して複数の更新メッセージを送ることができるという点に注目すべきである。
【０２０２】
信頼できるサービス提供組織は、条件更新メッセージの容認可能性を検討し、メッセージ構文、証明書と署名の有効性、及び、署名者の認証を検証する。次に、信頼できるサービス提供者は、これらの調査の結果により、サービス受領書を作成する（上記表９参照）。次に、信頼できるサービス提供者は、サービス受領書に署名し、図８のメッセージ４に示すように、第三者のサービス提供者に送る。
第三者のサービス提供者は、条件プロセスの履行について信頼できるサービス提供者に知らせるために、条件告知メッセージを作成する（上記した表１６を参照のこと）。このメッセージは、肯定的なメッセージにも、否定的なメッセージにもすることができる。第三者のサービス提供者は、このメッセージに署名し、図８のメッセージ５に示すように、これを信頼できるサービス提供者に送る。
【０２０３】
信頼できるサービス提供組織は、条件告知メッセージの容認可能性を検討し、メッセージ構文、証明書と署名の有効性、署名者の認証を検証する。次に、信頼できるサービス提供者は、これらの調査の結果により、サービス受領書を作成する（上記表９参照）。信頼できるサービス提供組織は、サービス受領書に署名し、図８のメッセージ６に示すように、これを第三者のサービス提供者に送る。
【０２０４】
条件付き支払債務メッセージフロー
好ましい実施形態においては、条件付き支払債務プロダクトのためのメッセージフローの多くは、条件付き支払債務指図書を図７のメッセージ１に示した支払債務指図書の代わりとする点を除けば、上述した支払債務のためのメッセージフローと同じである。しかし、追加的な処理が、ある条件の発生に対しそれを支払要求の実行に反映するために付加される。好ましくは、各条件は、信頼できるサービス提供者によって設定され、支払が行われる前に複数の第三者のサービス提供者によって満たされなくてはならない。好ましい実施形態においては、条件プロセスは、図８に関連して説明した処理と同じものとすることができる。
【０２０５】
保証付き／条件付き支払債務メッセージフロー
好ましい実施形態においては、保証付き／条件付き支払債務プロダクトは、保証付き／支払債務指図書を図７のメッセージ１に示した条件付き支払債務指図書の代わりとするとともに、保証付き／条件付き支払債務受諾確認メッセージを条件付き支払債務受諾確認書の代わりとする点を除けば、上述した条件付き支払債務に関連して説明したメッセージフローと同じものとすることができる。
これまでに詳しく説明したように、メッセージフォーマットは、決済システムはグローバル的な性格により、国境を超えた互換性を確保するために、標準を公開するのを固守するのが好ましい。例えば、異なる言語に適応させるために、マルチバイト文字群を使用するのが好ましい。
【０２０６】
また、好ましくは、支払取引には、決済システムの各関係者によって、デートスタンプ及びタイムスタンプが付される。好ましい実施形態においては、タイムスタンプは、ユニバーサルタイムコード（Ｕ．Ｔ．Ｃ．）フォーマットに基づき第三者の信頼できるタイムサーバによって提供される。
好ましい実施形態において、支払関連の全てのメッセージは、信頼される認証局によって発行される証明書を使用することによって保証される。好ましい実施形態において、これら証明書は、メッセージにデジタル署名するために、メッセージ認証、完全性、及び非否認性を提供するために使用される。
好ましい実施形態においては、決済システムの各関係者の間で交換される全ての情報の機密性が維持され、情報は不正なアクセスから保護される。ＳＳＬｖ３／ＴＬＳを使用して、少なくとも１２８ビット強度の暗号化を採用するのが好ましい。
【０２０７】
好ましい実施形態においては、本決済システムは、包括的なエラー処理を提供し、好ましくは、このエラー処理は、以下の範囲のエラーをカバーする。即ち、メッセージ構文、メッセージの署名検証／認証、適正でない銀行識別コード等のメッセージデータ、及び、支払認証を含む（但し、これに限定されない）メッセージ関連のエラー；設定条件を満足できないことを含む（但し、これに限定されない）メッセージ固有のエラー；及び、伝送の問題及び時間切れの問題を含む（ただし、これに限定されない）決済システム基盤構造のエラーを包含する。
好ましい実施形態において、全ての支払開始メッセージは、等羃である。例えば、支払要求指図書を送信したが、指定された制限時間内にサービス受領書が受信されない場合には、このメッセージの対象とする受信者にこの依頼メッセージについて２度同じ行動をさせることなく、その支払要求指図書を再び送ることができる。
また、本発明のシステムは、上述したように受領書の自動処理を含むのが好ましいが、各参加者は、従来の現金管理システム；ウェブを利用した銀行業務サービス；音声、ファックス、及びその他の電話サービス；又はＳＭＳ、ＷＡＰ，及びその他の移動体サービス；等の多くのチャンネルを介しての受領書の提供を選択することもできる。
以上、本発明を具体的な実施形態に関連して説明したが、当業者にとって、以上の説明に照らして、数多くの置換、変更、及び変形が想定されるのは明らかである。
【図１】
2011118898.tif 000101
【図２】
2011118898.tif 000102
【図３】
2011118898.tif 000103
【図４】
2011118898.tif 000104
【図５】
2011118898.tif 000105
【図６】
2011118898.tif 000106
【図７】
2011118898.tif 000107
【図８】
2011118898.tif 000108
【手続補正書】
【提出日】平成22年12月22日(2010.12.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１参加者に関連する第１取引調整装置を有する第１サーバ及び第２参加者に関連する第２取引調整装置を有する第２サーバを含み、前記第２取引調整装置は前記第１取引調整装置と通信可能に結合している通信ネットワークにおける、前記第１参加者、前記第２参加者、前記第１参加者の顧客（ＣＯＦＰ）、前記第２参加者の顧客（ＣＯＳＰ）、及びルートエンティティを含み、前記ルートエンティティは前記第１参加者及び前記第２参加者から分離して配置されており、前記第１参加者及び前記第２参加者にデジタル証明書を発行するルート認証局を含むものである４コーナー信頼モデルの関係における通信ネットワーク内の電子商取引において決済サービスを提供する方法であって、
前記ＣＯＦＰが、支払期日を指定する支払要求命令の買手部分を実行し、前記ＣＯＦＰの秘密鍵で前記支払要求命令をデジタル署名し、前記通信ネットワークを介して前記支払要求命令を前記ＣＯＳＰに電子的に送信する段階と、
前記ＣＯＳＰが、前記ＣＯＦＰの前記秘密鍵でデジタル署名された前記支払要求命令を受信し、前記要求命令の売手部分を実行し、前記ＣＯＳＰの秘密鍵で前記支払要求命令をデジタル署名し、前記通信ネットワークを介して前記支払要求命令を前記第２参加者に電子的に送信する段階と、
前記第２参加者が、前記ＣＯＦＰの前記秘密鍵及び前記ＣＯＳＰの前記秘密鍵でデジタル署名された前記支払要求命令を受信し、前記支払要求命令の参加者部分を実行し、前記第２参加者の秘密鍵で前記支払要求命令をデジタル署名する段階と、
前記支払要求命令を前記第２参加者が関連する前記第２取引調整装置から前記第１参加者が関連する前記第１取引調整装置に前記通信ネットワークを介して電子的に送信する段階と、を含み、
前記支払要求命令は、前記支払要求命令が前記支払期日に実行されるような前記第１参加者に対する命令を含み、
前記第１参加者の前記秘密鍵及び前記第２参加者の前記秘密鍵の少なくとも１つが、前記支払要求命令の内容に対するエンティティの契約上の責任の証拠として前記ルートエンティティに要求されるデジタル署名を生成するために使用されることを特徴とする方法。
【請求項２】
前記支払要求命令は、支払債務命令であることを特徴とする請求項１に記載の方法。
【請求項３】
前記支払要求命令は、条件付き支払要求命令であることを特徴とする請求項１に記載の方法。
【請求項４】
前記支払要求命令は、条件付き支払債務命令であることを特徴とする請求項１に記載の方法。
【請求項５】
前記支払要求命令は、保証付き支払債務命令であることを特徴とする請求項１に記載の方法。
【請求項６】
前記支払要求命令は、保証付き／条件付き支払債務命令であることを特徴とする請求項１に記載の方法。
【請求項７】
前記第１顧客は、前記支払要求命令に関する役割及び責任を規定する前記第１参加者との法的契約を履行しているものであることを特徴とする請求項１に記載の方法。
【請求項８】
前記第２顧客は、前記支払要求命令に関する役割及び責任を規定する第２参加者との法的契約を履行しているものであることを特徴とする請求項１に記載の方法。
【請求項９】
前記第１参加者が金融機関であり、前記金融機関が前記支払期日に前記支払要求命令を実行する請求項１に記載の方法。
【請求項１０】
前記選択された支払要求ドキュメントは、支払債務であることを特徴とする請求項９に記載の方法。
【請求項１１】
前記選択された支払要求ドキュメントは、条件付き支払要求であることを特徴とする請求項９に記載の方法。
【請求項１２】
前記選択された支払要求ドキュメントは、条件付き支払債務であることを特徴とする請求項９に記載の方法。
【請求項１３】
前記選択された支払要求ドキュメントは、保証付き支払債務であることを特徴とする請求項９に記載の方法。
【請求項１４】
前記選択された支払要求ドキュメントは、保証付き／条件付き支払債務であることを特徴とする請求項９に記載の方法。
【請求項１５】
前記支払要求ドキュメントは、譲渡可能であることを特徴とする請求項９に記載の方法。