JP6830062B2 - メッセージ・システムを使用する支払の送信および受信 - 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. 前記少なくとも１つのプロセッサによって実行される時に、前記システムに、
    前記第２のクライアント・デバイスから、前記受信者が前記支払を断る前記選択可能オプションを選択したことを示す標識を受信する工程と、
    前記受信者が前記支払を断る前記選択可能オプションを選択したことを示す前記標識の受信に応答して前記取引を取り消す工程と、
    をさらに行わせる、請求項１３に記載のシステム。