JP2003521763A - 電子商取引における決済サービスを提供するためのシステム及び方法 - Google Patents

Abstract

(57)【要約】 複数の決済サービスを提供し電子商取引を促進させるためのシステム及び方法が開示される。一実施形態において、これらサービスは、オンライン取引を行う買手１０６及び売手１０８を含む４コーナーモデルと関連して提供される。買手は、第１金融機関１０２の顧客である。第１金融機関は、買手の認証局としての機能を果たし、秘密鍵と第１金融機関が署名したデジタル証明書とを含むハードウェアのトークンを売手に発行する。実行に際し、買手は、自分の秘密鍵を使用して、第１金融機関１０２又は第２金融機関１０４に送る支払指図書に署名する。この指図メッセージは、売手又は第２金融機関を介して間接的に第１の金融機関に転送される。本システムによってサポートされる支払指図として、支払要求、支払債務、保証付き支払債務、及び条件付き支払を挙げることができる。

Description

【発明の詳細な説明】

【０００１】 (関連出願） 本出願は、「決済サービスのためのシステム及び方法」と題する１９９９年９
月２４日出願の米国仮特許出願番号第６０／１５５，８４１号に基づく優先権を
主張するものである。尚、この米国仮特許出願を本出願の参考文献とする。

【０００２】 （技術分野） 本発明は、全体的には、公開鍵暗号基盤を介してサービスを提供することによ
り電子商取引を促進する分野に関する。

【０００３】 （背景技術） 電子商取引の世界では、契約当事者間の関係構築についての新たな課題が生じ
ている。これら課題の１つは、取引当事者が互いに会ったり話し合ったりするこ
とができず、さもなければ互いの身元及び行為権限を容易には確認できないとい
うことに起因する。 この問題に関する１つの対処方法は、送信メッセージに署名するための秘密鍵
を取引当事者の各々が提供し合うことである。署名する側が、彼の秘密鍵で署名
したメッセージを解読する関連の公開鍵を提供することによって、受信側は送信
者の身元を確認することが可能となる。 しかし、送信者の公開鍵が、事前に受信者に知らされていないことがある。そ
の場合には、送信者は、認証局によって発行されたデジタル証明書を、彼の署名
入りメッセージとともに送信することができる。この証明書自体が、特定の公開
鍵が送信者の公開鍵であることを証明する（認証局の秘密鍵で署名された）署名
付き電子文書となる。

【０００４】 また、時には、受信者が認証局の公開鍵に不案内であったり、証明書が現在も
有効であるかどうか識別できなかったりすることもある。この場合には、受信者
は、自身が信頼する実体（実体）によってその証明書の信憑性及び有効性を調査
することを望むであろう。証明書のステータスを調査するための公知プロトコル
の１つに、オンライン証明書ステータスプロトコル（ＯＣＳＰ）がある。 電子商取引が直面するもう１つの課題は、決済及び決済システムの確立に関係
する。時として、購入者は、販売業者にクレジットカード番号を送信することに
よって、インターネットを介して購入した商品の代金を支払う。この方法は、そ
の手法に関連した機密上のリスク等の難点があり、対消費者取引でさえ不都合が
多く、まして対事業所取引に適応するものではない。

【０００５】 また、これまでに幾つかの電子決済システムが提案されおり、デジタル証明書
を用いて支払人の身元を認証する方式もその１つである。しかしながら、これら
のシステムは、今日の電子商取引、特に、対事業所電子商取引に必要とされる一
連の決済証書を提供するものではなく、電子決済を確実に且つ検証し得るに足る
基盤を提供できない場合が多い。

【０００６】 （発明の概要） 電子商取引を促進する複数の決済システムを提供するためのシステム及び方法
が開示される。好ましい実施形態において、これらサービスは、４コーナー信頼
モデルとの関連において提供される。４コーナーモデルは、オンライン取引に参
加する、加入顧客（Ｓｕｂｓｃｒｉｂｉｎｇ Ｃｕｓｔｏｍｅｒ）とも呼ばれる
買手及び信頼顧客（Ｒｅｌｙｉｎｇ Ｃｕｓｔｏｍｅｒ）とも呼ばれる売手を含
む。買手は、発行参加者（Ｉｓｓｕｉｎｇ Ｐａｒｔｉｃｉｐａｎｔ）と呼ばれ
る第１の金融機関の顧客である。発行参加者は、買手のための認証局の役割を果
たし、秘密鍵と発行参加者によって署名されたデジタル証明書とを含むハードウ
ェアのトークンを買手に発行する。売手は、信頼参加者と呼ばれる第２の金融機
関の顧客である。信頼参加者は、売手のための認証局の役割を果たし、秘密鍵と
信頼参加者によって署名されたデジタル証明書とを含むハードウェアのトークン
を売手に発行する。また、このシステムには、発行参加者及び信頼参加者に対し
てデジタル証明書を発行するルート認証局も含まれる。

【０００７】 ４コーナーモデルの１つの利点は、売手と買手との間の信頼が、各当事者が同
じ認証局を使って互いのデジタル証明書又は身元を検証することによって決定さ
れるのではない点にある。そうではなくて、売手及び買手は、最初に各自の取引
銀行にこの検証を求める。次に、売手と買手の取引銀行は、売手及び買手の相互
の身元と両者が交換するメッセージの完全性とを高い信頼性を持って検証するた
めに必要な橋渡しをするようルート実体に求める。

【０００８】 本システム及び方法は、この信頼モデルを活用して買手及び売手に対する決済
サービス機能を向上する。４コーナー信頼モデルと、両当事者及びそれぞれの取
引銀行の間で既に確立されている銀行取引関係とによって、これら両当事者は、
オンラインでの購買又は売買を完結し、それと同時に、確実で効率が良く且つ場
合によっては保証付きの支払の取り決めをすることが可能となる。更に、本シス
テムにおいて、デジタル署名した支払指図書を使用することにより、認証、メッ
セージの完全性、否認防止性、及び機密性を確保することができる。

【０００９】 好ましい実施形態において、本システムにおける支払メッセージングは、買手
から売手、売手の取引銀行、買手の取引銀行へと進められる。従って、例えば、
買手が支払指図書に署名してこれを売手に送ると、売手は、それを売手の取引銀
行に転送し、売手の取引銀行がそれを最終的に買手の取引銀行に配信することに
より買手の取引銀行が支払を行う。 両当事者は、各々の取引銀行との間で決済認可、作業手順、及び清算指図を既
に確立しており、これによって両当事者が個別のオフライン手続きではなく取引
と並行したオンライン決済を開始できる状態にあるということもあり、本システ
ム及び方法は効果的に機能する。銀行での標準化された決済処理手順により、効
率は更に向上する。

【００１０】 本システム及び方法は、買手に多くの利点を与える。特に、本システム及び方
法によれば、買手は、様々な決済方式を選択、利用して売手の要求を満たすこと
ができる。また、買手は、よりタイミング良くしかも更に多くの情報を持って資
金繰りを行うことができる。更に、本システム及び方法によれば、買手は、条件
付き支払を利用することにより、売買に内在するリスクを補うことができる。更
に、買手には、支払と購入とが１つのプロセスにまとめられたような効率的な仕
事の流れが約束される。本システム及び方法を長年使用されている既存システム
と調和させることにより、取引全体を完全に電子処理化することが可能となる。

【００１１】 更に、本システム及び方法は、売手にも多くの利点を与える。特に、本システ
ム及び方法によれば、売手は、大切な得意先に合わせた支払条件を提案すること
ができる。また、保証付き支払によって、売手は、自身の信用取引リスクを軽減
することもできる。加えて、本システム及び方法によれば、売手は、よりタイミ
ング良くしかも更に多くの情報を持って資金繰りを行うことができる。更に、売
手にも、支払と購入とが１つのプロセスにまとめられたような効率的な仕事の流
れが約束される。また、売手が支払債券を所有している場合には、売手は彼の取
引銀行に債券を割引して売手に資金融資するよう依頼することができる。本シス
テム及び方法を長年使用されている既存システムと調和させることにより、取引
全体を完全に電子処理化することが可能となる。

【００１２】 好ましい実施形態において、本システム及び方法により、複数の決済手段が円
滑に活用される。これら決済手段には、支払要求、支払債務、保証付き支払債務
、及び条件付き支払が含まれる。これらの決済手段の各々については、以下でよ
り詳細に説明する。 好ましい実施形態において、本システムにより、売買可能な電子決済手段の作
成及び譲渡が促進される。例えば、本システムは、好ましくは流通市場で売却で
きる支払債券を含む。これら支払債券の所有者の変更は、好ましくは所有者登録
サービスによって行うことができる。 上述した本発明の概要は、以下の詳細な説明及び添付図面を併せて把握するこ
とによって一層良く理解されると考える。

【００１３】 （発明を実施するための最良の形態）システムアーキテクチャと技術特性 本明細書は、各金融機関がそれぞれの顧客に対して決済サービスを安全に提供
できるようにするシステムに関する。好ましい実施形態において、これらのサー
ビスは、４コーナー信頼モデルとの関連において提供することができる。本発明
に用いられる４コーナーモデルの好ましい実施形態を図１に示す。

【００１４】 図１に示すように、４コーナーモデルは、第１の金融機関１０２と第２の金融
機関１０４とを含む。第１金融機関１０２は、本システムへの参加者であり、後
述するように、その顧客に対してデジタル証明書を発行するということから、「
発行参加者」と呼ばれる。第２金融機関１０４は、本システムへの参加者であり
、後述するように、第２金融機関１０４によって、その顧客が発行参加者１０２
及び発行参加者１０２の顧客によって作成された表示に頼るということから、「
信頼参加者」と呼ばれる。参加者１０２、１０４とは、典型的には銀行又はその
他の金融機関である。

【００１５】 図１には、第１の顧客１０６及び第２の顧客１０８も示されている。好ましく
は、第１顧客１０６及び第２顧客１０８は、それぞれ、発行参加者１０２の顧客
及び信頼参加者１０４の顧客である。 第１顧客１０６は、参加者１０２によって提供されるサービスに加入している
ということから、「加入顧客」と呼ばれることもある。第１顧客１０６は、４コ
ーナーモデルでの取引において典型的には買手の役割を果たすということから、
「買手」と呼ばれることもある。

【００１６】 第２顧客１０８は、発行参加者１０２及び加入顧客１０６の双方によって作
られる表示に頼るということから、「信頼顧客」と呼ばれることがある。また、
第２顧客１０８は、４コーナーモデルでの取引において典型的には売手の役割を
果たすということから、「売手」と呼ばれることもある。以下の記述においては
、主として、売手１０６及び買手１０８として説明するが、その代わりに、特定
の取引において第１顧客１０６及び第２顧客１０８が異なる役割を果たすことも
あるということは理解されるべきである。例えば、第１顧客１０６が第２顧客１
０８に貸付金を返済する借手となる場合もあろう。

【００１７】 図１にはルート実体１１０も示されている。ルート実体１１０は、典型的には
、電子商取引及び電子通信を促進するための一連の共通運用ルールを設定し実施
する組織である。ルート実体１１０は、これらの運用ルールに従うことに合意し
た複数の銀行及び／又はその他の金融機関によって共同で所有される。このよう
なルート実体の一例は、「証明に関するサービス及びその他のサービスを提供す
るためのシステム及び方法」と題する２０００年２月１１日に出願され審査過程
にある米国特許出願第０９／５０２，４５０号に記載されている。尚、この出願
を本明細書の参考文献とされたい。

【００１８】 図２は、好ましくは４コーナーモデルの各実体に設けられる構成要素を示すブ
ロック図である。図２に示すように、好ましくは、参加者１０２、１０４及びル
ート実体１１０の各々は、本システムによって提供されるサービスに関係する全
ての実体相互のメッセージを送受信するためのゲートウェイとしの機能を果たす
取引調整装置２０２を備えている。取引調整装置２０２は、発行参加者１０２の
オンラインサービス及び信頼参加者１０４のオンラインサービスに対する単一の
インターフェースを備えており、取引調整装置２０２と４コーナーモデルの他の
実体との間の安全な電子通信の確保に必要な防護対策を行なう。本システムの使
用に適した取引調整装置２０２の好ましい実施形態は、「証明書検証等のサービ
スのためのシステム及び方法」と題する本件特許と同日に出願され審査過程にあ
る米国特許出願第 ／ 号に記載されている。尚、この出願を本明細書の参
考文献とされたい。

【００１９】 好ましくは、参加者１０２、１０４及びルート実体１１０の各々は、オンライ
ン証明書ステータスプロトコル（ＯＣＳＰ）応答装置２０４及びハードウェア機
密保護モジュール（ＨＳＭ）２０６を更に備える。ハードウェア機密保護モジュ
ール（即ち、ハードウェア暗号モジュール）２０６は、メッセージに署名すると
ともに、メッセージに付けられた署名を検証するよう構成される。 また、好ましくは、各参加者１０２、１０４及びルート実体１１０は、（参加
者１０２、１０４の場合、銀行の支払請求アプリケーション２１０に接続された
）支払請求データのデータベース２０８と、生の取引記録２１２と、顧客データ
のデータベース２１４と、（顧客データデータベース２１４に接続された）リス
クマネージャ２１６と、ハードウェア機密保護モジュール２１８とを備えており
、これらの各々は、取引調整装置２０２に接続されている。

【００２０】 更に、図２に示すように、信頼顧客１０８は、インターネットを介して情報を
送受信するように構成されたウェブサーバを備えるのが好ましい。また、信頼顧
客１０８は、信頼参加者１０４と通信するための銀行インターフェース２２２を
備えるのが好ましい。銀行インターフェース２２２の好ましい一実施形態（及び
、信頼顧客１０８が備えるのが好ましいその他の構成要素）は、「証明書関連等
のサービスに関する売手の利用を促進するためのシステム及び方法」と題する本
件特許と同日に出願され審査過程の米国特許出願第 ／ 号に記載されており
、この出願を本明細書の参考文献とされたい。信頼顧客１０８は、システムメッ
セージに署名するとともに、システムメッセージを検証するためのハードウェア
暗号モジュール２３０を更に備えるのが好ましい。 また、図２に示すように、加入顧客１０６は、インターネットを閲覧するため
のウェブブラウザ２２４と、後述するように、メッセージに署名するためのスマ
ートカード２２６（及び、関連する読取装置）とを備えるのが好ましい。

【００２１】 好ましい実施形態において、各システム実体は、認証を容易にするために、２
つのデジタル証明書、即ち、身元証明書（場合によっては、保証証明書と呼ばれ
る）及びユーティリティ証明書（及び、対応する秘密鍵）を備えている。更に、
好ましい実施形態においては、各取引調整装置２０２は、それ自身の身元証明書
、ユーティリティ証明書、及び、対応する秘密鍵を備えるのが好ましい。

【００２２】 この身元証明用秘密鍵は、電子商取引のコンテンツに対する実体の契約におけ
る責任の証拠としてルート実体１１０から要求されるデジタル署名を作成するた
めに使用される。この鍵を使用してオペレーションをサポートするためには、証
明書チェーンが必要である。例えば、「証明書検証等のサービスのためのシステ
ム及び方法」と題する本件特許と同日に出願され審査過程の米国特許出願第 ／ 号に記載されているように、身元証明書のステータスは公認された実体から
入手することができる。尚、この出願を本明細書の参考文献とされたい。

【００２３】 特別な取引上の機密保護を行うことができるデジタル署名を作成するために、
ユーティリティ秘密鍵が使用される。通常、ユーティリティ証明書は、セキュア
ソケット層（ＳＳＬ）セッション（暗号化機能）をサポートするとともに、Ｓ／
ＭＩＭＥ（セキュア／多目的インターネットメール拡張仕様）のメッセージに署
名するために使用され、更に、その他のユーティリティアプリケーションのため
にも使用される。また、証明書チェーンは、ユーティリティ鍵を使用してオペレ
ーションをサポートする上でも必要となる。しかし、ユーティリティ証明書のス
テータスは、依頼者に公開されていない場合もある。本明細書の全体を通して、
「証明書」という用語は、他に特記しない限り、身元証明書のことをいう。

【００２４】 好ましい実施形態において、加入顧客１０６のデジタル証明書及びこれに対応
する秘密鍵は、発行参加者１０２によって加入顧客１０６に提供される。発行参
加者１０２は、少なくとも加入顧客１０６の身元証明書に対応する秘密鍵を含む
スマートカード又はその他の適切な証書を、加入顧客１０６に発行するのが好ま
しい。必要であれば、スマートカードは、加入顧客の身元証明書を含むこともで
きる。スマートカードの好ましい仕様、その製造元、及びそのコンテンツは、「
署名インターフェース要件、スマートカード順守要件、保証サービス、機能要件
、及び追加的開示」と題する２０００年８月１４日に出願された米国仮特許出願
第 ／ 号に記載されている。尚、この出願を本明細書の参考文献とされたい
。

【００２５】 好ましい実施形態において、本システムは、少なくとも、ハイパーテキスト伝
送プロトコル（ＨＴＴＰ）、多目的インターネットメール拡張仕様（ＭＩＭＥ）
、シンプルメール伝送プロトコル（ＳＭＴＰ）、及びインターネットＯＲＢ間プ
ロトコル等のインターネット伝送プロトコルをサポートするのが好ましい。更に
、本システムは、少なくとも、セキュアソケット層（ＳＳＬ）、セキュア／多目
的インターネットメール拡張仕様（Ｓ／ＭＩＭＥ）、トランスポート層セキュリ
ティ（ＴＬＳ）、及びセキュアインターネットＯＲＢ間プロトコル（Ｓ−ＩＩＯ
Ｐ）等のインターネット伝送機密保護プロトコル 好ましい実施形態において、本システムにおける支払手段は、秘密の金融情報
を保護するために暗号化される。全ての参加者間で交換される情報は機密性を有
するものであるため、高度な暗号化が好ましい。好ましくは、この暗号化は、伝
送レベルの暗号化に加えて、メッセージレベルの暗号化とすべきである。

【００２６】 自動処理を可能にするために、本システムにおける支払メッセージは、本シス
テム及び本システムに外付けされる従来システムのような他のシステムによって
提供される証明書管理サービス（例えば、証明書検証）による高速オンライン処
理を最適化するように構成するのが好ましい。本システムに組み込むものとして
、一連のＭＩＭＥベースのメッセージを含むことができる。他のシステムに組み
込むものとして、ＥＤＩＦＡＣＴ、ＸＭＬ／ＢｉｚＴａｌｋ、及びＥｎｔｅｒｐ
ｒｉｓｅ Ｊａｖａ Ｂｅａｎｓを含むことができる。これらは、既存の支払メ
ッセージフォーマットにそのまま変換可能であるという点で好ましい。

【００２７】 好ましくは、本システムの決済サービスメッセージは、それらの身元証明書に
対応した秘密鍵を用いて各システム実体によって署名される。決済サービスメッ
セージは、証明書管理サービスメッセージのコンテンツに同封されるか又は参照
される、或いは、同封且つ参照される。

【００２８】 以下で説明する支払メッセージの多くは、完成されたメッセージが最終受信者
に送信される前に、２人以上の当事者による貢献を必要とする。従って、本シス
テムにおけるメッセージは、各署名当事者及び最終受信者の否認防止機能を保持
した状態で、原本のコンテンツに署名付きの追加を加えることをサポートするよ
うに構成されるのが好ましい。 まさに下位層側において、通常、買手１０６は、本システムに関係するアプリ
ケーションをサポートするいくらかの方式に加えて、Ｎｅｔｓｃａｐｅ Ｎａｖ
ｉｇａｔｏｒ（商標）又はＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（商標）等の標
準的インターネットブラウザを使用することができる。上記方式として、ブラウ
ザプラグイン、ジャバアプレット方式等の技術を挙げることができる。拡張マー
クアップ言語（ＸＭＬ）等の技術オプションも使用することができる。

【００２９】 実施可能なものとして、買手１０６と売手１０８との間の取引条件に関する交
渉結果の情報を持つ売手側サーバから、ＨＴＭＬページをブラウザ２２４にロー
ドすることが考えられる。署名付きジャバアプレットをダウンロードしたＨＴＭ
Ｌページの一部として使用すれば、スマートカード２２６を使用して情報を構成
するとともにデジタル署名することができる。次に、作成したメッセージは、更
に処理するために、サーバに転送することができる。この代わりとして実施でき
る手法としては、決済サービスメッセージを構成し署名するプラグイン又はヘル
パーアプリケーションを用いる方法がある。これらを実施するための好ましい実
施形態は、「署名インターフェース要件、スマートカード順守要件、保証サービ
ス、機能要件、及び追加的開示」と題する２０００年８月１４日に出願された米
国仮特許出願第 ／ 号に記載されている。尚、この出願を本明細書の参考文
献とされたい。

【００３０】 この同期通信モデルに加え、買手１０６と売手１０８との間で情報交換する他
のモデルもサポートすることができる。例えば、非同期電子メール交換も本シス
テムでサポートできる。 典型的には、売手は、標準ＨＴＴＰウェブサーバ（例えば、Ａｐａｃｈｅ）を
使ってＨＴＭＬページを呼び出し、アプリケーションサーバを作動して買手に特
定の取引機能（例えば、ショッピングシステム）を提供する。例えば「証明書検
証等のサービスのためのシステム及び方法」と題する本特許と同日に出願され審
査中の米国特許出願第 ／ 号に記載された検証及び保証サービスを含むシス
テムサービスの利用を促進にする他のソフトウェア構成要素が、このアプリケー
ションと統合される。尚、この出願を本明細書の参考文献とされたい。また、こ
の出願には、決済サービスについても記載されている。 好ましい実施形態において、上記統合は、「証明書関連等のサービスに関する
売手の利用を促進するためのシステム及び方法」と題する本件特許と同日に出願
され審査過程の米国特許出願第 ／ 号に記載された能動的統合である。尚、
この出願を本明細書の参考文献とされたい。買手１０６に提示するための支払手
段に関する売手１０８の決定を行ないそれにより購買条件を設定するのは、売手
のアプリケーションの不可欠な役割である。

【００３１】 一例として、売手１０８のアプリケーションは、買手１０６の証明書を使って
顧客を識別し、その顧客に特別の条件を適用することができる。更に、決済サー
ビスの利用方法は、対象商品、及び、顧客の売手１０８との取引履歴に応じて変
えることができる。例えば、特定上限を超える注文に関しては、売手１０８は、
銀行が提供する保証付き支払債務を受け入れることのみに同意することかできる
。これとは対照的に、特定閾値を下回る場合には、各支払要求を受け入れるよう
決定することができる。更に、売手は、ダンアンドブラッドストリート社の評価
サービスのような第三者サービスを利用して、特定の取引についてどの支払手段
が受け入れ可能かを判断することもできる。

【００３２】 売手１０８側で実行しているアプリケーションは、例えば、「証明書関連等の
サービスに関する売手の利用を促進するためのシステム及び方法」と題する本件
特許と同日に出願され審査過程の米国特許出願第 ／ 号に記載されたように
、メッセージに署名するとともに、メッセージに付けられた署名を検証したり証
明書のステータスを調査したりして、本明細書に述べられている決済サービスを
提供するよう構成するのが好ましい。尚、この出願を本明細書の参考文献とされ
たい。 また、ウェブを基盤とした実施に加え、対サーバ通信又は自動電子メール処理
ツールも売手側で使用することができる。

【００３３】 本システムにおける各参加者は、状況に応じて、信頼参加者になったり発行参
加者になったりする。従って、例えば、第１の参加者の顧客が特定取引において
買手となり、第２の参加者の顧客がその取引における売手となる場合には、第１
参加者は、その取引に関して発行参加者となり、第２参加者は、その取引に関し
て信頼参加者となる。各参加者は、その顧客に対する認証局の機能を果たしたり
（証明書の発行、更新、及び取消のサポート）、その顧客に検証サービス及び保
証サービスを提供したり、他のシステム参加者からのＯＣＳＰ依頼に応答したり
（証明書検証のサポート）、その顧客に対して決済サービス（例えば、本明細書
で説明する決済サービス）を提供したりすることを含む数多くのサービスを提供
するのが好ましい。

【００３４】 好ましい実施形態において、取引調整装置２０２は、参加者が提供する証明書
に基づくサービスの主要インターフェースとなる。「証明書検証等のサービスの
ためのシステム及び方法」と題する本件特許と同日に出願され審査過程にある米
国特許出願第 ／ 号に記載されたように、取引調整装置２０２は、メッセー
ジ確認、ロギング、請求書発送、及び証明書に基づく全てのサービスに関する認
可等のシステム機能を円滑化する。尚、上記出願を本明細書の参考文献とされた
い。

【００３５】 各顧客証明書は、発行参加者１０２及び信頼参加者１０４側にあるエンドユー
ザ認可システムに関連付けられるのが好ましい。認可システムの構成要素は、各
参加者によって決定されるが、典型的には、取引形式に関する情報、額的上限、
取扱手数料、各顧客証明書に許された承認を含む。好ましい認可手法は、「認可
／認証認定サービス及び認可／認証認定サービス提案」と題する本件特許と同日
に出願され審査過程にある米国特許出願第 ／ 号に記載されている。尚、こ
の出願を本明細書の参考文献とされたい。

【００３６】 各顧客証明書は、買手銀行１０２及び売手銀行１０４側にある決済テンプレー
トシステムに関連付けられるのが好ましい。決済テンプレートには、買手１０６
、売手１０８、及び、売手銀行１０４のためのディフォルト形式の支払指図書を
記憶しており、決済認可メッセージを実行するために買手銀行１０２によって使
用される。決済認可メッセージの設計によって、その指図の一部を、正式に認可
された買手又は売手エンドユーザが優先させることが可能となる。 好ましい実施形態において、各銀行は、自由裁量により、それぞれの顧客に付
加的機能を提供することができる。この付加的機能としては、買手企業に対する
上限の運用、又は、特定顧客による決済サービス利用に関する一括管理情報の提
供等を挙げることができる。

【００３７】 好ましい実施形態において、本明細書に開示した決済サービスでは、実際の支
払のために既存の銀行ネットワークが使用される。それら銀行ネットワークは、
将来の期限付き支払のための支払入庫システムのような銀行で利用可能な既存機
能を使用することもできる。これら既存システムへの接続の一部は、リアルタイ
ムでオンラインであるのが好ましい。これらシステムには、支払要求を作成し、
保管し、発信するための支払開始システムに対するリアルタイムでオンラインの
インターフェース、昼間及び夜間の上限を監視する支払リスクシステムに対する
リアルタイムでオンラインのインターフェース、支払開始受領を発生するための
リアルタイムでオンラインの構成要素、デジタル署名及び身元保証を処理するシ
ステム身元サーバに対するリアルタイムでオンラインのインターフェース、アプ
リケーション認可システムに対するリアルタイムでオンラインのインターフェー
ス、及び、買手銀行１０２が支払要求を受け取る前に、買手１０６が送った支払
要求取消依頼の倉庫（支払取消リスト）に対するリアルタイムでオンラインのイ
ンターフェースが含まれる。

【００３８】決済手段及びシナリオ 本システムによって提供される決済手段には、支払要求、支払債務、保証付き
支払債務と、条件付き支払が含まれる。各決済手段の簡単な説明をこれまでに行
ったが、以下、各々の決済手段についてより詳細に説明する。

【００３９】支払要求 支払要求（ＰＯｒ）は、買手１０６が、売手１０８に対する特定金額の信用支
払を特定日に開始するよう、買手銀行１０２に依頼する取消可能で無条件の電子
的指図である。支払要求は、普通買手と売手との取引関係が確立されている場合
に使用される。

【００４０】支払債務及び保証付き支払債務 支払債務（ＰＯｂ）は、買手銀行１０２で特定日に特定金額を、債券を持つ
売手１０８即ち債券の所有者に支払うという、買手１０６の取消不能な無条件の
約束である。それは売手に対する買手の負債の証拠となる。買手１０６は、買手
銀行１０２に対し、売手１０８に支払債務を引き受ける即ち保証するよう依頼す
ることができる。この場合、支払債務は、保証付き支払債務（Ｃｅｒｔｉｆｉｅ
ｄ ＰＯｂ）となる。 通常、保証付き支払債務は、期日通りに支払うという買手１０６の意図に、売
手１０８が確信を持てない場合に使用される。

【００４１】条件付き支払 条件付き支払は、予め合意された条件を満たしていることを証明する特定当事
者間で署名された特定の電子メッセージが買手銀行１０２に示された時に買手銀
行１０２で支払可能な、特定の売手に有利な支払要求又は支払債務である。買手
１０６は、売手１０８に支払債務を引き受ける即ち保証することを買手銀行１０
２に依頼することができるが、この場合、この支払手段は、保証された条件付き
支払債務（Ｃｅｒｔｉｆｉｅｄ ＣＰＯｂ）となる。 条件付き支払は、買手１０６又は売手１０８の一方、又はそれら双方が、特定
の規定が満たされて初めてその支払が行なわれると合意した場合に使用される。
条件付き支払は、支払のタイミング及び発生を引き起こすために使用される。保
証された条件付き支払債務には、指定の規定が満たされるとその支払が行なわれ
るという保証が付加される。

【００４２】決済のシナリオ及びモデル 好ましい実施形態において、買手１０６は、様々な商業的及び金融的シナリオ
を想定して、支払要求及び支払債務の使用を考えることができる。これは商業取
引又は金融取引のほとんどの段階で両当事者を識別する図２のシステム２００の
能力によるものであって、これにより、買手が支払を考える際に大きな自由度を
提供する。後述するシナリオはこの柔軟性を例示している。

【００４３】売手の決済サーバを介したオンライン決済の開始 第１の決済シナリオにおいて、売手１０８の決済サーバは、買手１０６に対し
て支払要求又は支払債務の選択肢を用意する。図３に示すように、この第１シナ
リオでは、買手１０６は、支払要求又は支払債務の指図書を作成して、この指図
書を、売手銀行１０４を介して買手銀行１０２に転送することを売手１０８に許
可する。買手１０６及び売手１０８、場合によっては売手銀行１０４も、決済を
開始する即ちその債券を作成する上で必要な情報を交換する。好ましい実施形態
においては、買手銀行１０２は、４コーナー取引モデルを用いて、買手１０６の
署名に基づいて決済を開始する即ち支払債券を作成する。

【００４４】売手決済サーバを介してのオンライン口座引落し認可 第２の支払シナリオにおいて、売手１０８の決済サーバは、図４に示すように
、口座振替（ｄｉｒｅｃｔ ｄｅｂｉｔ）の選択肢を買手１０６に用意する。図
４に示すように、この第２シナリオでは、買手１０６は売手１０８に対し、買手
１０６の口座からの自動引落しの指図書を売手銀行１０４に転送することを許可
する。好ましい実施形態において、買手１０６及び売手１０８は、決済を開始す
る上で必要な情報を交換する。売手銀行１０４は、売手１０８の署名に基づいて
口座振替手続きを開始する。これは口座振替取引モデルと呼ばれる。買手１０６
と売手１０８とが異なる国で事業運営されている場合には、このシナリオは成り
立たないということに留意されたい。

【００４５】買手の決済サーバを介しての決済の開始 第３の支払シナリオにおいて、図５に示すように、買手１０６の決済サーバが
、買手銀行１０２に、直接、支払要求又は支払債務の指図書を送る。図５に示す
ように、この第３支払シナリオでは、買手１０６は、決済の開始即ち債券作成に
必要な情報を与える。買手銀行１０２は、買手１０６の署名に基づいて決済を開
始する即ち債券を作成する。これは、買手対買手銀行取引モデルと呼ばれる。

【００４６】システム実体間の法的関係 好ましい実施形態においては、銀行とその顧客とは、契約合意によって法的に
拘束される。特に、システムサービスの利用方法は、一連の運用規則、及び、後
でより詳細に説明するような、各システム実体を法的に拘束するこれら規則に基
づいて作成された１つ又はそれ以上の契約によって規定するのが好ましい。 好ましい実施形態においては、本明細書に開示された決済サービスの運用手順
及び規則によって、参加者の権利及び義務が規定される。これら規則を作成する
際、（諸外国の管轄下のものも含む）様々な電子決済共同体の規則を指針として
活用することができる。更に、それらの共同体規約によって、新しい規則に特定
の要件を強いる可能性もある。例えば、取引の取消及び決済の終結の問題に関す
る共同体規則には特に注意するのが好ましい。

【００４７】 その代わりに、支払要求又は支払債務を既存の決済規則と調和できない場合、
又は、オンライン決済開始の特殊性を考慮してこのような規則を（それらの既存
の枠組み範囲外で）補足する必要がある場合には、取引の様々な関係者を、ルー
ト実体１１０によって課せられる他の一連の規則により拘束することができる。 好ましい実施形態においては、本システムのための運用規則は、国際商工会議
所（ＩＣＣ）によって承認されると、電子通商及び決済に関する統一規則（ＵＲ
ＥＴＳ）に組み込まれる。

【００４８】 好ましい実施形態においては、本システムにおける支払債務及び保証付き支払
債務の全ては、帳簿記入形式で作成され記録される。為替手形の場合のように、
支払債券及び保証付き支払債券は、流通市場で売却できるのが好ましい。これら
債券の所有者の変更は、所有者登録サービスにより行うことができるのが好まし
い。買手銀行１０２は、正確な債券所有者を登録する責任を持つようにするのが
好ましい。

【００４９】 好ましい実施形態において、決済サービスが利用される前に、買手１０６及び
売手１０８の各々は、自身の参加者１０２、１０４との関係を確立しておくのが
好ましい。このため、好ましい実施形態においては次のような段階が含まれる。 −各顧客及びそれぞれの参加者は、決済サービスに関する各自の役割及び義務
を規定した契約を結ぶ。この契約は、通常、それぞれの顧客と銀行との関係以外
の側面を対象とする両当事者間の他の契約とは別のものである。契約の締結によ
って、顧客は決済サービスの運用規則を受諾する。 −各参加者の各々は、自身の顧客のために決済サービスを設定する。この設定
には、多くの銀行部門に関連する与信監査プロセスを必要とされる可能性がある
。決済保証口座の設定には、時間もかかるであろうし、両当事者間の既存の信用
関係にも関係するであろう。また、決済サービスの設定には、好ましくは、決済
サービスの利用を許可され、顧客との一連の信用を確立する従業員の登録も含ま
れる。更に、買手１０６のための標準清算指図書（例えば、通貨に応じた引落し
口座、利用する決済システム）の設定を含むのが好ましい。加えて、各銀行は、
顧客に提供する特定のサービスに応じた付加な設定手続きも必要となるであろう
。

【００５０】 好ましい実施形態において、各システム実体間における紛争の解決は、参考の
ために本明細書に組み込まれた、「証明に関するサービス及びその他のサービス
を提供するためのシステム及び方法」と題する２０００年２月１１日に出願され
審査過程にある米国特許出願第０９／５０２，４５０号に記載されている。尚、
この出願を本明細書の参考文献とされたい。

【００５１】決済サービスプロダクトの概要 好ましい実施形態において、本システムにおける支払債務、又は、取消可能性
、及び荷為替条件との組合せによって、対事業所電子商取引の信用・リスク管理
ニーズに適合する様々な支払手段を提供するいくつかの手段形式が作り出される
。これら手段の形式を下表に要約する。 表１

【００５２】 好ましい実施形態では、支払要求によって、買手及び売手は、自動オンライン
決済を開始しワールドワイドウェブを介して電子商取引を行うことができる。 支払要求は、信用状又は支払伝票とすることができる。支払伝票は、買手１０
６が作成しても(よって、買手の発行した認可証書となる)、（買手の認可なしに
、売手１０８が作成した）代金取立書（注：これは全ての国で許されるものでは
ない）とすることも可能である。

【００５３】 買手銀行１０２が売手１０８に支払う義務を負う信用度の高い決済サービスに
は、保証付き支払債務を含むことができる。保証付き支払債務は、購入商品につ
いての売手１０８に対する支払を買手銀行１０２が無条件で保証するものである
ことが好ましい。 好ましい実施形態において、条件付き支払要求は、売手１０８が取引対象の品
物を出荷したことを証明する、売手１０８からの文書を受け取るまで、買手銀行
１０２が支払を求めないという点を除けば、上記の支払要求と同様である。保証
付きで条件付きの支払債務は、契約義務の実行を証明するために、売手１０８又
は第三者が荷為替信用状に指定された文書を買手銀行１０２に提出することを条
件に、売手１０８への支払を買手銀行１０２が保証するものとするのが好ましい
。

【００５４】 本システム及び方法は、上記の認定された支払手段を実施するために、複数の
依頼メッセージ及び応答メッセージを用いる。これらは、概ね以下のものを含む
。 表２ １）依頼メッセージ

【００５５】 表３ ２）応答メッセージ

【００５６】 上記メッセージの分類は一般的なものであって、これらメッセージ及びその他
の関連メッセージのより具体的な分類及び機能内容は、本発明のシステムが具体
的にどのように実施されるかによって変えることができる点に注目されたい。拡
張可能なマークアップ言語（ＸＭＬ）を使用するシステムメッセージの好ましい
実施については、後に詳しく説明する。

【００５７】 好ましい実施形態において、各メッセージは、各署名当事者及び最終受信者の
否認防止機能を保持した状態で、原本のコンテンツ及び添付書類に署名付きの追
加（これには、各追加に対する１つ又はそれ以上の署名／証明書が含まれる）を
付加することをサポートするように構成される。更に、好ましい実施形態におい
て、システムは、以下の要件を厳守する。 １．各依頼メッセージは、対象とする最終当事者によって受け取られた時、サ
ービス受領（Ｓｒｖ Ａｃｋ）メッセージを返信する。 ２．金融機関が支払を実行する時、その金融機関は、この行為についての確認
メッセージ（Ｐａｙ Ｃｏｎｆ）を適切な当事者に送る。 ３．金融機関が支払債務指図書を受け取った時、その金融機関は、その債務が
履行されるか否かを示すメッセージの発信者に、確認メッセージ（ＰＯｂ Ａｃ
ｐｔ Ｃｏｎｆ）を送る。保証付きであることを依頼された支払債務メッセージ
に応答して、ＣｅＰＯｂ Ａｃｐｔ Ｃｏｎｆメッセージが送られるのが好まし
い。 ４．金融機関が支払要求取消メッセージ（ＰＯｒ Ｃｎｃｌ）を受け取った時
、その金融機関は、この取消が受諾されたか拒否されたかを確認するメッセージ
（ＰＯｒ Ｃｎｃｌ Ｃｏｎｆ）で応答する。 ５．第三者のサービス提供者（ＴＰＳＰ）実体が条件通知メッセージ（Ｃｎｄ
Ａｄｖ）を受け取った時、条件が満足される場合又はこの条件は満足される可
能性がないと確信した場合には、その第三者のサービス提供者実体は、条件告知
メッセージ（Ｃｎｄ Ｄｅｃｌ）で応答する。 ６．支払指図メッセージには、買手１０６組織の複数の当事者が署名できる。 ７．全ての支払メッセージには、信頼当事者の各々が署名する。 ８．買手１０６及び売手１０８は、（買手及び売手の銀行が同一である場合、
即ち４コーナー取引ではなく３コーナー取引の場合を除き）、銀行の証明書を用
いて、支払メッセージにおいて自身の身元を識別する。

【００５８】 各システムメッセージのコンテンツを説明する表を以下に示す。各表において
、第１欄は、メッセージ部分の名称を識別し、第２欄は、好ましい実施形態にお
いて、そのメッセージ部分が義務的なものか選択的なものかそれとも条件的なも
のか（即ち、状況によってはそれが義務的なものになるか否か）を特定し、第３
欄は、そのメッセージ部分のコンテンツを提供する実体を識別し、更に、第４欄
には、そのメッセージ部分に関する付加的コメントが記載されている。

【００５９】 好ましい実施形態においては、支払要求指図書は、下記のデータを含む。 表４

【００６０】 好ましい実施形態においては、支払債務指図書は、下表に挙げた変更を除き支
払要求指図書の上記表に挙げたデータを含む。 表５

【００６１】 好ましい実施形態において、保証付き支払債務指図書は、支払要求指図書の上
記表に挙げたものと同じデータを含む。 好ましい実施形態において、（１）条件付き支払要求指図書は、下表に挙げた
変更を除き、支払要求指図書の上記データを含み、（２）条件付き支払債務指図
書は、下表に挙げた変更を除き、支払債務指図書の上記データを含み、（３）保
証付き／条件付き支払債務指図書は、下表に挙げた変更を除き、保証付き支払債
務指図書の上記データを含む。 表６

【００６２】 好ましい実施形態において、支払条件は、条件テンプレート群から選択される
。更に、各条件は、真偽を明白に確認できるよう構成するのが好ましい。 好ましい実施形態において、ＴＰＳＰは、これら条件下で必要とされてもされ
なくてもよい情報提供を目的とし、確認メッセージに追加される購入品詳細又は
電子文書／ファイルを添付又は付け加えることができる。 好ましい実施形態において、支払要求取消メッセージ（ＰＯｒ Ｃｎｃｌ）に
は、買手１０６組織の複数当事者が署名することができる。

【００６３】 好ましい実施形態において、支払要求取消メッセージは、下記データを含む。 表７

【００６４】 好ましい実施形態において、条件通知（Ｃｎｄ Ａｄｖ）メッセージは、信頼
できるサービス提供（ＴＳＳ）組織から送られるが、買手銀行１０２は、この組
織としての役割を果たすことができる。これらメッセージは、決済実行を円滑化
する上で満足しなくてはならない条件を設定するために使用される。好ましい実
施形態において、全ての条件通知メッセージ（Ｃｎｄ Ａｄｖ）は、ＴＰＳＰに
送られ、このメッセージに応答してＴＰＳＰがサービス受領（Ｓｒｖ Ａｃｋ）
メッセージを送る。好ましい実施形態において、条件通知メッセージは、以下の
データを含む。 表８

【００６５】 好ましい実施形態においては、各当事者は、ステータス照会メッセージを使用
して、支払開始システムの他の関係者から特定の取引に関する情報を入手する。 好ましい実施形態においては、どの形式の依頼メッセージを受け取った時でも
応答メッセージが作成される。各応答メッセージは、受け取った依頼メッセージ
に対して肯定的応答が返信されるのか否定的な応答が返信されるのかを示すのが
好ましい。 好ましい実施形態においては、すべての依頼メッセージに応答してサービス受
領（Ｓｒｖ Ａｃｋ）メッセージが送られる。好ましくは、下記メッセージの全
ては、サービス受領（Ｓｒｖ Ａｃｋ）メッセージで応答される。 −ＰＯｒ Ｉｎｓｔ（支払要求指図） −ＰＯｂ Ｉｎｓｔ（支払債務指図） −ＣＰＯｒ Ｉｎｓｔ（条件付き支払要求指図） −ＣＰＯｂ Ｉｎｓｔ（条件付き支払債務指図） −ＣｅＰＯｂ Ｉｎｓｔ（保証付き支払債務指図） −ＣｅＣＰＯｂ Ｉｎｓｔ（保証付き／条件付き支払債務指図） −ＰＯｒ Ｃｎｃｌ（支払要求の取消） −Ｃｎｄ Ａｄｖ（条件通知） −Ｃｎｄ Ｕｐｄａｔｅ（条件通知メッセージに応答した中間更新） −Ｃｎｄ Ｄｅｃｌ（条件通知メッセージに応答した条件告知）

【００６６】 好ましい実施形態においては、対象とする最終受信者によってメッセージに含
まれた構文、署名、証明書、及びユーザー許可が検証された時、サービス受領（
Ｓｒｖ Ａｃｋ）メッセージが送られる。この対象最終受信者は、決済シナリオ
の機能に応じて変えることができる。例えば、４コーナーモデルにおいて、支払
要求／支払債務依頼メッセージの対象最終受信者は、買手銀行１０２である。こ
れに対して、口座振替モデルにおいては、支払要求／支払債務依頼メッセージの
対象最終受信者は、売手銀行１０４となる。好ましい実施形態においては、支払
指図メッセージの対象最終受信者によって受け取られてから１分以内に、受け取
られた支払指図メッセージに応答して、サービス受領（Ｓｒｖ Ａｃｋ）メッセ
ージが送られる。

【００６７】 好ましい実施形態においては、サービス受領（Ｓｒｖ Ａｃｋ）メッセージは
、下表に記されたデータを含む。 表９

【００６８】 好ましい実施形態においては、対象とする最終受信者ではない実体がサービス
受領（Ｓｒｖ Ａｃｋ）メッセージを受け取ると、如何なる場合でも、その実体
は、この情報を同封し、このサービス受領（Ｓｒｖ Ａｃｋ）情報を添付して該
メッセージを対象最終受信者に回送する。例えば、４コーナーモデルで運用され
る場合、売手銀行１０４が買手銀行１０２からサービス受領（Ｓｒｖ Ａｃｋ）
メッセージを受け取った場合には、売手銀行１０４は、このサービス受領（Ｓｒ
ｖ Ａｃｋ）メッセージをその売手１０８に回送する。

【００６９】 好ましい実施形態においては、このサービス受領（Ｓｒｖ Ａｃｋ）メッセー
ジは、表９に挙げたデータ及び下表に挙げたデータを含む。 表１０

【００７０】 好ましい実施形態においては、金融機関が関連する支払指図書に指定された支
払方法の実行を完了した時、支払実行確認（Ｐａｙ Ｃｏｎｆ）メッセージが送
られる。支払実行確認（Ｐａｙ Ｃｏｎｆ）メッセージは、翌日の営業日最終時
刻までに適切な受信者に送られるのが好ましい。好ましくは、この支払実行確認
（Ｐａｙ Ｃｏｎｆ）メッセージは次のデータを含む。 表１１

【００７１】 好ましい実施形態においては、実体が支払実行確認（Ｐａｙ Ｃｏｎｆ）メッ
セージを受け取った時、その実体は、この情報を同封し、その支払実行確認（Ｐ
ａｙ Ｃｏｎｆ）情報を添付したメッセージを対象とする最終受信者に回送する
。例えば、４コーナーモデルで運用される場合、売手銀行１０４が買手銀行１０
２から支払実行確認（Ｐａｙ Ｃｏｎｆ）を受け取った時、売手銀行１０４は、
この支払実行確認（Ｐａｙ Ｃｏｎｆ）メッセージをその売手１０８に回送する
。 好ましい実施形態においては、この支払実行確認（Ｐａｙ Ｃｏｎｆ）メッセ
ージは表１１に挙げたデータ及び以下のデータを含む。 表１２

【００７２】 好ましい実施形態においては、翌日の就業日最終時刻までに、支払債務依頼メ
ッセージに応答して支払債務受諾確認（ＰＯｂ Ａｃｐｔ Ｃｏｎｆ）メッセー
ジが送られる。好ましくは、支払債務受諾確認（ＰＯｂ Ａｃｐｔ Ｃｏｎｆ）
メッセージは以下に挙げるデータを含む。 表１３

【００７３】 好ましい実施形態においては、対象となる最終受信者ではない実体が支払債務
受諾確認（ＰＯｂ Ａｃｐｔ Ｃｏｎｆ）メッセージを受け取った時、その実体
は、この情報を同封し、その支払債務受諾確認（ＰＯｂ Ａｃｐｔ Ｃｏｎｆ）
情報を添付したメッセージを対象最終受信者に回送する。例えば、４コーナーモ
デルで運用される場合、売手銀行１０４が買手銀行１０２から支払債務受諾確認
（ＰＯｂ Ａｃｐｔ Ｃｏｎｆ）を受け取った時、売手銀行１０４は、この支払
債務受諾確認（ＰＯｂ Ａｃｐｔ Ｃｏｎｆ）をその売手１０８に回送する。好
ましくは、この支払債務受諾確認（ＰＯｂ Ａｃｐｔ Ｃｏｎｆ）メッセージは
、上記表１３に挙げたデータ及び以下のデータを含む。 表１４

【００７４】 好ましい実施形態においては、翌日の就業日最終時刻までに、保証付き支払債
務依頼メッセージに応答して、保証付き支払債務受諾確認（ＣｅＰＯｂ Ａｃｐ
ｔ Ｃｏｎｆ）メッセージが送られる。好ましくは、保証付き支払債務受諾確認
（ＣｅＰＯｂ Ａｃｐｔ Ｃｏｎｆ）メッセージは、表１３のデータを含む。

【００７５】 好ましい実施形態においては、翌日の就業日最終時刻までに、支払要求取消指
図メッセージ（ＰＯｒ Ｃｎｃｌ Ｃｏｎｆ）に応答して、支払要求取消確認（
ＰＯｒ Ｃｎｃｌ Ｃｏｎｆ）メッセージが送られる。好ましくは、支払要求取
消確認（ＰＯｒ Ｃｎｃｌ Ｃｏｎｆ）メッセージは以下のデータを含む。 表１５

【００７６】 好ましい実施形態においては、条件通知メッセージに関連して条件更新（Ｃｎ
ｄ Ｕｐｄａｔｅ）メッセージが送られる。これらのメッセージは、条件通知メ
ッセージによって指定された条件を満足する形で行われた進捗状況の更新情報を
提供するために、好ましくはＴＰＳＰ関係者から送られる。 好ましい実施形態においては、ＴＰＳＰ関係者による条件通知メッセージに応
答して、条件告知（Ｃｎｄ Ｄｅｃｌ）メッセージが送られる。好ましくは、条
件告知（Ｃｎｄ Ｄｅｃｌ）メッセージは、条件通知（Ｃｎｄ Ａｄｖ）メッセ
ージの原本に概要が示された条件が満足された場合、又は、この条件が満足され
る可能性がない場合に送られる。例えば、ある商品が指定期日までに出荷される
というのが条件であったが、その商品が発送されないままこの指定期日が過ぎて
しまったという状況であれば、否定的応答が送られる。

【００７７】 好ましくは、条件告知（Ｃｎｄ Ｄｅｃｌ）メッセージは以下のデータを含む
。 表１６

【００７８】 好ましい実施形態においては、ステータス照会応答メッセージ（Ｓｔｓ Ｉｎ
ｑ Ｒｅｓｐ）は、ステータス照会依頼で指定された取引の履歴を含む。

【００７９】 通信プロトコル 好ましい実施形態においては、以下のプロトコル及びフォーマットが、署名し
て署名データをフォーマットする際に使用される。 １．ＸＭＬＤＳｉｇ（ＸＭＬ−署名構文及び処理）−取引調整装置や商人の署
名及びフォーマット化のために使用される ２．ＰＫＣＳ＃７−データ要素のブラウザを基盤とした記入のために使用され
る ３．Ｓ／ＭＩＭＥｖ３（セキュア／多目的インターネットメール拡張バージョ
ン３）−当事者間の非同期通信のために使用される ４．ＳＳＬｖ３（セキュアソケット層バージョン３．０）又はＴＬＳｖ１．０
（トランスポート層機密保護バージョン１．０）−同期メッセージのために使用
される

【００８０】 特に、好ましくは、以下の規則は、本発明のシステム及び方法を使用した取引
における支払当事者間で交信したり署名したりするためのフォーマットを規定す
る。 −全ての同期交信は、後述するシステム規則に従って、ＨＴＴＰによる 安全なＳＳＬｖ３．０又はＴＬＳｖ１．０インターネット機密保護プロトコルを
使用して行うのが好ましい。 −エンドユーザは、受諾されたフォーマットで署名することのできるブラウ ザ及びメールクライアントよりも高度なシステムは持たなくてよい。例えば、受
諾のために買手１０６及びＴＰＳＰに送られる文書は、この範疇に入る。このブ
ラウザは、ＰＫＣＳ＃７で包装されたメッセージを提供すると考えられる。ＰＫ
ＣＳ＃７は、デジタル署名のような暗号化することができるデータのための一般
的構文を記述した暗号メッセージ構文標準である。買手１０６が署名するデータ
は、後述するように適切なブロックで表される。 −好ましくは、後述する標準システムＸＭＬメッセージングは、当事者間で通
信するために使用されるため、売手１０８、売手銀行１０４、及び、買手銀行１
０２は、このようなメッセージを作成したり受信したりすることができる必要が
ある。 −また、買手１０６及びＴＰＳＰが、本発明のシステムメッセージングをサポ
ートするサーバを基盤とするシステムを有する場合、各銀行又は各参加者は、そ
れら組織をサポートするために、後述するＸＭＬ ＤＴＤを使用することができ
る。 −好ましくは、全ての受領は、Ｓ／ＭＩＭＥｖ３プロトコルを使用して暗号化
される。この受領が、未知のサーバにサポートされて買手又はＴＰＳＰに送られ
ている場合、署名は、Ｓ／ＭＩＭＥｖ３標準の部分であり、後述するＸＭＬＤＳ
ｉｇ署名ではない。 −選択的に、実施を容易にするために、各買手及び各ＴＰＳＰとの全ての非同
期通信は、Ｓ／ＭＩＭＥ標準の部分として非同期通信を行なう金融機関の署名付
きＳ／ＭＩＭＥｖ３メッセージとして送ることができる。 −しかし、非同期通信は、包装され、好ましくは、後述するＮＩＢ(ネットワ
ーク情報ブロック)アプリケーションブロック及びＸＭＬメッセージングからの
応答を含むが、ＣｅｒｔＢｕｎｄｌｅ即ち非同期包装構造内で複製されている各
署名ブロックは必ずしも含まない。 −システム応答メッセージは、ＴＰＳＰ対ＴＳＳの通信のために設定されるが
、各ＴＰＳＰは、ウェブインターフェースを介して条件を解除することができる
。後者の場合には、ＴＰＳＰは、条件を解除するために、ＰＫＣＳ＃７署名を使
用してメッセージに署名することになる。

【００８１】 データ形式の定義 好ましい実施形態において、技術的実施及び統合による選択肢を制限しないた
めに、システムメッセージは、常に適切な対応データ形式の定義を持つ拡張可能
なマークアップ言語（ＸＭＬ）を使用して構成される。以下、いくつかのデータ
形式定義（ＤＴＤ）の好ましい実施形態について説明する。

【００８２】 このシステムでは、全ての支払固有メッセージが、支払メッセージとして一意
に識別可能であること、及び、メッセージ識別子（タグ）が曖昧さのない形で定
義されることが必要である。ＸＭＬ文書により、本発明のシステムは、ＸＭＬネ
ームスペースを使用してこれらの要件を満たすのが好ましい。ＸＭＬネームスペ
ースは、ＸＭＬ文書に使用される要素名称及び各属性名称を、ＵＲＩ（統一的資
源識別子）参照符によって識別されるネームスペースと関係付けることによって
、それら要素名称及び各属性名称を特定する簡易な手段を提供する。各トップレ
ベルのＸＭＬ支払文書においては、各データ要素が発生するＸＭＬネームスペー
スが明示される。例えば、ＸＭＬ文書には、表１７に記載したようなネームスペ
ースが参照符として付けられる。

【００８３】 表１７

【００８４】支払請求書のＤＴＤ 好ましい実施形態において、支払請求書のＤＴＤのコンテンツを以下の表１８
に示す（また、支払請求書のＤＴＤは、後述する、「条件群」や「証明書ステー
タス調査」等の特定のＤＴＤをインポートしてもよい）。 表１８

【００８５】 本システムでは、「Ｍｓｇｇｒｐｉｄ」及びＮＩＢ（ネットワーク情報ブロッ
ク）の「ＭｓｇＩＤ」属性が特定され、この値を取引のメッセージ毎に一意に特
定することが要求される。Ｍｓｇｇｒｐｉｄは、一回の交信における全ての文書
に共通な一意の識別子（ＩＤ）である。多数の交信を、１つの支払取引に関連さ
せることができる点に注目されたい。各々の交信（例えば、支払請求−サービス
受領の交信、又は、取消依頼−サービス受領の交信）では、Ｍｓｇｇｒｐｉｄは
同一のものとなる。非同期通信は、小さな交信として処理されことになる。Ｍｓ
ｇｉｄは、交信における文書毎のシーケンシャルカウンタとして使用される。し
かし、交信が複雑になると、ＭｓｇｇｒｐｉｄとＭｓｇｉｄとの組合せによって
確実に交信中の文書を一意に識別できるようにするため、発信者のロールは、連
番を付けて使用されるのが好ましい。

【００８６】 Ｍｓｇｉｄの好ましい構造は、「ｘｘ：ｎｎ」であって、ここで、ｘｘは、ロ
ール識別子、ｎｎは、現在の交信におけるそのロールによって送られた文書の連
番である。取引調整装置がシステム支払メッセージを識別できるようにするため
に、ＨＴＴＰコンテンツ形式かどうかを適切に特定する必要がある。 上記システム支払依頼文書は、前述し表２に挙げた支払指図メッセージ、即ち
ＰＯｒ Ｉｎｓｔ、ＰＯｂ Ｉｎｓｔ、ＣＰＯｒ Ｉｎｓｔ、ＣＰＯｂ Ｉｎｓ
ｔ、ＣｅＰＯＢ Ｉｎｓｔ、及びＣｅＣＰＯｂ Ｉｎｓｔ、を特定するために使
用することができる。好ましい実施形態におけるシステム支払依頼のＤＴＤを表
１９に示す。

【００８７】 表１９

【００８８】 上記システムヘッダーは、全ての取引に対する一意の取引参照符を提供し、プ
ロダクト属性により、特定の支払プロダクト指図メッセージを特定できるように
する。このヘッダーは、全てのメッセージに共通の構成要素であって、好ましい
実施形態においては以下の属性（表２０）を含む。 表２０

【００８９】 好ましい実施形態においては、以下の表２１の検証規則は、システムヘッダー
の属性に適用される。 表２１

【００９０】 システム支払依頼ＤＴＤの買手署名データＤＴＤは、好ましい実施形態におい
ては、以下のデータブロック（表２２）を含む。 表２２

【００９１】 上記交渉データブロックは、取引の過程で交渉されたデータ要素を搬送し、好
ましくは以下の属性（表２３）を有する。 表２３

【００９２】 以下の表２４の検証規則は、交渉日の属性に適用される。 表２４

【００９３】 （買手署名データＤＴＤの）買手データブロックは、取引過程で買手１０６に
よって提供される情報を含み、取引過程で交渉されたデータ要素を搬送する。好
ましくは、買手データブロックは、（例えば、接触サブブロック内に）その取引
に関するあらゆる課題の詳細を提供する接触データを含む。買手データブロック
は、好ましい実施形態においては、以下の属性（表２５）を有する。 表２５

【００９４】 以下の表２６の検証規則は、買手データの属性に適用される。 表２６

【００９５】 （買手署名データＤＴＤの）売手公開データブロックは、取引において売手１
０８によって提供された情報を含み、好ましくは、その取引に関して生じたあら
ゆる課題についての接触の詳細も含む。売手公開データブロックは、好ましい実
施形態においては、以下の表２７に挙げた属性を有する。 表２７

【００９６】 以下の表２８の検証規則は、好ましくは、売手公開データの属性に適用される
。 表２８

【００９７】 （買手署名データＤＴＤにおける）債務ブロックは、取引の結果生じるあらゆ
る債務の詳細を含む。債務が引き受けられる予定のない場合、そのブロックは、
債務形式が「ＮＯＮＥ」に設定されるという点に留意されたい。債務ブロックは
、好ましい実施形態においては、以下の属性を有する（表２９）。 表２９

【００９８】 以下の検証規則は、好ましくは、債務ブロックの属性に適用される（表３０）
。 表３０

【００９９】 （買手署名データＤＴＤの）条件群ブロックは、支払に関連する諸条件の記述
を含む（このブロックは、前述し表２に挙げた条件通知依頼メッセージに対応す
る）。条件群ブロックは、インポートされた要素であって、別途説明するように
、このシステムにおける多くの支払ブロックにおいて使用される。 （買手署名データＤＴＤの）買手署名詳細ブロックには、買手組織の関係者に
よって作成される署名が含まれる。承認サイクルでは、後でより詳細に説明する
ように、どの指図書に対しても多くの署名を求めることができる。よって、買手
署名詳細ブロックを、複数の買手署名詳細ブロックとすることが可能である。買
手署名詳細ブロックは、以下の表３１のように、買手１０６によって作成された
署名に関する情報を含むのが好ましい。

【０１００】 表３１

【０１０１】 下記の検証規則は、好ましくは、買手署名詳細の属性に適用される（表３２）
。 表３２

【０１０２】 システム支払請求ＤＴＤは、買手組織の関係者によって作成された署名を入れ
た買手署名ブロックも含む。承認サイクルでは、どの指図書に対しても多くの署
名を求めることができる。好ましい実施形態において、買手署名ブロックは、以
下の表３３のブロックを含む。 表３３

【０１０３】 以下の表３４の検証規則は、好ましくは、買手署名ブロックに適用される。 表３４

【０１０４】 買手署名ブロックは、好ましくは、以下の表３５の属性も含む。 表３５

【０１０５】 好ましい実施形態において、表３６の検証規則は、連番の属性に適用される。 表３６

【０１０６】 システム支払請求ＤＴＤの売手私的データブロックは、売手１０８から売手銀
行１０４に送られる私的データを含む。売手私的データブロックは、売手銀行１
０４によって除去され、買手銀行１０２に送られるデータブロックには含まれな
い。好ましい実施形態において、売手私的データブロックは、以下の属性（表３
７）を含む。

【０１０７】 表３７

【０１０８】 以下の表３８の検証規則は、売手私的データの属性に適用される。 表３８

【０１０９】 システム支払請求ＤＴＤの売手銀行データブロックは、取引において売手銀行
１０４から買手銀行１０２に情報を搬送する。売手銀行１０４は、必要に応じ、
（後述する）接触ブロックの関連接触詳細を提供することができる。好ましい実
施形態において、売手銀行データブロックは、表３９の属性を含む。 表３９

【０１１０】 以下の検証規則(表４０)は、好ましくは、売手銀行データの属性に適用される
。 表４０

【０１１１】支払応答 好ましい実施形態における支払応答ＤＴＤのコンテンツを、以下の表４１に示
す（支払応答ＤＴＤは、証明書ステータス調査及び接触要素等の特定ＤＴＤをイ
ンポートすることもできる）。 表４１

【０１１２】 好ましい実施形態におけるシステム支払応答ＤＴＤを、以下の表４２に示す。 表４２

【０１１３】 前述したように、システムヘッダーは、全ての取引に対して一意の取引参照符
を提供し、且つ、全てのメッセージに共通の構成要素である。システムヘッダー
の属性は、表２０に示す通りで、好ましい実施形態における対応する検証規則は
表２１に示す通りである。 システム支払応答ＤＴＤの参照符ＤＴＤは、好ましくは、以下の属性を含む（
表４３）。 表４３

【０１１４】 以下の表４４の検証規則は、好ましくは、参照符の属性に適用される。 表４４

【０１１５】 精査依頼に応答して、精査受領ＤＴＤが返送される。精査依頼は、金融機関に
よって選択的に使用され、対応する金融機関に支払詳細を回送する前にその金融
機関の身元を検証するためのものである。受領を行う金融機関が、（ａ）発信者
の身元を確実に認証できる場合、及び（ｂ）依頼を行なっているプロダクトをサ
ポートできる場合には、精査受領は順調に行なわれる。接触情報は、この対応す
る金融機関によって精査受領データに含ませることができる。好ましい実施形態
においては、精査受領データは、以下の属性を含む（表４５）。

【０１１６】 表４５

【０１１７】 表４６の検証規則は、精査受領の属性に適用される。 表４６

【０１１８】 以下の理由コード（表４７）は、精査受領とともに使用することができる。 表４７

【０１１９】 サービス受領ＤＴＤ（上記した表３のサービス受領応答メッセージに対応する
）は、応答する金融機関による接触情報をサービス受領データに含むことができ
る。それは、好ましくは、以下の表４８の属性を有する。 表４８

【０１２０】 以下の検証規則（表４９）は、サービス受領の属性に適用される。 表４９

【０１２１】 好ましい実施形態においては、以下の理由コードがサービス受領とともに使用
される（表５０）。 表５０

【０１２２】 支払指図受領ＤＴＤは、銀行決済システムにおける取引情報の検証結果として
送られる肯定的又は否定的な受領である。支払指図受領は、好ましくは、処理の
ために買手銀行１０２（口座振替取引モデルでは売手銀行１０４）によって処理
されているデータを確認する交渉データブロックを含む。交渉データブロックは
、上記表２３に挙げた属性を含む。システム支払応答との関連において、下表５
１に記した検証規則は、好ましくは、交渉データブロックの属性に適用される。 表５１

【０１２３】 支払指図受領は、好ましくは、以下の表５２の属性を含む。 表５２

【０１２４】 以下の検証規則は、好ましくは、支払指図受領の属性に適用される（表５３）
。 表５３

【０１２５】 表５４の理由コードは、好ましい実施形態においては、支払指図受領とともに
使用される。 表５４

【０１２６】 支払確認ＤＴＤは、支払を実行している銀行によって顧客及びコルレス銀行に
送られるとともに、システム支払指図の実行の成否、決済ネットワークによる処
理の不履行、及び受益銀行による支払の受け取り完了について知らせるために、
買手銀行１０２及び売手銀行１０４双方が使用できる。成功の支払確認について
の理由コード及び理由テキストは、成功件であることを明確にする。支払確認は
、好ましい実施形態においては、以下の属性を含む（表５５）。

【０１２７】 表５５

【０１２８】 以下の表５６の検証規則は、好ましくは、支払確認の属性に適用される。 表５６

【０１２９】 以下の理由コードは、好ましくは、支払確認とともに使用される（表５７）。 表５７

【０１３０】 債務確認ＤＴＤブロックは、債務依頼の成否を確認する。債務確認は、（条件
付き）支払債務又は（条件付き）保証付き支払債務が依頼された時のみに返信さ
れる。システムヘッダーに応じて、このブロックは、表３に挙げたＰＯｂ Ａｃ
ｐｔ Ｃｏｎｆ応答メッセージ又はＣｅＰＯｂ Ａｃｐｔ Ｃｏｎｆ応答メッセ
ージに対応する。債務確認は、好ましくは、以下の表５８に挙げた属性を有する
。

【０１３１】 表５８

【０１３２】 以下の表５９の検証規則は、好ましくは、債務確認の属性に適用される。 表５９

【０１３３】 また、以下の理由コード（表６０）は、好ましくは債務確認とともに使用され
る。 表６０

【０１３４】 取消確認ＤＴＤブロックは、取消要求の肯定的又は否定的な確認を提供する。
このブロックは、上述した支払要求取消確認応答メッセージを実施するために使
用することができる。好ましい実施形態においては、取消確認は、表６１に挙げ
た属性を有する。 表６１

【０１３５】 以下の検証規則（表６２）は、好ましくは、取消確認の属性に適用される。 表６２

【０１３６】 また、以下の理由コード（表６３）は、好ましくは、取消確認とともに使用す
ることができる。 表６３

【０１３７】 条件設定確認ＤＴＤブロックは、支払に関する条件を確認する要求に対する肯
定的又は否定的な確認を提供する。条件設定確認は、上記した表３に挙げた条件
更新応答メッセージに対応する。この応答は、現在その条件がＴＳＳ領域にある
ということのみを表す。条件に関する他の全ての通信は、（後述する）支払条件
ＤＴＤにおいて定義される文書を使用する。条件確認は、好ましくは、以下の表
６４に挙げた属性を含む。 表６４

【０１３８】 以下の検証規則は、好ましくは、要素に含まれた条件確認の属性とともに使用
される（表６５）。 表６５

【０１３９】 以下の表６６の理由コードは、好ましくは、条件確認とともに使用される。 表６６

【０１４０】 関係する受領ＤＴＤ要素は、取引に関係するその他の受領をサポートし搬送す
るために選択的に使用することができる。例えば、関係する受領ＤＴＤ要素は、
売手銀行１０４対売手１０８の通信において、買手銀行１０２によって売手銀行
１０４に提供される受領を搬送するために使用することができる。関係する受領
ＤＴＤ要素は、コンテンツの識別、暗号解読、及び解釈を可能にする３つの標準
化された属性を有する。好ましい実施形態においては、それら属性は、以下の表
６７に挙げた通りである。

【０１４１】 表６７ 関連受領属性に相応しい検証規則を、適切に実施することができる。

【０１４２】 支払条件 支払条件文書は、条件のステータスに関する情報を、取引に関連する各関係者
の間で受け渡すために使用される（上記表３に挙げた条件告知応答メッセージは
、支払条件文書に対応する）。この文書は、各条件がＴＳＳにおいてうまく作り
出された時のみに使用される点に留意されたい。 支払条件文書は、好ましくは、以下の場合に使用される。 １．解除する必要のある条件が発生したことをＴＰＳＰに知らせるために、ＴＳ
Ｓによって使用される。 ２．解除のために、指定条件のステータスに変化が生じたことをＴＳＳに知らせ
るために、ＴＰＳＰによって使用される。 ３．買手１０６が行う支払に付随する条件のステータスに変化が生じたことを、
買手銀行１０２に知らせるために、ＴＳＳによって使用される（この買手銀行１
０２は、ＴＳＳとして働く、即ちＴＳＳの役割を果たすことができるという点に
留意）。 ４．条件のステータスに変化が生じたことを買手１０６又は売手銀行１０４に（
必要に応じ）知らせるために、ＴＳＳによって使用される。 ５．条件のステータスに変化が生じたことを売手１０８に知らせるために、売手
銀行１０４によって使用される。

【０１４３】 支払条件ＤＴＤのコンテンツは、好ましくは、以下の表６８に示す通りである
。 表６８

【０１４４】 好ましい実施形態におけるシステム支払条件ＤＴＤは、（表６９に示すような
）以下の要素又はブロックを含む。 表６９

【０１４５】 条件付き支払プロダクトのための、好ましい実施形態におけるシステムヘッダ
ーの属性は、上記した表２０に含まれている。好ましい関連の検証規則は、上記
した表２１に示されており、好ましくは表７０のプロダクト属性のための検証規
則も含む。 表７０

【０１４６】 この参照符ブロックは、条件付の商業的支払取引を識別するために使用される
。好ましい実施形態における参照符ブロックの属性及び関連検証規則は、それぞ
れ上記した表４３及び表４４に示される。 条件群ブロックは、支払の付随する条件の記述を含む。条件群ブロックは、イ
ンポート要素であり、前述したように、多くのシステム支払ブロックで使用され
る。このブロックの好ましい記述は、後でより詳細に示す。 また、前述したように、接触ブロックは、取引に関連する各関係者に接触情報
を提供するために使用できる接触詳細を含む。好ましくは、接触ブロックは、イ
ンポート要素であって、それをインポートする多くのシステム支払ブロックにお
いても使用される（また、前述したように条件群も含む）。好ましい実施形態に
おける接触データブロックも、後でより詳細に説明する。

【０１４７】 支払取消 支払取消文書は、支払の取消を依頼するために使用される。前述し表２に挙げ
た支払要求取消依頼メッセージは、支払取消文書で実施される。通常、−買手又
は銀行の債務が保証された「取消不能な」支払は、売手１０８の同意を得て初め
て取消すことができる。好ましい実施形態においては、支払取消ＤＴＤのコンテ
ンツは表７１のように定義される。 表７１

【０１４８】 システム支払取消ＤＴＤは、好ましくは、以下の表７２に挙げたブロックを含
む。 表７２

【０１４９】 システムヘッダーブロックは、前述したように、全てのメッセージに共通の構
成要素である。上記した表２０及び表２１は、好ましい実施形態によるこのブロ
ックの属性及び検証規則となる。更に、支払取消に関連して、メッセージ形式に
関し、依頼構造での有効値は、「取消依頼」及び「照会」である。 取消買手署名データブロックは、好ましくは、以下の要素を含む（表７３）。 表７３

【０１５０】 参照符ブロックは、取消を依頼されている取引の参照符を含む。好ましい実施
形態における参照符ブロックの属性及び関連する検証規則は、それぞれ上記した
表４３及び表４４に示される。取消データブロックは、買手１０６が提供した追
加データを含み、取消に関係する買手銀行１０２に受け渡される。好ましくは、
このブロックは、取消指図書を実行するための属性及び関連検証規則を有する。

【０１５１】 （取消買手署名データブロックの）買手署名ブロックは、取引取消を許可する
買手組織の関係者によって作成される署名を含む。承認サイクルでは、どの指図
書に対しても多くの署名を求めることができる。よって、買手署名詳細ブロック
を、複数の買手署名詳細ブロックとすることができる。買手署名詳細ブロックは
、買手１０６が作成した署名に関する情報を含み、好ましい実施形態において、
その属性は表３１に、関連検証規則は表３２に示される。また、前述したように
、（システム支払取消ＤＴＤに含まれる）関連する買手署名ブロックは、好まし
くは、署名がＰＣＤＡＴＡとして買手署名要素に含まれるＰＣＤＡＴＡブロック
を含む（表３３参照）。好ましい実施形態に関し、そのブロックの属性及び関連
検証規則は表３４に記されている。

【０１５２】支払精査 支払精査文書は、申請データを交換するに先立って、第三者金融機関の身元の
裏付けを必要とする金融機関が、その第三者金融機関の身元を確証するとともに
支払プロダクトがサポートされていることを確認することを可能とする。支払精
査に対する応答は、精査受領を含む支払応答である。支払精査ＤＴＤは、好まし
い実施形態においては、以下の要素を有する（表７４）。 表７４

【０１５３】条件群 条件群要素ＤＴＤは、支払に付随できる条件に関する情報を搬送するために、
多くの取引において使用される。条件群ＤＴＤは、好ましくは、以下の表７５に
挙げた要素を含む。 表７５

【０１５４】 条件群は、好ましくは、以下の表７６に挙げた属性を有する。 表７６ 相応しい検証規則が、条件群属性に適用される。

【０１５５】 条件ブロックは、接触ブロックを含む。支払の条件が、異なるＴＰＳＰによっ
て解除される場合には、接触情報は、条件群に対してではなく各条件に個別に添
付するのが好ましい。この要素は、買手１０６又は売手１０８が支払依頼文書の
条件を金融機関に知らせる場合のみに存在するのが好ましい。条件ブロックは、
好ましい実施形態においては、以下の属性を有する（表７７）。 表７７

【０１５６】 以下の表７８に挙げた検証規則は、好ましくは、条件ブロックの属性に適用さ
れる。 表７８ このシステムは、支払プロダクトとともに使用されるべき条件を定義すること
ができる。

【０１５７】 支払条件に関連して使用できる他の要素は、パッケージコンテンツである。パ
ッケージコンテンツ要素は、置換えシステムによってそれを誤解釈しないように
しつつＸＭＬ互換性を保証するように変形された埋め込みデータストリームの概
念をサポートする。それをシステムで使用するにより、ＴＰＳＰは、条件を解除
する時にサポート文書を提供することができる。全条件の解除が完了すると、支
払確認データとして搬送される文書が売手に転送されるのが好ましい。パッケー
ジコンテンツデータストリームは、好ましくは、そのコンテンツの識別、解読、
及び解釈を可能とする３つの標準属性を有しており、これら属性は、好ましくは
以下の表７９のように定義される。 表７９ ここでも、相応しい検証規則を、パッケージコンテンツの属性に適用すること
ができる。

【０１５８】 接触 接触ＤＴＤは、多くの文書定義において使用されるため、好ましくは、再利用
のために個別のＤＴＤで定義される。この構造は、これとともに使用されている
要素に関連した包括的な接触データを含む。通常、このデータは、所定取引を扱
う複数の個人に関する名前及び接触詳細を含む。従って、接触ブロックは、以下
の属性を有する（その内容は、表８０で明らかである）。 表８０

【０１５９】 相応しい検証規則を、接触の属性に適用することができる。接触データブロッ
クは、以下の属性も含むことができる（ここでも、これらの属性に関する内容は
、表８１から明らかである）。 表８１ また、検証規則を、これら属性に適切に適用することができる。

【０１６０】フィールド長とフォーマット 表８２は、好ましい実施形態における大部分の決済システムのデータフィール
ドに関するフィールド長及びフォーマットを要約したものである。 表８２

【０１６１】 エラーコード及びエラーテキスト 理由コードを決済システムで使用して、特定件の成否理由についても詳細を更
に提供することができる。理由コードの好ましい構造は、ｓｓｂｂｎｎである。
ここで、 ｓｓ＝エラーコード（例えば、００）を有するスキームの識別子、 ｂｂ＝そのスキーム内のＤＴＤブロック、 ｎｎ＝エラーの数 を示す。

【０１６２】 例えば、以下の表８３のｂｂブロックコードは、上記ＤＴＤに対して使用する
ことができる。 表８３

【０１６３】 また、以下の表８４は、理由コード群を要約したものである。 表８４

【０１６４】 以下、特定の支払プロセスの好ましい全体メッセージフロー、及び、他の取引
モデルにおけるそれらのメッセージフローを例示する取引ステップを、図６乃至
図８を参照して説明する。

【０１６５】支払要求メッセージフロー 支払要求を処理するための好ましい全体的メッセージフローを図６に示す。 このプロセスにおける最初のメッセージに先立って、買手１０６及び売手１０８
は、それぞれの証明書を介してお互いを識別し、売買契約を結ぶ。買手１０６は
、買手１０６から買手銀行１０２への支払要求によってこの取引に関する支払を
行うことに合意する。 次に、買手１０６は、支払要求の容認可能性を検討し、支払要求指図書の買手
欄に記入して（表４参照）、その支払要求指図書に署名する。次に、図６のメッ
セージ１に示すように、買手１０６は、支払要求指図書を売手１０８に送る。

【０１６６】 売手１０８は、受け取った支払要求指図書の容認可能性を検討し、支払要求指
図書の売手欄に記入し（表４参照）、補充された支払要求指図書に署名する。次
に、図６のメッセージ２に示すように、売手１０８は、その支払要求指図書を売
手銀行１０４に送る。 売手銀行１０４は、支払要求指図書の容認可能性を検討し、売手の証明書を検
証し、その要求指図書の売手銀行欄に記入し（表４参照）、補充された支払要求
指図書に署名する。次に、図６のメッセージ３に示すように、売手銀行１０４は
その支払要求指図書を買手銀行１０２に送る。

【０１６７】 買手銀行１０２は、支払要求指図書の容認可能性を検討し、メッセージ構文、
証明書と署名の有効性、及び、署名者の認証を検証する。次に、買手銀行１０２
は、これらの調査結果を付したサービス受領メッセージ（表９参照）を作成し、
このサービス受領に署名して、図６のメッセージ４に示すように売手銀行１０４
に送る。 売手銀行１０４は、サービス受領認書を検討し、必要に応じ、その詳細を補充
して、補充したメッセージに署名する。次に、このメッセージは、図６のメッセ
ージ５に示すように売手１０８に送られる。

【０１６８】 売手１０８は、サービス受領書を検討し、必要に応じその詳細を補充して、そ
れに署名する。次に、補充されたメッセージは、図６のメッセージ６に示すよう
に買手１０６に送られる。 好ましくは、支払要求指図書に特定された支払実行日時になった時、支払要求
指図は、銀行の既存支払設備を使用して実行される。 買手銀行１０２は、支払要求が実行されたことを示すために、支払実行の確認
書を作成する（表１１参照）。次に、買手銀行１０２は、このメッセージに署名
して、図６のメッセージ７に示すように売手銀行１０４に送る。支払実行の確認
書は、支払要求が成功裏に実行されたか否かを示す。支払実行の確認メッセージ
は、好ましくは、翌日の就業日最終時刻までに送られる。

【０１６９】 売手銀行１０４は、支払実行の確認書を検討し、必要に応じ、その詳細欄で支
払実行の確認書を補充し、補充されたメッセージに署名し、それを図６のメッセ
ージ８に示すように売手１０８に送る。 買手銀行１０２は、支払要求が成功裏に実行されたか否かを示すために、支払
実行の確認書を作成する。次に、買手銀行１０２は、このメッセージに署名して
、それを図６のメッセージ９に示すように買手１０６に送る。支払実行が不成功
であった場合には、売手１０８及び売手銀行１０４に送られたものより更に詳細
なその理由の説明書が買手に送られる。支払実行の確認メッセージは、少なくと
も翌日の営業日最終時刻までに送られるのが好ましい。

【０１７０】 好ましい実施形態においては、支払要求が実行されて銀行の支払設備に渡され
たことを明示する支払実行の確認メッセージを、買手銀行１０２がまだ送ってい
ないのであれば、買手１０６は、その支払要求を取消すことができる。支払要求
を取消すためには、買手１０６は、支払要求取消書を作成する（表７参照）。買
手は、支払要求取消書に署名し、それを図６のメッセージ１０に示すように買手
銀行１０２に送る。 好ましい実施形態においては、買手１０６による支払依頼の取消は認められて
いるので、好ましくは、決済サービスは、対応する支払依頼がまだ入手されてい
ない場合でも、全ての取消依頼を記憶している。これにより、既に無効とされた
遅延した支払依頼が識別されて実行されるのを阻止することができる。

【０１７１】 買手銀行１０２は、支払要求取消書の容認可能性を検討し、メッセージ構文、
証明書と署名の有効性、及び、署名者の認証を検証する。次に、買手銀行１０２
は、これらの調査結果を付したサービス受領メッセージ（表９参照）を作成する
。次に、買手銀行１０２は、サービス受領書に署名し、これを図６のメッセージ
１１に示すように買手１０６に送る。 買手銀行１０２は、支払要求取消依頼が受諾されたことを示すために、支払要
求取消の確認書を作成する（表１５参照）。次に、買手銀行１０２は、支払要求
取消書に署名し、これを図６のメッセージ１２に示すように買手１０６に送る。
支払要求取消メッセージの確認書は、好ましくは、翌日の営業日最終時刻までに
送られるべきである。

【０１７２】 買手銀行１０２は、支払要求取消依頼が承認されたことを示すために、支払要
求取消の確認書を作成する。買手銀行１０２は、図６のメッセージ１３に示すよ
うに支払要求取消の確認書に署名し、これを売手銀行１０４に送る。支払要求取
消メッセージは、好ましくは、翌日の営業日最終時刻までに送られるべきである
。 支払要求は、前述した３つのモデルで表すことができる。即ち、４コーナーモ
デルでは、買手から買手銀行への指図として、或いは、売手銀行によって決済シ
ステムに組み込まれる口座振替形式の指図として表すことができる。

【０１７３】４コーナーモデルにおける支払要求取引 ４コーナーモデルにおける典型的な支払要求取引は、以下のように発生する。
１．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する
。 ２．購買時点において、売手のソフトウェアは、買手１０６が記入するための支
払フォーマットを提示する。 ３．買手１０６は、買手署名データブロックに署名する。このブロックは、買手
データブロック、売手公開データブロック、交渉データブロック、及び、買手署
名詳細ブロックを含む。支払要求のために、買手署名データブロックは、債務形
式が「ＮＯＮＥ」に設定された債務ブロックを含むこともできる。（内部的又は
売手１０８のシステムを介して提供される設備による）買手の役割として、支払
を認証するために多くの署名を求めることができるという点に注目されたい。よ
って、それ以降の署名は、上記のデータブロックのみに署名するか、又は、既に
作成されている買手署名ブロックに追加して署名することができる。 ４．選択的に、売手１０８は、買手からのＰＫＣＳ＃７パッケージに含まれた買
手１０６の署名を調査することができる。通常、買手の指令を処理する前に買手
の署名を調査するのは買手銀行１０２の要件であるため、この段階は選択的なも
のである。 ５．適切な場合には、売手１０８は売手私有データを添付して、メッセージに署
名し、署名されたメッセージを売手銀行１０４に送る。 ６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、
売手１０８の証明書に示された認証及び権利を調査する。これらの調査が不成功
に終わった場合には、売手１０８に対して否定的なサービス受領書を送る。 ７．売手１０８が、売手公開データ又は売手私有データブロックのいずれかの口
座詳細を提供した場合には、売手銀行１０４は、これら口座詳細を検証する。売
手銀行１０４は、売手銀行データブロックのメッセージに口座詳細を添付するこ
とができる。売手銀行１０４は、取引の通貨に基づくコルレス銀行コードを添付
することもできる。売手銀行１０４は、メッセージから売手私有データブロック
を除去する。 ８．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて
、買手銀行１０２との精査応答取引を始めることを希望することができる。精査
応答取引を選択した場合には、売手銀行１０４は、システムヘッダーを含む支払
精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売
手銀行１０４の信任状を含むメッセージに署名する。 次に、買手銀行１０２は、売手銀行１０４の信任状を調査するとともに、依頼
されている支払プロダクトを処理できるかどうかを調査し、買手銀行１０２の検
証された信用状を含む売手に対する応答書に署名する。 売手銀行１０４は、買手銀行１０２によって提示される信任状を検証する。検
証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサー
ビス受領書を売手１０８に送る。 ９．売手銀行１０４は、そのメッセージに署名し、これを買手銀行１０２に送る
。 １０．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス
と、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支払
依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ていること
を裏付ける必要がある。これら調査が不成功に終わった場合には、買手銀行１０
２は、売手銀行１０４に対して否定的なサービス受領書を送る。これらの調査が
成功した場合には、買手銀行１０２は、顧客サービス発行に使用されるべき参照
符の表示を含む肯定的なサービス受領書を送る。売手銀行１０４は、そのサービ
ス受領書に再度署名し、これを売手１０８に送る。全ての受領書は、受領する組
織の署名付き証明書という新しい証拠を含む。 １１．買手銀行１０２は、口座関連の詳細も検証する。この検証は同時に行うこ
とができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０
２は、否定的な支払指図受領書を送る。口座関連詳細を同時に検証する場合には
、支払指図受領書は、サービス受領書と同じ文書で返信することができる。 １２．支払実行時には、買手銀行１０２は、買手１０６及び売手銀行１０４に、
その支払が実行されたことを通知する支払確認書を送る。決済システムが、支払
取引をうまく処理できない場合には、否定的な支払確認が作成される。売手銀行
１０４は、買手銀行１０２から資金が順調に入金されたことを確認するために、
支払確認書を送ることができる。

【０１７４】４コーナーモデルを使用した支払要求の取消 取消可能な支払要求に対しては、４コーナーモデルを使用して、支払を取消す
ことができる。買手銀行１０２は、取消依頼の成功について、買手１０６に対し
て同時に知らせるすべきである。この形式の取引における支払要求の典型的な取
消は、以下の通りである。 １．買手１０６及び売手１０８は、売手１０８のシステムを介して取消を調整す
る。 ２．購買時点において、売手１０８は、買手１０６が記入するための取消フォー
マットを提示する。 ３．買手１０６、取消買手署名データブロックに署名する。（内部的又は売手１
０８のシステムを介して提供される設備による）買手の役割として、支払を取消
すために多くの署名を求めることができるという点に注目されたい。よって、そ
れ以降の署名は、上記のデータブロックに署名するとともに、選択的に以前の即
ち先行の買手署名ブロックに署名することができる。 ５．選択的に、売手１０８は、買手１０６の署名を調査することができる。 ６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、
及び、売手１０８の証明書に示された認証及び権利を調査する。これらの調査が
不成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサ
ービス受領書を送る。 ７．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて
、買手銀行１０２との精査応答取引を始めることを希望することができる。売手
銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートに
よってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセ
ージに署名する。 買手銀行１０２は、売手銀行１０４の信任状を調査するとともに、依頼されて
いる支払プロダクトを処理できるかどうかを調査し、買手銀行１０２の検証信任
状を含む売手１０８に対する応答書に署名する。 売手銀行１０４は、買手銀行１０２によって提示された信任状を検証する。検
証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサー
ビス受領書を売手１０８に送る。 ８．売手銀行１０４は、取消メッセージに署名し、これを買手銀行１０２に送る
。 ９．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支
払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ているこ
との裏付けを行なう。 これらの調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０
４に対して否定的なサービス受領書を送る。これらの調査が成功した場合には、
買手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定
的なサービス受領書を送る。売手銀行１０４はそのサービス受領書に再度署名し
、これを売手１０８に送る。全ての受領書は、受領する組織の署名付き証明書と
いう新しい証拠を含む。 １０．次に、買手銀行１０２は、取消依頼を処理することになる。取消が成功裏
に実行された場合には、買手銀行１０２は、肯定的な取消確認書を売手銀行１０
４及び売手１０８に送る。取消が実行できない場合には、否定的な取消確認書が
発せられることになる。取消依頼が同時に処理できる場合には、取消確認書は、
サービス受領書でまかなうことができる。

【０１７５】 買手対買手銀行モデルにおける支払要求処理 買手対買手銀行取引では、購買技術又は他の買手技術で支払プロダクトを確実
に配信できる。支払要求のための典型的な買手対買手銀行取引は、以下のように
行われる。 １．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する
。 ２．買手１０６が、買手銀行１０２に支払要求を直接行う。 ３．買手１０６は、買手署名データブロックに署名する。このブロックは、買手
データブロック、売手公開データブロック、交渉データブロック、及び、買手署
名詳細ブロックを含む。支払要求の際、買手署名データブロックは、債務形式が
「ＮＯＮＥ」に設定された債務ブロックも含むことになる。 （内部的又は売手１０８のシステムを介して提供される設備による）買手の役
割として、支払を認証するために多くの署名を求めることができるという点に注
目されたい。よって、それ以降の署名は、上記のデータブロックのみに署名する
か、又は、既に作成されている買手署名ブロックに追加して署名することができ
る。 ４．買手１０６は、この文書に署名し、それを買手銀行１０２に送る。 ５．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付
いた支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得て
いることを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、買手１０６に対
して否定的なサービス受領書を送る。これら調査が成功した場合には、買手銀行
１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサー
ビス受領書を送る。 ６．買手銀行１０２は、口座関連詳細も検証する。この検証は同時に行うことが
できる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は
、否定的な支払指図受領書を送る。口座関連詳細が同時に検証される場合には、
支払指図受領書は、サービス受領書と同じ文書で送り返すことができる。 ７．支払実行時には、買手銀行１０２は、支払が実行されたことを通知する支払
確認書を買手１０６に送る。決済システムが支払取引をうまく処理できない場合
には、否定的な支払確認を発することができる。

【０１７６】買手対買手銀行モデルを使用しての支払要求の取消 取消可能な支払要求に関しては、買手対買手銀行モデルを使用して、支払を取
消すことができる。このモデルを使用した場合における、典型的な支払要求取消
は、以下の通りである。 １．買手１０６は、それ自身の内部システムを介して又はその金融機関のシステ
ムを介して支払要求の取消を試みる。 ２．買手１０６は、システムヘッダーと参照符ブロックとに署名する。買手の役
割として、支払を取消すために多くの署名を必要とするという点に注目されたい
。よって、それ以降の署名は、上記のデータブロックに署名するとともに、選択
的に以前の買手署名ブロックに署名することができる。 ３．買手１０６は、それを買手銀行１０２に送る。 ４．買手銀行１０８は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付
いた支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得て
いることを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、買手１０６に対
して否定的なサービス受領書を送る。これら調査が成功した場合には、買手銀行
１０２は、顧客サービス発行に使用される参照符の表示を含む肯定的なサービス
受領書を送る。 ５．次に、買手銀行１０２は、取消依頼を処理することになる。取消が成功裏に
実行された場合には、買手銀行１０２は、肯定的な取消確認書を買手１０６に送
る。取消が実行できない場合には、否定的な取消確認書が発せられることになる
。取消依頼が同時に処理できる場合には、取消確認書は、サービス受領書でまか
なうことができる。

【０１７７】口座振替モデルにおける支払要求取引 本発明における口座振替モデルの使用により、支払プロダクトを、口座振替形
式の支払を実現にする決済システムとともに使用することが可能となる。この形
式の取引は、個々の清算機関の規則に基づいて使用することができる。口座振替
モデルを使用した典型的な支払要求取引は、以下のように発生する。 １．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する
。商業取引は、売手銀行１０４が指図書を決済システムに受け渡すことによって
、口座振替形のネットワークを介して決済されることになる。 ２．買手１０６は、買手の口座から引き落とすことを売手に認証する指令を構成
する買手署名データブロックに署名する。この買手署名データブロックには、買
手データ、売手公開データ、及び、交渉データが含まれる。 ３．売手１０８は、選択的に、買手１０６の署名を調査する。これは推奨される
が義務的なものではない。買手１０６の口座からの引落しを認証するに先立ち、
買手銀行１０２は、買手１０６の署名を調査するのが好ましい。 ４．売手１０８は、必要に応じ、買手署名データに売手私有データブロックを添
付して署名し、これを売手銀行１０４に送る。 ５．売手銀行１０４は、売手の署名、メッセージの構文、及び、売手１０８の認
証を調査する。これら調査のいずれかが不成功に終わった場合には、売手銀行１
０４は、否定的なサービス受領書を売手１０８に送る。 ６．売手銀行１０４は、買手の署名付き指令書に署名し、これを買手銀行１０２
に送る。要求データを提出するに先立ち、対応する金融機関の身元を厳格に検証
する必要がある場合、売手銀行１０４は、選択的に、システム精査応答を開始で
きるという点に注目されたい。 買手銀行１０２は、買手１０６の署名、メッセージの構文、買手１０６の認証
を調査する。これら調査のいずれかが不成功に終わった場合には、買手銀行１０
２は、関連する売手銀行１０４に対し、売手に対するサービス受領書の関連受領
書として否定的なサービス受領書を送る。買手銀行１０２は、買手の指令を確認
して、買手１０６の口座からの引落しを認証する。 ７．肯定的なサービス受領書を受け取ると、売手銀行１０４は、適当なバックエ
ンド決済システムで支払（口座引落し）指図書を作成する。肯定的なサービス受
領書が売手１０８に送られる。 ８．支払指図を実行すると、売手銀行１０４は、選択的に、口座引落し指図が実
行されたことを売手１０８及び買手銀行１０２に知らせることができる。 ９．売手１０８の口座に資金を受け取ると、売手銀行１０４は、選択的に、資金
の受領を通知する支払確認書を売手１０８及び売手銀行１０４に送ることができ
る。

【０１７８】口座振替モデルを使用した支払要求の取消 口座振替ネットワークの規則及び／又は加盟銀行の方針に応じて、口座振替指
図書は、２当事者モデル（買手対買手銀行、及び、売手対売手銀行）又は４当事
者モデルにおいても取消すことができる。以下は、４当事者モデルにおける典型
的な取消を説明したものである。 １．買手１０６及び売手１０８は、売手のオンラインシステムを介して取消を進
める。 ２．購買時点において、売手１０８は、買手１０６が記入するための取消フォー
マットを提供する。 ３．買手１０６は、取消し対象の商業取引の参照符情報を含む取消買手署名デー
タブロックに署名する。（内部的又は売手１０８のシステムを介して提供される
設備による）買手の役割として、支払を取消すために多くの署名を必要とすると
いう点に注目されたい。よって、それ以降の署名は、上記のデータブロックに署
名するとともに、選択的に、以前の買手署名ブロックに署名することができる。
４．選択的に、売手１０８は、買手１０６の署名を調査することができる。 ５．売手１０８は、署名された文書を売手銀行１０４に送る。 ６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、
及び、売手１０８の証明書に示された認証及び権利を調査する。これら調査が不
成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサー
ビス受領書を送る。 ７．このしくみの規則により、売手銀行１０４が、支払を取消す前に買手１０６
の署名の有効性を調査する必要がある場合には、さもなければ売り手銀行が支払
の取消しを行なう下記段階８において、売手銀行１０４は、選択的に、取消確認
を買手銀行１０２及び売手に通知する。 ８．売手銀行１０４は、取消メッセージに署名し、それを買手銀行１０２に送る
。 ９．買手銀行１０８は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付
いた支払依頼書に対しては、買手銀行１０２は、取消依頼書が適正な認証を得て
いることを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４
に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手
銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的な
サービス受領書を送ることになる。そして、売手１０８は支払を取消す。この例
では、買手銀行１０２からの取消依頼に対応する応答がサービス受領メッセージ
である点に注目されたい。取消確認を開始するのは売手銀行１０４である。 売手銀行１０４は、サービス受領書に再度署名し、それを売手１０８に送る。
全ての受領書は、証明書に署名する受領組織の新しい証拠を含む。

【０１７９】支払債務メッセージフロー 支払債務を処理するための好ましい全体的メッセージフローを図７に示す。こ
のプロセスにおける最初のメッセージに先立ち、買手１０６及び売手１０８は、
それぞれの証明書を介して互いに身元確認し、売買契約を結ぶ。次に、買手１０
６は、買手１０６から売手銀行１０４への支払債務（表４及び表５参照）を利用
してその取引の支払を行うことに合意する。 買手１０６は、支払方法を受諾し、支払債務指図書の容認可能性を検討し、支
払債務指図書の買手欄に記入した後に、この支払債務指図書に署名する。次に、
この支払債務指図書は、図７のメッセージ１に示すように、売手１０８に送られ
る。

【０１８０】 売手１０８は、支払債務指図書の容認可能性を検討し、その要求欄（表４及び
表５参照）に記入した後に、この補充メッセージに署名して、これを図７のメッ
セージ２に示すように売手銀行１０４に送る。 売手銀行１０４は、この支払債務指図書の容認可能性を検討するとともに、売
手１０８の証明書を検証し、その要求欄（表４及び表５参照）に記入した後に、
この補充したメッセージに署名する。次に、このメッセージは、図７のメッセー
ジ３に示すように買手銀行１０２へ送られる。

【０１８１】 買手銀行１０２は支払債務指図書の容認可能性を検討するとともに、メッセー
ジ構文、証明書と署名の有効性、及び、署名者の認証を検証する。次に、買手銀
行１０２は、これら調査結果を備えたサービス承認メッセージ（表９を参照のこ
と）を生成する。次に、買手銀行１０２は、図７のメッセージ４に示すように、
サービス受領書に署名してこれを売手銀行１０４に送る。

【０１８２】 売手銀行１０４は、サービス受領書を検討し、必要に応じ、その詳細欄を使用
してこれを補充した後に、この補充したメッセージに署名する。次に、図７のメ
ッセージ５に示すように、補充されたサービス承認メッセージは、売手１０８に
送られる。 売手は、サービス受領書を検討し、必要に応じ、その詳細欄を使用してこれを
補充した後に、この補充したメッセージに署名する。次に、図７のメッセージ６
に示すように、補充されたサービス承認は、買手１０６に送られる。 買手銀行１０２は、支払債務が受諾されたか否かを示すために、支払債務受諾
確認メッセージ（表１３を参照のこと）を作成する。次に、買手銀行１０２は、
支払債務受諾確認書に署名し、図７のメッセージ７に示すように、これを売手銀
行１０４に送る。

【０１８３】 売手銀行１０４は、支払債務受諾確認書を検討し、必要に応じ、その詳細欄を
使用してそれを補充した後に、補充したメッセージに署名して、それを図７のメ
ッセージ８に示すように売手１０８に送る。 買手銀行１０２は、支払実行に関するこの確認書を検討し、必要に応じ、その
詳細欄を使用してこれを補充した後に、補充したメッセージに署名して、図７の
メッセージ９に示すようにこれを売手１０８に送る。 支払債務指図書に指定された日時になった時、支払債務は、銀行の既存支払施
設を利用して実行されるのが好ましい。

【０１８４】 買手銀行１０２は、この支払債務が履行されたことを示すために、支払実行確
認書（表１１参照）を作成する。次に、買手銀行１０２は、このメッセージに署
名し、図７のメッセージ１０に示すようにこれを売手銀行１０４に送る。支払実
行確認書は、この支払債務が成功裏に履行されたか否かを表す。少なくとも、支
払実行確認メッセージは、翌日の営業日最終時刻までに送られるのが好ましい。

【０１８５】 売手銀行１０４は、この支払実行確認メッセージを検討し、その詳細欄を使用
して支払実行確認情報を補充した後に、この補充したメッセージに署名してそれ
を図７のメッセージ１１に示すように売手１０８に送る。 買手銀行１０２は、支払要求が実行されたことを示す支払実行確認メッセージ
を作成する。次に、買手銀行１０２は、このメッセージに署名し、図７のメッセ
ージ１２に示すようにこれを買手１０６に送る。支払実行確認メッセージは、こ
の支払債務が成功裏に履行されたか否かを表す。支払実行が不成功に終わった場
合には、売手１０８及び売手銀行１０４に送られたものより詳細なその理由の説
明が買手１０６に送られる。少なくとも、支払実行確認メッセージは、翌日の営
業日最終時刻までに送られるのが好ましい。

【０１８６】４コーナーモデルにおける支払債務取引 支払債務は、４コーナーモデル又は買手対買手銀行モデルにおいて使用するこ
とができる。４コーナーモデルにおける典型的な支払債務取引は、以下の通りで
ある。 １．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する
。 ２．購買時点において、売手のソフトウェアは、買手１０６が記入するための支
払フォーマットを提供する。 ３．買手１０６は、買手署名データブロックに署名する。このブロックは、買手
データブロック、売手公開データブロック、交渉データブロック、及び、買手署
名詳細ブロックを含む。支払債務に関して、買手署名データブロックは、「買手
」に設定された債務形式の債務ブロックも含むことになる。 （内部的又は売手１０８のシステムにより提供される設備を介しての）買手の
役割として、支払いを認証するために多くの署名を求めることができるという点
に注目されたい。よって、それ以降の署名は、上記のデータブロックにのみ署名
するか又は既に作成されている買手署名ブロックに追加して署名することができ
る。選択的に、売手１０８は、買手１０６の署名を調査することができる。支払
処理において買手銀行１０２が買手１０６の証明書を検証する要件は、一般的な
ものである。 ４．適切な場合には、売手１０８は、売手私有データを添付した後に、メッセー
ジに署名し、この署名付きメッセージを売手銀行１０４に送る。 ５．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、
売手１０８の証明書に示された認証及び権利を調査する。これらの調査が不成功
に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサービス
受領書を送る。 ６．売手１０８が、売手公開データブロック又は売手私有データブロックに口座
詳細を提供した場合には、売手銀行１０４は、これら口座詳細を検証することに
なる。売手銀行１０４は、売手銀行データブロックのメッセージに口座詳細を添
付する。また、売手銀行１０４は、取引の通貨に基づくコルレス銀行コードを添
付する。売手銀行１０４は、このメッセージから売手私有データブロックを除去
する。 ７．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて
、買手銀行１０２との精査応答取引を始めることを希望することができる。売手
銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートに
よってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセ
ージに署名することになる。 買手銀行１０２は、売手銀行１０４の信任状を調査し、依頼されている支払プ
ロダクトを処理できるか否かを調査し、買手銀行１０２の検証された信任状を含
む売手１０８への応答に署名することになる。 売手銀行１０４は、買手銀行１０２が提示した信任状を検証することになる。
検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサ
ービス受領メッセージを売手１０８に送ることになる。 ８．売手銀行１０４は、そのメッセージに署名し、これを買手銀行１０２に送る
。 ９．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支
払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ているこ
とを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４
に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手
銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的な
サービス受領書を送ることになる。 売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送
る。全ての受領書は、受領組織の署名付き証明書という新しい証拠を含む。 １０．買手銀行１０２は、口座関連詳細も検証する。この検証は同時に行うこと
ができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２
は、否定的な支払指図受領書を送ることになる。口座関連詳細が同時に検証され
る場合には、支払指図受領書は、サービス受領書と同じ文書で返送することがで
きる。 １１．支払実行時には、買手銀行１０２は、支払が行なわれたことを通知する支
払確認書を買手１０６及び売手銀行１０４に送ることができる。決済システムが
支払取引を成功裏に処理することができない場合には、否定的な支払確認書を発
することができる。売手銀行１０４は、買手銀行１０２から資金の受け取りが成
功裏に完了したことを確認するために支払確認書を送ることができる。

【０１８７】４コーナーモデルを使用した支払債務の取消 支払債務に関しては、以下の４コーナーモデルプロセス又は売手による取消に
対する積極的な同意を含む拘束のないプロセスを使用して支払取消しを行なうこ
とができる。 １．買手１０６及び売手１０８は、売手のシステムを介して取消を進める。 ２．購買時点において、売手１０８は、買手１０６が記入するための支払フォー
マットを提供する。 ３．買手１０６は、取消買手署名データブロックに署名する。（内部的又は売手
のシステムを介して提供される設備による）買手の役割として、支払を取消すた
めに多くの署名を求めることができるという点に注目されたい。よって、それ以
降の署名は、上記のデータブロックに署名するとともに、選択的に、以前の買手
署名ブロックに署名することができる。 ４．選択的に、売手１０８は、買手１０６の署名を調査することができる。 ５．売手１０８は、署名した文書を売手銀行１０４に送る。 ６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、
及び、売手１０８の証明書に示された認証及び権利を調査する。これら調査が不
成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサー
ビス受領書を送る。 ７．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて
、買手銀行１０２との精査応答取引を始めることを希望することができる。精査
応答取引を選択した場合には、売手銀行１０４は、システムヘッダーを含む支払
精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売
手銀行１０４の信任状を含むメッセージに署名することになる。 買手銀行１０２は、売手銀行１０４の信任状を調査し、依頼されている支払プ
ロダクトを処理できるか否かを調査し、買手銀行１０２の検証された信任状を含
む売手１０８への応答に署名する。 売手銀行１０４は、買手銀行１０２によって提示された信任状を検証すること
になる。検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通
知するサービス受領書を売手１０８に送る。 ８．売手銀行１０４は、取消メッセージに署名し、これを買手銀行１０２に送る
。 ９．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支
払依頼書に対しては、買手銀行１０２は、その取消依頼書が適正な認証を得てい
ることを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４
に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手
銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的な
サービス受領書を送ることになる。 売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送
る。全ての受領書は、受領組織の署名付き証明書という新しい証拠を含む。 １０．次に、買手銀行１０２は、取消依頼を処理することになる。取消が成功裏
に実行された場合には、買手銀行１０２は、肯定的な取消確認書を売手銀行１０
４及び売手１０８に送ることができる。取消が実行できない場合には、否定的な
取消確認書が発せられることになる。取消依頼が同時に処理できる場合には、取
消確認書は、サービス受領書でまかなうことができる。 取引が識別できない場合には、否定的な取消依頼文書が作成されることになる
。

【０１８８】 買手対買手銀行モデルにおける支払債務取引 買手対買手銀行モデルにおける典型的な支払債務取引は、以下のように行われ
る。 １．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する
。 ２．買手１０６は、支払債務を直接買手銀行１０２に依頼する。 ３．買手１０６は、買手署名データブロックに署名する。買手１０６は、売手１
０８の口座詳細の欄を含み、且つ、売手１０８の同意を得て初めて取消すことが
できる売手１０８に対する債務を買手１０６が引き受けることを示す売手公開デ
ータを記入することになる。支払債務に関して、債務ブロックの債務形式属性は
、「買手」に設定される。 買手の役割として、支払を認証するために多くの署名を求めることができると
いう点に注目されたい。それ以降の署名は、上記のデータブロックのみに署名す
るか、又は既に作成されている買手署名ブロックに追加して署名することができ
る。 ４．買手１０６は、文書に署名し、これを買手銀行１０２に送る。 ５．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付
いた支払債務依頼書に関して、買手銀行１０２は、その依頼書が適正な認証を得
ていることを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、否定的なサービ
ス受領書を買手１０６に送る。これら調査が成功した場合には、買手銀行１０２
は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受
領書を送ることになる。 支払債務に関し、買手銀行１０２は、買手１０６がその債務を引き受けたこと
を示すサービス受領書の入った債務確認ブロックを含むことになる。 ６．買手銀行１０２は、口座関連詳細も検証する。この検証は同時に行うことが
できる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は
、否定的な支払指図受領書を送る。口座関連詳細が同時に検証される場合には、
支払指図受領書は、サービス受領書と同じ文書で返送することができる。 ７．支払実行時には、買手銀行１０２は、支払が行なわれたことを通知する支払
確認書を買手１０６に送ることができる。決済システムが支払取引を成功裏に処
理することができない場合には、否定的な支払確認書を発することができる。 通常、支払債務は、買手対買手銀行モデルを使用して取消すことはできない。

【０１８９】保証付き支払債務メッセージフロー 好ましい実施形態において、保証付き支払債務プロダクトは、保証付き支払債
務指図メッセージが支払債務指図書の代わりとなるとともに、保証付き支払債務
受諾確認メッセージが支払債務受諾確認の代わりとなる点を除けば、図７に示し
たものと同じ全体メッセージフローを用いることができる。

【０１９０】４コーナーモデルにおける保証付き支払債務取引 ４コーナーモデルにおいて、典型的な保証付き支払債務処理は、以下のように
行われる。 １．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する
。 ２．購買時点において、売手のソフトウェアは、買手１０６が記入するための支
払フォーマットを提供する。これは、保証付き支払債務が適切に売手に申請され
るという要件を含む。 ３．買手１０６は、買手署名データブロックに署名する。（内部的又は売手１０
８のシステムを介して提供される設備による）買手の役割として、支払を認証す
るために多くの署名を求めることができる点に注目されたい。保証付き支払債務
に関して、債務ブロックの債務形式属性は、「銀行」に設定される。 ４．選択的に、売手１０８は、買手１０６の署名を調査することができる。通常
、支払処理においては、買手銀行１０２が買手１０６の証明書を検証することは
、重要な要件である。 ５．適切な場合には、売手１０８は、売手私有データを添付した後に、メッセー
ジに署名し、この署名付きメッセージを売手銀行１０４に送る。 ６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、
及び、売手１０８の証明書に示された認証及び権利を調査する。これらの調査が
不成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサ
ービス受領書を送る。 ７．売手１０８が、売手公開データデータブロック又は売手私有データブロック
で口座詳細を提供した場合、売手銀行１０４は、これらの口座詳細を検証するこ
とになる。売手銀行１０４は、売手銀行データブロックにおいてメッセージに口
座詳細を添付することができる。売手銀行１０４は、取引の通貨に基づくコルレ
ス銀行コードを添付することもできる。売手銀行１０４は、メッセージから売手
私有データブロックを除去する。 ８．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて
、買手銀行１０２との精査応答取引を始めることを希望することができる。精査
応答取引を選択した場合には、売手銀行１０４は、システムヘッダーを含む支払
精査ブロックで構成され、ルートによってタイムスタンプされ且つ検証された売
手銀行１０４の信任状を含むメッセージに署名する。 買手銀行１０２は、売手銀行１０４の信任状を調査し、依頼されている支払プ
ロダクトを処理できるか否かを調査するとともに、買手銀行１０２の検証された
信任状を含む売手への応答に署名することになる。 売手銀行１０４は、買手銀行１０２によって提示された信任状を検証すること
になる。検証が不成功に終わった場合には、売手銀行１０４は、その不成功を通
知するサービス受領書を売手１０８に送る。 ９．売手銀行１０４は、このメッセージに署名し、これを買手銀行１０２に送る
。 １０．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス
、及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた
支払依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を得ている
ことを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４
に対して否定的なサービス受領書を送る。これら調査が成功した場合には、買手
銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的な
サービス受領書を送る。 売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送
る。全ての受領書は、受領組織の署名付き証明書という新しい証拠を含む。 １１．買手銀行１０２は、口座関連詳細も検証する。この検証は同時に行うこと
ができる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２
は、否定的な支払指図受領書を送ることになる。口座関連詳細が同時に検証され
る場合、支払指図受領書は、サービス受領書と同じ文書で返送することができる
。 １２．買手銀行１０２は、内部リスク方針に沿って、カード／法人に対して現在
指定された上限額を調査することになる。買手銀行１０２が、債務責任を受諾し
、債務を保証する場合には、肯定的な債務確認が買手銀行１０２から売手銀行１
０４に送られる。買手銀行１０２が債務に同意しない場合には、否定的な債務確
認応答が買手銀行１０２から売手銀行１０４に送られる。この応答は、翌日の営
業日最終時刻めでに送られるべきであり、このようなリスクの同時的受諾をサポ
ートする金融機関システムにおいて、サービス受領書と同時に送ることができる
。 １３．支払実行時には、買手銀行１０２は、支払が行なわれたことを通知する支
払確認書を買手１０６及び売手銀行１０４に送ることができる。決済システムが
支払処置を成功裏に処理できない場合には、否定的な支払確認を発することがで
きる。売手銀行１０４は、買手銀行１０２から資金が成功裏に受領されたことを
確認するために、支払確認書を送ることができる。

【０１９１】４コーナーモデルを使用した保証付き支払債務の取消 保証付き支払債務に関し、以下の４コーナーモデルプロセス又は売手による取
消に対する積極的な同意を含む拘束のないプロセス使用して、支払の取消を行な
うことができる。 １．買手１０６及び売手１０８は、売手のシステムを介して取消を進める。 ２．購買時点において、売手１０８は、買手１０６が記入するための支払フォー
マットを提供する。 ３．買手１０６は、取消買手署名データブロックに署名する。（内部的又は売手
のシステムを介して提供される設備による）買手の役割として、支払を取消すた
めに多くの署名を求めることができるという点に注目されたい。よって、それ以
降の署名は、上記のデータブロックに署名するとともに、選択的に、先行する買
手署名ブロックに署名することができる。 ４．選択的に、売手１０８は、買手１０６の署名を調査することができる。 ５．売手１０８は、署名された文書を売手銀行１０４に送る。 ６．売手銀行１０４は、売手１０８の署名、売手１０８の証明書のステータス、
及び、売手１０８の証明書に示された認証及び権利を調査する。これら調査が不
成功に終わった場合には、売手銀行１０４は、売手１０８に対して否定的なサー
ビス受領書を送る。 ７．選択的に、売手銀行１０４は、売手銀行１０４自身のリスクモデルに応じて
、買手銀行１０２との精査応答取引を始めることを希望することができる。売手
銀行１０４は、システムヘッダーを含む支払精査ブロックで構成され、ルートに
よってタイムスタンプされ且つ検証された売手銀行１０４の信任状を含むメッセ
ージに署名することになる。買手銀行１０２は、売手銀行１０４の信任状を調査
し、依頼されている支払プロダクトを処理できるか否かを調査する。売手銀行１
０４は、買手銀行１０２によって提示された信任状を検証するであろう。検証が
不成功に終わった場合には、売手銀行１０４は、その不成功を通知するサービス
受領書を売手１０８に送る。 ８．売手銀行１０４は、取消メッセージに署名し、これを買手銀行１０２に送る
。 ９．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手の証明書に示された認証及び権利を調査する。複数の署名の付いた支
払依頼書に対しては、買手銀行１０２は、その取消依頼書が適正な認証を得てい
ることを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、売手銀行１０４
に対して否定的なサービス受領書を送る。これらの調査が成功した場合には、買
手銀行１０２は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的
なサービス受領書を送ることになる。 売手銀行１０４は、そのサービス受領書に再度署名し、これを売手１０８に送
る。全ての受領書は、受領組織の署名付き証明書という新しい証拠を含む。 １０．次に、買手銀行１０２は、取消依頼を処理することになる。取消が成功裏
に実行された場合には、買手銀行１０２は、肯定的な取消確認書を売手銀行１０
４及び買手１０６に送る。取消が実行できない場合には、否定的な取消確認書が
発せられることになる。取消依頼が同時に処理できる場合には、取消確認書は、
サービス受領書でまかなうことができる。 取引が識別できない場合には、否定的な取消依頼文書が発せられることになる
。

【０１９２】 買手対買手銀行モデルにおける保証付き支払債務取引 買手対買手銀行モデルにおける典型的な保証付き支払債務取引は、以下ように
行われる。 １．買手１０６及び売手１０８は、売手のオンラインシステムを介して対話する
。 ２．買手１０６は、支払債務を、直接、買手銀行１０２に依頼する。 ３．買手１０６は、買手署名データブロックに署名する。買手１０６は、売手１
０８の口座詳細情報の項目を含み、且つ、売手１０８の同意を得て初めて取消す
ことができる売手１０８に対する債務を買手１０６が引き受けることを示す売手
公開データを記入することになる。保証付き支払債務に関し、債務要素の債務形
式属性は、「銀行」に設定される。 買手の役割として、支払を認証するために多くの署名を求めることができると
いう点に注目されたい。よって、それ以降の署名は、上記のデータブロックのみ
に署名するか、又は、既に作成されている買手署名ブロックに追加して署名する
ことができる。 ４．買手１０６は、文書に署名し、これを買手銀行１０２に送る。 ５．買手銀行１０２は、買手１０６の署名、買手１０６の証明書のステータス、
及び、買手１０６の証明書に示された認証及び権利を調査する。複数の署名の付
いた支払債務依頼書に対しては、買手銀行１０２は、その依頼書が適正な認証を
得ていることを裏付ける必要がある。 これら調査が不成功に終わった場合には、買手銀行１０２は、否定的なサービ
ス受領書を買手１０６に送る。これら調査が成功した場合には、買手銀行１０２
は、顧客サービス発行に使用されるべき参照符の表示を含む肯定的なサービス受
領書を送ることになる。 支払債務に関し、買手銀行１０２は、買手１０６がその債務を引き受けたこと
を示す債務確認ブロックを提供することになる。金融機関が債務依頼を同時的に
処理できる場合、債務確認は、サービス承認に含めることができる。また、債務
確認も、翌日の就業日最終時刻までに提供されるべきである。 ６．買手銀行１０２は、口座関連詳細を検証する。この検証は同時に行うことが
できる点に注目されたい。検証が不成功に終わった場合には、買手銀行１０２は
、否定的な支払指図受領書を送る。口座関連詳細が同時に検証される場合には、
支払指図受領書は、サービス受領書と同じ文書で返送することができる。 ７．支払実行時には、買手銀行１０２は、支払が行なわれたことを通知する支払
確認書を買手１０６に送る。決済システムが支払取引を成功裏に処理できなかっ
た場合には、否定的な支払確認書を作成することができる。 通常、保証付き支払債務は、買手対買手銀行モデルを使用して取消すことはで
きない。

【０１９３】条件付き支払 前にも説明したように、３つの条件付き支払プロダクトを形成するために、前
述の３つの支払プロダクト全てに条件を付すことができる。

【０１９４】条件付き支払における条件の管理 条件及び債務の設定と管理との関係を規定するために、基本原則を本発明に適
用することができる。好ましい実施形態においては、支払指図書に条件を使用す
るための以下の基本原則を適用する。 １．先ず、全ての条件は、主として、支払グループによって定義され公開される
。好ましい条件コード群とその記述は、前に述べた通りである。 ２．各条件は、信頼できるサービス提供者（ＴＳＳ）によって管理される。 ３．第三者のサービス提供者は、条件を解除する、即ち、その条件が満たされた
という記述にシステムトークンを使用して署名することになる。支払に付随する
諸条件が解除されると、その指図が実行されることになる。 ４．各条件は、売手１０８によって提示されるか、又は、買手１０６によって入
力される。 ５．この条件は、２つの部分を有する。即ち、（システムによって定義されるよ
うな）条件の包括的な記述、及び、特定取引に関する詳細である。 ６．支払における各条件は、その条件が解除されたことを確認するために署名す
ることになる機関である第三者のサービス提供者に割り振る必要がある。この機
関は、企業体、その企業体内部のグループ、又は、個人とすることができる。Ｔ
ＳＰＳ組織は、その機関が署名することに対して適切な規制を実施するのが好ま
しい。ＴＰＳＰは、少なくとも電子メールアドレスによって識別されるべきであ
る。 ７．条件管理は、取引と独立した状態に維持される。 ８．ＴＰＳＰ証明書の検証は、ＴＰＳＰからの応答を処理する過程に含む必要が
ある。ＴＰＳＰは、第三者機関によって証明書を発行してもらうことができる。
９．ＴＰＳＰは、自分の金融機関によって、金融機関により提出された証明書の
ステータス調査を行なえるようにすべきである。 １０．条件を解除する時、ＴＰＳＰによって添付文書を付けることができる。こ
れは、買手銀行１０２によって処理されず、買手１０６のシステムに対する受領
書に含まれるべきである。支払に適用する全ての条件（条件群）が解除されると
、全ての添付文書が転送される。 １１．支払と条件との関係は、１対多数の関係である。１つの支払は、これが実
行される前に満たされるべき多数の条件を持つことができる。それら条件は、単
一の支払以外に適用されることはない。 １２．条件付き支払プロダクトの取消のための規則は、非条件付き支払の取消の
ための規則に従う。条件管理システムは、条件付き支払が取消されるか否かを知
らされるべきである。ＴＰＳＰは、条件が取消されたことを示すメッセージを、
金融機関から受け取ることになる。

【０１９５】条件付き支払における条件のライフサイクル 好ましくは、条件のライフスタイルは以下のように決定される。 １．支払に付随する条件は、支払交渉の一部として、買手１０６と売手１０８と
の間で合意される。条件管理システム（ＴＳＳ）に受諾される前の各条件及び条
件群のステータスは「依頼受」となる。 ２．４コーナーモデルにおいては、各条件は、買手１０６によって署名され、売
手１０８によって再署名される。買手対買手銀行モデルにおいては、買手１０６
が、適用する条件の詳細を売手１０８に提供する。 ３．売手銀行１０４は、文書の処理に先立って、各条件を局所的に記録する。 ４．支払に付随する各条件は、買手銀行１０２の条件管理システムに記録される
。 ５．条件設定確認文書が作成され、売手銀行１０４に（又は、買手対買手銀行モ
デルにおいては買手１０６に）送られ、条件管理システム（ＴＳＳ）に各条件が
存在することを確認する。この条件ステータスは、「未完了」である。 ６．条件管理システムは、支払に付随する条件が存在することを第三者のサービ
ス提供者（ＴＰＳＰ）に知らせる。 ７．ＴＰＳＰは、条件管理システムに更新メッセージを送り、支払に付随する条
件の中でそのＴＰＳＰに割り振られ終了した１つの条件のステータスを更新する
ことができる。支払条件文書が、条件のステータスの変化を、その取引の全関係
者に知らせるために使用される。 ８．終了すると、支払に付随する条件のステータスは、「解除」となる。全ての
条件が解除されると、条件群ステータスは、「解除済」となる。 ９．ＴＰＳＰによる解除に関する条件に付けられたいずれの添付文書も、全ての
条件が解除されてその支払指図が解かれるまでは、売手１０８に送られるべきで
はない。 １０．各条件は有効期間を有する。条件の有効期間が満了した場合には、条件群
を解除することはできず、「有効期間満了」とマークされるべきである。支払条
件文書は、条件の有効期間が満了したことを知らせるために、取引の各参加者に
送られるべきである。 １１．条件付き支払が取消された場合には、支払に付随する全ての条件は取消さ
れたとマークされる。ＴＰＳＰには、全てのステータスフィールドを「取消済」
と設定した支払条件文書を使用して知らせる必要がある。

【０１９６】条件付き支払における条件を規制する規則 更に、以下の規則が、本発明の条件付き債務の処理を規制するのが好ましい。
１．債務は、条件が付されている場合でも受諾しなくてはならない。 ２．条件は、債務が成功裏に登録されるまで、登録されるべきではない。債務が
拒否される場合には、否定的な条件設定確認書を買手１０６（買手対買手銀行モ
デルの場合）又は売手銀行１０４（４コーナーモデルの場合）に送らなくてはな
らない。 ３．債券の所有権は、各条件が解除されるまでは移転できない。 ４．各条件の有効期限が満了するか又は取消された場合には、債務管理機能に、
その条件付き支払に対して保留された制限を解くことを知らせなくてはならない
。

【０１９７】条件付き支払要求メッセージフロー 好ましい実施形態においては、条件付き支払要求プロダクトのためのメッセー
ジフローの多くは、条件付き支払要求指図書を図６のメッセージ１に示す支払要
求指図書の代わりとする点を除けば、上述した支払要求プロダクトのためのメッ
セージフローと同じである。しかし、追加的な処理が、ある条件発生に対してこ
れを支払要求の実行を反映させるために付加される。好ましくは、各条件は、Ｔ
ＳＳによって設定され、支払が行われる前に複数のＴＰＳＰによってこれら条件
が満たされなくてはならない。これらの追加的処理の一実施形態が、図８に示さ
れている。

【０１９８】 条件詳細は、買手銀行１０２によってＴＳＳに供給される。この場合、トラス
ＴＳＳは、条件が何時満たされたかを買手銀行１０２に知らせるため、買手銀行
１０２はそれに応答することができる。その代わりに、買手銀行１０２がＴＳＳ
として機能することもできる。 図８に戻って説明すると、信頼できるサービス提供者は、支払が実行できる前
に、第三者のサービス提供者が満す必要のある条件を示す条件通知メッセージ（
上記表８参照）を作成する。次に、信頼できるサービス提供者は、条件通知メッ
セージに署名し、図８のメッセージ１に示すように、これを第三者のサービス提
供者に送る。

【０１９９】 第三者のサービス提供者は、条件通知メッセージの容認可能性を検討し、メッ
セージ構文、証明書と署名の有効性、及び、署名者の認証を検証する。次に、第
三者のサービス提供者は、これらの調査の結果によりサービス受領メッセージを
作成する。次に、第三者のサービス提供者は、サービス受領書に署名し、図８の
メッセージ２に示すように、信頼できるサービス提供者に送る。 第三者のサービス提供者は、条件履行プロセスにおける完了した段階について
、信頼できるサービス提供者に知らせるために、条件更新メッセージを作成する
。第三者のサービス提供者は、このメッセージに署名し、これを図８のメッセー
ジ３に示すように、信頼できるサービス提供者に送る。各条件に対して複数の更
新メッセージを送ることができるという点に注目すべきである。

【０２００】 信頼できるサービス提供組織は、条件更新メッセージの容認可能性を検討し、
メッセージ構文、証明書と署名の有効性、及び、署名者の認証を検証する。次に
、信頼できるサービス提供者は、これらの調査の結果により、サービス受領書を
作成する（上記表９参照）。次に、信頼できるサービス提供者は、サービス受領
書に署名し、図８のメッセージ４に示すように、第三者のサービス提供者に送る
。 第三者のサービス提供者は、条件プロセスの履行について信頼できるサービス
提供者に知らせるために、条件告知メッセージを作成する（上記した表１６を参
照のこと）。このメッセージは、肯定的なメッセージにも、否定的なメッセージ
にもすることができる。第三者のサービス提供者は、このメッセージに署名し、
図８のメッセージ５に示すように、これを信頼できるサービス提供者に送る。

【０２０１】 信頼できるサービス提供組織は、条件告知メッセージの容認可能性を検討し、
メッセージ構文、証明書と署名の有効性、署名者の認証を検証する。次に、信頼
できるサービス提供者は、これらの調査の結果により、サービス受領書を作成す
る（上記表９参照）。信頼できるサービス提供組織は、サービス受領書に署名し
、図８のメッセージ６に示すように、これを第三者のサービス提供者に送る。

【０２０２】 条件付き支払債務メッセージフロー 好ましい実施形態においては、条件付き支払債務プロダクトのためのメッセー
ジフローの多くは、条件付き支払債務指図書を図７のメッセージ１に示した支払
債務指図書の代わりとする点を除けば、上述した支払債務のためのメッセージフ
ローと同じである。しかし、追加的な処理が、ある条件の発生に対しそれを支払
要求の実行に反映するために付加される。好ましくは、各条件は、信頼できるサ
ービス提供者によって設定され、支払が行われる前に複数の第三者のサービス提
供者によって満たされなくてはならない。好ましい実施形態においては、条件プ
ロセスは、図８に関連して説明した処理と同じものとすることができる。

【０２０３】保証付き／条件付き支払債務メッセージフロー 好ましい実施形態においては、保証付き／条件付き支払債務プロダクトは、保
証付き保証付き／支払債務指図書を図７のメッセージ１に示した条件付き支払債
務指図書の代わりとするとともに、保証付き／条件付き支払債務受諾確認メッセ
ージを条件付き支払債務受諾確認書の代わりとする点を除けば、上述した条件付
き支払債務に関連して説明したメッセージフローと同じものとすることができる
。 これまでに詳しく説明したように、メッセージフォーマットは、決済システム
はグローバル的な性格により、国境を超えた互換性を確保するために、標準を公
開するのを固守するのが好ましい。例えば、異なる言語に適応させるために、マ
ルチバイト文字群を使用するのが好ましい。

【０２０４】 また、好ましくは、支払取引には、決済システムの各関係者によって、デート
スタンプ及びタイムスタンプが付される。好ましい実施形態においては、タイム
スタンプは、ユニバーサルタイムコード（Ｕ．Ｔ．Ｃ．）フォーマットに基づき
第三者の信頼できるタイムサーバによって提供される。 好ましい実施形態において、支払関連の全てのメッセージは、信頼される認証
局によって発行される証明書を使用することによって保証される。好ましい実施
形態において、これら証明書は、メッセージにデジタル署名するために、メッセ
ージ認証、完全性、及び非否認性を提供するために使用される。 好ましい実施形態においては、決済システムの各関係者の間で交換される全て
の情報の機密性が維持され、情報は不正なアクセスから保護される。ＳＳＬｖ３
／ＴＬＳを使用して、少なくとも１２８ビット強度の暗号化を採用するのが好ま
しい。

【０２０５】 好ましい実施形態においては、本決済システムは、包括的なエラー処理を提供
し、好ましくは、このエラー処理は、以下の範囲のエラーをカバーする。即ち、
メッセージ構文、メッセージの署名検証／認証、適正でない銀行識別コード等の
メッセージデータ、及び、支払認証を含む（但し、これに限定されない）メッセ
ージ関連のエラー；設定条件を満足できないことを含む（但し、これに限定され
ない）メッセージ固有のエラー；及び、伝送の問題及び時間切れの問題を含む（
ただし、これに限定されない）決済システム基盤構造のエラーを包含する。 好ましい実施形態において、全ての支払開始メッセージは、等羃である。例え
ば、支払要求指図書を送信したが、指定された制限時間内にサービス受領書が受
信されない場合には、このメッセージの対象とする受信者にこの依頼メッセージ
について２度同じ行動をさせることなく、その支払要求指図書を再び送ることが
できる。 また、本発明のシステムは、上述したように受領書の自動処理を含むのが好ま
しいが、各参加者は、従来の現金管理システム；ウェブを利用した銀行業務サー
ビス；音声、ファックス、及びその他の電話サービス；又はＳＭＳ、ＷＡＰ，及
びその他の移動体サービス；等の多くのチャンネルを介しての受領書の提供を選
択することもできる。 以上、本発明を具体的な実施形態に関連して説明したが、当業者にとって、以
上の説明に照らして、数多くの置換、変更、及び変形が想定されるのは明らかで
ある。

【図面の簡単な説明】

【図１】 本システムに用いる４コーナーモデルの好ましい実施形態のブロック図である
。

【図２】 好ましくは４コーナーモデルにおける各実体に設けられる構成要素を示すブロ
ック図である。

【図３】 第１の決済シナリオの構成及び流れの総合図である。

【図４】 第２の決済シナリオの構成及び流れの総合図である。

【図５】 第３の決済シナリオの構成及び流れの総合図である。

【図６】 支払指図書を処理するためのメッセージの流れに関する好ましい実施形態を示
す図である。

【図７】 支払債務を処理するためのメッセージの流れに関する好ましい実施形態を示す
図である。

【図８】 支払条件を処理するためのメッセージの流れに関する好ましい実施形態を示す
図である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 9/32 Ｈ０４Ｌ 9/00 ６７５Ｂ ６７５Ｄ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ， ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ， ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，Ｃ Ａ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ， ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，Ｋ Ｅ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ， ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ， ＺＡ，ＺＷ (71)出願人 シュトルヒ オリヴァー ドイツ連邦共和国 65779 ケルクハイム ホルナゥエシュトラーセ 172アー (71)出願人 ランズマン ペーテル ドイツ連邦共和国 85402 クランツベル ク フリッツ−ベンドル−シュトラーセ 10 (71)出願人 ジェッター ウィリアム アメリカ合衆国 カリフォルニア州 94610 ピードモント トレストル グレ ン ロード 1877 (71)出願人 ウォン マーガレット カナダ エル３ ６ケイ９ ユニオンヴィ ル ハーパーズ クロフト 26 (71)出願人 キャメロン ウィリアム カナダ エム４エル ３ケイ６ トロント ノルマンデイ ブールヴァード 117 (72)発明者 マッケンニー メアリー アメリカ合衆国 ペンシルヴァニア州 19382 ウェスト チェスター オークボ ーン ロード 700 (72)発明者 ウォルヒ マルクス ドイツ連邦共和国 デー61476 クロンベ ルク テュルペンヴェク 29 (72)発明者 ベイカー ウォルター ザ サード アメリカ合衆国 イリノイ州 60093 ウ ィネトカ ウィネトカ アベニュー 414 (72)発明者 シュトルヒ オリヴァー ドイツ連邦共和国 65779 ケルクハイム ホルナゥエシュトラーセ 172アー (72)発明者 ランズマン ペーテル ドイツ連邦共和国 85402 クランツベル ク フリッツ−ベンドル−シュトラーセ 10 (72)発明者 ジェッター ウィリアム アメリカ合衆国 カリフォルニア州 94610 ピードモント トレストル グレ ン ロード 1877 (72)発明者 ウォン マーガレット カナダ エル３ ６ケイ９ ユニオンヴィ ル ハーパーズ クロフト 26 (72)発明者 キャメロン ウィリアム カナダ エム４エル ３ケイ６ トロント ノルマンデイ ブールヴァード 117 Ｆターム(参考） 5J104 AA09 LA03 LA06 PA10 PA11

Claims (19)

【特許請求の範囲】
1. 【請求項１】 ルート実体と第１参加者と第２参加者と前記第１参加者の顧
   客である第１顧客と前記第２参加者の顧客である第２顧客とを含み、各々がデジ
   タル証明書及びこれに関連する秘密鍵を備えた複数の実体で構成された４コーナ
   ーモデルにおいて決済サービスを提供する方法であって、 前記第１顧客が、支払期日を指定する支払指図書の買手欄に記入する段階、 前記第１顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、 前記第１顧客が、前記支払指図書を前記第２顧客に送信する段階、 前記第２顧客が、前記支払指図書の売手欄に記入する段階、 前記第２顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、 前記第２顧客が、前記支払指図書を第２参加者に送信する段階、 前記第２参加者が、前記支払指図書の第２参加者欄に記入する段階、 前記第２参加者が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、 前記第２参加者が、前記支払指図書を第１参加者に送信する段階、及び 前記第１参加者が、前記支払期日に、前記支払指図書の指図を実行する段階を
   含むことを特徴とする方法。
2. 【請求項２】 前記支払指図書は、支払要求指図書であることを特徴とする
   請求項１に記載の方法。
3. 【請求項３】 前記支払指図書は、支払債務指図書であることを特徴とする
   請求項１に記載の方法。
4. 【請求項４】 前記支払指図書は、条件付き支払要求指図書であることを特
   徴とする請求項１に記載の方法。
5. 【請求項５】 前記支払指図書は、条件付き支払債務指図書であることを特
   徴とする請求項１に記載の方法。
6. 【請求項６】 前記支払指図書は、保証付き支払債務指図書であることを特
   徴とする請求項１に記載の方法。
7. 【請求項７】 前記支払指図書は、保証付き／条件付き支払債務指図書であ
   ることを特徴とする請求項１に記載の方法。
8. 【請求項８】 前記第１顧客は、決済サービスに関する役割及び責任を規定
   する第１参加者との契約を履行することを特徴とする請求項１に記載の方法。
9. 【請求項９】 前記第２顧客は、決済サービスに関する役割及び責任を規定
   する第２参加者との契約を履行することを特徴とする請求項１に記載の方法。
10. 【請求項１０】 決済サービスを提供する方法であって、 買手に、各々が関連を持つ支払指示書である複数の支払手段を提供する段階、 前記買手が、前記複数の支払手段の１つを選択する段階、 前記買手によって選択された前記支払手段に関連するとともに支払期日を指定
    する支払指図メッセージの少なくとも第１欄に前記買手が記入する段階、 前記第１顧客が、前記買手のデジタル証明書に対応する秘密鍵を用いて、前記
    支払指図メッセージに署名する段階、 前記署名された支払指図メッセージが、銀行によって受信される段階、及び 前記銀行が、支払期日に、前記支払指図メッセージの指図を実行する段階を含
    むことを特徴とする方法。
11. 【請求項１１】 前記選択された支払手段は、支払要求であることを特徴と
    する請求項１０に記載の方法。
12. 【請求項１２】 前記選択された支払手段は、支払債務であることを特徴と
    する請求項１０に記載の方法。
13. 【請求項１３】 前記選択された支払手段は、条件付き支払要求であること
    を特徴とする請求項１０に記載の方法。
14. 【請求項１４】 前記選択された支払手段は、条件付き支払債務であること
    を特徴とする請求項１０に記載の方法。
15. 【請求項１５】 前記選択された支払手段は、保証付き支払債務であること
    を特徴とする請求項１０に記載の方法。
16. 【請求項１６】 前記選択された支払手段は、保証付き／条件付き支払債務
    であることを特徴とする請求項１０に記載の方法。
17. 【請求項１７】 前記支払手段は、譲渡可能であることを特徴とする請求項
    １０に記載の方法。
18. 【請求項１８】 参加者と前記参加者の顧客である顧客とを含み、各々がデ
    ジタル証明書及びこれに関連する秘密鍵を備えた複数の実体で構成される買手対
    参加者モデルにおいて決済サービスを提供する方法であって、 前記顧客が、支払期日を指定する支払指図書の買手欄に記入する段階、 前記顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、 前記顧客が、前記支払指図書を前記参加者に送信する段階、 前記参加者が、前記支払指図書の参加者欄に記入する段階、 前記参加者が、自分の秘密鍵で、前記支払指図書に署名する段階、及び 前記参加者が、支払期日に、前記支払指図書の指図を実行する段階を含むこと
    を特徴とする方法。
19. 【請求項１９】 参加者と第１顧客と前記参加者の顧客である第２顧客とを
    含み、各々がデジタル証明書及びこれに関連する秘密鍵を備えた複数の実体で構
    成される口座振替モデルにおいて決済サービスを提供する方法であって、 前記第１顧客が、支払期日を指定する支払指図書の買手欄に記入する段階、 前記第１顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、 前記第１顧客が、前記支払指図書を第２顧客に送信する段階、 前記第２顧客が、前記支払指図書の売手欄に記入する段階、 前記第２顧客が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、 前記第２顧客が、前記支払指図書を前記参加者に送信する段階、 前記参加者が、前記支払指図書の参加者欄に記入する段階、 前記参加者が、自分の秘密鍵を用いて、前記支払指図書に署名する段階、及び 前記参加者が、支払期日に、前記支払指図書の指図を実行する段階を含むこと
    を特徴とする方法。