JP2020024719A - ポイントツーポイントトランザクション処理を記録する方法及びシステム - Google Patents

Abstract

【課題】ポイントツーポイント支払トランザクションを処理する方法及びシステムを提供する。【解決手段】処理方法は、支払トランザクションに係わる第１データメッセージを受信するステップ、第１、第２及び第３データ要素を、第１データメッセージに属する記録へのリンクと共に格納するステップ、支払トランザクションに係わる第２データメッセージを生成するステップ、第１データ要素を、第２データメッセージに属する記録へのリンクと共に格納するステップ、支払トランザクションに係わる第３データメッセージを生成するステップ、第１データ要素及び第２データ要素を、第３データメッセージに属する記録へのリンクと共に格納するステップ及び第１データメッセージと、第２データメッセージと、第３データメッセージと、を、グラフィカルユーザインターフェイス（ＧＵＩ）上に表示するために送信するステップを含む。【選択図】図７

Description

関連出願の相互参照

本願は、2016年3月21日に出願された米国仮特許出願第62/311,062号、2016年12月12日
に出願された米国仮特許出願第62/433,118号、及び2016年12月15日に出願された米国仮特
許出願第62/434,824号に対する優先権を主張するものである。当該出願は、その全体が、
参照によって本明細書に取り込まれる。

本開示は、ポイントツーポイントトランザクションの記録、処理、及び表示に関し、具
体的には、当事者の取引ディレクトリと、トランザクションの元帳と、個人間（P2P）及
び企業間（B2B）の集計された電子支払トランザクションの、銀行口座と単一のトランザ
クション処理システムを使用する第三者との間の決済と、を安全な環境において提供する
ことに関する。

ビジネスは、技術、プロセス及び人材の複雑なエコシステムを内部的に頼るのみでなく
、数千のB2Bソリューションプロバイダやネットワークに依存して、ビジネスの請求書を
管理し、又はほぼ毎日支払を行うか、支払を受領する。金融トランザクションに関わるエ
ンティティの数が増加するにつれて、日々処理される電子支払トランザクションの数が増
加し、その数は一日で数千億の規模にさえ達する場合も多い。例えば、請求書による購入
に対して、バイヤは、注文に係わる発注書（PO）、請求書、及び注文に係る出荷確認を検
証した後でのみ、サプライヤに対する支払を承認する。これは、「三方一致」として知ら
れている。承認されると、支払が、正式に許可され、スケジュールが設定され、支出され
る。多くの場合では、エンティティは、支払手段によって電子支払トランザクションを行
なう。その場合トランザクションは、第１支払ネットワークによって処理され、次いで決
済され、実際の資金は、第２支払ネットワークによって、発行銀行と加盟店銀行との間で
交換される。

現在、既存の決済システムは、個々の支払トランザクションの決済を使用して作動する
ことが多い。例えば、トランザクションが処理された後、発行銀行は、その単一のトラン
ザクションのための資金を、決済ネットワークに移転する。決済ネットワークが、次いで
、その単一のトランザクションのための資金を、加盟店銀行に転送する。たいていの企業
は、金融会社でないため、又は財務面で規制されているため、B2Bトランザクションの刷
新は、当事者間の支払フローを手付かずのままにしていた。その結果、２１世紀のB2Bコ
ラボレーションは、扱いにくく、未接続の、ほとんど変わっていない２０世紀半ばのB2B
支払プラットフォーム上に位置している。処理される、従って決済されるトランザクショ
ンの数が増加するにつれて、決済システム及び金融機関の処理能力にかかる負担が増加し
、同様に、日々発生せねばならない資金移転の数も増加する。

図１０Ａ及び図１０Ｂ（以下、まとめて図１０と称する）に示すように、現行のB2Bシ
ステムには多くの問題がある。例えば、支払を監視、作成、又は加速する未接続の方法が
多すぎる。サプライヤは、新規顧客の信用リスクを決定するために、自ら費用の嵩む労力
を払わせられる可能性がある。サプライヤは、顧客の支払意思、支払調整、又は支払のタ
イミングへのリアルな視認性を有していない可能性がある。費用のかかる回収活動及び労
力によれば、これらが軽減されるかもしれない。バイヤは、サプライヤの銀行口座を維持
しなければならない。バイヤは、複数の支払人のために、より高額の銀行手数料に直面す
る可能性がある。

更に、多くの場合では、そのように膨大な量の個々のトランザクションを決済するため
に要求される演算能力及び処理能力が、既存の決済システム及び金融機関にとって過剰な
までに大きくなる、という可能性もある。従って、処理量並びに通信量及び資金移転量を
低減可能である破壊的（disruptive）な統一決済システムを提供する、技術的ソリューシ
ョンに対する必要性が存在する。また統一決済システムは、決済システム及び金融機関に
消費されるリソース並びに処理能力を低減する助けともなり、電子支払トランザクション
をより効率的かつ費用対効果に優れて決済するであろう。

本開示は、ポイントツーポイントトランザクションを記録、処理、及び表示するシステ
ム及び方法を記載する。システムは、会社に対して、非カード型支払を経由して、サプラ
イヤ又はベンダに支払う能力を提供する。例えば、サプライヤがその顧客に請求明細書を
送るとき、典型的には、サプライヤはクレジットカードでの支払を受け付けない。サプラ
イヤは、３０日又は６０日等の条件でサプライヤに支払うために、請求書を購入者に送付
する。たいていのサプライヤは、３０日以内に資金を受領し、サプライヤが３０日のうち
に支払われるよう希望するであろう。しかしながら従来技術のシステムでは、たいていの
サプライヤは、支払転記及び支払が実際にどのようになされるかに関して、視認性を有さ
ない。これは、キャッシュフローの問題につながる。システムは、関係する全ての当事者
に対してトランザクションの視認性が明確なプラットフォームを提供することによって、
これらの問題を回避するものである。

システムは、貨幣を移動し、貨幣移動周辺の金融ソリューションを提供し、金融システ
ム周辺の役務を評価及び／又は採点するソリューションを提供する。B2B支払トランザク
ションの処理に関する追加情報は、David Messinaらによって、2014年8月5日に出願され
た、「企業間支払トランザクションを処理する方法及びシステム」と題する、米国特許出
願公開第20160042327号に見ることが出来る。当該出願は、その全体が、参照によって本
明細書に取り込まれるものである。

一実施形態では、ポイントツーポイント支払トランザクションを記録する方法は、次の
ステップを含む。すなわち、支払トランザクションに係る第１トランザクションメッセー
ジを、処理システムの受信装置によって受信するステップであって、第１トランザクショ
ンメッセージを、１つ以上のアプリケーションプログラムインターフェイス（API）を使
用して標準に従ってフォーマットし、第１トランザクションメッセージが、少なくとも、
トランザクション明細を格納するよう構成された第１データ要素と、主要アカウント番号
を格納するよう構成された第２データ要素と、レシピエントアカウント番号を格納するよ
う構成された第３データ要素と、を含む少なくとも複数のデータ要素を含むステップ。第
１、第２及び第３データ要素を、第１トランザクションメッセージに属する記録へのリン
クと共に処理サーバの商用データベースに格納するステップであって、リンクが、第１ト
ランザクションメッセージに基づいて文書へのアクセスを提供するステップ。支払トラン
ザクションに係る第２トランザクションメッセージを、処理システムの生成モジュールに
よって生成するステップであって、第２トランザクションメッセージを、１つ以上のAPI
を使用して標準に従ってフォーマットし、第２トランザクションメッセージが、支払額を
格納するよう構成された第１データ要素を含む少なくとも複数のデータ要素を含み、支払
額が、少なくともトランザクション明細に基づくステップ。第１データ要素を、第２トラ
ンザクションメッセージに属する記録へのリンクと共に処理サーバの商用データベースに
格納するステップであって、リンクが、第２トランザクションメッセージに基づいて文書
へのアクセスを提供するステップ。第２トランザクションメッセージを、処理システムの
送信装置によって、主要アカウント番号に係るトランザクションアカウントと関連付けら
れた第１金融機関に電子送信するステップ。支払トランザクションに係る第３トランザク
ションメッセージを、処理システムの生成モジュールによって生成するステップであって
、第３トランザクションメッセージを、１つ以上のAPIを使用して標準に従ってフォーマ
ットし、第３トランザクションメッセージが、決済額を格納するよう構成された第１デー
タ要素と、レシピエントアカウント番号を格納するよう構成された第２データ要素と、を
含む少なくとも複数のデータ要素を含み、決済額が、少なくともトランザクション明細に
基づくステップ。第１データ要素及び第２データ要素を、第３トランザクションメッセー
ジに属する記録へのリンクと共に処理サーバの商用データベースに格納するステップであ
って、リンクが、第３トランザクションメッセージに基づいて文書へのアクセスを提供す
るステップ。第３トランザクションメッセージを、処理システムの送信装置によって、レ
シピエント（受取）アカウント番号に係るトランザクションアカウントと関連付けられた
第２金融機関に電子送信するステップ。第１トランザクションメッセージと、第２トラン
ザクションメッセージと、第３トランザクションメッセージとを、処理システムの送信装
置によって、処理システムの送信装置によって、グラフィカルユーザインターフェイス（
GUI）上に表示するために、電子送信するステップ。

別の実施形態では、ポイントツーポイント支払トランザクションを記録するシステムは
、以下を含む。すなわち、支払トランザクションに係る第１トランザクションメッセージ
を受信するよう構成された、処理システムの受信装置であって、第１トランザクションメ
ッセージが、１つ以上のアプリケーションプログラムインターフェイス（API）を使用し
て標準に従ってフォーマットされ、また第１トランザクションメッセージが、少なくとも
、トランザクション明細を格納するよう構成された第１データ要素と、主要アカウント番
号を格納するよう構成された第２データ要素と、レシピエントアカウント番号を格納する
用構成された第３データ要素と、を含む少なくとも複数のデータ要素を含む受信装置。第
１、第２及び第３データ要素を、第１トランザクションメッセージに属する記録へのリン
クと共に格納するよう構成された、処理サーバの商用データベースであって、リンクが、
第１トランザクションメッセージに基づいて文書へのアクセスを提供する商用データベー
ス。支払トランザクションに係る第２トランザクションメッセージを生成するよう構成さ
れた、処理システムの生成モジュールであって、第２トランザクションメッセージが、１
つ以上のAPIを使用して標準に従ってフォーマットされ、また支払額を格納するよう構成
された第１データ要素を含む少なくとも複数のデータ要素を含み、支払額が、少なくとも
トランザクション明細に基づく生成モジュール。第１データ要素を、第２トランザクショ
ンメッセージに属する記録へのリンクと共に格納するよう構成された、処理サーバの商用
データベースであって、リンクが、第２トランザクションメッセージに基づいて文書への
アクセスを提供する商用データベース。第２トランザクションメッセージを、主要アカウ
ント番号に係るトランザクションアカウントと関連付けられた第１金融機関に電子送信す
るよう構成された、処理システムの送信装置。支払トランザクションに係る第３トランザ
クションメッセージを生成するよう構成された、処理システムの生成モジュールであって
、第３トランザクションメッセージが、１つ以上のAPIを使用して標準に従ってフォーマ
ットされ、また決済額を格納するよう構成された第１データ要素及びレシピエントアカウ
ント番号を格納するよう構成された第２データ要素を含む少なくとも複数のデータ要素を
含み、決済額が、少なくともトランザクション明細に基づく生成モジュール。第１データ
要素及び第２データ要素を、第３トランザクションメッセージに属する記録へのリンクと
共に格納するよう構成された、処理サーバの商用データベースであって、リンクが、第３
トランザクションメッセージに基づいて文書へのアクセスを提供する商用データベース。
処理システムの送信装置であって、第３トランザクションメッセージを、レシピエントア
カウント番号に係るトランザクションアカウントと関連付けられた第２金融機関に送信す
るよう構成され、また第１トランザクションメッセージと、第２トランザクションメッセ
ージと、第３トランザクションメッセージとを、グラフィカルユーザインターフェイス（
GUI）上に表示するために、送信するよう構成された送信装置。

本開示の範囲は、添付の図面と共に解釈されると、例示的な実施形態についての下記の
詳細な記載から最も良く理解される。図面には次の図が含まれる。
例示的実施形態による、ポイントツーポイントランザクションを記録、処理、及び表示するハイレベルのシステムアーキテクチャのブロック図である。 例示的実施形態による、ポイントツーポイントランザクションを記録、処理、及び表示する図１のコンピューティング装置のブロック図である。 例示的実施形態による、単一のコンピューティング装置、及びエンティティシステムを使用してポイントツーポイントランザクションを決済するプロセスのフロー図である。 例示的実施形態による、単一のコンピューティング装置、及びエンティティシステムを使用してポイントツーポイントランザクションを記録、処理、及び表示するプロセスのフロー図である。 例示的実施形態による、複数のコンピューティング装置、及び第三者のネットワークを使用してポイントツーポイントランザクションを記録、処理、及び表示するプロセスのフロー図である。 例示的実施形態による、図１の処理システムにおいて、複数のコンピューティング装置を使用してポイントツーポイントランザクションを決済するプロセスのフロー図である。 例示的な実施形態による、図１の処理システムにおいて、複数のコンピューティング装置を使用してポイントツーポイントランザクションを決済するプロセスのフロー図である。 例示的実施形態による、図１の処理システムにおいて、ポイントツーポイントランザクションを記録、処理、及び表示するプロセスの図である。 例示的実施形態による、図１の処理システムにおいて、ポイントツーポイントランザクションを記録、処理、及び表示するプロセスの図である。 例示的実施形態による、ポイントツーポイント支払トランザクションを処理する例示的な方法のフローチャートである。 例示的実施形態による、支払トランザクションの処理のフロー図である。 例示的実施形態による、コンピュータシステムアーキテクチャのブロック図である。 現行の企業間支払システムの問題を示す図である。 現行の企業間支払システムの問題を示す図である。

下記の詳細な説明から、本開示の更なる適用分野が自明である。例示的実施形態の詳細
な説明は、例示目的のみを意図としており、本開示の範囲を制限することを意図しない。

用語解説
アクワイアラ：販売者に代わって支払カードトランザクションを処理してよいエンティ
ティである。アクワイアラは、販売者に代わって支払カードトランザクションを処理する
権限を与えられた銀行又は他の金融機関であってよい。多くの場合では、アクワイアラは
、受取人として活動する販売者と信用供与を行なってよい。イシュアによって提供される
信用供与に対する受取人である消費者が、アクワイアラによって代理される販売者と支払
カードによってトランザクションを行う場合では、アクワイアラはイシュアと資金を交換
してよい。

イシュア：受取人のために信用照会状又は信用供与を設定し（例えば開設し）、受取人
が振り出す手形を、信用照会状又は信用供与に明示された額に対して引き受けるエンティ
ティ。多くの場合では、イシュアは、銀行、又は信用供与を開設する権限を与えられた他
の金融機関であってよい。場合によっては、信用供与を受取人に拡大できる任意のエンテ
ィティを、イシュアと見なすことができる。イシュアによって開設される信用供与は、支
払アカウントの形式で表され、支払カードの使用を介して、受取人が引き出すことができ
る。関連技術の当業者には自明であるように、またイシュアは、デビット口座、プリペイ
ド口座、電子財布口座、普通預金口座、当座預金口座等の、追加のタイプの支払アカウン
トを消費者に提供してもよい。またイシュアが、そのような口座にアクセスする、及び／
又はそのような口座を利用する物理的又は非物理的手段であるデビットカード、プリペイ
ドカード、自動取引装置カード、電子財布、小切手等を、消費者に提供してもよい。

支払カード：販売者へ提供される支払アカウントと関連付けられたカード又はデータで
あり、関連付けられた支払アカウントを介して金融トランザクションに資金を供給するた
めのものである。支払カードは、クレジットカード、デビットカード、特定店舗のクレジ
ットカード、ストアドバリューカード、プリペイドカード、フリートカード（fleet card
）、仮想支払番号、仮想カード番号、制御支払番号（controlled payment number）等を
含んでよい。支払カードは物理的なカードであり、販売者へ提供されてよいし、関連付け
られた支払アカウントを示すデータ（これは、例えばスマートフォン又はコンピュータ等
の通信機器に格納される）であってよい。例えば、場合によっては、支払アカウント番号
を含むデータはトランザクションを処理するための支払カードとして考慮されてよい。当
該トランザクションは、関連付けられた支払アカウントによって資金を供給される。場合
によっては、適用可能な場合、小切手が支払カードとして考慮されてよい。

支払ネットワーク：現金代替物の使用によって、貨幣移転で使用されるシステム又はネ
ットワーク。支払ネットワークは、様々な異なるプロトコル及び手順を使用して、多様な
タイプのトランザクションのために貨幣移転を処理してよい。支払ネットワークを介して
実行され得るトランザクションは、製品又は役務の購入と、クレジット購入と、デビット
トランザクションと、資金移転と、口座引き落としと、を含んでよい。支払ネットワーク
は、現金代替物によってトランザクションを実行するよう構成されてよく、これは支払カ
ードと、信用紹介状と、小切手と、トランザクションアカウントと、を含んでよい。支払
ネットワークとして実行されるネットワーク又はシステムの例は、MasterCard（登録商標
）、VISA（登録商標）、Discover（登録商標）、American Express（登録商標）、PayPal
（登録商標）等によって運営されるものを含む。本開示での、「支払ネットワーク」との
用語は、エンティティとしての支払ネットワークと、物理的支払ネットワーク（例えば支
払ネットワークを構成する機器、ハードウエア及びソフトウエア）の両方を指す。

支払レール（Payment Rail）：支払トランザクションの処理、並びにトランザクション
メッセージ及び支払ネットワークと支払ネットワークに相互接続された他のエンティティ
との間の他の同様のデータを通信する際に使用される、支払ネットワークと関連付けられ
たインフラストラクチャ。支払レールが、支払ネットワーク、及び他の関連するエンティ
ティの間の相互接続を確立するために使用されるハードウエアを備えてよい。他の関連す
るエンティティとは、例えば、金融機関、ゲートウエイプロセッサ等である。場合によっ
ては、また支払レールが、通信ハードウエアの特別プログラム、及び支払レールを構成す
る装置を介する等、ソフトウエアの影響を受ける可能性もある。例えば、支払レールが、
明示的に構成されたコンピューティング装置を含んでもよい。コンピューティング装置が
、トランザクションメッセージのルーティングのために特別に構成されてよい。トランザ
クションメッセージは、下記に詳説するように、支払レールを介して電子送信される特別
にフォーマットされたデータメッセージであってよい。

支払トランザクション：貨幣又は他の金銭的利得が一方のエンティティから他方のエン
ティティに交換される２つのエンティティ間のトランザクション。関連技術の当業者には
自明であるように、支払トランザクションは、商品又は役務の購入、借り方の返済、又は
金銭的利得の他の何らかの交換のための資金の移転であってよい。場合によっては、支払
トランザクションは、クレジットカードトランザクション等の支払カード及び／又は支払
アカウントを介して資金を供給されるトランザクションを指してよい。そのような支払ト
ランザクションは、イシュア、支払ネットワーク、及びアクワイアラを介して処理されて
よい。そのような支払トランザクションを処理するプロセスは、許可、バッチ処理、清算
、決済、及び資金の供給のうちの少なくとも１つを含んでよい。許可は、消費者が販売者
に支払明細を提供することと、販売者からアクワイアラに（例えば支払明細を含む）トラ
ンザクション明細を提出することと、トランザクションに資金を供給するために使用され
る消費者の支払アカウントのイシュアと支払明細とを確認することと、を含んでよい。バ
ッチ処理は、アクワイアラに配信するために、許可されたトランザクションを他の許可さ
れたトランザクションと共にバッチでまとめて格納することを指してよい。清算は、処理
するために、バッチ処理されたトランザクションをアクワイアラから支払ネットワークへ
送信することを含んでよい。決済は、イシュアの受取人が関係するトランザクションに対
して、支払ネットワークによりイシュアから引き落とす（debit）ことを含んでよい。い
くつかの場合では、イシュアは支払ネットワークを介して、アクワイアラに支払ってよい
。他の場合では、イシュアはアクワイアラに直接に支払ってよい。資金の供給は、清算さ
れ且つ決済された支払トランザクションに対する、アクワイアラから販売者への支払を含
んでよい。上述したステップの順序及び／又は分類は、支払トランザクション処理の一部
として実行されることが、関連技術の当業者には自明であろう。

トランザクションアカウント：トランザクションへ資金を供給するために使用され得る
金融アカウント（例えば、当座預金口座、普通預金口座、クレジット口座、仮想支払口座
等）である。トランザクションアカウントは消費者と関連付けられてよく、これは、支払
アカウントと関連付けられた任意の適切なタイプのエンティティ（人、家族、人の集まり
、会社、政府エンティティ等を含んでよい）であってよい。場合によっては、トランザク
ションアカウントは、仮想的（例えばPayPal（登録商標）等によって運営されるアカウン
ト等）であってよい。

ポイントツーポイントトランザクションを処理及び決済するシステム
図１は、例示的実施形態による、ポイントツーポイントランザクションを記録、処理、
及び表示するハイレベルのシステムアーキテクチャ１００のブロック図である。

システムは、処理システム１０２を含んでよい。処理システム１０２が、１つ以上のコ
ンピューティング装置を備え、ポイントツーポイント電子支払トランザクションを処理及
び決済するよう構成されてよい。ポイントツーポイント電子支払トランザクションは、第
１トランザクションアカウントから第２トランザクションアカウントへの支払のために行
なわれる金融トランザクションであってよい。場合によっては、ポイントツーポイントラ
ンザクションが、追加の支払手段及び対応する番号を使用せずに、それぞれのトランザク
ションアカウントと直接に関連付けられたアカウント番号を使用して、処理システム１０
２を介して、処理及び決済されてよい。例えば、ポイントツーポイントランザクションは
、カードと関連付けられた異なる番号を有する可能性があるクレジットカード又は他のタ
イプの支払カードを使用せずに、トランザクションアカウント番号を介して行なわれても
よい。

いくつかの実施形態では、処理システム１０２は、単一のコンピューティング装置を介
して、本開示で説明する機能を実行するよう構成されてよい。他の実施形態では、処理シ
ステム１０２は、複数のコンピューティング装置を含んでよい。複数のコンピューティン
グ装置の各々は、処理システム１０２の特定の機能を実行するよう構成されてよい。例え
ば、図１に示すように、処理システム１０２が、少なくとも、第１コンピューティング装
置１０４及び第２コンピューティング装置１０６を備えてよい。第１コンピューティング
装置１０４及び第２コンピューティング装置１０６が、以下に詳述するように、第１エン
ティティから第２エンティティへの支払のために、ポイントツーポイントランザクション
の処理及び決済を実行するよう構成されてよい。

図１に示すシステムにおいて、センダシステム１０８は、ポイントツーポイントランザ
クションの処理のため、支払をレシピエントシステム１１０に送付するために、処理シス
テム１０２を利用してよい。センダシステム１０８及びレシピエントシステム１１０は、
電子通信を実行するよう構成されたエンティティと関連付けられたコンピューティングシ
ステムであってよい。当該電子通信は、本開示で説明する機能を達成すること、センダシ
ステム１０８又はそれと関連するエンティティ（例えば、差出企業又は差出消費者のよう
なセンディングエンティティ）から、レシピエントシステム１１０又はそれと関連するエ
ンティティ（例えば、受取企業又は受取消費者のようなレシピエントエンティティ）へ資
金を送ること、に適している。センダシステム１０８及びレシピエントシステム１１０は
、例えば、アカウント管理、在庫管理、支払勘定及び／又は受取勘定等のために使用され
るコンピューティングシステムを含んでよい。

センダシステム１０８は、レシピエントシステム１１０へのトランザクション額の支払
のために、ポイントツーポイント支払トランザクションを開始してよい。いくつかの場合
では、センダシステム１０８が、トランザクション額のレシピエントシステムへの送金の
ために、送金依頼を直接に処理システム１０２に電子送信してよい。他の場合では、セン
ダシステム１０８がセンダネットワーク１１２を利用してよい。センダネットワーク１１
２が、金銭移転エンティティ（例えばWestern Union）、又はトレード若しくはサプライ
チェインネットワーク（例えばAriba）のような、ポイントツーポイント支払トランザク
ションを開始する際に使用するのに適するエンティティ及び／又はシステムであってもよ
い。場合によっては、センダシステム１０８が、センダネットワーク１１２を使用してポ
イントツーポイント支払トランザクションを開始する個人であってよい。

ポイントツーポイント支払トランザクションの開始の一部として、センダシステム１０
８又はセンダネットワーク１１２が、送金依頼が重畳されたデータ信号を、処理システム
１０２に電子送信してよい。送金依頼は、少なくとも、支払われるトランザクション額と
、支払に資金を供給するためにセンダが使用するトランザクションアカウントと関連付け
られた主要アカウント番号と、送金された資金を受領するためにレシピエントが使用する
トランザクションアカウントと関連付けられたレシピエントアカウント番号と、を含んで
よい。センダが使用するトランザクションアカウントは、センダ機関１１４を介してセン
ダに発行されてよい。センダ機関１１４が、発行銀行又は他の適切なエンティティのよう
な発行金融機関であってよい。発行金融機関が、ポイントツーポイント支払トランザクシ
ョンに資金を供給する際に使用するために、センディングエンティティにトランザクショ
ンアカウントを発行するよう構成されてよい。場合によっては、センダ機関１１４が、送
金依頼を処理システム１０２に電子送信するよう構成されてよい。そのような場合、セン
ダ又はセンダシステム１０８は、センダ機関１１４を使用して、ポイントツーポイント支
払トランザクションを開始してよい。例えば、センダはコンピューティング装置（例えば
ディスクトップコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、
テーブルコンピュータ、携帯電話、スマートフォン、スマートウオッチ、ウエアラブルコ
ンピューティングデバイス、埋め込み型コンピューティングデバイス等）を使用して、送
金依頼に含まれるべき情報が重畳された又さもなければエンコードされたデータ信号を、
ウエブページ又はセンダ機関１１４と関連付けられたアプリケーションプログラム等を介
して、センダ機関１１４に電子送信してよい。

処理システム１０２は、送金依頼を受信してよい。支払がレシピエントシステム１１０
になされるとき、処理システム１０２が、センダ機関１１４に送信する資金供給依頼を生
成してよく、資金の移転を開始してよい。処理システム１０２は、少なくとも、支払を行
なうトランザクションアカウントと関連付けられた主要アカウント番号と、なされる支払
に対応するトランザクション額と、を含むことのできる資金供給依頼を生成してよい。処
理システム１０２が、資金供給依頼が重畳された又さもなければエンコードされたデータ
信号を、センダ機関１１４に電子送信してよい。センダ機関１１４が、依頼を受信してよ
く、主要アカウント番号と関連付けられたトランザクションアカウントからトランザクシ
ョン額を引き落としてよく、通貨をあるエンティティから別のエンティティへ移転する従
来の方法及びシステムを使用して、対応する資金を処理システム１０２に移転してよい。
いくつかの実施形態では、処理システム１０２は、主要アカウント番号を介してセンダ機
関１１４を識別してよい。例えば、主要アカウント番号は、銀行識別番号、イシュア識別
番号、又はセンダ機関１１４と関連付けられた他の値を含んでよく、又そうでなければ、
主要アカウント番号とセンダ機関１１４との間の関連を格納してもよい。

処理システム１０２は、適切な資金がセンダ機関１１４から受領されたことを確認して
よい。処理システム１０２が、次いで、送金された資金の適切なレシピエント機関１１６
への支払を開始してよい。レシピエント機関１１６は、加盟店銀行又は他の適切なエンテ
ィティのようなアクワイアリング金融機関であってよい。アクワイアリング金融機関は、
ポイントツーポイント支払トランザクションにおいて支払を受ける際に使用するために、
レシピエントエンティティにトランザクションアカウントを発行するよう構成される。処
理システム１０２は、レシピエント機関１１６に対して、ポイントツーポイント支払トラ
ンザクションのために支払われるトランザクション額及び額が支払われるトランザクショ
ンアカウントを示すことのできる、決済予告を生成してよい。従って決済予告が、少なく
とも、レシピエントアカウント番号、及び従前に処理システム１０２に提出された送金依
頼からのトランザクション額を含んでよい。処理システム１０２が、生成された決済予告
が重畳された又さもなければエンコードされたデータ信号を、レシピエント機関１１６に
電子送信してよい。また処理システム１０２は、通貨をあるエンティティから別のエンテ
ィティへ移転する従来の方法及びシステムを使用して、適切な資金をレシピエント機関１
１６に移転してもよい。

レシピエント機関１１６は、決済予告に含まれたレシピエントアカウント番号に対応す
るレシピエントエンティティと関連付けられたトランザクションアカウントに、トランザ
クション額を入金（credit）してよく、レシピエントエンティティに支払を果たしてよい
。処理システム１０２によるレシピエント機関１１６への支払に続いて、レシピエントエ
ンティティに、ポイントツーポイント支払トランザクションの決済が通知されてよい。い
くつかの実施形態では、処理システム１０２は決済通知を生成してよい。決済通知は、少
なくとも、レシピエントシステム１１０に電子送信され得るトランザクション額を含んで
よい。他の実施形態では、処理システム１０２は、決済通知をレシピエントネットワーク
１１８に電子送信してよく、レシピエントシステム１１０に転送してよく、又はウエブペ
ージ、アプリケーションプログラム、ショートメッセージングサービスのメッセージ等を
介する他の方法によってレシピエントエンティティに配信してよい。レシピエントネット
ワーク１１８が、金銭移転エンティティ（例えばWestern Union）、又はトレード若しく
はサプライチェインネットワーク（例えばAriba）のような、ポイントツーポイント支払
トランザクションを通知及び管理する際に使用するのに適するエンティティ及び／又はシ
ステムであってもよい。場合によっては、センダネットワーク１１２及びレシピエントネ
ットワーク１１８が、１つ以上のポイントツーポイント支払トランザクションのための同
一のエンティティであってよい。いくつかの実施形態では、レシピエント機関１１６は、
レシピエントシステム１１０に決済予告を提供する、又はレシピエント機関１１６とレシ
ピエントエンティティとの間の従来の通信方法を使用して、処理システム１０２からの決
済資金の受領に続くレシピエントエンティティに、決済予告を提供するよう構成されてよ
い。

いくつかの実施形態では、処理システム１０２は、ポイントツーポイント支払トランザ
クションを集計し、ポイントツーポイント支払トランザクションを合算決済するよう構成
されてよい。そのような実施形態では、処理システム１０２が、異なるポイントツーポイ
ント支払トランザクションの各送金依頼である、複数の送金依頼を受信してよい。各送金
依頼は、主要アカウント番号、トランザクションアカウント番号、及びレシピエントアカ
ウント番号を含んでよい。いくつかの場合では、各送金依頼が、固有の主要アカウント番
号及び／又はレシピエントアカウント番号を含んでよい。他の場合では、１つ以上の送金
依頼が、１つのセンディングエンティティから様々な受取エンティティへの資金のポイン
トツーポイント支払のため、又は複数のセンディングエンティティからの資金を単一のレ
シピエントエンティティが受領するために等の場合のために、共通の主要アカウント番号
及び／又はレシピエントアカウント番号を含んでよい。

処理システム１０２は、センダ機関１１４及びレシピエント機関１１６のための送金依
頼を集計するよう構成されてよく、それらと関連付けられた資金移転の数を低減する。前
者の場合では、処理システム１０２は、同一の主要アカウント番号を含む送金依頼を集計
してよい。その場合、含まれた各主要アカウント番号は、同一の銀行識別番号、イシュア
識別番号、又は他の識別値を有すること等によって、センダ機関１１４と関連付けられる
。いくつかの場合では、処理システム１０２は、アカウントレベルで（例えば同一の主要
アカウント番号を有する送金依頼）又はエンティティレベルで（例えばセンダ機関１１４
と関連付けられた主要アカウント番号を有する全ての送金依頼）、トランザクションを（
例えばセンダ機関１１４からの依頼によって）集計するよう構成されてよい。場合によっ
ては、アカウントレベル集計は、単一のセンダシステム１０８が、センダ機関１１４によ
って集計され得る複数のトランザクションアカウントを利用する場合等の、複数の主要ア
カウント番号を使用してよい。送金依頼の集計は、集計された送金依頼の各々からの各ト
ランザクション額の合計に対応する支払額のための、単一の資金供給依頼（処理手数料の
ような追加基準に基づいて増減する可能性あり）の生成を含んでよい。場合によっては、
資金供給依頼が、各主要アカウント番号及び対応する支払額を示してよい。これらは、対
応する各トランザクションアカウントから適切な額を引き落とす際に、センダ機関１１４
が使用する等のためである。

処理システム１０２は、集計された送金依頼のための単一の資金供給依頼が重畳された
又さもなければエンコードされたデータ信号を、センダ機関１１４に電子送信してよい。
センダ機関１１４は、次いで、それに従って各トランザクションアカウントから引き落と
しを行ない、合計支払額のための単一の資金移転を、処理システム１０２に行なうことが
可能である。その結果、センダ機関１１４は、複数のポイントツーポイントトランザクシ
ョンのための支払を、単一の資金移転及び単一の資金供給依頼を介して提供することがで
きる。これによって、資金移転及び関連する通信の数を低減することができる。従って、
センダ機関１１４が必要とする演算能力及び処理能力、並びに関連する手数料及び費用が
低減される。

また処理システム１０２は、レシピエント機関１１６への決済資金の支払に関連して集
計を実行するよう構成されてもよい。処理システム１０２が、共通のレシピエントアカウ
ント番号を含む送金依頼を集計することによって（例えばアカウントレベルの集計のため
に）、又はレシピエント機関１１６と関連付けられた共通の銀行識別番号、イシュア識別
番号、若しくは他の識別値を含む送金依頼を集計することによって（例えばエンティティ
レベルの集計のために）、レシピエント機関１１６への送金依頼を集計してよい。レシピ
エント機関１１６への送金依頼の集計は、各トランザクション額の単一の決済額への集計
を含んでよい。これは、処理手数料の支払のような追加基準に基づいて増減する可能性が
ある。処理システム１０２は、単一の決済予告を生成してよい。単一の決済予告は、集計
された決済額を含んでよく、また各レシピエントアカウント番号及び対応するトランザク
ション額を含んでよい。これらは、対応するトランザクションアカウントに入金する際に
、レシピエント機関１１６が使用するためのものである。

処理システム１０２は、単一の決済予告が重畳された又さもなければエンコードされた
データ信号を、レシピエント機関１１６に電子送信してよい。また処理システム１０２が
、レシピエント機関１１６への全決済額の移転を開始することもできる。レシピエント機
関１１６は、決済額を受領してよく、決済予告に含まれたデータに基づいて適宜に、レシ
ピエントエンティティのための各トランザクションアカウントに入金してよい。その結果
、レシピエント機関１１６が、複数のポイントツーポイントランザクションのための支払
を、単一の資金移転及び単一の決済予告を介して受信することができる。これによって、
資金移転及び関連する通信の数を低減することができる。従って、レシピエント機関１１
６が必要とする演算能力及び処理能力、並びに関連する手数料及び費用が低減される。処
理システム１０２が、センダ機関１１４及びレシピエント機関１１６の両方に対して集計
を実行する場合、決済を、数千、数百万、及び数十億でさえある支払トランザクションに
対して、一握りのみの資金供給依頼、決済予告、及び資金移転を介して実行することがで
きる。

処理システム１０２は、ポイントツーポイントランザクションの資金の供給及び／又は
決済の集計のために集計する、送金依頼の数を決定するために、多様な基準を使用するよ
う構成されてよい。そのような場合では、基準は、処理システム１０２又は適用可能なセ
ンダ機関１１４及び／又はレシピエント機関１１６によって定められてよい。基準が、例
えば、送金依頼の数、合計の支払額又は決済額、主要アカウント番号又はレシピエントア
カウント番号の数、時間及び／又は日付を含んでよい。例えば、全ての送金依頼が毎日集
計される場合、センダ機関１１４は、日々の単一の資金供給依頼を依頼してよい。または
、集計された支払額が所定の値に達する度に、センダ機関１１４がその都度資金供給依頼
を依頼することもできる。いくつかの場合では、複数の基準が使用されてもよい。例えば
、決済額が100,000ドルを超える場合には、日々の終わりの決済のために、追加の決済予
告及び移転を伴う決済額の集計を行なう等である。

場合によっては、単一のエンティティが、処理システム１０２によって受信される複数
の送金依頼において、センダ機関１１４及びレシピエント機関１１６の両方であってよい
。そのような場合では、そのエンティティに関係する送金依頼の集計は、資金を送金する
主要アカウント番号と関連付けられる送金依頼、並びに資金を受領するレシピエントアカ
ウント番号と関連付けられる送金依頼の集計を含んでよい。集計には、単一のエンティテ
ィがセンダ機関１１４である送金依頼に対して単一のエンティティによって支払われる送
金額の、単一のエンティティがレシピエント機関１１６である送金依頼に対して単一のエ
ンティティに支払われる決済額に対する、収支が関係してよい。例えばエンティティは、
送金で100,000ドルの資金供給を要求されるかもしれないが、決済では80,000ドルの権利
があるかもしれない。そのような例では、処理システム１０２は、送金額及び決済額にお
ける差額に適応するために、単一のエンティティに20,000ドルの単一の資金供給依頼を送
信することができる。

いくつかの実施形態では、処理システム１０２は、商用作動ネットワーク１２０を使用
して、整合データの使用を含む可能性のある企業間トランザクションのポイントツーポイ
ント支払トランザクションを処理するために、センダシステム１０８、レシピエントシス
テム１１０、センダネットワーク１１２、及び／又はレシピエントネットワーク１１８と
共に作動してよい。整合データは、請求書番号、発注書番号、製品品目詳細等のような、
センディングエンティティ及び／又はレシピエントエンティティがポイントツーポイント
ランザクションを追跡するために使用するデータを含んでよい。そのような場合では、送
金依頼が整合データを含んでよい。処理システム１０２は、レシピエントシステム１１０
（例えば、適用可能であれば、又はレシピエントネットワーク１１８）に電子送信される
決済予告に、決済予告に含まれたレシピエントアカウント番号に基づく等の、対応するポ
イントツーポイント支払トランザクションのために、整合データを含めるよう構成されて
よい。いくつかの場合では、整合データを、処理システム１０２と、センダシステム１０
８、センダネットワーク１１２、レシピエントシステム１１０、及びレシピエントネット
ワーク１１８との間の通信にのみ含めてよい。そのような場合では、センダ機関１１４に
送信される資金供給依頼及びレシピエント機関１１６に送信される決済予告は、整合デー
タを含まずともよい。

いくつかの実施形態では、処理システム１０２は、複数の通貨を関係させるポイントツ
ーポイント支払トランザクションの処理及び決済を実行するよう構成されてよい。そのよ
うな実施形態では、センディングエンティティは、送金又は決済のための通貨指定を有す
る送金依頼、並びに所望の送金額又は決済額を提出してよい。処理システム１０２は、次
いで、送金及び／又は決済のために必要な任意の通貨換算を実行できる。これは、関係す
る各通貨の為替レートに基づいてよい。場合によっては、処理システム１０２は、使用す
ることのできる為替レートを、センディングエンティティに（例えばセンダネットワーク
１１２又はセンダシステム１０８を介して）提供してよい。そのような為替レートは、処
理システム１０２、センダ機関１１４、レシピエント機関１１６、又は市場為替レート等
の他のエンティティによって設定されてよい。そのような場合のいくつかでは、処理シス
テム１０２は、為替レートに対する適用可能期間を示してよい。一例では、センディング
エンティティが米国ドル（USD）で1,000の送金を希望し、レシピエントエンティティが英
国ポンド（GBP）での受領を希望するとする。処理システム１０２は、決済のために、1,0
00USDに等しい額のGBPを計算してよい。別の例では、センディングエンティティが、GBP
で1,000を受領するレシピエントエンティティに対して、USDで十分な通貨の送金を希望す
る場合がある。そのような例では、処理システム１０２は、支払トランザクションの送金
額として使用するために、1,000GBPの相当額をUSDで計算するであろう。そのような実施
形態では、為替レート及び通貨換算のデータは、資金供給依頼及び／又は決済予告に含め
られてよい。

いくつかの実施形態では、処理システム１０２は、本開示で説明する機能を実行するた
めに、複数のコンピューティング装置を使用するよう構成されてよい。そのような実施形
態では、第１コンピューティング装置１０４は、センダシステム１０８、センダネットワ
ーク１１２、及びセンダ機関１１４から送金依頼を受信するよう構成されてよく、適用可
能であれば送金依頼の集計を実行するよう構成されてよい。第１コンピューティング装置
１０４が、内部通信ネットワーク及び手段を使用して、送金依頼に含まれたデータ又は集
計されたデータを、第２コンピューティング装置１０６に送信してよい。第２コンピュー
ティング装置１０６が、対応する資金供給依頼を生成してよく、資金供給依頼上に重畳さ
れた又はエンコードされたデータ信号を、適用可能なセンダ機関１１４に電子送信してよ
く、対応する支払額の受領を確認することができる。

また第２コンピューティング装置１０６は、レシピエント機関１１６に電子送信するた
めの決済予告を生成し、レシピエント機関１１６への資金の移転を開始するよう構成され
てもよい。場合によっては、第１コンピューティング装置１０４が、最初に信号を第２コ
ンピューティング装置１０６に移転し、決済額の支払を開始してもよい。例えば、第１コ
ンピューティング装置１０４は、レシピエント機関１１６が複数のセンダ機関１１４から
由来する集計された決済額を受け取る予定である場合等に、集計された決済額に対して全
支払が受領されたことを確認するよう構成されてよい。また第１コンピューティング装置
１０４は、レシピエントシステム１１０、レシピエントネットワーク１１８、及び／又は
レシピエント機関１１６に電子送信するための、適用可能であれば、レシピエントエンテ
ィティに資金の受領を通知するための、決済予告を生成するよう構成されてよい。

いくつかの実施形態では、処理システム１０２は、各エンティティによって、及び場合
によっては追加的な第三エンティティによってアクセス可能な元帳に格納する等のために
、支払トランザクションに関係するエンティティと関連付けられたデータを格納するため
に使用されるよう構成されてよい。処理システム１０２は、センディングエンティティと
レシピエントエンティティとの間で決済される支払トランザクションと関連付けられたデ
ータを格納するよう構成されてよい。企業間（B2B）トランザクションの場合では、処理
システム１０２が、支払トランザクションに係る追加機能を実行する際にセンディングエ
ンティティ及びレシピエントエンティティが使用できるような、支払トランザクションの
ための整合データを格納してよい。例えば、処理システム１０２は、各エンティティと関
連付けられた識別情報をデータベース１２２の元帳に格納してよく、また支払トランザク
ションのための発注書、請求書、支払等に関するステータス情報を格納し、コーポレイト
アイデンティティデータ、支払トランザクション及び財務決定に関する権限を有すること
ができる各エンティティの個人と関連付けられたデータ、トランザクションアカウント明
細等のような追加情報も格納してよい。従って、そのような元帳が、エンティティに対す
る完全な眺望、並びに、エンティティ及び他のセンダエンティティ及びレシピエントエン
ティティの間のトランザクション履歴に対する完全な眺望を有することができる。

一例では、本開示で説明するシステムで使用するために、会社が処理システム１０２に
登録されてよい。会社は、次いで、取引ディレクトリ（例えばデータベース１２２に格納
された元帳）に登録されてよい。その場合、彼らの銀行口座情報は、支払勘定（AP）又は
受取勘定（AR）の責任者は誰か、金融財政担当役員、会社の金融トランザクションに対し
て権限を与えられた個人、並びに発注書及び／又は請求書等の、会社と関連付けられた追
加データと共に、システム内にあり得る。また取引ディレクトリが、処理システム１０２
を介してなされる将来の請求書及び支払と関連付けられたデータを格納してもよい。その
結果、時間の経過と共に、登録されたエンティティと、任意の他の可能とされた第三者と
の間の各発注書、請求書、及びトランザクション、又はそれらのステータスが、元帳に（
つまり、基礎となるトランザクション自体の完全コピーが取り込まれる又は格納されるこ
となく）取り込まれる。また取引ディレクトリが、例えばエンティティ属性（例えばエン
ティティ又は核となる組織レベルデータ）、支払属性（例えば支払／アカウント明細デー
タ、送金データ等）、エンティティ階層（例えば関係性、組織構造、子会社等）、系列エ
ンティティデータ（例えばバイヤ、サプライヤ、ネットワーク関係等）、補足データ（例
えば証明書、文書等）、関連する個人等を、格納するためにも使用されてよい。

第１コンピューティング装置１０４及び／又は第２コンピューティング装置１０６は、
１つ以上のアプリケーションプログラムインターフェイス（API）を介して、元帳で使用
するための情報を取り込んでよい。APIは、請求書、発注書、及び支払トランザクション
に係る他の項目から、必須情報（例えばトランザクション額、請求書日付、品目数量、出
荷日付等）を引き出してよく又は受信してよい。これらは、次いで、元帳に格納されてよ
い。場合によっては、APIが、トランザクション通信を処理システム１０２に提出するた
めに使用できる外部アプリケーションプログラム又はB2Bネットワークへのリンクを介す
る等、関連する請求書、発注書、及び／又は他のトランザクション通信へのリンクを、元
帳に格納してもよい。例えば、処理システム１０２におけるAPIが、取引ネットワークと
通信してよく、発注書及び請求書又はそれらのステータスを、取引ネットワークからセン
ダエンティティ及びレシピエントエンティティのために受信してよい。つまり、発注書又
は請求書自体は、完全コピーされない。またAPIが、取引ネットワークにおいて、発注書
及び請求書へのリンクを元帳内に含んでよい。従って、センダシステム１０８及び／又は
レシピエントシステム１１０は、任意のトランザクション明細を見るため、並びにオリジ
ナルの通信に戻ってリンクするために、元帳にアクセスすることができる。

場合によっては、また処理システム１０２は、支払トランザクションのためにエンティ
ティにステータス情報を提供してもよい。例えば、APIが元帳に格納されたトランザクシ
ョンデータを更新するとき、各エンティティはデータにアクセスし、彼らのトランザクシ
ョンのためのステータスを、彼らの各システム（例えばセンダシステム１０８、レシピエ
ントシステム１１０等）又はネットワーク（例えばセンダネットワーク１１２、レシピエ
ントネットワーク１１８等）を介して識別することができる。例えば、センダエンティテ
ィは、上記で説明した方法を使用して、レシピエントエンティティへの資金の移転を開始
し、処理システム１０２を使用して、レシピエントがいつ資金を受領したか、元帳を介し
て識別することができる。他の例では、レシピエントエンティティは、センダエンティテ
ィに請求書を送信し、元帳でのステータスがAPIを介したトランザクション通信の受領に
よって変化すると、いつセンダエンティティが請求書を受け取ったかを、元帳を介して識
別することができる。

さらに、また処理システム１０２は、処理される全ての支払トランザクションの中央信
託部及びリポジトリとして機能してもよい。例えば、第三者の金融提供者は、エンティテ
ィに関係するトランザクションの履歴を見て、リスクを検証し、それに基づいてそのエン
ティティに金融ソリューションを提供することが可能である。例えば、金融提供者は、処
理システム１０２によって維持される元帳に含まれるトランザクションデータの、信頼さ
れるリポジトリを介して確認できるいくつかの未払請求書に対して、金融提供者が予期す
る支払の強さを踏まえて、ローンを提供する又はレシピエントエンティティに支払われる
債権を得ることができる。また処理システム１０２は、データの堅牢性及び信頼性を提供
できる。その堅牢性及び信頼性は、規制権限局が、ライセンス要件、規制要件、並びに当
事者及び個人のアイデンティティに付随する任意の他の問題を効果的にアウトソースする
ために、その信頼性を潜在的に拠り所とすることが可能なものである。例えば、規制当局
は、処理システム１０２に接触し、法規に準拠していることを確認する際に使用するため
に、元帳に格納されたトランザクションデータ又は取引パートナー識別データにアクセス
することができる。

いくつかの実施形態では、システムは１つ以上の第三者システム１２４を含んでよい。
第三者システム１２４が、例えば、借り入れるため又は債権をノンリコースベースで売却
するための資金を、金利で提供できる異なる会社であってよく、又は処理システム１０２
に格納されたトランザクション元帳を使用することで利益を得ることのできる他のエンテ
ィティであってよい。例えば、レシピエントエンティティは、第三者システム１２４が彼
らのトランザクションに関する元帳を閲覧する許可をオプトインすることができる。第三
者システム１２４が、プライバシーに関する関心事及びトランザクションに係わる全ての
当事者の同意に適合する（例えばセンダエンティティ情報が匿名とされている、又はエン
ティティの同意のもとで使用される）取引ディレクトリにおける、レシピエントエンティ
ティのトランザクションの閲覧にアクセスすることができる。第三者システム１２４が、
価格リスクを分析し、例えば特定の請求書についてレシピエントエンティティに金融ソリ
ューションを提供することができる。例えば、第三者システム１２４は、レシピエントエ
ンティティが要求に応じて現金を得る能力を提供することができる。レシピエントエンテ
ィティが処理される決済を介して彼らの現金を受領することを第３０日又は第４０日まで
待つ代わりに、第三者システム１２４は、サプライヤと購入者との間のトランザクション
の履歴に基づいて、センダエンティティが彼らの請求書の99.9パーセントを完済すると知
ることができる。従って第三者システム１２４は、センダエンティティが、支払期限であ
るが未だそのサプライヤに支払われていない次の請求書を支払うつもりであると示す元帳
からのデータに基づいて、高い快適度を有することができる。その結果、第三者システム
１２４が、元帳を介して識別された快適度の強さを踏まえて、そのレシピエントエンティ
ティに対して、現金を前払いするための極めて低い年率（APR）を提供することができる
。いくつかの場合では、また処理システム１０２は、第三者システム１２４からのオファ
ーを追跡し、取引ディレクトリに記録することもできる。そのような場合では、処理シス
テム１０２がレシピエント機関１１６への支払のためにレシピエント機関１１６に資金を
支出しようとすると、処理システム１０２は、レシピエント機関１１６に対して直接に決
済を開始してよく、支払が既に第三者システム１２４によって提供されていたので、レシ
ピエントエンティティに対して支払がなされないと、示してよい。そのような場合では、
レシピエント機関１１６に提供される決済予告は、第三者システム１２４に支払われると
、示してよい。またはレシピエントエンティティへの決済予告で、レシピエント機関１１
６から行なわれた支払は、第三者システム１２４によって提供された現金前払のためのも
のであると、示してよい。

いくつかの実施形態では、元帳は、関連するデータを格納するよう構成されたブロック
チェーンであってよい。ブロックチェーンは、複数のブロックを備えてよい。各ブロック
は、少なくとも１つのブロックヘッダと１つ以上のデータ値を備える。各ブロックヘッダ
は、タイムスタンプ、並びにブロックチェーンに追加された先のブロックのブロックヘッ
ダを参照する参照値、及び各ブロックに含まれた１つ以上のデータ値を参照する参照値を
含んでよい。例示的な実施形態では、参照値は、１つ以上のハッシュアルゴリズムのアプ
リケーションを介して各データに対して生成されたハッシュ値であってよい。例えば、先
のブロックヘッダへの参照値は、（例えばタイムスタンプに基づく）先のブロックのブロ
ックヘッダのハッシングを介して生成されたハッシュ値であってよい。そのようなものと
して、ブロックチェーンは不変であってよい。任意のデータ値における変化は、各ブロッ
クのブロックヘッダに含まれたハッシュ値への変化という結果となり、また続くブロック
のブロックヘッダのハッシュ値における変化という結果となるため、変化がブロックチェ
ーンの残りのブロックを通して運ばれる。従って、ブロックチェーン内の任意のデータ値
又はデータへの変更が防止される。システム１００において、データ値は、発注書、請求
書、トランザクションデータ、及び本開示で説明する元帳に格納される他のデータを含ん
でよい。

いくつかの実施形態では、図１に示す、また本開示で説明するシステムのエンティティ
間の通信は、１つ以上の標準に従ってフォーマットされてよい。標準は、例えば、国際標
準化機構（ISO）によって発行された標準としてよい。例えば、送金依頼はISO8583標準に
従ってフォーマットされ、資金供給依頼はISO20022標準に従ってフォーマットされてよい
。いくつかの実施形態では、図１に示すシステムにおいて実行される各通信は、ISO8583
標準又はISO20022標準を使用して実行される全ての通信のように、単一の標準を使用して
よい。他の実施形態では、複数の標準を使用してもよい。例えば、センダネットワーク１
１２及び／又はセンダシステム１０８から受信される送金依頼、並びにレシピエントネッ
トワーク１１８及び／又はレシピエントシステム１１０に送信される決済予告は、ISO858
3標準に従ってフォーマットされてよい。一方、センダ機関１１４に送信される資金供給
依頼及びレシピエント機関１１６に送信される決済予告は、ISO20022標準に従ってフォー
マットされてよい。そのような実施形態のいくつかでは、処理システム１０２の機能は、
それと関連する標準に基づいて、異なるコンピューティング装置によって実行されてよい
。例えば、第１コンピューティング装置１０４は、ISO8583標準に従ってフォーマットさ
れた通信を、受信、生成及び送信するよう構成されてよい。一方、第２コンピューティン
グ装置１０６は、ISO20022標準に従ってフォーマットされた通信を、受信、生成及び送信
するよう構成されてよい。

標準に従ってフォーマットされたデータメッセージは、関連する標準に定められたよう
なデータを格納するよう構成されたデータ要素を含んでよい。例えば、標準は、標準に従
ってフォーマットされたデータメッセージに含まれ得るデータ要素、及びそこに格納され
得るデータを示してよい。場合によっては、異なる標準に従ってフォーマットされたデー
タメッセージが同一のデータを含んでよい。そのデータは異なるデータ要素に含まれる。
例えば、ISO8583標準に従ってフォーマットされた送金依頼は、主要アカウント番号及び
トランザクション額を格納するよう構成されたデータ要素を含んでよい。一方、ISO20022
に従ってフォーマットされた対応する資金供給依頼も、主要アカウント番号及びトランザ
クション額を格納するよう構成されたデータ要素を含んでよい。全体として、データメッ
セージ内の異なるデータ要素に含まれる各データを有し、また異なってフォーマットされ
る各データメッセージに格納されるデータを有するのである。

複数の標準が使用されてよい実施形態では、それに含まれる処理システム１０２及び／
又はコンピューティング装置は、データ信号及び／又はその上に重畳された又さもなけれ
ばエンコードされたデータメッセージを、１つの標準から他の標準に変換するよう構成さ
れてよい。例えば、第１コンピューティング装置１０４は、第２コンピューティング装置
１０６への配信に先立って、送金依頼をISO8583標準からISO20022標準へ変換するよう構
成されてよい。そのような例では、送金依頼のISO20022標準への変換が、送金依頼を、セ
ンダ機関１１４へ送信するための資金供給依頼に変換するものであってよい。いくつかの
実施形態では、変換は、第三者エンティティによって実行されてよい。例えば、処理シス
テム１０２は、第１標準に従ってフォーマットされたデータメッセージが重畳された又さ
もなければエンコードされたデータ信号を第三者エンティティに電子送信してよく、第三
者エンティティから、第２標準に従ってフォーマットされたデータメッセージが重畳され
た又さもなければエンコードされたデータ信号を戻り受信してよい。処理システム１０２
が複数のコンピューティングを備えてよい場合には、第１コンピューティング装置１０４
は、データ信号を第三者エンティティに電子送信してよい。一方、第２コンピューティン
グ装置１０６は、第三者エンティティによって電子送信されるデータ信号を受信してよい
。

本開示で説明する処理システム１０２によって実行される通信は、任意の適切な通信ネ
ットワーク、関連するプロトコル、及び通信方法を使用してよい。適切な通信ネットワー
クは、例えば、支払ネットワーク及び関連する支払レール、ローカルエリアネットワーク
、無線エリアネットワーク、無線周波数ネットワーク、セルラ通信ネットワーク、インタ
ーネット等を含んでよい。場合によっては、処理システム１０２が、支払トランザクショ
ンの処理を実行するよう構成された支払ネットワークの一部であってよい。その場合、本
開示で説明する１つ以上の通信が、関連する支払レールを使用して実行されてよい。例え
ば、センダ機関１１４及びレシピエント機関１１６に送信されるデータ信号、及び／又は
センダ機関１１４及びレシピエント機関１１６から送信されるデータ信号は、支払ネット
ワークと関連付けられた支払レールを使用して実行されてよい。場合によっては、複数の
通信ネットワークが使用されてよい。例えば、処理システム１０２は、センダ機関１１４
、レシピエント機関１１６、センダネットワーク１１２、及びレシピエントネットワーク
１１８と、支払ネットワークと関連付けられた支払レールを使用して通信してよいが、イ
ンターネットを使用してセンダシステム１０８及びレシピエントシステム１１０と通信し
てもよい。特別にフォーマットされたトランザクションメッセージを、支払ネットワーク
と関連付けられた支払レールを使用して送信すること、及びそれに基づいて支払トランザ
クションを従来のように処理することについては、図８に示すプロセス８００に関して、
以下に詳説する。

いくつかの実施形態では、処理システム１０２は、主要アカウント番号及び／又はレシ
ピエントアカウント番号のマッピングを実行するよう構成されてよい。例えば、場合によ
っては、センダシステム１０８又はレシピエントシステム１１０は、各々、資金を送る又
は受領するために、代替的な支払手段を使用してよい。そのような場合では、主要アカウ
ント番号又はレシピエントアカウント番号は、支払手段と関連付けられ、適用可能であれ
ば、資金を送る又は受領するために使用されるトランザクションアカウントに直接には関
連付けられない可能性がある。処理システム１０２は、主要アカウント番号又はレシピエ
ントアカウント番号を、それらに対してマップされた代替的な番号に置き換えるよう構成
されてよい。代替的な番号は、関連するトランザクションアカウントに直接に対応する。
例えば、センディングエンティティは、レシピエントエンティティの銀行口座に資金を送
金するために、クレジットカードを使用してよい。そのような例では、処理システム１０
２は、送金依頼に含まれたクレジットカード番号を、センダ機関１１４に資金供給依頼を
提供するのに先立って、基礎となるトランザクションアカウントのためのアカウント番号
と交換してよい。そのような実施形態では、処理システム１０２が、マッピングの際に使
用するアカウント番号間の関連を格納する際に使用するのに適する、１つ以上のデータベ
ースを格納してよい。

コンピューティング装置
図２は、例示的実施形態による、ポイントツーポイントランザクションを記録、処理、
及び表示する図１のシステム１００に示す処理システム１０２の、第１コンピューティン
グ装置１０４又は第２コンピューティング装置１０６のようなコンピューティング装置２
００の、ブロック図である。当業者にとって、図２に示すコンピューティング装置２００
の実施形態が、例示的目的のみで提供されることと、本開示の機能を実行するのに適する
コンピューティング装置２００の全ての可能な構成を徹底して示したものでないことは、
自明である。例えば、図９に示し下記で詳述するコンピュータシステム９００を、コンピ
ューティング装置２００の適切な構成としてよい。

コンピューティング装置２００は受信装置２０２を含んでよい。受信装置２０２が、１
つ以上のネットワーク上で、１つ以上のネットワークプロトコルを介してデータを受信す
るよう構成されてよい。いくつかの実施形態では、受信装置２０２は、極秘金融データ及
び情報を含むトランザクションメッセージを送信するために、支払ネットワークと関連付
けられたインフラストラクチャであって、特別に構成されたインフラストラクチャを使用
する等、支払レール上でデータを受信するよう構成されてよい。場合によっては、また受
信装置２０２は、センダシステム１０８、センダネットワーク１１２、センダ機関１１４
、他のコンピューティング装置、レシピエントシステム１１０、レシピエントネットワー
ク１１８、レシピエント機関１１６、及びインターネットのような代替的なネットワーク
を介する他のエンティティから、データを受信するよう構成されてもよい。いくつかの実
施形態では、受信装置２０２は、異なるネットワーク上でデータを受信する異なる受信装
置のような、複数の装置を備えてよい。例えば、支払レール上でデータを受信する第１受
信装置、及びインターネット上でデータを受信する第２受信装置等である。受信装置２０
２は、電子送信されるデータ信号を受信してよい。その場合データは、データ信号上に重
畳されてよく又さもなければエンコードされてよい。またデータは、受信装置２０２によ
るデータ信号の受信を介して、デコードされ、解析され、読み込まれ、又さもなければ取
得されてよい。場合によっては、受信装置２０２は、データ信号上に重畳されたデータを
取得するために、受信したデータ信号を解析する解析モジュールを含んでよい。例えば、
受信装置２０２は、データ信号を受信し、受信したデータ信号を、処理装置によって実行
される機能のために使用可能な入力へ変換するよう構成された解析プログラムを含んでよ
く、本開示で記載する方法及びシステムを実行してよい。

受信装置２０２は、センダシステム１０８、センダネットワーク１１２、及び／又はセ
ンダ機関１１４によって電子送信されるデータ信号を受信するよう構成されてよい。デー
タ信号は、送金依頼が重畳される又さもなければエンコードされる。送金依頼は、主要ア
カウント番号、トランザクション額、及びレシピエントアカウント番号を含んでよい。場
合によっては、送金依頼が、ISO8583又はISO20022標準等、１つ以上の標準に従ってフォ
ーマットされてよい。場合によっては、送金依頼が、処理システム１０２において、第１
コンピューティング装置１０４の受信装置２０２によってのみ受信されてよい。また受信
装置２０２が、他のコンピューティング装置２００よって電子送信されるデータ信号を受
信するよう構成されてもよい。例えば、第２コンピューティング装置１０６の受信装置２
０２は、資金供給依頼を生成する際に使用する集計された送金依頼のために、第１コンピ
ューティング装置１０４によって電子送信されるデータ信号を受信してよい。また受信装
置２０２は、従来の方法及びシステムを使用して、金銭移転を介して通貨を受領するよう
構成されてもよい。いくつかの実施形態では、受信装置２０２は更に、第三者エンティテ
ィから電子送信されるデータ信号を受信するよう構成されてよい。データ信号は、変換さ
れたデータメッセージが重畳されてよく又さもなければエンコードされてよい。

また受信装置２０２は、センダネットワーク１１２、レシピエントネットワーク１１８
、支払ネットワーク、又は支払トランザクションの処理に係わる他のエンティティ等から
、支払トランザクションに係わるトランザクションメッセージを受信するよう構成されて
よい。トランザクションメッセージが、１つ以上の標準に従ってフォーマットされ、１つ
以上のアプリケーションプログラムインターフェイス（API）を使用して受信されてよい
。各トランザクションメッセージは、少なくとも複数のデータ要素を含んでよい。複数の
データ要素は、トランザクション明細を格納するよう構成された第１データ要素、主要ア
カウント番号を格納するよう構成された第２データ要素、及びレシピエントアカウント番
号を格納するよう構成された第３データ要素である。場合によっては、また受信装置２０
２は、支払トランザクションに係る追加のデータメッセージを受信してもよい。追加のデ
ータメッセージは、発注書、請求書等の、トランザクション通信に係わるデータを含んで
よい。場合によっては、受信装置２０２によって受信されるデータメッセージは、多様な
データフォーマッティング標準を使用してフォーマットされてよく、受信装置２０２、又
は他のモジュール、又はAPIを介するようなコンピューティング装置２００のエンジンに
よって受信されると、再フォーマットされてよい。

またコンピューティング装置２００は、通信モジュール２０４を含んでもよい。通信モ
ジュール２０４が、モジュール、エンジン、データベース、メモリ、及び本開示で説明す
る機能を実行する際に使用するコンピューティング装置２００の他のコンポーネントの間
で、データを送信するよう構成されてよい。通信モジュール２０４が、１つ以上の通信タ
イプを備え、コンピュータ装置内部で通信するための多様な通信方法を利用してよい。例
えば、通信モジュール２０４は、バス、コンタクトピンコネクタ、ワイヤ等を備えてよい
。いくつかの実施形態では、また通信モジュール２０４は、コンピューティング装置２０
０の内部コンポーネントと、外部接続されたデータベース、ディスプレイ装置、入力装置
等のようなコンピューティング装置２００の外部コンポーネントとの間で、通信するよう
構成されてもよい。処理装置は、本開示で説明するコンピューティング装置２００の機能
を実行するよう構成されてよいことは、当業者にとって自明である。いくつかの実施形態
では、処理装置は、複数のエンジン、及び／又は処理装置の１つ以上の機能を実行するよ
う特別に構成された複数のモジュールを含んでよい、及び／又はそれらから構成されてよ
い。それらは、クエリモジュール２１０、生成モジュール２１２、決定モジュール２１４
等である。本開示で使用されるように、用語「モジュール」は、入力を受信し、その入力
を使用して１つ以上の処理を実行し、出力を提供するよう特別にプログラムされたソフト
ウエア又はハードウエアであってよい。多様なモジュールによって実行される入力、出力
、及びプロセスは、本開示に基づき、当業者にとって自明である。

コンピューティング装置２００は、アカウントデータベース２０６を含んでよい。アカ
ウントデータベース２０６が、適切なデータ格納フォーマット及びスキームを使用して、
複数のアカウントプロファイル２０８を格納するよう構成されてよい。アカウントデータ
ベース２０６は、そこに格納される構造化データセットの格納、識別、修正、更新、アク
セス等のために、構造化クエリ言語を利用するリレーショナルデータベースであってよい
。各アカウントプロファイル２０８は、１つ以上のトランザクションアカウントに係るデ
ータを格納するよう構成された構造化データセットであってよい。いくつかの実施形態で
は、各アカウントプロファイル２０８は、センディングエンティティ又はレシピエントエ
ンティティに対応するような、単一のトランザクションアカウントと関連付けられてよい
。そのような実施形態では、アカウントプロファイル２０８は、関連するセンダ機関又は
レシピエント機関１１６を識別する際に使用するのに適するデータ、又は代替的な支払手
段が使用されてよい場合のように適用可能であれば、アカウント番号をアカウント番号の
マッピングのために交換する際に使用するのに適するデータを含んでよい。他の実施形態
では、各アカウントプロファイル２０８は、センダ機関１１４又はレシピエント機関１１
６と関連付けられてよい。そのような実施形態では、アカウントプロファイル２０８が、
送金依頼の集計で使用される、アカウントプロファイル２０８と関連付けられたデータを
含んでよい。このデータは、集計された支払及び決済額、関連する識別値（例えば、アカ
ウントプロファイル２０８との関連のために送金依頼を識別する際に使用される）、及び
本開示で説明する機能を実行するために適する他のデータ等である。

いくつかの実施形態では、各アカウントプロファイル２０８は更に、係わるエンティテ
ィ（例えば支払人、受取先、バイヤ、サプライヤ等）と関連付けられた情報を含んでよい
。各アカウントプロファイル２０８は、例えば、エンティティ情報、コーポレイトアイデ
ンティティデータ、エンティティ内でバンキングトランザクション及び金融トランザクシ
ョンに関する権限を有する個人と関連付けられたデータ、及び／又は実際の銀行口座情報
等を格納することができる。またアカウントプロファイル２０８は、トランザクションメ
ッセージの第１、第２、及び第３データ要素、又は係わるエンティティと関連付けられ、
トランザクション又はデータメッセージに属する記録へのリンクを有する他のデータメッ
セージを含んでもよい。リンクは、第１トランザクションメッセージに基づいて文書への
アクセスを提供することができる。例えば、発注書に係わるデータメッセージ又はそこか
ら解析されるデータは、アカウントプロファイル２０８に格納されてよい。またアカウン
トプロファイル２０８は、係わる発注書へのリンク（例えば、対応するAPIを介するセン
ダネットワーク１１２又はレシピエントネットワーク１１８のような、外部エンティティ
を介してアクセス可能なリンク）を含んでもよい。いくつかの場合では、データメッセー
ジ自体がアカウントプロファイル２０８に格納されてよい。他の場合では、アカウントプ
ロファイル２０８は、データメッセージから解析されるトランザクションデータを含んで
よい。トランザクションデータは、センダエンティティ及びレシピエントエンティティ識
別情報、トランザクション額、提出データ等である。またアカウントプロファイル２０８
は、鍵情報を収集するために、APIの使用に関係する支払トランザクションに係わる、任
意の数の追加的なトランザクション明細を格納してもよい。アカウントプロファイル２０
８に格納されるリンクは、オリジナルの請求書、発注書、及び／又はトランザクションに
係わる任意の他の通信へのアクセスを提供することができる。

コンピューティング装置２００は、クエリモジュール２１０を含んでよい。クエリモジ
ュール２１０が、情報を識別するために、データベース上でクエリを実行するよう構成さ
れてよい。クエリモジュール２１０は、１つ以上のデータ値又はクエリストリングを受信
し、そこに格納された情報を識別するために、アカウントデータベース２０６のような指
定されたデータベース上で、それに基づいてクエリストリングを実行してよい。クエリモ
ジュール２１０は、次いで、識別された情報をコンピューティング装置２００の適切なエ
ンジン又はモジュールに、必要に応じて出力してよい。クエリモジュール２１０は、（例
えば、受信装置２０２によって受信される）送金依頼と関連付けられたアカウントプロフ
ァイルを識別するために、銀行識別番号、イシュア識別番号、又は（例えば、関連する標
準に定められたような）対応するデータ要素に格納された主要アカウント番号及び／又は
レシピエントアカウント番号に含まれた他の識別値に基づいて、集計を実行する際又は通
信をそれに送信する際に使用する等のために、アカウントデータベース２０６上でクエリ
を実行してよい。

またコンピューティング装置２００は、生成モジュール２１２を含んでよい。生成モジ
ュール２１２が、本開示で説明する機能を実行する際に処理システム１０２が使用するの
に適するデータメッセージを生成するよう構成されてよい。生成モジュール２１２は、入
力としてのデータメッセージの生成のための命令、及びそれと共に使用するのに適するデ
ータを受信してよく、依頼されたデータメッセージを生成してよく、生成したデータメッ
セージを、コンピューティング装置２００の別のモジュール又はエンジンに出力してよい
。生成モジュール２１２は、資金供給依頼を生成するよう構成されてよい。資金供給依頼
は、少なくとも、主要アカウント番号及び関連する支払額を含んでよい。場合によっては
、生成モジュール２１２は、送金依頼の集計のための資金供給依頼を生成してよい。この
資金供給依頼は、全体的な支払額、複数の異なる主要アカウント番号、及び関連する支払
額を含んでよい。また生成モジュール２１２は、決済予告を生成するよう構成されてよい
。レシピエント機関１１６に送信される決済予告は、少なくとも１つのレシピエントアカ
ウント番号及び関連する決済額、又は集計された決済額、複数のレシピエントアカウント
番号、及び関連する決済額を含んでよい。またレシピエントシステム１１０及び／又はレ
シピエントネットワーク１１８に送信される決済予告は、少なくとも決済額を含み、また
整合データも含み又はポイントツーポイント支払トランザクションのレシピエントに通知
するのに有用な他のデータを含んでもよい。

場合によっては、生成モジュール２１２が、ISO8583及びISO20022標準等の、１つ以上
の標準に従ってデータメッセージを生成するよう構成されてよい。いくつかの場合では、
生成モジュール２１２は、単一の標準に従ってデータメッセージを生成するよう構成され
てよい。例えば、第１コンピューティング装置１０４の生成モジュール２１２は、ISO858
3標準に従ってフォーマットされたデータメッセージを生成するよう構成されてよい。一
方、第２コンピューティング装置１０６の生成モジュール２１２は、ISO20022標準に従っ
てフォーマットされたデータメッセージを生成するよう構成されてよい。いくつかの実施
形態では、生成モジュール２１２は、データメッセージを１つのフォーマットから別のフ
ォーマットへ変換するよう構成されてよい。データメッセージの変換は、１つ以上のデー
タ要素の再フォーマット及びそこに含まれるデータ要素の再編成、並びに関連する標準に
定められたデータの追加又は削除を含んでよい。例えば、生成モジュール２１２は、ISO8
583に従ってフォーマットされたデータメッセージを、ISO20022標準に準拠させるべく変
換するよう構成されてよい。これは、１つ以上のデータ要素におけるデータの移動、及び
それらの再編成を含んでよい。

いくつかの実施形態では、生成モジュール２１２は、支払トランザクションに係わる第
２データメッセージを生成するよう構成されてよい。第２データメッセージが、１つ以上
の標準に従ってフォーマットされ、支払額を格納するよう構成された第１データ要素を含
む少なくとも複数のデータ要素を含んでよく、支払額が、少なくともトランザクション明
細に基づいてよい。また生成モジュール２１２は、支払トランザクションに係わる第３デ
ータメッセージを生成するよう構成されてよい。第３トランザクションメッセージが、１
つ以上の標準に従ってフォーマットされ、決済額を格納するよう構成された第１データ要
素と、レシピエントアカウント番号を格納するよう構成された第２データ要素と、を含む
少なくとも複数のデータ要素を含んでよい。決済額は、少なくともトランザクション明細
に基づいてよい。また生成モジュール２１２は、支払トランザクションに係わる第４デー
タメッセージを生成するよう構成されてよい。第４データメッセージを、１つ以上の標準
に従ってフォーマットし、第４データメッセージが、少なくとも、トランザクション明細
を格納するよう構成された第１データ要素と、レシピエントアカウント番号を格納するよ
う構成された第２データ要素と、を含む、複数のデータ要素を含んでよい。

またコンピューティング装置２００は、決定モジュール２１４を含んでよい。決定モジ
ュール２１４が、本開示で説明する処理システム１０２によって実行される機能に係わる
、１つ以上の決定を実行するよう構成されてよい。決定モジュール２１４は、決定のため
の命令、及び付随するデータを受信してよく、決定を下してよく、その決定の結果をコン
ピューティング装置２００の別のモジュール又はエンジンへ出力してよい。例えば、決定
モジュール２１４は、１つ以上の送金依頼に対して、センダ機関１１４からの送金資金の
受領を決定するよう構成されてよい。決定は、それと関連付けられた通知の（例えば、受
信装置２０２を介する）受領、トランザクションアカウント及びその収支の監視、及び他
の適切な方法に基づいてよい。また決定モジュール２１４は、複数の送金依頼に対して、
集計された支払額及び決済額を決定するよう構成されてよい。金額は、主要アカウント番
号又はレシピエントアカウント番号における共通性に基づいて集計されてよく、適用可能
であれば、そこに含まれる識別値を含んでよい。

いくつかの実施形態では、決定モジュール２１４は、センダ機関１１４から受領した資
金の整合を実行するよう構成されてよい。整合は、センダ機関１１４から受領した資金に
対応する送金依頼の、決定を含んでよい。例えば、センダ機関１１４は、（例えば、集計
された資金供給依頼に基づいて）複数の異なる送金依頼に対して送金資金を移転してよい
。また決定モジュール２１４は、受信装置２０２によって受領されたどの送金依頼が、受
領された資金を介して成功裡に資金を供給されたか、決定することができる。決定は、次
いで、送金依頼の決済のために、どの送金依頼が履行されたか決定するために使用されて
よい。例えば、処理システム１０２が、レシピエント機関１１６への決済支払の移転を集
計していると、決定モジュール２１４によって実行される整合は、レシピエント機関１１
６と関連付けられた全ての送金依頼が、対応するセンダ機関１１４からいつ資金を受領し
ていたか、という（例えば、レシピエントアカウント番号に基づく）決定を含んでよい。

いくつかの実施形態では、決済資金は、センダ機関１１４からの対応する送金依頼のた
めの全ての資金の受領に先立って、レシピエント機関１１６に移転されてよい。例えば、
処理システム１０２は、レシピエント機関１１６への資金の支払のために、レシピエント
機関１１６と合意を結んでよい。その場合、決定モジュール２１４は、決済支払が合意に
基づいて適切であるかどうか、決定することができる。別の例では、所定額の資金がセン
ダ機関１１４から受領されたときに、決済資金がレシピエント機関１１６に移転されてよ
い。受領は、決定モジュール２１４によって決定されてよい。

またコンピューティング装置２００は、送信装置２１６を含んでもよい。送信装置２１
６が、１つ以上のネットワーク上で、１つ以上のネットワークプロトコルを介してデータ
を送信するよう構成されてよい。いくつかの実施形態では、送信装置２１６は、識別され
た支払信用証明等の極秘金融データ及び情報を含むトランザクションメッセージを送信す
るために、支払ネットワークと関連付けられたインフラストラクチャであって、特別に構
成されたインフラストラクチャを使用する等、支払レール上でデータを送信するよう構成
されてよい。場合によっては、送信装置２１６は、コンピューティング装置２００、セン
ダシステム１０８、センダネットワーク１１２、センダ機関１１４、レシピエントシステ
ム１１０、レシピエントネットワーク１１８、レシピエント機関１１６、及びインターネ
ットのような代替的なネットワークを介する他のエンティティに、データを送信するよう
構成されてよい。いくつかの実施形態では、送信装置２１６は、異なるネットワーク上で
データを送信する異なる送信装置のような、複数の装置を備えてよい。例えば、支払レー
ル上でデータを送信する第１送信装置、及びインターネット上でデータを送信する第２送
信装置等である。送信装置２１６は、受信コンピューティング装置によって解析され得る
データが重畳されたデータ信号を、電子送信してよい。場合によっては、送信装置２１６
が、データを、送信に適するデータ信号に重畳する、エンコードする、又さもなければフ
ォーマットする１つ以上のモジュールを含んでよい。

送信装置２１６は、センダ機関１１４に、資金供給依頼が重畳された又さもなければエ
ンコードされたデータ信号を電子送信するよう構成されてよい。資金供給依頼は、少なく
とも、主要アカウント番号及び支払額を含んでよく、又は集計された送金のために、複数
の主要アカウント番号及び関連する支払額を有する支払額を含んでよい。また送信装置２
１６は、決済予告が重畳された又さもなければエンコードされたデータ信号を、レシピエ
ント機関１１６に電子送信するよう構成されてもよい。レシピエント機関１１６に送信さ
れる決済予告は、レシピエントアカウント番号及び決済額を含んでよく、又は合算決済の
ための単一の決済額、複数のレシピエントアカウント番号、及び関連する決済額を含んで
よい。また送信装置２１６は、レシピエントシステム１１０及び／又はレシピエントネッ
トワーク１１８にデータ信号を電子送信するよう構成されてもよい。データ信号は、少な
くとも決済額が重畳されてよく、又さもなければエンコードされてよく、また係わるポイ
ントツーポイントのための整合データ等の、レシピエントエンティティが使用するのに適
する追加データを含んでもよい。追加データは、例えば、請求書番号、発注書番号、製品
品目データ等を含んでよい。また送信装置２１６は、データ信号を、処理システム１０２
における他のコンピューティング装置２００に送信するよう構成されてもよい。例えば、
第１コンピューティング装置１０４の送信装置２１６はデータ信号を第２コンピューティ
ング装置１０６に送信し、第２コンピューティング装置１０６が、資金供給依頼に含める
集計された送金依頼を含んでよい。送信装置２１６は更に、従来の方法及びシステムを使
用して、資金を、（例えばレシピエント機関１１６と関連付けられた）トランザクション
アカウントに送金する、又は資金の移転を開始するための命令を電子送信するよう構成さ
れてよい。

場合によっては、送信装置２１６は、データ信号を第三者エンティティに電子送信する
よう構成されてよい。データ信号は、ISO8583標準からISO20022標準への変換等の、１つ
の標準から別の標準へ変換するデータメッセージが重畳される、又さもなければエンコー
ドされる。いくつかの実施形態では、コンピューティング装置２００の送信装置２１６は
、単一の標準を使用してフォーマットされるデータ信号を送信するよう構成されてよい。
いくつかの場合では、コンピューティング装置２００は、複数の送信装置２１６を含んで
よい。その場合、各送信装置２１６は、単一の関連する標準を使用してフォーマットされ
たデータメッセージを送信するよう構成されてよい。

また送信装置２１６は、第２データメッセージを、主要アカウント番号に係るトランザ
クションアカウントと関連付けられた第１金融機関に電子送信するよう構成されてよい。
送信装置２１６は、第３データメッセージを、レシピエントアカウント番号に係るトラン
ザクションアカウントと関連付けられた第２金融機関に電子送信し、また第１データメッ
セージと、第２データメッセージと、第３データメッセージとを、グラフィカルユーザイ
ンターフェイス（GUI）上に表示するために、送信してよい。

またコンピューティング装置２００は、メモリ２１８を含んでもよい。メモリ２１８が
、本開示で説明する機能を実行する際にコンピューティング装置２００が使用するデータ
を格納するよう構成されてよい。メモリ２１８は、適切なデータフォーマット方法及びス
キームを使用してデータを格納するよう構成されてよく、リードオンリーメモリ、ランダ
ムアクセスメモリ等の、任意の適切なタイプのメモリとしてよい。メモリ２１８は、例え
ば、暗号鍵及びアルゴリズム、通信プロトコル及び標準、データフォーマット標準及びプ
ロトコル、処理装置のモジュール及びアプリケーションプログラム用プログラムコード、
並びに本開示の機能を実行する際にコンピューティング装置２００が使用するのに適する
、当業者に自明な他のデータを含んでよい。いくつかの実施形態では、メモリ２１８は、
そこに格納される構造化データセットの格納、識別、修正、更新、アクセス等のために、
構造化クエリ言語を利用するリレーショナルデータベースから構成されてよく、又さもな
ければそれらを含んでよい。

ポイントツーポイントトランザクションを決済する第１プロセス
図３Ａは、例示的実施形態による、単一のコンピューティング装置、及びエンティティ
システムを使用してポイントツーポイントランザクションを決済するプロセス３００ａの
フロー図である。ポイントツーポイントランザクションを処理及び決済するプロセス３０
０ａは、単一のコンピューティング装置２００を有する処理システム１０２を利用する。
その場合処理システム１０２が、センダシステム１０８及びレシピエントシステム１１０
と直接に通信する。

ステップ３０２ａにおいて、センダシステム１０８は、ポイントツーポイントトランザ
クションのための送金依頼が重畳された又さもなければエンコードされたデータ信号を、
処理システム１０２に電子送信してよい。送金依頼は、少なくとも、ポイントツーポイン
トランザクションに資金を供給するために使用されるトランザクションアカウントと関連
付けられた主要アカウント番号、ポイントツーポイントランザクションにおいて支払われ
るトランザクション額、及び支払われた資金を受領するために使用されるトランザクショ
ンアカウントと関連付けられたレシピエントアカウント番号を含んでよい。いくつかの実
施形態で、また送金依頼は、発注書番号、請求書番号、及び製品品目データ等の、整合デ
ータを含んでもよい。処理システム１０２のコンピューティング装置２００の受信装置２
０２は、データ信号を受信し、そこに重畳された送金依頼を解析することができる。いく
つかの場合では、送金依頼は、ISO8583標準又はISO20022標準等に従ってフォーマットさ
れてよい。

ステップ３０４ａにおいて、処理システム１０２におけるコンピューティング装置２０
０の決定モジュール２１４は、受信した送金依頼を、他のポイントツーポイント支払トラ
ンザクションのために受信した送金依頼と集計してよい。送金依頼の集計は、受信した送
金依頼におけるトランザクション額を、同一の主要アカウント番号を含む他の送金依頼に
含まれたトランザクション額と集計すること、又は同一の銀行識別番号、イシュア識別番
号、又は単一のセンダ機関１１４と関連付けられた他の識別値を有する他の主要アカウン
ト番号を含むトランザクション額と集計することを含んでよい。場合によっては、またス
テップ３０４ａにおいて実行する集計は、受信した送金依頼と他の送金依頼との、決済の
ための集計を含んでもよい。その場合、他の送金依頼は、同一のレシピエントアカウント
番号、又は、同一の銀行識別番号、イシュア識別番号を有する他のレシピエントアカウン
ト番号、又は単一のレシピエント機関１１６と関連付けられた識別値を含んでよい。集計
の一部として、処理システム１０２におけるコンピューティング装置２００の生成モジュ
ール２１２は、資金供給依頼を生成してよい。その場合、資金供給依頼が、センダ機関１
１４のために集計された支払額、主要アカウント番号及びその関連するトランザクション
額、並びに他の主要アカウント番号及び対応するトランザクション額を含む。いくつかの
実施形態では、資金供給依頼は、ISO8583標準又はISO20022標準等に従ってフォーマット
されてよい。

ステップ３０６ａにおいて、処理システム１０２におけるコンピューティング装置２０
０の送信装置２１６は、資金供給依頼が重畳された又さもなければエンコードされたデー
タ信号を、センダ機関１１４に電子送信してよい。いくつかの実施形態では、データ信号
を、支払ネットワークと関連付けられた支払レールを介して電子送信してよい。ステップ
３０８ａにおいて、センダ機関１１４は、処理システム１０２から受信した資金供給依頼
に示されたように、送金依頼に含まれたトランザクション額のために、センダシステム１
０８に発行されたトランザクションアカウントから、主要アカウント番号と関連付けられ
るように、引き落としを行う。ステップ３１０ａにおいて、センダ機関１１４は、従来の
方法及びシステムを使用して、資金供給依頼に含まれた支払額であって、集計された支払
額を合計する送金資金を、処理システム１０２に移転してよい。

ステップ３１２ａにおいて、処理システム１０２におけるコンピューティング装置２０
０の決定モジュール２１４は、送金の整合を実行してよい。整合は、受領した送金資金を
、対応する送金依頼と関連付けることを含んでよく、受領した額、及び対応する資金供給
依頼へと集計された送金依頼に基づいてよい。また整合は、センダシステム１０８から受
信した送金依頼に含まれたレシピエントアカウント番号と関連付けられたレシピエント機
関１１６のために集計された決済額が、多様なセンダ機関１１４から受領されたかを決定
することを含んでもよい。

適切な額の資金がレシピエント機関の決済のために受領されたら、処理システム１０２
におけるコンピューティング装置２００の生成モジュール２１２は、決済予告を生成して
よい。決済予告が、集計された決済額、レシピエントアカウント番号、送金依頼からのト
ランザクション額、並びに他のレシピエントアカウント番号、及び対応する集計された送
金依頼からの関連するトランザクション額を含む。いくつかの場合では、決済予告は、IS
O8583標準又はISO20022標準等に従ってフォーマットされてよい。ステップ３１４ａにお
いて、処理システム１０２におけるコンピューティング装置２００の送信装置２１６は、
決済予告が重畳された又さもなければエンコードされたデータ信号を、レシピエント機関
１１６に電子送信してよい。場合によっては、データ信号を、支払ネットワークと関連付
けられた支払レールを介して電子送信してよい。ステップ３１６ａにおいて、送信装置２
１６は、従来の方法を使用して、集計された決済額に対応する資金を、レシピエント機関
１１６へ移転してよく、又はレシピエント機関１１６への移転を開始してよい。

ステップ３１８ａにおいて、レシピエント機関１１６は、送金依頼に含まれたレシピエ
ントアカウント番号と関連付けられたレシピエントエンティティに発行されたトランザク
ションアカウントに、トランザクション額を入金してよい。またレシピエント機関１１６
は、決済予告に含まれた他のレシピエントアカウント番号と関連付けられた他のトランザ
クションアカウントに、関連するトランザクション額を入金することもできる。ステップ
３１２ａにおいて実行する整合の一部として、また処理システム１０２におけるコンピュ
ーティング装置２００の生成モジュール２１２は、レシピエントシステム１１０のための
決済予告を生成することもできる。決済予告は、少なくともトランザクション額を含んで
よく、また送金依頼に含まれた整合データをも含んでよく、適用可能であれば、レシピエ
ントシステム１１０に提供するのに適する任意の他のデータを含んでよい。決済予告は、
ISO8583又はISO20022標準等の標準に従ってフォーマットされてよい。ステップ３２０ａ
において、送信装置２１６は、決済予告が重畳された又さもなければエンコードされたデ
ータ信号を、レシピエントシステム１１０に電子送信してよい。

図３Ｂは、例示的実施形態による、単一のコンピューティング装置、及びエンティティ
システムを使用してポイントツーポイントランザクションを記録、処理、及び表示するプ
ロセス３００ｂのフロー図である。ポイントツーポイントランザクションを記録、処理及
び表示するプロセス３００ｂは、単一のコンピューティング装置２００を有する処理シス
テム１０２を利用する。その場合処理システム１０２が、センダシステム１０８及びレシ
ピエントシステム１１０と直接に通信する。

ステップ３０２ｂにおいて、センダシステム１０８は、ポイントツーポイントトランザ
クションのためのトランザクション明細が重畳された又さもなければエンコードされたデ
ータ信号を、処理システム１０２に電子送信してよい。トランザクション明細は、少なく
とも、ポイントツーポイントランザクションに資金を供給するために使用されるトランザ
クションアカウントと関連付けられた主要アカウント番号、ポイントツーポイントランザ
クションにおいて支払われるトランザクション額、及び支払われた資金を受領するために
使用されるトランザクションアカウントと関連付けられたレシピエントアカウント番号を
含んでよい。いくつかの実施形態では、またトランザクション明細は、発注書番号、請求
書番号、及び製品品目データ等の、整合データを含んでもよい。処理システム１０２のコ
ンピューティング装置２００の受信装置２０２は、データ信号を受信してよく、そこに重
畳された送金依頼を分析してよい。いくつかの場合では、トランザクション明細は、ISO8
583標準又はISO20022標準等に従ってフォーマットされてよい。

ステップ304bにおいて、処理システム１０２におけるコンピューティング装置２００は
、その支払トランザクションのために受信したトランザクション明細、及び他のポイント
ツーポイント支払トランザクションのために受信したトランザクション明細を格納してよ
い。ステップ３０６ｂにおいて、処理システム１０２におけるコンピューティング装置２
００の送信装置２１６は、資金供給依頼が重畳された又さもなければエンコードされたデ
ータ信号を、センダ機関１１４に電子送信してよい。いくつかの実施形態では、データ信
号を、支払ネットワークと関連付けられた支払レールを介して電子送信してよい。ステッ
プ３０８ｂにおいて、センダ機関１１４は、処理システム１０２から受信した資金供給依
頼に示されたように、トランザクション明細に含まれたトランザクション額のために、セ
ンダシステム１０８に発行されたトランザクションアカウントから、主要アカウント番号
と関連付けられるように、引き落としを行なってよい。ステップ３１０ｂにおいて、セン
ダ機関１１４は、従来の方法及びシステムを使用して、資金供給依頼に含まれた支払額を
合計する資金を、処理システム１０２に移転してよい。

いくつかの実施形態では、第三者システム１２４は、トランザクション明細を認識して
よい。第三者システム１２４が、例えば、予期される決済に基づいて借り入れするレシピ
エントエンティティのための資金提供に、関心を持つ会社であってよい。レシピエントエ
ンティティは、処理システム１０２を使用して、第三者システム１２４が彼らの支払トラ
ンザクションに関する元帳を閲覧する許可をオプトインすることができる。ステップ３２
２ｂにおいて、第三者システム１２４は、決済される支払トランザクション及びレシピエ
ントエンティティと関連付けられた元帳に格納された追加トランザクションに関する、取
引ディレクトリの閲覧にアクセスすることができる。

ステップ３２４ｂにおいて、第三者システム１２４は、レシピエントエンティティが要
求に応じて現金を得る能力を、決済される支払トランザクションと関連付けられたオファ
ーを彼らに提供することによって、提供してよい。第三者システム１２４は、レシピエン
トエンティティのトランザクション履歴を再調査してよい。再調査は、レシピエントエン
ティティとトランザクションのために送金を支払う特定のセンダエンティティとの間の、
先のトランザクションを識別することを含んでよい。また第三者システムが、トランザク
ションに基づいて、ローンを提供するための金利を決定してよい。レシピエントエンティ
ティによって受諾され得る又は拒否され得るオファーは、レシピエントエンティティに、
直接に又は処理システム１０２を介して通信されてよい。受諾された場合、第三者システ
ム１２４は、レシピエントエンティティによって直接になされ得る、又は処理システム１
０２を介してなされ得る、及び／又は本開示で説明する決済プロセスの一部としてレシピ
エント機関１１６によってなされ得る後の返済のために、レシピエントエンティティに対
して早期支払を提供することができる。

ステップ３１４ｂにおいて、処理システム１０２におけるコンピューティング装置２０
０の送信装置２１６は、決済予告が重畳された又さもなければエンコードされたデータ信
号を、レシピエント機関１１６に電子送信してよい。いくつかの実施形態では、データ信
号を、支払ネットワークと関連付けられた支払レールを介して電子送信してよい。ステッ
プ３１６ｂにおいて、送信装置２１６は、集計された決済額に対応する資金を、従来の方
法を使用してレシピエント機関１１６へ移転してよく、又はレシピエント機関１１６への
移転を開始してよい。

ステップ３１８ｂにおいて、レシピエント機関１１６は、送金依頼に含まれたレシピエ
ントアカウント番号と関連付けられたレシピエントエンティティに発行されたトランザク
ションアカウントに、トランザクション額を入金してよい。またレシピエント機関１１６
は、決済予告に含まれた他のレシピエントアカウント番号と関連付けられた他のトランザ
クションアカウントに、関連するトランザクション額を入金することもできる。レシピエ
ントエンティティが第三者システム１２４のオファーを受諾した場合、レシピエント機関
１１６は、クレジット額の支払を第三者システム１２４に提供することができる。そのよ
うな場合のいくつかでは、レシピエント機関１１６は、通常通りに、トランザクションア
カウントに入金してよい。その場合レシピエントエンティティは、第三者システム１２３
に独自にローンを返済することができる。ステップ３２０ｂにおいて、送信装置２１６は
、トランザクションステータスが重畳された又さもなければエンコードされたデータ信号
を、レシピエントシステム１１０に電子送信してよい。そのためレシピエントは、トラン
ザクション明細を詳述する元帳を閲覧可能である。レシピエントエンティティは、次いで
、設定された条件に従ってローンを返済することによって、第三者システム１２４とのト
ランザクションを終了してよい。

ポイントツーポイントトランザクションを決済する第２プロセス
図４は、第１コンピューティング装置１０４及び第２コンピューティング装置１０６を
使用する処理システム１０２を利用する、ポイントツーポイントランザクションを処理及
び決済する代替的なプロセス４００を示す。その場合処理システム１０２が、センダネッ
トワーク１１２及びレシピエントネットワーク１１８のそれぞれを介して、センディング
エンティティ及びレシピエントエンティティと直接に通信する。場合によっては、センダ
ネットワーク１１２及びレシピエントネットワーク１１８が、同一のエンティティであっ
てよい。

ステップ４０２において、センダネットワーク１１２はセンディングエンティティから
、送金情報を受信してよい。いくつかの場合では、送金情報は、センダシステム１０８か
らの電子送信を介する等、センダシステム１０８から受信されてよい。他の場合では、送
金情報は、ウエブページ又はアプリケーションプログラムを介する等、センディングエン
ティティによって使用されるコンピューティング装置との通信を介して受信されてよい。
いくつかの場合では、送金情報は、センディングエンティティから受信した命令に基づい
てセンダネットワーク１１２に手動でデータを入力するセンダネットワーク１１２の従業
員等の、センダネットワーク１１２のユーザによって手動で入力されてよい。センダネッ
トワーク１１２に提供された送金情報は、センダ機関１１４によってセンディングエンテ
ィティに発行されたトランザクションアカウントのための主要アカウント番号、支払われ
るトランザクション額、及び支払を受領するためにレシピエント機関１１６によってレシ
ピエントエンティティに発行されたトランザクションアカウントのためのレシピエントア
カウント番号を含んでよい。

ステップ４０４において、センダネットワーク１１２は、送金依頼が重畳された又さも
なければエンコードされたデータ信号を、処理システム１０２の第１コンピューティング
装置１０４に電子送信してよい。送金依頼は、少なくとも、主要アカウント番号、トラン
ザクション額、及びレシピエントアカウント番号を含んでよい。いくつかの実施形態では
、送金依頼は、ISO8583標準に従ってフォーマットされてよい。ステップ４０６において
、第１コンピューティング装置１０４の決定モジュール２１４は、送金依頼を関連する送
金依頼と集計してよい。集計は、ポイントツーポイントランザクションの送金のための集
計、及びポイントツーポイントトランザクションの決済のための集計を含んでよい。送金
の集計は、送金依頼を、同一の主要アカウント番号又は他の主要アカウント番号を含む他
の送金依頼と集計することを含んでよい。その場合、各送金依頼は、センダ機関１１４と
関連付けられた共通の識別値を含む。決済の集計は、送金依頼を、同一のレシピエントア
カウント番号又は他のレシピエントアカウント番号を含む他の送金依頼と集計することを
含んでよい。その場合各送金依頼は、レシピエント機関１１６と関連付けられた共通の識
別値を含む。

ステップ４０８において、第１コンピューティング装置１０４の送信装置２１６は、内
部通信方法及びネットワークを使用して、センダ機関１１４と関連付けられた資金供給デ
ータを、処理システム１０２の第２コンピューティング装置１０６に電子送信してよい。
第２コンピューティング装置１０６の受信装置２０２は、資金供給データを受信してよい
。資金供給データが、少なくとも、トランザクション額、受信された送金依頼に含まれた
主要アカウント番号、及び識別され集計された送金依頼を含んでよい。いくつかの場合で
は、また資金供給データは、集計された支払額を含んでもよい。他の場合では、第２コン
ピューティング装置１０６の決定モジュール２１４は、集計された支払額を決定してよい
。

第２コンピューティング装置１０６の生成モジュール２１２は、資金供給依頼を生成し
てよい。その場合、資金供給依頼は、少なくとも、集計された支払額、各主要アカウント
番号、及び関連するトランザクション額を含んでよい。いくつかの実施形態では、資金供
給依頼は、ISO20022標準に従ってフォーマットされてよい。ステップ４１０において、第
２コンピューティング装置１０６の送信装置２１６は、資金供給依頼が重畳された又さも
なければエンコードされたデータ信号を、センダ機関１１４に電子送信してよい。ステッ
プ４１２において、センダ機関１１４は、資金供給依頼に含まれた各主要アカウント番号
に対応するトランザクションアカウントから、関連するトランザクション額を引き落とし
てよい。ステップ４１４において、センダ機関１１４は、集計された支払額の金額である
送金資金の、処理システム１０２への移転を開始してよい。

ステップ４１６において、第２コンピューティング装置１０６の決定モジュール２１４
は、受領した送金資金の整合を実行してよい。整合は、送金資金の、受信した資金供給デ
ータとの整合を含んでよく、どの送金依頼が資金を供給されたかを決定してよい。整合の
一部としてステップ４１８において、第２コンピューティング装置１０６の送信装置２１
６は、内部通信ネットワーク及び方法を使用して、送金資金の受領の確認を第１コンピュ
ーティング装置１０４に電子送信してよい。いくつかの実施形態では、第２コンピューテ
ィング装置１０６は、送金資金の受領のみを確認するだけでよい。追加の整合は、第１コ
ンピューティング装置１０４の決定モジュール２１４によって実行される。整合は、（例
えばステップ４０６において実行されるように）レシピエント機関１１６のために集計さ
れた決済額の、適切な金額が受領されたかを決定することを含んでよい。

適切な額が受領されたら、次いで、ステップ４２０において、第１コンピューティング
装置１０４の送信装置２１６は、決済を実行する依頼が重畳された又さもなければエンコ
ードされたデータ信号を、内部通信ネットワーク及び方法を使用して第２コンピューティ
ング装置１０６に電子送信してよい。決済依頼は、少なくとも、レシピエントアカウント
番号及びレシピエント機関１１６のために集計されたトランザクション額を含んでよい。
いくつかの実施形態では、また決済依頼は、集計された決済額を含んでよい。他の実施形
態では、第２コンピューティング装置１０６の決定モジュール２１４は、集計された決済
額を決定してよい。

決済を依頼すると、第１コンピューティング装置１０４は、（例えばそこに含まれた生
成モジュール２１２を介して）レシピエントエンティティに配信するための決済予告を生
成してよい。決済予告は、少なくとも、受信した送金依頼に含まれたトランザクション額
及び整合データ等の任意の追加データを含んでよい。いくつかの実施形態では、決済予告
は、ISO8583標準に従ってフォーマットされてよい。ステップ４２２において、第１コン
ピューティング装置１０４の送信装置２１６は、決済予告が重畳された又さもなければエ
ンコードされたデータ信号を、レシピエントネットワーク１１８に電子送信してよい。ス
テップ４２４において、レシピエントネットワーク１１８は、決済資金が受領されたこと
をレシピエントエンティティに通知してよい。レシピエントネットワーク１１８は、電話
、電子メール、ショートメッセージサービス、マルチメディアメッセージサービス等の適
切な方法を介して、レシピエントエンティティと通信してよい。

第１コンピューティング装置１０４から決済依頼を受信した後、第２コンピューティン
グ装置１０６の生成モジュール２１２は、レシピエント機関１１６に配信するために決済
予告を生成してよい。この決済予告は、少なくとも、集計された送金依頼からの各レシピ
エントアカウント番号及び関連するトランザクション額を含んでよい。いくつかの場合で
は、また決済予告は、集計された決済額を含んでもよい。いくつかの実施形態では、決済
予告は、ISO20022標準に従ってフォーマットされてよい。ステップ４２６において、第２
コンピューティング装置１０６の送信装置２１６は、決済予告が重畳された又さもなけれ
ばエンコードされたデータ信号を、レシピエント機関１１６に電子送信してよい。ステッ
プ４２８において、処理システム１０２は、集計された決済額のレシピエント機関１１６
への移転を開始してよい。ステップ４３０において、レシピエント機関は、レシピエント
アカウント番号に対応する各トランザクションアカウントに、関連するトランザクション
額を入金してよい。

ポイントツーポイントトランザクションのための合算決済のプロセス
図５Ａ及び図５Ｂは、例示的実施形態による、図１の処理システムにおいて、複数のコ
ンピューティング装置を使用してポイントツーポイントランザクションを決済するプロセ
スのフロー図である。図５Ａ及び図５Ｂは、処理システム１０２において、複数のコンピ
ューティング装置２００を使用して、集計されたポイントツーポイントランザクションを
決済するプロセスを示す。その場合、ポイントツーポイントランザクションは、送金及び
決済の両方のために集計される。図５Ａ及び図５Ｂに示す処理システム１０２によって実
行される本開示で説明する機能は、単一のコンピューティング装置２００を使用して代替
的に実行され得ること、また図５Ａ及び図５Ｂに示すプロセスに対する代替として、送金
のみ又は決済のみの集計を含み得ることは、当業者にとって自明である。

ステップ５０２において、第１コンピューティング装置１０４の受信装置２０２は、複
数の送金依頼を受信してよい。送金依頼が、センダシステム１０８、センダネットワーク
１１２、及び／又はセンダ機関１１４から受信されてよい。各送金依頼は、少なくとも、
そこから支払がなされるトランザクションアカウントと関連付けられた主要アカウント番
号、支払のためのトランザクション額、及び支払を受領するためのトランザクションアカ
ウントと関連付けられたレシピエントアカウント番号を含んでよい。いくつかの実施形態
では、また送金依頼は、整合データを含んでよい。場合によっては、送金依頼は、ISO858
3又はISO20022標準に従ってフォーマットされてよい。

ステップ５０４において、第１コンピューティング装置１０４の決定モジュール２１４
は、送金額及び複数の送金依頼のための資金供給額を集計してよい。送金額は、受信され
た送金依頼に含まれた少なくとも１つの主要アカウント番号と関連付けられた各センダ機
関１１４のための額であってよい。その場合、それぞれの送金額は、センダ機関１１４と
関連付けられた主要アカウント番号を含む各送金依頼に含まれたトランザクション額の合
計であってよい。これは、銀行識別番号、イシュア識別番号、又は主要アカウント番号に
含まれた他の識別値に基づいて決定してよい。資金供給額は、受信された送金依頼に含ま
れた少なくとも１つのレシピエントアカウント番号と関連付けられた各レシピエント機関
１１６のための額であってよい。その場合、それぞれの資金供給額は、レシピエント機関
１１６と関連付けられた主要アカウント番号を含む各送金依頼に含まれたトランザクショ
ン額の合計であってよい。これは、銀行識別番号、イシュア識別番号、又はレシピエント
アカウント番号に含まれた他の識別値に基づいて決定してよい。

ステップ５０６において、第１コンピューティング装置１０４の生成モジュール２１２
は、資金供給データを生成してよい。資金供給データが、各センダ機関１１４のために決
定された送金額、対応するセンダ機関１１４、並びに各センダ機関１１４のための関連す
る主要アカウント番号及び対応するトランザクション額を含んでよい。ステップ５０８に
おいて、第１コンピューティング装置１０４の送信装置２１６は、資金供給データが重畳
された又さもなければエンコードされたデータ信号を、処理システム１０２の内部通信ネ
ットワーク及び方法を介して第２コンピューティング装置１０６に電子送信してよい。ス
テップ５１０において、第２コンピューティング装置１０６の受信装置２０２は、資金供
給データを受信してよい。

ステップ５１２において、第２コンピューティング装置１０６の生成モジュール２１２
は、各センダ機関１１４のための資金供給依頼を生成してよい。資金供給依頼は、対応す
るトランザクション額と関連付けられた送金額及び関連付けられた主要アカウント番号を
含む。資金供給依頼は、第２コンピューティング装置１０６の送信装置２１６によってそ
れぞれのセンダ機関１１４に電子送信されるデータ信号に、重畳されてよく、又さもなけ
ればエンコードされてよい。いくつかの実施形態では、各資金供給依頼は、ISO8583又はI
SO20022標準に従ってフォーマットされてよい。センダ機関１１４は、資金供給依頼を受
信し、それらを処理システム１０２に提供される送金額と共に適宜に処理してよい。ステ
ップ５１４において、第２コンピューティング装置１０６の受信装置２０２は、送金資金
をセンダ機関１１４から受領する、又は受領の確認を受信してよい。

ステップ５１６において、第２コンピューティング装置１０６の送信装置２１６は、デ
ータを、処理システム１０２の内部通信方法及びネットワークを使用して第１コンピュー
ティング装置１０４に電子送信してよい。データは、送金資金の受領の確認が重畳される
。確認は、少なくとも、そこから資金が受領されたセンダ機関１１４及び受領された対応
する送金額を含んでよい。ステップ５１８において、第１コンピューティング装置１０４
の受信装置２０２は、確認を受信してよい。ステップ５２０において、第１コンピューテ
ィング装置１０４の決定モジュール２１４は、送金資金の整合を実行してよい。整合は、
受領された資金がどの送金依頼に対応するか決定することを含んでよい。これは、いずれ
のレシピエント機関１１６との決済のために適切な資金が受領されたかを決定するために
使用することができる。

ステップ５２２において、第１コンピューティング装置１０４の生成モジュール２１２
は、決済依頼を生成してよい。決済依頼が、（例えば整合に基づいて）決済を受領する各
レシピエント機関１１６のための資金供給額、並びに関連するレシピエントアカウント番
号及び対応するトランザクション額を含んでよい。また生成モジュール２１２は、（例え
ば第１コンピューティング装置１０４の送信装置２１６を介して）決済依頼を、処理シス
テム１０２の適切な内部通信ネットワーク及び方法を使用して、第２コンピューティング
装置１０６に電子送信してよい。いくつかの実施形態では、決済依頼は、ISO8583又はISO
20022標準に従ってフォーマットされてよい。ステップ５２４において、第１コンピュー
ティング装置１０４の生成モジュール２１２は、複数の送金依頼の各々のための決済予告
を生成してよい。決済予告が、少なくとも、トランザクション額及び任意の他の追加デー
タ（例えば、送金依頼に含まれた整合データ等）を含んでよい。決済予告は、レシピエン
トエンティティにポイントツーポイントランザクションの決済を通知するために、関連す
るレシピエントシステム１１０、レシピエント機関１１６、又はレシピエントネットワー
ク１１８に電子送信されるデータ信号に、重畳されてよく、又さもなければエンコードさ
れてよい。

ステップ５２６において、第２コンピューティング装置１０６の受信装置２０２は、第
１コンピューティング装置１０４から決済依頼を受信してよい。ステップ５２８において
、第２コンピューティング装置１０６の生成モジュール２１２は、各レシピエント機関１
１６のための決済通知を生成してよい。各決済通知は、レシピエント機関１１６のために
決定された集計された資金供給額、送金依頼からの関連するレシピエントアカウント番号
、及び対応するトランザクション額を含んでよい。いくつかの実施形態では、決済通知は
、ISO8583又はISO20022標準に従ってフォーマットされてよい。ステップ５３０において
、第２コンピューティング装置１０６の送信装置２１６は、関連する決済通知が重畳され
た又さもなければエンコードされたデータ信号を、各レシピエント機関１１６に電子送信
してよい。ステップ５３２おいて、送信装置２１６は、従来の方法及びシステムを使用し
て、決済資金を各レシピエント機関１１６へ移転してよく、又は決済資金の各レシピエン
ト機関１１６への移転を開始してよい。

ポイントツーポイントトランザクションを記録及び表示するプロセス
図６Ａ及び図６Ｂ（以下、まとめて図６と称する）は、例示的実施形態による、図１の
処理システムにおいて、ポイントツーポイントランザクションを記録、処理、及び表示す
るプロセス６００の図である。例えば、プロセス６００は、非カード型支払を経由してサ
プライヤ又はベンダに支払う会社の能力を提供することを示す。なぜなら、サプライヤが
その顧客に請求明細書を送付する場合、典型的には、サプライヤはクレジットカードでの
支払いを受け付けないためである。

ステップ６０８において、バイヤ６０２（例えばセンダエンティティ）は、商品及び／
又は役務のための発注書を発行してよい。発注書を、システムプラットフォーム６０４に
送付してよい。システムプラットフォーム６０４は、処理システム１０２によって提供さ
れるプラットフォームであり、そこに含まれた第１コンピューティング装置１０４及び第
２コンピューティング装置１０６等のコンピューティング装置２００を介して実行される
プラットフォームであってよい。ステップ６１０において、システムプラットフォーム６
０４が、このデータをトランザクション明細として、サプライヤ６０６（例えばレシピエ
ントエンティティ）に送信してよく、発注書の受領を確認することができる。

いくつかの実施形態では、システムプラットフォーム６０４は、APIを使用して重要な
トランザクションデータ（例えば、トランザクション額、依頼された商品及び／又は役務
の名称、依頼された商品及び／又は役務の数、支払日付等）を取り込んでよく、また情報
を、元帳内の内部データベース（例えばアカウントデータベース２０６）に、バイヤ６０
２及びサプライヤ６０６の取引ディレクトリ内のアカウントプロファイル情報と共に格納
してよい。システムプラットフォーム６０４は、オリジナルの発注書、請求書、及び／又
はトランザクションに係わる任意の他の通信へのリンクを提供してよい。リンクは、バイ
ヤ６０２、サプライヤ６０６、及び／又は任意の他のシステムのウエブサイト及び／又は
支払処理システムに戻るオリジナルの通信を示す。

ステップ６１２において、サプライヤ６０６は、システムプラットフォーム６０４に請
求書を送付してよい。システムプラットフォーム６０４が、APIを使用して重要な情報を
抽出し、ステップ６１４において、データをバイヤ６０２に送信する。例えば、サプライ
ヤは６０６、３０日又は６０日の条件でサプライヤ６０６に支払うために、請求書をバイ
ヤ６０２に送付することができる。たいていのサプライヤは、３０日以内に資金を受領し
、サプライヤが３０日のうちに支払われるよう希望するであろう。しかしながら従来技術
のシステムでは、たいていのサプライヤは、支払転記及び支払が実際にどのようになされ
るかに関して、視認性を有していない。これは、キャッシュフローの問題につながる。シ
ステムプラットフォーム６０４は、トランザクションの視認性と適時の支払期待の確実性
が、関係する全ての当事者に対して明確なプラットフォームを提供することによって、こ
れらの問題を回避する。システムプラットフォーム６０４は、当事者のアイデンティティ
及び存在する全てのトランザクションの元帳を取り込む取引ディレクトリを提供する。ま
た当事者（例えば、支払人及び受取先、又はバイヤ及びサプライヤ）のアイデンティティ
は、当事者情報、コーポレイトアイデンティティ、及びその企業内でバンキングトランザ
クション及び金融トランザクションに関する権限を有する個人、及び／又は実際の銀行口
座情報をも含む。取引ディレクトリは、システムプラットフォームを利用する上で識別さ
れた当事者間に存在する、全てのトランザクションの元帳である。

ステップ６１６において、バイヤ６０２は請求書を承認する。ステップ６１８において
、サプライヤ６０６は請求書及び支払ステータスを監視する。例えば、サプライヤ６０６
は、取引ディレクトリに登録することによって、システムを使用することをサインアップ
することが可能である。その場合、彼らの銀行口座情報はシステム内にあり、支払勘定（
AP）又は受取勘定（AR）の責任者は誰かが分かり、並びに彼らの金融財政担当役員が識別
され、サプライヤの金融トランザクションに対して権限を与えられた個人及び任意の発注
書が識別され、並びにシステムプラットフォームを介してなされる請求書及び支払が、こ
の取引ディレクトリの元帳の態様で取り込まれる。その結果、時間の経過と共に、可能と
された当事者間の各発注書、請求書、トランザクション、又はそれらのステータス及びそ
れらに対する適時の実行が、元帳に取り込まれる。

ステップ６２０において、サプライヤは前払いを選択してよい。システムプラットフォ
ーム６０４は、１つ以上の第三者システムを含んでよい。第三者システムが、第三者金融
提供者によって提案される条件に応じて、借り入れるため、又は債権をノンリコースベー
スで売却するための資金を、金利で提供する。システムプラットフォーム６０４によって
提供されるデータへの視認性は、第三者システムに機会を提供する。例えば、サプライヤ
６０６は、第三者システムがサプライヤのトランザクションに関する元帳を閲覧する許可
をオプトインすることができる。第三者システムは、プライバシーに関する関心事及びト
ランザクションに係わる全ての当事者の同意に適合する取引ディレクトリの閲覧にアクセ
スすることができる。第三者システムが、価格リスクを分析し、例えば特定の請求書につ
いてサプライヤ６０６に金融ソリューションを提供することができる。第三者システムは
、サプライヤ６０６が要求に応じて現金を得る能力を提供することができる。従ってサプ
ライヤ６０６が、彼らの現金を受領することを第３０日又は第４０日まで待つ代わりに、
第三者システムが、サプライヤ６０６とバイヤ６０２との間のトランザクションの履歴に
基づいて、バイヤ６０２が彼らの請求書の99.9パーセントを完済すると知ることができる
。従って第三者システムは、バイヤ６０２がそのサプライヤ６０６の次の請求書を支払う
つもりであると示す元帳からのデータに基づいて、高い快適度を有することができる。第
三者システムは、その際、そのサプライヤ６０６に対して、現金を前払いするための極め
て低いAPRを提供することができる。

ステップ６２２において、バイヤ６０２が支払支出日をスケジュールする。ステップ６
２４において、送金情報を伴う支払命令を、システムプラットフォーム６０４に提供する
。ステップ６２８において、サプライヤの銀行は早期支払を受領した。ステップ６３０に
おいて、バイヤの銀行は支払をシステムプラットフォーム６０４に提供する。ステップ６
３２及び６３４において、トランザクション結果に基づく、バイヤ６０２、サプライヤ６
０６、及び第三者のデータを、元帳の一部としてシステムプラットフォーム６０４にアッ
プロードする。

ポイントツーポイント支払トランザクションを処理する例示的な方法
図７は、例示的実施形態による、ポイントツーポイント支払トランザクションを処理す
る例示的な方法のフローチャートである。

ステップ７０２において、支払トランザクションに係る第１データメッセージを、処理
サーバ（例えば処理サーバ１０２）の受信装置（例えば受信装置２０２）によって受信し
てよい。第１データメッセージを、１つ以上の標準に従ってフォーマットし、１つ以上の
アプリケーションプログラムインターフェイス（API）を使用して受信する。第１データ
メッセージが、少なくとも、トランザクション明細を格納するよう構成された第１データ
要素と、主要アカウント番号を格納するよう構成された第２データ要素と、レシピエント
アカウント番号を格納するよう構成された第３データ要素と、を含む少なくとも複数のデ
ータ要素を含む。

ステップ７０４において、第１、第２及び第３データ要素を、第１データメッセージに
属する記録へのリンクと共に処理サーバ（例えば処理サーバ１０２）の商用データベース
（例えばデータベース１２２）に格納してよい。リンクが、第１データメッセージに基づ
いて文書へのアクセスを提供する。

ステップ７０６において、支払トランザクションに係わる第２データメッセージを、処
理サーバ（例えば処理サーバ１０２）の生成モジュール（例えば生成モジュール２１２）
によって生成してよい。第２データメッセージを、１つ以上の標準に従ってフォーマット
し、第２データメッセージが、支払額を格納するよう構成された第１データ要素を含む少
なくとも複数のデータ要素を含み、支払額が、少なくともトランザクション明細に基づく
。ステップ７０８において、第１データ要素を、第２データメッセージに属する記録への
リンクと共に処理サーバ（例えば処理サーバ１０２）の商用データベース（例えばデータ
ベース１２２）に格納してよい。リンクが、第２データメッセージに基づいて文書へのア
クセスを提供する。

ステップ７１０において、第２データメッセージを、処理サーバ（例えば１０２）の送
信装置（例えば送信装置２１６）によって、主要アカウント番号に係るトランザクション
アカウントと関連付けられた第１金融機関に電子送信してよい。ステップ７１２において
、支払トランザクションに係わる第３データメッセージを、処理サーバ（例えば処理サー
バ１０２）の生成モジュール（例えば生成モジュール２１２）によって生成してよい。第
３データメッセージを、１つ以上の標準に従ってフォーマットし、第３データメッセージ
が、決済額を格納するよう構成された第１データ要素と、レシピエントアカウント番号を
格納するよう構成された第２データ要素と、を含む少なくとも複数のデータ要素を含み、
決済額が、少なくともトランザクション明細に基づく。

ステップ７１４において、第１データ要素及び第２データ要素を、第３データメッセー
ジに属する記録へのリンクと共に処理サーバ（例えば処理サーバ１０２）の商用データベ
ース（例えばデータベース１２２）に格納してよい。リンクが、第３データメッセージに
基づいて文書へのアクセスを提供する。

ステップ７１６において、第３データメッセージを、処理サーバ（例えば処理サーバ１
０２）の送信モジュール（例えば送信モジュール２１６）によって、レシピエントアカウ
ント番号に係るトランザクションアカウントと関連付けられた第２金融機関に電子送信し
てよい。また第１データメッセージと、第２データメッセージと、第３データメッセージ
とを、グラフィカルユーザインターフェイス（GUI）上に表示するために、送信してよい
。

一実施形態では、第１データメッセージ、第２データメッセージ、及び第３データメッ
セージは、ISO8583標準に従ってフォーマットしてよい。別の実施形態では、第１データ
メッセージをISO8583標準に従ってフォーマットし、また第２データメッセージ及び第３
データメッセージをISO20022標準に従ってフォーマットしてよい。更なる実施形態では、
第２データメッセージを生成するステップは、ISO8583標準とISO20022標準との間の対応
に基づいて、第１データメッセージを第２データメッセージに変換するステップを含んで
よい。いくつかの実施形態では、支払額はトランザクション額と同等でよく、及び／又は
決済額はトランザクション額と同等でよい。

一実施形態では、方法１００は更に、次のステップを含んでよい。すなわち、１つ以上
の追加のデータメッセージを、処理サーバの受信装置によって受信するステップである。
各追加のデータメッセージが、追加の支払トランザクションに係わり、少なくとも、複数
のアカウント番号のうちの１つを格納するよう構成された第１データ要素と、異なるトラ
ンザクション額を格納するよう構成された第２データメッセージと、を含む複数のデータ
要素を含む。支払額は、各追加のデータメッセージに含まれた第２データ要素に格納され
た異なるトランザクション額の集計である。主要アカウント番号及び複数のアカウント番
号の各々は、共通の銀行識別番号又はイシュア識別番号を含む。更なる実施形態では、主
要アカウント番号及び複数のアカウント番号の各々は、同一のトランザクションアカウン
トに関連付けられてよい。別の更なる実施形態では、共通の銀行識別番号又はイシュア識
別番号は、第１金融機関に関連付けられてよい。

一実施形態では、トランザクション明細は、トランザクション額、注文日、履行日、及
びステータスのうちの１つ以上を含む。決済額は、トランザクション明細と同等であって
よい。いくつかの実施形態では、商用データベースに格納されたデータ要素は、取引ディ
レクトリ及び／又は元帳を備える。

いくつかの実施形態では、また方法１００は、次のステップを含んでよい。すなわち、
１つ以上の追加のデータメッセージを、処理サーバの受信装置によって受信するステップ
である。各追加のデータメッセージが、追加の支払トランザクションに係わり、少なくと
も、異なるトランザクション額を格納するよう構成された第２データ要素と、複数のアカ
ウント番号のうちの１つを格納するよう構成された第３データ要素と、を含む複数のデー
タ要素を含む。決済額は、各追加のデータメッセージに含まれた第２データ要素に格納さ
れた異なるトランザクション額の集計である。レシピエントアカウント番号及び複数のア
カウント番号の各々は、共通の銀行識別番号又はイシュア識別番号を含む。更なる実施形
態では、レシピエントアカウント番号及び複数のアカウント番号の各々は、同一のトラン
ザクションアカウントに関連付けられてよい。別の更なる実施形態では、共通の銀行識別
番号又はイシュア識別番号は、第２金融機関に関連付けられてよい。

一実施形態では、方法１００は更に、次のステップを含んでよい。すなわち、支払トラ
ンザクションに係る第４データメッセージを、処理サーバの生成モジュールによって生成
するステップであって、第４データメッセージを標準に従ってフォーマットし、第４デー
タメッセージが、少なくとも、トランザクション額を格納するよう構成された第１データ
要素と、レシピエントアカウント番号を格納するよう構成された第２データ要素と、を含
む複数のデータ要素を含むステップと、第４データメッセージを処理サーバの送信装置に
よって電子送信するステップと、である。更なる実施形態では、第４データメッセージを
、第２金融機関に電子送信してよい。別の更なる実施形態では、第１データメッセージを
第三者システムから受信してよく、また第４データメッセージを第三者システムに電子送
信してよい。また別の更なる実施形態では、第４データメッセージを、ISO8583標準に従
ってフォーマットしてよい。

いくつかの実施形態では、処理サーバは、第１コンピューティング装置（例えば第１コ
ンピューティング装置１０４）及び第２コンピューティング装置（例えば第２コンピュー
ティング装置１０６）を含んでよい。第１コンピューティング装置が受信装置を含み、第
２コンピューティング装置が、生成モジュール、決定モジュール、及び送信装置を含む。
更なる実施形態では、方法６００は更に、次のステップを含んでよい。すなわち、少なく
とも支払額が重畳されたデータ信号を、処理サーバの第１コンピューティング装置の生成
モジュールによって生成するステップと、生成したデータ信号を、処理サーバの第１コン
ピューティング装置の送信装置によって第２コンピューティング装置に電子送信するステ
ップと、データ信号を処理サーバの第２コンピューティング装置の受信装置によって受信
するステップと、である。

支払トランザクションの処理システム及びプロセス
図８は、例示的実施形態による、支払トランザクションの処理のフロー図である。

図８は、トランザクション処理システム、及びシステムにおいて支払トランザクション
を処理するプロセス８００を示す。支払トランザクションは、（例えば毎時、毎日、毎週
等の）所定期間に、数千、数百万、及び数十億にもなる支払トランザクションを含んでよ
い。プロセス８００及びそこに含まれたステップは、処理システム１０２、センダ機関１
１４、レシピエント機関１１６等の、上記で説明したシステム１００の１つ以上のコンポ
ーネントによって実行されてよい。図８に示すシステム及びプロセス８００を使用する以
下に説明する支払トランザクションの処理は、支払レールを利用してよい。支払レールは
、コンピューティング装置、及びプロセス８００のステップを実行するために利用される
インフラストラクチャを備えてよい。それらは、以下に説明するエンティティによって特
別に構成され、プログラムされ、またトランザクション処理サーバ８１２を含む。トラン
ザクション処理サーバ８１２は、支払トランザクションを処理するよう構成された１つ以
上の支払ネットワークと関連付けられてよい。当業者にとって自明であるように、プロセ
ス８００は、支払トランザクションの処理に関係するステップについて上記で説明した図
３Ａ、３Ｂ、４、５Ａ、５Ｂ、６及び７に示すプロセス内に組み込まれてよい。更に、本
開示で説明するプロセス８００を実行するエンティティは、下記で説明する機能を実行す
るよう構成された１つ以上のコンピューティング装置又はシステムを含んでよい。例えば
、販売者８０６は、１つ以上の販売時点（point of sale）デバイス、ローカル通信ネッ
トワーク、コンピューティングサーバ、及び以下に説明する機能を実行するよう構成され
た他のデバイスを備えてよい。

ステップ８２０において、発行金融機関８０２は、支払カード又は他の適切な支払手段
を、消費者８０４に発行してよい。発行金融機関８０２は金融機関であってよい。金融機
関は、例えば銀行であってよく、又は支払アカウント、及び／又は支払トランザクション
に資金を供給するために支払アカウントと共に使用可能な支払手段を、執行及び管理する
他の適切なタイプのエンティティであってよい。消費者８０４は、発行金融機関８０２に
トランザクションアカウントを持つことができる。発行された支払カードは、トランザク
ションアカウントに関連付けられる。例えば、支払カードが支払に使用されると、支払ト
ランザクションは、関連するトランザクションアカウントによって資金を供給される。い
くつかの実施形態では、支払カードを消費者８０４に物理的に発行してよい。他の実施形
態では、支払カードは、仮想支払カードであってもよく、又はさもなければ電子的フォー
マットで消費者８０４に支給されてもよい。

ステップ８２２において、消費者８０４は、支払トランザクションに資金を供給する際
に使用するために、発行された支払カードを販売者８０６に提示してよい。販売者８０６
は、企業、別の消費者、又は消費者８０４との支払トランザクションに関与する任意のエ
ンティティであってよい。物理的なカードを販売者８０６に提出すること、支払カードの
ための支払明細を電子的に（例えば近距離通信、無線送信、又は他の適切な電子送信タイ
プ及びプロトコル等を介して）送信すること、又は第三者を介して支払明細の販売者８０
６への送信を開始することを介して、消費者８０４は支払カードを提示してよい。販売者
８０６は、（例えば電子送信を介して、物理的な支払カードから読むことを介して）支払
明細を受信してよい。支払明細は、少なくとも、支払カードと関連付けられたトランザク
ションアカウント番号及び／又は関連するトランザクションアカウントを含んでよい。場
合によっては、支払明細は、支払トランザクションの処理の際に使用することができる１
つ以上のアプリケーション暗号を含んでよい。

ステップ８２４において、販売者８０６は、トランザクション明細を販売時点コンピュ
ーティングシステムに入力してよい。トランザクション明細は、支払カードと関連付けら
れた消費者８０４によって提供された支払明細、及びトランザクション額、時間及び／又
は日付、製品データ、オファーデータ、ロイヤルティデータ、報酬データ、販売者データ
、消費者データ、販売時点データ等の、トランザクションと関連付けられた追加の詳細を
含んでよい。トランザクション明細を、製品バーコードをスキャンするよう構成された光
学バーコードスキャナ、ユーザによって入力された製品コードを受信するよう構成された
キーボード等の、１つ以上の入力装置を介して、販売者８０６の販売時点システムに入力
してよい。販売者販売時点システムは、電子金融トランザクションの処理目的及び（例え
ば支払レールを介する）支払ネットワークとの通信目的を意図して特別に構成されたコン
ピューティング装置及び／又は専用コンピューティング装置であってよい。販売者販売時
点システムは、電子装置であってよく、その上で販売時点システムアプリケーションが作
動する。アプリケーションは、電子装置に、電子金融トランザクション情報を受信させて
、支払ネットワークに通信させる。いくつかの実施形態では、販売者８０６は、電子商取
引におけるオンライン小売業者であってよい。そのような実施形態では、当業者にとって
自明であるように、トランザクションデータを電子トランザクションに格納するために、
トランザクション明細をショッピングカート又は他のリポジトリに入力してよい。

ステップ８２６において、販売者８０６は、トランザクションデータが重畳されたデー
タ信号を、ゲートウエイプロセッサ８０８に電子送信してよい。ゲートウエイプロセッサ
８０８が、販売者８０６からトランザクション明細を受信し、フォーマットし、アクワイ
アリング金融機関８１０に送信するよう構成されたエンティティであってよい。場合によ
っては、ゲートウエイプロセッサ８０８は、複数の販売者８０６及び複数のアクワイアリ
ング金融機関８１０に関連付けられてよい。そのような場合では、ゲートウエイプロセッ
サ８０８が、多様な販売者が関係する複数の異なるトランザクションのための支払明細を
受信し、適切なアクワイアリング金融機関８１０に転送してよい。複数のアクワイアリン
グ金融機関８１０と関係を有することによって、また支払レールを使用して金融機関と通
信するために必須なインフラストラクチャを有することによって、例えば、ゲートウエイ
プロセッサ８０８と関連付けられた、又はデータの提出、受信及び検索に使用される金融
機関と関連付けられたアプリケーションプログラムインターフェイスを使用することによ
って、ゲートウエイプロセッサ８０８は、販売者８０６のための仲介者としての機能を果
たし、ゲートウエイプロセッサ８０８との単一の通信チャネル及びフォーマットを介して
支払トランザクションを行なうことができる。その際、複数のアクワイアリング金融機関
８１０及び支払プロセッサ、並びにそれらと関連付けられたハードウエアとの関係を維持
する必要がない。アクワイアリング金融機関８１０は金融機関であってよい。金融機関は
、例えば銀行であってよく、又は支払アカウント、及び／又は支払アカウントと共に使用
する支払手段を、執行及び管理する他のエンティティであってよい。場合によっては、ア
クワイアリング金融機関８１０が、販売者８０６のためのトランザクションアカウントを
管理してよい。いくつかの場合では、単一の金融機関が、発行金融機関８０２及びアクワ
イアリング金融機関８１０の両方として働いてもよい。

販売者８０６からゲートウエイプロセッサ８０８に送信されたデータ信号に、支払トラ
ンザクションのためのトランザクション明細を重畳してよい。データ信号を、１つ以上の
標準に従ってフォーマットしてよい。いくつかの実施形態では、標準を、ゲートウエイプ
ロセッサ８０８によって定めてよい。標準が、トランザクションデータをゲートウエイプ
ロセッサ８０８に／ゲートウエイプロセッサ８０８から送信するために、固有の専用フォ
ーマットを使用してよい。他の実施形態では、国際標準化機構のISO8883標準等の、公的
標準を使用してよい。標準は、含まれ得るデータのタイプ、データのフォーマット、どの
ようにしてデータを格納し、送信するか、及びゲートウエイプロセッサ８０８にトランザ
クションデータを送信するための他の標準を示してよい。

ステップ８２８において、ゲートウエイプロセッサ８０８は、トランザクションデータ
信号を解析してよく、その上に重畳されたトランザクションデータを取得し、必要に応じ
てトランザクションデータをフォーマットしてよい。トランザクションデータのフォーマ
ットは、ゲートウエイプロセッサ８０８又は支払トランザクションと関連付けられたアク
ワイアリング金融機関８１０の専用標準に基づいて、ゲートウエイプロセッサ８０８が実
行してよい。専用標準は、トランザクションデータに含まれたデータのタイプ、及びデー
タの格納及び送信のためのフォーマットを明示してよい。アクワイアリング金融機関８１
０は、トランザクションデータを解析する（例えばデータ要素に分解する）等によって、
そこに含まれたアクワイアリング金融機関８１０に関連付けられた識別子を取得するため
に、トランザクションデータを使用して、ゲートウエイプロセッサ８０８によって識別さ
れてよい。場合によっては、ゲートウエイプロセッサ８０８は、次いで、アクワイアリン
グ金融機関８１０によって明示されたフォーマットの標準に準拠する等のために、識別さ
れたアクワイアリング金融機関８１０に基づいて、トランザクションデータをフォーマッ
トしてよい。いくつかの実施形態では、識別されたアクワイアリング金融機関８１０は、
支払トランザクションに関係する販売者８０６と関連付けられてよく、またいくつかの場
合では、販売者８０６と関連付けられたトランザクションアカウントを管理してもよい。

ステップ８３０において、ゲートウエイプロセッサ８０８は、フォーマット済みのトラ
ンザクションデータが重畳されたデータ信号を、識別されたアクワイアリング金融機関８
１０に電子送信してよい。アクワイアリング金融機関８１０は、データ信号を受信してよ
く、信号を解析してよく、その上に重畳されたフォーマット済みのトランザクションデー
タを取得してよい。ステップ８３２において、アクワイアリング金融機関は、フォーマッ
トされたトランザクションデータに基づいて、支払トランザクションのための許可依頼を
生成してよい。許可依頼は、ISO8883標準、及び支払ネットワーク等の、支払トランザク
ションを処理するために使用される支払プロセッサによって定められた標準等の、１つ以
上の標準に従ってフォーマットされる、特別にフォーマットされたトランザクションメッ
セージであってよい。許可依頼は、許可依頼を表示可能なメッセージタイプの標識を含む
トランザクションメッセージであってよい。許可依頼が、支払トランザクションに関係す
る販売者８０６が、トランザクションのために発行金融機関８０２からの支払又は支払約
束を要求していると示すことができる。許可依頼は、複数のデータ要素を含んでよい。各
データ要素を、アカウント番号、アプリケーション暗号、トランザクション額、発行金融
機関８０２情報等を格納する等のために、関連する標準に定められたデータを格納するよ
う構成する。

ステップ８３４において、アクワイアリング金融機関８１０は、許可依頼を、処理のた
めにトランザクション処理サーバ８１２に電子送信してよい。トランザクション処理サー
バ８１２は、１つ以上のコンピューティング装置を、支払トランザクションを処理するよ
う構成された支払ネットワークの一部として備えてよい。いくつかの実施形態では、許可
依頼を、アクワイアリング金融機関８１０における、又はアクワイアリング金融機関と関
連付けられた他のエンティティにおけるトランザクションプロセッサによって送信してよ
い。トランザクションプロセッサは、トランザクションメッセージ及び他のデータを、ト
ランザクション処理サーバ８１２へ送信し及びそこから送信するために、トランザクショ
ン処理サーバ８１２と通信する複数の通信チャネルを含む、１つ以上のコンピューティン
グ装置を含んでよい。いくつかの実施形態では、トランザクション処理サーバ８１２と関
連付けられた支払ネットワークは、各々のトランザクションプロセッサを、有してよく又
は作動させてよい。そのため支払ネットワークが、ネットワーク及び情報セキュリティの
ために、トランザクション処理サーバ８１２へ及びトランザクション処理サーバ８１２か
らの、トランザクションメッセージの通信に関する制御を維持することができる。

ステップ８３６において、トランザクション処理サーバ８１２は、支払トランザクショ
ンのために付加価値サービスを実行してよい。付加価値サービスが、発行金融機関８０２
によって明示されたサービスであってよく、発行金融機関８０２又は消費者８０４に、支
払トランザクションにおいて付加価値を提供してよい。付加価値サービスは、例えば、詐
欺スコアリング、トランザクション又はアカウントの管理、アカウント番号マッピング、
オファーの償還、ロイヤリティ処理等を含んでよい。例えば、トランザクション処理サー
バ８１２がトランザクションを受信すると、トランザクションのための詐欺スコアを、そ
こに含まれたデータ及び１つ以上の詐欺スコアリングアルゴリズム及び／又はエンジンに
基づいて計算することができる。場合によっては、トランザクション処理サーバ８１２は
、最初に、トランザクションと関連付けられた発行金融機関８０２を識別してよく、次い
で、発行金融機関８０２によって実行される任意のサービスを識別してよい。発行金融機
関８０２を、例えば、イシュア識別番号等の、許可依頼に含まれた特定のデータ要素に含
まれたデータ要素によって識別してよい。別の例では、発行金融機関８０２を、識別のた
めに、主要アカウント番号の部分（例えば銀行識別番号）を使用する等によって、許可依
頼に格納された主要アカウント番号によって識別してよい。

ステップ８３８において、トランザクション処理サーバ８１２は、許可依頼を発行金融
機関８０２に電子送信してよい。場合によっては、トランザクション処理サーバ８１２に
よる付加価値サービスの実行の結果として、許可依頼を変更してよく、又は許可依頼に伴
って追加データを含んでよく、又は送信してよい。いくつかの実施形態では、許可依頼を
発行金融機関８０２に位置する（例えばトランザクション処理サーバ８１２が有する又は
作動させる）トランザクションプロセッサに送信してよく、又は許可依頼をそれと関連付
けられたエンティティに送信してよく、当該エンティティが許可依頼を発行金融機関８０
２に転送してよい。

ステップ８４０において、発行金融機関８０２は、支払トランザクションの支払のため
に、トランザクションアカウントを許可してよい。許可は、トランザクションアカウント
のために利用可能なクレジット額、支払トランザクションのためのトランザクション額、
トランザクション処理サーバ８１２によって提供された詐欺スコア、及び当業者にとって
自明な他の考察に基づいてよい。発行金融機関８０２は、許可依頼を変更し、支払トラン
ザクションの承認（例えば、トランザクションが拒否されるべきかどうかを否定する）を
示す応答コード含んでよい。また発行金融機関８０２は、トランザクションメッセージの
ためのメッセージタイプの標識を変更し、トランザクションメッセージが許可応答へと変
えられたことを示すこともできる。ステップ８４２において、発行金融機関８０２は、許
可応答をトランザクション処理サーバ８１２に（例えばトランザクションプロセッサを介
して）送信してよい。

ステップ８４４において、トランザクション処理サーバ８１２は、許可応答をアクワイ
アリング金融機関８１０に（例えばトランザクションプロセッサを介して）転送してよい
。ステップ８４６において、アクワイアリング金融機関は、許可応答の応答コードに示さ
れたように、支払トランザクションの承認又は否定を示す応答メッセージを生成してよく
、ゲートウエイプロセッサ８０８によって定められた標準及びプロトコルを使用して、応
答メッセージをゲートウエイプロセッサ８０８に送信してよい。ステップ８４８において
、ゲートウエイプロセッサ８０８は、適切な標準及びプロトコルを使用して、応答メッセ
ージを販売者８０６に転送してよい。ステップ８８０において、トランザクションが承認
されたと仮定すると、販売者８０６は、次いで、消費者８０４によって購入された製品を
、支払トランザクションの一部として消費者８０４に提供してよい。

いくつかの実施形態では、プロセス８００が完了すると、発行金融機関８０２からアク
ワイアリング金融機関８１０への支払を実行してよい。いくつかの場合では、支払は、即
座に又は１営業日以内になされてよい。他の場合では、支払は、時間の経過後に、アクワ
イアリング金融機関８１０から発行金融機関８０２への清算依頼がトランザクション処理
サーバ８１２を介して提出されたことに応答して、なされてもよい。そのような場合では
、複数の支払トランザクションのための清算依頼を、単一の清算依頼へ集計してもよい。
トランザクション処理サーバ８１２は、単一の清算依頼を使用してよく、誰によって又誰
のために支払トランザクションの決済がなされるか、全体的な支払いを識別する。

場合によっては、またシステムは、通信パスが利用可能でない場合に、支払トランザク
ションの処理を実行するよう構成されてもよい。例えば、発行金融機関が（例えばステッ
プ８４０において）トランザクションアカウントの許可を実行できないと、トランザクシ
ョン処理サーバ８１２を、発行金融機関８０２に代わってトランザクションの許可を実行
するよう構成してよい。そのようなアクションは、トランザクション処理サーバが発行金
融機関８０２の代役を務める「スタンド‐イン処理」と称することができる。そのような
場合では、トランザクション処理サーバ８１２は、発行金融機関８０２によって定められ
たルールを利用して、支払トランザクションの承認又は否定を決定してよく、またステッ
プ８４４においてアクワイアリング金融機関８１０に転送するのに先立って、適宜にトラ
ンザクションメッセージを変更してよい。トランザクション処理サーバ８１２は、トラン
ザクション処理サーバ８１２が代役を務めるトランザクションに関連付けられたデータを
保持してよく、通信が再確立されると、保持したデータを発行金融機関８０２に送信して
よい。発行金融機関８０２は、次いで、トランザクションアカウントを適宜に処理してよ
く、失われた通信の時間に適応することができる。

別の例では、トランザクション処理サーバ８１２を、アクワイアリング金融機関８１０
による許可依頼の提出のために利用できないと、その場合、アクワイアリング金融機関８
１０におけるトランザクションプロセッサを、トランザクション処理サーバ８１２及び発
行金融機関８０２の処理を実行するよう構成してよい。トランザクションプロセッサは、
そこに含まれたデータに基づいて支払トランザクションの承認又は否定の決定を行なう際
に使用するのに適切な、ルール及びデータを含んでよい。例えば、発行金融機関８０２及
び／又はトランザクション処理サーバ８１２は、トランザクションタイプ、トランザクシ
ョン額等に対して制限を設けてよい。制限を、トランザクションプロセッサに格納し、そ
れに基づいて支払トランザクションの承認又は否定を決定するために使用してよい。その
ような場合では、アクワイアリング金融機関８１０は、トランザクション処理サーバ８１
２が利用不可能でも、支払トランザクションのための許可応答を受信することができ、確
実にトランザクションを処理し、通信が利用不可能な場合でさえも、ダウンタイムを経験
せずに済む。そのような場合では、トランザクションプロセッサは、支払トランザクショ
ンのためのトランザクション明細を格納してよい。通信が再確立されると、トランザクシ
ョン明細をトランザクション処理サーバ８１２に（例えば、またそこから関連する発行金
融機関８０２に）送信してよい。

いくつかの実施形態では、トランザクションプロセッサを、複数の異なる通信チャネル
を含むよう構成してよい。複数の異なる通信チャネルは、複数の通信カード及び／又はデ
バイスを利用してよく、トランザクションメッセージを送受信するために、トランザクシ
ョン処理サーバ８１２と通信してよい。例えば、トランザクションプロセッサは、複数の
コンピューティング装置を備えてよい。各コンピューティング装置は、トランザクション
処理サーバ８１２に接続される複数の通信ポートを有する。そのような実施形態では、ト
ランザクションプロセッサは、トランザクションメッセージをトランザクション処理サー
バ８１２に送信する際に、通信チャネルを循環して、ネットワーク輻輳を緩和し、より高
速でより円滑な通信を保証することができる。更に、通信チャネルが中断される又さもな
ければ利用不可能な場合、これによって代替的な通信チャネルを利用可能であり、それに
よってネットワークの稼働時間を更に増加させることができる。

いくつかの実施形態では、トランザクションプロセッサを、直接に他のトランザクショ
ンプロセッサと通信するよう構成してもよい。例えば、アクワイアリング金融機関８１０
におけるトランザクションプロセッサは、許可依頼が、付加価値サービスが依頼されない
発行金融機関８０２に関係することを（例えば、トランザクションメッセージに含まれた
銀行識別番号を介して）識別してよい。アクワイアリング金融機関８１０におけるトラン
ザクションプロセッサは、次いで、（例えば、許可依頼がトランザクション処理サーバ８
１２を通過せずに）許可依頼を直接に、発行金融機関８０２におけるトランザクションプ
ロセッサに送信してよい。発行金融機関８０２は、適宜にトランザクションを処理してよ
い。

上記で説明した、支払トランザクションの処理の方法は、複数の通信チャネルを使用す
る複数の通信方法を利用しており、プロセス内の複数のポイント及びシステム内の複数の
位置において、支払トランザクションの処理を提供するフェールセーフ、並びに中断の場
合でさえも通信が通信先に成功裡に到達することを保証する冗長性を含み、支払トランザ
クションが常に成功裡に処理され、エラーと中断を最小とする堅牢なシステムを提供する
ことができる。この先進的なネットワーク並びにそのインフラストラクチャ及びトポロジ
は、一般に「支払レール」と称することができる。支払レールでは、数百万の異なる販売
時点において、販売者からトランザクションデータが支払レールに提出され、インフラス
トラクチャを通って、適切なトランザクション処理サーバ８１２へ、処理のためにルーテ
ィングされてよい。支払レールは、汎用コンピューティング装置が、特別なプログラミン
グ及び／又は設定なしでは、通信を適切にフォーマットすることができず、レールに通信
を提出したりすることのできないようなものであってよい。コンピューティング装置は、
コンピューティング装置の特別な目的によって、この先進的なネットワークを使用して処
理するために、トランザクションデータを（例えば、ゲートウエイプロセッサ８０８、ア
クワイアリング金融機関８１０等の）適切なエンティティに提出し、消費者８０４が支払
トランザクションに資金を供給する能力に関する応答を迅速かつ効果的に受信するよう、
構成されてよい。

コンピュータシステムアーキテクチャ
図９は、例示的実施形態による、コンピュータシステムアーキテクチャのブロック図で
ある。

図９は、本開示の実施形態又はその一部が、コンピュータ可読コードとして実装されて
よいコンピュータシステム９００を示す。例えば、図１の第１コンピューティング装置１
０４及び第２コンピューティング装置１０６、並びに図２のコンピューティング装置２０
０は、ハードウエア、ソフトウエア、ファームウエア、そこに格納された命令を有する非
一時的なコンピュータ可読媒体、又はこれらの組み合わせを用いて実装されてよく、１つ
以上のコンピュータシステム又は他の処理システムにおいて実装されてよい。ハードウエ
ア、ソフトウエア、又それらの任意の組み合わせは、図３Ａ、３Ｂ、４、５Ａ、５Ｂ，及
び図６乃至８の方法を実行するためにモジュール及びコンポーネントを実現してよい。

プログラマブルロジックが使用されると、そのようなロジックは、（例えば、プログラ
マブルロジックアレイ、特定用途向け集積回路等である）特定の目的用途コンピュータ又
は専用デバイスとなるために実行可能なソフトウエアコードによって構成された、市販の
処理プラットフォーム上で実行されてよい。当業者は、開示された事項の実施形態が、多
様なコンピュータシステム構成で実行可能であることを理解する。当該コンピュータシス
テム構成は、マルチコアのマルチプロセッサシステム、ミニコンピュータ、メインフレー
ムコンピュータ、分散された機能でリンクされ又はクラスタ化されたコンピュータ、並び
に任意の装置へ事実上組み込まれ得る普及型又はミニチュアのコンピュータを含む。例え
ば、少なくとも１つのプロセッサ装置及びメモリは、上記に記載した実施形態を実装する
ために使用されてよい。

本開示で説明するプロセッサユニット又は装置は、単一のプロセッサ、複数のプロセッ
サ、又はそれらの組み合わせであってよい。プロセッサ装置は、１つ以上のプロセッサ「
コア」を有してよい。本開示で説明する「コンピュータプログラム媒体」、「非一時的な
コンピュータ可読媒体」、及び「コンピュータ使用可能媒体」との用語は、概して、取り
外し可能なストレージユニット９１８、取り外し可能なストレージユニット９２２、及び
ハードディスクドライブ９１２にインストールされたハードディスク等の、有形の媒体を
指すために使用される。

本開示の多様な実施形態は、この例示的なコンピュータシステム９００に関して記載さ
れる。この記載を読んだ後、当業者にとって、他のコンピュータシステム及び／又はコン
ピュータアーキテクチャを使用して本開示をどのように実装するかは自明である。作動は
、シーケンシャルな処理として記載されてよく、いくつかの作動は実際には、並行して、
同時に、及び／又は分散環境で、実行されてよい。このとき、プログラムコードは、単一
プロセッサ又はマルチプロセッサのマシンによってアクセスするために、ローカルに又は
リモートに格納された状態である。更に、いくつかの実施形態では、作動の順番は、開示
される事項の趣旨を逸脱することなく、再配置されてよい。

プロセッサ装置９０４は、本開示で説明する機能を実行するよう構成された、特定目的
の、又は汎用目的のプロセッサ装置であってよい。プロセッサ装置９０４は、例えばバス
、メッセージキュー、ネットワーク、マルチコアメッセージパススキーム等の、通信イン
フラストラクチャ９０６へ接続されてよい。ネットワークは、本開示の機能を実行するの
に適した任意のネットワークであってよく、ローカルエリアネットワーク（LAN）、ワイ
ドエリアネットワーク（WAN）、無線ネットワーク（例えばWifi）、モバイル通信ネット
ワーク、衛星ネットワーク、インターネット、光ファイバ、同軸ケーブル、赤外線、無線
周波数（RF）、又はこれらの任意の組合せを含んでよい。他の適切なネットワークタイプ
及び構成は、当業者にとって自明である。またコンピュータシステム９００は、（例えば
ランダムアクセスメモリ、読み取り専用メモリ等の）メインメモリ９０８を含んでよく、
また、補助メモリ９１０を含んでよい。補助メモリ９１０は、ハードディスクドライブ９
１２、及びフロッピーディスクドライブ、磁気テープドライブ、光ディスクドライブ、フ
ラッシュメモリ等の取外し可能なストレージドライブ９１４を含んでよい。

取り外し可能なストレージドライブ９１４は、周知の方法で、取り外し可能なストレー
ジユニット９１８から読み取ってよく、及び／又はそこへ書込みをしてもよい。取外し可
能なストレージユニット９１８は、取外し可能なストレージドライブ９１４によって読み
取られ又は書き込まれることができる、取外し可能なストレージ媒体を含んでよい。例え
ば、取外し可能なストレージドライブ９１４がフロッピーディスクドライブ又はユニバー
サルシリアルバスポートであれば、取外し可能なストレージユニット９１８はそれぞれ、
フロッピーディスク又はポータブルフラッシュドライブであってよい。一実施形態では、
取外し可能なストレージユニット９１８は非一時的な可読記録媒体であってよい。

いくつかの実施形態では、補助メモリ９１０は代替手段を含み、コンピュータプログラ
ム又は他の命令が、例えば取外し可能なストレージユニット９２２及びインタフェース９
２０である、コンピュータシステム９００にロードされることを可能にしてよい。そのよ
うな手段の例は、（例えばビデオゲームシステムで見られる）プログラムカートリッジ及
びカートリッジインタフェース、（例えばEEPROM、PROM等）取外し可能なメモリチップ、
関連ソケット、並びに他の取外し可能なストレージユニット９２２及びインタフェース９
２０を含んでよい。このことは当業者にとって自明である。

コンピュータシステム９００に（例えばメインメモリ９０８に及び／又は補助メモリ９
１０に）格納されたデータは、（例えば、コンパクトディスク、デジタル多目的ディスク
、Blu-rayディスク等）光ストレージのような、任意のタイプの適切なコンピュータ可読
媒体上、又は（例えばハードディスクドライブである）磁気テープストレージ上に格納さ
れてよい。データは、リレーショナルデータベース、構造化クエリ言語（SQL）データベ
ース、分散データベース、オブジェクトデータベース等の、任意のタイプの適切なデータ
ベース構成で構成されてよい。適切な構成及びストレージタイプは、当業者にとって自明
である。

またコンピュータシステム９００は、通信インタフェース９２４を含んでよい。通信イ
ンタフェース９２４が、ソフトウエア及びデータが、コンピュータシステム９００と外部
装置との間で送信されることを可能にしてよい。例示的な通信インタフェース９２４は、
モデム、ネットワークインタフェース（例えばイーサネットカード）、通信ポート、PCMC
IAスロット及びカード等を含んでよい。通信インタフェース９２４を介して転送されるソ
フトウエア及びデータは信号形式であってよい。当該信号形式は、電子の、電磁気の、光
の、又は当業者にとって自明な他の信号のものであってよい。信号は、通信パス９２６を
介して伝わってよい。当該通信パス９２６は信号を伝送するよう構成され、電線、ケーブ
ル、光ファイバ、電話線、携帯電話リンク、無線周波数リンク等を用いて実装されてよい
。

コンピュータシステム９００は更に、表示インタフェース９０２を含んでよい。表示イ
ンタフェース９０２が、データが、コンピュータシステム９００と外部のディスプレイ９
３０との間で転送されることを可能にするよう構成されてよい。例示的な表示インタフェ
ース９０２は、高精細度マルチメディアインタフェース（HDMI）、デジタルビジュアルイ
ンタフェース（DVI）、ビデオグラフィックスアレイ（VGA）等を含んでよい。ディスプレ
イ９３０は任意の適切なタイプのディスプレイであってよく、コンピュータシステム９０
０の表示インタフェース９０２を介して送信されるデータを表示する。ディスプレイ９３
０は、ブラウン管（CRT）ディスプレイ、液晶ディスプレイ（LCD）、発光ダイオード（LE
D）ディスプレイ、静電容量方式タッチディスプレイ、薄膜トランジスタ（TFT）ディスプ
レイ等を含む。

コンピュータプログラム媒体及びコンピュータ使用可能媒体は、メインメモリ９０８及
び補助メモリ９１０等、メモリを指してよく、（例えば、DRAM等）半導体メモリであって
よい。これらのコンピュータプログラム製品は、コンピュータシステム９００へソフトウ
エアを提供するための手段であってよい。コンピュータプログラム（例えばコンピュータ
制御ロジック）は、メインメモリ９０８及び／又は補助メモリ９１０に格納されてよい。
またコンピュータプログラムは、通信インタフェース９２４を介して受信されてよい。そ
のようなコンピュータプログラムは、実行されると、コンピュータシステム９００が本開
示で説明する方法を実行することを可能にしてよい。特に、コンピュータプログラムは、
実行されると、本開示で説明するように、プロセッサ装置９０４が、図３、４、５Ａ、５
Ｂ、６及び７に示す方法を実行することを可能にしてよい。従って、そのようなコンピュ
ータプログラムはコンピュータシステム９００のコントローラを示してよい。本開示はソ
フトウエアを使用して実装される。当該ソフトウエアは、取外し可能なストレージドライ
ブ９１４、インタフェース９２０、及びハードディスクドライブ９１２、又は通信インタ
フェース１９２４を用いて、コンピュータプログラム製品に格納されてコンピュータシス
テム９００へロードされてよい。

プロセッサ装置９０４は、コンピュータシステム９００の機能を実行するよう構成され
た１つ以上のモジュール又はエンジンを含んでよい。モジュール又はエンジンの各々は、
ハードウエアを使用して実装されてよい。場合によっては、モジュール又はエンジンの各
々が、メインメモリ９０８又は補助メモリ９１０に格納されたプログラムコード及び／又
はプログラムに対応するような、ソフトウエアを利用してもよい。そのような場合では、
プログラムコードは、コンピュータシステム９００のハードウエアによる実行に先立って
、プロセッサ装置９０４によって（例えば、コンパイリングモジュール又はエンジンによ
って）コンパイルされてよい。例えば、プログラムコードは、コンピュータシステム９０
０のプロセッサ装置９０４及び／又は任意の追加のハードウエアコンポーネントによる実
行のために、アセンブリ言語又はマシンコード等の、より低いレベルの言語に翻訳される
プログラミング言語で書かれたソースコードであってよい。コンパイリングのプロセスは
、語彙分析、前処理、解析、意味分析、構文主導型翻訳、コード生成、コード最適化の使
用、及びコンピュータシステム９００による本開示の機能の実行を制御するのに適する、
より低いレベルの言語へとプログラムコードを翻訳するのに適し得る、任意の他の技術の
使用を含んでよい。そのようなプロセスは、結果的にコンピュータシステム９００におい
て、上記に説明する機能を実行するために一意的にプログラムされた、特別に構成された
コンピュータシステム９００となることは、当業者にとって自明である。

本開示で一貫する技術は、他の特徴の中でも、ポイントツーポイント支払トランザクシ
ョンを処理するシステム及び方法を提供する。開示するシステム及び方法の多様な例示的
実施形態が上述されるが、それらは限定目的でなく、例示目的のみで記載されることを理
解されたい。それらは徹底したものでなく、本開示を、開示された形態そのものへ限定し
ない。上記の教示に照らして修正例及び変形例が可能である。広がり又は範囲を逸脱する
こと無く、本開示の実装から修正例及び変形例が得られてよい。

Claims (28)

1. ポイントツーポイント支払トランザクションを記録する方法であって、
   支払トランザクションに係る第１データメッセージを、処理サーバの受信装置によって
   受信するステップであって、前記第１データメッセージを、１つ以上の標準に従ってフォ
   ーマットし、１つ以上のアプリケーションプログラムインターフェイス（API）を使用し
   て受信し、前記第１データメッセージが、少なくとも、トランザクション明細を格納する
   よう構成された第１データ要素と、主要アカウント番号を格納するよう構成された第２デ
   ータ要素と、レシピエントアカウント番号を格納するよう構成された第３データ要素と、
   を含む少なくとも複数のデータ要素を含むステップと、
   前記第１、第２及び第３データ要素を、前記第１データメッセージに属する記録へのリ
   ンクと共に前記処理サーバの商用データベースに格納するステップであって、前記リンク
   が、前記第１データメッセージに基づいて文書へのアクセスを提供するステップと、
   前記支払トランザクションに係る第２データメッセージを、前記処理サーバの生成モジ
   ュールによって生成するステップであって、前記第２データメッセージを、１つ以上の標
   準に従ってフォーマットし、前記第２データメッセージが、支払額を格納するよう構成さ
   れた第１データ要素を含む少なくとも複数のデータ要素を含み、前記支払額が、少なくと
   も前記トランザクション明細に基づくステップと、
   前記第１データ要素を、前記第２データメッセージに属する記録へのリンクと共に前記
   処理サーバの前記商用データベースに格納するステップであって、前記リンクが、前記第
   ２データメッセージに基づいて文書へのアクセスを提供するステップと、
   前記第２データメッセージを、前記処理サーバの送信装置によって、前記主要アカウン
   ト番号に係るトランザクションアカウントと関連付けられた第１金融機関に電子送信する
   ステップと、
   前記支払トランザクションに係る第３データメッセージを、前記処理サーバの前記生成
   モジュールによって生成するステップであって、前記第３データメッセージを、１つ以上
   の標準に従ってフォーマットし、前記第３データメッセージが、決済額を格納するよう構
   成された第１データ要素と、前記レシピエントアカウント番号を格納するよう構成された
   第２データ要素と、を含む少なくとも複数のデータ要素を含み、前記決済額が、少なくと
   も前記トランザクション明細に基づくステップと、
   前記第１データ要素及び前記第２データ要素を、前記第３データメッセージに属する記
   録へのリンクと共に前記処理サーバの前記商用データベースに格納するステップであって
   、前記リンクが、前記第３データメッセージに基づいて文書へのアクセスを提供するステ
   ップと、
   前記第３データメッセージを、前記処理サーバの前記送信装置によって、前記レシピエ
   ントアカウント番号に係るトランザクションアカウントと関連付けられた第２金融機関に
   電子送信するステップと、
   前記第１データメッセージと、前記第２データメッセージと、前記第３データメッセー
   ジとを、前記処理サーバの前記送信装置によって、グラフィカルユーザインターフェイス
   （GUI）上に表示するために、電子送信するステップと、を含む方法。
2. 前記第１データメッセージ、第２データメッセージ、及び第３データメッセージを、IS
   O8583標準に従ってフォーマットする、請求項１に記載の方法。
3. 前記第１データメッセージをISO8583標準に従ってフォーマットし、
   前記第２データメッセージ及び前記第３データメッセージをISO20022標準に従ってフォ
   ーマットする、請求項１に記載の方法。
4. 前記第２データメッセージを生成するステップは、ISO8583標準とISO20022標準との間
   の対応に基づいて、前記第１データメッセージを前記第２データメッセージに変換するス
   テップを含む、請求項３に記載の方法。
5. トランザクション明細は、トランザクション額、注文日、履行日、及びステータスのう
   ちの１つ以上を含む、請求項１に記載の方法。
6. 前記決済額が前記トランザクション明細と同等である、請求項１に記載の方法。
7. 更に、前記支払トランザクションに係わる第４データメッセージを、前記処理サーバの
   生成モジュールによって生成するステップであって、前記第４データメッセージを標準に
   従ってフォーマットし、前記第４データメッセージが、少なくとも、前記トランザクショ
   ン明細を格納するよう構成された第１データ要素と、前記レシピエントアカウント番号を
   格納するよう構成された第２データ要素と、を含む複数のデータ要素を含むステップと、
   前記第４データメッセージを、前記処理サーバの送信装置によって電子送信するステッ
   プと、を含む、請求項１に記載の方法。
8. 前記第４データメッセージを前記第２金融機関に電子送信する、請求項７に記載の方法
   。
9. 前記第１データメッセージを第三者システムから受信し、また前記第４データメッセー
   ジを第三者システムに電子送信する、請求項７に記載の方法。
10. 前記第４データメッセージをISO8583標準に従ってフォーマットする、請求項７に記載
    の方法。
11. 前記処理サーバが、第１コンピューティング装置及び第２コンピューティング装置を含
    み、
    前記第１コンピューティング装置が前記受信装置を含み、
    前記第２コンピューティング装置が、前記生成モジュール、決定モジュール、及び前記
    送信装置を含む、請求項１に記載の方法。
12. 更に、少なくとも前記支払額が重畳されたデータ信号を、前記処理サーバの前記第１コ
    ンピューティング装置の生成モジュールによって生成するステップと、
    生成した前記データ信号を、前記処理サーバの前記第１コンピューティング装置の送信
    装置によって、前記第２コンピューティング装置に電子送信するステップと、
    前記データ信号を、前記処理サーバの前記第２コンピューティング装置の受信装置によ
    って受信するステップと、を含む、請求項１１に記載の方法。
13. 前記商用データベースに格納された前記データ要素が取引ディレクトリを備える、請求
    項１に記載の方法。
14. 前記商用データベースに格納された前記データ要素が元帳を備える、請求項１に記載の
    方法。
15. ポイントツーポイント支払トランザクションを記録するシステムであって、
    支払トランザクションに係る第１データメッセージを受信するよう構成された、処理サ
    ーバの受信装置であって、前記第１データメッセージが、１つ以上の標準に従ってフォー
    マットされ、１つ以上のアプリケーションプログラムインターフェイス（API）を使用し
    て受信され、また前記第１データメッセージが、少なくとも、トランザクション明細を格
    納するよう構成された第１データ要素と、主要アカウント番号を格納するよう構成された
    第２データ要素と、レシピエントアカウント番号を格納するよう構成された第３データ要
    素と、を含む少なくとも複数のデータ要素を含む受信装置と、
    前記第１、第２及び第３データ要素を、前記第１データメッセージに属する記録へのリ
    ンクと共に格納するよう構成された、前記処理サーバの商用データベースであって、前記
    リンクが、前記第１データメッセージに基づいて文書へのアクセスを提供する商用データ
    ベースと、
    前記支払トランザクションに係る第２データメッセージを生成するよう構成された、前
    記処理サーバの生成モジュールであって、前記第２データメッセージが、１つ以上の標準
    に従ってフォーマットされ、また支払額を格納するよう構成された第１データ要素を含む
    少なくとも複数のデータ要素を含み、前記支払額が、少なくとも前記トランザクション明
    細に基づく生成モジュールと、
    前記第１データ要素を、前記第２データメッセージに属する記録へのリンクと共に格納
    するよう構成された、前記処理サーバの前記商用データベースであって、前記リンクが、
    前記第２データメッセージに基づいて文書へのアクセスを提供する前記商用データベース
    と、
    前記第２データメッセージを、前記主要アカウント番号に係るトランザクションアカウ
    ントと関連付けられた第１金融機関に電子送信するよう構成された、前記処理サーバの送
    信装置と、
    前記支払トランザクションに係る第３データメッセージを生成するよう構成された、前
    記処理サーバの前記生成モジュールであって、前記第３データメッセージが、１つ以上の
    標準に従ってフォーマットされ、また決済額を格納するよう構成された第１データ要素と
    前記レシピエントアカウント番号を格納するよう構成された第２データ要素とを含む少な
    くとも複数のデータ要素を含み、前記決済額が、少なくとも前記トランザクション明細に
    基づく前記生成モジュールと、
    前記第１データ要素及び前記第２データ要素を、前記第３データメッセージに属する記
    録へのリンクと共に格納するよう構成された、前記処理サーバの前記商用データベースで
    あって、前記リンクが、前記第３データメッセージに基づいて文書へのアクセスを提供す
    る前記商用データベースと、
    前記処理サーバの前記送信装置であって、
    前記第３データメッセージを、前記レシピエントアカウント番号に係るトランザクショ
    ンアカウントと関連付けられた第２金融機関に送信するよう構成され、
    前記第１データメッセージと、前記第２データメッセージと、前記第３データメッセー
    ジとを、グラフィカルユーザインターフェイス（GUI）上に表示するために、送信するよ
    う構成された送信装置と、を含むシステム。
16. 前記第１データメッセージ、第２データメッセージ、及び第３データメッセージが、IS
    O8583標準に従ってフォーマットされる、請求項１５に記載のシステム。
17. 前記第１データメッセージがISO8583標準に従ってフォーマットされ、また前記第２デ
    ータメッセージ及び前記第３データメッセージがISO20022標準に従ってフォーマットされ
    る、請求項１５に記載のシステム。
18. 前記第２データメッセージの生成は、ISO8583標準とISO20022標準との間の対応に基づ
    く、前記第１データメッセージの前記第２データメッセージへの変換を含む、請求項１７
    に記載のシステム。
19. トランザクション明細は、トランザクション額、注文日、履行日、及びステータスのう
    ちの１つ以上を含む、請求項１５に記載のシステム。
20. 前記決済額が前記トランザクション明細と同等である、請求項１５に記載のシステム。
21. 更に、前記支払トランザクションに係わる第４データメッセージを生成するよう構成さ
    れた、前記処理サーバの生成モジュールであって、前記第４データメッセージが、標準に
    従ってフォーマットされ、少なくとも、前記トランザクション明細を格納するよう構成さ
    れた第１データ要素と、前記レシピエントアカウント番号を格納するよう構成された第２
    データ要素と、を含む複数のデータ要素を含む生成モジュールと、
    前記第４データメッセージを送信するよう構成された、前記処理サーバの前記送信装置
    と、を含む、請求項１５に記載のシステム。
22. 前記第４データメッセージが前記第２金融機関に電子送信される、請求項２１に記載の
    システム。
23. 前記第１データメッセージが第三者システムから受信され、また前記第４データメッセ
    ージが第三者システムに電子送信される、請求項２１に記載のシステム。
24. 前記第４データメッセージがISO8583標準に従ってフォーマットされる、請求項２１に
    記載のシステム。
25. 前記処理サーバが、第１コンピューティング装置及び第２コンピューティング装置を含
    み、
    前記第１コンピューティング装置が前記受信装置を含み、
    前記第２コンピューティング装置が、前記生成モジュール、決定モジュール、及び前記
    送信装置を含む、請求項１５に記載のシステム。
26. 更に、少なくとも前記支払額が重畳されたデータ信号を生成するよう構成された、前記
    処理サーバの前記第１コンピューティング装置の生成モジュールと、
    生成された前記データ信号を前記第２コンピューティング装置に送信するよう構成され
    た、前記処理サーバの前記第１コンピューティング装置の送信装置と、
    前記データ信号を受信するよう構成された、前記処理サーバの前記第２コンピューティ
    ング装置の受信装置と、を含む、請求項２５に記載のシステム。
27. 前記商用データベースに格納された前記データ要素が取引ディレクトリを備える、請求
    項１５に記載のシステム。
28. 前記商用データベースに格納された前記データ要素が元帳を備える、請求項１５に記載
    のシステム。