JP6727299B2 - 非金融機関システムでのセキュア取引を促進するシステム及び方法 - Google Patents

Description

技術分野は、電子送金ネットワークを介して送金するシステム及び方法に関し、より詳細には、電子送金ネットワークを介して、金融機関以外のエンティティにより維持される物理的支払い端末又はオンライン支払いプロセスにアクセスを有する個人にセキュアに送金するシステム及び方法に関する。

自動クリアリングハウス（ＡＣＨ）ネットワーク等の電子送金ネットワークを介して送金する多くの既存のシステムには制限がある。例えば、通常の電信送金では、通常、送金者及び受取人の両方が金融機関に物理的に存在する必要があるか、又は金融機関の口座への直接アクセス（例えば、オンラインアクセス）を有する必要がある。送金者及び受取人が金融機関に口座を有するという要件は、人口の非銀行利用者層区分及び／又は金融機関への容易なアクセスを有さない人々等の一部の人々からの／への送金を難しくし得る。更に、金融機関間での送金又は通貨の交換を含む従来の電信送金は、規制が多く、一般に追加料金が必要である。これらの料金は、個人間の送金を非効率的、非実用的、又は他に困難にし得る取引コストの根幹をなし得る。

個人に送金する多くの既存のシステムは、通常生じ得る送金シナリオに対応していない。例として、既存の送金システムは、小売店又は金融機関ではない他の非金融機関の物理的な支払い端末で金銭を送る又は受け取ることを望む人々に資金を提供しないことがある。既存の送金システムは、非金融機関のオンライン支払いプロセスを使用して金銭を送る又は受け取ることを望む人々に資金を提供しないことがある。デビット転送システム並びに小売業者施設及び／又は小売業者ウェブサイトにおいて人々に送金する他のシステムは、コストが法外であり得、及び／又は人々間での送金を促進しないことがある。多くの既存の個人への送金システムは、資金への要求が行われた後、直ちに（例えば、略「リアルタイム」で）資金を提供しないことがある。その結果、多くの場合、個人、特に金融機関の支払いシステムへのアクセスを有さない個人に、電子送金ネットワークを介して費用効率的に送金することが難しいことが証明されている。

本明細書で考察するシステム、方法、及びコンピュータ可読媒体は、自動クリアリングハウス（ＡＣＨ）ネットワーク等の電子送金ネットワークを介して、第２の（例えば、公衆）ネットワークへのアクセスを有する個人にセキュアに送金することに関する。方法例は、送金に関連する取引データを受信することであって、取引データは、送金の送金額、送金の送金者を識別する送金者公開識別子、送金の受取人を識別する受取人公開識別子、送金者金融機関の金融機関識別子、受取人金融機関の金融機関識別子、及び送金者のトークン化金融商品を指定する、受信することと、送金者金融機関の金融機関識別子を使用して、送金者金融機関を特定することであって、送金者金融機関は、支払いネットワークのメンバである、特定することと、送金者金融機関に送金者のトークン化金融商品を提供して、送金者金融機関が送金者のトークン化金融商品をトークン化解除し、且つ送金者に関連付けられた送金者金融機関の口座を識別することを可能にすることと、送金者金融機関から、送金者金融機関によって生成された送金者秘密識別子を受信することであって、送金者金融機関は、送金者に関連付けられた送金者金融機関の口座を確認した場合に送金者秘密識別子を生成する、受信することと、送金者秘密識別子を送金者公開識別子に関連付けることと、送金者金融機関に送金の送金額、受取人公開識別子、及び受取人金融機関識別子を提供して、送金者金融機関が、送金の送金額を満たす、送金者に関連付けられた口座内の金銭の利用可能性を特定することを可能にすることと、送金に関連付けられた取引識別子を生成することと、取引識別子及び受取人秘密識別子を受取人金融機関に提供して、受取人金融機関が、受取人に関連付けられた口座を識別することを可能にして、受取人金融機関がＡＣＨネットワークを介してＡＣＨメッセージを受信することを可能にすることであって、ＡＣＨメッセージは、送金者金融機関から受取人金融機関への支払いを示し、ＡＣＨメッセージは、送金者金融機関によって生成され、且つ送金者と受取人との間での送金を識別する取引識別子を含み、ＡＣＨメッセージは、受取人金融機関がＡＣＨバッチ送金から金銭を取得し、且つ受取人に関連付けられた口座に金銭を入金することを可能にする、可能にすることとを含み得る。

幾つかの実施形態では、本方法は、送金者が、公開識別子を使用して送金を実行する許可を有することを検証することを更に含み得る。本方法は、受取人のトークン化金融商品及び受取人金融機関に関連付けられた受取人ＦＩ識別子を受信することと、受取人ＦＩ識別子を使用して受取人金融機関を特定することであって、受取人金融機関は、支払いネットワークのメンバである、特定することと、受取人金融機関に受取人のトークン化金融商品を提供して、受取人金融機関が受取人のトークン化金融商品をトークン化解除し、且つ受取人に関連付けられた受取人金融機関の口座を識別することを可能にすることと、受取人金融機関から、受取人金融機関によって生成された受取人秘密識別子を受信することであって、受取人金融機関は、送金者に関連付けられた受取人金融機関の口座を確認した場合に受取人秘密識別子を生成する、受信することとを更に含み得る。

本方法は、送金の送金額、送金の送金者を識別する送金者公開識別子、送金の受取人を識別する受取人公開識別子、送金者金融機関の金融機関識別子、受取人金融機関の金融機関識別子、及び送金者のトークン化金融商品を第１のオンライン製品再販業者から受信することを更に含み得る。第１のオンライン製品再販業者は、送金者の金融商品をトークン化して、送金者のトークン化金融商品を作成し得る。金融商品は、送金者金融機関によって発行され得る。

幾つかの実施形態では、本方法は、第１のオンライン製品再販業者と異なる第２のオンライン製品再販業者から受取人のトークン化金融商品を受信することを更に含み得る。第２のオンライン製品再販業者は、受取人の金融商品をトークン化して、受取人のトークン化金融商品を作成し得る。受取人金融機関は、受取人金融機関がＡＣＨメッセージを受信する前に、受取人に関連付けられた口座に送金し得る。本方法は、送金者が送金者からの送金を受け入れるか否かを要求する通知要求を送金者システムに提供することを更に含み得る。

システム例は、１つ又は複数のプロセッサと、１つ又は複数のプロセッサに結合されたメモリとを含む。メモリは、１つ又は複数のプロセッサに方法を実行するように指示するように構成され得る。方法は、送金に関連する取引データを受信することであって、取引データは、送金の送金額、送金の送金者を識別する送金者公開識別子、送金の受取人を識別する受取人公開識別子、送金者金融機関の金融機関識別子、受取人金融機関の金融機関識別子、及び送金者のトークン化金融商品を指定する、受信することと、送金者金融機関の金融機関識別子を使用して、送金者金融機関を特定することであって、送金者金融機関は、支払いネットワークのメンバである、特定することと、送金者金融機関に送金者のトークン化金融商品を提供して、送金者金融機関が送金者のトークン化金融商品をトークン化解除し、且つ送金者に関連付けられた送金者金融機関の口座を識別することを可能にすることと、送金者金融機関から、送金者金融機関によって生成された送金者秘密識別子を受信することであって、送金者金融機関は、送金者に関連付けられた送金者金融機関の口座を確認した場合に送金者秘密識別子を生成する、受信することと、送金者秘密識別子を送金者公開識別子に関連付けることと、送金者金融機関に送金の送金額、受取人公開識別子、及び受取人金融機関識別子を提供して、送金者金融機関が、送金の送金額を満たす、送金者に関連付けられた口座内の金銭の利用可能性を特定することを可能にすることと、送金に関連付けられた取引識別子を生成することと、取引識別子及び受取人秘密識別子を受取人金融機関に提供して、受取人金融機関が、受取人に関連付けられた口座を識別することを可能にして、受取人金融機関がＡＣＨネットワークを介してＡＣＨメッセージを受信することを可能にすることであって、ＡＣＨメッセージは、送金者金融機関から受取人金融機関への支払いを示し、ＡＣＨメッセージは、送金者金融機関によって生成され、且つ送金者と受取人との間での送金を識別する取引識別子を含み、ＡＣＨメッセージは、受取人金融機関がＡＣＨバッチ送金から金銭を取得し、且つ受取人に関連付けられた口座に金銭を入金することを可能にする、可能にすることとを含み得る。

非一時的コンピュータ可読媒体システムは、実行可能命令を含み得、実行可能命令は、方法を実行するようにプロセッサによって実行可能である。方法は、送金に関連する取引データを受信することであって、取引データは、送金の送金額、送金の送金者を識別する送金者公開識別子、送金の受取人を識別する受取人公開識別子、送金者金融機関の金融機関識別子、受取人金融機関の金融機関識別子、及び送金者のトークン化金融商品を指定する、受信することと、送金者金融機関の金融機関識別子を使用して、送金者金融機関を特定することであって、送金者金融機関は、支払いネットワークのメンバである、特定することと、送金者金融機関に送金者のトークン化金融商品を提供して、送金者金融機関が送金者のトークン化金融商品をトークン化解除し、且つ送金者に関連付けられた送金者金融機関の口座を識別することを可能にすることと、送金者金融機関から、送金者金融機関によって生成された送金者秘密識別子を受信することであって、送金者金融機関は、送金者に関連付けられた送金者金融機関の口座を確認した場合に送金者秘密識別子を生成する、受信することと、送金者秘密識別子を送金者公開識別子に関連付けることと、送金者金融機関に送金の送金額、受取人公開識別子、及び受取人金融機関識別子を提供して、送金者金融機関が、送金の送金額を満たす、送金者に関連付けられた口座内の金銭の利用可能性を特定することを可能にすることと、送金に関連付けられた取引識別子を生成することと、取引識別子及び受取人秘密識別子を受取人金融機関に提供して、受取人金融機関が、受取人に関連付けられた口座を識別することを可能にして、受取人金融機関がＡＣＨネットワークを介してＡＣＨメッセージを受信することを可能にすることであって、ＡＣＨメッセージは、送金者金融機関から受取人金融機関への支払いを示し、ＡＣＨメッセージは、送金者金融機関によって生成され、且つ送金者と受取人との間での送金を識別する取引識別子を含み、ＡＣＨメッセージは、受取人金融機関がＡＣＨバッチ送金から金銭を取得し、且つ受取人に関連付けられた口座に金銭を入金することを可能にする、可能にすることとを含み得る。

これら及び他の利点は、以下の説明を読むこと及び図面の幾つかの例の研究から当業者に明らかになる。

実施形態例による、送金者及び受取人が異なる銀行機関を使用する送金システムの概略図を示す。 実施形態例による、資金転送要求のトークンを管理し得るトークン管理論理の概略図を示す。 実施形態例による、送金要求が登録受取人又は非登録受取人による資金受け取りにつながるプロセスを示す。 実施形態例による、送金要求が登録受取人又は非登録受取人による受け取りにつながるプロセスを示す。 ユーザ選好を構成し、他のユーザとの結び付きを管理するのにユーザに提示し得るウェブページの画面例を示す。 通知設定を構成するのにユーザに提示し得るウェブページの画面例を示す。 受取人に送信するのにユーザに提示し得るウェブページの画面例を示す。 ネットワーク外のユーザが支払いを送信する場合にネットワーク外ユーザに提示し得るウェブページの画面例を示す。 実施形態例による、送金者及び受取人が異なる銀行組織を使用する送金システムの概略図を示す。 実施形態例による、ネットワーク外受取人への送信を促進するプロセス例を示す流れ図を示す。 実施形態例による、ネットワーク外送金者からネットワーク内受取人への送金を促進するプロセス例を示す流れ図を示す。 実施形態例による、ネットワーク内送金者からネットワーク外受取人への急速送金を促進するプロセス例を示す流れ図を示す。 幾つかの実施形態による、非金融機関システム送金者から非金融機関システム受取人へセキュアに送金する送金システムの図を示す。 幾つかの実施形態による転送論理の図を示す。 幾つかの実施形態による登録論理の図を示す。 幾つかの実施形態による、送金システムにおいて送金者から受取人にセキュアに送金するデータフローの図を示す。 幾つかの実施形態による、送金システムにおいて送金者から受取人にセキュアに送金する方法のフローチャートの図を示す。 幾つかの実施形態による、送金システムにおいて送金者から受取人にセキュアに送金する方法のフローチャートの図を示す。 幾つかの実施形態による、送金システムにおいて送金者から非登録受取人にセキュアに送金するデータフローの図を示す。 幾つかの実施形態による、送金システムにおいて送金者から非登録受取人にセキュアに送金する方法のフローチャートの図を示す。 幾つかの実施形態による、送金システムにおいて送金者から非登録受取人にセキュアに送金する方法のフローチャートの図を示す。 幾つかの実施形態による、送金システムに参加者を登録するデータフローの図を示す。 幾つかの実施形態による、送金システムに参加者を登録する方法のフローチャートの図を示す。 幾つかの実施形態によるデジタルデバイスの例を示す。

図１を参照して、支払いネットワーク又は「送金支払いネットワーク」を実施する送金システム１００を示す。送金システム１００は、送金者が資金を受取人に送信するため及び受取人が資金を受け取るために利用し得る。送金システム１００は、いずれの当事者も互いにいかなる金融口座情報も開示せずに、送金者から受信者（例えば、受取人）への送金を促進し得る。送金者及び受取人は、個人又はビジネスエンティティであり得る。実施形態例では、送金者は、銀行口座を資金源として使用する。他の実施形態では、送金者は、クレジットカード、デビットカード、ビジネスクレジットカード、又はチェックカードを資金源として使用し得る。送金システム１００は、銀行内転送（すなわち、送金者及び受取人が両方とも同じ銀行に口座を有し、資金が同じ銀行内の口座間で転送される転送）及び銀行間転送（すなわち、送金者及び受取人が異なる銀行に口座を有し、資金が異なる銀行の口座間で転送される転送）の両方で使用し得る。

送金システム１００は、特に、送金者コンピュータシステム１１０、銀行コンピュータシステム１２０、受取人コンピュータシステム１３０、銀行コンピュータシステム１５０、支払いサービスコンピュータシステム１６０、及び自動クリアリングハウスコンピュータシステム１７０を含み得る。上述した各システムは、ネットワーク１４０を通して通信し得、ネットワーク１４０は、インターネット、セルラネットワーク、Ｗｉ−Ｆｉ、Ｗｉ−Ｍａｘ、プロプライエタリ銀行ネットワーク等の１つ又は複数を含み得る。図１及び残りの説明全体を通して、例を提供するために、送金者が、銀行コンピュータシステム１２０により維持される口座からの送金を実行し、受取人が、銀行コンピュータシステム１５０により維持される口座を使用して資金を受け取ると仮定する。したがって、コンピュータシステム１２０は、本明細書では、送金者銀行コンピュータと呼ばれることもあり、コンピュータシステム１５０は、本明細書では、受取人銀行コンピュータシステムと呼ばれることがある。当然ながら、任意の所与の銀行コンピュータシステムが、様々な送金取引に関して異なる容量で動作し得ることが明らかである。更に、本明細書に提供される例は、主に受取人への送金を要求する送金者に関するものであるが、受取人が送金者からの送金を要求し得ることも理解される。

送金者コンピュータシステム１１０は、個々のユーザ（例えば、ビジネスオーナー又は従業員、消費者等）が取引を行い、送金者銀行コンピュータシステム１２０により提供されるウェブサイトのオンライン銀行エリアを通して又は支払いサービス１６０により提供されるウェブサイトを通して提供される銀行機能と対話するのに使用し得る。送金者コンピュータシステム１１０は、例えば、ユーザコンピュータ（例えば、デスクトップ若しくはラップトップコンピュータ）、携帯電話、スマートフォン、モバイルハンドヘルド無線電子メールデバイス、個人情報端末、ポータブルゲーミングデバイス、又は他の適するデバイスを含み得る。送金者コンピュータシステム１１０は、メモリに記憶された命令を実行するように構成される１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含むこともできる。例えば、そのような構成は、送金者が商人又は他のビジネスである場合に利用し得る。

送金者コンピュータシステム１１０は、ネットワークインターフェース論理１１２、表示デバイス１１４、入力デバイス１１６、及びクライアントアプリケーション１１８を含み得る。ネットワークインターフェース論理１１２は、例えば、送金者コンピュータシステム１１０をネットワーク１４０に接続するプログラム論理を含み得る。以下に更に詳細に説明するように、例えば、送金者コンピュータシステム１１０は、口座情報、取引命令等を含む画面を受信し、表示デバイス１１４に表示し得る。実施形態例では、そのような画面を使用してユーザ名及びパスワード情報を要求し得る。そのような画面は、資金額及び資金を受け取るべき商人又は個人の識別情報に関する情報を提供するようにユーザに促すのにも使用し得る。そのような情報は、例えば、氏名、住所、電話番号、電子メールアドレス、又は電子ディレクトリからの受取人の選択、及び／又は他の情報を含み得る。そのような画面は、過去の取引に関する情報を表示する画面を含むこともできる。そのような画面は、表示デバイス１１４を介してユーザに提示される。入力デバイス１１６は、ユーザが口座アクセスを開始できるようにし、ユーザからの送金要求情報の受信を促進するのに使用し得る。

クライアントアプリケーション１１８は、本明細書に記載される機能の少なくとも幾つかを実施するように構成されるプログラム論理（すなわち、記憶された実行可能命令）を含み得る。理解されるように、送金システム１００の他の構成要素と比較して、送金者コンピュータシステム１１０に常駐する機能のレベルは、実施形態に応じて様々であり得る。クライアントアプリケーション１１８は、単純に銀行コンピュータシステム１２０からウェブページを受信し、受信したウェブページを表示するように構成されるウェブブラウザ（例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）、Ｍｏｚｉｌｌａ Ｆｉｒｅｆｏｘ（登録商標）、Ｃｈｒｏｍｅ（登録商標）、Ｓａｆａｒｉ（登録商標）等）であり得る。クライアントアプリケーションは、モバイルウェブブラウザ、テキストメッセージ（ＳＭＳ）インターフェース、専用アプリケーション、又はネットワーク１４０を介して情報を送受信するのに適する他のプログラムを含むこともできる。

銀行コンピュータシステム１２０は、普通預金口座、クレジットカード口座、住宅抵当貸し付け、学生ローン等の顧客により保持される口座を維持する銀行機関により運営される。銀行コンピュータシステム１２０は、例えば、メモリに記憶された命令を実行し、メモリに記憶されたデータを送受信し、他の動作を実行して、図１〜図７に示される論理又はプロセスに関連する、本明細書に記載される動作を実施するように構成される１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含み得る。

銀行コンピュータシステム１２０は、ネットワークインターフェース論理１２２、口座処理論理１２４、口座データベース１２６、及び情報ディレクトリ１２８を含み得る。ネットワークインターフェース論理１２２は、例えば、銀行コンピュータシステム１２０をネットワーク１４０に接続するプログラム論理を含み得る。ネットワークインターフェース論理１２２は、銀行と送金者及び／又は受取人との間のセキュア通信を促進し得る。ネットワークインターフェース論理１２２は、他の銀行、決済システム等の他のエンティティとの通信を促進することもできる。ネットワークインターフェース論理１２２は、ウェブページを生成し、ネットワーク１４０を介して銀行コンピュータシステム１２０にアクセスするユーザにウェブページを提示するように構成されるユーザインターフェースプログラム論理を含み得る。

口座処理論理１２４は、口座処理を実行して、当座預金口座及び預金口座への口座貸方記入及び借方記入、住宅抵当貸し付けへの貸方記入及び借方記入等の口座保有者の口座に関連する取引を処理する。したがって、資金が口座保有者（例えば、資金の送金者又は受取人）の口座内又は外に送金される場合には常に、口座処理論理１２４は、口座データベース１２６内の適切な借方又は貸方を反映し、口座データベース１２６は、顧客の代理として銀行により維持される口座についての口座情報（例えば、取引、口座保有者についての情報等）を記憶する。口座処理論理１２４はまた、送金者コンピュータシステム１１０を使用する送金者から、受取人コンピュータシステム１３０を使用する受取人に送金する送金要求を処理することもできる。

情報ディレクトリ１２８は、送金の受取人の識別に銀行口座／銀行支店コード以外の識別子が使用される場合（例えば、電子メールアドレス、電話番号、共通支払識別コード（ＵＰＩＣ）、乱数等）に使用され得る。情報ディレクトリ１２８は、金融機関が受取人の携帯電話番号（又は電子メールアドレス若しくは他の識別子）を受取人の銀行口座の銀行口座番号／銀行支店コードに変換／相関付けられるようにするために維持されるデータベースであり得る。この構成により、送金者は、必ずしも受取人に関するプライベート／個人情報（すなわち、受取人の銀行口座／銀行支店コード）を有する必要なく、受取人を一意に識別することができる（例えば、電子メールアドレス又は他の識別子を用いて）。

ユーザは、任意の金融取引前に情報を情報ディレクトリ１２８に登録し得る。ユーザは、銀行コンピュータシステム１２０を通して送金システム１００に登録すると、情報ディレクトリ１２８に追加され得る。登録されると、情報ディレクトリ１２８を実施するデータベースに、新たに登録されたユーザの新しいエントリを作成し得る。ユーザは、ユーザが、相互作用する（例えば、他の個人と通信するために、人々がそのような他の個人と電話番号及び電子メールアドレスを選択的又は自由に共有するのと同じように）他の個人と共有し得る１つ又は複数の識別子（例えば、電話番号、電子メールアドレス等）を提供し得る。本明細書では、そのような識別子は「公開識別子」又は「公開トークン」と呼ばれる。（「識別子」及び「トークン」という用語は、本明細書では、ユーザを識別するコード（例えば、電子メールアドレス、電話番号、ユーザ生成又はシステム生成の文字列等）を指すために同義で使用される）。情報ディレクトリ１２８は、セキュアに維持され、情報ディレクトリ１２８においてユーザを識別するのに使用される識別子を生成し、又は他に関連付けることもできる。本明細書では、そのような識別子は「秘密識別子」と呼ばれる。秘密識別子は、例えば、情報ディレクトリ１２８内のユーザのデータベースエントリの一意のＩＤであり得る。秘密識別子は情報ディレクトリ１２８により既知であるが、秘密識別子が関連付けられるユーザ又は他のユーザにより知られる必要はない。しかし、秘密識別子は、送金支払いネットワークのメンバである銀行及び他のエンティティにより知られ得る。公開識別子（例えば、電話番号、電子メールアドレス等）、秘密識別子（例えば、データベースＵＩＤ）に加えて、銀行にユーザが保持する口座及びユーザ選好についての口座情報（口座番号、銀行支店コード等）等の他の情報をデータベースエントリに記憶することもできる。この情報の少なくとも幾つかは、例えば、ユーザが、銀行コンピュータシステム１２０でのセキュアなオンラインバンキングセッション中、送金システム１００に登録する場合に自動的に記入し得る。

更に、各ユーザのデータベースエントリは、そのユーザに結び付けられた他のユーザのレジストリを記憶することもできる。すなわち、ユーザ毎に、ユーザが確立された結び付きを有する他の各ユーザのリストを含むレジストリを記憶し得る。そのような結び付きは、例えばユーザが資金を送信するか、又は他のユーザから資金を受け取る最初のときに確立し得る。結び付きは、ユーザが、情報ディレクトリ１２８及び／又は別の情報ディレクトリ内のルックアップサービスを通して、他のユーザとの結び付きを追加できるようにするユーザインターフェースにより確立することもできる。そのようなユーザインターフェースの例については、図４に関連して以下に考察する。ユーザは、送金支払いネットワークに登録しているユーザのみならず、更に詳細に以下に考察するように他の関連支払いネットワークも含み得る。レジストリ内のユーザ毎に、ユーザの一意のＩＤ及び／又は他の情報等の追加情報を追加し得る。別の例として、他のユーザについての情報を情報ディレクトリ１２８内の別個のデータベースエントリに記憶し得る。

様々な実施形態では、複数の情報ディレクトリが存在し得、各ディレクトリは異なる機関又はエンティティにより維持される。例えば、銀行コンピュータシステム１２０に関連付けられた銀行に口座を保持するユーザは、銀行コンピュータシステム１２０を通して登録し得、銀行コンピュータシステム１５０に関連付けられた銀行に口座を保持するユーザは、銀行コンピュータシステム１５０を通して登録し得、他のエンティティに口座を保持する他のユーザに関しても以下同様である。そのようなエンティティは、非銀行エンティティ（例えば、支払い処理企業、クレジットエージェンシー、クレジットカードネットワークプロバイダ等）を含むこともでき、ユーザはそのような非銀行エンティティを通して登録することもできる。

本明細書に既に記載された公開識別子及び秘密識別子に加えて、追加の識別子を使用することもできる。例えば、そのような追加の識別子は、様々なセキュリティレベルで扱われ得る。別の例として、更に詳細に以下に考察するように、既存の公開識別子の変形を使用して特殊公開トークン、カスタマイズされた機能を有する公開トークン等を実施し得る。

トークン管理論理１２９はトークンを管理する。例えば、トークン管理論理１２９は、トークンを登録し、トークンを認証し、トークンを生成等するように構成し得る。トークン管理論理１２９は、トークンが認識されない場合、受取人の識別を促進することもできる。トークン管理論理１２９は、特定の口座が使用され、特定の通知方法が使用される等であるように、トークンの属性をカスタマイズするのに使用することもできる。トークン管理論理１２９については、図２に関連して以下に更に詳細に考察する。

受取人コンピュータシステム１３０は、本明細書に記載の他のコンピュータシステムと概して同じように構成し得る。例えば、資金受取人が個人である場合、コンピュータシステム１３０は、携帯電話、スマートフォン、モバイルハンドヘルド無線電子メールデバイス、個人情報端末、ポータブルゲーミングデバイス、デスクトップコンピュータ、又は他の適するデバイス等のモバイルデバイスであり得る。コンピュータシステム１３０は、メモリに記憶された命令を実行するように構成される１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含むこともできる。例えば、そのような構成は、受取人が商人又は他のビジネスである場合に利用し得る。

一実施形態（例えば、受取人が従来型の商人である）では、受取人コンピュータシステム１３０は、顧客から公開トークン情報を電子的に取得するように備えられた販売時点管理デバイス（例えば、キャッシュレジスターシステム）を含み得る。例えば、キャッシュレジスターシステムは、近距離通信（ＮＦＣ）装備の携帯電話から公開トークン（例えば、携帯電話番号）を読み取ることが可能なＮＦＣリーダーデバイスを含み得る。別の例として、携帯電話は、バーコード又は公開トークンを含む他の画像を表示画面に生成するように構成され、キャッシュレジスターシステムは、バーコードを読み取るように構成されたバーコードリーダーを含み得る。次に、受取人コンピュータシステム１３０は、販売時点で得られる公開トークンを使用して、送金システム１００を介して送金者からの支払いを要求し得る。

受取人銀行コンピュータシステム１５０は、送金者銀行コンピュータシステム１２０と同様に構成し得る。したがって、銀行コンピュータシステム１５０は、ネットワークインターフェース論理１５２、口座処理論理１５４、口座データベース１５６、並びに銀行コンピュータシステム１２０のネットワークインターフェース論理１２２、口座処理論理１２４、口座データベース１２６、及び情報ディレクトリ１２８に対応する情報ディレクトリ１５８を含む。

支払いサービスコンピュータシステム１６０には、銀行間送金、例えば、上述したような非銀行エンティティにより提供される支払いサービスを促進するように構成された支払いサービスを関連付け得る。支払いサービスは、例えば、銀行間及び／又は送金システム１００を使用して資金を送受信する他のエンティティ間の合弁事業として形成されるエンティティであり得る。別の例として、支払いサービスは第三者ベンダーであり得る。別の例として、支払いサービスは、個人がユーザ名／ログインＩＤを取得し、又は他に登録メンバになる、そのような個人のオンラインコミュニティに提供されるウェブポータルであり得る。個人は、例えば、ウェブポータルを使用して互いと対話し、及び／又はオンラインコミュニティにより提供されるサービスと対話し得る。オンラインコミュニティの例としては、ＭＳＮ（登録商標）、ｉＰｈｏｎｅ（登録商標）ユーザ、Ｆａｃｅｂｏｏｋ（登録商標）、ＬｉｎｋｅｄＩｎ（登録商標）等が挙げられる。支払いサービスは、例えば、ウェブポータルからオンラインコミュニティのメンバに提供される追加のサービスであり得る。別の例として、支払いサービスは、銀行の１つにより、すなわち、銀行が、銀行コンピュータシステム１２０／１５０により実行されるものとして本明細書に記載される動作及び支払いサービスコンピュータシステム１６０により実行されるものとして本明細書に記載される動作の両方を実行するように提供し得る。

本明細書では、コンピュータシステム１２０及び１５０に関連付けられた銀行は、「メンバ銀行」であると仮定される。すなわち、コンピュータシステム１２０及び１５０に関連付けられた銀行は、送金システム１００を使用して送金する、確立したプロトコルに従うと仮定される。例えば、合弁事業として作成される支払いサービスに関して、メンバ銀行は、少なくとも、合弁事業の共同所有者である銀行及び潜在的に他の銀行を含み得る。２つのメンバ銀行が図１に示されているが、追加のメンバ銀行があり得ることが理解される。更に、先に示したように、非銀行エンティティがメンバであることもできる。支払いサービスは、非メンバ銀行に銀行口座を有する送金者及び受取人によっても、例えば、そのようなユーザが支払いサービスコンピュータシステム１６０に直接登録できるようにすることにより使用し得る。したがって、ユーザは、送金システム１００の使用が可能であるため、いかなる特定の銀行の顧客である必要もない。

支払いサービスコンピュータシステム１００は、例えば、メモリに記憶された命令を実行し、メモリに記憶されたデータを送受信し、他の動作を実行して、図１〜図６に示される論理又はプロセスに関連付けられた本明細書に記載の動作を実施するように構成される１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含み得る。支払いサービスコンピュータシステム１６０は、ネットワークインターフェース論理１６２及び情報ディレクトリ１６８を含む。特に示されていないが、支払いサービスコンピュータシステム１６０が、口座処理論理１２４、１５５及び口座データベース１２６、１５６と同じように又は同様に口座処理論理及び口座データベースを含み得ることが理解される。ネットワークインターフェース論理１６２は、ウェブページを生成し、ネットワーク１４０を介して支払いサービスコンピュータシステム１６０にアクセスするユーザに提示するように構成されるユーザインターフェースプログラム論理を含み得る。

情報ディレクトリ１６８は、銀行口座／銀行支店コード以外の識別子が使用される（例えば、電子メールアドレス、電話番号、共通支払識別コード（ＵＰＩＣ）、乱数等）場合に使用し得る。情報ディレクトリ１２８及び１５８に関連して上述したように、情報ディレクトリ１６８は、支払いサービスが受取人の携帯電話番号（又は電子メールアドレス又は他のトークン）を、支払いコンピュータサービスシステム１６０を通して登録したユーザの受取人の銀行口座の銀行口座番号／銀行支店コードに変換できるようにするのに維持されるデータベースである。この構成により、送金者は、必ずしも受取人に関するプライベート／個人情報（すなわち、受取人の銀行口座／銀行支店コード）を有する必要なく、受取人を一意に識別することができる（例えば、電子メールアドレス又は他の識別子を用いて）。

送金者及び受取人を含むユーザは、例えば、そのようなユーザがいかなる他のメンバエンティティともバンキングせず、又はいかなる他のメンバエンティティの口座も有さない場合、ユーザの情報を情報ディレクトリ１６８に事前に登録し得る。更に、支払いサービスコンピュータシステム１６０は、送金のみを望むユーザが、登録せずにそれを行うことができるように構成し得る。例えば、支払いサービスコンピュータシステム１６０は、送金者が送金を望むたびに送金者が支払いサービスコンピュータサービスシステム１６０に登録する必要なく、送金者からクレジットカード情報を受信して、取引を完了するウェブページを生成するように構成し得る。

理解されるように、情報ディレクトリ１６８に記憶される情報は、情報が情報ディレクトリ１２８及び１５８にも記憶される程度を含め、実施形態に応じて様々であり得る。例えば、一実施形態では、ユーザが銀行コンピュータシステム１２０（又は銀行コンピュータシステム１５０又は別のメンバエンティティのコンピュータシステム）に登録する場合、情報は、情報ディレクトリ１２８及び情報ディレクトリ１５８の両方に記憶し得る。情報ディレクトリ１２８は、ユーザの銀行口座及の完全な識別情報及び登録中に収集される他の情報を記憶し得る。逆に、情報ディレクトリ１６８は、登録された公開トークン、関連付けられた金融機関、及び各トークンに関連付けられた秘密トークン（例えば、一意のＩＤ）等のより少量の情報を記憶し得る。より詳細な銀行口座番号／銀行支店コード又は他の機密情報は、情報ディレクトリ１６８に記憶する必要がない。別の実施形態では、支払いサービスコンピュータシステム１６０を使用して、情報ディレクトリ１６８を維持する代わりに、そのような情報は、全体的に、個々のメンバ銀行により維持される情報ディレクトリ１２８、１５８に記憶し得る。これも理解されるように、口座処理論理１２４、１５４において取引詳細が追跡され、維持される程度は、取引詳細が支払いサービスコンピュータシステム１６０により追跡され、維持される程度と比較して、実施形態に応じて様々であり得る。

自動クリアリングハウス（ＡＣＨ）システム１７０は、送金者及び受取人の銀行口座と資金をやりとりするのに使用される。既知のように、ＡＣＨネットワークは、参加している預貯金取り扱い金融機関の電子支払いの銀行間決済に提供される、全国的なバッチ処理指向電子送金システムである。ＡＣＨエントリは、口座保有者（ＡＣＨ用語では受信者として知られている）が、オリジネータ（例えば、個人又は企業）が口座に対してＡＣＨデビット又はクレジットを発行するのを認証することで開始し得る。ＡＣＨ取引に応じて、オリジネータは、レシーバから認証を受信しなければならない。ＡＣＨの規則及び規制によれば、金融機関は、レシーバからの事前認証なしでは、口座に向けてＡＣＨ取引を発行しない（それがデポジットであれ、クレジットであれ関係なく）。認証が受信されると、オリジネータは、発信側受託金融機関（ＯＤＦＩ）に与えられるＡＣＨエントリを作成し、これは、ＡＣＨオリジネーションを行う任意の金融機関であり得る。このＡＣＨエントリは、次にＡＣＨオペレータ（すなわち、金融機関がＡＣＨエントリを送信又は受信する中央決済施設）に送信され、受信側受託金融機関（ＲＤＦＩ）に渡され、ここで、レシーバの口座がＡＣＨ取引に応じてクレジット又はデポジットのいずれかで発行される。しかし、ＲＤＦＩは、ＡＣＨ取引を拒絶し、口座内の資金が不十分であった又は取引が承認されていないことを口座保有者が示した等の適切な理由と共にＯＤＦＩにＡＣＨ取引を返し得る。ＲＤＦＩは、リターンを実行する規定量の時間（例えば、ＡＣＨ取引の受信から２日〜６０日）を有する。ＡＣＨエントリのリターンを受信するＯＤＦＩは、ＡＣＨエントリを２回以上又は合計で３回まで決済のために再提示し得る。再び、ＲＤＦＩは取引を拒絶し得、その後、ＯＤＦＩはもはやＡＣＨを介して取引を表さない。ＡＣＨシステムの上記説明は、現在使用されているものであり、本発明の実施形態は、ＡＣＨシステムでの幾つかの方法及びステップが変更される場合であっても、引き続き同様に機能する。

図２を参照すると、図２は、トークン管理論理１６９を更に詳細に示す。図２に示されるように、トークン管理論理１６９は、スポンサー識別又はスポンサーサーチ論理１８２、登録論理１８４、トークン認証論理１８６、規則エンジン１８８、及びトークン生成論理１９０を含む。トークン管理論理１６９は示されているが、トークン管理論理１２９及び１５９を同じように又は同様に構成し得ることが理解される。

スポンサー識別論理１８２は、トークンのスポンサーを識別するように構成し得る。例えば、送金者がトークンを使用して、送金者銀行コンピュータシステム１２０の情報ディレクトリ１２８において認識されない（すなわち、受取人が送金者銀行の顧客ではないため）受取人を識別する場合、スポンサー識別論理１８２は、トークンを送金者銀行コンピュータシステム１２０から受信し、情報ディレクトリ１６８にアクセスして、そのトークンに関連付けられた一意のＩＤ及び金融機関の識別情報を提供するように構成し得る。

理解されるように、銀行コンピュータシステム１２０、１５０が、スポンサー識別論理１８２と同じように動作するスポンサー識別論理を有する程度は、部分的に、その情報が情報ディレクトリ１２８及び１５８にも記憶される程度と比較して、その情報が情報ディレクトリ１６８に記憶される程度に依存し得る。様々な実施形態では、エンティティ間の送金に関連して集中化されてユーザ識別機能を実行するために、より大きい程度又はより小さい程度で情報ディレクトリ１６８に依拠し得る。本明細書では、例を提供するために、情報ディレクトリ１６８が使用されて、エンティティ間の送金に関連して集中化されてユーザ識別機能を実行すると仮定される。そのような実施形態では、スポンサー識別論理１８２及び銀行コンピュータシステム１２０、１５０の機能を全て複製することを回避することが可能であり得る。

一実施形態では、送金支払いネットワークは、他の関連支払いネットワーク（例えば、ＰａｙＰａｌ（登録商標）、ＣａｓｈＥｄｇｅ等）と対話するように構成される。そのような構成では、送金者銀行コンピュータシステム１２０により提供されるトークンが情報ディレクトリ１６８において認識されない場合、スポンサー識別論理１８２は、問い合わせを他の関連支払いネットワークに送信して（例えば、所定のシーケンスで）、トークンが他の関連支払いネットワークのいずれかで認識されるか否かを特定するように構成される。受取人が別の支払いネットワークに登録している場合、他のその支払いネットワークを通して資金をルーティングすることにより、受取人に送金し得る。ユーザルックアップサービスが情報ディレクトリ１６８により提供される実施形態では、ルックアップサービスは、同じように動作して、リモートエンティティに登録されたユーザを識別し得る。そのトークンに関連付けられていると特定された支払いネットワークを識別する情報を情報ディレクトリ１６８に記憶することもでき、それにより、将来、そのトークンへの更なる送金に役立つ。したがって、そのような構成では、送金支払いネットワークに登録しておらず、むしろ、別の支払いシステムに登録している受取人に資金をプッシュし得る。更に、そのような資金は、受取人が送金支払いネットワークに登録しているか否かについて送金者が知る又は考慮する必要なく、受取人にプッシュし得る。

登録論理１８４は、新規ユーザを登録するプロセスを促進するように構成される。例えば、先の考察では、トークンが情報ディレクトリ１６８において認識され、いかなる他の関連支払いネットワークにも登録されていない場合、登録論理は、受取人を支払いネットワークに登録するように案内する電子メール又は他の通信を受取人に送信するように構成し得る。そのような電子メールは、支払いサービスコンピュータシステム１６０により提供されるウェブサイトへのリンクを含み得る。登録論理１８４は、ウェブサイトでユーザに提示されるウェブページを生成して、登録プロセスを促進するように構成し得る。ウェブサイトでの登録時、ユーザにより提供される情報に基づいてユーザがメンバエンティティの１つの顧客であると特定される場合、ユーザは、登録プロセスを完了するために、そのメンバエンティティのウェブサイトに転送され得る。理解されるように、登録論理１８４は、他のシナリオ（例えば、ユーザがサーチエンジンクエリの結果としてそのウェブサイトを訪問した場合、ユーザが別のウェブサイト（例えば、オンラインコミュニティウェブサイト又は業者ウェブサイト）を介してそのウェブサイトを訪問した場合等）でウェブページをユーザに提示することもできる。登録論理１８４は、ユーザから受信した入力を表す新しいデータベースエントリを情報ディレクトリ１６８に作成し得る。

トークン認証論理１８６は、トークンを認証するように構成される。例えば、ユーザが新しいトークンを登録する場合、トークン認証論理１８６は、ユーザがそのトークンに関連付けられていること（例えば、トークンとして携帯電話番号を登録しようとしているユーザが実際にその携帯電話番号の所有者であること）を確認するように構成し得る。（本明細書では、電話番号に関する「所有」という用語は、電話番号が、他のユーザに割り当てられているのとは対照的に、一人の特定のユーザに割り当てられていることを指し、ユーザと電話番号をユーザに提供する電話キャリアとのいずれをとるかに関する所有権を指すために使用されていない。この用語は、電子メールアドレスに関しても同様に使用される）。別の例として、ユーザが新しい電子メールアドレスを登録しようとする場合、認証論理１８６は、新しい電子メールアドレスでユーザに新しい電子メールを送信する等の認証動作を実行し得る。電子メールは、例えば、登録プロセスを問題なく完了するためにユーザがアクセスしなければならない特定のリンクを含み得る。

更に、トークン認証論理１８６は、前に登録されたトークンに対して認証動作を実行するように構成し得る。例えば、携帯電話番号を登録するユーザは、最終的に携帯電話番号及び／又は携帯電話キャリアを切り替え得る。トークン認証論理１８６は、携帯電話キャリアにより公開され、そのキャリアにより解約された携帯電話番号を列挙した解約ディレクトリを処理するように構成し得る。例えば、登録された携帯電話番号が解約されたものとして列挙されている場合、トークン認証論理１８６は、ユーザの登録された電子メールアドレスに電子メールを送信して、携帯電話番号がもはやそのユーザの有効なトークンではないかどうか、又はユーザが単に携帯電話キャリアを変更したのみであるが、携帯電話番号を維持しているかどうかを特定し得る。

トークン認証論理１８６は、トークンを使用して別のユーザに金銭を送信／別のユーザから金銭を受信しようとするユーザに、その別のユーザがトークンの正しい所有者であるか否かに関して不確実である場合、フォローアップ通信を送信するように構成することもできる。例えば、トークン認証論理１８６は、そのような不確実性が存在することを送金者に通知し、受取人に関して提供された確認情報を提供するように送金者に要求し、受取人に関する追加情報を提供する等を行うように構成し得る。例えば、ユーザがトークンｊｓｍｉｔｈ＠ａｂｃ−ｃｏｍｐａｎｙ．ｃｏｍを使用して送金しようとする場合、トークンｊｓｍｉｔｈ＠ａｂｃ−ｃｏｍｐａｎｙ．ｃｏｍの所有権が変更されたか否か（例えば、ＡＢＣ社の従業員の変更に起因して）に不確実性がある場合、電子メールをユーザに送信し得る。認証論理１８６は、他のネットワーク又はオンラインコミュニティ（例えば、Ｆａｃｅｂｏｏｋ（登録商標）、ＬｉｎｋｅｄＩｎ（登録商標）等）にアクセスして、トークンの認証に使用し得る追加情報を取得するように構成することもできる。トークン認証論理１８６は、使用日時及び特定の受取人が特定の公開トークンの使用を停止した日時により、変化しつつある公開トークンを追跡するように構成することもできる。

したがって、登録論理１８４及び認証論理１８６は協働して、トークンの登録を促進し、トークンが正しい所有者に関連付けられることを保証する。一実施形態では、トークンを登録するエンティティは、登録の有効性を保証する責任を負う。例えば、受取人銀行がトークン４１５−５５５−１２２６を登録し、続けて、トークン４１５−５５５−１２２６を登録したユーザへの支払いを受け入れる場合、トークン４１５−５５５−１２２６を登録したユーザが実際には送金時にその携帯電話番号の所有者ではない（例えば、前の所有者が携帯電話番号を変更し、新しい所有者が異なる支払いネットワークにいるため）とき、受取側銀行は、送金者に金銭をリファンドする責任を負う。したがって、受取側銀行は、登録時にユーザを正しく認証し、解約ディレクトリを日常的に処理して、認証が有効な状態のままであることを保証する責任を負う。

一実施形態では、保証（及び／又は情報ディレクトリ１６８への制限付きアクセス）は、第三者にサービスとして提供し得る。例えば、金銭を顧客にリファンドしているオンライン再販業者は、顧客により前に提供されたトークン（例えば、「４１５−５５５−１２２６」）が正確なままであることを確認することを望み得る。資金が「４１５−５５５−１２２６」トークンにおける顧客にリファンドされるが顧客がもはやそのトークンを所有しない場合、支払いサービスは、資金を正しい顧客にリファンドする責任を負う。サービスに課される料金は、例えば、不正確な情報を提供することについて支払いサービスが受け入れる責任のドル価に基づき得る。別の例として、トークン当たりの料金が、トークンに基づいてユーザを識別し、及び／又はユーザの識別情報に基づいてトークン（例えば、電子メールアドレス、携帯電話番号等）を識別するのに課されるサービスを提供し得る。

ルールエンジン１８８は、ユーザが異なるトークンに異なる属性を構成できるように構成し得る。属性は、ユーザ指定の選好に基づいて構成されるルールで指定し得る。様々な実施形態では、ルールエンジン１８８は、ユーザがルールのカスタマイズを選択するまで使用されるデフォルト設定をユーザに提供し得る。例えば、ルールエンジン１８８を使用して、銀行でユーザが保有する様々な口座に向けられる方法（例えば、資金の少なくとも一部を転送し、又は特定のタイプの口座に送金する）等を構成し得る。別の例として、資金は、ユーザにより指定されるルールに従って複数の口座に分け得、例えば、資金は、退職金口座、普通預金口座、ＰａｙＰａｌ（登録商標）口座、又は譲渡性預金証書の少なくとも１つに転送することもできる。別の例として、受け取った資金の一部は、支払いネットワークに登録した異なるユーザに転送し得る。別の例として、ルールエンジン１８８を使用して、送金要求が送金者により行われた受取人を通知する通知が受取人に送信される方法を構成し得る。例えば、一実施形態によれば、ルールは、通知が送信されるチャネル（電子メール、テキストメッセージ、ボイスメール等）、通知が送信される電子メールアカウント及び／又は電話番号等を指定するように構成し得る。別の例として、送金額が閾値よりも大きい場合、ユーザは、電子メッセージの代わりに自動電話コールを受け取り得、又はメッセージがない代わりに電子メール／電話コールを受け取り得る。別の例として、送金要求が特定の送金者を発端とする場合、ユーザは、通知モードを指定し得る（例えば、電子メール、ボイスメール、又はテキストメッセージ）。別の例として、ルールエンジン１８８を使用して、受取人への送金に使用される支払いチャネル（例えば、ＡＣＨ転送、クレジットカードネットワーク、ＰａｙＰａｌ（登録商標）ネットワーク、印字され郵送される小切手等）を構成し得る。別の例として、ルールエンジン１８８を使用して、受取人に送金されるスピード（例えば、即座、同日、翌日、翌々日支払い等）を構成し得る。別の例として、ルールエンジン１８８を使用して取引限度を構成し得る（例えば、１日、１週間、１ヶ月等の所定の時間期間中、＄５００を超える金額を特定のトークンに課すことができないことを保証するために）。

トークン生成論理１９０は、ユーザの追加の公開トークンを生成するように構成し得る。トークン生成論理１９０は、ルールエンジン１８８と協働して、異なる属性が構成された異なるトークンを作成し得る。例えば、会社は、会社内の誰が特定の取引を担当しているかに応じて、異なる個々のトークンを使用することを望み得る。例えば、幾つかのアパートを所有している大家である受取人は、各アパートに異なるトークンを作成することを望み得る。例えば、追加のトークンは、ユーザ提供の英数字文字列の基づいてもよく、疑似ランダム英数字文字列に基づいてシステムにより生成されてもよく、又は別の方法で生成されてもよい。例えば、大家である受取人が既に電子メールアドレスを公開トークンとして使用している（例えば、ｌａｎｄｌｏｒｄ＠ｍａｉｌ．ｃｏｍ）場合、追加の公開トークンは、受取人が既に使用している公開トークンの変形（例えば、ｌａｎｄｌｏｒｄ＠ｍａｉｌ．ｃｏｍ／ｂｕｉｌｄｉｎｇ１、ｌａｎｄｌｏｒｄ＠ｍａｉｌ．ｃｏｍ／ｂｕｉｌｄｉｎｇ２、ｌａｎｄｌｏｒｄ＠ｍａｉｌ．ｃｏｍ／ｂｕｉｌｄｉｎｇ３等）であり得る。次に、そのようなトークンには、ルールエンジン１８８を使用して異なる属性を構成し得る。例えば、異なる建物のそれぞれが異なる建物管理者を有する場合、アパートのテナントが家賃を払うとき、その特定のアパートの各建物管理者の電子メールアドレスに電子メールを送信し得る。

別の例として、大家である受取人は、各テナントに、テナントが家賃を支払うために使用する異なる公開トークンを提供し得る。ここでも、例えば、追加のトークンは、受取人が既に使用している公開トークンの変形であり得る（例えば、ｌａｎｄｌｏｒｄ＠ｍａｉｌ．ｃｏｍ／ｕｎｉｔ１０１、ｌａｎｄｌｏｒｄ＠ｍａｉｌ．ｃｏｍ／ｕｎｉｔ２、ｌａｎｄｌｏｒｄ＠ｍａｉｌ．ｃｏｍ／ｕｎｉｔ３等）。次に、銀行コンピュータシステム１５０は、各テナントから資金を受け取り得、全ての資金は大家に属する１つ又は複数の口座に送信し得る。口座処理論理１５４は、各トークンに関連して受け取った資金を示すリポートを生成する（それにより、例えば、いずれのテナントが所与の月に支払ったか及びいずれのテナントが所与の月に依然として支払っていないかを示す）ように構成する。トークンには、追加の情報、例えば、予期される毎月の支払額をプログラムすることもできる。次に、口座処理論理１５４は、実際に受け取った金額を予期される毎月の支払いと比較して、テナントが完全に支払いを済ませたことを保証し、テナントの口座ステータス全体を追跡するように構成し得る。

別の例として、受取人は、使い捨てトークンを構成することもできる。例えば、受取人は、他のユーザがイベントに金融的に寄与することが予期されるイベントを組織中であり得る。その場合、受取人は、他のユーザに提供し得るトークン（例えば、ｊｏｈｎｓｍｉｔｈ＠ｍａｉｌ．ｃｏｍ／ｍｏｍｓ−ｂｉｒｔｈｄａｙ−ｐａｒｔｙ）を構成し得る。次に、口座処理論理１５４は、そのトークンに関連する他のユーザのそれぞれから受け取った資金を示すリポートを生成し得る。

別の例として、送金者は、異なるトークンを構成することもできる。例えば、送金者は、第１のトークンをデフォルトトークンとして使用し（例えば、ｊｏｈｎｓｍｉｔｈ＠ｍａｉｌ．ｃｏｍ）、支払いを他の口座から行うべきである場合、追加の専用トークン（例えば、大学費用資金から授業料の支払いを行うためのｊｏｈｎｓｍｉｔｈ＠ｍａｉｌ．ｃｏｍ／ｃｏｌｌｅｇｅｓａｖｉｎｇｓ）を作成し得る。

別の例として、上述したように、情報ディレクトリ１２８、１５８、１６８は、他のユーザとの結び付きを確立するのにユーザが使用し得るルックアップサービスを提供し得る。そのような実施形態では、ユーザは、他のユーザに表示されるトークンの側面を構成可能であり得る。例えば、個人が別の名前で商売をしている（例えば、Ｊｏｓｅｐｈ Ｓｍｉｔｈ ＤＢＡ「ジョーの芝刈りサービス」）場合、口座の名前が実際には個人の名前である場合であっても、会社名が他のユーザに表示されるように、ユーザがトークンを構成できるようにすることが望ましいことがある。このようにすれば、商売の顧客はより容易に商売との結び付きを確立し得る。

図３Ａ及び図３Ｂを参照すると、図３Ａ及び図３Ｂは、資金が実施形態例に従って登録又は非登録受取人に受け取られ得るプロセスを示す。図３Ａ及び図３Ｂでは、送金メッセージが送金者銀行コンピュータシステム１２０において送金者から受信され、受取人銀行コンピュータシステムに伝搬され、受取人銀行コンピュータシステムにおいて資金を受取人の口座に入金させる。特に、図３Ａのステップ３０１において、送金者銀行コンピュータシステム１２０は、トークンを使用して受取人を識別する送金要求を送金者から受信する。ステップ３１１において、銀行コンピュータシステム１２０は、情報ディレクトリ１２８をサーチして、トークンが送金者銀行に登録されたユーザに関連付けられている（すなわち、同じ銀行内の送金である）か否かを特定する。トークンが送金者銀行に登録しているユーザに関連付けられる場合、ステップ３１３において、受取人の口座情報が情報ディレクトリ１２８から取得される。続けて、ステップ３１５において、受取人の口座に送信される。図４〜図６に関連して以下に更に詳細に考察するように、送金者及び受取人の選好に基づいて受取人の金融口座に送金し得る。

ステップ３１１において、受取人が送金者銀行に登録していない場合、プロセスはステップ３２１に進む。ステップ３２１において、銀行コンピュータシステム１２０は、問い合わせを支払いサービスコンピュータシステム１６０に送信し、トークンが、送金支払いネットワークの別のメンバエンティティに登録されたユーザに関連付けられているか否かを特定する。例えば、送金者がこの特定の受取人に送金する初回である場合、銀行コンピュータシステム１２０は、送金者により提供された受取人の公開トークンを転送し得る。このシナリオでは、スポンサー識別論理１８２は、情報ディレクトリ１６８のサーチを実行して、トークンが別のメンバエンティティに登録しているユーザに関連付けられているか否かを特定し得る。公開トークンがディレクトリ内にある場合、支払いサービスコンピュータシステム１６０は、公開トークンに関連付けられた一意のＩＤを、送金者銀行コンピュータシステム１２０に関連付けられた金融機関又は他のメンバエンティティの識別情報と共に返し得る。次に、送金者銀行コンピュータシステム１２０は、送金者に別のレジストリエントリを作成し、レジストリエントリの一部として受取人の公開トークン及び一意のＩＤを記憶し得る。送金者銀行コンピュータシステム１２０は、受取人についての他の情報（例えば、ニックネーム又は送金者が受取人を識別することを望む他の名前）を提供するように送金者に促すこともできる。

別の例として、送金者がこの受取人に以前に送金したことがある場合、銀行コンピュータシステム１２０は、受取人の一意のＩＤを支払いサービスコンピュータシステム１６０に転送し得る。このシナリオでは、スポンサー識別論理１８２は、情報ディレクトリ１６８を実施するデータベースへのインデックスとして一意のＩＤを使用して、情報ディレクトリ１６８内の受取人を見つけ得る。一意のＩＤがなお有効であり、情報ディレクトリ１６８内になおあると仮定すると、支払いサービスコンピュータシステム１６０は、送金者銀行コンピュータシステム１２０に関連付けられた金融機関又は他のメンバエンティティを返し得る。別の例として、送金者が以前にこの受取人に送金していた場合、銀行コンピュータシステム１２０は、一意のＩＤ自体に基づいて、関連付けられたメンバエンティティを識別する（例えば、一意のＩＤが、金融機関を識別する情報と共に埋め込まれる場合）。ステップ３２３において、送金者のレジストリは、受取人の一意の識別子を含め、受取人のエントリを含むように更新される。ステップ３２５において、受取人の一意のＩＤと共にメンバエンティティ（例えば、図１の例での受取人銀行）に送金され、入金される。一意のＩＤに基づいて、情報ディレクトリ１５８は、受取人銀行コンピュータシステム１５０によりアクセスされて、受取人の口座番号を識別し得る。次に、資金を受取人の銀行口座に入金し得る。

ステップ３２１において、受取人が送金支払いシステムの別のメンバエンティティに登録しているユーザではない場合、プロセスは、図３Ｂに示されるステップ３３１に進む。ステップ３３１において、支払いサービスコンピュータシステム１６０のスポンサー識別論理１８２は、問い合わせを他の支払いネットワーク（例えば、ＰａｙＰａｌ（登録商標）、Ｓｔａｒ、Ｂｌｉｎｋ、Ｉｎｔｅｒｌｉｎｋ、Ｐｌｕｓ等）に送信し、トークンが、別の支払いネットワークに登録しているユーザに関連付けられているか否かを特定する。例えば、スポンサー識別論理１８２が第１の支払いネットワークに問い合わせを送信して、受取人がその支払いネットワークに登録しているか否かを問い合わせ得る。登録していない場合、スポンサー識別論理１８２は、受取人が口座を登録している支払いネットワークが識別されるまで、他の関連支払いネットワークに追加の問い合わせを送信し続け得る。ステップ３３３において、受取人が別の支払いネットワークに登録されている場合、そのトークンに関連付けられていると特定される支払いネットワークを識別する情報も情報ディレクトリ１６８に記憶され得、それにより、将来のそのトークンへの追加の送金を促進し得る。次に、ステップ３３５において、他のその支払いネットワークを通して資金をルーティングすることにより、受取人に送金し得る。したがって、そのような構成では、資金は、受取人が送金支払いネットワークに登録しているか否かについて送金者が知る又は考慮する必要なく、送金支払いネットワークに登録していない受取人にプッシュし得る。

他の支払いネットワークのサーチが完了した後、受取人が登録された他の支払いネットワークが識別される場合、受取人は、いかなる支払いネットワークの登録ユーザでもないと推測される。したがって、ステップ３４１において、支払いネットワークへの参加を誘う招待状が受取人に送信される。例えば、送金者が使用するトークンが電子メールアドレスである場合、別のユーザが受取人に送金しようとしていることを通知し、受取人に支払いネットワークに参加するように誘う電子メールが受取人に送信される。電子メール内のリンクが、例えば、受取人を銀行コンピュータシステム１２０により提供されるウェブサイトに向けられ得る。別の例として、送金者が使用するトークンが携帯電話番号である場合、支払いネットワークに参加するように受取人を誘うＵＲＬを含むテキストメッセージを受取人に送信し得る。理解されるように、他の状況で、例えば、受取人が送金支払いネットワークの登録ユーザではない場合、ユーザが別の支払いネットワークの登録ユーザであるときであっても受取人にそのような紹介状を送信し得る。

ステップ３４３において、受取人は、口座情報を提供するように促され得る。ステップ３５１において、口座情報に基づいてユーザがメンバエンティティの１つの顧客であるか否かを特定し得る。例えば、当座預金口座の銀行支店コードを使用して、ユーザがメンバエンティティの１つの顧客であるか否かを特定し得る。受取人がメンバエンティティの顧客である場合、ステップ３５３において、受取人は、登録のためにメンバエンティティ（例えば、図１の例での受取人銀行）に転送し得る。受取人銀行コンピュータシステム１５０の情報ディレクトリ１５８及び支払いサービスコンピュータシステム１６０の情報ディレクトリ１６８において、一意のＩＤが受取人に関連付けられる。ステップ３５５において、送金者のレジストリは、受取人の一意の識別子を含め、受取人を含むように更新される。ステップ３５７において受取人に送金される。

受取人がメンバエンティティの顧客ではない場合、ステップ３６３において、受取人は、支払いサービスコンピュータシステム１６０により登録される。ステップ３６５において、送金者のレジストリは、受取人の一意の識別子を含め、受取人のエントリを含むように更新される。ステップ３６７において、受取人に送金される。理解されるように、受取人がカスタマイズされた送金選好を有する場合、送金は、受取人選好に従ってルールエンジン１８８により処理し得る。そのような選好を反映したトークンカスタム化の例については、ルールエンジン１８８及びトークン生成論理１９０に関連して既に上述した。

図４は、ユーザが選好タブを選択する場合、ユーザに提供し得るウェブページ４００の画面例である。ウェブページ４００は、トークン管理論理１２９、１５９、又は１６９（ユーザがどこで支払いネットワークに登録するかに応じて）に関連して選好を構成するのに使用し得る。ウェブページ４００は、デフォルト通知設定フィールド４０１、接続管理フィールド４１１、及び受取人管理フィールド４３１を含む複数のフィールドを含む。デフォルト通知設定フィールド４０１は、送金イベントの現在のデフォルト通知設定に関する情報をユーザに提示する。図４の画面例に示されるように、通知設定フィールド４０１は、自動電話通知又はテキストメッセージ通知を送信すべき電話番号（フィールド４０３）及び電子メール通知を送信すべき電子メールアドレス（フィールド４０５）を指定する設定を含み得る。ユーザは、他のユーザが送金通知を受信するとき、他のユーザに見られるべき口座の名前（フィールド４０７）を指定することも許され得る。フィールド４０７において指定された情報は、他の状況、例えば、他のユーザが、情報ディレクトリ１２８、１５８、１６８内でのサービス探索を通して、結び付きをサーチしている場合にも使用し得る。ユーザは、取引発生前に、ユーザから受信したユーザ選好に基づいて取引に関してユーザに通知するように、ルールエンジン１８８を構成し得る。ユーザがカスタマイズされた通知設定の構成に失敗した場合、デフォルト通知設定を使用し得る。様々な実施形態では、ユーザは、ユーザが登録した各トークンで、異なる／カスタム通知設定を選択し得る。

図４に示される例では、所定のイベントの発生時にコール、テキストメッセージ、又はボイスメッセージを受信し得る電話番号は、９４９−５５５−７８７８である。更に、送金がユーザの口座から又はユーザの口座に行われたことをユーザに通知するのに使用し得る電子メールアドレスは、ｐａｔ＠ｍａｉｌ．ｃｏｍである。ユーザは、電子メール、電話、又は両方による通知を選択し得る。

トークンフィールド４１３は、ユーザが登録したか又は登録プロセス中である特定のトークンを表示し得る。ステータスフィールド４１５は、トークンが検証済み／未検証であるか、又はアクティブ／非アクティブであるかを表示し得る。金銭受取フィールド４１７は、部分的に、ステータスフィールド内の情報から導出され、特定のトークンが現在、資金の送信／受信に利用可能であるか否かを示す。例えば、非アクティブ電話番号（すなわち、６５０−５５５−５５５５）の場合、ユーザは、トークンが非アクティブになる前に確立された結び付きにこのトークンを使用して資金を送信／受信し得る。しかし、ユーザは、このトークンに基づいて他のユーザとの新しい結び付きを確立することはできない。例えば、これは、ユーザが以前所有していた携帯番号であり得る。一意のＩＤは、結び付きが確立された後、送金のベースとして機能するため、前に確立された結び付きはなお有効である（それらの結び付きは、携帯番号ではなく一意のＩＤに基づくため）が、新しい結び付きを確立することは許されない（その時点で別のユーザがトークンを使用中であり得るため）。

口座番号フィールド４１９は、口座の種類と、フィールド４１３内のトークンに関連付けられた口座の部分的な口座番号とを表示し得る。したがって、フィールド４１３で指定されるトークンを使用して送信／受信される資金は、フィールド４１９で指定された口座に対して出金／入金される。口座番号がフィールド４１３での電子メールアドレス又は携帯番号に関連しない場合、口座番号フィールド４１９は、「口座が指定されていません」等のメッセージを表示し得る。通知フィールド４２１は、フィールド７０１において指定されたデフォルト通知設定が通知に使用されるべきか否か又は他の／カスタム化された設定を使用すべきか否かを示し得る。

アクションフィールド４２３は、ユーザが様々な行動をとれるようにする様々なリンクを含み得る。例えば、リンクは、編集、削除、及び検証を含み得る。トークンのステータスが検証されている場合、編集フィールドにより、ユーザは、ルールエンジン１８８において指定されたようにトークンの属性を編集することができる。例えば、口座及び通知選好（フィールド７１９及び７２１）を更に詳細に編集し得る。口座番号が検証されている場合、削除リンクを表示することもできる。口座が未検証又は非アクティブである場合、電子メール又はＳＭＳを送信し、検証コードを表示する検証リンクを表示し得る。編集リンク及び削除リンクは、未検証又はアクティブの電子メール又は電話番号に表示することもできる。ユーザは、新規結び付きリンク４２５を使用して新しいトークンを追加することもできる。

フィールド４０１及び４１１から明らかなように、送金に別個の支払い及び通知チャネルを使用し得る。例えば、４１５−５５５−４００１トークンの場合、支払いチャネルは４１５−５５５−４００１トークンを通して行われるが、通知チャネルは、９４９−５５５−７８７８及びｐａｔ＠ｍａｉｌ．ｃｏｍトークンを通して行われる。更に、ユーザが、４１５−５５５−４００１トークンにカスタム通知チャネルを設定すると決定する場合、ユーザは、４１５−５５５−４００１トークンを使用して既に確立された結び付きを妨げることなく、そうすることができる。あるチャネルの妨げ（例えば、トークン変更による）は他のチャネルに影響を及ぼさない。

結び付き管理フィールド４３１は、ユーザが他のユーザとのユーザの結び付きの管理に関する様々な機能を実行できるようにする。フィールド４３１は、ユーザにより確立された結び付きのレジストリを示す。フィールド４３１内には、他の各ユーザに関する様々な情報、例えば、名前（フィールド４３３）、ニックネーム（フィールド４３５）、電子メール／携帯（フィールド４３７）、ステータス（フィールド４３９）、及びアクション（フィールド４４１）、並びにユーザが新しい受取人４４３を追加できるようにするリンクを表示し得る。特に示されていないが、各ユーザの一意のＩＤをフィールド４３１に示されるレジストリに表示することも可能であることが理解される。上述したように、一意のＩＤは、ユーザにより知られる必要はなく、より安全に維持される。

名前フィールド４３３は、他のユーザに関連付けられた口座に表示される（例えば、他のそのユーザにより指定された）受取人の名前であり得る。ニックネームフィールド４３５は、他のそのユーザに割り当てられた（例えば、ユーザにより指定された）ニックネームであり得る。電子メール／携帯フィールド４３７は、受取人が使用中の公開トークンを表示し得る。ステータスフィールド４３７は、特定の交信に対して永続的な結び付きが確立されたか否かを表示し得る。アクションフィールド４４１は、ステータスフィールドに基づいて決定し得る。例えば、リンクが確立された場合、アクションフィールド４４１は、ユーザが金銭を受取人に送信できるようにするリンクを表示し得る。リンクが確立されていない場合、アクションフィールドは、金銭送信リンクを表示し得るが、アクションフィールド４４１は、詳細表示リンクを表示することもできる。詳細表示リンクは、別の画面をユーザに表示し得、その別の画面において、ユーザが受取人との結び付きを確立するために更なる詳細を提供し得る。表示し得る他の動作は、編集及び削除である。編集は、ユーザが上述した各フィールドを編集できるようにし、削除は、ユーザがユーザのレジストリから受取人及び関連情報を削除できるようにし得る。リンク４４３は、例えば情報ディレクトリ１２８、１５８、及び／又は１６８のサーチを介して追加のユーザをレジストリに追加するのに使用し得る。

実施形態例では、結び付き管理フィールド４３１は、別のユーザがもはやトークンの所有者ではない場合をユーザに通知するメッセージをユーザに提示し得る。メッセージは、ユーザがトークン情報を更新できるようにするリンクを含み得る。他の実施形態では、他のユーザの情報が変更された場合、結び付き管理フィールド４３１により提示されるメッセージは、ユーザが古い情報を更新できるようにし得る。

図５は、デフォルト又はカスタム通知設定をユーザが更新できるようにするフォームの画面例である。図５では、ユーザの口座に関連付けられた電子メールアドレスのリストがユーザに提供される。ユーザは、チェックボックスを使用して、いずれの電子メールアドレスで通知を受信すべきかを示し得る。例えば、図５に示される画面例でのユーザは、適切なフィールドにチェックマーク５０５を配置することにより、電子メールアドレス「ｐｓｍｉｔｈ＠ｇｏｏｇｌｅ．ｃｏｍ」を選択した。他の実施形態では、ユーザは、１つの電子メールアドレスを選択する代わりに、複数の電子メールアドレスを選択し得る。画面例には、ユーザ口座に関連付けられた電話番号も示される。ユーザは、チェックマーク５０９を使用して、通知を受信する電話番号を選択し得る。他の実施形態では、ユーザは、通知に複数の電話番号及び複数の電子メールアドレスを選択し得る。リンク５１１により、ユーザは、銀行により維持される口座情報に電子メールアドレス又は電話番号を追加することができ得る。一実施形態では、ユーザは、リンクを選択し得、ユーザに自動的に、銀行機関により提供されるウェブポータルを表示し得る。ユーザは、保存ボタン５１３をクリックして、ユーザにより実施される通知変更を保存し得る。

図６は、ユーザが送金タブを選択した場合、ユーザに提示し得るウェブページ６００の画面例を示す。ウェブページ６００は、ユーザが、選択された受取人に送金するために記入し得る送金フィールド６０１を含み得る。ウェブページ６００は、ユーザが利用可能な様々な支払いチャネル６１９の表示を含み得る。ウェブページ６００は、保留中、返却された又は完了した最近の取引に関する詳細を示すフィールド６３０を含むこともできる。

送金フォーム６０１は、プルダウンメニュー６０３から受取人を選択するようにユーザに促し得る。メニュー６０３を使用して提示される受取人のリストは、図４で考察したフィールド４３１に含まれる受取人のリストを使用して埋め得る。受取人メニュー６０３のリストは、ユーザが過去に送金したか、若しくは資金を受け取ったユーザの名前又は別の方法で追加されたユーザの名前を含み得る。一実施形態では、受取人は、各受取人に割り当てられたニックネームで識別し得る。ニックネームは、トークン管理論理１２９内の一意のＩＤに直接相関付け得るため、一意のＩＤを介してニックネームから口座情報を導出し得る。したがって、上述したように、２人のユーザ間の結び付きは、携帯電話番号又は電子メールアドレスが陳腐化した場合に妨げられない。受取人を選択した後、ユーザは、ドロップダウンメニュー６０５を使用して受取人に送金し得る口座を選択し得る。ドロップダウンメニューは、ユーザが保有する全ての口座のリストで予め埋め得る。ユーザは、金額フィールド６０７に、ユーザが受取人に転送することを望むドル価格を入力し得る。ユーザの名前は、任意選択的なフィールド説明６０９と共に提示し得、任意選択的なフィールド説明６０９により、ユーザは、支払いが受取人により提供される特定の製品又はサービスに対してものであることを確認することができ得る。別のフィールドには、送金者としてユーザの名前を自動的に埋め得る。ニックネームフィールド６１１は、ユーザの口座に見られるユーザの名前と異なる名前により受取人がユーザを知る場合にも表示される。送金フォーム６０１は、ユーザが受取人を追加できるようにするリンク６１５、受取人を管理できるようにするリンク６１７、及び現在の通知選好を編集できるようにするリンク６１３も表示する。

ユーザに提示される支払いチャネルフォーム６１９により、ユーザは、クレジットカード、ＡＣＨ、又はＰａｙＰａｌ（登録商標）等の様々な支払いチャネルを選択することができ得る。各支払いチャネルと共に受取利用可能資金フィールド６２３も表示され得る。例えば、クレジットカード方法は、送信要求処理の２日以内に受取人に資金を提供し得る。しかし、ユーザには、フィールド６２５により示されるような料金、例えば、＄５．００が課され得る。他の例では、ユーザはフィールド６２１においてＡＣＨを選択し得るが、資金は、料金なしで４日以内に受取人に提供し得る。ＰａｙＰａｌ（登録商標）、Ｓｔａｒ、Ｂｌｉｎｋ、Ｉｎｔｅｒｌｉｎｋ、及びＰｌｕｓ等の他の支払いチャネルをユーザに提示することもできる。

フィールド６３０は、ユーザが実行した最新の取引のうちの少数を示す。より多くの送金を表示するリンクの選択を介して、及び／又は送金活動タブを選択することにより、追加の最近の取引を表示し得る。フィールド６３０は、取引に関する情報を含む様々なフィールドを表示し得る。例えば、そのようなフィールドは、送金日フィールド６３３、送金元口座フィールド６３５、受取人フィールド６３７、金額フィールド６３９、説明フィールド６４１、ステータスフィールド６４３、及びアクションフィールド６４５を含み得る。送金日フィールド６３３は、ユーザが送金要求を開始した日付を列挙する。送金元口座フィールド６３５は、口座の種類（すなわち、当座、普通、又は金融市場）及び部分的な口座番号を表示し得る。受取人フィールド６３７は、受取人のフルネームを表示し得る。金額フィールド６３９は、受取人に送金されたドル価格を表示する。説明フィールド６４１は、要求を処理する間、ユーザにより入力された説明を表示する。ステータスフィールド６４３は、送金が保留中であるか、返されたか、若しくは処理されないか、又は完了したかをユーザに通知し得る。アクションフィールド６４５は、ユーザが送金の現在ステータスに関する更なる詳細を見られるようにするリンクを表示し得る。

ネットワーク外での支払い
図３Ａ及び図３Ｂへの代替の実施形態では、送金者は、任意の支払いネットワーク − 送金支払いネットワークであれ、又は他の既存の支払いネットワークであれ − の任意のメンバの登録ユーザではない受取人に送金可能であり得る。参加銀行（すなわち、送金側銀行）におけるユーザは、例えば、送金側銀行のオンラインインターフェースを通して、所望の受取人のトークン（例えば、携帯電話番号又は電子メールアドレス）及び受取人に送金することが望まれるドル価格を入力する。ドル価格及びトークンは、次に、照合サービスのために送金支払いネットワークに送信される。受取人は、送金支払いネットワーク外にあるか、若しくは任意の既知の支払いネットワークの一部ではないため、又は両方であるため、送金支払いネットワークは、支払いネットワークのディレクトリにおいてトークンの一致を見つけることができない。それに応答して、送金支払いネットワークは、トークンが未知であることを示すメッセージを送金側銀行に送信する。送金支払いネットワークは保留中の支払いも生成し、これは、以下のフィールドの幾つか又は全てを含み得る：未知のトークン、送金側銀行、ドル価格、ユーザの名前、及び受取人の名前。

次に、送金側銀行は、トークンを使用してメッセージを受取人に送信する。例えば、送金側銀行は、送金者が受取人に送金することを望む旨のメッセージを受取人に送信し得る。代替的に、送金支払いネットワークは、メッセージを受取人に送信する。受取人は、任意の支払いネットワークの任意のメンバの登録ユーザではない場合、送金支払いネットワークのウェブサイトへのリンクに向けられ、登録して、保留中の支払いを受け取るプロセスを開始し得る。送金者により入力されたトークンが受取人の電子メールアドレスである場合、受取人は、電子メールアドレスでリンクを受信する。送金者により入力されたトークンが受取人の携帯電話番号である場合、受取人は、携帯電話番号においてリンクを受信する。

図７は、リンクでの招待状を許容した場合、受取人に提示し得る例としてのウェブページ７００の画面例を示す。図７に示されるように、受取人は、受取人が保留中の支払いについて通知された場所において、トークンを入力するように促される。ユーザは、ウェブページ７００内のフィールドにトークンを入力する。送金支払いネットワークは、入力されたトークンを保留中の支払いと照合する。一実施形態では、受取人は、入力されたトークンが保留中の支払いの未知のトークンに一致する場合にのみ進むことができる。

一実施形態では、送金支払いネットワークの任意のメンバに登録していない受取人は、登録された送金者がその非登録受取人を招待する場合のみ、送金支払いネットワークに参加し、資金を受け取ることができる。受取人による送金支払いネットワークへの参加を可能にするには、受取人の情報及び口座所有権を検証し、収集する必要があり得る。したがって、非登録のネットワーク外受取人が送金支払いネットワークに参加するには、送金支払いネットワークにより、支払いが保留中であることを検証する必要があり得ることを理解されたい。本明細書では、「ネットワーク外」は、送金支払いネットワークのメンバではない金融機関のユーザを指す。代替的に、「ネットワーク外」は、送金支払いネットワークのメンバではない金融機関を指すこともできる。ネットワーク外ユーザが送金支払いネットワークに参加するには、ネットワーク内ユーザがネットワーク外ユーザに資金を送信しなければならない。これは、取引に関わる全てのユーザ又はエンティティを検証し得ることを保証することにより、詐欺を回避し得る。更に、ネットワーク外ユーザは、ネットワーク内ユーザにより送金支払いネットワークに招待されなければならないため、詐欺及び不正取引は更に低減するか又はなくなる。

受取人が送金支払いネットワークに登録すると、送金支払いネットワークは、受取人の銀行口座情報を送金側銀行に送信して開始取引を完了し得る。取引は、例えばＡＣＨを介して完了し得る。当技術分野で既知のように、ＡＣＨ取引は、「プル」取引又は「プッシュ」取引であり得る。ネットワーク内ユーザが金銭をネットワーク外ユーザに送信する場合、送金側銀行はプッシュ取引を使用し得る。

受取人が送金支払いネットワークの登録ユーザになると、送金支払いネットワーク及び送金システム１００は、受取人についての情報をネットワーク外データベースに保持し得る。図８は、例としての送金システム８００を示す。送金システム８００は、送金システム１００と同様であるが、支払いサービスコンピュータシステムは、ネットワーク外データベース１６７を含む。ネットワーク外データベース１６７は、ネットワーク外ユーザが関わる金融取引中に収集される情報を記憶し得る。例えば、送金支払いネットワークは、ネットワーク外ユーザへの送金を実行し得、ネットワーク外受取人についての銀行情報をネットワーク外データベース１６７に記憶し得る。一実施形態では、送金システム８００は、ネットワーク外ユーザのトークン及び銀行口座情報をネットワーク外データベース１６７に記憶し得る。

代替の実施形態では、送金システム８００は、ネットワーク外ユーザの銀行口座情報をネットワーク外データベース１６７に記憶するが、ネットワーク外ユーザのトークン情報をネットワーク外データベース１６７に記憶しない。その代わり、送金支払いネットワークは、上述したように、受取人に秘密識別子を関連付ける。秘密識別子は、情報ディレクトリ１６８に記憶し得る。代替的に、秘密識別子は、情報ディレクトリ１２８又は情報ディレクトリ１５８に記憶し得る。したがって、ユーザのトークン情報は、ネットワーク外データベース１６７とは別個のディレクトリ、例えば、情報ディレクトリ１６８に記憶され、ユーザの銀行口座情報はネットワーク外データベース１６７に記憶される。この代替の実施形態は、ユーザのトークン及びユーザの銀行情報を同じデータベースに記憶しないことにより、ユーザのセキュリティを上げることを理解されたい。ユーザの銀行情報と共に、公開されている情報が記憶されず、それにより、詐欺又は盗難のリスクを低減することも理解されたい。したがって、送金支払いネットワークは、秘密識別子を使用して受取人のトークンを受取人の銀行情報と照合することにより、ネットワーク外受取人の支払い及び取引をセキュアに処理することができる。

一実施形態では、情報ディレクトリ１６８は、銀行口座情報を記憶しない。ネットワーク外データベース１６７は、図８では支払いサービスコンピュータシステム１６０の外部に示されるが、一実施形態では、ネットワーク外データベース１６７は、支払いサービスコンピュータシステム１６０内部に存在し得る。

受取人が関わる将来の取引では、送金支払いネットワークは、ネットワーク外データベース１６７を利用して、メンバからの資金の送金を促進する。図９は、本発明の実施形態例による、ネットワーク外受取人への支払い又は送金を促進する例としてのプロセス９００を示す流れ図である。プロセス９００について図９に示される流れ図を参照して説明するが、プロセス９００に関連する動作を実行する多くの他の方法が使用可能であることが理解される。例えば、ブロックのうちの多くの順序は、変更し得、特定のブロックは他のブロックと組み合せ得、記載されるブロックの多くは任意選択的なものである。

情報がネットワーク外データベース１６７に既に記憶されているネットワーク外受取人に資金を支払うために、データは、送金者コンピュータシステム１１０、ネットワーク外データベース１６７を含む支払いサービスコンピュータシステム１６０を使用又は実施する送金支払いネットワーク及び受取人コンピュータシステム１３０間で流れ得る。送金者は、ブロック９０２に示されるように、トークンを使用して受取人に送金することを望み得る。送金側銀行は、トークン及びドル価格を送金支払いネットワークに送信する。送金支払いネットワークは、ブロック９０４に示されるように、トークンがネットワーク外受取人のものであることに留意し、ブロック９０６に示されるように、受取人がネットワーク外受取人であることを示すメッセージを送金側銀行に送信する。ブロック９０８に示されるように、送金側銀行は、確認を送金支払いネットワークに送信して取引を継続し得る。確認を受信すると、送金支配ネットワークは、ブロック９１０に示されるように、別個のネットワーク外データベース１６７にアクセスする。送金システムネットワークは、ブロック９１２に示されるように、トークンをネットワーク外データベース１６７に記憶された受取人の銀行情報と照合する。送金支払いネットワークは、ブロック９１４に示されるように、受取側銀行口座情報を暗号化し、受取人の銀行口座情報を送金側銀行に不透明に送信する。送金側銀行は、受取人の銀行口座情報を復号化し、受取人の銀行口座情報及び取引の完了に必要な任意の他の情報をＡＣＨ １７０に送信する。

送金システム１００はまた、金融機関の非顧客への通信も可能にする。例えば、銀行が送金支払いネットワークのメンバになると、その銀行は、その銀行の顧客ではないユーザにメッセージを送信することが可能であり得る。したがって、送金支払いネットワークは、通信仲介者として振る舞うことができる。例えば、新しいユーザが、サインアップしてメンバエンティティに登録するように促される場合、そのユーザに、そのユーザにメッセージを送信する承認を明示的に与える画面を提示し得る。換言すれば、ユーザは、一実施形態では、送金支払いネットワーク及び送金システム１００に参加する条件として、メンバからメッセージを受信することに同意しなければならない。したがって、ユーザがサインアップすると、そのユーザは他のメンバによって連絡され得る。

一実施形態では、送金支払いネットワークのメンバである金融機関は、顧客の代理として、非顧客への送金、非顧客からの資金受け取り、及び資金要求を行うことが可能である。したがって、送金支払いネットワークのメンバである金融機関が、その顧客がその金融機関の顧客ではない他のエンティティとビジネスを行うことに役立ち得ることを理解されたい。

一実施形態では、送金システム１００は、支払いステータスを追跡し、支払いステータスについての通知を送金者及び受取人に提供し得る。

一実施形態では、情報は、送金側銀行により暗号化され、受取側銀行により復号化され、それにより、支払いネットワークは、送金者情報又は受取人情報のいずれへのアクセスも有さない。例えば、送金側銀行は、受取側銀行により知られているが、送金支払いネットワークには知られていない暗号化アルゴリズムを使用し得る。この場合、送金側銀行は、任意の情報が支払いネットワークに与えられる前に口座情報を暗号化する。支払いネットワークは、暗号化された送金者情報及び受取人情報を受取側銀行に転送することを含めて情報を処理する。受取側銀行は、暗号化された情報を復号化する方法を知っている。このようにして、支払いネットワークは、ある銀行から別の銀行に通信されているいかなる情報にもアクセスすることができない。したがって、送金は、全体的に送金支払いネットワークから不透明である。

一実施形態では、送金システム１００は、銀行の既存の詐欺システムに依拠してリスクを管理する。一実施形態では、支払いシステムは、実際に、いかなる金銭もあるエンティティから別のエンティティに又はある銀行から別の銀行に移さない。一時的な期間であってさえも金銭を保有することができる、支払いサービスにより所有される口座は存在しない。一実施形態では、支払いシステムは、ある銀行から別の銀行への送金のみを促進する。

一実施形態では、送金システム１００又は送金支払いネットワークは、支払いをネットワーク外ユーザからネットワーク内ユーザに送信し得る。送金支払いネットワークは、ネットワーク外送金者についての情報を記憶する別個のネットワーク外データベースを作成してもよく、又は既存のデータベースを利用してもよい。

一実施形態では、メンバ銀行のユーザは、送金システム１００を使用して請求書又は送り状を提示することが可能であり得る。請求書は、メンバ銀行のユーザにより提供される製品又はサービスの消費者に提示し得る。消費者は、ネットワーク内ユーザ又はネットワーク外ユーザであり得る。請求書の提示は、電子ファイル、例えば、Ａｄｏｂｅ ＰＤＦ（登録商標）文書、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ（登録商標）文書、テキストファイル、イメージファイル、又は請求書を消費者に表示する任意の他の適する文書を含み得る。電子ファイル、例えば、Ａｄｏｂｅ ＰＤＦ（登録商標）文書は、請求者により提供される支払い期限を含み得る。一実施形態では、送金システム１００は、例えば、抵当証書類、ビジネス文書、召喚状、又は特許出願書類若しくは申請書等の請求書以外の他のアイテムを提示し得る。

送金システム１００は、銀行が文書を受け取る消費者の身元を識別する場合、文書を安全に提示するのに使用することもできる。送金者は、銀行を使用して文書の受取を検証することもできる。一実施形態では、請求者は、消費者が請求書を受け取ったか否かを追跡することができる。例えば、請求者は、消費者が請求書を受け取った旨の通知を送金システム１００から受信し得る。送金者は、消費者が請求書を見たこと、例えば、コンピュータ又は携帯電話で電子ファイルを開いたか、又は電子ファイルにアクセスしたことを確認することも可能であり得る。消費者が請求書を受け取ったことを請求者が確認することができ、受け取ったことを消費者が否定できないため、受信の検証又は追跡が有用であることを理解されたい。

ネットワーク内請求書提示の場合、請求者は、金銭要求、請求書、又は送り状を送金支払いネットワークに送信する。要求又は請求書は、請求書の受取人又は消費者を識別するトークンを含む。請求者は、要求ＩＤを支払いＩＤに添付し、請求書を送金支払いネットワークに送信する。請求者はまた、支払い指示を請求書に追加することも可能であり得る。送金支払いネットワークは、トークンに基づいて請求書又は送り状を消費者にルーティングする。消費者はこれに応答して、支払う。次に、送金支払いネットワークは、支払いを請求者に通知する。支払いＩＤは、銀行に送信され、次に口座と照合される。請求者又は請求者の銀行が消費者の銀行支店コード及び口座番号を有する必要がなく、それにより、消費者及び請求者のセキュリティ及び便宜性を上げることを理解されたい。

ネットワーク外消費者の場合、支払いＩＤを要求ＩＤと共に送信する代わりに、送金支払いネットワークは、口座に借方記入する指示を請求側銀行に提供する。送金支払いネットワークはまた、借方記入するために、消費者のＡＣＨ情報に支払いＩＤ、要求ＩＤを加えたものを請求者の銀行に提供する。

一実施形態では、ネットワーク外ユーザは、メンバ銀行顧客が支払い要求をネットワーク外ユーザに送信しない場合であっても、支払いをメンバ銀行顧客に送信することが可能であり得る。したがって、登録済みのネットワーク外ユーザ、すなわち、ネットワーク外データベース１６７に見られるユーザは、金銭をメンバ銀行の顧客に送ることができる。メンバ銀行顧客は、そのメンバ銀行顧客の選択したチャネルを使用して金銭を受け取ることができる。メンバ銀行顧客は、銀行口座番号等の機密であると認識される情報を、金銭を受け取ることを望むネットワーク外ユーザに提供する必要がないことを理解されたい。送金システム１００は、借方取引、電子送金、クレジットカード取引、Ａｍａｚｏｎ（登録商標）支払い、単純に電子メールを介して促進される支払い、ビジネス間又はビジネス−商人支払い、早期支払い、及び家賃、家事、又は毎週のベビーシッター等の定期的な支払いに使用し得る。一実施形態では、送金支払いネットワークは、トライアル入金を介して口座アクセスを検証する。送金者は、取引金額を与え、送金システム１００は、ネットワーク外送金者が口座にアクセスすることができ、入金取引を認可したことを検証する。

一実施形態では、送金するネットワーク外ユーザは、送金限度を受け得る。送金限度額は、１日毎、繰り返される７日時間期間毎、又は繰り返される３０日時間期間毎であり得る。送金限度は、支払い先に関係なく、各ネットワーク外ユーザに対して施行し得る。ネットワーク外ユーザが送金限度を超える支払いを送ろうとする場合、送金システム１００は、支払いが送金限度を超えていることをネットワーク外ユーザに通知し得る。一実施形態では、送金支払いネットワークは、ネットワーク外ユーザがメンバ銀行の顧客に金銭を送るとき、取引料を課すことができる。

送金を望むネットワーク外消費者からの送金を受け入れ、実行するとの判断は、メンバ銀行、すなわち、金銭を受け取るネットワーク内ユーザの銀行により管理し得る。ネットワーク外データベース１６７に関して上述したように、ネットワーク外ユーザは、メンバ銀行顧客に送金可能になるには、ネットワーク外サービスに登録しなければならない。したがって、登録しているネットワーク外ユーザが、メンバ銀行の登録顧客への支払いを開始すること及びメンバ銀行の顧客からの金銭要求（例えば、請求書）に応答することの両方が可能であり得ることを理解されたい。

ネットワーク外ユーザの銀行口座からの借方取引は、メンバ銀行によりＡＣＨレールを介して生じ得る。一実施形態では、メンバ銀行は、ＡＣＨレールを介して取引を処理するために、以下のうちの少なくとも１つを必要とする：送信者の名前、取引額、取引料、受取人プロファイルＩＤ、送金者により提供されるような受取人の名前、支払い備考、開始日、銀行口座番号、銀行支店コード、及び口座の種類、例えば、当座又は普通。ネットワーク外ユーザがネットワーク内ユーザに送金する場合、送金側銀行はプル取引を使用し得る。

セキュリティを目的として、一実施形態では、ネットワーク外ユーザは、支払い要求を開始することが許されないことがあり、また、支払いを他のネットワーク外ユーザに送ることも許されないことがある。これらの特徴が詐欺を阻止すると共に、送金支払いネットワークへの金融機関の参加を促すことを理解されたい。

図１０は、本発明の実施形態例による、ネットワーク外送金者からネットワーク内受取人への支払い又は送金を促進する、例としてのプロセス１０００を示す流れ図である。プロセス１０００について図１０に示される流れ図を参照して説明するが、プロセス１０００に関連する動作を実行する多くの他の方法が使用可能であることが理解される。例えば、ブロックのうちの多くの順序は、変更し得、特定のブロックは他のブロックと組み合せ得、記載されるブロックの多くは任意選択的なものである。

情報がネットワーク外データベース１６７に既に記憶されたネットワーク外送金者からネットワーク内受取人に送金するために、データは、送金者コンピュータシステム１１０、ネットワーク外データベース１６７を含む支払いサービスコンピュータシステム１６０を使用又は実施する送金支払いネットワーク及び受取人コンピュータシステム１３０間で流れ得る。送金者は、ブロック１００２に示されるように、トークンを使用して受取人に送金することを望み得る。送金側銀行は、トークン及びドル価格を送金支払いネットワークに送信する。ブロック１００４に示されるように、送金支払いネットワークは、要求がネットワーク外送金者からのものであることに留意する。ブロック１００６に示されるように、送金支払いネットワークは、トライアル入金を使用して口座アクセスを検証し得る。ブロック１００８に示されるように、送金支払いネットワークは、送金者がネットワーク外送金者であることを示すメッセージを受取側銀行に送信する。受取側銀行は、ブロック１０１０に示されるように、確認を送金支払いネットワークに送信して取引を継続し得る。確認を受信すると、送金支払いネットワークは、ブロック１０１２に示されるように、別個のネットワーク外データベース１６７にアクセスする。ブロック１０１４に示されるように、送金支払いネットワークは、送金者をネットワーク外データベース１６７に記憶された送金者の銀行情報と照合する。ブロック１０１６に示されるように、送金支払いネットワークは、送金側銀行口座情報を暗号化し、送金側銀行の口座情報を受取側銀行に不透明に送信する。受取側銀行は、送金者の銀行口座情報を復号化し、送金者の銀行口座情報及び取引の完了に必要な任意の他の情報をＡＣＨ１７０に送信する。

早期支払い
一実施形態では、送金者は、受取人への資金の「リアルタイム」又は早期支払いを行うことが可能であり得る。支払われた資金が、支払いが通常提供されるよりもはるかに早く受取人に提供される場合、支払いを「リアルタイム」と見なし得ることを理解されたい。例えば、支払いは、資金が数分以内に受取人の口座に入金される場合、準リアルタイムであると見なし得る。一実施形態では、支払いは、送金者から受取人への資金が、送金者の銀行から受取人の銀行にメッセージを送信するのに必要な時間量で受取人の口座に入金される場合、リアルタイムであると見なし得る。メッセージは、ＩＢＭ（登録商標）、ＷｅｂＳｐｈｅｒｅ ＭＱ等の管理サービスを介して送金側銀行、送金支払いネットワーク及び受取側銀行間で送信し得る。

幾つかのシステムは、リアルタイム支払いを提供しようとするが、デビットカードシステムを利用する必要があり、これは不便であり得る。他のシステムはＡＣＨシステムを利用し、これは、処理に数日かかり得、ここで開示されるリアルタイム又は早期支払いのスピードを提供しない。他のシステムは、送金者が幾つかの代替の支払い提供者との口座を作成することを必要とする。更に他のシステムは、金融機関のコア処理プラットフォームへの直接アクセスを有することを必要とする。

更に他のシステムでは、送金者のクレジットカードからの迅速な支払いを可能にする。送金支払いネットワークは、送金者の主要金融機関等の送金者の金融機関から受取人へのリアルタイム送金を可能にする。送金者の主要金融機関からの送金により、送金者が金融取引を集中化し、金銭をより容易且つ好都合に管理することが可能であり得ることを理解されたい。送金者は、任意の数の金融機関を使用することができ、各金融機関が送金支払いネットワークのメンバであり、送金者が各金融機関で異なるトークン（例えば、電子メールアドレス、電話）を使用する限り、それらの任意の機関から金銭を送信／受信することができる。

他のシステムでは、送金側銀行が受取側銀行と同じである場合、迅速な支払いが可能である。送金支払いネットワークは、送金者及び受取人が異なる銀行を使用する場合であっても、送金者から受取人へのリアルタイム支払いを可能にする。送金支払いネットワークは、ＡＰＩシステムを通して任意のコア金融機関のシステムと協働することができ、金融機関のコア処理プラットフォームへの直接接続を必要としない。送金支払いネットワークは、代替的に、例えば、証券会社又は投資会社等の非銀行金融機関と協働することができる。

一実施形態では、送金側銀行及び受取側銀行は両方ともネットワーク内銀行である。リアルタイム支払いを行うには、送金側銀行及び受取側銀行は、互いのリアルタイム支払いの提供に合意する必要があり得る。例えば、送金支払いネットワークは、リアルタイム支払いサービスを送金側銀行及び受取側銀行に提供し得、ここで、両方の銀行は、互いへのリアルタイム支払いの促進に合意する。送金支払いネットワークは、追加又は代替として、メンバ銀行になる前に、銀行が他のメンバ銀行からの支払いのリアルタイム送受信に合意しなければならないという要件を有し得る。個々のユーザは、サービス料の早期支払いの送信及び／又は受信を可能にするために、各金融機関にサインアップすることもできる。

図１１は、本発明の実施形態例による、ネットワーク内送金者からネットワーク内受取人へのリアルタイムの資金の支払い又は転送を促進する、例としてのプロセス１１００を示す流れ図である。プロセス１１００について図１１に示される流れ図を参照して説明するが、プロセス１１００に関連する動作を実行する多くの他の方法が使用可能であることが理解される。例えば、ブロックのうちの多くの順序は、変更し得、特定のブロックは他のブロックと組み合せ得、記載されるブロックの多くは任意選択的なものである。

ネットワーク内送金者からネットワーク内受取人に資金をリアルタイムで支払うために、データは、送金者コンピュータシステム１１０、支払いサービスコンピュータシステム１６０を使用又は実施する送金支払いネットワーク及び受取人コンピュータシステム１３０間で流れ得る。ブロック１１０２に示されるように、送金者は、受取人にリアルタイムで送金することを望み得る。一実施形態では、受取人は、例えば、受取人の金融機関とのサービスにサインアップすることによる等、リアルタイム支払いを受け取るために適格でなければならない。送金側銀行は、受取人がリアルタイム支払いを受け取るのに適格であるか否かについて、送金支払いネットワークに問い合わせ得る。送金支払いネットワークは、ブロック１１０４に示されるように、受取人がリアルタイム支払いを受け取るのに適格であるか否かをチェックし、適格である場合、ブロック１１０６に示されるように、確認メッセージを送金側金融機関に送信する。受取人が適格であるとの確認を受信すると、送金側銀行は、ブロック１１０８に示されるように、資金を送金者口座から取り出す。したがって、プロセス１１００のこの段階で、資金は送金者の銀行口座から取り出されている。

次に、ブロック１１１０に示されるように、送金側銀行は、早期支払いメッセージを送金支払いネットワークに送信する。したがって、ブロック１１１２に示されるように、送金支払いネットワークは、リアルタイム支払いを示す早期支払いメッセージを受取人銀行に送信する。次に、ブロック１１１４に示されるように、受取人銀行は、受取人の口座に資金を供給する。プロセス１１００のこの段階において、資金が受取人の銀行口座に入金されていることを理解されたい。プロセス１１００のこの段階において、受取人銀行がそれ自体の資金から受取人の銀行口座に資金を供給しているが、送金側銀行が依然として受取人銀行に金銭を供給していないことも理解されたい。

送金側銀行と受取人銀行との間の調停又は決済は、受取人の口座に資金供給された後のある時点で行われ得る。送金側銀行と受取人銀行との間の決済又は調停は、支払いが受取人に対して行われた後、数時間又は数日、行われないことがある。受取人の口座への入金と、送金側銀行と受取人銀行との間の調停との間の時間量は、調停遅延と呼び得る。送金支払いネットワークが実質的に、受取人が資金を受け取る前に調停遅延にわたり待つのを回避することを理解されたい。幾つかの場合、送金支払いネットワークは、金銭が受取人に提供されるまでの最大時間数、例えば、２時間を提供し得る。実質的に電子メッセージを受取人銀行に送信するのに必要な時間量で受取人が金銭を利用できるようになることを理解されたい。

図１１を再び参照すると、受取人の口座に資金供給された後、受取人銀行は、ブロック１１１６に示されるように、受取人の口座が資金供給されたことを送金支払いネットワークに通知する。次に、送金支払いネットワークは、ブロック１１１８に示されるように、受取人の口座に資金供給されたことを送金側銀行に通知する。送金側銀行は、受取人の口座に資金供給されたことを示す支払い確認メッセージを送金者に送信し得る。次に、送金側銀行は、ブロック１１２０に示されるように、ＡＣＨ支払いを介して受取人銀行との資金を決済する。

一実施形態では、支払いを更に迅速にするために、送金側銀行は、受取人の口座に資金が供給される後まで送金者の口座から出金されない。しかし、送金側銀行は、送金者が、送金者の口座内で利用可能な金銭を超える送金を選択することを制限し得る。このようにして、送金側銀行は、送金者の口座が送金側銀行に支払うのに十分な資金を有することを確実にする。

一実施形態では、受取側銀行が受取人の口座に即座に資金供給する代わりに、受取人は、資金が受取人の口座に転送される前に支払いを受け入れなければならない。受取人が支払いを受け入れると、受取側銀行は、所要金額を受取人の口座に転送する。

一実施形態では、送金支払いネットワークは、早期に資金を受け取るために、未登録受取人がネットワーク内金融機関に登録するように要求し得る。

本発明の実施形態について、図面を参照して説明した。図面は、本発明のシステム、方法、及びプログラムを実施する特定の実施形態の特定の詳細を示す。しかし、図面を用いて本発明を説明することは、図面に提示し得る任意の限定を本発明に課すものとして解釈されるべきではない。本発明は、方法、システム、及びその動作を達成する任意の機械可読媒体でのプログラム製品を意図する。本発明の実施形態は、既存のコンピュータプロセッサを使用して、又はこの目的若しくは別の目的で組み込まれる専用コンピュータプロセッサにより、又はハードワイヤードシステムにより実施し得る。

上述したように、本発明の範囲内の実施形態は、記憶された機械実行可能命令又はデータ構造を含むか、又は有する機械可読媒体を含むプログラム製品を含む。そのような機械可読媒体は、汎用若しくは専用コンピュータ又はプロセッサ内の他の機械によりアクセスすることができる任意の利用可能な媒体であることができる。例として、そのような機械可読媒体は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、若しくは他の光ディスク記憶装置、磁気ディスク記憶装置、若しくは他の磁気記憶装置、又は機械実行可能命令若しくはデータ構造の形態で所望のプログラムコードを記憶するのに使用することができ、汎用コンピュータ若しくは専用コンピュータ、若しくはプロセッサを有する他の機械によりアクセスすることができる任意の他の非一時的媒体を含むことができる。上記の組み合わせも機械可読媒体の範囲内に含まれる。機械実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、又は専用処理機械に特定の機能又は機能群を実行させる命令及びデータを含む。

本発明の実施形態について一般的に、例えば、ネットワーク化環境内で機械により実行されるプログラムモジュールの形態で、プログラムコード等の機械実行可能命令を含むプログラム製品により実施されるもので実施し得る方法ステップに関して説明した。一般に、プログラムは、特定のタスクを実行し、又は特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。機械実行可能命令は、関連するデータ構造、及びプログラムモジュールは、本明細書に開示される方法のステップを実行するプログラムコードの例を表す。特定のシーケンスのそのような実行可能命令又は関連するデータ構造は、そのようなステップで説明される機能を実施する対応する動作の例を表す。

上述したように、本発明の実施形態は、プロセッサを有する１つ又は複数のリモートコンピュータへの論理接続を使用してネットワーク化環境で実施し得る。そのようなネットワーク計算環境が、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベース又はプログラマブル消費者電子デバイス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等を含め、多くのタイプのコンピュータを包含し得ることを当業者は理解する。本発明の実施は、分散計算環境で実施することもでき、分散計算環境では、タスクは、通信ネットワークを通してリンクされる（ハードワイヤードリンク、無線リンク、又はハードワイヤードリンクと無線リンクとの組み合わせにより）ローカル処理デバイス及びリモート処理デバイスにより実行される。分散計算環境では、プログラムモジュールは、ローカルメモリ記憶装置及びリモートメモリ記憶装置の両方に配置し得る。

本発明のシステム全体又は部分を実施する例示的なシステムは、処理ユニット、システムメモリ、及びシステムメモリを含む様々なシステム構成要素を処理ユニットに結合するシステムバスを含む、コンピュータの形態の汎用計算コンピュータを含み得る。システムメモリは、読み取り専用メモリ（ＲＯＭ）及びランダムアクセスメモリ（ＲＡＭ）を含み得る。コンピュータは、磁気ハードディスクへの読み書きを行う磁気ハードディスクドライブ、リムーバブル磁気ディスクへの読み書きを行う磁気ディスクドライブ、及びＣＤ ＲＯＭ 又は他の光学媒体等のリムーバブル光ディスクへの読み書きを行う光ディスクドライブを含むこともできる。ドライブ及び関連する機械可読媒体は、コンピュータの機械実行可能命令、データ構造、プログラムモジュール、及び他のデータの不揮発性記憶装置を提供する。「端末」という用語が、本明細書では、コンピュータ入力デバイス及び出力デバイスを包含することが意図されることにも留意されたい。入力デバイスは、本明細書で記載されるように、キーボード、キーパッド、マウス、ジョイスティック、又は同様の機能を実行する他の入力デバイスを含む。出力デバイスは、本明細書に記載されるように、コンピュータモニタ、プリンタ、ファクシミリ機、又は同様の機能を実行する他の出力デバイスを含む。

本明細書での図は、特定の順序及び構成の方法ステップを示し得るが、これらのステップの順序が図示の順序と異なり得ることが理解されることに留意されたい。例えば、２つ以上のステップは、同時に又は部分的に同時に実行し得る。また、離散ステップとして実行される幾つかの方法ステップは、結合し得、結合ステップとして実行されるステップは、離散ステップに分離し得、特定のプロセスのシーケンスは、逆又は他に変更し得、離散プロセスの性質及び数は、変更又は変形し得る。任意の要素又は装置の順序又はシーケンスは、代替の実施形態に従って変形又は置換し得る。したがって、そのような全ての変更形態は、添付の特許請求の範囲に規定される本発明の範囲内に包含されることが意図される。そのような変形形態は、選択されるソフトウェア及びソフトウェアシステム並びに設計者の選択に依存する。そのような全ての変形形態が本発明の範囲内にあることが理解される。同様に、本発明のソフトウェア及びウェブ実施形態は、ルールベースの論理及び他の論理を用いる標準プログラミング技法を用いて達成されて、様々なデータベースサーチステップ、相関付けステップ、比較ステップ、及び特定ステップを達成することができる。本発明の実施形態の上記説明は、例示及び説明を目的として提示された。網羅的である、すなわち、本発明を開示された厳密な形態に限定することは意図されず、上記教示に鑑みて変更形態及び変形形態が可能であり、又は変更形態及び変形形態を本発明の実施から取得し得る。実施形態は、当業者が、本発明を様々な実施形態で、意図される特定の用途に適するような様々な変更を行って利用できるようにするように、本発明の原理及びその実際用途を説明するために選択され説明された。添付の特許請求の範囲で表現されるような本発明の範囲から逸脱せずに、実施形態の設計、動作条件、及び構成に対する他の置換形態、修正形態、変更形態、及び省略形態がなされ得る。

非金融機関を通してのセキュアな送金
様々な実施形態では、送金者及び／又は受取人は、非金融機関（例えば、サービス提供者）により維持されるオンライン支払いプロセス又は物理的な支払い端末へのアクセスを有さないことがある。本明細書で使用される場合、「送金者」は、送金者の金融機関から受取人にある金額の資金を転送する命令を提供するエンティティ（個人、企業、コーポレーション等）を含み得る。資金の「受取人」は、本明細書で使用される場合、送金者からの資金の意図される受取人を指し得る（例えば、資金の受取人は、受取人の金融機関の受取人口座で資金を受け取り得る）。「送金の参加者」は、本明細書で使用される場合、送金者又は資金の受取人のいずれかを指し得る。

「金融機関」又はＦＩは、投資、ローン、及び／又は預金等の金融取引に主に対処するエンティティである。金融機関例としては、商業銀行、投資銀行、保険会社、証券会社、投資会社、送金エンティティ、信託会社、貯蓄貸付エンティティ、クレジットユニオン、シャドーバンク等の組織が挙げられる。

「非金融機関」又は「非ＦＩ」は、本明細書で使用される場合、その主要機能の一環として金融サービスを提供しないエンティティを指し得る。非金融機関は、製品及びサービスの販売又は交換を促進するビジネスエンティティを含み得る。そのようなビジネスエンティティの例としては、サービスエンティティ及び小売りエンティティ（例えば、従来型の小売店及びオンライン小売店）が挙げられる。幾つかの実施形態では、非金融機関は、ソーシャルネットワーキングサービスをユーザ及び／又は他の個人に提供するソーシャルネットワーキングエンティティを含む。そのようなソーシャルネットワーキングエンティティの例としては、Ｆａｃｅｂｏｏｋ（登録商標）、ＬｉｎｋｅｄＩｎ（登録商標）、Ａｌｐｈａｂｅｔ（登録商標），Ｉｎｃ．により提供されるソーシャルネットワーク、及びＳｎａｐｃｈａｔ（登録商標）が挙げられる。

非金融機関は、オンライン支払いシステムをサポートし得る。「オンライン支払いシステム」は、本明細書で使用される場合、個人のデジタルデバイスを使用して個人（例えば、送金者又は受取人）による製品／サービスの閲覧、レビュー、及び／又は支払いを可能にするウェブサイト又はネットワークアプリケーション及びサーバシステムを指し得る。例えば、非金融機関は、非金融機関への、提供されたサービスの支払い又は過去の請求書の支払いの物理的なデバイス及び／又はオンラインサービスを提供し得る。別の例では、オンライン小売業者（例えば、ＧＡＰ）は、インターネット等の公衆ネットワークを介して通信する支払い処理サーバを提供し得る。個人は、ウェブページ（任意の数のデジタルデバイスのブラウザによりアクセス可能）又はスマートフォンのアプリケーション等のアプリケーションを通して、支払い処理サーバと対話し得る。

様々な実施形態では、非金融機関は、製品及び／又はサービスの支払いのために個人から資金を受け入れる物理的な支払い端末を含み得る。非金融機関での物理的支払い端末により、ユーザは、資金（例えば、物理的な通貨、デジタル通貨等）を得ることもでき得る。

金融機関は、送金者と受取人との間の記入仲介者として動作し得、送金を促進し得る。金融機関は、政府及び／又は他の規制機関により規制し得る。「送金者金融機関」は、別のエンティティへの送金を試みるエンティティに金融サービスを提供する金融機関を指し得る。例えば、送金者金融機関は、送金者の銀行であり得る。送金者の銀行は、送金者に関連付けられた任意の数の銀行口座を含み得る。送金者の各口座は、１つ又は複数の送金者口座番号（例えば、送金者の口座を識別する口座番号）を含み得る。送金者金融機関は、送金者が受取人への送金に使用し得る資金（物理的な通貨、デジタル通貨、与信枠等）へのアクセスを提供し得る。

「受取人金融機関」は、別のエンティティから資金を受け取るエンティティに金融サービスを提供する金融機関を指し得る。例えば、受取人金融機関は受取人の銀行であり得る。受取人の銀行は、受取人に関連付けられた任意の数の銀行口座を含み得る。受取人の各口座は、１つ又は複数の受取人口座番号（例えば、受取人の口座を識別する口座番号）を含み得る。受取人金融機関は、受取人が送金者から資金を受け取るのに使用し得る資金（物理的な通貨、デジタル通貨、与信枠等）へのアクセスを提供し得る。

図１２は、幾つかの実施形態による、送金者非金融機関システムから受取人非金融機関システムにセキュアに送金する送金システム１２００の図を示す。送金システム１２００は、送金者システム１２０２、受取人システム１２０４、第１の非ＦＩシステム１２０６、第２の非ＦＩシステム１２０８、送金者ＦＩシステム１２１０、受取人ＦＩシステム１２１２、支払いサービスシステム１２１８、自動クリアリングハウス（ＡＣＨ）システム１２２０、公衆ネットワーク１２１４、及びＡＣＨネットワーク（例えば、プライベートネットワーク）１２１６を含み得る。

送金者システム１２０２は、送金者（例えば、ユーザ）に関連付けられた１つ又は複数のデジタルデバイスを含み得る。例として、送金者は、非金融機関のウェブサイト又は非金融機関の物理的支払い端末を使用して（例えば、クレジットカード、デビットカード、又は非金融機関により提供される端末を有するスマートデバイスを使用して）、第三者受取人に送金する人物であり得る。例として、送金者は、小売業者（例えば、第１のＦＩシステム１２０６）により管理されるネットワークアプリケーション又はウェブページにアクセスすることができる人物であり得る。送金者による送金は、本明細書で更に考察する送金者金融機関により後援し得る。例として、送金者は、送金者が受取人に送金することを望む資金へのアクセスを提供する送金者金融機関に送金者口座を維持し得る。

送金者システム１２０２は、デジタルデバイスの構成要素の幾つか又は全てを有し得、それらの例は図１２に示され、本明細書において更に考察される。例えば、送金者システム１２０２は、コンピュータ（例えば、デスクトップ又はラップトップコンピュータ）、携帯電話、スマートフォン、モバイルハンドヘルド無線電子メールデバイス、個人情報端末、ポータブルゲーミングデバイス、又は他の適するデジタルデバイスであり得る。送金者システム１２０２は、メモリに記憶された命令を実行するように構成される１つ又は複数のプロセッサを含むこともできる。

送金者システム１２０２は、ネットワークインターフェース論理１２２２、表示デバイス１２２４、入力デバイス１２２６、及びクライアントアプリケーション１２２８を含み得る。ネットワークインターフェース論理１２２２は、送金者システム１２０２と公衆ネットワーク１２１４（又は任意のネットワーク）との間の接続を可能にするプログラム論理を含み得る。表示デバイス１２２４は、オンライン支払いシステムのグラフィカルユーザインターフェース（ＧＵＩ）又は支払いサーバシステム１２１８からの情報及び／又は送金者ＦＩシステム１２１０からの情報等のコンテンツを表示するように構成されるディスプレイを含み得る。入力デバイス１２２６は、送金者が口座アクセスを開始できるようにし、ユーザからの送金要求情報の受信を促進するのに使用し得る。

幾つかの実施形態では、送金者システム１２０２は、受取人システム１２０４への送金を可能にし得る。例えば、送金者システム１２０２は、第１の非ＦＩシステム１２０６によりサポートされるオンライン支払いプロセス（例えば、オンライン支払いシステム）と対話するように構成されるブラウザ又はアプリケーションを含み得る。

クライアントアプリケーション１２２８は、送金者システム１２０２の機能の１つ又は複数を実施するように構成されるプログラム論理を含み得る。幾つかの実施形態では、クライアントアプリケーション１２２８は、コンテンツを受信し表示する（例えば、表示デバイス１２２４に）ように構成されるアプリケーションを含むか、若しくはアプリケーションであり得、又は送金者ＦＩシステム１２１０からウェブページを受信して表示するように構成されるウェブブラウザを含むか、若しくはウェブブラウザであり得る。例えば、クライアントアプリケーション１２２８は、モバイルウェブブラウザ、ショートメッセージングサービス（ＳＭＳ）又は他のテキストメッセージングアプリケーション、専用アプリケーション、又はネットワーク１２１４を介して情報を送信／受信するように構成される他のコンピュータプログラムを含み得る。

図１２は、送金システム１２００内の送金者システム１２０２を示すが、幾つかの実施形態では、送金者システム１２０２が送金システム１２００内に存在しなくてもよく、又は送金者システム１２０２の機能の幾つか若しくは全てが第１の非ＦＩシステム１２０６により実行されてもよいことに留意する。例えば、第１の非ＦＩシステム１２０６が物理的支払い端末を組み込む幾つかの実施形態では、送金システム１２００は、送金者システム１２０２を含まなくてもよく、及び／又は第１の非ＦＩシステム１２０６は、送金者システム１２０２に帰する機能の幾つかの若しくは全てを実行してもよい。

受取人システム１２０４は、受取人に関連付けられたデジタルデバイスを含み得る。例えば、受取人は、非金融機関（例えば、第１の非ＦＩシステム１２０６）のオンライン支払いプロセスを介して送金者により提供される（例えば、送金者システム１２０２から）資金を受け取る人物であり得る。受取人への送金は、受取人金融機関で受取人が保有する口座への転送を含み得る。幾つかの実施形態では、資金が受取人に提供される前に、受取人金融機関（例えば、受取人ＦＩシステム１２１２）で受取人が保有する受取人口座に送金される。様々な実施形態では、受取人ＦＩシステム１２１２は、送金が送金者ＦＩシステム１２１０の送金者の口座から行われる（例えば、ＡＣＨネットワーク１２１６を介して）前に、受取人に資金を提供し得る。

受取人システム１２０４は、デジタルデバイスの構成要素の幾つか又は全てを有し得、それらの例は図１９に示され、本明細書において更に考察される。送金者システム１２０２のように、受取人システム１２０４は、コンピュータ（例えば、デスクトップ又はラップトップコンピュータ）、携帯電話、スマートフォン、モバイルハンドヘルド無線電子メールデバイス、個人情報端末、ポータブルゲーミングデバイス、又は他の適するデジタルデバイスであり得る。受取人システム１２０４は、メモリに記憶された命令を実行するように構成される１つ又は複数のプロセッサを含むこともできる。

受取人システム１２０４は、ネットワークインターフェース論理１２３０、表示デバイス１２３２、入力デバイス１２３４、及びクライアントアプリケーション１２３６を含み得る。ネットワークインターフェース論理１２３０、表示デバイス１２３２、及び入力デバイス１２３４は、送金者システム１２０２の相手方と同様に構成し得る。クライアントアプリケーション１２３６は、受取人システム１２０４の機能の１つ又は複数を実施するように構成されるプログラム論理を含み得る。様々な実施形態では、クライアントアプリケーション１２３６は、コンテンツを受信して表示するように構成されるアプリケーション又は第１の非ＦＩシステム１２０６、第２の非ＦＩシステム１２０８、送金者ＦＩシステム１２１０、支払いサービスシステム１２１８、受取人ＦＩシステム１２１２、又は任意の組み合わせからウェブページを受信し、表示するように構成されるウェブブラウザを含み得る。クライアントアプリケーション１２３６は、モバイルウェブブラウザ、ショートメッセージングサービス（ＳＭＳ）若しくは他のテキストメッセージングアプリケーション、専用アプリケーション、又はネットワーク１２１４を介して情報を送信／受信するように構成される他のコンピュータプログラムを含み得る。

様々な実施形態では、受取人システム１２０４は、送金者からの資金の受け取り許可を要求する通知要求、取引の承認を要求する通知要求、送金のステータスを示す通知、及び／又は送金者からの送金成功の通知を受信し得る。受取人システム１２０４は、第１の非ＦＩシステム１２０６、第２の非ＦＩシステム１２０８、又は両方によりサポートされるオンライン支払いプロセスと対話するように構成し得る。

図１２は、送金システム１２００内の受取人システム１２０４を示すが、幾つかの実施形態では、受取人システム１２０４が送金システム１２００内に存在しなくてもよく、又は受取人システム１２０４の機能の幾つか若しくは全てが第２の非ＦＩシステム１２０８により実行されてもよいことに留意する。例えば、第２の非ＦＩシステム１２０８が物理的支払い端末を組み込む幾つかの実施形態では、送金システム１２００は、受取人システム１２０４を含まなくてもよく、及び／又は第２の非ＦＩシステム１２０８は、受取人システム１２０４に帰する機能の幾つかの若しくは全てを実行してもよい。

第１の非ＦＩシステム１２０６は、第１の非金融機関の機能をサポートするように構成される任意の数のデジタルデバイスを含み得る。例えば、第１の非ＦＩシステム１２０６は、小売業者のウェブサイトをホストするサーバであり得る。ウェブサイトでは、ユーザ（例えば、送金者又は受取人）は製品及び／又はサービスを閲覧することができ得る。ウェブサイトでは、ユーザは製品及び／又はサービスを購入することもでき得る。幾つかの実施形態では、第１の非ＦＩシステム１２０６は、任意の数のデジタルデバイス上のアプリケーション（例えば、クライアントアプリケーション１２２８又はクライアントアプリケーション１２３６）と対話するサーバであり得る。アプリケーションにより、ユーザは、製品及び／又はサービスの支払いを行うことができ得る。

様々な実施形態では、第１の非ＦＩシステム１２０６は、資金を他のユーザに向けるのにユーザを支援するサービスを提供し得る。例えば、第１の非ＦＩシステム１２０６は、送金者又は受取人が支払いサービスシステム１２１８に登録できるようにするインターフェース又はデバイスを提供し得る。インターフェースにより、送金者システム１２０２は、受取人を識別し、受取人への送金額を示すこともでき得る。第１の非ＦＩシステム１２０６は、本明細書に更に記載されるように、情報の全て又は一部を支払いサービスシステム１２１８、送金者ＦＩシステム１２１０、又は任意の他のシステムに提供し得る。そのような実施形態では、第１の非ＦＩシステム１２０６は、メモリに記憶された命令を実行するように構成された１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含み得る。サーバは、送金者システム１２０２上のクライアントアプリケーション１２２８により提供される支払い情報を処理するように構成し得る。

第１の非ＦＩシステム１２０６は、デジタルデバイスの構成要素の幾つか又は全てを有し得、それらの例は図１９に示され、本明細書において更に考察される。幾つかの実施形態では、第１の非ＦＩシステム１２０６は、送金者非金融機関の支払いを管理するように構成される物理的支払い端末を含む。これらの実施形態では、物理的支払い端末は、送金者からの支払い情報（例えば、物理的端末でのクレジットカード）又は送金者システム１２０２からの支払い情報を処理するように構成される回路、他のハードウェア、及び／又はソフトウェアを含み得る。

第１の非ＦＩシステム１２０６は、ネットワーク論理１２３８、任意選択的な表示デバイス１２４０、入力デバイス１２４２、及び非ＦＩアプリケーション１２４４を含み得る。ネットワークインターフェース論理１２３８、表示デバイス１２４０、及び入力デバイス１２４２は、本明細書に記載される相手方と同様に構成し得る。

非ＦＩアプリケーション１２４４は、送金者非金融機関の支払いを管理するように構成し得る。例えば、非ＦＩアプリケーション１２４４は、物理的デバイス、ウェブページ、又は情報をアプリケーション（例えば、クライアントアプリケーション１２２８を含む）に提供し得る。非ＦＩアプリケーション１２４４により、幾つかの実施形態では、ユーザは、以前購入した製品／サービスの支払いをし、製品／サービスを閲覧し、製品／サービスを購入し、及び／又は他への送金要求を提供することができ得る。幾つかの実施形態では、送金者非ＦＩアプリケーション１２４４は、第１の非ＦＩシステム１２０６により指示される物理的支払い端末に提供される支払い情報を処理するプログラム論理を含み得る。送金者非ＦＩアプリケーション１２４４は、第１の非ＦＩシステム１２０６により管理されるオンライン支払いプロセスをサポートするプログラム論理を含み得る。

幾つかの実施形態では、非ＦＩアプリケーション１２４４又は金融サービス提供者（例えば、ＭａｓｔｅｒＣａｒｄネットワーク）は、送金者又は受取人の金融商品に関連付けられた幾つかの他の識別情報（例えば、クレジットカード番号又はデビットカード番号）をトークン化（例えば、暗号化）して、送金者又は受取人のトークンを作成し得る。金融商品の発行又は後援金融機関は、本明細書に記載のように、トークンをトークン化解除しることが可能であり得る。非ＦＩ機関１２４４は、将来の取引のために、送金者又は受取人のトークン化金融商品を記憶し得る。非ＦＩアプリケーション１２４４は、金融商品（例えば、金融商品を発行した金融機関）に関連付けられた金融機関を識別する金融識別子を取得又は識別することもできる。

第２の非ＦＩシステム１２０８は、第１の非ＦＩシステム１２０６と同様であり得る。例えば、両方のシステムは、同じエンティティ又は関連エンティティにより所有し得る（両方のシステムは同じエンティティにサービスを提供する）。代替的に、各システムは、異なるエンティティにより運営、所有、又は制御され得る。

第１の非ＦＩシステム１２０６のように、第２の非ＦＩシステム１２０８は、第２の非金融機関の機能をサポートするように構成される任意の数のデジタルデバイスを含み得る。例えば、第２の非ＦＩシステム１２０８は、送金者又は受取人の公開識別子及び／又は口座番号を受信して、任意の数の個人に送金する物理的インターフェースを提供し得る。別の例では、第２の非ＦＩシステム１２０８は、小売業者のウェブサイトをホストするサーバであり得る。ウェブサイトでは、ユーザ（例えば、送金者又は受取人）は、製品及び／又はサービスの過去の購入及び／又は将来の校入力を閲覧することができ得る。ウェブサイトでは、ユーザは製品及び／又はサービスを購入することもでき得る。幾つかの実施形態では、第２の非ＦＩシステム１２０８は、任意の数のデジタルデバイス上のアプリケーション（例えば、クライアントアプリケーション１２２８又はクライアントアプリケーション１２３６）と対話するサーバであり得る。アプリケーションにより、ユーザは、製品及び／又はサービスの支払いを行うことができ得る。

様々な実施形態では、第２の非ＦＩシステム１２０８は、資金を他のユーザに向けるのにユーザを支援するサービスを提供し得る。例えば、第２の非ＦＩシステム１２０８は、送金者又は受取人が支払いサービスシステム１２１８に登録できるようにするインターフェース又はデバイスを提供し得る。インターフェースにより、送金者システム１２０２は、受取人を識別し、受取人への送金額を示すこともでき得る。第２の非ＦＩシステム１２０８は、本明細書に更に記載されるように、情報の全て又は一部を支払いサービスシステム１２１８、第１のＦＩシステム１２０６、又は任意の他のシステムに提供し得る。そのような実施形態では、第２の非ＦＩシステム１２０８は、メモリに記憶された命令を実行するように構成された１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含み得る。サーバは、受取人システム１２０４上のクライアントアプリケーション１２３６により提供される支払い情報を処理するように構成し得る。

第２の非ＦＩシステム１２０８は、デジタルデバイスの構成要素の幾つか又は全てを有し得、それらの例は図１２に示され、本明細書において更に考察される。幾つかの実施形態では、第２の非ＦＩシステム１２０８は、受取人非金融機関の支払いを管理するように構成されるサーバ及び／又は物理的支払い端末を含む。物理的支払い端末は、受取人システム１２０４上の支払いハードウェアにおいて支払い情報を処理するように構成される回路、他のハードウェア、及び／又はソフトウェアを含み得る。

幾つかの実施形態では、第２の非ＦＩシステム１２０８は、受取人非金融機関のオンライン支払いプロセスをサポートするように構成し得る。そのような実施形態では、第２の非ＦＩシステム１２０８は、メモリに記憶された命令を実行するように構成された１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含み得る。サーバは、受取人システム１２０４上のクライアントアプリケーション１２３６により提供される支払い情報を処理するように構成し得る。

第２の非ＦＩシステム１２０８は、ネットワークインターフェース論理１２４６、表示デバイス１２４８、入力デバイス１２５０、及び非ＦＩアプリケーション１２５２を含み得る。ネットワークインターフェース論理１２４６、表示デバイス１２４８、及び入力デバイス１２５０は、本明細書に記載される相手方と同様に構成し得る。非ＦＩアプリケーション１２５２は、支払いを管理するように構成し得る。受取人非ＦＩアプリケーション１２５２は、第２の非ＦＩシステム１２０８によりサポートされるウェブサイト又は物理的支払い端末に提供される支払い情報を処理するプログラム論理を含み得る。幾つかの実施形態では、受取人非ＦＩアプリケーション１２５２は、第２のＦＩシステム１２０８により管理されるオンライン支払いプロセスをサポートするプログラム論理と、送金者又は受取人の金融商品をトークン化する論理とを含む。

送金者ＦＩシステム１２１０は、金融機関（例えば、送金者金融機関）により運営されるか、又は金融機関（例えば、送金者金融機関）にサービスを提供する任意のデジタルデバイスであり得る。送金者ＦＩシステム１２１０は、デジタルデバイスの構成要素の幾つか又は全てを有し得、それらの例は図１９に示され、本明細書において更に考察される。送金者ＦＩシステム１２１０は、送金者の代理として１つ又は複数の口座を保有し得る。送金者金融機関は、要求払預金口座、クレジットカード口座、住宅抵当貸付け、学生ローン等の顧客により保有される口座を維持し得る。送金者ＦＩシステム１２１０は、メモリに記憶された命令を実行し、メモリに記憶されたデータを送受信し、１つ又は複数の動作を実行するように構成される１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含み得る。送金者ＦＩシステム１２１０は、ネットワークインターフェース論理１２５４、口座処理論理１２５６、口座データベース１２５８、情報ディレクトリ１２６０、及びトークン管理論理１２６２を含み得る。ネットワークインターフェース論理１２５４は、送金者ＦＩシステム１２１０をネットワーク１２１４に接続するプログラム論理を含み得る。ネットワークインターフェース論理１２５４は、送金者ＦＩシステム１２１０と図１２の他の要素との間のセキュア通信を促進し得る。

口座処理論理１２５６は、当座口座及び普通口座への貸方記入及び借方記入、住宅抵当及び住宅担保への貸方記入及び借方記入、学生ローン口座への貸方記入及び借方記入等の口座保有者の口座に関連する取引を処理するように構成し得る。幾つかの実施形態では、口座保有者の口座（例えば、参加者の口座）内外に送金される場合、口座処理論理１２５６は、口座データベース１２５８において適切な借方記入及び貸方記入を反映し得る。口座処理論理１２５６は、送金者から受取人に送金する送金要求を処理することもできる。本明細書に記載される技法を使用して送金し得る。

口座データベース１２５８は、顧客の代理として銀行により維持される口座の口座情報（例えば、取引、口座保有者についての情報等）を記憶するように構成し得る。

情報ディレクトリ１２６０は、送金を行うために使用される口座情報に、ユーザ識別子を相関付けるテーブルを記憶するように構成し得る。情報ディレクトリ１２６０は、口座情報を指定しないユーザ識別子が送金を行うために使用される場合に使用し得る。幾つかの実施形態では、情報ディレクトリ１２６０は、送金者の秘密識別子を口座データベース１２５８内の送金者の口座に関連付け得る。情報ディレクトリ１２６０について更に本明細書において記載する。

「口座情報」は、本明細書で使用される場合、送金の参加者に又は送金の参加者から送金を行うのに使用される情報を指し得る。口座情報は、例えば、送金を行う口座番号、銀行支店コード、クレジットカード番号、デジタル通貨コード等を含み得る。

「ユーザ識別子」又は同義の「ユーザトークン」は、本明細書で使用される場合、送金を目的として、送金の参加者を識別する情報を指し得る。ユーザ識別子は、公開識別子／公開トークン及び秘密識別子／秘密トークンを含み得るか、又は関連し得る。

「公開識別子」又は同義の「公開トークン」は、送金の参加者を識別するが、参加者に関連する口座情報を識別しない情報を指し得る。幾つかの実施形態では、公開識別子は、参加者により互いと共有されるように構成し得る。例として、参加者は、参加者に送金することを望むか、又は参加者から資金を受け取ることを望む他の参加者と公開識別子を共有することを望み得る。公開識別子は、例えば、電子メールアドレス又は電話番号等の参加者（例えば、送金者又は受取人）の識別に使用し得る他の情報であり得る。

「秘密識別子」又はそれと同義の「秘密トークン」は、本明細書で使用される場合、ユーザ（例えば、ＦＩシステムに口座を有するユーザ）を識別する情報を指し得、及び／又は参加者に関連する口座情報（例えば、口座番号）に関連付けられ得る。秘密識別子は、送金者ＦＩシステム１２１０により生成し得、送金者ＦＩシステム１２１０により、口座番号、銀行支店番号、クレジットカード情報等の口座情報を識別するのに使用し得る。幾つかの実施形態では、秘密識別子は、銀行口座番号、銀行支店コード、クレジットカード番号等を含まない。

秘密識別子は、参加者への送金を行う支払いネットワークのメンバである１つ又は複数の金融機関及びエンティティにより知られ得る。一例では、送金者ＦＩシステム１２１０は、送金者に関連付けられた秘密識別子を生成し得る。しかし、秘密識別子は、いかなる他のエンティティにもいかなる秘密情報も示さなくてよい。送金者ＦＩシステム１２１０は、送金者の秘密識別子を支払いサービスシステム１２１８と共有し得る。送金者の秘密識別子は、送金者システム１２０２、送金者、受取人のシステム１２０４、受取人、第１の非ＦＩシステム１２０６、又は第２の非ＦＩシステム１２０８に提供されなくてよい。支払いサービスシステム１２１８も受取人ＦＩシステム１２１２も、送金者の秘密識別子からいかなる口座番号又は他の秘密情報も識別することができない。

ＦＩシステム（例えば、送金者ＦＩシステム１２１０及び受取人ＦＩシステム１２１２）は、ＦＩシステム（例えば、互いと）、本明細書で考察される自動クリアリングハウスシステム１２２０、及び／又は支払いサービスシステム１２１８以外のいかあるエンティティとも秘密識別子を共有しない。同様に、支払いサービスシステム１２１８は、ＦＩシステム以外のいかなるエンティティとも、ＦＩシステムから受信される秘密識別子を共有しない。本明細書に記載のように、非金融機関間の送金への参加者は、本明細書に記載の技法を使用して、参加者が互いに提供する公開識別子を使用して互いに送金し得る。この構成では、幾つかの実施形態では、送金者は、必ずしも受取人に関する秘密／個人情報（すなわち、受取人の銀行口座／銀行支店コード）を有する必要なく、受取人（例えば、電子メールアドレス又は他の識別子を用いて）を一意に識別することができる。本明細書に既に説明した公開識別子及び秘密識別子に加えて、追加の識別子を使用することもできる。例えば、そのような追加の識別子は、様々なレベルのセキュリティで扱い得る。別の例として、更に詳細に以下に考察するように、既存の公開識別子の変形を使用して特殊目的公開トークン、カスタマイズされた機能を有する公開トークン等を実施し得る。

送金者ＦＩシステム１２１０は、口座データベース１２５８及び情報ディレクトリ１２６０を含み得る。ユーザが本明細書に記載の支払いサービスシステム１２１８に登録すると、送金者ＦＩシステム１２１０は、ユーザの公開識別子に関連付けられた秘密識別子を生成し得る。ユーザの秘密識別子に、ユーザの公開識別子（例えば、ユーザの電子メールアドレス、電話番号、又は他の連絡情報）及び送金者ＦＩシステム１２１０におけるユーザの口座の両方を関連付け得る。口座データベース１２５８は、ユーザの口座を含み得、情報ディレクトリ１２６０は、公開識別子、秘密識別子、及び口座情報（例えば、口座番号）を関連付け得る。口座データベース１２５８は、任意の数のユーザの任意の数の口座を含み得る。情報ディレクトリ１２６０は、任意の数のユーザの任意の数の秘密識別子及び公開識別子についての情報を含み得る。

トークン管理論理１２６２は、トークン（例えば、公開識別子及び／又は秘密識別子）を管理するように構成し得る。様々な実施形態では、トークン管理論理１２６２は、トークンを登録し、トークンを認証し、トークンを生成等するように構成し得る。トークン管理論理１２６２は、トークンが認識されない場合、受取人の識別に役立つこともできる。トークン管理論理１２６２は、特定の口座が使用され、特定の通知方法が使用される等のように、トークンの属性をカスタマイズするのにも使用し得る。トークン管理論理１２６２は、図２に示され、図２に関連して考察されたトークン管理論理１２９の属性の幾つか又は全てを有し得る。

幾つかの実施形態では、トークン管理論理１２６２は、金融商品のトークン（例えば、第１の非ＦＩシステム１２０６によりトークン化された）を認識し、識別し、認証し、トークン化解除するように構成し得る。トークン化解除されると、トークン管理論理１２６２は、本明細書で考察されるような金融商品に関連付けられた口座番号又は銀行支店番号等の金融情報を復元し得る。

受取人ＦＩシステム１２１２は、金融サービスを受取人システム１２０４に提供される金融機関により運営されるデジタルデバイスを含み得る。受取人ＦＩシステム１２１２は、デジタルデバイスの構成要素の幾つか又は全てを有し得、それらの例は図１９に示され、本明細書において更に考察される。受取人金融機関は、要求払預金口座、クレジットカード口座、住宅抵当貸付け、学生ローン等の顧客により保有される口座を維持し得る。受取人ＦＩシステム１２１２は、メモリに記憶された命令を実行し、メモリに記憶されたデータを送受信し、１つ又は複数の動作を実行するように構成される１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含み得る。受取人ＦＩシステム１２１２は、ネットワークインターフェース論理１２６４、口座処理論理１２６６、口座データベース１２６８、情報ディレクトリ１２７０、及びトークン管理論理１２７２を含み得る。ネットワークインターフェース論理１２６４、口座処理論理１２６６、口座データベース１２６８、情報ディレクトリ１２７０、及びトークン管理論理１２７２は、送金者ＦＩシステム１２１０の相手方と同様に構成し得る。

支払いサービスシステム１２１８は、送金者から受取人への（例えば、送金者システム１２０２により指示されるような、第１の非ＦＩシステム１２０６を介して送金者ＦＩシステム１２１０の送金者口座から受取人ＦＩシステム１２１２の受取人口座への）セキュア送金を可能にする支払いサービスを可能又は促進するように構成されるデジタルデバイスを含み得る。支払いサービスシステム１２１８は、デジタルデバイスの構成要素の幾つか又は全てを有し得、それらの例は図１９に示され、本明細書において更に考察される。支払いサービスシステム１２１８は、メモリに記憶された命令を実行し、メモリに記憶されたデータを送受信し、１つ又は複数の動作を実行するように構成される１つ又は複数のプロセッサをそれぞれ有する１つ又は複数のサーバを含み得る。

幾つかの実施形態では、支払いサービスシステム１２１８は、送金者ＦＩシステム１２１０、受取人ＦＩシステム１２１２、送金者非ＦＩ銀行システム１２１４、及び受取人非ＦＩ銀行システム１２１６の１つ又は複数間での送金を支援する。

支払いサービスシステム１２１８は、メンバ銀行に口座を有する参加者に支払いサービスを提供し得る。より詳細には、幾つかの実施形態では、送金者ＦＩシステム１２１０及び受取人ＦＩシステム１２１２に関連付けられた金融機関は、メンバ銀行を含み得る。「メンバ銀行」は、本明細書で使用される場合、支払いサービスシステム１２１８のメンバであり、互いに送信するために政府機関、規制機関等により確立されたプロトコルに従う金融機関を指し得る。様々な実施形態では、支払いサービスシステム１２１８は、メンバ銀行ではない金融機関に口座を有する参加者に支払いサービスを提供する。

支払いサービスシステム１２１８は、ネットワークインターフェース論理１２７４、口座処理論理１２７６、口座データベース１２７８、情報ディレクトリ１２８０、トークン管理論理１２８２、送金論理１２８４、及び登録論理１２８６を含み得る。ネットワークインターフェース論理１２７４、口座処理論理１２７６、口座データベース１２７８、情報ディレクトリ１２８０、及びトークン管理論理１２８２は、送金者ＦＩシステム１２１０の相手方と同様に構成し得る。

様々な実施形態では、送金への参加者は、ネットワーク１２１４を使用して情報を情報ディレクトリ１２８０と共有し得る。ネットワークインターフェース論理１２７４は、ネットワーク１２１４を介して情報を受信するように構成し得る。口座処理論理１２７６は、口座データベース１２７８内に公開識別子に関連付けられた口座があるか否かを特定することにより、参加者の公開識別子が登録されているか否かを特定し得る。参加者は、送金者ＦＩシステム１２１０又は第１の非ＦＩシステム１２０６を通して送金システム１２００に登録すると、情報ディレクトリ１２８０に追加し得る。登録されると、情報ディレクトリ１２８０を実施するデータベース内に、新たに登録されたユーザの新しいエントリを作成し得る。幾つかの実施形態では、情報ディレクトリ１２８０は、送金者ＦＩシステム１２１０を含むセキュアオンラインバンキングセッション中、公開識別子及び秘密識別子で自動的に埋められる。

幾つかの実施形態では、情報ディレクトリ１２８０は、特定の参加者に結び付いた他の参加者のレジストリを記憶する。例えば、ユーザ毎に、情報ディレクトリ１２８０は、ユーザが結び付きを確立した他の各ユーザのリストを含むレジストリを記憶し得る。そのような結び付きは、例えば、ユーザが他のユーザと資金をやりとりした最初のときに確立し得る。結び付きは、情報ディレクトリ１２８０及び／又は別の情報ディレクトリナイオンルックアップサービスを通して、ユーザが他のユーザとの結び付きを追加できるようにするユーザインターフェースにより確立することもできる。そのようなユーザインターフェースの例については、図４に関連して、本明細書において更に考察されている。ユーザは、送金支払いネットワークに登録しているユーザのみならず、更に詳細に後述するように、他の関連支払いネットワークに登録しているユーザも含み得る。レジストリ内のユーザ毎に、ユーザの一意のＩＤ及び／又は他の情報等の追加情報を記憶し得る。別の例として、他のユーザの情報は、情報ディレクトリ１２８０内の別個のデータベースエントリに記憶し得る。

様々な実施形態では、情報ディレクトリ１２８０は、複数の情報ディレクトリのうちの１つを含み得、各情報ディレクトリは、異なる機関又はエンティティにより維持される。各情報ディレクトリは、各情報ディレクトリを含むデジタルデバイスに関連する参加者についての情報を記憶し得る。各情報ディレクトリは、関連する参加者が情報ディレクトリに登録できるようにし得る。

送金論理１２８４は、２人の参加者間での送金を支援するように構成し得る。送金論理１２８４については図１３に関して更に説明する。送金は、送金者から受取人への送金を含み得る。様々な実施形態では、転送への全ての参加者は、支払いサービスシステム１２１８により提供される送金サービスに登録していることがある。しかし、幾つかの実施形態では、少なくとも１人の参加者は、金融機関の金融サービスのみに登録し得、及び／又は非金融機関の購入プロセス（物理的購入端末、オンライン購入プロセス等）の使用に登録していることがある。本明細書に記されるように、支払いサービスシステム１２１８により提供される送金サービスへの登録は、参加者口座の公開識別子の登録及び／又は参加者償還ツール（例えば、金融商品）の受け取りを含み得、これら両方について本明細書において更に考察する。様々な実施形態では、送金の受取人は、支払いを受け入れるためにいかなる行動もとる必要がなくてよい（例えば、受取人は、受取人による更なる行動なしで、受取人の特定の口座への送金を可能にする「自動受け入れ」ステータスを有し得る）。幾つかの実施形態では、受取人は、少なくとも幾つかの送金又は全ての送金を手動で受け入れる必要があり得ることに留意する。

幾つかの実施形態では、支払いサービスシステム１２１８は、個人のオンラインコミュニティに提供されるウェブポータルを提供し得、ウェブポータルにおいて、そのような個人は、ユーザの名前／ログインＩＤを取得するか、又は他に登録メンバになる。個人は、例えば、ウェブポータルを使用して互いと対話し、及び／又はオンラインコミュニティにより提供されるサービスと対話し得る。オンラインコミュニティの例としては、ＭＳＮ（登録商標）、ｉＰｈｏｎｅ（登録商標）ユーザ、Ｆａｃｅｂｏｏｋ（登録商標）、ＬｉｎｋｅｄＩｎ（登録商標）等が挙げられる。支払いサービスは、例えば、オンラインコミュニティのメンバにウェブポータルにより提供される追加のサービスであり得る。別の例として、支払いサービスは、例えば、金融機関が、送金者ＦＩシステム１２１０、受取人ＦＩシステム１２１２、送金者非ＦＩ銀行システム１２１４、及び受取人非ＦＩ銀行システム１２１６により実行されるものとして本明細書で説明される両方の動作を実行するように、金融機関の１つにより提供し得る。

第２の非ＦＩシステム１２０８が物理的購入端末に対応する実施形態では、送金論理１２８４は、送金者ＦＩシステム１２１０から第２の非ＦＩシステム１２０８への送金を管理し得る。第２の非ＦＩシステム１２０８で得られた資金は、物理的な通貨、デジタル通貨等の形態をとり得、受取人は、物理的購入端末から取得し得る。第２の非ＦＩシステム１２０８がオンライン支払いプロセスをサポートする実施形態では、送金論理１２８４は、送金者ＦＩシステム１２１０から第２の非ＦＩシステム１２０８及び／又は受取人システム１２０４への送金を管理し得る。第２の非ＦＩシステム１２０８及び／又は受取人システム１２０４で得られた資金は、受取人ＦＩシステム１２１２により管理され、並びに／或いは第２の非ＦＩシステム１２０８及び／又は受取人システム１２０４によりアクセスされるオンライン口座に入金することができるデジタル通貨等の形態をとり得る。幾つかの実施形態では、送金論理１２８４は、未登録参加者への送金を促進し得る。幾つかの実施形態では、送金論理１２８４は、取引データから公開識別子を抽出するように、送金者ＦＩシステム１２１０及び受取人ＦＩシステム１２１２に指示し得る。送金論理１２８４は、公開識別子が抽出された後、ＤＤＡを取得するように、送金ＦＩシステム１２１０及び／又は受取人ＦＩシステム１２１２に更に指示し得る。

登録論理１２８６は、送金への未登録参加者の登録を管理するように構成し得る。登録論理１２８６については図１４に関して更に説明する。幾つかの実施形態では、登録論理１２８６は、これらの参加者口座にアクセスするために、参加者口座を発行し得る。「参加者口座」は、本明細書で使用される場合、支払いサービスシステム１２１８により管理されて、金融機関間の送金を支援する登録口座を指し得る。参加者口座は、金融機関により提供される金融口座内の資金にリンク及び／又は資金により後援し得る。参加者口座は、口座番号及び／又は他の口座識別子により識別し得る。

登録論理１２８６は、参加者がそれらの参加者口座のユーザ識別子を登録しようとする場合、それらの参加者口座のトークン化口座データを作成し得る。「トークン化口座データ」は、本明細書で使用される場合、外部発見から口座情報をセキュアにする口座情報の表現を含み得る。幾つかの実施形態では、トークン化口座データは、プロキシ番号又は口座情報を暗号化したものを含み得る。トークン化口座データは、口座情報に関連付けられた金融機関の名称／識別子等を更に含み得る。様々な実施形態では、登録論理１２８６は、ユーザが参加者口座のユーザ識別子を登録できるようにし得る。

自動クリアリングハウス（ＡＣＨ）システム１２２０は、送金者及び受取人の銀行口座と資金をやりとりするのに使用される１つ又は複数のデジタルデバイスを含み得る。自動クリアリングハウス（ＡＣＨ）システム１２２０は、送金者及び受取人の銀行口座と資金をやりとりするのに使用し得る。幾つかの実施形態では、ＡＣＨシステム１２２０は、送金者ＦＩコンピュータシステム１２１０と受取人ＦＩコンピュータシステム１２１２との間の資金及び／又は情報のセキュアな転送を促進し得る。ＡＣＨシステム１２２０は、図１に示されるＡＣＨシステム１７０と同様に構成されるコンピュータシステムを含み得る。

幾つかの実施形態では、ＡＣＨシステム１２２０は、バッチ処理システムを可能にし得る。「バッチ処理システム」は、本明細書で使用される場合、金融機関が、指定された時間期間にわたり取引を蓄積できるようにするシステムを含み得る。幾つかの実施形態では、バッチ処理システムを介して互いと資金を転送する金融機関は、指定された時間期間（１時間毎、１日毎、１週間毎等）にわたり又は指定されたイベントが生じるまで取引を蓄積し得る。指定された時間期間又は指定されたイベント後、金融機関は、プライベートネットワーク（例えば、ＡＣＨネットワーク１２１６）及び／又はＡＣＨシステム１２２０を使用して互いへの支払額を決済し得る。幾つかの実施形態では、バッチ送金システムは、金融機関が必要に応じて互いに送金し、毎日、毎週等の指定された時間に互いに支払う金額を決済できるようにし得る。決済時間は、規制によりサポートし得る。例として、全米自動決済協会（ＮＡＣＨＡ）規則では、特定の送金後、次の営業日の終了前に、バッチ処理システムを使用して互いへのクレジットを決済することを金融機関に要求し得る。

様々な実施形態では、ＡＣＨネットワーク１２２０は、送金者ＦＩシステム１２１０及び受取人ＦＩシステム１２１２が電子的に送金できるようにし得る。小切手を用いる場合等、紙を使用して必要な取引情報を伝える代わりに、ＡＣＨネットワーク１２２０を介した取引は、プライベートネットワークを介して電子的に伝送し得、より高速且つよりセキュアな処理時間及びコスト節約を可能にする。ＡＣＨネットワーク１２２０は、口座振り込み取引及び直接払い取引を含むが、これらに限定されない異なるタイプの取引を処理し得る。口座振り込み取引は、給与の入金、従業員費用の払い戻し、政府の給付金、税金及び他の払い戻し、並びに年金及び利子の支払いを含み得る。直接振り込み取引は、企業又は政府から消費者へのＡＣＨクレジット支払いを含み得る。直接払い取引は、資金を使用して支払うことを含み得る。幾つかの実施形態では、個人及び／又は組織は、ＡＣＨクレジット又はＡＣＨデビットのいずれかとしてＡＣＨを介して直接払いを行うことができる。直接払い取引は、ＡＣＨデビット取引、ＡＣＨクレジット取引、又はそれらの何らかの組み合わせとして処理し得る。ＡＣＨクレジット取引として処理される直接払い取引は、資金を口座にプッシュする。この例は、消費者が、諸費者の銀行又は信用組合を通して、請求書に支払うための支払いを開始する場合である。ＡＣＨデビット取引として処理される直接払いは、資金を口座からプルし得る。この例は、消費者が住宅ローン又は公共料金の毎月繰り返される支払いを確立し、消費者の口座から自動的に引き落とされる場合である。

図１２は、送金者システム１２０２及び受取人システム１２０４を記載しているが、送金者システム１２０２及び受取人システム１２０４が任意選択的なものであることが理解される。例えば、送金者は、例えば、クレジットカード番号又はデビットカード番号を送金者から受信するように構成される物理的デバイスを含み得る第１の非ＦＩシステム１２０６と直接対話し得る。物理的デバイスは、送金者の公開識別子を更に受信し得る。幾つかの実施形態では、物理的デバイス又は送金者システム１２０２の別の部分は、受取人への送金額及び受取人公開識別子を更に受信し得る。この例では、物理的デバイス、送金者システム１２０２、又は金融サービス提供者（例えば、ＭａｓｔｅｒＣａｒｄ又はＶｉｓａ）は、クレジットカード番号及び／又はデビットカード番号をトークン化し、及び／又は金融商品を後援又は発行した金融機関の識別子を提供し得る。非ＦＩシステム１２０６及び／又は金融サービス提供者は、送金者公開識別子、金融機関の識別子（例えば、送金者ＦＩシステム１２１０を識別する）、送金額、及び／又は受取人識別子を支払いサービスシステム１２１８及び／又は送金者ＦＩシステム１２１０に提供し得る。

図１３は、幾つかの実施形態による送金論理１２８４の論理を示す。送金論理１２８４は、取引データ管理論理１３０２、支払い検証論理１３０４、情報ディレクトリ管理論理１３０６、支払い通知論理１３０８、及び支払いステータス管理論理１３１０を含み得る。取引データ管理論理１３０２、支払い検証論理１３０４、情報ディレクトリ管理論理１３０６、支払い通知論理１３０８、及び支払いステータス管理論理１３１０の１つ又は複数は、物理的なコンピュータプロセッサ及び送金論理１２８４に記憶されたメモリを使用して実施し得る。メモリは、取引データ管理論理１３０２、支払い検証論理１３０４、情報ディレクトリ管理論理１３０６、支払い通知論理１３０８、及び支払いステータス管理論理１３１０の１つ又は複数を実施するように物理的なプロセッサに指示するコンピュータプログラム命令を記憶し得る。

取引データ管理論理１３０２は、特定のシステム（例えば、送金者システム１２０２、受取人システム１２０４、第１の非ＦＩシステム１２０６、及び第２の非ＦＩシステム１２０８）との取引データ並びに支払いサービスシステム１２１８との取引データを含め、取引データを管理するように構成し得る。「取引データ」は、本明細書で使用される場合、ある参加者から別の参加者に（例えば、送金者から、第１の非ＦＩシステム１２０６から受信した受取人に）送金を実行する要求、送金者の公開識別子、受取人の公開識別子、送金する取引を識別する取引識別子、送金者の秘密識別子、受取人の秘密識別子、送金者に関連付けられた金融機関（ＦＩ）識別子、受取人に関連付けられたＦＩ識別子、又は任意の組み合せを含め、取引に関連するデータを指し得る。幾つかの実施形態では、取引データは送金額を含む。

取引データ管理論理１３０２は、幾つかの実施形態では、送金者が資金を受取人に提供しようとしていることを示す取引データを受信し得る（例えば、送金者システム１２０２、第１の非ＦＩシステム１２０６、送金者ＦＩシステム１２１０、及び／又は金融サービス提供者から）。取引データは、この例では、送金者の公開識別子、受取人の公開識別子、送金者ＦＩシステム識別子、及び送金額を含み得る。取引データ管理論理１３０２は、送金者の公開識別子を登録ユーザのリスト（例えば、口座データベース１２７８、情報ディレクトリ１２８０等内の情報）と比較することにより、送金者が登録されているか否かを特定し得る。登録されている場合、取引データ管理論理１３０２は、送金者が第１の非ＦＩシステム１２０６及び／又は送金者システム１２０２に登録されていることの成功メッセージを提供し得る。更に、取引データ管理論理１３０２は、送金者の秘密識別子及び送金額を送金者ＦＩシステム１２１０に提供し得る。取引データ管理論理１３０２は、受取人の公開識別子、受取人の秘密識別子、受取人ＦＩ識別子、送金者の公開識別子、及び／又は任意の他の情報を送金者ＦＩシステム１２１０に提供することもできる。

取引データ管理論理１３０２は、送金者ＦＩシステム１２１０が送金者の口座を識別し、送金者が取引に十分な資金を有することを示す認証を送金者ＦＩシステム１２１０から受信し得る。随時、取引データ管理論理１３０２は、送金者から受取人に送金する取引を識別する取引識別子を生成し、送金者ＦＩシステム１２１０及び／又は受取人ＦＩシステム１２１２と共有し得る。

幾つかの実施形態では、取引データ管理論理１３０２は、第１の非ＦＩシステム１２０６が送金オプションをシステムのユーザに提供できるようにする論理及び／又は命令を第１の非ＦＩシステム１２０６に提供し得る。例えば、取引データ管理論理１３０２は、第１の非ＦＩシステム１２０６により送金者又は送金者システム１２０２に提供される物理的デバイス、ウェブページ、又はコード内に配置又は組み込まれる論理（例えば、コード又はソフトウェア）を第１の非ＦＩシステム１２０６を提供し得る。論理は、送金者が送金オプションを閲覧できるようにし、送金者が受取人の公開識別子を入力又は選択できるようにし、送金者自身の公開識別子を送金者が入力又は選択できるようにし、送金額を示し、送金者のデビットカード番号又はクレジットカード番号及び／又は任意の他の情報を受信できるようにし得る。

検証論理１３０４は、取引データに関連する支払い詳細を検証するように構成し得る。検証は、送金者の公開識別子が登録されているか否かを特定すること、受取人の公開識別子が登録されているか否かを特定すること、又はＦＩ識別子に既知の金融機関（又はメンバ金融機関）が関連付けられていることの特定を含み得る。ＦＩ識別子が、送金者のデビットカード番号若しくはクレジットカード番号のトークン化の一環として、又は任意の数の方法（例えば、送金者のデビットカード若しくはクレジットカード又は送金者により提供される情報に基づいて取得される）で生成し得ることが理解される。

様々な実施形態では、検証論理１３０４は、送金者が要求された資金を提供する認可を有するか否かの金融機関からの確認を要求する１つ又は複数の検証プロトコル（例えば、検証インターフェース）を実施する。検証論理１３０４は、１つ又は複数のチェックを更に実施して、取引データに関連付けて提供された公開識別子が有効であるか否かを調べ得る。

情報ディレクトリ管理論理１３０６は、情報ディレクトリ１２８０に取引データを追加する命令を提供するように構成し得る。様々な実施形態では、情報ディレクトリ管理論理１３０６は、情報ディレクトリ１２８０の追加、削除、及び／又は他に変更又は管理を行い得る。

支払い通知論理１３０８は、支払い通知、例えば、受取人及び／又は送金者への送金の成功又は失敗を示す通知を送金者ＦＩシステム１２１０に提供し、サポートするように構成し得る。

支払いステータス管理論理１３１０は、送金が可能であるか否か又はエラーがあるか否かを示すステータス更新を管理するように構成し得る。幾つかの実施形態では、支払いステータス管理論理１３１０は、送金プロセスを支援するために、追加の情報を要求し得る。

図１４は、幾つかの実施形態による登録論理１２８６の図を示す。幾つかの実施形態では、登録論理１２８６が送金者及び／又は受取人を一度登録し得ることが理解される。登録論理１２８６は、参加者口座発行論理１４０２、ユーザ識別検証論理１４０４、トークン化論理１４０６、金融機関識別論理１４０８、及び口座確認論理１４１０を含み得る。参加者口座発行論理１４０２、ユーザ識別検証論理１４０４、トークン化論理１４０６、金融機関識別論理１４０８、及び口座確認論理１４１０の１つ又は複数は、物理的コンピュータプロセッサ及び登録論理１２８６に記憶されたメモリを使用して実施し得る。メモリは、参加者口座発行論理１４０２、ユーザ識別検証論理１４０４、トークン化論理１４０６、金融機関識別論理１４０８、及び口座確認論理１４１０の１つ又は複数を実施するように物理的プロセッサに指示するコンピュータプログラム命令を記憶し得る。

参加者口座発行論理１４０２は、参加者口座の発行を促進するように構成し得る。幾つかの実施形態では、参加者口座発行論理１４０２は、口座番号及び／又は参加者口座のベースとして参加者が使用することができる他の口座識別子（例えば、金融機関間の送金を支援し得る）を作成し得る。

ユーザ識別検証論理１４０４は、参加者口座の登録にユーザ識別子が提供されるとき、ユーザ識別子を検証するように構成し得る。様々な実施形態では、ユーザ識別検証論理１４０４は、参加者が特定の参加者口座を登録する権利を有するか否かを評価するように構成される。ユーザ識別検証論理１４０４は、参加者により提供されるユーザ識別子及び／又は参加者口座情報が金融機関の口座に関連付けられているか否か、又は金融機関を識別し得るか否かを特定するように更に構成し得る。

公開識別子の検証は、公開識別子が適切なフォーマット（例えば、適切な英数字フォーマット）であることの検証、公開識別子が以前に別の参加者に割り当てられていないことの検証、公開識別子が口座情報を含んでいないことの検証等の１つ又は複数の検証技法を含み得る。

トークン化論理１４０６は、参加者口座情報をトークン化するように構成し得る。様々な実施形態では、トークン化論理１４０６は、参加者口座情報を暗号化し、又はプロキシ番号を参加者口座情報に割り当てて、非金融機関を含む外部エンティティにより参加者口座情報が発見されないようにし得る。

金融機関識別論理１４０８は、参加者口座情報に関連付けられた金融機関を識別するように構成し得る。金融機関識別論理１４０８は、金融サービスを参加者システムに提供する参加者金融機関を識別し得る。幾つかの実施形態では、金融機関識別論理１４０８は、トークン化口座データに含まれる金融機関のユーザ名／識別子等を使用して適切な参加者金融機関を識別し得る。例として、参加者システムが送金者システム１２０２に対応する実施形態では、金融機関識別論理１４０８は送金者ＦＩシステム１２１０を識別し得る。参加者システムが受取人システム１２０４に対応する実施形態では、金融機関識別論理１４０８は受取人ＦＩシステム１２１２を識別し得る。

口座確認論理１４１０は、ステータス更新及び／又は他の情報を提供して、参加者口座の登録が成功したか否かを示し得る。口座確認論理１４１０は、公開識別子の所有権を確認し、参加者シムに対応する非ＦＩシステムに公開識別子及び口座情報を送信するように参加者システムに指示し得る。例として、口座確認論理１４１０は、公開識別子の所有権を確認し、公開識別子及び口座情報を第１の非ＦＩシステム１２０６に送信するように送金者システム１２０２に指示し得る。別の例として、口座確認論理１４１０は、公開識別子の所有権を確認し、公開識別子及び口座情報を第２の非ＦＩシステム１２０８に送信するように受取人システム１２０４に指示し得る。

口座確認論理１４１０は、参加者システムに対応する非ＦＩシステムに、公開識別子及びトークン化口座データを支払いサービスシステム１２１８に送信するように指示し得る。幾つかの実施形態では、公開識別子及びトークン化口座データは、支払いサービスシステム１２１８に直接送信され、一方、他の実施形態では、公開識別子及びトークン化口座データは、送金者非ＦＩ銀行システム１２１４を通して支払いサービスシステム１２１８に送信される。口座確認論理１４１０は、関連する参加者ＦＩシステムに、トークン化口座データを使用して、参加者に関連付けられた金融機関の識別子を取得するように指示し得る。口座確認論理１４１０は、ＤＤＡルックアップを実行し、ＤＤＡ番号を公開識別子にマッピングし、公開識別子を関連するユーザ口座に関連付けるように、参加者ＦＩシステムに指示し得る。様々な実施形態では、口座確認論理１４１０は、参加者が非金融機関での送金登録に成功したか否かの確認を提供し得る。

図１５は、幾つかの実施形態による、送金システムにおいて送金者から受取人にセキュアに送金するデータフロー１５００の図を示す。図１５に示されるデータフロー１５００は、例えば、送金者及び受取人の両方が支払いサービスシステム１２１８に既に登録している例であり得る。データフロー１５００は、図１２に示され、本明細書において更に考察する送金システム１２００の構成要素を含む。より具体的には、データフロー１５００は、送金者システム１２０２、受取人システム１２０４、第１の非ＦＩシステム１２０６、送金者ＦＩシステム１２１０、受取人ＦＩシステム１２１２、及び支払いサービスシステム１２１８の１つ又は複数の動作を含む。データフロー１５００の要素が単なる例であり、様々な実施形態が、本明細書に記載される本発明の概念の範囲及び趣旨から逸脱せずに、より多数の要素又はより少数の要素を利用し得ることに留意する。

動作１５０２において、送金者システム１２０２は、送金者システム１２０２から、送金に関連する取引データを受信し得る。取引データは、送金額、送金者（例えば、送金者システム１２０２に関連付けられる参加者）の公開識別子及び受取人（例えば、第２の非ＦＩシステム１２０８に関連付けられた参加者）の公開識別子を指定し得る。更に本明細書に記載されるように、送金者及び受取人の公開識別子は、口座情報を金融機関外部に提供する必要なく、受取人への送金のルーティングを促進すると共に、送金者金融口座と受取人金融口座との調停を促進し得る。

動作１５０４において、送金者システム１２０２は、公衆ネットワーク１２１４（又は任意のネットワーク）を介して取引データを第１の非ＦＩシステム１２０６に提供し得る。様々な実施形態では、送金者システム１２０２は、取引データを物理的購入端末又は第１の非ＦＩシステム１２０６によりサポートされるオンライン購入プロセスにより調達されるアプリケーション、若しくはウェブサイト等に提供し得る。取引データは、送金額並びに送金者及び受取人の公開識別子を含み得る。

動作１５０２及び１５０４が任意選択的であり得ることが理解される。例えば、本明細書で考察されるように、非ＦＩシステム１２０６は、送金者システム１２０２なしで、送金者から送金情報（例えば、送金者公開識別子、クレジット又はデビットカード番号、送金元口座等）を受信するように構成される物理的デバイスを含み得る。

動作１５０６において、第１の非ＦＩシステム１２０６は、取引データを支払いサービスシステム１２１８にルーティングし得る。第１の非ＦＩシステム１２０６は、送金者及び受取人の識別子が、支払いサービスシステム１２１８により管理される送金に対応するフォーマットであることを認識し得る。動作１５０８において、第１の非ＦＩシステム１２０６は、公衆ネットワーク１２１４（又は任意の他のネットワーク）を介して取引データを支払いサービスシステム１２１８に提供し得る。

動作１５１０において、支払いサービスシステム１２１８は、取引データの支払い詳細を検証し得る。本明細書に記載されるように、検証は、送金者の公開識別子が有効であるか否か、受取人の公開識別子が有効であるか否か、送金者が、要求された資金を提供する許可を有するか否か等を特定することを含み得る。幾つかの実施形態では、支払いサービスシステム１２１８は、送金者の公開識別子が送金者秘密識別子及びＦＩシステム（例えば、送金者ＦＩシステム１２１０）に関連付けられていることを確認する。同様に、支払いサービスシステム１２１８は、受取人の公開識別子が受取人秘密識別子及びＦＩシステム（例えば、受取人ＦＩシステム１２１２）に関連付けられていることを確認し得る。支払い検証論理１３０４は動作１５１０を実行し得る。

動作１５１２において、支払いサービスシステム１２１８は、取引データの幾つか又は全てを情報ディレクトリ１２８０に追加し得る。例えば、支払いサービスシステム１２１８は、送金情報（例えば、時刻、送金額、受取人秘密識別子、送金者ＦＩ識別子、受取人ＦＩ識別子、及び／又は取引識別子等）をログ記録し得る。幾つかの実施形態では、支払いサービスシステム１２１８は、追加の送金者公開識別子等の追加の情報を受取人口座と共に記憶し得る。様々な実施形態では、送金要求が情報ディレクトリ１２８０に問題なく追加された場合、支払いサービスシステム１２１８は、その趣旨の通知を第１の非ＦＩシステム１２０６に送信し得る。情報ディレクトリ管理論理は動作１５１２を実行し得る。

動作１５１４において、情報ディレクトリ管理論理１３０６は、送金者秘密識別子及び受取人秘密識別子を情報ディレクトリ１２８０から収集し得る。本明細書で考察されるように、送金者秘密識別子は、以前に送金者ＦＩシステム１２１０により生成され、支払いサービスシステム１２１８に提供されていることがある。同様に、受取人秘密識別子も受取人ＦＩシステム１２１２により以前に生成されていることがある。

動作１５１６において、支払いサービスシステム１２１８は、公衆ネットワーク１２１４（又は任意のネットワーク）を介して支払い通知を送金者ＦＩシステム１２１０に提供し得る。支払い通知は、送金要求が情報ディレクトリ１２８０に問題なく追加されたことを送金者ＦＩシステム１２１０に通知し得る。支払い通知は、送金要求額、送金者の秘密識別子、及び受取人の秘密識別子を含め、取引データの少なくとも幾つかを含み得る。支払い通知は、受取人ＦＩシステム１２１２への送金を支援する、送金者ＦＩシステム１２１０への命令又は情報を含み得る。支払い通知論理１３０８は動作１５１６を実行し得る。

動作１５１８において、送金者ＦＩシステム１２１０は、送金者の秘密識別子に関連付けられた１つ又は複数の口座（例えば、ＤＤＡ）を取得し得る。様々な実施形態では、送金者ＦＩシステム１２１０は、送金者の秘密識別子を使用して情報ディレクトリ１２６０においてＤＤＡを取得し得る。送金者ＦＩシステム１２１０は、送金者システム１２０６に関連する任意の数の口座及び／又は他の情報を識別し得る。

動作１５２０において、送金者ＦＩシステム１２１０は、送金者口座が送金の実行に十分な資金を有するか否かを特定し得る。動作１５２２において、送金者ＦＩシステム１２１０は、送金者口座が十分な資金を有するか否か、取引データが詐欺／疑いがある可能性が高いか否か、又は規制準拠に基づき得る任意の他のチェック等の内部チェックを実行し得る。

動作１５２４において、送金者ＦＩシステム１２１０は、支払いサービスシステム１２１８に、送金用の資金が承認されたか否か及び／又は実施されるか否かに関連する任意の関連ステータスを更新する命令を提供し得る。随時、支払いサービスシステム１２１８は、取引を識別する取引識別子を生成し得る。取引識別子は、支払いサービスシステム１２１８により、送金者ＦＩシステム１２１０及び受取人ＦＩシステム１２０４と共有し得る。支払いサービスシステム１２１８は、第１の非ＦＩシステム１２０６に、送金用の資金を送金すべきか否かを含め、更新されたステータスの第１の通知を提供し得る。

動作１５２６において、支払いサービスシステム１２１８は、送金者システム１２０２（又は第１の非ＦＩシステム１２０６）に、送金されるか否かを含め、更新されたステータスの第２の通知を提供し得る。様々な実施形態では、支払いステータス管理論理１３１０は、動作１５２４及び１５２６を実行し得る。

動作１５２８において、送金者ＦＩシステム１２１０は、ＡＣＨネットワーク１２１６を使用して、２つの金融機関間での送金を決済するバッチ送金を受取人ＦＩシステム１２１２に提供し得る。様々な実施形態では、支払いを決済する要求は、取引識別子（例えば、取引を識別し、送金額、送金者ＦＩシステム１２１０の識別子、及び任意の他の情報にリンクし得る）及び／又は送金額を指定するＡＣＨメッセージを含むか、又はＡＣＨメッセージを関連付け得る。幾つかの実施形態では、バッチ送金は、送金者秘密識別子、送金者公開識別子、受取人秘密識別子、受取人公開識別子、送金者ＦＩシステム１２１０のＦＩ識別子、及び／又は任意の他の情報を付随し得る。代替的に、送金者秘密識別子、送金者公開識別子、受取人秘密識別子、受取人公開識別子、送金者ＦＩシステム１２１０のＦＩ識別子、及び／又は任意の他の情報は、後に提供し得る。幾つかの実施形態では、支払いステータス管理論理１３１０は、動作１５２８を実行し得る。

動作１５３０において、受取人ＦＩシステム１２１２は、取引識別子を識別し、例えば、受取人及び送金額を含む、送金に関連する情報を取得し得る。例えば、受取人ＦＩシステム１２１２は、取引識別子を使用して受取人を識別し、受取人に関連付けられた１つ又は複数の口座（例えば、ＤＤＡ）を取得し得る。

動作１５３２において、受取人ＦＩシステム１２１２は、受取人の受取人口座に送金額の資金を入金し得る。例えば、資金は、ＡＣＨ転送で受け取った金額から受取人ＦＩシステム１２１２により受取人のＤＤＡに入金し得る。

動作１５３４において、受取人ＦＩシステム１２１２は、第２の非ＦＩシステム１２０８及び／又は受取人システム１２０４に、資金が受取人口座に送金されたことを示す、更新されたステータスを提供し得る。

動作１５３６において、受取人ＦＩシステム１２１２は、支払いサービスシステム１２１８に、受取人口座に送金されたことを示す、更新されたステータスを提供し得る。動作１５３８において、支払いサービスシステム１２１８は、第１の非ＦＩシステム１２０６又は送金者システム１２０２に、受取人口座に送金されたことを示す、更新されたステータスを提供し得る。

図１６Ａ及び図１６Ｂは、幾つかの実施形態による、送金システムにおいて送金者から受取人にセキュアに送金する方法１６００Ａ及び１６００Ｂのフローチャートの図を示す。方法１６００Ａ及び１６００Ｂのフローチャートは、図１５のものと同様の動作を含み得る。方法１６００Ａ及び１６００Ｂは、図１２〜図１４に示されるシステム及びシステム構成要素の１つ又は複数により実行し得る。なお、方法１６００Ａ及び１６００Ｂは、明示的に示される動作よりも多数又は少数の動作を含むこともできる。

動作１６０２において、取引データ管理論理１３０２は、公衆ネットワーク１２１４を介して第１の非ＦＩシステム１２０６から取引データを受信し得る。取引データは、送金者と受取人との間（例えば、送金者システム１２０２と第２の非ＦＩシステム１２０８又は受取人システム１２０４との間）での送金額を指定し得る。幾つかの実施形態では、取引データは、送金の送金者を識別する送金者公開識別子を含み得る。送金者公開識別子は、送金者を一意に識別するが、外部発見から保護するために、送金者の金融情報を含まない、電子メールアドレス、ユーザの名前、電話番号、英数字列等の送金者と連絡をとるのに使用し得る情報を含み得る。取引データは、送金の受取人を識別する受取人公開識別子を含み得る。受取人公開識別子も同様に、電子メールアドレス、ユーザの名前、電話番号、英数字列等を含み得る。受取人公開識別子はまた、受取人を一意に識別し得るが、受取人の金融情報を外部発見から保護する。

動作１６０４において、支払いサービスシステム１２１８の取引データ管理論理１３０２は、送金者及び受取人が、それぞれ送金者公開識別子及び受取人公開識別子を使用して送金を実行するのに登録していると特定し得る。様々な実施形態では、取引データ管理論理１３０２は、送金者及び受取人が情報ディレクトリ１２８０に登録していると特定し得る。取引データ管理論理１３０２は、例えば、送金者及び／又は受取人の公開及び／又は秘密識別子が、情報ディレクトリ１２８０に登録していると特定し得る。

動作１６０６において、取引データ管理論理１３０２は、送金者公開識別子を使用して、送金者金融口座を有する送金者金融機関の識別子及び送金者秘密識別子を収集し得る。動作１６０８において、取引データ管理論理１３０２は、受取人公開識別子を使用して、受取人金融口座を有する受取人金融機関の識別子及び受取人秘密識別子を収集し得る。取引データ管理論理１３０２は、取引データ内に組み込まれた名前、識別子等を使用して送金者金融機関及び受取人金融機関を識別して、送金者金融機関及び／又は受取人金融機関を取得し得る。

動作１６１０において、支払い通知論理１３０８は、取引データ及び取得された情報の少なくともいくらかを送金者金融機関に送信して送金を実行し得る。様々な実施形態では、送金者秘密識別子、受取人公開識別子、受取人ＦＩシステム１２１２、及び送金額は、支払い通知論理１３０８により送金者ＦＩシステム１２１０に送信し得る。取引データの部分は、送金の送金者、送金の受取人、及び送金額の識別に十分なデータを含み得る。

動作１６１２において、送金者ＦＩシステム１２１０は、送金者秘密識別子を使用して送金者口座を取得し得る。幾つかの実施形態では、送金者ＦＩシステム１２１０は、送金者秘密識別子を使用して情報ディレクトリ１２６０を照会することにより、送金者口座を識別し得る。その結果としての応答は、送金者口座を取得するベースをなし得る。本明細書で考察されるように、登録中、送金者秘密識別子は、登録中、送金者ＦＩシステム１２１０により生成され、送金者に、送金者ＦＩシステム１２１０により維持又は管理される送金者の口座の１つ又は複数の口座番号をリンクするのに使用し得る。送金者秘密識別子は、口座番号又は暗号化口座番号ではないこともある。例えば、送金者秘密識別子は送金者システム１２０２、受取人システム１２０４、又は第１の非ＦＩシステム１２０６に提供されないが、送金者秘密識別子は、リバースエンジニアリング可能ではない（例えば、送金者の秘密識別子から口座番号を得ることはできない）。送金者秘密識別子は、他の口座情報との関連により、送金者ＦＩシステム１２１０が使用可能な唯一の識別子ではない。動作１６１４において、送金者ＦＩシステム１２１０は、送金者金融口座が送金の実行に十分な資金を有するか否かを評価し得る。幾つかの実施形態では、送金者ＦＩシステム１２１０は、送金者が口座アクセス、十分な資金、及び公開識別子を使用して送金を実行するために必要な他の情報を有することを保証する１つ又は複数の命令を送金者ＦＩシステム１２１０に送信し得る。

動作１６１６において、送金者ＦＩシステム１２１０は、取引データに基づいて、送金が詐欺である可能性が高いか否かを評価し得る。幾つかの実施形態では、支払い検証論理１３０４は、送金者の送金状況から、送金者が、送金者が主張する人物ではないように見えると特定し得る。送金者ＦＩシステム１２１０は、送金者のインターネットプロトコル（ＩＰ）アドレス等が有効であるか否か及び／又は送金者が許可されたシステム又は送金者が以前使用したシステムから送金しようとしたか否か、短期間に送金を繰り返したか否か等を評価し得る。送金が承認される場合、送金者ＦＩシステム１２１０は、送金を実行可能であることの通知を提供し得る。動作１６１８において、支払いサービスシステム１２１８は、送金者ＦＩシステム１２１０が送金を実行可能であることの通知を受信し得る。

幾つかの実施形態では、支払いサービスシステム１２１８は、送金に関連付けられた取引識別子を生成し、取引識別子を送金者ＦＩシステム１２１０及び受取人ＦＩシステム１２１２に提供し得る。取引識別子は、ＡＣＨバッチ送金において、送金者ＦＩシステム１２１０と受取人ＦＩシステム１２１２との間で使用し得る。

動作１６２０において、支払い通知論理１３０８は、送金者システム１２０２及び第１の非ＦＩシステム１２０６の一方又は両方に、送金が行われることを示す送金ステータスを提供し得る。

動作１６２２において、送金者ＦＩシステム１２１０又は支払いサービスシステム１２１８は、受取人ＦＩシステム１２１２に、取引識別子、受取人秘密識別子、取引額、送金者金融機関の識別子、及び／又は送金者秘密識別子を識別する取引データを受取人金融機関に提供し得る。様々な実施形態では、秘密識別子は、公衆ネットワーク１２１４（又は他のネットワーク）を介して口座情報を送信する必要がないように提供される。

動作１６２４において、送金者ＦＩシステム１２１０は、ＡＣＨシステム１２２０及び／又はＡＣＨネットワーク１２１６を通して、バッチ送金プロセスの一環として資金（送金用の資金を含む）を受取人ＦＩシステム１２１２に提供し得る。動作１６２８において、支払いステータス管理論理１３１０は、受取人金融機関の受取人金融口座への送金資金の入金の通知を受信し得る。

図１７は、幾つかの実施形態による、送金システムにおいて送金者から受取人にセキュアに送金するデータフロー１７００の図を示す。データフロー１７００は、例えば、送金者等のある参加者が過去に支払いサービスシステム１２０８に登録していない場合のデータフローであり得る。データフロー１７００は、図１２に示され、本明細書で更に考察する送金システム１２００の構成要素を含む。より詳細には、データフロー１７００は、送金者システム１２０２、第１の非ＦＩシステム１２０６、第２の非ＦＩシステム１２０８、送金者ＦＩシステム１２１０、支払いサービスシステム１２１８、及び受取人ＦＩシステム１２１２の１つ又は複数の動作を含む。なお、データフロー１７００の要素は、単なる例であり、様々な実施形態は、本明細書に記載される本発明の概念の範囲及び趣旨から逸脱せずに、より多数の要素又はより少数の要素を利用することもできる。

動作１７０２において、送金者システム１２０２は、送金に関連する取引データを受信し得る。取引データは、送金額を指定し得る。取引データは、送金者（例えば、送金者システム１２０２に関連付けられる参加者）の公開識別子及び受取人の公開識別子を指定し得る。本明細書に更に記載されるように、更に本明細書に記載されるように、送金者及び受取人の公開識別子は、口座情報を金融機関外部に提供する必要なく、受取人への送金のルーティングを促進すると共に、送金者金融口座と受取人金融口座との調停を促進し得る。受取人システム１２０４が送金に関連する取引データを受信することもできることが理解される。

動作１７０４において、送金者システム１２０２（及び受取人システム１２０４）は、公衆ネットワーク１２１４を介して、取引データを第１の非ＦＩシステム１２０６に提供し得る。様々な実施形態では、送金者システム１２０２は、物理的購入端末又は第１の非ＦＩシステム１２０６によりサポートされる支払いプロセスにより調達されるアプリケーション、若しくはウェブサイト等に提供し得る。同様に、受取人システム１２０４も、取引詳細を第２の非ＦＩシステム１２０８又は第１の非ＦＩシステム１２０６に提供し得る。幾つかの実施形態では、第１の非ＦＩシステム１２０６及び第２の非ＦＩシステム１２０８は、同じエンティティにより所有される。幾つかの実施形態では、送金者システム１２０２は、送金者の第１の金融商品又は送金者のトークン化金融商品（送金者トークンを生成するために）を第１のＦＩシステム１２０６に提供し、受取人システム１２０４は、受取人の第２の金融商品又は受取人のトークン化金融商品（受取人トークンを生成するために）を第１の非ＦＩシステム１２０６又は第２の非ＦＩシステム１２０８に提供する。

動作１７０２及び１７０４が任意選択的であり得ることが理解される。例えば、本明細書で考察されるように、非ＦＩシステム１２０６は、送金者システム１２０２なしで、送金者から送金情報（例えば、送金者公開識別子、クレジット又はデビットカード番号、送金元口座等）を受信するように構成される物理的デバイスを含み得る。

第１及び第２の非ＦＩシステムが必要ないことがあることが理解される。例えば、送金者システム１２０２及び受取人システム１２０４は、それぞれ取引情報（例えば、送金資金、受取人及び送金者からトークンを作成するためのトークン化金融商品、並びに送金者及び受取人の公開識別子）を共有するように構成されるスマートフォンであり得る。取引情報は、支払いサービスシステム１２１８に提供し得る。

動作１７０６において、第１の非ＦＩシステム１２０６は、取引データを支払いサービスシステム１２１８にルーティングし得る。動作１７０８において、第１の非ＦＩシステム１２０６は、公衆ネットワーク１２１４（又は任意のネットワーク）を介して取引データを支払いサービスシステム１２１８に提供し得る。取引データは、送金者公開識別子、受取人公開識別子、送金額、受取人トークン、及び送金者トークンを含み得る。幾つかの実施形態では、第１の非ＦＩシステム１２０６は、任意の数の金融商品に関連付けられた口座番号を受信し得る。第１の非ＦＩシステム１２０６は、金融商品の口座番号をトークン化するか、又は金融商品に関連付けられた金融サービス提供者に口座番号を提供して、口座番号をトークン化し得る。続けて、第１の非ＦＩシステム１２０６又は金融商品に関連付けられた金融サービス提供者は、口座番号のトークンを支払いサービスシステム１２１８に提供する。

動作１７１０において、支払いサービスシステム１２１８は、送金者が、送金者の公開識別子を使用して支払いサービスシステム１２１８に登録しているか否かを確認し得る。送金者が既に登録している場合、送金者は再登録する必要はない。送金者が認識されない場合、支払いサービスシステム１２１８は、送金者を識別するために、送金者、送金者システム１２０２、又は第１の非ＦＩシステム１２０６から追加の情報を要求し得る。

同様に、支払いサービスシステム１２１８は、受取人が、受取人の公開識別子を使用して支払いサービスシステム１２１８に登録しているか否かを確認し得る。受取人が既に登録している場合、受取人は再登録する必要はない。受取人が認識されない場合、支払いサービスシステム１２１８は、送金者を識別するために、受取人、受取人システム１２０４、第１の非ＦＩシステム１２０６、又は第２の非ＦＩシステム１２０８から追加の情報を要求し得る。

幾つかの実施形態では、第１の非ＦＩシステム１２０６又は送金者の金融商品に関連付けられたエンティティは、送金者の金融商品及び／又は受取人の金融商品をトークン化し得る（送金者トークン及び／又は受取人トークンを生成するために）。第１の非ＦＩシステム１２０６はまた、送金者の金融商品に関連付けられたＦＩ識別子（例えば、金融商品を発行した銀行）及び受取人の金融商品に関連付けられたＦＩ識別子を支払いサービスシステム１２１８に送信することもできる。支払いサービスシステム１２１８が、送金者の登録を特定する（例えば、送金者登録要求時に）場合、支払いサービスシステム１２１８は、ＦＩ識別子を用いて送金者ＦＩシステム１２１０を識別し、送金者のトークン及び送金者公開識別子を送金者ＦＩシステム１２１０に提供し得る。

動作１７１２において、支払いサービスシステム１２１８は、取引データを情報ディレクトリ１２８０に追加して取引を一時的にログ記録し得る。非ＦＩシステム１２１０が、例えば、送金者公開識別子、送金する資金、受取人公開識別子、金融商品に関連付けられた金融識別子、金融商品のトークン化口座番号（例えば、送金者のトークン及び／又は受取人のトークン）、又は任意の組み合わせを含め、送金に関連する情報をログ記録又は記憶し得ることが理解される。

動作１７１４において、支払いサービスシステム１２１８は、公衆ネットワーク１２１４（又は任意のネットワーク）を介して送金者ＦＩシステム１２１０に、送金者公開識別子、受取人公開識別子、送金者のトークン、送金する資金、又は任意の他の情報を含む通知を提供し得る。支払いサービスシステム１２１８は、公衆ネットワーク１２１４（又は任意のネットワーク）を介して受取人ＦＩシステム１２１２に、送金者公開識別子、受取人公開識別子、受取人のトークン、送金する資金、又は任意の他の情報を含む通知を提供することもできる。

動作１７１６において、送金者ＦＩシステム１２１０は、送金者のトークンをトークン化解除して、金融商品番号（例えば、クレジット又はデビットカード番号）を識別し得る。動作１７１８において、送金者ＦＩシステム１２１０は、１つ又は複数のトークン化解除番号を取得して、送金者及び送金者に関連付けられた任意の数の口座（例えば、ＤＤＡ）を識別し得る。様々な実施形態では、送金者ＦＩシステム１２１０は、送金者の公開識別子を使用して口座を更に確認し得る。送金者ＦＩシステム１２１０は、例えば、送金者システム１２０６に関連する口座及び／又は他の情報を識別し得る。送金者及び送金者ＦＩシステム１２１０の送金者の口座が識別される場合、動作１７２０において、送金者ＦＩシステム１２１０は、送金者秘密識別子を生成し、秘密識別を支払いサービスシステム１２１８と共有し得、支払いサービスシステム１２１８は、次に情報を情報ディレクトリに記憶し得る。

動作１７２２において、送金者ＦＩシステム１２１０は、送金者口座が送金の実行に十分な資金を有するか否かを特定し得る。送金者ＦＩシステム１２１０は、取引データが詐欺／疑いがある可能性が高いか否か等に関連するチェック等の内部チェックを実行することもできる。動作１７２４において、送金者ＦＩシステム１２１０は、取引のステータスを更新する命令を支払いサービスシステム１２１８に提供し得る。

動作１７２６において、支払いサービスシステム１２１８は、第１の非ＦＩシステム１２０６に、送金用の資金を送金し得るか否かを含め、更新されたステータスの第１の通知を提供し得る。動作１７２８において、支払いサービスシステム１２１８は、第１の非ＦＩシステム１２０６又は送金者システム１２０２に、送金用の資金を送金し得るか否かを含め、更新されたステータスの第２の通知を提供し得る。様々な実施形態では、支払いステータス管理論理１３１０は動作１７２６及び１７２８を実行し得る。

随時、支払いサービスシステム１２１８は、取引に関連付けられた取引識別子を生成し得る。一例では、支払いサービスシステム１２１８は、送金者秘密識別子が送金者ＦＩシステム１２１０から受信され、受取人秘密識別子が受取人ＦＩシステム１２１２から受信されると、取引識別子を生成し得る。支払いサービスシステム１２１８は、取引識別子及び任意の他の情報を受取人ＦＩシステム１２１２及び送金者ＦＩシステム１２１０に提供し得る。

動作１７３０において、受取人ＦＩシステム１２１２は、受取人トークンをトークン化解除し得る。動作１７３４において、受取人ＦＩシステム１２１２は、受取人の公開識別子に関連付けられた１つ又は複数のＤＤＡを取得し得る。受取人ＦＩシステム１２１２は、受取人の公開識別子を使用して、情報ディレクトリ１２７０内の送金者システム１２０２に関連付けられたＤＤＡを取得し得る。

動作１７３４において、送金者ＦＩシステム１２１０は、受取人ＦＩシステム１２１２に、バッチ支払いを提供して、ＡＣＨネットワーク１２１６を介して送金の支払いを決済し得る。様々な実施形態では、支払いを決済する要求は、ＡＣＨネットワーク１２１６を介した両方の転送を含み得、取引識別子及び送金額を伴い得る。

動作１７３６において、受取人ＦＩシステム１２１２は、取引識別子を使用してＡＣＨバッチ処理から資金を識別し、送金額の資金を受取人の受取人口座に入金し得る。資金は、受取人ＦＩシステム１２１２により受取人のＤＤＡに入金し得る。動作１７３８において、受取人ＦＩシステム１２１２は、資金が受取人口座に送金されたことを示すように、受取人口座のステータスを更新し得る。動作１７４０において、受取人ＦＩシステム１２１２は、受取人非ＦＩシステム１２０８及び／又は受取人システム１２０４に、資金が受取人口座に送金されたことを示す、更新されたステータスを提供し得る。

動作１７４２において、受取人ＦＩシステム１２１２は、支払いサービスシステム１２１８に、資金が受取人口座に送金されたことを示す更新されたステータスを提供し得る。動作１７４４において、支払いサービスシステム１２１８は、第１の非ＦＩシステム１２０６に、資金が受取人口座に送金されたことを示す、更新されたステータスを提供し得る。動作１７４６において、第１の非ＦＩシステム１２０６は、送金者システム１２０２に、資金が受取人口座に送金されたことを示す、更新されたステータスを提供し得る。動作１７４８において、送金者ＦＩシステム１２１０及び受取人ＦＩシステム１２１２は、ＡＣＨシステム１２２０及び／又はＡＣＨネットワーク１２１６を介して送金額を決済し得る。動作１７４８は、２つの組織間のバッチ送金プロセスの一環として行い得る。

幾つかの実施形態では、受取人ＦＩシステム１２１２は、資金がＡＣＨネットワークを通して送金者ＦＩシステム１２１０から受け取られる前に資金を受取人の口座に配置し得る。次に、バッチ支払いを受け取ったとき、受取人ＦＩシステム１２１２に払い戻し得る。

図１８Ａ及び図１８Ｂは、幾つかの実施形態による、送金システムにおいて送金者から受取人にセキュアに送金する方法１８００Ａ及び１８００Ｂのフローチャートの図を示す。１８００Ａ又は１８００Ｂのフローチャートは、図１７で考察したフローと同様であり得る。方法１８００Ａ及び１８００Ｂは、図１２〜図１４に示されるシステム又はシステム構成要素の１つ又は複数により実行し得る。なお、方法１８００Ａ及び１８００Ｂは、明示的に示されるよりも多数又は少数の動作を含むこともできる。

動作１８０２において、支払いサービスシステム１２１８の取引データ管理論理１３０２は、公衆ネットワーク１２１４を介して第１の非ＦＩシステム１２０６から取引データを受信し得る。取引データは、送金者と受取人との間（例えば、送金者システム１２０２と第２の非ＦＩシステム１２０８又は受取人システム１２０４との間）での送金額、送金の送金者を識別する送金者公開識別子、送金の受取人を識別する受取人公開識別子、送金者のトークン化金融商品の送金者トークン、受取人のトークン化金融商品の受取人トークン、送金者の金融商品に関連付けられた送金者ＦＩ識別子（例えば、送金者の金融商品の発行銀行）、及び／又は受取人の金融商品に関連付けられた受取人のＦＩ識別子を指定し得る。取引データが任意の数のソースから受信可能であることが理解される。例えば、取引データ管理論理１３０２は、第１の非ＦＩシステム１２０６から取引データのいくらかを受信し、任意の数のエンティティから送金者のトークン化金融商品の送金者トークン、受取人のトークン化金融商品の受取人トークン、又は両方を受信し得る。

動作１８０４において、取引データ管理論理１３０２は、送金者及び受取人が、送金者公開識別子及び受取人公開識別子をそれぞれ使用して送金を実行するのに登録していないと特定し得る。様々な実施形態では、取引データ管理論理１３０２は、送金者及び受取人が非金融機関を通して登録していると特定し得る。様々な実施形態では、送金者、受取人、又は両方が登録していない。

動作１８０６において、取引データ管理論理１３０２は、動作１８０４において受信される取引データからの金融機関識別子を使用して送金者ＦＩシステム１２１０又は受取人ＦＩシステム１２１２を識別し得る。

動作１８０８において、支払い通知論理１３０８は、取引データの少なくともいくらかを送金者金融機関に送信して送金を行い得る。様々な実施形態では、送金者公開識別子、受取人公開識別子、送金額、受取人ＦＩ識別子、及び／又は送金者のトークンは、支払い通知論理１３０８により送金者ＦＩシステム１２１０に送信し得る。取引データの部分は、送金の送金者、送金の受取人、及び送金額の識別に十分なデータを含み得る。

動作１８１０において、支払い通知論理１３０８は、取引データの少なくともいくらかを受取人金融機関に送信して送金を行い得る。様々な実施形態では、受取人公開識別子、送金者公開識別子、送金額、送金者ＦＩ識別子、及び／又は受取人のトークンは、支払い通知論理１３０８により受取人ＦＩシステム１２１２に送信し得る。取引データの部分は、送金の送金者、送金の受取人、及び送金額の識別に十分なデータを含み得る。

動作１８１２において、送金者ＦＩシステム１２１０は、送金者秘密識別子をトークン化解除し得る。動作１８１４において、送金者ＦＩシステム１２１０は、トークン化解除された送金者秘密識別子からの情報を使用して（例えば、送金者のクレジットカード番号又はデビットカード番号を使用して）送金者口座を取得し得る。

動作１８１６において、送金者ＦＩシステム１２１０は、送金者金融口座が送金の実行に十分な資金を有するか否かを評価し得る。幾つかの実施形態では、送金者ＦＩシステム１２１０は、送金者が口座アクセス、十分な資金、及び公開識別子を使用して送金を実行するのに必要な他の情報を有することを保証し得る。

動作１８１８において、送金者ＦＩシステム１２１０は、取引データに基づいて、送金が詐欺である可能性が高いか否かを評価し得る。送金者ＦＩシステム１２１０は、送金を実行可能であることの通知を提供し得る。動作１８２０において、支払いサービスシステム１２１８は、送金者ＦＩシステム１２１０が送金を実行可能であることの通知を受信し得る。

動作１８２２において、受取人ＦＩシステム１２１２は、受取人のトークンをトークン化解除し得る。動作１８２４において、受取人ＦＩシステム１２１２は、トークン化解除された受取人のトークンを使用して（例えば、受取人のクレジットカード番号又はデビットカード番号を使用して）、受取人ＦＩシステム１２１２の受取人の口座の１つ又は複数を識別し得る。成功した場合、受取人ＦＩシステム１２１２は、動作１８２６において、受取人の口座が特定されたことの通知を支払いサービスシステム１２１８に提供し得る。支払いサービスシステム１２１８は、送金の取引識別子及び一方又は両方の金融機関が送金を準備可能な状態であることの通知を受取人ＦＩシステム１２１２及び／又は送金者ＦＩシステム１２１０に提供し得る。

動作１８２８において、送金者ＦＩシステム１２１０は、ＡＣＨシステム１２２０及び／又はＡＣＨネットワーク１２１６を通して、取引識別子の指示を含むバッチ送金プロセスの一環として、送金の資金を受取人ＦＩシステム１２１２に提供し得る。動作１８３０において、支払いステータス管理論理１３１０は、受取人金融機関の受取人金融口座への送金の入金の通知を受信し得る。

図１９は、幾つかの実施形態による、送金システムに参加者を登録するデータフロー１９００の図を示す。データフロー１９００は、図１２に示され、本明細書で更に考察する送金システム１２００の構成要素を含む。データフローは、支払いサービスシステム１２１８及び参加者システム１９０２、参加者非ＦＩシステム１９０４、及び参加者ＦＩシステム１９０６を含み得る。幾つかの実施形態では、参加者システム１９０２は送金者システム１２０２に対応し、参加者非ＦＩシステム１９０４は第１の非ＦＩシステム１２０６に対応し、参加者ＦＩシステムは送金者ＦＩシステム１２１０に対応する。様々な実施形態では、参加者システム１９０２は受取人システム１２０４に対応し、参加者非ＦＩシステム１９０４は第２の非ＦＩシステム１２０８に対応し、参加者ＦＩシステム１９０６は受取人ＦＩシステム１２１２に対応する。データフロー１９００は、登録論理１２８６が送金システム１２００の構成要素に提供し得る命令に対応する複数の動作を更に含む。なお、データフロー１９００の要素は単なる例であり、様々な実施形態は、本明細書に記載される本発明の概念の範囲及び趣旨から逸脱せずに、より多数の要素又はより少数の要素を利用することもできる。

動作１９０８において、参加者ＦＩシステム１９０６は参加者口座を作成し得る。参加者口座は、金融機関の金融口座にリンクし得る。様々な実施形態では、参加者口座は、口座番号及び／又は参加者が口座の公開識別子を登録しようとするとき、口座の識別に使用することができる他の口座識別子を含み得る。参加者口座は、デビット／クレジットカード情報、銀行支店コード、口座番号等の金融データを含む金融機関の金融口座にリンクし得る。金融データは、金融サービスを参加者システム１９０２に提供する金融機関の識別子（名称、銀行支店コード等）を含み得る。動作１９１０において、参加者ＦＩシステム１９０６は、金融商品を作成し得る（例えば、デビット／クレジットカードをプリントし得、及び／又は参加者口座のオンライン口座を作成し得る）。

動作１９１２において、参加者ＦＩシステム１９０６は、金融商品を参加者（参加者システム１９０２のユーザ）、参加者システム１９０２、及び／又は支払いサービスシステム１２１８と共有し得る。参加者ＦＩシステム１９０６は、金融サービス提供者（例えば、ＭａｓｔｅｒＣａｒｄ）と併せて金融商品を共有し得る。幾つかの実施形態では、コードを参加者又は参加者システム１９０２に郵送及び／又は電子的に送信し得、それにより、参加者は、参加者口座のユーザ識別子を登録し得る。

幾つかの実施形態では、参加者システム１９０２は参加者非ＦＩシステム１９０４と対話し得る。他の実施形態では、参加者は参加者非ＦＩシステム１９０４と対話し得る（例えば、クレジットカード及び参加者非ＦＩの物理的デバイスを使用して）。動作１９１４〜１９２０は、本明細書において、参加者システム１９０２の使用から説明されるが、他の実施形態が動作の全て又はいずれかを必要としないことが理解される。

動作１９１４において、参加者システム１９０２は、金融商品を使用して参加者口座を登録する要求を参加者から受信し得る。動作１９１６において、参加者システム１９０２は、１つ又は複数の参加者登録画面を参加者に提供し得る。動作１９１８において、参加者システム１９０２は、参加者の公開識別子を受信し得る。幾つかの実施形態では、公開識別子及び口座情報は、参加者システム１９０２の入力デバイスに提供し得る。公開識別子は、参加者を識別することができる英数字又は他のストリングを含み得る。参加者システム１９０２は、公開識別子の検証を可能にするパスワード、生体認証技法、他の認証技法等を受信し得る。

動作１９２０において、参加者システム１９０２は、公開識別子又は参加者口座情報を参加者非ＦＩシステム１９０４に送信し得る。幾つかの実施形態では、参加者システム１９０２又は参加者（例えば、ユーザ）は、金融商品（例えば、金融商品に関連する口座番号、銀行支店コード等）を参加者非ＦＩシステム１９０４に提供し得、又は金融商品をトークン化して、金融商品のトークンを生成し、トークンを特定の非ＦＩシステム１９０４若しくは金融サービス提供者に提供し得る。参加者システム１９０２は、金融商品を発行したＦＩ識別子を参加者非ＦＩシステム１９０４に送信することもできる。

動作１９２２において、参加者非ＦＩシステム１９０４又は口座データに関連付けられた金融サービス提供者は、参加者口座情報を表すトークン化口座データを識別し得る。トークン化口座データは、参加者口座情報を暗号化したものを含み得る。幾つかの実施形態では、トークン化口座データは、参加者口座情報内のデビット／クレジット等のカード番号を表すプロキシ番号を含み得る。動作１９２６において、参加者非ＦＩシステム１９０４（又は金融サービス提供者）は、参加者口座情報を表すトークン化口座データを識別し得る。

動作１９２４において、参加者非ＦＩシステム１９０４及び／又は金融サービス提供者は、公開識別子又はトークン化口座データを支払いサービスシステム１２１８に送信し得る。動作１９２６において、参加者非ＦＩシステム１９０４は任意選択的に、公開識別子及び／又はトークン化口座データを参加者ＦＩシステム１９０６に送信し得る。幾つかの実施形態では、参加者非ＦＩシステム１９０４は、情報を参加者ＦＩシステム１９０６、支払いサービスシステム１２１８、又は両方に提供し得る。

動作１９２８において、参加者ＦＩシステム１９０６は任意選択的に、公開識別子及び／又はトークン化口座データを支払いサービスシステム１２１８に送信し得る。一例では、情報は、参加者非ＦＩシステム１９０４により、参加者ＦＩシステム１９０６と共有され、したがって、参加者ＦＩシステム１９０６は、任意選択的に、情報の全て又はいくらかを支払いサービスシステム１２１８と共有する。

動作１９３０において、支払いサービスシステム１２１８は、公開識別子が使用されていないことを検証し得る。公開識別子の検証は、情報ディレクトリをレビューして、別のユーザが既に、別の口座に関連してその公開識別子を登録しているか否かを特定することを含み得る。幾つかの実施形態では、支払いサービスシステム１２１８は、公開識別子が既に使用中である場合、失敗メッセージを返し得る。ユーザ識別検証論理１４０４は動作１９３０を実行し得る。

動作１９３２において、支払いサービスシステム１２１８は、参加者システム１９０２及び／又は参加者非ＦＩシステム１９０４からのトークン化口座データ又は金融機関識別子を使用して参加者金融機関を識別し得る。幾つかの実施形態では、支払いサービスシステム１２１８は、金融機関に対応する名称、識別子等についてトークン化口座を評価し得る。様々な実施形態では、支払いサービスシステム１２１８は、トークン化口座データをトークン化解除して、情報を抽出し、参加者金融機関（例えば、参加者ＦＩシステム１９０６を管理する金融機関）を識別し得る。

動作１９３４において、支払いサービスシステム１２１８は、公開識別子及びトークン化口座データ（例えば、参加者のトークン）を参加者ＦＩシステム１９０６に送信し得る。口座確認論理１４１０は、動作１９３２及び１９３４を実行し得る。

動作１９３６において、参加者ＦＩシステム１９０６は、トークン化口座データをトークン化解除し得る。参加者ＦＩシステム１９０６は、任意のプロキシ番号等を復号化し、翻訳して、参加者口座の口座情報を取得し得る。動作１９３８において、参加者ＦＩシステム１９０６は、例えば、参加者の口座の口座情報を使用してＤＤＡルックアップを実行し得る。動作１９４０において、参加者ＦＩシステム１９０６は、ＤＤＡをユーザの公開識別子にマッピングし得る。参加者ＦＩシステム１９０６は、参加者のＦＩシステム１９０６での参加者の口座番号に関連付けられた秘密識別子を生成し得る。幾つかの実施形態では、参加者ＦＩシステム１９０６は、口座番号（例えば、ＤＤＡ）、公開識別子、及び秘密識別子を参加者ＦＩシステム１９０６に記憶された情報ディレクトリに書き込み得る。動作１９４２において、参加者ＦＩシステム１９０６は、公開識別子を将来の送金及び参加者が関わる他の取引に使用可能であることを反映するように、公開識別子ステータスを更新し得る。

動作１９４４において、参加者ＦＩシステム１９０６は、支払いサービスシステム１２１８に、公開識別子が将来の送金又は参加者が関わる他の取引に使用可能であることの確認を提供し得る。参加者ＦＩシステム１９０６は、参加者の秘密識別子を支払いサービスシステム１２１８と共有することもできる。

動作１９４６において、情報ディレクトリ管理論理１３０６は、参加者秘密識別子を参加者公開識別子に関連付け得る。動作１９４８において、支払いサービスシステム１２１８は、参加者非ＦＩシステム１９０４に、公開識別子が将来の送金及び参加者が関わる他の取引に使用可能であることの成功メッセージを提供し得る。口座確認論理１４１０は動作１９４８を実行し得る。

動作１９５０において、参加者非ＦＩシステム１９０４は、参加者の登録が成功したことを示す成功メッセージを示すように、参加者システム１９０２を提供し、構成し得る。動作１９５２において、参加者非ＦＩシステム１９０４は、参加者システム１９０２に、公開識別子が将来の送金又は参加者が関わる他の取引に使用可能であることの成功メッセージを提供し得る。動作１９５４において、成功メッセージは参加者システム１９０２に表示し得る。

図２０は、幾つかの実施形態による、送金システムに参加者を登録する方法２０００のフローチャートの図を示す。方法２０００は、図１２〜図１４に示される方法の１つ又は複数により実行し得る。なお、方法２０００は、明示的に示されるよりも多数又は少数の動作を含んでもよい。

動作２００２において、参加者口座発行論理１４０２は、参加者金融口座を作成する。参加者口座発行論理１４０２は、特定の送金者に対応する送金者金融口座又は特定の受取人に対応する受取人口座を作成し得る。参加者口座発行論理１４０２は、金融機関により維持／後援される金融口座に参加者口座をリンクし得る。幾つかの実施形態では、参加者口座は、担保、現金等にリンクし得る。参加者口座発行論理１４０２は、参加者口座についての情報を情報ディレクトリ１２８０に記憶し得る。

動作２００４において、ユーザ識別検証論理１４０４は、提案された公開識別子を参加者から受信する。提案された公開識別子は、電子メールアドレス、英数字ユーザ名、共通支払識別コード（ＵＰＩＣ）、電話番号、ユーザ生成又はシステム生成の番号又は文字列等を含むこともあれば、含まないこともある。提案された公開識別子は、参加者及び／又は参加者システムを識別するベースを提供し得る。

動作２００６において、ユーザ識別検証論理１４０４は、提案された公開識別子に任意の参加者が関連付けられているか否かを検証する。ユーザ識別検証論理１４０４は、提案された公開識別子が、電子メールアドレス、英数字ユーザ名、共通支払識別コード（ＵＰＩＣ）、電話番号、ユーザ生成又はシステム生成の番号又は文字列等を含むか否かを検証し得る。ユーザ識別検証論理１４０４は、提案された公開識別子が、別の参加者の識別に使用される公開識別子に対応するか否かを検証し得る。

動作２００８において、提案された公開識別子がいかなる参加者にも関連付けられていない場合、ユーザ識別検証論理１４０４は、提案された公開識別子を参加者公開識別子に登録する。本明細書で考察するように、参加者公開識別子及び任意の他の金融情報（例えば、トークン、金融商品番号等）は、参加者の金融機関と共有し得る。代替的に、参加者は、金融機関と対話し得（例えば、参加者の口座をログ記録し得）、金融機関は参加者の口座を確認し得る。金融機関は、参加者及び金融機関での参加者の口座番号に関連付けられた参加者秘密識別子を生成し、参加者秘密識別子を支払いサービスシステムに提供し得る。

ユーザ識別検証論理１４０４は、提案された公開識別子を秘密識別及び関連付けられた口座情報と共に情報ディレクトリ１２８０に記憶し得る。

図２１は、幾つかの実施形態によるデジタルデバイス２１００の例を示す。デジタルデバイス２１００は、プロセッサ２１０５、メモリシステム２１１０、記憶システム２１１５、通信ネットワークインターフェース２１２０、入／出力（Ｉ／Ｏ）インターフェース２１２５、ディスプレイインターフェース２１３０、及びバス２１３５を含む。バス２１３５は、プロセッサ２０１５、メモリシステム２１１０、記憶システム２１１５、通信ネットワークインターフェース２１２０、Ｉ／Ｏインターフェース２１２５、及びディスプレイインターフェース２１３０に通信可能に結合し得る。

幾つかの実施形態では、プロセッサ２１０５は、実行可能命令を処理可能な回路又は任意のプロセッサを含む。メモリシステム２１１０は、データを記憶するように構成される任意のメモリを含む。メモリシステム２１１０の幾つかの例は、ＲＡＭ又はＲＯＭ等の記憶装置である。メモリシステム２１１０はＲＡＭキャッシュを含み得る。様々な実施形態では、データはメモリシステム２１１０内に記憶される。メモリシステム２１１０内のデータは、クリアし得るか、最終的に記憶システム２１１５に転送し得る。

記憶システム２１１５は、データを取得し記憶するように構成される任意の記憶装置を含む。記憶システム２１１５の幾つかの例は、フラッシュドライブ、ハードドライブ、光学ドライブ、及び／又は磁気テープである。幾つかの実施形態では、デジタルデバイス２１００は、ＲＡＭの形態のメモリシステム２１１０及びフラッシュデータの形態の記憶システム２１１５を含む。メモリシステム２１１０及び記憶システム２１１５は両方とも、プロセッサ２１０５を含むコンピュータプロセッサにより実行可能な命令又はプログラムを記憶し得るコンピュータ可読媒体を含む。

通信ネットワークインターフェース（ｃｏｍネットワークインターフェース）２１２０は、データネットワークに結合し得る。通信ネットワークインターフェース２１２０は、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）接続、シリアル接続、並列接続、又はＡＴＡ接続を介して通信をサポートし得る。通信ネットワークインターフェース２１２０は、無線通信（例えば、８０２．１ ａ／ｂ／ｇ／ｎ、ＷｉＭＡＸ、ＬＴＥ、３Ｇ、２Ｇ）をサポートすることもできる。通信ネットワークインターフェース２１２０が多くの有線及び無線規格をサポートし得ることが当業者に理解される。

任意選択的な入／出力（Ｉ／Ｏ）インターフェース２１２５は、ユーザから入力を受信し、データを出力する任意のデバイスである。ディスプレイインターフェース２１３０は、グラフィックス及びデータをディスプレイに出力するように構成し得る任意のデバイスである。一例では、ディスプレイインターフェース２１３０はグラフィックスアダプタである。

デジタルデバイス２１００のハードウェア要素が、図２１に示されるものに限定されないことが当業者に理解される。デジタルデバイス２１００は、示されるよりも多数又は少数のハードウェア要素を含み得る。更に、ハードウェア要素は、機能を共有し得、それでもなお、本明細書に記載される様々な実施形態内であり得る。一例では、符号化及び／又は復号化は、プロセッサ２１０５及び／又はＧＰＵに配置されるコプロセッサにより実行し得る。

上述した機能又は構成要素は、コンピュータ可読媒体等の記憶媒体に記憶される命令で構成し得る。命令は、プロセッサにより取得し実行し得る。命令の幾つかの例は、ソフトウェア、プログラムコード、及びファームウェアである。記憶媒体の幾つかの例は、メモリデバイス、テープ、ディスク、集積回路、及びサーバである。命令は、プロセッサにより実行されると、プロセッサに幾つかの実施形態により動作するように指示する動作可能である。当業者は、命令、プロセッサ、及び記憶媒体に精通している。

説明を目的として、説明の詳細な理解を提供するために多くの特定の詳細が記載されている。しかし、これらの特定の詳細なしで本開示の実施形態が実施可能であることが当業者に明らかである。場合により、モジュール、構造、プロセス、特徴、及びデバイスは、説明を曖昧にしないように、ブロック図の形態で示されている。場合により、機能ブロック図又は流れ図がデータ又は論理フローを表すために示される。ブロック図又は流れ図の構成要素（例えば、モジュール、ブロック、構造、デバイス、特徴等）は、本明細書に明示的に説明され示されるもの以外の方法で様々に結合、分離、削除、順序替え、及び置換され得る。

本明細書での「一実施形態」、「実施形態」、「幾つかの実施形態」、「様々な実施形態」、「特定の実施形態」、「他の実施形態」、「一連の実施形態」等の言及は、実施形態に関連して説明される特定の特徴、設計、構造、又は特性が本開示の少なくとも１つの実施形態に含まれることを意味する。本明細書の様々な箇所での例えば「一実施形態において」又は「実施形態において」という語句の現れは、必ずしも全てが同じ実施形態を指すわけではなく、他の実施形態に相互に排他的な別個の又は代替の実施形態でもない。更に、「実施形態」等の明示的な言及があるか否かに関係なく様々な特徴が記載され、様々な特徴は、様々に結合し得、幾つかの実施形態に含まれ得るが、他の実施形態では様々に省くこともできる。同様に、幾つかの実施形態では好ましい又は必要であり得るが、他の実施形態ではそうではない様々な特徴が記載される。

本明細書で使用される言語は、主に読みやすさ及び教授を目的として選択されており、本発明の趣旨を描く又は限定するために選択されていない。したがって、範囲がこの詳細な説明により限定されず、むしろ、本明細書に基づく用途に由来する任意の請求項により限定されることが意図される。したがって、実施形態の開示は、範囲の限定ではなく例示であることが意図され、範囲は以下の特許請求の範囲に記載される。

Claims (20)

1. 送金に関連する取引データであって、前記送金の送金額、前記送金の送金者を識別する送金者公開識別子、前記送金の受取人を識別する受取人公開識別子、送金者金融機関の金融機関識別子、受取人金融機関の金融機関識別子、及び前記送金者のトークン化金融商品を指定する、取引データを、前記送金者金融機関、前記受取人金融機関および前記送金者のいずれとも異なる一以上の機関から、支払いサービスコンピュータシステムにおいて受信することと、
   前記支払いサービスコンピュータシステムにおいて、前記送金者金融機関の前記金融機関識別子を使用して、前記支払いサービスコンピュータシステムに関連付けられた支払いネットワークのメンバである前記送金者金融機関を特定することと、
   前記支払いサービスコンピュータシステムから前記送金者金融機関に前記送金者の前記トークン化金融商品を提供して、前記送金者金融機関が前記送金者の前記トークン化金融商品をトークン化解除し、且つ前記送金者に関連付けられた前記送金者金融機関の口座を識別することを可能にすることと、
   前記送金者金融機関が前記送金者に関連付けられた前記送金者金融機関の前記口座を確認した場合に前記送金者金融機関が生成する送金者秘密識別子を、前記送金者金融機関から前記支払いサービスコンピュータシステムにおいて受信することと、
   前記支払いサービスコンピュータシステムにおいて、前記送金者秘密識別子を前記送金者公開識別子に関連付けることと、
   前記支払いサービスコンピュータシステムから前記送金者金融機関に、前記送金の前記送金額、前記受取人公開識別子、及び前記受取人金融機関の前記金融機関識別子を提供して、前記送金者金融機関が、前記送金の前記送金額を満たす、前記送金者に関連付けられた前記送金者金融機関の前記口座内の金銭の利用可能性を特定することを可能にすることと、
   前記支払いサービスコンピュータシステムにおいて、前記受取人公開識別子に基づいて、受取人秘密識別子を特定することと、
   前記支払いサービスコンピュータシステムにおいて、前記送金に関連付けられた取引識別子を生成することと、
   前記取引識別子を、前記支払いサービスコンピュータシステムから前記送金者金融機関に送信することと、
   前記取引識別子及び前記受取人秘密識別子を前記支払いサービスコンピュータシステムから前記受取人金融機関に提供して、前記受取人金融機関が前記受取人に関連付けられた前記受取人金融機関の口座を識別することを可能にし、前記送金者金融機関によって生成され前記送金者金融機関から前記受取人金融機関への支払いを示すＡＣＨメッセージであって、前記送金者と前記受取人との間での前記送金を識別する前記取引識別子を含み、前記受取人金融機関がＡＣＨバッチ送金から資金を取得し、且つ前記受取人に関連付けられた前記受取人金融機関の前記口座に前記資金を入金することを可能にするＡＣＨメッセージを、前記受取人金融機関がＡＣＨネットワークを介して受信することを可能にすることと
   を含む方法。
2. 前記送金者が、前記送金者公開識別子を使用して前記送金を実行する許可を有することを検証することを更に含む、請求項１に記載の方法。
3. 前記支払いサービスコンピュータシステムにおいて、前記受取人のトークン化金融商品及び前記受取人金融機関の前記金融機関識別子を受信することと、
   前記支払いサービスコンピュータシステムにおいて、前記受取人金融機関の前記金融機関識別子を使用して、前記支払いサービスコンピュータシステムに関連付けられた前記支払いネットワークのメンバである前記受取人金融機関を特定することと、
   前記支払いサービスコンピュータシステムから前記受取人金融機関に、前記受取人の前記トークン化金融商品を提供して、前記受取人金融機関が前記受取人の前記トークン化金融商品をトークン化解除し、且つ前記受取人に関連付けられた前記受取人金融機関の前記口座を識別することを可能にすることと
   を更に含む、請求項１又は２に記載の方法。
4. 前記一以上の機関は第１のオンライン製品再販業者を含み、前記送金に関連する前記取引データは、前記第１のオンライン製品再販業者から受信される、請求項３に記載の方法。
5. 前記第１のオンライン製品再販業者は、前記送金者の金融商品をトークン化して、前記送金者の前記トークン化金融商品を作成する、請求項４に記載の方法。
6. 前記送金者の前記金融商品は、前記送金者金融機関によって発行される、請求項５に記載の方法。
7. 前記一以上の機関は前記第１のオンライン製品再販業者とは異なる第２のオンライン製品再販業者を含み、前記受取人の前記トークン化金融商品は、前記第２のオンライン製品再販業者から受信される、請求項４〜６のいずれか一項に記載の方法。
8. 前記第２のオンライン製品再販業者は、前記受取人の金融商品をトークン化して、前記受取人の前記トークン化金融商品を作成する、請求項７に記載の方法。
9. 前記受取人金融機関は、前記受取人金融機関が前記ＡＣＨメッセージを受信する前に、前記受取人に関連付けられた前記受取人金融機関の前記口座に前記資金を送金する、請求項１〜８のいずれか一項に記載の方法。
10. 前記受取人が前記送金者からの前記送金を受け入れるか否かを要求する通知要求を、前記支払いサービスコンピュータシステムから前記受取人に提供することを更に含む、請求項１〜９のいずれか一項に記載の方法。
11. １つ又は複数のプロセッサと、
    前記１つ又は複数のプロセッサに結合された非一時的コンピュータ可読媒体と
    を含み、
    前記非一時的コンピュータ可読媒体は、前記１つ又は複数のプロセッサで実行されるように構成された実行可能命令であって、
    送金に関連する取引データであって、前記送金の送金額、前記送金の送金者を識別する送金者公開識別子、前記送金の受取人を識別する受取人公開識別子、送金者金融機関の金融機関識別子、受取人金融機関の金融機関識別子、及び前記送金者のトークン化金融商品を指定する、取引データを、前記送金者金融機関、前記受取人金融機関および前記送金者のいずれとも異なる一以上の機関から、支払いサービスコンピュータシステムにおいて受信することと、
    前記支払いサービスコンピュータシステムにおいて、前記送金者金融機関の前記金融機関識別子を使用して、前記支払いサービスコンピュータシステムに関連付けられた支払いネットワークのメンバである前記送金者金融機関を特定することと、
    前記支払いサービスコンピュータシステムから前記送金者金融機関に前記送金者の前記トークン化金融商品を提供して、前記送金者金融機関が前記送金者の前記トークン化金融商品をトークン化解除し、且つ前記送金者に関連付けられた前記送金者金融機関の口座を識別することを可能にすることと、
    前記送金者金融機関が前記送金者に関連付けられた前記送金者金融機関の前記口座を確認した場合に前記送金者金融機関が生成する送金者秘密識別子を、前記送金者金融機関から前記支払いサービスコンピュータシステムにおいて受信することと、
    前記支払いサービスコンピュータシステムにおいて、前記送金者秘密識別子を前記送金者公開識別子に関連付けることと、
    前記支払いサービスコンピュータシステムから前記送金者金融機関に前記送金の前記送金額、前記受取人公開識別子、及び前記受取人金融機関の前記金融機関識別子を提供して、前記送金者金融機関が、前記送金の前記送金額を満たす、前記送金者に関連付けられた前記送金者金融機関の前記口座内の金銭の利用可能性を特定することを可能にすることと、
    前記支払いサービスコンピュータシステムにおいて、前記受取人公開識別子に基づいて、受取人秘密識別子を特定することと、
    前記支払いサービスコンピュータシステムにおいて、前記送金に関連付けられた取引識別子を生成することと、
    前記取引識別子を、前記支払いサービスコンピュータシステムから前記送金者金融機関に送信することと、
    前記取引識別子及び前記受取人秘密識別子を前記支払いサービスコンピュータシステムから前記受取人金融機関に提供して、前記受取人金融機関が前記受取人に関連付けられた前記受取人金融機関の口座を識別することを可能にし、前記送金者金融機関によって生成され前記送金者金融機関から前記受取人金融機関への支払いを示すＡＣＨメッセージであって、前記送金者と前記受取人との間での前記送金を識別する前記取引識別子を含み、前記受取人金融機関がＡＣＨバッチ送金から資金を取得し、且つ前記受取人に関連付けられた前記受取人金融機関の前記口座に前記資金を入金することを可能にするＡＣＨメッセージを、前記受取人金融機関がＡＣＨネットワークを介して受信することを可能にすることと
    を実行するように構成される実行可能命令を含む、システム。
12. 前記実行可能命令は、前記送金者が、前記送金者公開識別子を使用して前記送金を実行する許可を有することを検証することを実行するように更に構成される、請求項１１に記載のシステム。
13. 前記実行可能命令は、
    前記支払いサービスコンピュータシステムにおいて、前記受取人のトークン化金融商品及び前記受取人金融機関の前記金融機関識別子を受信することと、
    前記支払いサービスコンピュータシステムにおいて、前記受取人金融機関の前記金融機関識別子を使用して、前記支払いサービスコンピュータシステムに関連付けられた前記支払いネットワークのメンバである前記受取人金融機関を特定することと、
    前記支払いサービスコンピュータシステムから前記受取人金融機関に前記受取人の前記トークン化金融商品を提供して、前記受取人金融機関が前記受取人の前記トークン化金融商品をトークン化解除し、且つ前記受取人に関連付けられた前記受取人金融機関の前記口座を識別することを可能にすることと
    を実行するように更に構成される、請求項１１又は１２に記載のシステム。
14. 前記一以上の機関は第１のオンライン製品再販業者を含み、前記送金に関連する前記取引データは、前記第１のオンライン製品再販業者から受信される、請求項１３に記載のシステム。
15. 前記第１のオンライン製品再販業者は、前記送金者の金融商品をトークン化して、前記送金者の前記トークン化金融商品を作成する、請求項１４に記載のシステム。
16. 前記送金者の前記金融商品は、前記送金者金融機関によって発行される、請求項１５に記載のシステム。
17. 前記一以上の機関は前記第１のオンライン製品再販業者とは異なる第２のオンライン製品再販業者を含み、前記受取人の前記トークン化金融商品は、前記第２のオンライン製品再販業者から受信される、請求項１４〜１６のいずれか一項に記載のシステム。
18. 前記第２のオンライン製品再販業者は、前記受取人の金融商品をトークン化して、前記受取人の前記トークン化金融商品を作成する、請求項１７に記載のシステム。
19. 前記受取人金融機関は、前記受取人金融機関が前記ＡＣＨメッセージを受信する前に、前記受取人に関連付けられた前記受取人金融機関の前記口座に前記資金を送金する、請求項１１〜１８のいずれか一項に記載のシステム。
20. 実行可能命令を含む非一時的コンピュータ可読媒体であって、前記実行可能命令は、
    送金に関連する取引データであって、前記送金の送金額、前記送金の送金者を識別する送金者公開識別子、前記送金の受取人を識別する受取人公開識別子、送金者金融機関の金融機関識別子、受取人金融機関の金融機関識別子、及び前記送金者のトークン化金融商品を指定する、取引データを、前記送金者金融機関、前記受取人金融機関および前記送金者のいずれとも異なる一以上の機関から、支払いサービスコンピュータシステムにおいて受信することと、
    前記支払いサービスコンピュータシステムにおいて、前記送金者金融機関の前記金融機関識別子を使用して、前記支払いサービスコンピュータシステムに関連付けられた支払いネットワークのメンバである前記送金者金融機関を特定することと、
    前記支払いサービスコンピュータシステムから前記送金者金融機関に前記送金者の前記トークン化金融商品を提供して、前記送金者金融機関が前記送金者の前記トークン化金融商品をトークン化解除し、且つ前記送金者に関連付けられた前記送金者金融機関の口座を識別することを可能にすることと、
    前記送金者金融機関が前記送金者に関連付けられた前記送金者金融機関の前記口座を確認した場合に前記送金者金融機関が生成する送金者秘密識別子を、前記送金者金融機関から前記支払いサービスコンピュータシステムにおいて受信することと、
    前記支払いサービスコンピュータシステムにおいて、前記送金者秘密識別子を前記送金者公開識別子に関連付けることと、
    前記支払いサービスコンピュータシステムから前記送金者金融機関に前記送金の前記送金額、前記受取人公開識別子、及び前記受取人金融機関の前記金融機関識別子を提供して、前記送金者金融機関が、前記送金の前記送金額を満たす、前記送金者に関連付けられた前記送金者金融機関の前記口座内の金銭の利用可能性を特定することを可能にすることと、
    前記支払いサービスコンピュータシステムにおいて、前記受取人公開識別子に基づいて、受取人秘密識別子を特定することと、
    前記支払いサービスコンピュータシステムにおいて、前記送金に関連付けられた取引識別子を生成することと、
    前記取引識別子を、前記支払いサービスコンピュータシステムから前記送金者金融機関に送信することと、
    前記取引識別子及び前記受取人秘密識別子を前記支払いサービスコンピュータシステムから前記受取人金融機関に提供して、前記受取人金融機関が前記受取人に関連付けられた前記受取人金融機関の口座を識別することを可能にし、前記送金者金融機関によって生成され前記送金者金融機関から前記受取人金融機関への支払いを示すＡＣＨメッセージであって、前記送金者と前記受取人との間での前記送金を識別する前記取引識別子を含み、前記受取人金融機関がＡＣＨバッチ送金から資金を取得し、且つ前記受取人に関連付けられた前記受取人金融機関の前記口座に前記資金を入金することを可能にするＡＣＨメッセージを、前記受取人金融機関がＡＣＨネットワークを介して受信することを可能にすることと
    を実行するようにプロセッサによって実行可能である、非一時的コンピュータ可読媒体。

Images