(57)【要約】ポイントツーポイント支払トランザクションを処理する方法は次のステップを含む。すなわち、支払トランザクションに係わる第１データメッセージを受信するステップ、第１、第２及び第３データ要素を、第１データメッセージに属する記録へのリンクと共に格納するステップ、支払トランザクションに係わる第２データメッセージを生成するステップ、第１データ要素を、第２データメッセージに属する記録へのリンクと共に格納するステップ、支払トランザクションに係わる第３データメッセージを生成するステップ、第１データ要素及び第２データ要素を、第３データメッセージに属する記録へのリンクと共に格納するステップ、第１データメッセージと、第２データメッセージと、第３データメッセージと、を、グラフィカルユーザインターフェイス（GUI）上に表示するために送信するステップ、である。
2019512808.tif 000002
【特許請求の範囲】
【請求項１】
ポイントツーポイント支払トランザクションを記録する方法であって、
支払トランザクションに係る第１データメッセージを、処理サーバの受信装置によって受信するステップであって、前記第１データメッセージを、１つ以上の標準に従ってフォーマットし、１つ以上のアプリケーションプログラムインターフェイス（API）を使用して受信し、前記第１データメッセージが、少なくとも、トランザクション明細を格納するよう構成された第１データ要素と、主要アカウント番号を格納するよう構成された第２データ要素と、レシピエントアカウント番号を格納するよう構成された第３データ要素と、を含む少なくとも複数のデータ要素を含むステップと、
前記第１、第２及び第３データ要素を、前記第１データメッセージに属する記録へのリンクと共に前記処理サーバの商用データベースに格納するステップであって、前記リンクが、前記第１データメッセージに基づいて文書へのアクセスを提供するステップと、
前記支払トランザクションに係る第２データメッセージを、前記処理サーバの生成モジュールによって生成するステップであって、前記第２データメッセージを、１つ以上の標準に従ってフォーマットし、前記第２データメッセージが、支払額を格納するよう構成された第１データ要素を含む少なくとも複数のデータ要素を含み、前記支払額が、少なくとも前記トランザクション明細に基づくステップと、
前記第１データ要素を、前記第２データメッセージに属する記録へのリンクと共に前記処理サーバの前記商用データベースに格納するステップであって、前記リンクが、前記第２データメッセージに基づいて文書へのアクセスを提供するステップと、
前記第２データメッセージを、前記処理サーバの送信装置によって、前記主要アカウント番号に係るトランザクションアカウントと関連付けられた第１金融機関に電子送信するステップと、
前記支払トランザクションに係る第３データメッセージを、前記処理サーバの前記生成モジュールによって生成するステップであって、前記第３データメッセージを、１つ以上の標準に従ってフォーマットし、前記第３データメッセージが、決済額を格納するよう構成された第１データ要素と、前記レシピエントアカウント番号を格納するよう構成された第２データ要素と、を含む少なくとも複数のデータ要素を含み、前記決済額が、少なくとも前記トランザクション明細に基づくステップと、
前記第１データ要素及び前記第２データ要素を、前記第３データメッセージに属する記録へのリンクと共に前記処理サーバの前記商用データベースに格納するステップであって、前記リンクが、前記第３データメッセージに基づいて文書へのアクセスを提供するステップと、
前記第３データメッセージを、前記処理サーバの前記送信装置によって、前記レシピエントアカウント番号に係るトランザクションアカウントと関連付けられた第２金融機関に電子送信するステップと、
前記第１データメッセージと、前記第２データメッセージと、前記第３データメッセージとを、前記処理サーバの前記送信装置によって、グラフィカルユーザインターフェイス（GUI）上に表示するために、電子送信するステップと、を含む方法。
【請求項２】
前記第１データメッセージ、第２データメッセージ、及び第３データメッセージを、ISO8583標準に従ってフォーマットする、請求項１に記載の方法。
【請求項３】
前記第１データメッセージをISO8583標準に従ってフォーマットし、
前記第２データメッセージ及び前記第３データメッセージをISO20022標準に従ってフォーマットする、請求項１に記載の方法。
【請求項４】
前記第２データメッセージを生成するステップは、ISO8583標準とISO20022標準との間の対応に基づいて、前記第１データメッセージを前記第２データメッセージに変換するステップを含む、請求項３に記載の方法。
【請求項５】
トランザクション明細は、トランザクション額、注文日、履行日、及びステータスのうちの１つ以上を含む、請求項１に記載の方法。
【請求項６】
前記決済額が前記トランザクション明細と同等である、請求項１に記載の方法。
【請求項７】
更に、前記支払トランザクションに係わる第４データメッセージを、前記処理サーバの生成モジュールによって生成するステップであって、前記第４データメッセージを標準に従ってフォーマットし、前記第４データメッセージが、少なくとも、前記トランザクション明細を格納するよう構成された第１データ要素と、前記レシピエントアカウント番号を格納するよう構成された第２データ要素と、を含む複数のデータ要素を含むステップと、
前記第４データメッセージを、前記処理サーバの送信装置によって電子送信するステップと、を含む、請求項１に記載の方法。
【請求項８】
前記第４データメッセージを前記第２金融機関に電子送信する、請求項７に記載の方法。
【請求項９】
前記第１データメッセージを第三者システムから受信し、また前記第４データメッセージを第三者システムに電子送信する、請求項７に記載の方法。
【請求項１０】
前記第４データメッセージをISO8583標準に従ってフォーマットする、請求項７に記載の方法。
【請求項１１】
前記処理サーバが、第１コンピューティング装置及び第２コンピューティング装置を含み、
前記第１コンピューティング装置が前記受信装置を含み、
前記第２コンピューティング装置が、前記生成モジュール、決定モジュール、及び前記送信装置を含む、請求項１に記載の方法。
【請求項１２】
更に、少なくとも前記支払額が重畳されたデータ信号を、前記処理サーバの前記第１コンピューティング装置の生成モジュールによって生成するステップと、
生成した前記データ信号を、前記処理サーバの前記第１コンピューティング装置の送信装置によって、前記第２コンピューティング装置に電子送信するステップと、
前記データ信号を、前記処理サーバの前記第２コンピューティング装置の受信装置によって受信するステップと、を含む、請求項１１に記載の方法。
【請求項１３】
前記商用データベースに格納された前記データ要素が取引ディレクトリを備える、請求項１に記載の方法。
【請求項１４】
前記商用データベースに格納された前記データ要素が元帳を備える、請求項１に記載の方法。
【請求項１５】
ポイントツーポイント支払トランザクションを記録するシステムであって、
支払トランザクションに係る第１データメッセージを受信するよう構成された、処理サーバの受信装置であって、前記第１データメッセージが、１つ以上の標準に従ってフォーマットされ、１つ以上のアプリケーションプログラムインターフェイス（API）を使用して受信され、また前記第１データメッセージが、少なくとも、トランザクション明細を格納するよう構成された第１データ要素と、主要アカウント番号を格納するよう構成された第２データ要素と、レシピエントアカウント番号を格納するよう構成された第３データ要素と、を含む少なくとも複数のデータ要素を含む受信装置と、
前記第１、第２及び第３データ要素を、前記第１データメッセージに属する記録へのリンクと共に格納するよう構成された、前記処理サーバの商用データベースであって、前記リンクが、前記第１データメッセージに基づいて文書へのアクセスを提供する商用データベースと、
前記支払トランザクションに係る第２データメッセージを生成するよう構成された、前記処理サーバの生成モジュールであって、前記第２データメッセージが、１つ以上の標準に従ってフォーマットされ、また支払額を格納するよう構成された第１データ要素を含む少なくとも複数のデータ要素を含み、前記支払額が、少なくとも前記トランザクション明細に基づく生成モジュールと、
前記第１データ要素を、前記第２データメッセージに属する記録へのリンクと共に格納するよう構成された、前記処理サーバの前記商用データベースであって、前記リンクが、前記第２データメッセージに基づいて文書へのアクセスを提供する前記商用データベースと、
前記第２データメッセージを、前記主要アカウント番号に係るトランザクションアカウントと関連付けられた第１金融機関に電子送信するよう構成された、前記処理サーバの送信装置と、
前記支払トランザクションに係る第３データメッセージを生成するよう構成された、前記処理サーバの前記生成モジュールであって、前記第３データメッセージが、１つ以上の標準に従ってフォーマットされ、また決済額を格納するよう構成された第１データ要素と前記レシピエントアカウント番号を格納するよう構成された第２データ要素とを含む少なくとも複数のデータ要素を含み、前記決済額が、少なくとも前記トランザクション明細に基づく前記生成モジュールと、
前記第１データ要素及び前記第２データ要素を、前記第３データメッセージに属する記録へのリンクと共に格納するよう構成された、前記処理サーバの前記商用データベースであって、前記リンクが、前記第３データメッセージに基づいて文書へのアクセスを提供する前記商用データベースと、
前記処理サーバの前記送信装置であって、
前記第３データメッセージを、前記レシピエントアカウント番号に係るトランザクションアカウントと関連付けられた第２金融機関に送信するよう構成され、
前記第１データメッセージと、前記第２データメッセージと、前記第３データメッセージとを、グラフィカルユーザインターフェイス（GUI）上に表示するために、送信するよう構成された送信装置と、を含むシステム。
【請求項１６】
前記第１データメッセージ、第２データメッセージ、及び第３データメッセージが、ISO8583標準に従ってフォーマットされる、請求項１５に記載のシステム。
【請求項１７】
前記第１データメッセージがISO8583標準に従ってフォーマットされ、また前記第２データメッセージ及び前記第３データメッセージがISO20022標準に従ってフォーマットされる、請求項１５に記載のシステム。
【請求項１８】
前記第２データメッセージの生成は、ISO8583標準とISO20022標準との間の対応に基づく、前記第１データメッセージの前記第２データメッセージへの変換を含む、請求項１７に記載のシステム。
【請求項１９】
トランザクション明細は、トランザクション額、注文日、履行日、及びステータスのうちの１つ以上を含む、請求項１５に記載のシステム。
【請求項２０】
前記決済額が前記トランザクション明細と同等である、請求項１５に記載のシステム。
【請求項２１】
更に、前記支払トランザクションに係わる第４データメッセージを生成するよう構成された、前記処理サーバの生成モジュールであって、前記第４データメッセージが、標準に従ってフォーマットされ、少なくとも、前記トランザクション明細を格納するよう構成された第１データ要素と、前記レシピエントアカウント番号を格納するよう構成された第２データ要素と、を含む複数のデータ要素を含む生成モジュールと、
前記第４データメッセージを送信するよう構成された、前記処理サーバの前記送信装置と、を含む、請求項１５に記載のシステム。
【請求項２２】
前記第４データメッセージが前記第２金融機関に電子送信される、請求項２１に記載のシステム。
【請求項２３】
前記第１データメッセージが第三者システムから受信され、また前記第４データメッセージが第三者システムに電子送信される、請求項２１に記載のシステム。
【請求項２４】
前記第４データメッセージがISO8583標準に従ってフォーマットされる、請求項２１に記載のシステム。
【請求項２５】
前記処理サーバが、第１コンピューティング装置及び第２コンピューティング装置を含み、
前記第１コンピューティング装置が前記受信装置を含み、
前記第２コンピューティング装置が、前記生成モジュール、決定モジュール、及び前記送信装置を含む、請求項１５に記載のシステム。
【請求項２６】
更に、少なくとも前記支払額が重畳されたデータ信号を生成するよう構成された、前記処理サーバの前記第１コンピューティング装置の生成モジュールと、
生成された前記データ信号を前記第２コンピューティング装置に送信するよう構成された、前記処理サーバの前記第１コンピューティング装置の送信装置と、
前記データ信号を受信するよう構成された、前記処理サーバの前記第２コンピューティング装置の受信装置と、を含む、請求項２５に記載のシステム。
【請求項２７】
前記商用データベースに格納された前記データ要素が取引ディレクトリを備える、請求項１５に記載のシステム。
【請求項２８】
前記商用データベースに格納された前記データ要素が元帳を備える、請求項１５に記載のシステム。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本願は、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,000USDに等しい額の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標準を使用して実行される全ての通信のように、単一の標準を使用してよい。他の実施形態では、複数の標準を使用してもよい。例えば、センダネットワーク１１２及び／又はセンダシステム１０８から受信される送金依頼、並びにレシピエントネットワーク１１８及び／又はレシピエントシステム１１０に送信される決済予告は、ISO8583標準に従ってフォーマットされてよい。一方、センダ機関１１４に送信される資金供給依頼及びレシピエント機関１１６に送信される決済予告は、ISO20022標準に従ってフォーマットされてよい。そのような実施形態のいくつかでは、処理システム１０２の機能は、それと関連する標準に基づいて、異なるコンピューティング装置によって実行されてよい。例えば、第１コンピューティング装置１０４は、ISO8583標準に従ってフォーマットされた通信を、受信、生成及び送信するよう構成されてよい。一方、第２コンピューティング装置１０６は、ISO20022標準に従ってフォーマットされた通信を、受信、生成及び送信するよう構成されてよい。
【００４８】
標準に従ってフォーマットされたデータメッセージは、関連する標準に定められたようなデータを格納するよう構成されたデータ要素を含んでよい。例えば、標準は、標準に従ってフォーマットされたデータメッセージに含まれ得るデータ要素、及びそこに格納され得るデータを示してよい。場合によっては、異なる標準に従ってフォーマットされたデータメッセージが同一のデータを含んでよい。そのデータは異なるデータ要素に含まれる。例えば、ISO8583標準に従ってフォーマットされた送金依頼は、主要アカウント番号及びトランザクション額を格納するよう構成されたデータ要素を含んでよい。一方、ISO20022に従ってフォーマットされた対応する資金供給依頼も、主要アカウント番号及びトランザクション額を格納するよう構成されたデータ要素を含んでよい。全体として、データメッセージ内の異なるデータ要素に含まれる各データを有し、また異なってフォーマットされる各データメッセージに格納されるデータを有するのである。
【００４９】
複数の標準が使用されてよい実施形態では、それに含まれる処理システム１０２及び／又はコンピューティング装置は、データ信号及び／又はその上に重畳された又さもなければエンコードされたデータメッセージを、１つの標準から他の標準に変換するよう構成されてよい。例えば、第１コンピューティング装置１０４は、第２コンピューティング装置１０６への配信に先立って、送金依頼をISO8583標準からISO20022標準へ変換するよう構成されてよい。そのような例では、送金依頼のISO20022標準への変換が、送金依頼を、センダ機関１１４へ送信するための資金供給依頼に変換するものであってよい。いくつかの実施形態では、変換は、第三者エンティティによって実行されてよい。例えば、処理システム１０２は、第１標準に従ってフォーマットされたデータメッセージが重畳された又さもなければエンコードされたデータ信号を第三者エンティティに電子送信してよく、第三者エンティティから、第２標準に従ってフォーマットされたデータメッセージが重畳された又さもなければエンコードされたデータ信号を戻り受信してよい。処理システム１０２が複数のコンピューティングを備えてよい場合には、第１コンピューティング装置１０４は、データ信号を第三者エンティティに電子送信してよい。一方、第２コンピューティング装置１０６は、第三者エンティティによって電子送信されるデータ信号を受信してよい。
【００５０】
本開示で説明する処理システム１０２によって実行される通信は、任意の適切な通信ネットワーク、関連するプロトコル、及び通信方法を使用してよい。適切な通信ネットワークは、例えば、支払ネットワーク及び関連する支払レール、ローカルエリアネットワーク、無線エリアネットワーク、無線周波数ネットワーク、セルラ通信ネットワーク、インターネット等を含んでよい。場合によっては、処理システム１０２が、支払トランザクションの処理を実行するよう構成された支払ネットワークの一部であってよい。その場合、本開示で説明する１つ以上の通信が、関連する支払レールを使用して実行されてよい。例えば、センダ機関１１４及びレシピエント機関１１６に送信されるデータ信号、及び／又はセンダ機関１１４及びレシピエント機関１１６から送信されるデータ信号は、支払ネットワークと関連付けられた支払レールを使用して実行されてよい。場合によっては、複数の通信ネットワークが使用されてよい。例えば、処理システム１０２は、センダ機関１１４、レシピエント機関１１６、センダネットワーク１１２、及びレシピエントネットワーク１１８と、支払ネットワークと関連付けられた支払レールを使用して通信してよいが、インターネットを使用してセンダシステム１０８及びレシピエントシステム１１０と通信してもよい。特別にフォーマットされたトランザクションメッセージを、支払ネットワークと関連付けられた支払レールを使用して送信すること、及びそれに基づいて支払トランザクションを従来のように処理することについては、図８に示すプロセス８００に関して、以下に詳説する。
【００５１】
いくつかの実施形態では、処理システム１０２は、主要アカウント番号及び／又はレシピエントアカウント番号のマッピングを実行するよう構成されてよい。例えば、場合によっては、センダシステム１０８又はレシピエントシステム１１０は、各々、資金を送る又は受領するために、代替的な支払手段を使用してよい。そのような場合では、主要アカウント番号又はレシピエントアカウント番号は、支払手段と関連付けられ、適用可能であれば、資金を送る又は受領するために使用されるトランザクションアカウントに直接には関連付けられない可能性がある。処理システム１０２は、主要アカウント番号又はレシピエントアカウント番号を、それらに対してマップされた代替的な番号に置き換えるよう構成されてよい。代替的な番号は、関連するトランザクションアカウントに直接に対応する。例えば、センディングエンティティは、レシピエントエンティティの銀行口座に資金を送金するために、クレジットカードを使用してよい。そのような例では、処理システム１０２は、送金依頼に含まれたクレジットカード番号を、センダ機関１１４に資金供給依頼を提供するのに先立って、基礎となるトランザクションアカウントのためのアカウント番号と交換してよい。そのような実施形態では、処理システム１０２が、マッピングの際に使用するアカウント番号間の関連を格納する際に使用するのに適する、１つ以上のデータベースを格納してよい。
【００５２】
コンピューティング装置
図２は、例示的実施形態による、ポイントツーポイントランザクションを記録、処理、及び表示する図１のシステム１００に示す処理システム１０２の、第１コンピューティング装置１０４又は第２コンピューティング装置１０６のようなコンピューティング装置２００の、ブロック図である。当業者にとって、図２に示すコンピューティング装置２００の実施形態が、例示的目的のみで提供されることと、本開示の機能を実行するのに適するコンピューティング装置２００の全ての可能な構成を徹底して示したものでないことは、自明である。例えば、図９に示し下記で詳述するコンピュータシステム９００を、コンピューティング装置２００の適切な構成としてよい。
【００５３】
コンピューティング装置２００は受信装置２０２を含んでよい。受信装置２０２が、１つ以上のネットワーク上で、１つ以上のネットワークプロトコルを介してデータを受信するよう構成されてよい。いくつかの実施形態では、受信装置２０２は、極秘金融データ及び情報を含むトランザクションメッセージを送信するために、支払ネットワークと関連付けられたインフラストラクチャであって、特別に構成されたインフラストラクチャを使用する等、支払レール上でデータを受信するよう構成されてよい。場合によっては、また受信装置２０２は、センダシステム１０８、センダネットワーク１１２、センダ機関１１４、他のコンピューティング装置、レシピエントシステム１１０、レシピエントネットワーク１１８、レシピエント機関１１６、及びインターネットのような代替的なネットワークを介する他のエンティティから、データを受信するよう構成されてもよい。いくつかの実施形態では、受信装置２０２は、異なるネットワーク上でデータを受信する異なる受信装置のような、複数の装置を備えてよい。例えば、支払レール上でデータを受信する第１受信装置、及びインターネット上でデータを受信する第２受信装置等である。受信装置２０２は、電子送信されるデータ信号を受信してよい。その場合データは、データ信号上に重畳されてよく又さもなければエンコードされてよい。またデータは、受信装置２０２によるデータ信号の受信を介して、デコードされ、解析され、読み込まれ、又さもなければ取得されてよい。場合によっては、受信装置２０２は、データ信号上に重畳されたデータを取得するために、受信したデータ信号を解析する解析モジュールを含んでよい。例えば、受信装置２０２は、データ信号を受信し、受信したデータ信号を、処理装置によって実行される機能のために使用可能な入力へ変換するよう構成された解析プログラムを含んでよく、本開示で記載する方法及びシステムを実行してよい。
【００５４】
受信装置２０２は、センダシステム１０８、センダネットワーク１１２、及び／又はセンダ機関１１４によって電子送信されるデータ信号を受信するよう構成されてよい。データ信号は、送金依頼が重畳される又さもなければエンコードされる。送金依頼は、主要アカウント番号、トランザクション額、及びレシピエントアカウント番号を含んでよい。場合によっては、送金依頼が、ISO8583又はISO20022標準等、１つ以上の標準に従ってフォーマットされてよい。場合によっては、送金依頼が、処理システム１０２において、第１コンピューティング装置１０４の受信装置２０２によってのみ受信されてよい。また受信装置２０２が、他のコンピューティング装置２００よって電子送信されるデータ信号を受信するよう構成されてもよい。例えば、第２コンピューティング装置１０６の受信装置２０２は、資金供給依頼を生成する際に使用する集計された送金依頼のために、第１コンピューティング装置１０４によって電子送信されるデータ信号を受信してよい。また受信装置２０２は、従来の方法及びシステムを使用して、金銭移転を介して通貨を受領するよう構成されてもよい。いくつかの実施形態では、受信装置２０２は更に、第三者エンティティから電子送信されるデータ信号を受信するよう構成されてよい。データ信号は、変換されたデータメッセージが重畳されてよく又さもなければエンコードされてよい。
【００５５】
また受信装置２０２は、センダネットワーク１１２、レシピエントネットワーク１１８、支払ネットワーク、又は支払トランザクションの処理に係わる他のエンティティ等から、支払トランザクションに係わるトランザクションメッセージを受信するよう構成されてよい。トランザクションメッセージが、１つ以上の標準に従ってフォーマットされ、１つ以上のアプリケーションプログラムインターフェイス（API）を使用して受信されてよい。各トランザクションメッセージは、少なくとも複数のデータ要素を含んでよい。複数のデータ要素は、トランザクション明細を格納するよう構成された第１データ要素、主要アカウント番号を格納するよう構成された第２データ要素、及びレシピエントアカウント番号を格納するよう構成された第３データ要素である。場合によっては、また受信装置２０２は、支払トランザクションに係る追加のデータメッセージを受信してもよい。追加のデータメッセージは、発注書、請求書等の、トランザクション通信に係わるデータを含んでよい。場合によっては、受信装置２０２によって受信されるデータメッセージは、多様なデータフォーマッティング標準を使用してフォーマットされてよく、受信装置２０２、又は他のモジュール、又はAPIを介するようなコンピューティング装置２００のエンジンによって受信されると、再フォーマットされてよい。
【００５６】
またコンピューティング装置２００は、通信モジュール２０４を含んでもよい。通信モジュール２０４が、モジュール、エンジン、データベース、メモリ、及び本開示で説明する機能を実行する際に使用するコンピューティング装置２００の他のコンポーネントの間で、データを送信するよう構成されてよい。通信モジュール２０４が、１つ以上の通信タイプを備え、コンピュータ装置内部で通信するための多様な通信方法を利用してよい。例えば、通信モジュール２０４は、バス、コンタクトピンコネクタ、ワイヤ等を備えてよい。いくつかの実施形態では、また通信モジュール２０４は、コンピューティング装置２００の内部コンポーネントと、外部接続されたデータベース、ディスプレイ装置、入力装置等のようなコンピューティング装置２００の外部コンポーネントとの間で、通信するよう構成されてもよい。処理装置は、本開示で説明するコンピューティング装置２００の機能を実行するよう構成されてよいことは、当業者にとって自明である。いくつかの実施形態では、処理装置は、複数のエンジン、及び／又は処理装置の１つ以上の機能を実行するよう特別に構成された複数のモジュールを含んでよい、及び／又はそれらから構成されてよい。それらは、クエリモジュール２１０、生成モジュール２１２、決定モジュール２１４等である。本開示で使用されるように、用語「モジュール」は、入力を受信し、その入力を使用して１つ以上の処理を実行し、出力を提供するよう特別にプログラムされたソフトウエア又はハードウエアであってよい。多様なモジュールによって実行される入力、出力、及びプロセスは、本開示に基づき、当業者にとって自明である。
【００５７】
コンピューティング装置２００は、アカウントデータベース２０６を含んでよい。アカウントデータベース２０６が、適切なデータ格納フォーマット及びスキームを使用して、複数のアカウントプロファイル２０８を格納するよう構成されてよい。アカウントデータベース２０６は、そこに格納される構造化データセットの格納、識別、修正、更新、アクセス等のために、構造化クエリ言語を利用するリレーショナルデータベースであってよい。各アカウントプロファイル２０８は、１つ以上のトランザクションアカウントに係るデータを格納するよう構成された構造化データセットであってよい。いくつかの実施形態では、各アカウントプロファイル２０８は、センディングエンティティ又はレシピエントエンティティに対応するような、単一のトランザクションアカウントと関連付けられてよい。そのような実施形態では、アカウントプロファイル２０８は、関連するセンダ機関又はレシピエント機関１１６を識別する際に使用するのに適するデータ、又は代替的な支払手段が使用されてよい場合のように適用可能であれば、アカウント番号をアカウント番号のマッピングのために交換する際に使用するのに適するデータを含んでよい。他の実施形態では、各アカウントプロファイル２０８は、センダ機関１１４又はレシピエント機関１１６と関連付けられてよい。そのような実施形態では、アカウントプロファイル２０８が、送金依頼の集計で使用される、アカウントプロファイル２０８と関連付けられたデータを含んでよい。このデータは、集計された支払及び決済額、関連する識別値（例えば、アカウントプロファイル２０８との関連のために送金依頼を識別する際に使用される）、及び本開示で説明する機能を実行するために適する他のデータ等である。
【００５８】
いくつかの実施形態では、各アカウントプロファイル２０８は更に、係わるエンティティ（例えば支払人、受取先、バイヤ、サプライヤ等）と関連付けられた情報を含んでよい。各アカウントプロファイル２０８は、例えば、エンティティ情報、コーポレイトアイデンティティデータ、エンティティ内でバンキングトランザクション及び金融トランザクションに関する権限を有する個人と関連付けられたデータ、及び／又は実際の銀行口座情報等を格納することができる。またアカウントプロファイル２０８は、トランザクションメッセージの第１、第２、及び第３データ要素、又は係わるエンティティと関連付けられ、トランザクション又はデータメッセージに属する記録へのリンクを有する他のデータメッセージを含んでもよい。リンクは、第１トランザクションメッセージに基づいて文書へのアクセスを提供することができる。例えば、発注書に係わるデータメッセージ又はそこから解析されるデータは、アカウントプロファイル２０８に格納されてよい。またアカウントプロファイル２０８は、係わる発注書へのリンク（例えば、対応するAPIを介するセンダネットワーク１１２又はレシピエントネットワーク１１８のような、外部エンティティを介してアクセス可能なリンク）を含んでもよい。いくつかの場合では、データメッセージ自体がアカウントプロファイル２０８に格納されてよい。他の場合では、アカウントプロファイル２０８は、データメッセージから解析されるトランザクションデータを含んでよい。トランザクションデータは、センダエンティティ及びレシピエントエンティティ識別情報、トランザクション額、提出データ等である。またアカウントプロファイル２０８は、鍵情報を収集するために、APIの使用に関係する支払トランザクションに係わる、任意の数の追加的なトランザクション明細を格納してもよい。アカウントプロファイル２０８に格納されるリンクは、オリジナルの請求書、発注書、及び／又はトランザクションに係わる任意の他の通信へのアクセスを提供することができる。
【００５９】
コンピューティング装置２００は、クエリモジュール２１０を含んでよい。クエリモジュール２１０が、情報を識別するために、データベース上でクエリを実行するよう構成されてよい。クエリモジュール２１０は、１つ以上のデータ値又はクエリストリングを受信し、そこに格納された情報を識別するために、アカウントデータベース２０６のような指定されたデータベース上で、それに基づいてクエリストリングを実行してよい。クエリモジュール２１０は、次いで、識別された情報をコンピューティング装置２００の適切なエンジン又はモジュールに、必要に応じて出力してよい。クエリモジュール２１０は、（例えば、受信装置２０２によって受信される）送金依頼と関連付けられたアカウントプロファイルを識別するために、銀行識別番号、イシュア識別番号、又は（例えば、関連する標準に定められたような）対応するデータ要素に格納された主要アカウント番号及び／又はレシピエントアカウント番号に含まれた他の識別値に基づいて、集計を実行する際又は通信をそれに送信する際に使用する等のために、アカウントデータベース２０６上でクエリを実行してよい。
【００６０】
またコンピューティング装置２００は、生成モジュール２１２を含んでよい。生成モジュール２１２が、本開示で説明する機能を実行する際に処理システム１０２が使用するのに適するデータメッセージを生成するよう構成されてよい。生成モジュール２１２は、入力としてのデータメッセージの生成のための命令、及びそれと共に使用するのに適するデータを受信してよく、依頼されたデータメッセージを生成してよく、生成したデータメッセージを、コンピューティング装置２００の別のモジュール又はエンジンに出力してよい。生成モジュール２１２は、資金供給依頼を生成するよう構成されてよい。資金供給依頼は、少なくとも、主要アカウント番号及び関連する支払額を含んでよい。場合によっては、生成モジュール２１２は、送金依頼の集計のための資金供給依頼を生成してよい。この資金供給依頼は、全体的な支払額、複数の異なる主要アカウント番号、及び関連する支払額を含んでよい。また生成モジュール２１２は、決済予告を生成するよう構成されてよい。レシピエント機関１１６に送信される決済予告は、少なくとも１つのレシピエントアカウント番号及び関連する決済額、又は集計された決済額、複数のレシピエントアカウント番号、及び関連する決済額を含んでよい。またレシピエントシステム１１０及び／又はレシピエントネットワーク１１８に送信される決済予告は、少なくとも決済額を含み、また整合データも含み又はポイントツーポイント支払トランザクションのレシピエントに通知するのに有用な他のデータを含んでもよい。
【００６１】
場合によっては、生成モジュール２１２が、ISO8583及びISO20022標準等の、１つ以上の標準に従ってデータメッセージを生成するよう構成されてよい。いくつかの場合では、生成モジュール２１２は、単一の標準に従ってデータメッセージを生成するよう構成されてよい。例えば、第１コンピューティング装置１０４の生成モジュール２１２は、ISO8583標準に従ってフォーマットされたデータメッセージを生成するよう構成されてよい。一方、第２コンピューティング装置１０６の生成モジュール２１２は、ISO20022標準に従ってフォーマットされたデータメッセージを生成するよう構成されてよい。いくつかの実施形態では、生成モジュール２１２は、データメッセージを１つのフォーマットから別のフォーマットへ変換するよう構成されてよい。データメッセージの変換は、１つ以上のデータ要素の再フォーマット及びそこに含まれるデータ要素の再編成、並びに関連する標準に定められたデータの追加又は削除を含んでよい。例えば、生成モジュール２１２は、ISO8583に従ってフォーマットされたデータメッセージを、ISO20022標準に準拠させるべく変換するよう構成されてよい。これは、１つ以上のデータ要素におけるデータの移動、及びそれらの再編成を含んでよい。
【００６２】
いくつかの実施形態では、生成モジュール２１２は、支払トランザクションに係わる第２データメッセージを生成するよう構成されてよい。第２データメッセージが、１つ以上の標準に従ってフォーマットされ、支払額を格納するよう構成された第１データ要素を含む少なくとも複数のデータ要素を含んでよく、支払額が、少なくともトランザクション明細に基づいてよい。また生成モジュール２１２は、支払トランザクションに係わる第３データメッセージを生成するよう構成されてよい。第３トランザクションメッセージが、１つ以上の標準に従ってフォーマットされ、決済額を格納するよう構成された第１データ要素と、レシピエントアカウント番号を格納するよう構成された第２データ要素と、を含む少なくとも複数のデータ要素を含んでよい。決済額は、少なくともトランザクション明細に基づいてよい。また生成モジュール２１２は、支払トランザクションに係わる第４データメッセージを生成するよう構成されてよい。第４データメッセージを、１つ以上の標準に従ってフォーマットし、第４データメッセージが、少なくとも、トランザクション明細を格納するよう構成された第１データ要素と、レシピエントアカウント番号を格納するよう構成された第２データ要素と、を含む、複数のデータ要素を含んでよい。
【００６３】
またコンピューティング装置２００は、決定モジュール２１４を含んでよい。決定モジュール２１４が、本開示で説明する処理システム１０２によって実行される機能に係わる、１つ以上の決定を実行するよう構成されてよい。決定モジュール２１４は、決定のための命令、及び付随するデータを受信してよく、決定を下してよく、その決定の結果をコンピューティング装置２００の別のモジュール又はエンジンへ出力してよい。例えば、決定モジュール２１４は、１つ以上の送金依頼に対して、センダ機関１１４からの送金資金の受領を決定するよう構成されてよい。決定は、それと関連付けられた通知の（例えば、受信装置２０２を介する）受領、トランザクションアカウント及びその収支の監視、及び他の適切な方法に基づいてよい。また決定モジュール２１４は、複数の送金依頼に対して、集計された支払額及び決済額を決定するよう構成されてよい。金額は、主要アカウント番号又はレシピエントアカウント番号における共通性に基づいて集計されてよく、適用可能であれば、そこに含まれる識別値を含んでよい。
【００６４】
いくつかの実施形態では、決定モジュール２１４は、センダ機関１１４から受領した資金の整合を実行するよう構成されてよい。整合は、センダ機関１１４から受領した資金に対応する送金依頼の、決定を含んでよい。例えば、センダ機関１１４は、（例えば、集計された資金供給依頼に基づいて）複数の異なる送金依頼に対して送金資金を移転してよい。また決定モジュール２１４は、受信装置２０２によって受領されたどの送金依頼が、受領された資金を介して成功裡に資金を供給されたか、決定することができる。決定は、次いで、送金依頼の決済のために、どの送金依頼が履行されたか決定するために使用されてよい。例えば、処理システム１０２が、レシピエント機関１１６への決済支払の移転を集計していると、決定モジュール２１４によって実行される整合は、レシピエント機関１１６と関連付けられた全ての送金依頼が、対応するセンダ機関１１４からいつ資金を受領していたか、という（例えば、レシピエントアカウント番号に基づく）決定を含んでよい。
【００６５】
いくつかの実施形態では、決済資金は、センダ機関１１４からの対応する送金依頼のための全ての資金の受領に先立って、レシピエント機関１１６に移転されてよい。例えば、処理システム１０２は、レシピエント機関１１６への資金の支払のために、レシピエント機関１１６と合意を結んでよい。その場合、決定モジュール２１４は、決済支払が合意に基づいて適切であるかどうか、決定することができる。別の例では、所定額の資金がセンダ機関１１４から受領されたときに、決済資金がレシピエント機関１１６に移転されてよい。受領は、決定モジュール２１４によって決定されてよい。
【００６６】
またコンピューティング装置２００は、送信装置２１６を含んでもよい。送信装置２１６が、１つ以上のネットワーク上で、１つ以上のネットワークプロトコルを介してデータを送信するよう構成されてよい。いくつかの実施形態では、送信装置２１６は、識別された支払信用証明等の極秘金融データ及び情報を含むトランザクションメッセージを送信するために、支払ネットワークと関連付けられたインフラストラクチャであって、特別に構成されたインフラストラクチャを使用する等、支払レール上でデータを送信するよう構成されてよい。場合によっては、送信装置２１６は、コンピューティング装置２００、センダシステム１０８、センダネットワーク１１２、センダ機関１１４、レシピエントシステム１１０、レシピエントネットワーク１１８、レシピエント機関１１６、及びインターネットのような代替的なネットワークを介する他のエンティティに、データを送信するよう構成されてよい。いくつかの実施形態では、送信装置２１６は、異なるネットワーク上でデータを送信する異なる送信装置のような、複数の装置を備えてよい。例えば、支払レール上でデータを送信する第１送信装置、及びインターネット上でデータを送信する第２送信装置等である。送信装置２１６は、受信コンピューティング装置によって解析され得るデータが重畳されたデータ信号を、電子送信してよい。場合によっては、送信装置２１６が、データを、送信に適するデータ信号に重畳する、エンコードする、又さもなければフォーマットする１つ以上のモジュールを含んでよい。
【００６７】
送信装置２１６は、センダ機関１１４に、資金供給依頼が重畳された又さもなければエンコードされたデータ信号を電子送信するよう構成されてよい。資金供給依頼は、少なくとも、主要アカウント番号及び支払額を含んでよく、又は集計された送金のために、複数の主要アカウント番号及び関連する支払額を有する支払額を含んでよい。また送信装置２１６は、決済予告が重畳された又さもなければエンコードされたデータ信号を、レシピエント機関１１６に電子送信するよう構成されてもよい。レシピエント機関１１６に送信される決済予告は、レシピエントアカウント番号及び決済額を含んでよく、又は合算決済のための単一の決済額、複数のレシピエントアカウント番号、及び関連する決済額を含んでよい。また送信装置２１６は、レシピエントシステム１１０及び／又はレシピエントネットワーク１１８にデータ信号を電子送信するよう構成されてもよい。データ信号は、少なくとも決済額が重畳されてよく、又さもなければエンコードされてよく、また係わるポイントツーポイントのための整合データ等の、レシピエントエンティティが使用するのに適する追加データを含んでもよい。追加データは、例えば、請求書番号、発注書番号、製品品目データ等を含んでよい。また送信装置２１６は、データ信号を、処理システム１０２における他のコンピューティング装置２００に送信するよう構成されてもよい。例えば、第１コンピューティング装置１０４の送信装置２１６はデータ信号を第２コンピューティング装置１０６に送信し、第２コンピューティング装置１０６が、資金供給依頼に含める集計された送金依頼を含んでよい。送信装置２１６は更に、従来の方法及びシステムを使用して、資金を、（例えばレシピエント機関１１６と関連付けられた）トランザクションアカウントに送金する、又は資金の移転を開始するための命令を電子送信するよう構成されてよい。
【００６８】
場合によっては、送信装置２１６は、データ信号を第三者エンティティに電子送信するよう構成されてよい。データ信号は、ISO8583標準からISO20022標準への変換等の、１つの標準から別の標準へ変換するデータメッセージが重畳される、又さもなければエンコードされる。いくつかの実施形態では、コンピューティング装置２００の送信装置２１６は、単一の標準を使用してフォーマットされるデータ信号を送信するよう構成されてよい。いくつかの場合では、コンピューティング装置２００は、複数の送信装置２１６を含んでよい。その場合、各送信装置２１６は、単一の関連する標準を使用してフォーマットされたデータメッセージを送信するよう構成されてよい。
【００６９】
また送信装置２１６は、第２データメッセージを、主要アカウント番号に係るトランザクションアカウントと関連付けられた第１金融機関に電子送信するよう構成されてよい。送信装置２１６は、第３データメッセージを、レシピエントアカウント番号に係るトランザクションアカウントと関連付けられた第２金融機関に電子送信し、また第１データメッセージと、第２データメッセージと、第３データメッセージとを、グラフィカルユーザインターフェイス（GUI）上に表示するために、送信してよい。
【００７０】
またコンピューティング装置２００は、メモリ２１８を含んでもよい。メモリ２１８が、本開示で説明する機能を実行する際にコンピューティング装置２００が使用するデータを格納するよう構成されてよい。メモリ２１８は、適切なデータフォーマット方法及びスキームを使用してデータを格納するよう構成されてよく、リードオンリーメモリ、ランダムアクセスメモリ等の、任意の適切なタイプのメモリとしてよい。メモリ２１８は、例えば、暗号鍵及びアルゴリズム、通信プロトコル及び標準、データフォーマット標準及びプロトコル、処理装置のモジュール及びアプリケーションプログラム用プログラムコード、並びに本開示の機能を実行する際にコンピューティング装置２００が使用するのに適する、当業者に自明な他のデータを含んでよい。いくつかの実施形態では、メモリ２１８は、そこに格納される構造化データセットの格納、識別、修正、更新、アクセス等のために、構造化クエリ言語を利用するリレーショナルデータベースから構成されてよく、又さもなければそれらを含んでよい。
【００７１】
ポイントツーポイントトランザクションを決済する第１プロセス
図３Ａは、例示的実施形態による、単一のコンピューティング装置、及びエンティティシステムを使用してポイントツーポイントランザクションを決済するプロセス３００ａのフロー図である。ポイントツーポイントランザクションを処理及び決済するプロセス３００ａは、単一のコンピューティング装置２００を有する処理システム１０２を利用する。その場合処理システム１０２が、センダシステム１０８及びレシピエントシステム１１０と直接に通信する。
【００７２】
ステップ３０２ａにおいて、センダシステム１０８は、ポイントツーポイントトランザクションのための送金依頼が重畳された又さもなければエンコードされたデータ信号を、処理システム１０２に電子送信してよい。送金依頼は、少なくとも、ポイントツーポイントランザクションに資金を供給するために使用されるトランザクションアカウントと関連付けられた主要アカウント番号、ポイントツーポイントランザクションにおいて支払われるトランザクション額、及び支払われた資金を受領するために使用されるトランザクションアカウントと関連付けられたレシピエントアカウント番号を含んでよい。いくつかの実施形態で、また送金依頼は、発注書番号、請求書番号、及び製品品目データ等の、整合データを含んでもよい。処理システム１０２のコンピューティング装置２００の受信装置２０２は、データ信号を受信し、そこに重畳された送金依頼を解析することができる。いくつかの場合では、送金依頼は、ISO8583標準又はISO20022標準等に従ってフォーマットされてよい。
【００７３】
ステップ３０４ａにおいて、処理システム１０２におけるコンピューティング装置２００の決定モジュール２１４は、受信した送金依頼を、他のポイントツーポイント支払トランザクションのために受信した送金依頼と集計してよい。送金依頼の集計は、受信した送金依頼におけるトランザクション額を、同一の主要アカウント番号を含む他の送金依頼に含まれたトランザクション額と集計すること、又は同一の銀行識別番号、イシュア識別番号、又は単一のセンダ機関１１４と関連付けられた他の識別値を有する他の主要アカウント番号を含むトランザクション額と集計することを含んでよい。場合によっては、またステップ３０４ａにおいて実行する集計は、受信した送金依頼と他の送金依頼との、決済のための集計を含んでもよい。その場合、他の送金依頼は、同一のレシピエントアカウント番号、又は、同一の銀行識別番号、イシュア識別番号を有する他のレシピエントアカウント番号、又は単一のレシピエント機関１１６と関連付けられた識別値を含んでよい。集計の一部として、処理システム１０２におけるコンピューティング装置２００の生成モジュール２１２は、資金供給依頼を生成してよい。その場合、資金供給依頼が、センダ機関１１４のために集計された支払額、主要アカウント番号及びその関連するトランザクション額、並びに他の主要アカウント番号及び対応するトランザクション額を含む。いくつかの実施形態では、資金供給依頼は、ISO8583標準又はISO20022標準等に従ってフォーマットされてよい。
【００７４】
ステップ３０６ａにおいて、処理システム１０２におけるコンピューティング装置２００の送信装置２１６は、資金供給依頼が重畳された又さもなければエンコードされたデータ信号を、センダ機関１１４に電子送信してよい。いくつかの実施形態では、データ信号を、支払ネットワークと関連付けられた支払レールを介して電子送信してよい。ステップ３０８ａにおいて、センダ機関１１４は、処理システム１０２から受信した資金供給依頼に示されたように、送金依頼に含まれたトランザクション額のために、センダシステム１０８に発行されたトランザクションアカウントから、主要アカウント番号と関連付けられるように、引き落としを行う。ステップ３１０ａにおいて、センダ機関１１４は、従来の方法及びシステムを使用して、資金供給依頼に含まれた支払額であって、集計された支払額を合計する送金資金を、処理システム１０２に移転してよい。
【００７５】
ステップ３１２ａにおいて、処理システム１０２におけるコンピューティング装置２００の決定モジュール２１４は、送金の整合を実行してよい。整合は、受領した送金資金を、対応する送金依頼と関連付けることを含んでよく、受領した額、及び対応する資金供給依頼へと集計された送金依頼に基づいてよい。また整合は、センダシステム１０８から受信した送金依頼に含まれたレシピエントアカウント番号と関連付けられたレシピエント機関１１６のために集計された決済額が、多様なセンダ機関１１４から受領されたかを決定することを含んでもよい。
【００７６】
適切な額の資金がレシピエント機関の決済のために受領されたら、処理システム１０２におけるコンピューティング装置２００の生成モジュール２１２は、決済予告を生成してよい。決済予告が、集計された決済額、レシピエントアカウント番号、送金依頼からのトランザクション額、並びに他のレシピエントアカウント番号、及び対応する集計された送金依頼からの関連するトランザクション額を含む。いくつかの場合では、決済予告は、ISO8583標準又はISO20022標準等に従ってフォーマットされてよい。ステップ３１４ａにおいて、処理システム１０２におけるコンピューティング装置２００の送信装置２１６は、決済予告が重畳された又さもなければエンコードされたデータ信号を、レシピエント機関１１６に電子送信してよい。場合によっては、データ信号を、支払ネットワークと関連付けられた支払レールを介して電子送信してよい。ステップ３１６ａにおいて、送信装置２１６は、従来の方法を使用して、集計された決済額に対応する資金を、レシピエント機関１１６へ移転してよく、又はレシピエント機関１１６への移転を開始してよい。
【００７７】
ステップ３１８ａにおいて、レシピエント機関１１６は、送金依頼に含まれたレシピエントアカウント番号と関連付けられたレシピエントエンティティに発行されたトランザクションアカウントに、トランザクション額を入金してよい。またレシピエント機関１１６は、決済予告に含まれた他のレシピエントアカウント番号と関連付けられた他のトランザクションアカウントに、関連するトランザクション額を入金することもできる。ステップ３１２ａにおいて実行する整合の一部として、また処理システム１０２におけるコンピューティング装置２００の生成モジュール２１２は、レシピエントシステム１１０のための決済予告を生成することもできる。決済予告は、少なくともトランザクション額を含んでよく、また送金依頼に含まれた整合データをも含んでよく、適用可能であれば、レシピエントシステム１１０に提供するのに適する任意の他のデータを含んでよい。決済予告は、ISO8583又はISO20022標準等の標準に従ってフォーマットされてよい。ステップ３２０ａにおいて、送信装置２１６は、決済予告が重畳された又さもなければエンコードされたデータ信号を、レシピエントシステム１１０に電子送信してよい。
【００７８】
図３Ｂは、例示的実施形態による、単一のコンピューティング装置、及びエンティティシステムを使用してポイントツーポイントランザクションを記録、処理、及び表示するプロセス３００ｂのフロー図である。ポイントツーポイントランザクションを記録、処理及び表示するプロセス３００ｂは、単一のコンピューティング装置２００を有する処理システム１０２を利用する。その場合処理システム１０２が、センダシステム１０８及びレシピエントシステム１１０と直接に通信する。
【００７９】
ステップ３０２ｂにおいて、センダシステム１０８は、ポイントツーポイントトランザクションのためのトランザクション明細が重畳された又さもなければエンコードされたデータ信号を、処理システム１０２に電子送信してよい。トランザクション明細は、少なくとも、ポイントツーポイントランザクションに資金を供給するために使用されるトランザクションアカウントと関連付けられた主要アカウント番号、ポイントツーポイントランザクションにおいて支払われるトランザクション額、及び支払われた資金を受領するために使用されるトランザクションアカウントと関連付けられたレシピエントアカウント番号を含んでよい。いくつかの実施形態では、またトランザクション明細は、発注書番号、請求書番号、及び製品品目データ等の、整合データを含んでもよい。処理システム１０２のコンピューティング装置２００の受信装置２０２は、データ信号を受信してよく、そこに重畳された送金依頼を分析してよい。いくつかの場合では、トランザクション明細は、ISO8583標準又はISO20022標準等に従ってフォーマットされてよい。
【００８０】
ステップ304bにおいて、処理システム１０２におけるコンピューティング装置２００は、その支払トランザクションのために受信したトランザクション明細、及び他のポイントツーポイント支払トランザクションのために受信したトランザクション明細を格納してよい。ステップ３０６ｂにおいて、処理システム１０２におけるコンピューティング装置２００の送信装置２１６は、資金供給依頼が重畳された又さもなければエンコードされたデータ信号を、センダ機関１１４に電子送信してよい。いくつかの実施形態では、データ信号を、支払ネットワークと関連付けられた支払レールを介して電子送信してよい。ステップ３０８ｂにおいて、センダ機関１１４は、処理システム１０２から受信した資金供給依頼に示されたように、トランザクション明細に含まれたトランザクション額のために、センダシステム１０８に発行されたトランザクションアカウントから、主要アカウント番号と関連付けられるように、引き落としを行なってよい。ステップ３１０ｂにおいて、センダ機関１１４は、従来の方法及びシステムを使用して、資金供給依頼に含まれた支払額を合計する資金を、処理システム１０２に移転してよい。
【００８１】
いくつかの実施形態では、第三者システム１２４は、トランザクション明細を認識してよい。第三者システム１２４が、例えば、予期される決済に基づいて借り入れするレシピエントエンティティのための資金提供に、関心を持つ会社であってよい。レシピエントエンティティは、処理システム１０２を使用して、第三者システム１２４が彼らの支払トランザクションに関する元帳を閲覧する許可をオプトインすることができる。ステップ３２２ｂにおいて、第三者システム１２４は、決済される支払トランザクション及びレシピエントエンティティと関連付けられた元帳に格納された追加トランザクションに関する、取引ディレクトリの閲覧にアクセスすることができる。
【００８２】
ステップ３２４ｂにおいて、第三者システム１２４は、レシピエントエンティティが要求に応じて現金を得る能力を、決済される支払トランザクションと関連付けられたオファーを彼らに提供することによって、提供してよい。第三者システム１２４は、レシピエントエンティティのトランザクション履歴を再調査してよい。再調査は、レシピエントエンティティとトランザクションのために送金を支払う特定のセンダエンティティとの間の、先のトランザクションを識別することを含んでよい。また第三者システムが、トランザクションに基づいて、ローンを提供するための金利を決定してよい。レシピエントエンティティによって受諾され得る又は拒否され得るオファーは、レシピエントエンティティに、直接に又は処理システム１０２を介して通信されてよい。受諾された場合、第三者システム１２４は、レシピエントエンティティによって直接になされ得る、又は処理システム１０２を介してなされ得る、及び／又は本開示で説明する決済プロセスの一部としてレシピエント機関１１６によってなされ得る後の返済のために、レシピエントエンティティに対して早期支払を提供することができる。
【００８３】
ステップ３１４ｂにおいて、処理システム１０２におけるコンピューティング装置２００の送信装置２１６は、決済予告が重畳された又さもなければエンコードされたデータ信号を、レシピエント機関１１６に電子送信してよい。いくつかの実施形態では、データ信号を、支払ネットワークと関連付けられた支払レールを介して電子送信してよい。ステップ３１６ｂにおいて、送信装置２１６は、集計された決済額に対応する資金を、従来の方法を使用してレシピエント機関１１６へ移転してよく、又はレシピエント機関１１６への移転を開始してよい。
【００８４】
ステップ３１８ｂにおいて、レシピエント機関１１６は、送金依頼に含まれたレシピエントアカウント番号と関連付けられたレシピエントエンティティに発行されたトランザクションアカウントに、トランザクション額を入金してよい。またレシピエント機関１１６は、決済予告に含まれた他のレシピエントアカウント番号と関連付けられた他のトランザクションアカウントに、関連するトランザクション額を入金することもできる。レシピエントエンティティが第三者システム１２４のオファーを受諾した場合、レシピエント機関１１６は、クレジット額の支払を第三者システム１２４に提供することができる。そのような場合のいくつかでは、レシピエント機関１１６は、通常通りに、トランザクションアカウントに入金してよい。その場合レシピエントエンティティは、第三者システム１２３に独自にローンを返済することができる。ステップ３２０ｂにおいて、送信装置２１６は、トランザクションステータスが重畳された又さもなければエンコードされたデータ信号を、レシピエントシステム１１０に電子送信してよい。そのためレシピエントは、トランザクション明細を詳述する元帳を閲覧可能である。レシピエントエンティティは、次いで、設定された条件に従ってローンを返済することによって、第三者システム１２４とのトランザクションを終了してよい。
【００８５】
ポイントツーポイントトランザクションを決済する第２プロセス
図４は、第１コンピューティング装置１０４及び第２コンピューティング装置１０６を使用する処理システム１０２を利用する、ポイントツーポイントランザクションを処理及び決済する代替的なプロセス４００を示す。その場合処理システム１０２が、センダネットワーク１１２及びレシピエントネットワーク１１８のそれぞれを介して、センディングエンティティ及びレシピエントエンティティと直接に通信する。場合によっては、センダネットワーク１１２及びレシピエントネットワーク１１８が、同一のエンティティであってよい。
【００８６】
ステップ４０２において、センダネットワーク１１２はセンディングエンティティから、送金情報を受信してよい。いくつかの場合では、送金情報は、センダシステム１０８からの電子送信を介する等、センダシステム１０８から受信されてよい。他の場合では、送金情報は、ウエブページ又はアプリケーションプログラムを介する等、センディングエンティティによって使用されるコンピューティング装置との通信を介して受信されてよい。いくつかの場合では、送金情報は、センディングエンティティから受信した命令に基づいてセンダネットワーク１１２に手動でデータを入力するセンダネットワーク１１２の従業員等の、センダネットワーク１１２のユーザによって手動で入力されてよい。センダネットワーク１１２に提供された送金情報は、センダ機関１１４によってセンディングエンティティに発行されたトランザクションアカウントのための主要アカウント番号、支払われるトランザクション額、及び支払を受領するためにレシピエント機関１１６によってレシピエントエンティティに発行されたトランザクションアカウントのためのレシピエントアカウント番号を含んでよい。
【００８７】
ステップ４０４において、センダネットワーク１１２は、送金依頼が重畳された又さもなければエンコードされたデータ信号を、処理システム１０２の第１コンピューティング装置１０４に電子送信してよい。送金依頼は、少なくとも、主要アカウント番号、トランザクション額、及びレシピエントアカウント番号を含んでよい。いくつかの実施形態では、送金依頼は、ISO8583標準に従ってフォーマットされてよい。ステップ４０６において、第１コンピューティング装置１０４の決定モジュール２１４は、送金依頼を関連する送金依頼と集計してよい。集計は、ポイントツーポイントランザクションの送金のための集計、及びポイントツーポイントトランザクションの決済のための集計を含んでよい。送金の集計は、送金依頼を、同一の主要アカウント番号又は他の主要アカウント番号を含む他の送金依頼と集計することを含んでよい。その場合、各送金依頼は、センダ機関１１４と関連付けられた共通の識別値を含む。決済の集計は、送金依頼を、同一のレシピエントアカウント番号又は他のレシピエントアカウント番号を含む他の送金依頼と集計することを含んでよい。その場合各送金依頼は、レシピエント機関１１６と関連付けられた共通の識別値を含む。
【００８８】
ステップ４０８において、第１コンピューティング装置１０４の送信装置２１６は、内部通信方法及びネットワークを使用して、センダ機関１１４と関連付けられた資金供給データを、処理システム１０２の第２コンピューティング装置１０６に電子送信してよい。第２コンピューティング装置１０６の受信装置２０２は、資金供給データを受信してよい。資金供給データが、少なくとも、トランザクション額、受信された送金依頼に含まれた主要アカウント番号、及び識別され集計された送金依頼を含んでよい。いくつかの場合では、また資金供給データは、集計された支払額を含んでもよい。他の場合では、第２コンピューティング装置１０６の決定モジュール２１４は、集計された支払額を決定してよい。
【００８９】
第２コンピューティング装置１０６の生成モジュール２１２は、資金供給依頼を生成してよい。その場合、資金供給依頼は、少なくとも、集計された支払額、各主要アカウント番号、及び関連するトランザクション額を含んでよい。いくつかの実施形態では、資金供給依頼は、ISO20022標準に従ってフォーマットされてよい。ステップ４１０において、第２コンピューティング装置１０６の送信装置２１６は、資金供給依頼が重畳された又さもなければエンコードされたデータ信号を、センダ機関１１４に電子送信してよい。ステップ４１２において、センダ機関１１４は、資金供給依頼に含まれた各主要アカウント番号に対応するトランザクションアカウントから、関連するトランザクション額を引き落としてよい。ステップ４１４において、センダ機関１１４は、集計された支払額の金額である送金資金の、処理システム１０２への移転を開始してよい。
【００９０】
ステップ４１６において、第２コンピューティング装置１０６の決定モジュール２１４は、受領した送金資金の整合を実行してよい。整合は、送金資金の、受信した資金供給データとの整合を含んでよく、どの送金依頼が資金を供給されたかを決定してよい。整合の一部としてステップ４１８において、第２コンピューティング装置１０６の送信装置２１６は、内部通信ネットワーク及び方法を使用して、送金資金の受領の確認を第１コンピューティング装置１０４に電子送信してよい。いくつかの実施形態では、第２コンピューティング装置１０６は、送金資金の受領のみを確認するだけでよい。追加の整合は、第１コンピューティング装置１０４の決定モジュール２１４によって実行される。整合は、（例えばステップ４０６において実行されるように）レシピエント機関１１６のために集計された決済額の、適切な金額が受領されたかを決定することを含んでよい。
【００９１】
適切な額が受領されたら、次いで、ステップ４２０において、第１コンピューティング装置１０４の送信装置２１６は、決済を実行する依頼が重畳された又さもなければエンコードされたデータ信号を、内部通信ネットワーク及び方法を使用して第２コンピューティング装置１０６に電子送信してよい。決済依頼は、少なくとも、レシピエントアカウント番号及びレシピエント機関１１６のために集計されたトランザクション額を含んでよい。いくつかの実施形態では、また決済依頼は、集計された決済額を含んでよい。他の実施形態では、第２コンピューティング装置１０６の決定モジュール２１４は、集計された決済額を決定してよい。
【００９２】
決済を依頼すると、第１コンピューティング装置１０４は、（例えばそこに含まれた生成モジュール２１２を介して）レシピエントエンティティに配信するための決済予告を生成してよい。決済予告は、少なくとも、受信した送金依頼に含まれたトランザクション額及び整合データ等の任意の追加データを含んでよい。いくつかの実施形態では、決済予告は、ISO8583標準に従ってフォーマットされてよい。ステップ４２２において、第１コンピューティング装置１０４の送信装置２１６は、決済予告が重畳された又さもなければエンコードされたデータ信号を、レシピエントネットワーク１１８に電子送信してよい。ステップ４２４において、レシピエントネットワーク１１８は、決済資金が受領されたことをレシピエントエンティティに通知してよい。レシピエントネットワーク１１８は、電話、電子メール、ショートメッセージサービス、マルチメディアメッセージサービス等の適切な方法を介して、レシピエントエンティティと通信してよい。
【００９３】
第１コンピューティング装置１０４から決済依頼を受信した後、第２コンピューティング装置１０６の生成モジュール２１２は、レシピエント機関１１６に配信するために決済予告を生成してよい。この決済予告は、少なくとも、集計された送金依頼からの各レシピエントアカウント番号及び関連するトランザクション額を含んでよい。いくつかの場合では、また決済予告は、集計された決済額を含んでもよい。いくつかの実施形態では、決済予告は、ISO20022標準に従ってフォーマットされてよい。ステップ４２６において、第２コンピューティング装置１０６の送信装置２１６は、決済予告が重畳された又さもなければエンコードされたデータ信号を、レシピエント機関１１６に電子送信してよい。ステップ４２８において、処理システム１０２は、集計された決済額のレシピエント機関１１６への移転を開始してよい。ステップ４３０において、レシピエント機関は、レシピエントアカウント番号に対応する各トランザクションアカウントに、関連するトランザクション額を入金してよい。
【００９４】
ポイントツーポイントトランザクションのための合算決済のプロセス
図５Ａ及び図５Ｂは、例示的実施形態による、図１の処理システムにおいて、複数のコンピューティング装置を使用してポイントツーポイントランザクションを決済するプロセスのフロー図である。図５Ａ及び図５Ｂは、処理システム１０２において、複数のコンピューティング装置２００を使用して、集計されたポイントツーポイントランザクションを決済するプロセスを示す。その場合、ポイントツーポイントランザクションは、送金及び決済の両方のために集計される。図５Ａ及び図５Ｂに示す処理システム１０２によって実行される本開示で説明する機能は、単一のコンピューティング装置２００を使用して代替的に実行され得ること、また図５Ａ及び図５Ｂに示すプロセスに対する代替として、送金のみ又は決済のみの集計を含み得ることは、当業者にとって自明である。
【００９５】
ステップ５０２において、第１コンピューティング装置１０４の受信装置２０２は、複数の送金依頼を受信してよい。送金依頼が、センダシステム１０８、センダネットワーク１１２、及び／又はセンダ機関１１４から受信されてよい。各送金依頼は、少なくとも、そこから支払がなされるトランザクションアカウントと関連付けられた主要アカウント番号、支払のためのトランザクション額、及び支払を受領するためのトランザクションアカウントと関連付けられたレシピエントアカウント番号を含んでよい。いくつかの実施形態では、また送金依頼は、整合データを含んでよい。場合によっては、送金依頼は、ISO8583又はISO20022標準に従ってフォーマットされてよい。
【００９６】
ステップ５０４において、第１コンピューティング装置１０４の決定モジュール２１４は、送金額及び複数の送金依頼のための資金供給額を集計してよい。送金額は、受信された送金依頼に含まれた少なくとも１つの主要アカウント番号と関連付けられた各センダ機関１１４のための額であってよい。その場合、それぞれの送金額は、センダ機関１１４と関連付けられた主要アカウント番号を含む各送金依頼に含まれたトランザクション額の合計であってよい。これは、銀行識別番号、イシュア識別番号、又は主要アカウント番号に含まれた他の識別値に基づいて決定してよい。資金供給額は、受信された送金依頼に含まれた少なくとも１つのレシピエントアカウント番号と関連付けられた各レシピエント機関１１６のための額であってよい。その場合、それぞれの資金供給額は、レシピエント機関１１６と関連付けられた主要アカウント番号を含む各送金依頼に含まれたトランザクション額の合計であってよい。これは、銀行識別番号、イシュア識別番号、又はレシピエントアカウント番号に含まれた他の識別値に基づいて決定してよい。
【００９７】
ステップ５０６において、第１コンピューティング装置１０４の生成モジュール２１２は、資金供給データを生成してよい。資金供給データが、各センダ機関１１４のために決定された送金額、対応するセンダ機関１１４、並びに各センダ機関１１４のための関連する主要アカウント番号及び対応するトランザクション額を含んでよい。ステップ５０８において、第１コンピューティング装置１０４の送信装置２１６は、資金供給データが重畳された又さもなければエンコードされたデータ信号を、処理システム１０２の内部通信ネットワーク及び方法を介して第２コンピューティング装置１０６に電子送信してよい。ステップ５１０において、第２コンピューティング装置１０６の受信装置２０２は、資金供給データを受信してよい。
【００９８】
ステップ５１２において、第２コンピューティング装置１０６の生成モジュール２１２は、各センダ機関１１４のための資金供給依頼を生成してよい。資金供給依頼は、対応するトランザクション額と関連付けられた送金額及び関連付けられた主要アカウント番号を含む。資金供給依頼は、第２コンピューティング装置１０６の送信装置２１６によってそれぞれのセンダ機関１１４に電子送信されるデータ信号に、重畳されてよく、又さもなければエンコードされてよい。いくつかの実施形態では、各資金供給依頼は、ISO8583又はISO20022標準に従ってフォーマットされてよい。センダ機関１１４は、資金供給依頼を受信し、それらを処理システム１０２に提供される送金額と共に適宜に処理してよい。ステップ５１４において、第２コンピューティング装置１０６の受信装置２０２は、送金資金をセンダ機関１１４から受領する、又は受領の確認を受信してよい。
【００９９】
ステップ５１６において、第２コンピューティング装置１０６の送信装置２１６は、データを、処理システム１０２の内部通信方法及びネットワークを使用して第１コンピューティング装置１０４に電子送信してよい。データは、送金資金の受領の確認が重畳される。確認は、少なくとも、そこから資金が受領されたセンダ機関１１４及び受領された対応する送金額を含んでよい。ステップ５１８において、第１コンピューティング装置１０４の受信装置２０２は、確認を受信してよい。ステップ５２０において、第１コンピューティング装置１０４の決定モジュール２１４は、送金資金の整合を実行してよい。整合は、受領された資金がどの送金依頼に対応するか決定することを含んでよい。これは、いずれのレシピエント機関１１６との決済のために適切な資金が受領されたかを決定するために使用することができる。
【０１００】
ステップ５２２において、第１コンピューティング装置１０４の生成モジュール２１２は、決済依頼を生成してよい。決済依頼が、（例えば整合に基づいて）決済を受領する各レシピエント機関１１６のための資金供給額、並びに関連するレシピエントアカウント番号及び対応するトランザクション額を含んでよい。また生成モジュール２１２は、（例えば第１コンピューティング装置１０４の送信装置２１６を介して）決済依頼を、処理システム１０２の適切な内部通信ネットワーク及び方法を使用して、第２コンピューティング装置１０６に電子送信してよい。いくつかの実施形態では、決済依頼は、ISO8583又はISO20022標準に従ってフォーマットされてよい。ステップ５２４において、第１コンピューティング装置１０４の生成モジュール２１２は、複数の送金依頼の各々のための決済予告を生成してよい。決済予告が、少なくとも、トランザクション額及び任意の他の追加データ（例えば、送金依頼に含まれた整合データ等）を含んでよい。決済予告は、レシピエントエンティティにポイントツーポイントランザクションの決済を通知するために、関連するレシピエントシステム１１０、レシピエント機関１１６、又はレシピエントネットワーク１１８に電子送信されるデータ信号に、重畳されてよく、又さもなければエンコードされてよい。
【０１０１】
ステップ５２６において、第２コンピューティング装置１０６の受信装置２０２は、第１コンピューティング装置１０４から決済依頼を受信してよい。ステップ５２８において、第２コンピューティング装置１０６の生成モジュール２１２は、各レシピエント機関１１６のための決済通知を生成してよい。各決済通知は、レシピエント機関１１６のために決定された集計された資金供給額、送金依頼からの関連するレシピエントアカウント番号、及び対応するトランザクション額を含んでよい。いくつかの実施形態では、決済通知は、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）データベース、分散データベース、オブジェクトデータベース等の、任意のタイプの適切なデータベース構成で構成されてよい。適切な構成及びストレージタイプは、当業者にとって自明である。
【０１５１】
またコンピュータシステム９００は、通信インタフェース９２４を含んでよい。通信インタフェース９２４が、ソフトウエア及びデータが、コンピュータシステム９００と外部装置との間で送信されることを可能にしてよい。例示的な通信インタフェース９２４は、モデム、ネットワークインタフェース（例えばイーサネットカード）、通信ポート、PCMCIAスロット及びカード等を含んでよい。通信インタフェース９２４を介して転送されるソフトウエア及びデータは信号形式であってよい。当該信号形式は、電子の、電磁気の、光の、又は当業者にとって自明な他の信号のものであってよい。信号は、通信パス９２６を介して伝わってよい。当該通信パス９２６は信号を伝送するよう構成され、電線、ケーブル、光ファイバ、電話線、携帯電話リンク、無線周波数リンク等を用いて実装されてよい。
【０１５２】
コンピュータシステム９００は更に、表示インタフェース９０２を含んでよい。表示インタフェース９０２が、データが、コンピュータシステム９００と外部のディスプレイ９３０との間で転送されることを可能にするよう構成されてよい。例示的な表示インタフェース９０２は、高精細度マルチメディアインタフェース（HDMI）、デジタルビジュアルインタフェース（DVI）、ビデオグラフィックスアレイ（VGA）等を含んでよい。ディスプレイ９３０は任意の適切なタイプのディスプレイであってよく、コンピュータシステム９００の表示インタフェース９０２を介して送信されるデータを表示する。ディスプレイ９３０は、ブラウン管（CRT）ディスプレイ、液晶ディスプレイ（LCD）、発光ダイオード（LED）ディスプレイ、静電容量方式タッチディスプレイ、薄膜トランジスタ（TFT）ディスプレイ等を含む。
【０１５３】
コンピュータプログラム媒体及びコンピュータ使用可能媒体は、メインメモリ９０８及び補助メモリ９１０等、メモリを指してよく、（例えば、DRAM等）半導体メモリであってよい。これらのコンピュータプログラム製品は、コンピュータシステム９００へソフトウエアを提供するための手段であってよい。コンピュータプログラム（例えばコンピュータ制御ロジック）は、メインメモリ９０８及び／又は補助メモリ９１０に格納されてよい。またコンピュータプログラムは、通信インタフェース９２４を介して受信されてよい。そのようなコンピュータプログラムは、実行されると、コンピュータシステム９００が本開示で説明する方法を実行することを可能にしてよい。特に、コンピュータプログラムは、実行されると、本開示で説明するように、プロセッサ装置９０４が、図３、４、５Ａ、５Ｂ、６及び７に示す方法を実行することを可能にしてよい。従って、そのようなコンピュータプログラムはコンピュータシステム９００のコントローラを示してよい。本開示はソフトウエアを使用して実装される。当該ソフトウエアは、取外し可能なストレージドライブ９１４、インタフェース９２０、及びハードディスクドライブ９１２、又は通信インタフェース１９２４を用いて、コンピュータプログラム製品に格納されてコンピュータシステム９００へロードされてよい。
【０１５４】
プロセッサ装置９０４は、コンピュータシステム９００の機能を実行するよう構成された１つ以上のモジュール又はエンジンを含んでよい。モジュール又はエンジンの各々は、ハードウエアを使用して実装されてよい。場合によっては、モジュール又はエンジンの各々が、メインメモリ９０８又は補助メモリ９１０に格納されたプログラムコード及び／又はプログラムに対応するような、ソフトウエアを利用してもよい。そのような場合では、プログラムコードは、コンピュータシステム９００のハードウエアによる実行に先立って、プロセッサ装置９０４によって（例えば、コンパイリングモジュール又はエンジンによって）コンパイルされてよい。例えば、プログラムコードは、コンピュータシステム９００のプロセッサ装置９０４及び／又は任意の追加のハードウエアコンポーネントによる実行のために、アセンブリ言語又はマシンコード等の、より低いレベルの言語に翻訳されるプログラミング言語で書かれたソースコードであってよい。コンパイリングのプロセスは、語彙分析、前処理、解析、意味分析、構文主導型翻訳、コード生成、コード最適化の使用、及びコンピュータシステム９００による本開示の機能の実行を制御するのに適する、より低いレベルの言語へとプログラムコードを翻訳するのに適し得る、任意の他の技術の使用を含んでよい。そのようなプロセスは、結果的にコンピュータシステム９００において、上記に説明する機能を実行するために一意的にプログラムされた、特別に構成されたコンピュータシステム９００となることは、当業者にとって自明である。
【０１５５】
本開示で一貫する技術は、他の特徴の中でも、ポイントツーポイント支払トランザクションを処理するシステム及び方法を提供する。開示するシステム及び方法の多様な例示的実施形態が上述されるが、それらは限定目的でなく、例示目的のみで記載されることを理解されたい。それらは徹底したものでなく、本開示を、開示された形態そのものへ限定しない。上記の教示に照らして修正例及び変形例が可能である。広がり又は範囲を逸脱すること無く、本開示の実装から修正例及び変形例が得られてよい。
【図１】
2019512808.tif 000003
【図２】
2019512808.tif 000004
【図３Ａ】
2019512808.tif 000005
【図３Ｂ】
2019512808.tif 000006
【図４】
2019512808.tif 000007
【図５Ａ】
2019512808.tif 000008
【図５Ｂ】
2019512808.tif 000009
【図６Ａ】
2019512808.tif 000010
【図６Ｂ】
2019512808.tif 000011
【図７】
2019512808.tif 000012
【図８】
2019512808.tif 000013
【図９】
2019512808.tif 000014
【図１０Ａ】
2019512808.tif 000015
【図１０Ｂ】
2019512808.tif 000016
【国際調査報告】
2019512808.tif 000017
2019512808.tif 000018