JP7376581B2 - クレジット口座を使用する移転 - Google Patents

Description

関連出願の相互参照
本願は、その全体が本明細書に記載されたかのように組み込まれる、ＰＥＥＲ－ＴＯ－ＰＥＥＲ ＩＮＴＥＲＢＡＮＫ ＴＲＡＮＳＦＥＲＳ ＵＳＩＮＧ ＣＲＥＤＩＴ ＡＣＣＯＵＮＴＳという名称の２０１８年１０月１７日に出願された米国仮特許出願第６２／７４６，８６６号の優先権及び利益を主張する。

多くの個人は、商品又はサービスの支払いをするためにクレジット・カード口座を所有している。クレジット・カード所有者が支払いを行うとき、クレジット・カード所有者は、自分の情報を商人に提供する。商人は、クレジット・カード情報をクレジット・カード取引ネットワークに提出し、クレジット・カード取引ネットワークは、取引情報をクレジット・カード所有者の発行銀行に送る。発行銀行は、取引についてそれぞれのクレジット・カードから引き落とし、又はクレジット・カードに請求し、次いでネットワークに支払いを提供し得、ネットワークは、商人の銀行に支払いを提供する。しかしながら、クレジット・カード所有者はクレジット・カード取引ネットワークにアクセスできる任意の商人に支払いを行うことができるが、支払人は、支払人のクレジット・カードで他のクレジット・カード所有者又は非商人に支払いを行うことができない。同様に、商人は、任意の顧客から資金を受け取ることができるが、商人は、特定の取引を払い戻す場合を除いて、他の商人又は顧客に支払いを行うことができない。更に、クレジット・カード取引ネットワークの使用はしばしば、他の支払いレールと比較して高いフィーに関連付けられる。

以下の図面を参照すると、本開示の多くの態様をより良く理解することができる。図面中の構成要素は必ずしも原寸に比例せず、本開示の原理をはっきりと示す時に強調が行われる。更に、図面では、同様の参照番号は、いくつかの図全体にわたって、対応する部分を示す。

本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるクライアントによってレンダリングされるユーザ・インターフェースの例の絵画図である。 本開示の様々な実施形態によるネットワーク環境の図面である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内で実行されるアプリケーションの部分として実装される機能の例を示すシーケンス図である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内で実行されるアプリケーションの部分として実装される機能の例を示すシーケンス図である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内で実行されるアプリケーションの部分として実装される機能の例を示すシーケンス図である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内のアプリケーションの部分として実装される機能の例を示すシーケンス図である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内のアプリケーションの部分として実装される機能の例を示すシーケンス図である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内のアプリケーションの部分として実装される機能の例を示すシーケンス図である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内のアプリケーションの部分として実装される機能の例を示すシーケンス図である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内のアプリケーションの部分として実装される機能の例を示すシーケンス図である。 本開示の様々な実施形態による、図２のネットワーク環境内のコンピューティング環境内のアプリケーションの部分として実装される機能の例を示すシーケンス図である。

本開示の様々な実施形態は、プロセッサ及びメモリを備える第１のコンピューティング・デバイスと、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、第２のコンピューティング・デバイスからメッセージを受信することであって、メッセージが、資金移転の通知、及び資金移転にリンクされる取引識別子を含む、受信することと、資金移転を処理するようにという要求を第３のコンピューティング・デバイスに送ることであって、要求が、資金移転についての取引識別子、口座識別子、及び機関識別子を含む、送ることとを行わせる、メモリ内に記憶された機械可読命令とを備えるシステムを含む。

システムの一つ又は複数の実施形態では、メモリ内に記憶された機械可読命令は、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、資金移転が完了したという表示を受信させ、第１のコンピューティング・デバイスのディスプレイ上に、資金移転が完了したという表示をレンダリングさせる。システムの一つ又は複数の実施形態では、取引識別子が、メッセージ内に含まれるユニフォーム・リソース・インジケータ（ＵＲＩ）内に含まれ、機械可読命令は更に、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、ＵＲＩにアドレス指定される第１の要求を送らせ、第１の要求に応答して、機関のリストを受信させ、機関のリストからの機関の選択に応答して、機関についての認証証明を求める第２の要求を受信させ、認証証明の提出に応答して、機関のリストから選択された機関によって維持される金融口座のリストを受信させる。システムの一つ又は複数の実施形態では、第１のコンピューティング・デバイスはディスプレイを備え、機械可読命令は更に、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、ディスプレイによってレンダリングされたユーザ・インターフェース内に、金融口座のリストを提示させ、金融口座のリストからの金融口座の選択に応答して、資金移転を処理するようにという要求内に金融口座についての口座識別子を含めさせる。システムの一つ又は複数の実施形態では、機械可読命令は更に、第１のコンピューティング・デバイスに、少なくとも、第１のコンピューティング・デバイスのディスプレイ上に提示されたユーザ・インターフェース内に、資金移転を確認するようにというプロンプトをレンダリングさせ、資金移転の確認に応答して、資金移転を処理するようにという要求が送られる。システムの一つ又は複数の実施形態では、メッセージはショート・メッセージ・サービス（ＳＭＳ）メッセージである。

本開示の様々な実施形態は、指定のクレジット口座から受取人に指定の額の資金を送るようにという要求を第１のクライアント・デバイスから受信することと、受取人に指定の額の資金を送るようにという要求についての取引識別子をコンピューティング・デバイスに要求することと、第２のクライアント・デバイスに第１の通知を送ることであって、第１の通知が取引識別子を含み、第２のクライアント・デバイスが受取人に関連付けられる、送ることと、受取人が指定の額の資金を受け入れたという第２の通知をコンピューティング・デバイスから受信することであって、第２の通知が金融口座を識別する受信することと、指定の額の資金について金融口座への資金移転を開始することとを含む方法を含む。一つ又は複数の実施形態では、方法は、指定のクレジット口座から指定の額の資金を引き落とすことを更に含む。方法の一つ又は複数の実施形態では、指定の額の資金について金融口座への資金移転を開始することは、即時グロス決済（ＲＴＧＳ）システムを通じて支払いを開始することを更に含む。方法の一つ又は複数の実施形態では、指定の額の資金について金融口座への資金移転を開始することは、バッチ処理されるネット決済ネットワークを通じて支払いを開始することを更に含む。方法の一つ又は複数の実施形態では、指定の額の資金について金融口座への資金移転を開始することは、指定の額の資金についてエスクロー口座から金融口座への支払いを開始することを更に含む。方法の一つ又は複数の実施形態では、指定のクレジット口座から受取人に指定の額の資金を送るようにという要求は、受取人についての連絡先情報を更に含み、第２のクライアント・デバイスに第１の通知を送ることは、連絡先情報で指定される宛先に第１の通知を送ることを更に含む。一つ又は複数の実施形態では、方法は、取引識別子を含むユニフォーム・リソース・インジケータ（ＵＲＩ）を作成することと、第１の通知内にＵＲＩを含めることとを更に含む。方法の一つ又は複数の実施形態では、第２の通知は取引識別子を更に含む。一つ又は複数の実施形態では、方法は、第１のクライアント・デバイスにメッセージを送ることを更に含み、メッセージは、受取人が指定の額の資金を受け入れたことを示す。

本開示の様々な実施形態は、第１のコンピューティング・デバイスのプロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、クライアント・デバイスからの資金移転を処理するようにという要求を受信することであって、要求が取引識別子を含む、受信することと、クライアント・デバイスに機関のリストを提供することと、機関のリストからの機関の第１の選択をクライアント・デバイスから受信することと、機関のリストから選択された機関についての認証証明をクライアント・デバイスに要求することと、認証証明の受信に応答して、機関のリストから選択された機関に関連付けられる口座のリストをクライアント・デバイスに提供することと、口座のリストからの口座の第２の選択を受信することと、取引識別子、機関のリストから選択された機関についての第１の識別子、及び口座のリストから選択された口座についての第２の識別子を第２のコンピューティング・デバイスに提供することとを行わせる機械可読命令を含む非一時的コンピュータ可読媒体を含む。非一時的コンピュータ可読媒体の一つ又は複数の実施形態では、資金移転を処理するようにという要求は第２の要求であり、機械可読命令は、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、取引識別子を求める第２のコンピューティング・デバイスからの第１の要求に応答して、取引識別子を生成させ、第２のコンピューティング・デバイスに取引識別子を提供させる。非一時的コンピュータ可読媒体の一つ又は複数の実施形態では、取引識別子が、資金移転を処理するようにという要求内のクライアント・デバイスによって要求されるユニフォーム・リソース識別子（ＵＲＩ）内に含められる。非一時的コンピュータ可読媒体の一つ又は複数の実施形態では、機械可読命令は更に、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、認証証明を使用するクライアント・デバイスの代わりに、機関のリストから選択された機関によって運用されるピア支払いサービスとの間で認証させる。非一時的コンピュータ可読媒体の一つ又は複数の実施形態では、機械可読命令は更に、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、資金移転に関連付けられるエスクロー口座についての第３の識別子を第２のコンピューティング・デバイスに提供させる。

クレジット・カードなどのクレジット口座を使用して、資金を送り、受け取るための様々な手法が開示される。自動決済機関（ＡＣＨ）ネットワークや即時グロス決済（ＲＴＧＳ）ネットワークなどを通じた移転などの資金移転が、金融機関間で資金を移転するために使用され得る。金融機関は、顧客の代わりに口座内に資金を保管し、顧客が口座内に資金を預け、又は口座から資金を移転することを可能にする任意の機関又は団体を含み得る。したがって、金融機関は、銀行、クレジット・ユニオン、貯蓄貸付組合、仲介業者、証券会社、送金業者、ストアド・バリュー口座を提供する支払いプロバイダなどを含み得る。

移転の完了の前又は後に、資金の移転の性質を反映するように、クレジット・カード口座に入金又は引落しが行われ得る。したがって、金融口座（たとえば、当座預金口座、普通預金口座、証券口座、ストアド・バリュー口座など）又はクレジット口座を有する任意の個人に資金を支払うために、クレジット口座（たとえば、クレジット・カード）が使用され得る。同様に、クレジット口座はまた、金融口座又はクレジット口座を有する任意の個人から資金を受け取り得る。その結果、支払いレールと呼ばれることがある任意の支払いプラットフォーム又は支払いネットワークから資金を受け取り、或いはそれらを通じて資金を支払うために、クレジット・カードが使用され得る。以下の議論では、システム及びその構成要素の全般的な説明が与えられ、その後にそれらの動作の議論が続く。

図１Ａ～１Ｄは、クレジット・カード口座を使用して第３者（たとえば、友人、同僚、クライアント、又は商人）に金銭を送るために、どのように支払人がクライアント・デバイス１００と対話し得るかという例を示す。しかしながら、支払人は、他の実装では、クレジット・カード口座を使用して第３者に金銭を送るために他の方式で支払人のクライアント・デバイス１００と対話し得る。

図１Ａは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ａが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、支払人は、別の個人への直接的支払いのために、ユーザ・インターフェース１０６ａ内に提示されたクレジット・カードのリストからクレジット・カードを選択し得る。たとえば、支払人がクライアント・デバイス１００上で支払人のモバイル・バンキング・アプリケーションにログインし、別の個人に直接的に支払うためのオプションを選択した場合、支払人は、ユーザ・インターフェース１０６ａなどのインターフェースの提示を受け得る。

図１Ｂは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｂが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、支払人は、ユーザ・インターフェース１０６ｂ内に提示された受取人のリストから資金の受取人を選択し得る。受取人のリスト内の個々の受取人について、受取人に関連付けられる一意識別子が提示され得る。そのような一意識別子は、携帯電話番号、ｅメール・アドレスなどの受取人の連絡先情報を表し得る。たとえば、受取人が、受取人の電話番号を一意識別子として使用して以前に支払いを受けたことがある場合、受取人の電話番号が提示され得る。複数の一意識別子が同一の受取人に対応付けられる場合、デフォルト識別子が提示され得る。

様々な手法又は手法の組合せを使用して、受取人のリストにポピュレートされ得る。たとえば、クライアント・デバイス１００にとってアクセス可能なアドレス帳又は連絡先のリストから、ユーザ・インターフェース１０６ｂ内の受取人のリストにポピュレートされ得る。そのような状況では、アドレス帳又は連絡先リスト内のエントリが既知の受取人に合致した場合、エントリが受取人のリストに追加され得る。別の例として、受取人がユーザによって手動で追加されていることがある。

図１Ｃは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｃが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、支払人は、ユーザ・インターフェース１０６ｂを使用して選択した受取人に支払うために金額を指定し得る。支払人が金額を指定した後、支払人は、ユーザ・インターフェース１０６ｃを通じて、支払うべき金額を確認し得る。後続のユーザ・インターフェース１０６では、支払人は、取引詳細（たとえば、選択したクレジット・カード、選択した受取人、及び指定の額の資金）を確認し、ユーザのクレジット・カード口座を使用して受取人への支払いを開始し得る。

図１Ｄは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｄが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、支払人は、ユーザ・インターフェース１０６ｄ内で支払人の口座残高及び以前の取引を閲覧し得る。以前の取引の例は、商人との間のクレジット・カード取引、又はユーザ・インターフェース１０６ｂを使用して選択した受取人などの他の個人への直接的支払いを含み得る。それぞれの以前の取引の隣に取引額も表示され得る。

図１Ｅ～１Ｈは、どのように受取人が複数の個人間で取引を割り勘にし、各個人に各自の負担について支払いを要求し得るかという例を示す。図１Ｅ～１Ｈは、どのように受取人が支払いを要求し得るかという例を示すが、他の類似の手法も、本開示の様々な実施形態によって包含される。たとえば、特定の取引又は取引全体を割り勘にするのではなく、受取人は、複数の個人間で割り勘にすべき別の額を指定し、各個人に合計のうちの各自の負担について支払いを要求し得る。別の例として、受取人は、単一の個人に支払いを要求するための金額を指定し得る。

図１Ｅは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｅが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、ユーザ・インターフェース１０６ｅは、ユーザが選択し得る取引のリストを含み得る。たとえば、受取人が特定の購入（たとえば、レストランでの食事、車のためのタンクのガソリン、店からの贈り物など）の費用を割り勘にしたいと望んだ場合、受取人は、ユーザ・インターフェース１０６ｅ内に提示された取引から購入を選択し得る。

図１Ｆは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｆが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、ユーザ・インターフェース１０６ｆは、ユーザ・インターフェース１０６ｅで選択した取引を共に割り勘にすべき個人のリストを含み得る。支払人のリスト内の個々の支払人について、支払人に関連付けられる一意識別子が提示され得る。そのような一意識別子は、携帯電話番号、ｅメール・アドレスなどの支払人の連絡先情報を表し得る。たとえば、支払人が、支払人の電話番号を一意識別子として使用して以前に支払いを受けたことがある場合、支払人の電話番号が提示され得る。複数の一意識別子が同一の支払人に対応付けられる場合、デフォルト識別子が提示され得る。

様々な手法又は手法の組合せを使用して、支払人のリストにポピュレートされ得る。たとえば、クライアント・デバイス１００にとってアクセス可能なアドレス帳又は連絡先のリストから、ユーザ・インターフェース１０６ｆ内の支払人のリストにポピュレートされ得る。そのような状況では、アドレス帳又は連絡先リスト内のエントリが既知の支払人に合致した場合、エントリが支払人のリストに追加され得る。別の例として、支払人がユーザによって手動で追加されていることがある。

図１Ｇは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｇが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、ユーザ・インターフェース１０６ｇは、ユーザ・インターフェース１０６ｆから選択した支払人の間で、ユーザ・インターフェース１０６ｅから選択した取引の費用をどのように割り勘にするかを受取人が指定することを可能にし得る。いくつかの例では、取引の初期の割り勘が提示され得る（たとえば、個人間の均等な割り勘）。しかしながら、任意の一人の個人に要求すべき額が、ユーザ・インターフェース１０６ｇ内で調整され得る。額が決定されると、受取人は、ユーザ・インターフェースと対話して、個人の支払人に資金を要求し得る。

図１Ｈは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｈが、たとえば図１Ｅ～Ｇに示されるように要求された支払いのステータスを受取人が確認することを可能にするように、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、一つ又は複数の保留中の支払いが、ユーザ・インターフェース１０６ｈ内で受取人に提示され得る。たとえば、ユーザ・インターフェース１０６ｇを通じて特定の取引について受取人が一人又は複数の個人に資金を要求した後、受取人は、ユーザ・インターフェース１０６ｈ内の保留中の支払いのリストを閲覧することによって、どの支払人が支払ったか否か、又はどの支払人が支払いを保留にしているかを閲覧することができ得る。

図１Ｉ～１Ｍは、他者のクレジット・カード口座からユーザに支払われた資金をユーザがどのように請求し、又は受け取ることができるかという例を示す。たとえば、図１Ａ～１Ｈに示されるワークフローの結果として受取人が資金の支払いを受け取った場合、受取人は、一つ又は複数の図１Ｉ～１Ｍに示されるように、一つ又は複数のユーザ・インターフェース１０６と対話し得る。

図１Ｉは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｉが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、受取人は、資金が受取人に送られており、利用可能であることを示すメッセージを受け取っている。資金を請求するために、受取人はリンクを選択し得る。

図１Ｊは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｊが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、受取人は、ユーザ・インターフェース１０６ｉ内で先に提示されたリンクを選択していることがあり得、受取人が複数の金融機関から金融機関を選択することを可能にするユーザ・インターフェース１０６ｊの提示を受ける。受取人は、受取人が受け取ることになる資金を預けることを望む口座を受取人が有する金融機関を選択し得る。

図１Ｋは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｋが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、受取人は、先に選択した金融機関との間で認証するための認証インターフェースの提示を受ける。たとえば、受取人は、ユーザ・インターフェース１０６ｊ内で提供されたリストから金融機関を先に選択していることがある。

図１Ｌは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｌが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、ユーザ・インターフェース１０６ｌは、選択した金融機関内の口座及び口座残高のリストを受取人に提供し得る。受取人は、ユーザ・インターフェース１０６ｋを使用して認証が成功したことに応答して、ユーザ・インターフェース１０６ｌの提示を受け得る。ユーザ・インターフェース１０６ｌ内で、受取人は、受取人が資金を預けることを望む口座のうちの一つを選択することができ得る。

図１Ｍは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｍが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、ユーザ・インターフェース１０６ｍは、受取人が取引を検討することを可能にするための確認ステップを提供する。これは、たとえば、預けられることになる金額、資金が預けられる口座、及び資金を支払っている個人を含み得る。情報を検討した後は、受取人は、ユーザ・インターフェース１０６ｍを使用して、取引を確認し、資金を受け入れることができ得る。次いで、後で論じるように、受取人の口座に資金が預けられ得る。

しかしながら、いくつかの代替実装では、受取人は、受取人の金融機関との間で認証するように促されないことがある。たとえば、受取人は、図１Ｊで受取人の金融機関を選択した後に、受取人の口座番号を入力するように促され得る。これらのシナリオでは、図１Ｍに示されるように、受取人が受取人の口座情報を提供し、預金を確認した後に、資金が自動的に預けられ得る。

図１Ｎ～１Ｒは、他者のクレジット・カード口座に資金を支払うようにという要求にどのようにユーザが同意し得るかという例を示す。たとえば、図１Ｅ～１Ｈに示されるワークフローの結果として、支払人が資金を支払うようにという要求を受信した場合、支払人は、一つ又は複数の図１Ｎ～１Ｒに示されるように、一つ又は複数のユーザ・インターフェース１０６と対話し得る。

図１Ｎは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６Ｎが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、支払人は、別の個人が支払いを要求していることを示すメッセージを受信している。支払い要求に同意するために、支払人はリンクを選択し得る。

図１Ｏは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｏが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、支払人は、ユーザ・インターフェース１０６ｎ内で先に提示されたリンクを選択していることがあり得、支払人が複数の金融機関から金融機関を選択することを可能にするユーザ・インターフェース１０６ｏの提示を受ける。支払人は、支払い要求を履行するために支払人が資金を引き出すことを望む口座を支払人が有する金融機関を選択し得る。

図１Ｐは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｐが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、支払人は、先に選択した金融機関との間で認証するための認証インターフェースの提示を受ける。たとえば、支払人は、ユーザ・インターフェース１０６ｏ内で提供されたリストから金融機関を先に選択していることがある。

図１Ｑは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｑが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、ユーザ・インターフェース１０６ｑは、選択した金融機関内の口座及び口座残高のリストを支払人に提供し得る。支払人は、ユーザ・インターフェース１０６ｐを使用して認証が成功したことに応答して、ユーザ・インターフェース１０６ｌの提示を受け得る。ユーザ・インターフェース１０６ｑ内で、支払人は、支払い要求を履行するために支払人が資金を引き出すことを望む口座のうちの一つを選択することができ得る。

図１Ｒは、本開示の様々な実施形態によるディスプレイ１０３を備えるクライアント・デバイス１００を示す。ユーザ・インターフェース１０６ｒが、クライアント・デバイス１００のディスプレイ１０３上にレンダリングされ得る。図示されるように、ユーザ・インターフェース１０６ｒは、支払人が取引を検討することを可能にするための確認ステップを提供する。これは、たとえば、引き出されることになる金額、資金が引き出されることになる口座、及び資金が支払われることになる個人を含み得る。情報を検討した後は、支払人は、ユーザ・インターフェース１０６ｒを使用して、取引を確認し、資金を受け入れることができ得る。次いで、後で論じるように、受取人の口座に資金が預けられ得る。

図２を参照すると、様々な実施形態によるネットワーク環境２００が示されている。ネットワーク環境２００は、イシュア・コンピューティング環境２０３、ピア・コンピューティング環境２０６、インテグレータ・コンピューティング環境２０９、及びクライアント・デバイス１００を含み得る。イシュア・コンピューティング環境２０３は、クレジット・カード口座の形で顧客の代わりにクレジットを発行する金融機関であるクレジット・カード・イシュアによって、又はクレジット・カード・イシュアの代わりに運用され得る。ピア・コンピューティング環境２０６は、クレジット・カード・イシュアとの間のクレジット・カード口座の所有者が支払いを送り、又は支払いを受け取ることを望む顧客を有する金融機関であるピア金融機関によって、又はピア金融機関の代わりに運用され得る。インテグレータ・コンピューティング環境２０９は、様々な銀行を有する顧客が様々な機関の顧客の口座を単一のアプリケーション又はサービスに統合することを可能にするプロトコル、ツール、又はアプリケーション・プログラミング・インターフェースの共通セットを提供する機関である金融サービスインテグレータの代わりに運用され得る。イシュア・コンピューティング環境２０３、ピア・コンピューティング環境２０６、インテグレータ・コンピューティング環境２０９、及びクライアント・デバイス１００は、ネットワーク２１３を介して互いにデータ通信し得る。

ネットワーク２１３は、広域ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、パーソナル・エリア・ネットワーク（ＰＡＮ）、又はそれらの組合せを含み得る。これらのネットワークは、ワイヤード又はワイヤレス構成要素、或いはそれらの組合せを含み得る。ワイヤード・ネットワークは、イーサネット・ネットワークと、ケーブル・ネットワークと、光ファイバ・ネットワークと、ダイヤルアップ・ネットワーク、デジタル加入者線（ＤＳＬ）ネットワーク、統合サービス・デジタル・ネットワーク（ＩＳＤＮ）ネットワークなどの電話ネットワークとを含み得る。ワイヤレス・ネットワークは、セルラ・ネットワーク、サテライト・ネットワーク、Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃ Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ） ８０２．１１ワイヤレス・ネットワーク（すなわちＷＩ－ＦＩ（登録商標））、ＢＬＵＥＴＯＯＴＨ（登録商標）ネットワーク、マイクロ波伝送ネットワーク、並びに無線ブロードキャストに依拠する他のネットワークを含み得る。ネットワーク２１３はまた、二つ以上のネットワーク２１３の組合せをも含み得る。ネットワーク２１３の例は、インターネット、イントラネット、エクストラネット、仮想プライベート・ネットワーク（ＶＰＮ）、及び類似のネットワークを含み得る。

イシュア・コンピューティング環境２０３、ピア・コンピューティング環境２０６、及びインテグレータ・コンピューティング環境２０９は、プロセッサ、メモリ、及び／又はネットワーク・インターフェースを含む一つ又は複数のコンピューティング・デバイスを含み得る。たとえば、コンピューティング・デバイスは、他のコンピューティング・デバイス又はアプリケーションの代わりに計算を実施するように構成され得る。別の例として、そのようなコンピューティング・デバイスは、コンテンツをホストし、且つ／又はコンテンツを求める要求に応答して他のコンピューティング・デバイスにコンテンツを提供し得る。

更に、イシュア・コンピューティング環境２０３、ピア・コンピューティング環境２０６、及びインテグレータ・コンピューティング環境２０９は、一つ又は複数のサーバ・バンク、或いはコンピュータ・バンク、或いは他の構成で構成され得る複数のコンピューティング・デバイスを利用し得る。そのようなコンピューティング・デバイスは、単一の設備内に配置され得、又は多くの異なる地理的位置の間で分散され得る。たとえば、イシュア・コンピューティング環境２０３、ピア・コンピューティング環境２０６、又はインテグレータ・コンピューティング環境２０９は、ホストされるコンピューティング・リソース、グリッド・コンピューティング・リソース、又は任意の他の分散コンピューティング構成を共に含み得る複数のコンピューティング・デバイスを含み得る。いくつかのケースでは、イシュア・コンピューティング環境２０３、ピア・コンピューティング環境２０６、又はインテグレータ・コンピューティング環境２０９は、処理、ネットワーク、ストレージ、又は他のコンピューティング関連リソースの割り振られる容量が経時的に変動し得るエラスティック・コンピューティング・リソースに対応し得る。

様々なアプリケーション又は他の機能が、様々な実施形態にしたがってイシュア・コンピューティング環境２０３内で実行され得る。イシュア・コンピューティング環境２０３上で実行される構成要素は、イシュア支払いサービス２１６、並びに本明細書では詳細には論じない他のアプリケーション、サービス、プロセス、システム、エンジン、又は機能を含み得る。

イシュア支払いサービス２１６は、イシュアとの間のクレジット・カード口座を有する顧客の代わりに資金移転を処理するように実行され得る。たとえば、イシュア支払いサービス２１６は、顧客のクレジット・カード口座から、別の金融機関に金融口座を有する商人又は顧客への資金の支払いを処理し得る。別の例として、イシュア支払いサービス２１６は、イシュアとの間のクレジット・カード口座を有する顧客の代わりに資金を受け取り、顧客のクレジット・カード口座残高に資金を入金し得る。

更に、イシュア・コンピューティング環境２０３にとってアクセス可能であるイシュア・データ・ストア２１９内に様々なデータが記憶される。イシュア・データ・ストア２１９は複数のデータ・ストアを表し得、複数のデータ・ストアは、リレーショナル・データベース、オブジェクト指向データベース、階層データベース、ハッシュ・テーブル、又は類似のキー－値データ・ストア、並びに他のデータ・ストレージ・アプリケーション又はデータ構造を含み得る。イシュア・データ・ストア２１９内に記憶されたデータは、以下で説明する様々なアプリケーション又は機能エンティティの動作に関連付けられる。このデータは、被支払人ディレクトリ２２１ａエスクロー口座２２３ａ、一つ又は複数のクレジット・ユーザ口座２２６、機関識別子２２９ａ、及び潜在的には他のデータを含み得る。

被支払人ディレクトリ２２１ａなどの被支払人ディレクトリ２２１は、資金の被支払人又は受取人のディレクトリを表し得る。たとえば、電話番号、ｅメール・アカウントなどの個人についての任意の一意識別子について、以前の取引で使用された機関識別子２２９及び／又はクレジット口座識別子２３６又は金融口座識別子２４９を識別する被支払人ディレクトリ２２１ａ内にレコードが記憶され得る。その結果、同一の被支払人に対する後続の支払いが、どこに資金を送るかを決定するために被支払人ディレクトリ２２１ａを参照するイシュア支払いサービス２１６によって速められ得る。

エスクロー口座２２３ａなどのエスクロー口座２２３は、クレジット・カード口座と他の金融口座との間で移転される資金の一時的保管のためにクレジット・カード・イシュアによって運用される金融口座を表し得る。たとえば、クレジット・カード所有者がピア金融機関の顧客の金融口座から資金を受け取るとき、資金がエスクロー口座２２３ａ内に預けられ得る。次いで、顧客のクレジット・カード口座に入金が適用され得る。

エスクロー口座２２３ａの使用は、クレジット・カード口座が、クレジット・カード協会（たとえば、ＶＩＳＡ（登録商標）、ＭＡＳＴＥＲＣＡＲＤ（登録商標）、ＤＩＳＣＯＶＥＲ（登録商標）、ＤＩＮＥＲ ＣＬＵＢ（登録商標）、ＣＨＩＮＡ ＵＮＩＯＮＰＡＹ（登録商標）、又はＩＮＤＩＡＮ ＲＵＰＡＹ（登録商標））によって運用されるクレジット・カード・ネットワーク以外の銀行間取引ネットワークに参加することを可能にし得る。たとえば、クレジット・カード・イシュアは、クレジット・カード口座所有者の代わりに、エスクロー口座２２３ａから別の金融機関の口座への移転を開始し得る。次いで、クレジット・カード・イシュアは、移転された資金額についてクレジット・カード口座に請求し得る。同様に、クレジット・カード・イシュアは、まずクレジット・カードに請求し、次いで移転を開始し得る。その結果、クレジット・カード口座所有者は、クレジット・カード口座所有者のクレジット・カードを使用して、クレジット・カード・ネットワークを使用する必要なしに、他者に資金を支払い得る。同様に、クレジット・カード・イシュアは、クレジット・カード口座所有者の代わりにエスクロー口座２２３ａへの預金を受け取り、その後で資金をクレジット・カード口座の残高に入金し得、又はその逆である。その結果、クレジット・カード口座所有者は、他者からの支払いを受け入れ、その支払いをクレジット・カード口座所有者のクレジット・カード口座に預け、又は入金し得る。

クレジット・ユーザ口座２２６は、イシュア・コンピューティング環境２０３を運用するイシュアの顧客の口座情報を表し得る。たとえば、少なくとも一つのクレジット・カード口座、チャージ・カード口座、又は類似の直接引落しクレジット口座を有する各顧客が、イシュアとの間のクレジット・ユーザ口座２２６を有し得る。したがって、クレジット・ユーザ口座２２６は、一つ又は複数の認証証明２３３ａと、一つ又は複数のクレジット口座識別子２３６とを含み得る。顧客の名前、連絡先情報（たとえば、メーリング・アドレス、電話番号、又はｅメール・アドレス）などの、顧客についての追加の情報もクレジット・ユーザ口座２２６内に記憶され得る。

認証証明２３３ａなどの認証証明２３３は、口座の所有者の識別を認証又は検証するために使用され得るデータの任意の項目を含み得る。認証証明２３３の例は、ユーザ名、パスワード、個人識別番号（ＰＩＮ）、ワンタイム・パスワード（ＯＴＰ）、認証トークン、暗号鍵対又は証明などを含み得る。所望のセキュリティのレベルに応じて、ユーザは、ユーザの識別を証明するために一つ又は複数の認証証明２３３を提供するように求められ得る（たとえば、２要素認証、多要素認証など）。

クレジット口座識別子２３６は、顧客がイシュアとの間で所有するクレジット口座（たとえば、クレジット・カード口座、チャージ・カード口座など）を識別する任意の一意識別子であり得る。クレジット口座識別子２３６の例は、クレジット又はチャージ・カード番号、他の口座に対してイシュアによって維持される個人口座を一意に識別する、イシュアによって作成された口座番号などの、ペイメント・カード番号を含み得る。顧客がイシュアとの間で複数のクレジット口座を有するとき、顧客は、複数のクレジット口座識別子２３６を顧客のクレジット・ユーザ口座２２６に関連付けさせ得る。たとえば、顧客は、イシュアによって提供されたチャージ・カード口座について第１のクレジット口座識別子２３６を有し、イシュアによって提供されたクレジット・カード口座について第２のクレジット口座識別子２３６を有し得る。

機関識別子２２９ａなどの機関識別子２２９は、資金の移転が金融機関を源とし、又は金融機関を宛先にするものと識別することを可能にする任意の一意識別子を表し得る。したがって、各金融機関は、各金融機関に関連付けられる機関識別子２２９を有し得る。機関識別子２２９の例は、米国銀行協会（ＡＢＡ）ルーティング・トランジット番号（ＲＴＮ）、国際銀行間通信協会（ＳＷＩＦＴ）ビジネス識別子コード（ＢＩＣ）、又は類似の識別子を含む。金融機関が複数の取引又は支払いネットワークに参加する場合、金融機関は複数の機関識別子２２９を有し得る。たとえば、米国内の銀行は、ＡＢＡ ＲＴＮとＳＷＩＦＴ ＢＩＣのどちらも有し得る。

いくつかの例では、機関識別子２２９ａはまた、クレジット口座識別子２３６内に組み込まれ、又はクレジット口座識別子２３６の構成要素であり得る。たとえば、クレジット又はチャージ・カード番号の最初の数桁はしばしば、クレジット又はチャージ・カード口座のイシュアを一意に識別するイシュア識別番号（ＩＩＮ）として働く。

様々なアプリケーション又は他の機能が、様々な実施形態によるピア・コンピューティング環境２０６内で実行され得る。ピア・コンピューティング環境２０６上で実行される構成要素は、ピア支払いサービス２３９、並びに本明細書では詳細には論じない他のアプリケーション、サービス、プロセス、システム、エンジン、又は機能を含み得る。

ピア支払いサービス２３９は、ピア機関との間で金融口座を有する顧客の代わりに資金移転を処理するように実行され得る。たとえば、ピア支払いサービス２３９は、宛先として金融口座を識別した銀行間支払いネットワークを通じて資金移転を受け取り、ピア機関によって維持される金融口座に資金を入金し得る。ピア支払いサービス２３９は、銀行間支払いネットワークを通じて、同一又は別の機関の口座への資金移転を開始し、ピア機関によって維持される金融口座から資金を引き落とし得る。ピア機関によって維持される金融口座は、預金及び／又は引出しを要求時に行うことが許可される任意の口座を含み得る。金融口座の例は、取引口座（たとえば、当座預金口座（ｃｈｅｃｋｉｎｇ ａｃｃｏｕｎｔ、ｃｕｒｒｅｎｔ ａｃｃｏｕｎｔ）、要求払い口座など）、普通預金口座、金融市場預金口座、証券口座、ストアド・バリュー口座などを含み得る。

更に、様々なデータが、ピア・コンピューティング環境２０６にとってアクセス可能であるピア・データ・ストア２４３内に記憶される。ピア・データ・ストア２４３は複数のデータ・ストアを表し得、複数のデータ・ストアは、リレーショナル・データベース、オブジェクト指向データベース、階層データベース、ハッシュ・テーブル、又は類似のキー－値データ・ストア、並びに他のデータ・ストレージ・アプリケーション又はデータ構造を含み得る。ピア・データ・ストア２４３内に記憶されたデータは、以下で説明する様々なアプリケーション又は機能エンティティの動作に関連付けられる。このデータは、被支払人ディレクトリ２２１ｂ、エスクロー口座２２３ｂ、一つ又は複数のピア・ユーザ口座２４６、ピア機関についての機関識別子２２９ｂ、及び潜在的には他のデータを含み得る。

ピア・ユーザ口座２４６は、ピア・コンピューティング環境２０６を運用するピア金融機関の顧客の口座情報を表し得る。たとえば、ピア金融機関との間で少なくとも一つの金融口座を有する各顧客は、ピア・ユーザ口座２４６を有し得る。したがって、ピア・ユーザ口座２４６は、一つ又は複数の認証証明２３３ｂと、一つ又は複数の金融口座識別子２４９とを含み得る。口座残高２５３（たとえば、現在口座内にある資金の額）などの各金融口座についての情報も、ピア・ユーザ口座２４６に関連付けて記憶され得る。顧客の名前、連絡先情報（たとえば、メーリング・アドレス、電話番号、又はｅメール・アドレス）などの、顧客についての追加の情報も記憶され得る。

金融口座識別子２４９は、ピア金融機関によって維持される任意の金融口座についての一意識別子である。これらは、ピア金融機関によって内部で作成された口座番号、国際銀行口座番号（ＩＢＡＮｓ）、又は個々の金融口座間を区別するための類似の識別子を含み得る。

様々なアプリケーション又は他の機能が、様々な実施形態にしたがってインテグレータ・コンピューティング環境２０９内で実行され得る。インテグレータ・コンピューティング環境２０９上で実行される構成要素は、インテグレータ・サービス２５６、本明細書では詳細には論じない他のアプリケーション、サービス、プロセス、システム、エンジン、又は機能を含む。

インテグレータ・サービス２５６は、イシュア又はピア金融機関によって維持されるクレジット口座又は金融口座を、アプリケーション又は他の機関と統合し、或いは結び付けるために実行され得る。たとえば、インテグレータ・サービス２５６は、ユーザがイシュア支払いサービス２１６又はピア支払いサービス２３９との間で認証することを可能にするウェブ・ページ、ポータル、又はアプリケーションを提供し得る。認証が行われた後、インテグレータ・サービス２５６は、クレジット・ユーザ口座２２６又はピア・ユーザ口座２４６から情報（たとえば、口座番号及び機関識別子２２９）を取り出し、ユーザによって許可される別のサービス、アプリケーション、又は機関に情報を中継し得る。

イシュア支払いサービス２１６及びピア支払いサービス２３９とは別々に、独立して示されているが、インテグレータ・サービス２５６は、ピア支払いサービス２３９又はイシュア支払いサービス２１６のどちらかと同一のエンティティによって、或いはピア支払いサービス２３９又はイシュア支払いサービス２１６のどちらかと一緒に運用され得る。これらの実装では、イシュア支払いサービス２１６又はピア支払いサービス２３９のどちらかによって実施されるものとして先に説明した機能の一部が、インテグレータ・サービス２５６によって実施され得る。同様に、これらの実装では、インテグレータ・サービス２５６によって実施されるものとして説明した機能が、イシュア支払いサービス２１６又はピア支払いサービス２３９のどちらかによって実施され得る。

更に、様々なデータが、インテグレータ・コンピューティング環境２０９にとってアクセス可能であるインテグレータ・データ・ストア２５９内に記憶される。これらのインテグレータ・データ・ストア２５９は、複数のデータ・ストアを表し得、複数のデータ・ストアは、リレーショナル・データベース、オブジェクト指向データベース、階層データベース、ハッシュ・テーブル、又は類似のキー－値データ・ストア、並びに他のデータ・ストレージ・アプリケーション又はデータ構造を含み得る。インテグレータ・データ・ストア２５９内に記憶されたデータは、以下で説明する様々なアプリケーション又は機能エンティティの動作に関連付けられる。このデータは、一つ又は複数の取引レコード２６３、及び潜在的には他のデータを含み得る。

イシュア・データ・ストア２１９及びピア・データ・ストア２４３とは別々に、独立して示されているが、インテグレータ・データ・ストア２５９は、イシュア・データ・ストア２１９とピア・データ・ストア２４３のどちらかと同一のエンティティによって、又はイシュア・データ・ストア２１９とピア・データ・ストア２４３のどちらかと一緒に運用され得る。これらの実装では、インテグレータ・データ・ストア２５９内のデータ・ストアが、イシュア・データ・ストア２１９又はピア・データ・ストア２４３のどちらかの中に記憶され得る。同様に、イシュア・データ・ストア２１９又はピア・データ・ストア２４３内に記憶されたデータが、インテグレータ・データ・ストア２５９内に記憶され得る。

取引レコード２６３は、インテグレータ・サービス２５６によって促進される任意の金融取引を表し得る。これは、たとえば、二つの異なる金融機関によって維持される二つの金融口座間の資金の移転を含み得る。したがって、取引レコード２６３は、取引識別子２６６、取引宛先２６９、及び／又は取引額２７３を含み得る。取引の発生源などの追加の情報も、いくつかの実施形態では取引レコード２６３内に記憶され得る。しかしながら、他の実施形態は、追加の情報を含まないことがあり、又はデータ侵害の場合に顧客へのプライバシー・リスクを最小限に抑えるために、収集される追加の情報量を限定し得る。

取引識別子２６６は、個々の取引レコード２６３間を区別するために使用され得る任意の識別子を含み得る。取引識別子２６６の例は、取引が作成されるときに取引に割り当てられる順次番号、取引レコード２６３のハッシュなどを含み得る。

取引宛先２６９は、取引での資金が預けられる口座及び金融機関を表す。したがって、取引宛先２６９は、機関識別子２２９と口座識別子（たとえば、クレジット口座識別子２３６又は金融口座識別子２４９）のどちらも含み得る。

取引額２７３は、取引又は移転に関係する資金の合計額を表し得る。いくつかの実装では、取引額２７３は、ある口座から別の口座に移転される資金額を表し得る。他の実装では、追加のフィー又は料金（たとえば、プロセシング・フィー又はインターチェンジ・フィー）も取引額２７３に含まれ得る。

クライアント・デバイス１００は、ネットワーク２１３に結合され得る複数のクライアント・デバイス１００を表す。クライアント・デバイス１００は、コンピュータ・システムなどのプロセッサ・ベースのシステムを含み得る。そのようなコンピュータ・システムは、パーソナル・コンピュータ（たとえば、デスクトップ・コンピュータ、ラップトップ・コンピュータ、又は類似のデバイス）、モバイル・コンピューティング・デバイス（たとえば、携帯情報端末、セルラ電話、スマートフォン、ウェブ・パッド、タブレット・コンピュータ・システム、音楽プレーヤ、ポータブル・ゲーム・コンソール、電子書籍リーダ、及び類似のデバイス）、メディア再生デバイス（たとえば、メディア・ストリーミング・デバイス、ＢｌｕＲａｙ（登録商標）プレーヤ、デジタル・ビデオ・ディスク（ＤＶＤ）プレーヤ、セットトップ・ボックス、及び類似のデバイス）、ビデオゲーム・コンソール、又は同様の機能を有する他のデバイスの形態で実施され得る。クライアント・デバイス１００は、液晶ディスプレイ（ＬＣＤ）、ガス・プラズマ・ベースのフラット・パネル・ディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、電気泳動インク（「Ｅ－ｉｎｋ」）ディスプレイ、プロジェクタ、又は他のタイプのディスプレイ・デバイスなどの一つ又は複数のディスプレイ１０３を含み得る。いくつかの例では、ディスプレイ１０３はクライアント・デバイス１００の構成要素であり得、或いはワイヤード又はワイヤレス接続を通じてクライアント・デバイス１００に接続され得る。

クライアント・デバイス１００は、クライアント・アプリケーション２７６や他のアプリケーションなどの様々なアプリケーションを実行するように構成され得る。クライアント・アプリケーション２７６は、イシュア・コンピューティング環境２０３、ピア・コンピューティング環境２０６、インテグレータ・コンピューティング環境２０９、又は他のサーバによって提供されるネットワーク・コンテンツにアクセスするように、クライアント・デバイス１００内で実行され得、それによって、ディスプレイ１０３上にユーザ・インターフェース１０６をレンダリングする。この目的で、クライアント・アプリケーション２７６は、ブラウザ、専用アプリケーション、又は他の実行可能ファイルを含み得、ユーザ・インターフェース１０６は、ユーザ入力を取得するためのネットワーク・ページ、アプリケーション画面、又は他のユーザ機構を含み得る。クライアント・デバイス１００は、ｅメール・アプリケーション、ソーシャル・ネットワーキング・アプリケーション、ワード・プロセッサ、スプレッドシート、又は他のアプリケーションなどの、クライアント・アプリケーション２７６以外のアプリケーションを実行するように構成され得る。

次に、ネットワーク環境２００の様々な構成要素の動作の全般的な説明が与えられる。ネットワーク環境２００の様々な構成要素間の対話の一例が以下の段落で与えられるが、他の対話及び動作が可能である。ネットワーク環境２００の構成要素間の様々な対話のより詳細な説明が、後続の図３～８の議論で与えられる。

最初に、支払人は、支払人のクライアント・デバイス１００上で実行中のクライアント・アプリケーション２７６を使用して、イシュア支払いサービス２１６に要求を送り得る。要求は、受取人についての連絡先情報、受取人に支払う金額、及び受取人に支払うために使用するクレジット口座又はチャージ口座を指定し得る。したがって、要求は、受取人についてのセルラ電話番号又はｅメール・アドレス、取引額２７３、及びクレジット口座識別子２３６を含み得る。

次いで、イシュア支払いサービス２１６は、取引識別子２６６を求めてインテグレータ・サービス２５６に要求を送り得る。それに応答して、インテグレータ・サービス２５６は、取引識別子２６６を含む取引レコード２６３を作成し得る。次いで、インテグレータ・サービス２５６は、イシュア支払いサービス２１６に取引識別子２６６を返し得る。

次に、イシュア支払いサービス２１６は、受取人のクライアント・デバイス１００にメッセージを送り得る。たとえば、イシュア支払いサービス２１６は、支払人によって提供された受取人についての連絡先情報にショート・メッセージ・サービス（ＳＭＳ）メッセージ又はｅメールを送り得る。メッセージは、支払人が受取人に資金を送っているという通知を含み得る。メッセージはまた、取引識別子２６６と、インテグレータ・サービス２５６によって提供されるウェブ・ページ又はインターフェースへのリンクとを含み得る。受取人が資金を請求することを望む場合、受取人は、リンクをクリックし、選択し、或いはたどり得る。

受取人がリンクをたどった後は、インテグレータ・サービス２５６は、ウェブ・ページ又は類似のユーザ・インターフェース１０６を受取人に提供し得る。ユーザ・インターフェース１０６内で、受取人は、サポートされる金融機関のリストから受取人の金融機関を選択し得る。次いで、受取人は、選択した金融機関との間の受取人のピア・ユーザ口座２４６についての受取人の認証証明２３３ｂを提供し得る。次いで、インテグレータ・サービス２５６は、受取人の代わりに、選択した金融機関との間で認証し、金融口座識別子２４９のリストを取り出し得る。次いで、インテグレータ・サービス２５６は、ユーザ・インターフェース１０６を更新して、受取人が資金を受け取ることを望む金融口座についての金融口座識別子２４９を選択するように受取人に促し得る。

受取人が金融口座識別子２４９を選択した後は、インテグレータ・サービス２５６は、金融口座識別子２４９及び機関識別子２２９ｂをイシュア支払いサービス２１６に提供し得る。インテグレータ・サービス２５６はまた、金融口座識別子２４９及び機関識別子２２９ｂが関連付けられるのはどの個人取引かを複数の取引から識別する際にイシュア支払いサービス２１６を援助するために、取引識別子２６６をも提供し得る。

金融口座識別子２４９及び機関識別子２２９ｂの受信時に、イシュア支払いサービス２１６は、銀行間取引ネットワークを使用して移転を開始し、資金を受取人の口座内に配置し得る。いくつかのタイプの転送では、資金がエスクロー口座２２３ａから受取人の口座に移転され得る。他のタイプの転送では、資金がエスクロー口座２２３ａと２２３ｂとの間で移転され得る。次いで、イシュア支払いサービス２１６は、支払人のクレジット口座に割り当てられた与信限度を削減し得る。いくつかの実装では、与信限度が、支払人のクレジット口座から直ちに、又はほぼ直ちに削減され得る。他の実装では、移転が完了したという指示又は確認をイシュア支払いサービス２１６が受け取った後に与信限度が削減され得る。移転が行われる前に与信限度が削減され得る実装もあり得る。そのような実装は、後になるまで資金の移転が機関間で決済されない場合であっても、資金の即時移転の効果を可能にし得る。

同様に、受取人は、受取人のクライアント・デバイス１００上で実行中のクライアント・アプリケーション２７６を使用して、別の個人が受取人に支払うことを求めてイシュア支払いサービス２１６に要求を送り得る。要求は、受取人についての連絡先情報、支払人が受取人に支払うように受取人が要求している金額、及び資金が預けられるべき受取人のクレジット口座のクレジット口座識別子２３６を指定し得る。したがって、要求は、受取人についてのセルラ電話番号又はｅメール・アドレス、取引額２７３、及び受取人のクレジット口座識別子２３６を含み得る。

次いで、イシュア支払いサービス２１６は、取引識別子２６６を求めてインテグレータ・サービス２５６に要求を送り得る。それに応答して、インテグレータ・サービス２５６は、取引識別子２６６を含む取引レコード２６３を作成し得る。次いで、インテグレータ・サービス２５６は、イシュア支払いサービス２１６に取引識別子２６６を返し得る。

次に、イシュア支払いサービス２１６は、支払人のクライアント・デバイス１００にメッセージを送り得る。たとえば、イシュア支払いサービス２１６は、受取人によって提供された支払人についての連絡先情報にショート・メッセージ・サービス（ＳＭＳ）メッセージ又はｅメールを送り得る。メッセージは、受取人が支払人に資金を要求しているという通知を含み得る。メッセージはまた、取引識別子２６６と、インテグレータ・サービス２５６によって提供されるウェブ・ページ又はインターフェースへのリンクとを含み得る。支払人が要求された資金を送ることを望む場合、支払人は、リンクをクリックし、選択し、或いはたどり得る。

支払人がリンクをたどった後は、インテグレータ・サービス２５６は、ウェブ・ページ又は類似のユーザ・インターフェース１０６を支払人に提供し得る。ユーザ・インターフェース１０６内で、支払人は、サポートされる金融機関のリストから支払人の金融機関を選択し得る。次いで、支払人は、選択した金融機関との間の支払人のピア・ユーザ口座２４６についての支払人の認証証明２３３ｂを提供し得る。次いで、インテグレータ・サービス２５６は、支払人の代わりに、選択した金融機関との間で認証し、金融口座識別子２４９のリストを取り出し得る。次いで、インテグレータ・サービス２５６は、ユーザ・インターフェース１０６を更新して、要求された資金を支払人がそこから受取人に送ることを望む金融口座についての金融口座識別子２４９を選択するように支払人に促し得る。支払人が金融口座識別子２４９を選択した後は、インテグレータ・サービス２５６は、ピア機関についての金融口座識別子２４９及び機関識別子２２９ｂをイシュア支払いサービス２１６に送り得る。インテグレータ・サービス２５６はまた、金融口座識別子２４９及び機関識別子２２９ｂが関連付けられるのはどの個人取引かを複数の取引から識別する際にイシュア支払いサービス２１６を援助するために、取引識別子２６６をも提供し得る。

金融口座識別子２４９及び機関識別子２２９ｂの受信時に、イシュア支払いサービス２１６は、資金の移転を開始するようにピア支払いサービス２３９に要求を送り得る。要求は、イシュア支払いサービス２１６に関連付けられる機関識別子２２９ａと、エスクロー口座２２３ａについての口座番号又は識別子とを含み得る。要求はまた、移転に関連付けられる取引識別子２６６、又は資金が支払われることになる金融口座識別子２４９をも含み得る。

それに応答して、ピア支払いサービス２３９は、支払人の口座又はエスクロー口座２２３ｂからエスクロー口座２２３ａへの機関資金移転を開始し得る。イシュア支払いサービス２１６が資金の受信を確認した後は、クレジット口座識別子２３６によって識別される受取人のクレジット口座に入金が適用され得る。しかしながら、いくつかの実装では、機関資金移転の開始前にクレジット口座に入金が適用され得る。これは、後になるまで資金の移転が機関間で決済されない場合であっても、受取人又は支払人が即時又はリアル・タイムの資金移転を受けることを可能にし得る。

これらの例のいずれでも、多くのタイプの移転がイシュア支払いサービス２１６又はピア支払いサービス２３９によって使用され得る。たとえば、資金の即時移転を実現するために即時グロス決済（ＲＴＧＳ）システムが使用され得る。ＲＴＧＳシステムの例は、Ｆｅｄｗｉｒｅなどのワイヤ移転システムを含む。しかしながら、資金移転が時間に敏感でない場合、バッチ処理されるネット決済システムが使用され得る。バッチ処理されるネット決済システムの例は、ＦｅｄＡＣＨや電子支払いネットワーク（ＥＰＮ）などの自動決済機関（ＡＣＨ）ネットワークを含む。

次に図３を参照すると、クレジット・カード・イシュアとピア金融機関との間で資金を移転するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。図３のシーケンス図は、ネットワーク環境２００内の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図３のシーケンス図を、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。

ボックス３０１から始めて、クライアント・アプリケーション２７６ａが、受取人に資金を支払うようにという要求をイシュア支払いサービス２１６に送り得る。要求は、資金がそこから支払われるべきであるクレジット口座識別子２３６、支払われるべき資金額、受取人についての連絡先情報の識別（たとえば、電話番号又はｅメール・アドレス）、及び潜在的には他の情報を含み得る。

ボックス３０３に移ると、イシュア支払いサービス２１６は取引を許可し得る。たとえば、イシュア支払いサービス２１６は、クレジット口座識別子２３６に関連付けられる与信限度が、受取人への資金の支払いを可能にするのに十分な与信額を有するかどうかを評価し得る。イシュア支払いサービス２１６が取引を許可しない場合、対話のシーケンスは停止し得る。

次いでボックス３０６で、イシュア支払いサービス２１６は、取引識別子２６６を求めてインテグレータ・サービス２５６に要求を送り得る。それに応答して、インテグレータ・サービス２５６は取引識別子２６６を生成し、取引識別子２６６をイシュア支払いサービス２１６に提供し得る。イシュア支払いサービス２１６は、イシュア支払いサービス２１６が、クレジット口座識別子２３６によって識別される、支払人のクレジット口座から資金を支払うようにという要求を後で決定し、又はそれをピア金融サービスによって維持される金融口座に対応付けることを可能にするために、一時的に取引識別子２６６を記憶し得る。

次にボックス３０９で、イシュア支払いサービス２１６は受取人に支払い要求メッセージを送り得る。たとえば、支払人がボックス３０１で受取人についての携帯電話番号を提供した場合、イシュア支払いサービス２１６は、受取人のクライアント・デバイス１００にショート・メッセージ・サービス（ＳＭＳ）メッセージを送り得る。別の例として、支払人がボックス３０３で受取人についてのｅメール・アドレスを提供した場合、イシュア支払いサービス２１６は、受取人についてのｅメール・アドレスにｅメールを送り得る。

しかしながら、いくつかの実装では、ボックス３０９の機能がインテグレータ・サービス２５６によって実施され得る。たとえば、取引識別子２６６を作成した後、インテグレータ・サービス２５６は受取人に支払い要求メッセージを送り得る。これらの実装では、イシュア支払いサービス２１６は、ボックス３０６で、関係する連絡先情報（たとえば、電話番号又はｅメール・アドレス）をインテグレータ・サービス２５６に提供していることになる。

支払い要求メッセージはいくつかの項目を含み得る。たとえば、支払い要求メッセージは、インテグレータ・サービス２５６についてのアドレスと、取引識別子２６６とを含むユニフォーム・リソース・インジケータ（ＵＲＩ）を含み得る。支払い要求メッセージは、支払人が受取人に資金を送っているというメッセージ又は指示、資金額、支払人の識別などを更に含み得る。

その後で、ボックス３１３で、クライアント・アプリケーション２７６ｂは受取人を認証し、資金が預けられることになる金融口座識別子２４９の識別又は選択を受取人から取得し得る。たとえば、受取人が支払い要求メッセージ内に含まれるリンクを選択したとき、クライアント・デバイス１００は、クライアント・アプリケーション２７６ｂを開き、インテグレータ・サービス２５６に要求を送るようにクライアント・アプリケーション２７６ｂに指示し得る。要求は、ボックス３０９で先に送られたＵＲＩ内に含まれる取引識別子２６６を含み得る。

次いで、インテグレータ・サービス２５６は、クライアント・アプリケーション２７６ｂへの応答を提供し、受取人の金融機関を識別するように受取人に促し得る。この応答は、たとえば、受取人が金融機関を選択することを可能にするように、クライアント・アプリケーション２７６ｂにユーザ・インターフェース１０６をレンダリングさせ得る。受取人が金融機関を選択した後、インテグレータ・サービス２５６は、受取人から認証証明２３３ｂを取得するようにクライアント・アプリケーション２７６ｂに促し得る。

受取人がインテグレータ・サービス２５６に認証証明２３３ｂを供給した後、インテグレータ・サービス２５６は、受取人の代わりにピア支払いサービス２３９との間で認証し得る。認証されると、インテグレータ・サービス２５６は、受取人に関連付けられるピア支払いサービス２３９に金融口座識別子２４９のリストを要求し得る。次いで、インテグレータ・サービス２５６は、支払人からの資金が預けられるべき口座を選択するために、受取人についてのクライアント・アプリケーション２７６ｂに金融口座識別子２４９（たとえば、当座預金口座、普通預金口座などについての口座番号）のリストを提供し得る。受取人が金融口座識別子２４９を選択した後は、クライアント・アプリケーション２７６ｂは、インテグレータ・サービス２５６に金融口座識別子２４９を提供し得る。たとえば、受取人がクライアント・アプリケーション２７６ｂ内から受取人の当座預金口座を選択した場合、クライアント・アプリケーション２７６ｂは、インテグレータ・サービス２５６に、選択した口座として金融口座識別子２４９を提供し得る。

次にボックス３１６で、インテグレータ・サービス２５６は、選択した金融口座識別子２４９と、金融口座識別子２４９によって識別された口座を維持するピア金融機関についての機関識別子２２９ｂとをイシュア支払いサービス２１６に提供し得る。たとえば、ボックス３１３で、受取人がＥｘａｍｐｌｅＢａｎｋとの間で認証し、資金が預けられるべき口座としてＥｘａｍｐｌｅＢａｎｋの受取人の当座預金口座を選択した場合、インテグレータ・サービス２５６は、ＥｘａｍｐｌｅＢａｎｋのＡＢＡルーティング番号と、ＥｘａｍｐｌｅＢａｎｋの受取人の当座預金口座番号とを提供し得る。インテグレータ・サービス２５６はまた、金融口座識別子２４９及び機関識別子２２９ｂがどの支払いに関連付けられるべきかをイシュア支払いサービス２１６が決定することを可能にするように、ボックス３１６で取引識別子２６６を返し得る。

次いでボックス３１９で、イシュア支払いサービス２１６は、エスクロー口座２２３ａから、受取人の金融口座への、又はピア金融機関のエスクロー口座２２３ｂへの資金の移転を開始し得る。たとえば、イシュア支払いサービス２１６は、エスクロー口座２２３ａからのＡＣＨ支払いを開始し、ボックス３１６ａで提供された金融口座識別子２４９及び機関識別子２２９ｂによって識別される、受取人のピア金融機関の金融口座を指定し得る。別の例として、イシュア支払いサービス２１６は、エスクロー口座２２３ａからのワイヤ移転支払いを開始し得、受取人のピア金融機関の金融口座を指定する。しかしながら、イシュア支払いサービス２１６は、任意のバッチ処理されるネット決済又は即時グロス決済支払いシステムを使用して資金を移転し得る。

その後で、ボックス３２３で、イシュア支払いサービス２１６は、エスクロー口座２２３ａからピア金融機関によって維持される受取人の金融口座に移転された資金額に等しい額を、支払人のクレジット口座内の利用可能な与信額から差し引き得る。これは、イシュアの代わりに移転された資金額について、イシュアに対する支払人の負債を生み出し得る。その結果、支払人は、クレジット・カード取引ネットワークを使用する必要なしに、他者（たとえば、別の個人）に対する支払人のクレジット口座（たとえば、クレジット・カード）からの支払いを行わせることができる。一方、ボックス３２６で、ピア支払いサービス２３９は、イシュアから受け取った資金を受取人の金融口座に入金し、或いは預け得る。ボックス３２３及び３２６で示される機能が、シーケンス図中のより前で実装され得ることに留意されたい。たとえば、ボックス３１６での口座情報の移転のボックス３１９での資金の移転前に、それぞれの入金及び引落しが行われ得る。

次に図４を参照すると、第１のクレジット・イシュアと第２のクレジット・イシュア（たとえば、クレジット・カード・イシュア）との間で資金を移転するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。図４のシーケンス図は、ネットワーク環境２００内の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図４のシーケンス図を、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。

ボックス３０３に類似するボックス４０３から始めて、クライアント・アプリケーション２７６ａが、受取人に資金を支払うようにという要求をイシュア支払いサービス２１６ａに送り得る。要求は、資金がそこから支払われるべきであるクレジット口座識別子２３６、支払われるべき資金額、受取人についての連絡先情報の識別（たとえば、電話番号又はｅメール・アドレス）、及び潜在的には他の情報を含み得る。

ボックス３０６に類似するボックス４０６で、イシュア支払いサービス２１６ａは、取引識別子２６６を求めてインテグレータ・サービス２５６に要求を送り得る。それに応答して、インテグレータ・サービス２５６は取引識別子２６６を生成し、取引識別子２６６をイシュア支払いサービス２１６ａに提供し得る。イシュア支払いサービス２１６ａは、イシュア支払いサービス２１６ａが、クレジット口座識別子２３６によって識別される、支払人のクレジット口座から資金を支払うようにという要求を後で決定し、又はそれを別のイシュアによって維持されるクレジット口座に対応付けることを可能にするために、一時的に取引識別子２６６を記憶し得る。

次に、ボックス３０９に類似するボックス４０９で、イシュア支払いサービス２１６ａは受取人に支払い要求メッセージを送る。たとえば、支払人がボックス４０３で受取人についての携帯電話番号を提供した場合、イシュア支払いサービス２１６ａは、受取人のクライアント・デバイス１００にショート・メッセージ・サービス（ＳＭＳ）メッセージを送り得る。別の例として、支払人がボックス４０３で受取人についてのｅメール・アドレスを提供した場合、イシュア支払いサービス２１６ａは、受取人についてのｅメール・アドレスにｅメールを送り得る。

しかしながら、いくつかの実装では、ボックス４０９の機能がインテグレータ・サービス２５６によって実施され得る。たとえば、取引識別子２６６を作成した後、インテグレータ・サービス２５６は、受取人に支払い要求メッセージを送り得る。これらの実装では、イシュア支払いサービス２１６は、ボックス４０６で、関係する連絡先情報（たとえば、電話番号又はｅメール・アドレス）をインテグレータ・サービス２５６に提供していることになる。

次いで、ボックス３１３に類似するボックス４１３で、クライアント・アプリケーション２７６ｂは受取人を認証し、資金が入金されることになるクレジット口座識別子２３６の識別又は選択を受取人から取得し得る。たとえば、受取人が支払い要求メッセージ内に含まれるリンクを選択したとき、クライアント・デバイス１００は、クライアント・アプリケーション２７６ｂを開き、インテグレータ・サービス２５６に要求を送るようにクライアント・アプリケーション２７６ｂに指示し得る。要求は、ボックス４０９で先に送られたＵＲＩ内に含まれる取引識別子２６６を含み得る。

次いで、インテグレータ・サービス２５６は、クライアント・アプリケーション２７６ｂへの応答を提供し、受取人のクレジット口座（たとえば、クレジット・カード）のイシュアなどの、受取人の金融機関を識別するように受取人に促し得る。この応答は、たとえば、受取人が金融機関を選択することを可能にするように、クライアント・アプリケーション２７６ｂにユーザ・インターフェース１０６をレンダリングさせ得る。受取人が金融機関を選択した後、インテグレータ・サービス２５６は、受取人から認証証明２３３ａを取得するようにクライアント・アプリケーション２７６ｂに促し得る。

受取人がインテグレータ・サービス２５６に認証証明２３３ａを供給した後、インテグレータ・サービス２５６は、受取人の代わりにイシュア支払いサービス２１６ｂとの間で認証し得る。認証されると、インテグレータ・サービス２５６は、受取人に関連付けられるイシュア支払いサービス２１６ｂにクレジット口座識別子２３６のリストを要求し得る。次いで、インテグレータ・サービス２５６は、支払人からの資金が入金されるべき口座を選択するために、受取人についてのクライアント・アプリケーション２７６ｂにクレジット口座識別子２３６（たとえば、当座預金口座、普通預金口座などについての口座番号）のリストを提供し得る。受取人がクレジット口座識別子２３６を選択した後は、クライアント・アプリケーション２７６ｂは、インテグレータ・サービス２５６にクレジット口座識別子２３６を提供し得、インテグレータ・サービス２５６は、選択したクレジット口座識別子２３６をイシュア支払いサービス２１６ｂに中継し得る。たとえば、受取人がクライアント・アプリケーション２７６ｂ内から特定のクレジット・カード口座を選択した場合、クライアント・アプリケーション２７６ｂは、インテグレータ・サービス２５６に、選択した口座としてそれぞれのクレジット・カード番号を提供し得る。次いで、インテグレータ・サービス２５６は、支払人と受取人との間の取引の将来の調整のために、イシュア支払いサービス２１６ｂにこのクレジット・カード番号を提供し得る。

ボックス３１６に類似するボックス４１６で、インテグレータ・サービス２５６は、選択したクレジット口座識別子２３６と、クレジット口座識別子２３６によって識別された口座を維持する受取人の金融機関についての機関識別子２２９ａとをイシュア支払いサービス２１６ａに提供し得る。たとえば、ボックス４１３で、受取人がＥｘａｍｐｌｅＢａｎｋとの間で認証し、資金が入金されるべき口座としてＥｘａｍｐｌｅＢａｎｋの受取人のクレジット・カード口座を選択した場合、インテグレータ・サービス２５６は、ＥｘａｍｐｌｅＢａｎｋのＡＢＡルーティング番号と、ＥｘａｍｐｌｅＢａｎｋによって維持されるエスクロー口座２２３ａの番号とを提供し得る。インテグレータ・サービス２５６はまた、エスクロー口座２２３ａの口座番号及び機関識別子２２９ａがどの支払いに関連付けられるべきかをイシュア支払いサービス２１６が決定することを可能にするように、ボックス４１６で取引識別子２６６を返し得る。

次に、ボックス３１９に類似するボックス４１９で、イシュア支払いサービス２１６ａは、支払人のクレジット・イシュアのエスクロー口座２２３ａから、受取人のクレジット・イシュアのエスクロー口座２２３ａへの資金の移転を開始し得る。先に図２では、イシュア支払いサービス２１６がエスクロー口座２２３ａを有するものとして示されているが、二つの別々のイシュア支払いサービス２１６ａ及び２１６ｂが資金を交換する場合、各イシュア支払いサービス２１６は別々のエスクロー口座２２３ａを有すると理解されたい。たとえば、イシュア支払いサービス２１６ａは、エスクロー口座２２３ａ間のＡＣＨ支払いを開始し得る。別の例として、イシュア支払いサービス２１６ａは、エスクロー口座２２３ａと、受取人についての口座との間のワイヤ移転支払いを開始し得る。しかしながら、イシュア支払いサービス２１６ａは、任意のバッチ処理されるネット決済又は即時グロス決済支払いシステムを使用して資金を移転し得る。同様に、ボックス４２１で、受取人のクレジット・イシュアについてのイシュア支払いサービス２１６ｂは、そのそれぞれのエスクロー口座２２３ａで資金を受け取り得る。

次いで、ボックス３２３に類似するボックス４２３で、イシュア支払いサービス２１６ａは、エスクロー口座２２３ａ間で移転された資金額に等しい額を、支払人のクレジット口座内の利用可能な与信額から差し引き得る。これは、イシュアの代わりに移転された資金額について、支払人のイシュアに対する支払人の負債を生み出し得る。その結果、支払人は、クレジット・カード取引ネットワークを使用する必要なしに、他者（たとえば、別の個人）のクレジット口座に対する支払人のクレジット口座（たとえば、クレジット・カード）からの支払いを行わせることができる。ボックス４２３及び４２６で示される機能が、シーケンス図中のより前で実装され得ることに留意されたい。たとえば、ボックス４１６での口座情報の移転のボックス４１９での資金の移転前に、それぞれの入金及び引落しが行われ得る。

一方、ボックス３２６に類似するボックス４２６で、イシュア支払いサービス２１６ｂは、イシュア支払いサービス２１６ａから受け取った資金を受取人のクレジット口座に入金し得る。したがって、ボックス４２１でエスクロー口座２２３ａで受け取った資金は、受取人のクレジット口座上の受取人の未払残高に対する支払い又は入金として計算される。その結果、受取人は、第３者から預金を受け取ることができ、第３者に支払いを行うことのできる取引口座として受取人のクレジット口座（たとえば、クレジット・カード）を使用することができる。

次に図５を参照すると、同一の機関によって発行されたクレジット口座（たとえば、クレジット・カード）間で資金を移転するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。図５のシーケンス図は、ネットワーク環境２００内の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図５のシーケンス図を、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。

ボックス５０１から始めて、クライアント・アプリケーション２７６ａが、受取人に資金を支払うようにという要求をイシュア支払いサービス２１６に送り得る。要求は、資金がそこから支払われるべきであるクレジット口座識別子２３６、支払われるべき資金額、及び受取人の識別を含み得る。この例では、支払人と受取人は共に同一のイシュアとの間で口座を維持するので、イシュア支払いサービス２１６は受取人についての連絡先情報を既に有し得る。しかしながら、支払人が受取人の好ましい連絡先情報（たとえば、好ましい電話番号又はｅメール・アドレス）を知っている場合、受取人の好ましい連絡先情報も要求内に含まれ得る。

ボックス５０３に進むと、イシュア支払いサービス２１６は取引を許可し得る。たとえば、イシュア支払いサービス２１６は、クレジット口座識別子２３６に関連付けられる与信限度が、受取人への資金の支払いを可能にするのに十分な与信額を有するかどうかを評価し得る。イシュア支払いサービス２１６が取引を許可しない場合、対話のシーケンスは停止し得る。

次にボックス５０６で、イシュア支払いサービス２１６は受取人に支払い要求メッセージを送り得る。たとえば、支払人がボックス５０１で受取人についての携帯電話番号を提供した場合、イシュア支払いサービス２１６は、受取人のクライアント・デバイス１００にショート・メッセージ・サービス（ＳＭＳ）メッセージを送り得る。別の例として、支払人がボックス５０１で受取人についてのｅメール・アドレスを提供した場合、イシュア支払いサービス２１６は、受取人についてのｅメール・アドレスにｅメールを送り得る。メッセージは、たとえば、イシュア支払いサービス２１６によって提供される認証ページへのリンクを含み得る。

次いでボックス５０９で、クライアント・アプリケーション２７６ｂはイシュア支払いサービス２１６との間で認証し得る。たとえば、受取人は、クライアント・アプリケーション２７６ｂのユーザ・インターフェース１０６内に認証証明２３３ａを入力し得、クライアント・アプリケーション２７６ｂは、認証証明２３３ａを使用して、イシュア支払いサービス２１６で受取人を認証し得る。認証に応答して、イシュア支払いサービス２１６は、受取人が選択し得る一つ又は複数のクレジット口座識別子２３６（たとえば、受取人がイシュアとの間で所有するクレジット・カード口座のクレジット・カード口座番号）をクライアント・アプリケーション２７６ｂに提供し得る。次いで、クレジット口座識別子２３６が、クライアント・アプリケーション２７６ｂによってユーザ・インターフェース１０６内で受取人に提示され得、受取人は、支払人から資金を受け取るための口座を選択し得る。次いで、選択したクレジット口座識別子２３６が、イシュア支払いサービス２１６に提供され得る。

しかしながら、いくつかの実装では、ボックス５０６及び／又は５０９は任意選択であり得る。たとえば、受取人が支払人又は他者から以前に支払いを受けたことがある場合、受取人のクレジット口座についてのクレジット口座識別子２３６などの情報が、既に被支払人ディレクトリ２２１ａ内に記憶されていることがある。別の例として、受取人が以前にイシュア支払いサービス２１６との間で口座を作成したことがある場合、受取人の情報も既に被支払人ディレクトリ２２１ａ内に記憶されていることがある。そのような場合、被支払人ディレクトリ２２１ａ内に記憶された情報を使用して、受取人への支払いが、ボックス５０３からボックス５１３及び５１６に直ちに進み得る。

ボックス５１３及び５１６では、支払人及び受取人のクレジット口座の口座残高が、取引を反映するように調節され得る。たとえば、ステップ５１３で、資金の支払いを反映するように、支払人のクレジット口座がイシュア支払いサービス２１６によって引き落とされ得る。同様に、ステップ５１６で、支払いを反映するように、受取人のクレジット口座にそれぞれの資金額が入金され得る。その結果、二人のクレジット口座所有者は、クレジット・カード取引ネットワークを使用する必要なしに、同一の機関の任意の他のクレジット口座所有者に資金を支払い、又は任意の他のクレジット口座所有者から資金を受け取ることができる。

次に図６Ａを参照すると、ある当事者が金融口座から別の当事者のクレジット口座に資金を支払うことを要求するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。図６Ａのシーケンス図は、ネットワーク環境２００内の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図６Ａのシーケンス図を、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。

ボックス６０３ａから始めて、支払い要求がクライアント・アプリケーション２７６ａによって作成され、イシュア支払いサービス２１６に転送され得る。支払い要求は、クライアント・アプリケーション２７６ａによってレンダリングされたユーザ・インターフェース１０６と対話する受取人によって作成され得る。たとえば、クレジット口座所有者（たとえば、クレジット・カード所有者）が、ピア金融機関の金融口座所有者（たとえば、銀行又は証券口座所有者）が指定の資金の合計をクレジット口座所有者に支払うという要求を作成し得、指定の資金の合計は、それぞれのクレジット口座の未払残高に対する入金として適用され得る。要求は、要求する資金の合計、支払人の識別、及び支払人の連絡先情報を含み得る。完了すると、支払い要求がイシュア支払いサービス２１６に転送され得る。

いくつかの実装では、複数の支払い要求がボックス６０３ａで作成され得る。たとえば、受取人は、クライアント・アプリケーション２７６ａのユーザ・インターフェース１０６内で表示される取引を選択し、複数の個人間で取引を割り勘にすることを受取人が望むことを示し得る。これは、たとえば、受取人が個人のグループの代わりに購入を行い、精算することを望んだ場合に生じ得る。この例では、取引の費用が、受取人によって指示されるように個人間で割り勘にされ得、受取人に資金を借りたそれぞれの個々の支払人について、それぞれの支払い要求が作成され得る。

次いでボックス６０６ａで、イシュア支払いサービス２１６は、取引識別子２６６を求めてインテグレータ・サービス２５６に要求を送り得る。それに応答して、インテグレータ・サービス２５６は取引識別子２６６を生成し、取引識別子２６６をイシュア支払いサービス２１６に提供し得る。イシュア支払いサービス２１６は、イシュア支払いサービス２１６が、それぞれの金融口座識別子２４９によって識別される、支払人のクレジット口座から資金を支払うようにという要求を後で決定し、又はそれを受取人によって維持されるクレジット口座に対応付けることを可能にするために、一時的に取引識別子２６６を記憶し得る。いくつかの例では、イシュア支払いサービス２１６は、イシュア支払いサービス２１６に関連付けられるエスクロー口座２２３ａについての口座番号をインテグレータ・サービス２５６に提供し得る。

ボックス６０９ａに移ると、イシュア支払いサービス２１６は、要求した支払人に支払い要求メッセージを送り得る。たとえば、クレジット口座所有者がボックス６０３ａで支払人についての携帯電話番号を提供した場合、イシュア支払いサービス２１６は、支払人のクライアント・デバイス１００にショート・メッセージ・サービス（ＳＭＳ）メッセージを送り得る。別の例として、クレジット口座所有者がボックス６０３ａで支払人についてのｅメール・アドレスを提供した場合、イシュア支払いサービス２１６は、支払人についてのｅメール・アドレスにｅメールを送り得る。

しかしながら、いくつかの実装では、ボックス６０９ａの機能がインテグレータ・サービス２５６によって実施され得る。たとえば、取引識別子２６６を作成した後、インテグレータ・サービス２５６は、受取人に支払い要求メッセージを送り得る。これらの実装では、イシュア支払いサービス２１６は、ボックス６０６ａで、関係する連絡先情報（たとえば、電話番号又はｅメール・アドレス）をインテグレータ・サービス２５６に提供していることになる。

支払い要求メッセージはいくつかの項目を含み得る。たとえば、支払い要求メッセージは、インテグレータ・サービス２５６についてのアドレスと、取引識別子２６６とを含むユニフォーム・リソース・インジケータ（ＵＲＩ）を含み得る。支払い要求メッセージは、クレジット口座所有者が支払人に資金を要求しているというメッセージ又は指示、資金額、クレジット口座所有者の識別などを更に含み得る。

次にボックス６１３ａで、クライアント・アプリケーション２７６ｂは、支払人を認証し、資金がそこから支払われることになる金融口座識別子２４９の識別又は選択を支払人から取得し得る。たとえば、支払人が支払い要求メッセージ内に含まれるリンクを選択したとき、支払人のクライアント・デバイス１００は、クライアント・アプリケーション２７６ｂを開き、インテグレータ・サービス２５６に要求を送るようにクライアント・アプリケーション２７６ｂに指示し得る。要求は、ボックス６０９ａで先に送られたＵＲＩ内に含まれる取引識別子２６６を含み得る。

次いで、インテグレータ・サービス２５６は、クライアント・アプリケーション２７６ｂへの応答を提供し、支払人の金融機関を識別するように支払人に促し得る。この応答は、たとえば、支払人が金融機関を選択することを可能にするように、クライアント・アプリケーション２７６ｂにユーザ・インターフェース１０６をレンダリングさせ得る。支払人が金融機関を選択した後、インテグレータ・サービス２５６は、支払人から認証証明２３３ｂを取得するようにクライアント・アプリケーション２７６ｂに促し得る。

支払人がインテグレータ・サービス２５６に認証証明２３３ｂを供給した後、インテグレータ・サービス２５６は、支払人の代わりにピア支払いサービス２３９との間で認証し得る。認証されると、インテグレータ・サービス２５６は、支払人に関連付けられるピア支払いサービス２３９に金融口座識別子２４９のリストを要求し得る。次いで、インテグレータ・サービス２５６は、資金がそこから支払われることになる口座を選択するために、支払人についてのクライアント・アプリケーション２７６ｂに金融口座識別子２４９（たとえば、当座預金口座、普通預金口座などについての口座番号）のリストを提供し得る。支払人が金融口座識別子２４９を選択した後は、クライアント・アプリケーション２７６ｂは、インテグレータ・サービス２５６に金融口座識別子２４９を提供し得る。たとえば、支払人がクライアント・アプリケーション２７６ｂ内から支払人の当座預金口座を選択した場合、クライアント・アプリケーション２７６ｂは、インテグレータ・サービス２５６に、選択した口座として金融口座識別子２４９を提供し得る。

ボックス６１６ａに進むと、インテグレータ・サービス２５６は、先にボックス６０６ａで提供されたそれぞれのイシュア支払いサービス２１６のエスクロー口座２２３ａについての口座識別子をピア支払いサービス２３９に送り得る。これは、ピア支払いサービス２３９が、支払人の代わりに、先に識別された金融口座から、クレジット口座所有者についてのクレジット・イシュアに、要求された資金を支払うことを可能にし得る。

次にボックス６１９ａを参照すると、ピア支払いサービス２３９は、選択された金融口座識別子２４９によって識別される支払人の金融口座から、ボックス６１６で識別されたエスクロー口座２２３ａに資金を移転し得る。たとえば、ピア支払いサービス２３９は、支払人の金融口座を維持するピア機関に関連付けられるエスクロー口座２２３ｂからエスクロー口座２２３ａへの資金の移転を開始し得る。たとえば、ピア支払いサービス２３９は、エスクロー口座２２３ｂからエスクロー口座２２３ａへのＡＣＨ支払いを開始し得る。別の例として、ピア支払いサービス２３９は、エスクロー口座２２３ｂからエスクロー口座２２３ａへのワイヤ移転支払いを開始し得る。しかしながら、ピア支払いサービス２３９は、任意のバッチ処理されるネット決済又は即時グロス決済支払いシステムを使用して資金を移転し得る。いくつかの実装では、イシュア支払いサービス２１６がエスクロー口座２２３ａへの預金を特定の取引に関連付けることを可能にするように、取引識別子２６６もピア支払いサービス２３９によってイシュア支払いサービス２１６に提供され得る。

ピア支払いサービス２３９による資金の移転の後、ピア支払いサービス２３９及びイシュア支払いサービス２１６は、それぞれの口座残高を調節し得る。たとえば、ボックス６２３ａで、イシュア支払いサービス２１６は、クレジット口座所有者のクレジット口座の未払残高に、エスクロー口座２２３ａに移転されたそれぞれの資金額についての入金を適用し得る。同様に、ボックス６２６ａで、ピア支払いサービス２３９は、支払人の金融口座からそれぞれの資金額を引き落とし、又は差し引き得る。その結果、クレジット口座（たとえば、クレジット・カード口座）を所有する個人は、任意の個人の金融口座に支払いを要求し、支払いを受け取ることができる。更に、取引は既存のクレジット・カード・ネットワークを迂回し得る。

ボックス６２３ａ及び６２６ａで示される機能が、シーケンス図中のより前で実装され得ることに留意されたい。たとえば、ボックス６１６ａでの口座情報の移転のボックス６１９ａでの資金の移転前に、それぞれの入金及び引落しが行われ得る。

次に図６Ｂを参照すると、ある当事者が金融口座から別の当事者のクレジット口座に資金を支払うことを要求するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。したがって、図６Ｂを、図６Ａのシーケンス図の代替例と見ることができる。図６Ｂのシーケンス図は、ネットワーク環境２００内の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図６Ｂのシーケンス図は、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。ボックス６０３ｂから６０９ｂは、図６Ａで先に説明したボックス６０３ａから６１３ｂに類似している。

しかしながら、ボックス６１６ｂで、インテグレータ・サービス２５６は、ピア支払いサービス２３９のエスクロー口座２２３ｂについての情報をイシュア支払いサービス２１６に提供し得る。たとえば、ボックス６１３ｂで行われる認証及び口座選択プロセスの間に、インテグレータ・サービス２５６は、ピア支払いサービス２３９に関連付けられるエスクロー口座２２３ｂについての情報も要求していることがある。次いで、インテグレータ・サービス２５６は、このデータをイシュア支払いサービス２１６に提供し得る。しかしながら、時には、イシュア支払いサービス２１６がピア支払いサービス２３９のエスクロー口座２２３ｂについての関係する情報を既に知っていることがあるので、これらの動作は任意選択である。これは、たとえば、イシュアとピア金融機関との間の長年の関係又は既存の関係の結果として生じ得る。

次いでボックス６１９ｂで、図６Ａのボックス６１９ａとは対照的に、イシュア支払いサービス２１６は、エスクロー口座２２３ｂからエスクロー口座２２３ａへの資金の支払いを開始し得る。たとえば、イシュア支払いサービス２１６は、ピア支払い２３９に関連付けられるエスクロー口座２２３ｂについての口座情報を仲介者（たとえば、自動決済機関又はワイヤ移転サービス）に提供し得、次いで仲介者は、ボックス６０３ｂで要求された資金額について、エスクロー口座２２３ａと２２３ｂとの間で支払い又は決済を行わせる。

ボックス６２３ｂ及び６２６ｂで示される機能は、図６Ａで先に説明したように、ボックス６２３ａ及び６２６ａに関して説明したものに類似している。ボックス６２３ａ及び６２６ａと同様に、ボックス６２３ｂ及び６２６ｂで示される機能は、シーケンス図中のより前で実装され得る。たとえば、ボックス６１６ｂでの口座情報の移転のボックス６１９ｂでの資金の移転前に、それぞれの入金及び引落しが行われ得る。

次に図７Ａを参照すると、ある当事者がクレジット口座から別の当事者のクレジット口座に資金を支払うことを要求するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。図７Ａのシーケンス図は、ネットワーク環境２００内のクレジット・カード・イシュアとピア金融機関との間の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図７Ａのシーケンス図を、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。

ボックス７０３ａから始めて、支払い要求がクライアント・アプリケーション２７６ａによって作成され、イシュア支払いサービス２１６ａに転送され得る。支払い要求は、クライアント・アプリケーション２７６ａによってレンダリングされたユーザ・インターフェース１０６と対話する受取人によって作成され得る。たとえば、クレジット口座所有者（たとえば、クレジット・カード所有者）が、別のイシュアのクレジット口座所有者が指定の資金の合計をクレジット口座所有者に支払うという要求を作成し得、指定の資金の合計は、それぞれのクレジット口座の未払残高に対する入金として適用され得る。要求は、要求する資金の合計、支払人の識別、及び支払人の連絡先情報を含み得る。完了すると、支払い要求がイシュア支払いサービス２１６ａに転送され得る。

いくつかの実装では、複数の支払い要求がボックス７０３ａで作成され得る。たとえば、受取人は、クライアント・アプリケーション２７６ａのユーザ・インターフェース１０６内で表示される取引を選択し、複数の個人間で取引を割り勘にすることを受取人が望むことを示し得る。これは、たとえば、受取人が個人のグループの代わりに購入を行い、精算することを望んだ場合に生じ得る。この例では、取引の費用が、受取人によって指示されるように個々の支払人間で割り勘にされ得、受取人に資金を借りたそれぞれの個々の支払人について、それぞれの支払い要求が作成され得る。

次いでボックス７０６ａで、イシュア支払いサービス２１６ａは、取引識別子２６６を求めてインテグレータ・サービス２５６に要求を送り得る。それに応答して、インテグレータ・サービス２５６は取引識別子２６６を生成し、取引識別子２６６をイシュア支払いサービス２１６ａに提供し得る。イシュア支払いサービス２１６ａは、イシュア支払いサービス２１６ａが、支払人のクレジット口座から資金を支払うようにという要求を後で決定し、又はそれを受取人のクレジット口座に対応付けることを可能にするために、一時的に取引識別子２６６を記憶し得る。いくつかの例では、イシュア支払いサービス２１６ａは、イシュア支払いサービス２１６に関連付けられるエスクロー口座２２３ａについての口座番号をインテグレータ・サービス２５６に提供し得る。

ボックス７０９ａに移ると、イシュア支払いサービス２１６ａは、要求した支払人に支払い要求メッセージを送り得る。たとえば、クレジット口座所有者がボックス７０３ａで支払人についての携帯電話番号を提供した場合、イシュア支払いサービス２１６ａは、支払人のクライアント・デバイス１００にショート・メッセージ・サービス（ＳＭＳ）メッセージを送り得る。別の例として、クレジット口座所有者がボックス７０３ａで支払人についてのｅメール・アドレスを提供した場合、イシュア支払いサービス２１６ａは、支払人についてのｅメール・アドレスにｅメールを送り得る。

しかしながら、いくつかの実装では、ボックス７０９ａの機能がインテグレータ・サービス２５６によって実施され得る。たとえば、取引識別子２６６を作成した後、インテグレータ・サービス２５６は、受取人に支払い要求メッセージを送り得る。これらの実装では、イシュア支払いサービス２１６は、ボックス７０６ａで、関係する連絡先情報（たとえば、電話番号又はｅメール・アドレス）をインテグレータ・サービス２５６に提供していることになる。

支払い要求メッセージはいくつかの項目を含み得る。たとえば、支払い要求メッセージは、インテグレータ・サービス２５６についてのアドレスと、取引識別子２６６とを含むユニフォーム・リソース・インジケータ（ＵＲＩ）を含み得る。支払い要求メッセージは、クレジット口座所有者が支払人に資金を要求しているというメッセージ又は指示、資金額、クレジット口座所有者の識別などを更に含み得る。

次にボックス７１３ａで、クライアント・アプリケーション２７６ｂは、支払人を認証し、資金がそこから支払われることになるクレジット口座識別子２３６の識別又は選択を支払人から取得し得る。たとえば、支払人が支払い要求メッセージ内に含まれるリンクを選択したとき、支払人のクライアント・デバイス１００は、クライアント・アプリケーション２７６ｂを開き、インテグレータ・サービス２５６に要求を送るようにクライアント・アプリケーション２７６ｂに指示し得る。要求は、ボックス７０９ａで先に送られたＵＲＩ内に含まれる取引識別子２６６を含み得る。

次いで、インテグレータ・サービス２５６は、クライアント・アプリケーション２７６ｂへの応答を提供し、支払人の金融機関を識別するように支払人に促し得る。この応答は、たとえば、支払人が金融機関を選択することを可能にするように、クライアント・アプリケーション２７６ｂにユーザ・インターフェース１０６をレンダリングさせ得る。支払人が金融機関を選択した後、インテグレータ・サービス２５６は、支払人から認証証明２３３ａを取得するようにクライアント・アプリケーション２７６ｂに促し得る。

支払人がインテグレータ・サービス２５６に認証証明２３３ａを供給した後、インテグレータ・サービス２５６は、支払人の代わりにイシュア支払いサービス２１６ｂとの間で認証し得る。認証されると、インテグレータ・サービス２５６は、支払人に関連付けられるイシュア支払いサービス２１６ｂにクレジット口座識別子２３６のリストを要求し得る。次いで、インテグレータ・サービス２５６は、資金がそこから支払われることになる口座を選択するために、支払人についてのクライアント・アプリケーション２７６ｂにクレジット口座識別子２３６（たとえば、当座預金口座、普通預金口座などについての口座番号）のリストを提供し得る。支払人がクレジット口座識別子２３６を選択した後は、クライアント・アプリケーション２７６ｂは、インテグレータ・サービス２５６にクレジット口座識別子２３６を提供し得る。たとえば、支払人がクライアント・アプリケーション２７６ｂ内から支払人の当座預金口座を選択した場合、クライアント・アプリケーション２７６ｂは、インテグレータ・サービス２５６に、選択した口座としてクレジット口座識別子２３６を提供し得る。

ボックス７１６ａに進むと、インテグレータ・サービス２５６は、先にボックス７０６ａで提供されたそれぞれのイシュア支払いサービス２１６のエスクロー口座２２３ａについての口座識別子をイシュア支払いサービス２１６ｂに送り得る。これは、イシュア支払いサービス２１６ｂが、支払人の代わりに、先に識別されたクレジット口座から、クレジット口座所有者についてのクレジット・イシュアに、要求された資金を支払うことを可能にし得る。

次にボックス７１９ａを参照すると、イシュア支払いサービス２１６ｂは、イシュア支払いサービス２１６ｂに関連付けられるエスクロー口座２２３ａから、ボックス７１６で識別されたエスクロー口座２２３ａに資金を移転し得る。先に図２では、イシュア支払いサービス２１６がエスクロー口座２２３ａを有するものとして示されているが、二つの別々のイシュア支払いサービス２１６ａ及び２１６ｂが資金を交換している場合、各イシュア支払いサービス２１６は、別々のエスクロー口座２２３ａを有すると理解されたい。たとえば、イシュア支払いサービス２１６ｂは、エスクロー口座２２３ａ間のＡＣＨを開始し得る。別の例として、イシュア支払いサービス２１６ｂは、エスクロー口座２２３ａ間のワイヤ移転を開始し得る。しかしながら、イシュア支払いサービス２１６ｂは、任意のバッチ処理されるネット決済又は即時グロス決済支払いシステムを使用して資金を移転し得る。いくつかの実装では、イシュア支払いサービス２１６ａがエスクロー口座２２３ａへの預金を特定の取引に関連付けることを可能にするように、取引識別子２６６もイシュア支払いサービス２１６ｂによってイシュア支払いサービス２１６ａに提供され得る。しかしながら、代替実装では、イシュア支払いサービス２１６ａも、二つのエスクロー口座２２３ａ間で資金の移転を行わせ得る。

イシュア支払いサービス２１６ｂによる資金の移転の後、イシュア支払いサービス２１６ｂ及びイシュア支払いサービス２１６ａは、それぞれの口座残高を調節し得る。たとえば、ボックス７２３ａで、イシュア支払いサービス２１６ａは、クレジット口座所有者のクレジット口座の未払残高に、エスクロー口座２２３ａに移転されたそれぞれの資金額についての入金を適用し得る。同様に、ボックス７２６ａで、イシュア支払いサービス２１６ｂは、支払人の金融口座からそれぞれの資金額を引き落とし、又は差し引き得る。その結果、クレジット口座（たとえば、クレジット・カード口座）を有する個人は、任意の他の個人のクレジット口座に支払いを要求し、支払いを受け取ることができる。更に、取引は既存のクレジット・カード・ネットワークを迂回し得る。

次に図７Ｂを参照すると、ある当事者がクレジット口座から別の当事者のクレジット口座に資金を支払うことを要求するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。したがって、図７Ｂを図７Ａのシーケンス図に対する代替例と見ることができる。図７Ｂのシーケンス図は、ネットワーク環境２００内のクレジット・カード・イシュアとピア金融機関との間の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図７Ｂのシーケンス図を、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。ボックス７０３ｂから７０９ｂは、図６Ａで先に説明したように、ボックス７０３ａから７１３ｂに類似している。

しかしながら、ボックス７１６ｂで、インテグレータ・サービス２５６は、イシュア支払いサービス２１６ｂのエスクロー口座２２３ａについての情報をイシュア支払いサービス２１６ａに提供し得る。たとえば、ボックス７１３ｂで行われる認証及び口座選択プロセスの間に、インテグレータ・サービス２５６は、イシュア支払いサービス２１６ｂに関連付けられるエスクロー口座２２３ａについての情報も要求していることがある。次いで、インテグレータ・サービス２５６は、このデータをイシュア支払いサービス２１６ａに提供し得る。しかしながら、時には、イシュア支払いサービス２１６ａがイシュア支払いサービス２１６ｂのエスクロー口座２２３ａについての関係する情報を既に知っていることがあるので、これらの動作は任意選択である。これは、たとえば、イシュア間の長年の関係又は既存の関係の結果として生じ得る。

次いでボックス７１９ｂで、図７Ｂのボックス７１９ａとは対照的に、イシュア支払いサービス２１６ａは、イシュア支払いサービス２１６ｂのエスクロー口座２２３ａからイシュア支払いサービス２１６ａのエスクロー口座２２３ａへの資金の支払いを開始し得る。先に図２では、イシュア支払いサービス２１６がエスクロー口座２２３ａを有するものとして示されているが、二つの別々のイシュア支払いサービス２１６ａ及び２１６ｂが資金を交換している場合、各イシュア支払いサービス２１６は、別々のエスクロー口座２２３ａを有すると理解されたい。たとえば、イシュア支払いサービス２１６は、イシュア支払いサービス２１６ｂに関連付けられるエスクロー口座２２３ａについての口座情報を仲介者（たとえば、自動決済機関又はワイヤ移転サービス）に提供し得、次いで仲介者は、ボックス７０３ｂで要求された資金額について、エスクロー口座２２３ａ間で支払い又は決済を行わせる。

ボックス７２３ｂ及び７２６ｂで示される機能は、図７Ａで先に説明したように、ボックス７２３ａ及び７２６ａに関して説明したものに類似している。ボックス７２３ａ及び７２６ａと同様に、ボックス７２３ｂ及び７２６ｂで示される機能は、シーケンス図中のより前で実装され得る。たとえば、ボックス７１６ｂでの口座情報の移転のボックス７１９ｂでの資金の移転前に、それぞれの入金及び引落しが行われ得る。

次に図８を参照すると、同一の機関によって発行されたクレジット口座（たとえば、クレジット・カード）間で資金を移転するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。図８のシーケンス図は、ネットワーク環境２００内の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図８のシーケンス図を、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。

ボックス８０３から始めて、支払い要求がクライアント・アプリケーション２７６ａによって作成され、イシュア支払いサービス２１６に転送され得る。支払い要求は、クライアント・アプリケーション２７６ａによってレンダリングされたユーザ・インターフェース１０６と対話する受取人によって作成され得る。たとえば、クレジット口座所有者（たとえば、クレジット・カード所有者）が、同一の機関の別のクレジット口座所有者が指定の資金の合計を支払うという要求を作成し得、指定の資金の合計は、それぞれのクレジット口座の未払残高に対する入金として適用され得る。要求は、要求する資金の合計、支払人の識別、及び支払人の連絡先情報を含み得る。完了すると、支払い要求がイシュア支払いサービス２１６に転送され得る。

いくつかの実装では、複数の支払い要求がステップ８０３で作成され得る。たとえば、受取人は、クライアント・アプリケーション２７６ａのユーザ・インターフェース１０６内で表示される取引を選択し、複数の個人間で取引を割り勘にすることを受取人が望むことを示し得る。これは、たとえば、受取人が個人のグループの代わりに購入を行い、精算することを望んだ場合に生じ得る。この例では、取引の費用が、受取人によって指示されるように個人間で割り勘にされ得、受取人に資金を借りたそれぞれの個々の支払人について、それぞれの支払い要求が作成され得る。

次にボックス８０６で、イシュア支払いサービス２１６は支払人に支払い要求メッセージを送り得る。たとえば、要求元がボックス８０３で受取人についての携帯電話番号を提供した場合、イシュア支払いサービス２１６は、支払人のクライアント・デバイス１００にショート・メッセージ・サービス（ＳＭＳ）メッセージを送り得る。別の例として、要求元がボックス８０３で支払人についてのｅメール・アドレスを提供した場合、イシュア支払いサービス２１６は、支払人についてのｅメール・アドレスにｅメールを送り得る。メッセージは、たとえば、イシュア支払いサービス２１６によって提供される認証ページへのリンクを含み得る。

次いでボックス８０９で、クライアント・アプリケーション２７６ｂはイシュア支払いサービス２１６との間で認証し得る。たとえば、支払人は、クライアント・アプリケーション２７６ｂのユーザ・インターフェース１０６内に認証証明２３３ａを入力し得、クライアント・アプリケーション２７６ｂは、認証証明２３３ａを使用して、イシュア支払いサービス２１６で支払人を認証し得る。認証に応答して、イシュア支払いサービス２１６は、支払人が選択し得る一つ又は複数のクレジット口座識別子２３６（たとえば、受取人がイシュアとの間で所有するクレジット・カード口座のクレジット・カード口座番号）をクライアント・アプリケーション２７６ｂに提供し得る。次いで、クレジット口座識別子２３６が、クライアント・アプリケーション２７６ｂによってユーザ・インターフェース１０６内で支払人に提示され得、支払人は、資金がそこから支払われることになる口座を選択し得る。次いで、選択したクレジット口座識別子２３６がイシュア支払いサービス２１６に提供され得る。

ボックス８１１に移ると、イシュア支払いサービス２１６は取引を許可し得る。たとえば、イシュア支払いサービス２１６は、クレジット口座識別子２３６に関連付けられる与信限度が、受取人への資金の支払いを可能にするのに十分な与信額を有するかどうかを評価し得る。イシュア支払いサービス２１６が取引を許可しない場合、対話のシーケンスは停止し得る。

ボックス８１３及び８１６で、支払人及び要求元のクレジット口座の口座残高が、取引を反映するように調節され得る。たとえば、ボックス１３で、資金の支払いを反映するように、支払人のクレジット口座がイシュア支払いサービス２１６によって引き落とされ得る。同様に、ボックス８１６で、支払いを反映するように、要求元のクレジット口座にそれぞれの資金額が入金され得る。その結果、二人のクレジット口座所有者は、クレジット・カード取引ネットワークを使用する必要なしに、同一の機関の任意の他のクレジット口座所有者に資金を支払い、又は任意の他のクレジット口座所有者から資金を受け取ることができる。

次に図９を参照すると、クレジット・カード・イシュアとピア金融機関との間で資金を移転するための、ネットワーク環境２００の様々な構成要素間の対話の動作の一例を与えるシーケンス図が示されている。図９のシーケンス図は、ネットワーク環境２００内の資金の移転を実装するために利用され得る多くの異なるタイプの機能構成の一例を与えるに過ぎないことを理解されたい。代替として、図９のシーケンス図を、ネットワーク環境２００内で実装される方法の要素の一例を示すものと見ることができる。

ボックス９０１から始めて、支払人は、クライアント・アプリケーション２７６と対話し得、受取人に対する支払いを作成することに関する詳細を選択し得る。たとえば、クライアント・アプリケーション２７６を使用する支払人は、クライアント・デバイス１００のユーザ・インターフェース１０６内で提示される受取人のリストから受取人を選択し得る。受取人を選択することによって、支払人はまた、受取人についての一意識別子（たとえば、電話番号、ｅメール・アドレス、又は他の識別子）を選択し得る。支払人はまた、受取人に支払う資金額を指定し得る。いくつかの例では、支払人はまた、支払いのために使用するクレジット口座についてのクレジット口座識別子２３６を指定し得る（たとえば、支払人が複数のクレジット又はチャージ・カード口座を有していた場合）。

次いでボックス９０３で、クライアント・アプリケーション２７６は受取人への支払いを開始し得る。たとえば、クライアント・アプリケーション２７６は、受取人の識別子、支払われるべき資金額、及びクレジット口座識別子２３６をイシュア支払いサービス２１６に提供し得る。

次にボックス９０６で、イシュア支払いサービス２１６は取引を許可し得る。たとえば、イシュア支払いサービス２１６は、クレジット口座識別子２３６に関連付けられる与信限度が、受取人への資金の支払いを可能にするのに十分な与信額を有するかどうかを評価し得る。イシュア支払いサービス２１６が取引を許可しない場合、対話のシーケンスは停止し得る。

ボックス９０９に移ると、イシュア支払いサービス２１６は、受取人に支払われるべき資金額をユーザのクレジット口座から引き落とし得る。たとえば、イシュア支払いサービス２１６は、クレジット口座識別子２３６によって識別されるクレジット口座に関連付けられる与信限度を削減し得る。しかしながら、この動作はシーケンス図中の後に実施され得ることに留意されたい。

その後で、ボックス９１３で、イシュア支払いサービス２１６は、支払いについての情報をピア支払いサービス２３９に中継し得る。イシュア支払いサービス２１６は、いくつかの方式で、適切なピア支払いサービス２３９を識別し得る。たとえば、ピア支払いサービス２３９が、ボックス９０１で支払人によって指定されていることがある。或いは、イシュア支払いサービス２１６は、受取人についての被支払人ディレクトリ２２１ａ内にレコードを有し得、レコードは、前の取引に基づいて受取人に資金を移転するとき、どのピア支払いサービス２３９と対話するかを示す。

次いでボックス９１６で、ピア支払いサービス２３９は、受取人に関連付けられる金融口座に、対応する資金額を預け、又は入金し得る。たとえば、受取人が、受取人について単一の金融口座を登録している場合、ピア支払いサービス２３９は、その口座への預金又は入金を適用し得る。受取人が複数の金融口座を有する場合、受取人によって指定されたデフォルトの金融口座に資金が入金され、又は預けられ得る。

次にボックス９１９及び９２３で、イシュア支払いサービス２１６及びピア支払いサービス２３９に関連付けられるエスクロー口座２２３ａと２２３ｂとの間で資金が最終的に移転される。これは、周期的間隔（たとえば、毎夜、毎週、毎時など）で行われる、バッチ処理されるネット決済プロセスの一部であり得る。たとえば、ピア支払いサービス２３９は、イシュア支払いサービス２１６のエスクロー口座２２３ａから資金をプルするようにという要求を開始し得る。別の例として、イシュア支払いサービス２１６は、ピア支払いサービス２３９のエスクロー口座２２３ｂに資金をプッシュし、又は送るようにという要求を開始し得る。

図９に示されるシーケンス図は、イシュアによって維持されるクレジット口座と、ピア支払いサービス２３９によって維持される金融口座との間で資金を移転するためのプロセスの一例を示すが、ほぼ同様のプロセスが、二つの別々のイシュアによって維持されるクレジット口座間で資金を移転するために使用され得ることに留意されたい。しかしながら、ボックス９１６で金融口座に資金を預ける代わりに、受取人のクレジット口座に入金が適用されることになる。

先に論じたいくつかのソフトウェア構成が、それぞれのコンピューティング・デバイスのメモリ内に記憶され、それぞれのコンピューティング・デバイスのプロセッサによって実行可能である。これに関して、「実行可能ファイル」という用語は、プロセッサによって最終的に実行され得る形態のプログラム・ファイルを意味する。実行可能プログラムの例は、メモリのランダム・アクセス部分内にロードされ、プロセッサによって実行され得るフォーマットの機械コード又は機械可読命令に変換され得るコンパイル済みプログラム、メモリのランダム・アクセス部分内にロードされ、プロセッサによって実行することができるオブジェクト・コードなどの適切なフォーマットで表現され得るソース・コード、又はプロセッサによって実行される、メモリのランダム・アクセス部分内の命令を生成するように別の実行可能プログラムによって解釈され得るソース・コードであり得る。実行可能プログラムは、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、ハード・ドライブ、ソリッド・ステート・ドライブ、ユニバーサル・シリアル・バス（ＵＳＢ）フラッシュ・ドライブ、メモリ・カード、コンパクト・ディスク（ＣＤ）やデジタル・バーサタイル・ディスク（ＤＶＤ）などの光ディスク、フロッピィ・ディスク、磁気テープ、又は他のメモリ構成要素を含む、メモリの任意の部分又は構成要素の中に記憶され得る。

メモリは、揮発性と不揮発性のメモリ及びデータ記憶構成要素をどちらも含む。揮発性構成要素は、電源喪失時にデータ値を保持しないものである。不揮発性構成要素は、電源喪失時にデータ値を保持するものである。したがって、メモリは、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、ハード・ディスク・ドライブ、ソリッド・ステート・ドライブ、ＵＳＢフラッシュ・ドライブ、メモリ・カード・リーダを介してアクセスされるメモリ・カード、関連するフロッピィ・ディスク・ドライブを介してアクセスされるフロッピィ・ディスク、光ディスク・ドライブを介してアクセスされる光ディスク、適切なテープ・ドライブを介してアクセスされる磁気テープ、又は他のメモリ構成要素、或いはこれらのメモリ構成要素のうちの任意の二つ以上の組合せを含み得る。更に、ＲＡＭは、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、又は磁気ランダム・アクセス・メモリ（ＭＲＡＭ）、及び他のそのようなデバイスを含み得る。ＲＯＭは、プログラマブル読取り専用メモリ（ＰＲＯＭ）、消去可能プログラマブル読取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）、又は他の同様のメモリ・デバイスを含み得る。

本明細書で説明するアプリケーション及びシステムは、上記で論じたように、汎用ハードウェアによって実行されるソフトウェア又はコードで実施され得るが、代替として、本明細書で説明するアプリケーション及びシステムは、専用ハードウェア、又はソフトウェア／汎用ハードウェアと専用ハードウェアの組合せでも実施され得る。専用ハードウェアで実施される場合、それぞれは、いくつかの技術のうちのいずれか一つ又は組合せを利用する回路又は状態機械として実装され得る。これらの技術は、限定はしないが、一つ又は複数のデータ信号の印加時に様々な論理関数を実装するための論理ゲートを有するディスクリート・ロジック回路、適切な論理ゲートを有する特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又は他の構成要素などを含み得る。そのような技術は一般に当業者によって良く知られており、したがって本明細書では詳細には説明しない。

シーケンス図は、本開示の様々な実施形態の部分の実装の機能及び動作を示す。ソフトウェアで実施される場合、各ブロックは、指定の論理機能を実装するためのプログラム命令を含むモジュール、セグメント、又はコードの部分を表し得る。プログラム命令は、コンピュータ・システム内のプロセッサなどの適切な実行システムによって認識可能な数値命令を含むプログラミング言語又は機械コードで書かれた人間可読ステートメントを含むソース・コードの形態で実施され得る。機械コードは、様々なプロセスを通じてソース・コードから変換され得る。たとえば、対応するアプリケーションの実行前に、コンパイラでソース・コードから機械コードが生成され得る。別の例として、インタプリタを用いた実行と同時に、ソース・コードから機械コードが生成され得る。他の適切な手法も使用され得る。ハードウェアで実施される場合、各ブロックは、指定の論理機能を実装するための回路又はいくつかの相互接続された回路を表し得る。

シーケンス図は実行の特定の順序を示すが、実行の順序は、図示されるものとは異なり得ることを理解されたい。たとえば、二つ以上のブロックの実行の順序が、図示される順序に比べて撹乱され得る。更に、連続して示される二つ以上のブロックが、同時に、又は部分的に同時に実行され得る。更に、いくつかの実施形態では、シーケンス図に示されるブロックのうちの一つ又は複数が飛ばされ、又は省略され得る。更に、有用性の向上、アカウンティング、性能測定、又はトラブルシューティング援助の提供などのために、任意の数のカウンタ、状態変数、警告セマフォー、又はメッセージが、本明細書で説明する論理フローに追加され得る。すべてのそのような変形形態が本開示の範囲内にあることを理解されたい。

更に、ソフトウェア又はコードを含む本明細書で説明する任意の論理又はアプリケーションが、コンピュータ・システム又は他のシステム内のプロセッサなどの命令実行システムによる使用、又は命令実行システムと一緒の使用のために、任意の非一時的コンピュータ可読媒体で実施され得る。この意味で、論理は、コンピュータ可読媒体からフェッチされ、命令実行システムによって実行され得る命令及び宣言を含むステートメントを含み得る。本開示の文脈では、「コンピュータ可読媒体」は、命令実行システムによる使用、又は命令実行システムと一緒の使用のために、本明細書で説明する論理又はアプリケーションを含み、記憶し、又は維持する任意の媒体であり得る。更に、複数のコンピューティング・デバイス（たとえば、ストレージ・エリア・ネットワーク或いは分散型又はクラスタ化ファイルシステム又はデータベース）にわたって配置された分散型コンピュータ可読媒体の集合も、集合的に単一の非一時的コンピュータ可読媒体と見なされ得る。

コンピュータ可読媒体は、磁気媒体、光媒体、半導体などの多くの物理媒体のうちのいずれか一つを含み得る。適切なコンピュータ可読媒体のより具体的な例は、限定はしないが、磁気テープ、磁気フロッピィ・ディスケット、磁気ハード・ドライブ、メモリ・カード、ソリッド・ステート・ドライブ、ＵＳＢフラッシュ・ドライブ、又は光ディスクを含む。更に、コンピュータ可読媒体は、静的ランダム・アクセス・メモリ（ＳＲＡＭ）及びダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）又は磁気ランダム・アクセス・メモリ（ＭＲＡＭ）を含むランダム・アクセス・メモリ（ＲＡＭ）であり得る。更に、コンピュータ可読媒体は、読取り専用メモリ（ＲＯＭ）、プログラマブル読取り専用メモリ（ＰＲＯＭ）、消去可能プログラマブル読取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）、又は他のタイプのメモリ・デバイスであり得る。

更に、本明細書で説明する任意の論理又はアプリケーションが、様々な方式で実装及び構築され得る。たとえば、説明する一つ又は複数のアプリケーションが、単一のアプリケーションのモジュール又は構成要素として実装され得る。更に、本明細書で説明する一つ又は複数のアプリケーションが、共有コンピューティング・デバイス又は別々のコンピューティング・デバイス或いはそれらの組合せで実行され得る。たとえば、本明細書で説明する複数のアプリケーションが、同一のコンピューティング・デバイスで、又は同一のコンピューティング環境内の複数のコンピューティング・デバイスで実行され得る。

別段に具体的に述べられていない限り、「Ｘ、Ｙ、又はＺのうちの少なくとも一つ」という語句などの選言的言い回しは、文脈と共に、項目、用語などがＸ、Ｙ、又はＺ、或いはそれらの任意の組合せ（たとえば、Ｘ、Ｙ、又はＺ）であり得ることを提示するために一般に使用されると別の形で理解されたい。したがって、そのような選言的言い回しは一般に、Ｘの少なくとも一つ、Ｙの少なくとも一つ、又はＺの少なくとも一つがそれぞれ存在することをある実施形態が必要とすることを示唆するように意図するわけではなく、示唆すべきではない。

本開示の前述の実施形態は、本開示の原理の明快な理解のために述べられる実装の可能な例に過ぎないことを強調しておく。本開示の精神及び原理から大幅に逸脱することなく、前述の実施形態に対して多くの変形形態及び修正形態が作成され得る。すべてのそのような修正形態及び変形形態が、本明細書では本開示の範囲内に含まれ、以下の特許請求の範囲によって保護されるものとする。

本開示の様々な実施形態の例示的な例が以下で述べられる。本開示の追加の実施形態が、先行する段落で論じられる。したがって、本開示の範囲が以下の例示的実施形態に限定されると解釈されるべきではない。

実施形態１－プロセッサ及びメモリを備える第１のコンピューティング・デバイスと、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、第２のコンピューティング・デバイスからメッセージを受信することであって、メッセージが、資金移転の通知と、資金移転にリンクされる取引識別子とを含む、受信することと、資金移転を処理するようにという要求を第３のコンピューティング・デバイスに送ることであって、要求が、資金移転についての取引識別子、口座識別子、及び機関識別子を含む、送ることとを行わせる、メモリ内に記憶された機械可読命令とを備えるシステム。

実施形態２－メモリ内に記憶された機械可読命令が、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、資金移転が完了したという表示を受信させ、第１のコンピューティング・デバイスのディスプレイ上に、資金移転が完了したという表示をレンダリングさせる実施形態１のシステム。

実施形態３－取引識別子が、メッセージ内に含まれるユニフォーム・リソース・インジケータ（ＵＲＩ）内に含まれ、機械可読命令が更に、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、ＵＲＩにアドレス指定される第１の要求を送らせ、第１の要求に応答して、機関のリストを受信させ、機関のリストからの機関の選択に応答して、機関についての認証証明を求める第２の要求を受信させ、認証証明の提出に応答して、機関のリストから選択された機関によって維持される金融口座のリストを受信させる実施形態１又は２のシステム。

実施形態４－第１のコンピューティング・デバイスが、ディスプレイを備え、機械可読命令が更に、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、ディスプレイによってレンダリングされたユーザ・インターフェース内に、金融口座のリストを提示させ、金融口座のリストからの金融口座の選択に応答して、資金移転を処理するようにという要求内に金融口座についての口座識別子を含めさせる実施形態３のシステム。

実施形態５－機械可読命令が更に、第１のコンピューティング・デバイスに、少なくとも、第１のコンピューティング・デバイスのディスプレイ上に提示されたユーザ・インターフェース内に、資金移転を確認するようにというプロンプトをレンダリングさせ、資金移転の確認に応答して、資金移転を処理するようにという要求が送られる実施形態１～４のいずれかのシステム。

実施形態６－メッセージがショート・メッセージ・サービス（ＳＭＳ）メッセージである実施形態１～５のいずれかのシステム。

実施形態７－指定のクレジット口座から受取人に指定の額の資金を送るようにという要求を第１のクライアント・デバイスから受信することと、受取人に指定の額の資金を送るようにという要求についての取引識別子をコンピューティング・デバイスに要求することと、第２のクライアント・デバイスに第１の通知を送ることであって、第１の通知が取引識別子を含み、第２のクライアント・デバイスが受取人に関連付けられる、送ることと、受取人が指定の額の資金を受け入れたという第２の通知をコンピューティング・デバイスから受信することであって、第２の通知が金融口座を識別する、受信することと、指定の額の資金について金融口座への資金移転を開始することとを含む方法。

実施形態８－指定のクレジット口座から指定の額の資金を引き落とすことを更に含む実施形態７の方法。

実施形態９－指定の額の資金について金融口座への資金移転を開始することが、即時グロス決済（ＲＴＧＳ）システムを通じて支払いを開始することを更に含む実施形態７又は８の方法。

実施形態１０－指定の額の資金について金融口座への資金移転を開始することが、バッチ処理されるネット決済ネットワークを通じて支払いを開始することを更に含む実施形態７又は８の方法。

実施形態１１－指定の額の資金について金融口座への資金移転を開始することが、指定の額の資金についてエスクロー口座から金融口座への支払いを開始することを更に含む実施形態７～１０のいずれかの方法。

実施形態１２－指定のクレジット口座から受取人に指定の額の資金を送るようにという要求が、受取人についての連絡先情報を更に含み、第２のクライアント・デバイスに第１の通知を送ることが、連絡先情報で指定される宛先に第１の通知を送ることを更に含む実施形態７～１１のいずれかの方法。

実施形態１３－取引識別子を含むユニフォーム・リソース・インジケータ（ＵＲＩ）を作成することと、第１の通知内にＵＲＩを含めることとを更に含む実施形態７～１２のいずれかの方法。

実施形態１４－第２の通知が取引識別子を更に含む実施形態７～１３のいずれかの方法。

実施形態１５－第１のクライアント・デバイスにメッセージを送ることを更に含み、メッセージが、受取人が指定の額の資金を受け入れたことを示す実施形態７～１４のいずれかの方法。

実施形態１６－第１のコンピューティング・デバイスのプロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、クライアント・デバイスからの資金移転を処理するようにという要求を受信することであって、要求が取引識別子を含む、受信することと、クライアント・デバイスに機関のリストを提供することと、機関のリストからの機関の第１の選択をクライアント・デバイスから受信することと、機関のリストから選択された機関についての認証証明をクライアント・デバイスに要求することと、認証証明の受信に応答して、機関のリストから選択された機関に関連付けられる口座のリストをクライアント・デバイスに提供することと、口座のリストからの口座の第２の選択を受信することと、取引識別子、機関のリストから選択された機関についての第１の識別子、及び口座のリストから選択された口座についての第２の識別子を第２のコンピューティング・デバイスに提供することとを行わせる機械可読命令を含む非一時的コンピュータ可読媒体。

実施形態１７－資金移転を処理するようにという要求が第２の要求であり、機械可読命令が、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、取引識別子を求める第２のコンピューティング・デバイスからの第１の要求に応答して、取引識別子を生成させ、第２のコンピューティング・デバイスに取引識別子を提供させる実施形態１６の非一時的コンピュータ可読媒体。

実施形態１８－取引識別子が、資金移転を処理するようにという要求内のクライアント・デバイスによって要求されるユニフォーム・リソース識別子（ＵＲＩ）内に含められる実施形態又は１６及び１７の非一時的コンピュータ可読媒体。

実施形態１９－機械可読命令が更に、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、認証証明を使用するクライアント・デバイスの代わりに、機関のリストから選択された機関によって運用されるピア支払いサービスとの間で認証させる実施形態１６～１８のいずれかの非一時的コンピュータ可読媒体。

実施形態２０－機械可読命令が更に、プロセッサによって実行されるとき、第１のコンピューティング・デバイスに、少なくとも、資金移転に関連付けられるエスクロー口座についての第３の識別子を第２のコンピューティング・デバイスに提供させる実施形態１６～１９のいずれかの非一時的コンピュータ可読媒体。

Claims (5)

1. プロセッサ及びメモリを備える第１のコンピューティング・デバイスと、
   前記プロセッサによって実行されるとき、前記第１のコンピューティング・デバイスに、少なくとも、
   第２のコンピューティング・デバイスからメッセージを受信することであって、前記メッセージが、資金移転の通知と、前記資金移転にリンクされる取引識別子とを含む、受信することと、
   前記資金移転を処理するようにという要求を第３のコンピューティング・デバイスに送ることであって、前記要求が、前記資金移転についての前記取引識別子、口座識別子、及び機関識別子を含む、送ることと、
   を行わせる、前記メモリ内に記憶された機械可読命令と、
   を備え、
   前記取引識別子が、前記メッセージ内に含まれるユニフォーム・リソース・インジケータ（ＵＲＩ）内に含まれ、前記機械可読命令が更に、前記プロセッサによって実行されるとき、前記第１のコンピューティング・デバイスに、少なくとも、
   前記ＵＲＩにアドレス指定される第１の要求を送らせ、
   前記第１の要求に応答して、機関のリストを受信させ、
   機関の前記リストからの機関の選択に応答して、前記機関についての認証証明を求める第２の要求を受信させ、
   前記認証証明の提出に応答して、機関の前記リストから選択された前記機関によって維持される金融口座のリストを受信させ、
   前記資金移転は、エスクロー口座から前記金融口座への支払いによって実現される、
   システム。
2. 前記メモリ内に記憶された前記機械可読命令が、前記プロセッサによって実行されるとき、前記第１のコンピューティング・デバイスに、少なくとも、
   前記資金移転が完了したという表示を受信させ、
   前記第１のコンピューティング・デバイスのディスプレイ上に、前記資金移転が完了したという表示をレンダリングさせる請求項１に記載のシステム。
3. 前記第１のコンピューティング・デバイスがディスプレイを備え、前記機械可読命令が更に、前記プロセッサによって実行されるとき、前記第１のコンピューティング・デバイスに、少なくとも、
   前記ディスプレイによってレンダリングされたユーザ・インターフェース内に、金融口座の前記リストを提示させ、
   金融口座の前記リストからの金融口座の選択に応答して、前記資金移転を処理するようにという前記要求内に前記金融口座についての前記口座識別子を含めさせる請求項１又は２に記載のシステム。
4. 前記機械可読命令が更に、前記第１のコンピューティング・デバイスに、少なくとも、
   前記第１のコンピューティング・デバイスのディスプレイ上に提示されたユーザ・インターフェース内に、前記資金移転を確認するようにというプロンプトをレンダリングさせ、
   前記資金移転の確認に応答して、前記資金移転を処理するようにという前記要求が送られる請求項１乃至３のいずれか一項に記載のシステム。
5. 前記メッセージがショート・メッセージ・サービス（ＳＭＳ）メッセージである請求項１乃至４のいずれか一項に記載のシステム。

Images