JP2016177839A - 支払いアプリケーションフレームワーク - Google Patents

Abstract

【課題】バリューの送り手の支払い承認フローを含む支払いアプリケーションを提供する。【解決手段】送り手から１つ以上の受け手への値の転送を示す支払い取引に関連付けられている支払いファシリテータで要求を受信し、要求に対応する支払いキーを生成し、支払いキーは前記送り手による前記要求の承認に使用され、送り手のクライアントマシンを、支払いキーをパラメータとして、支払いファシリテータの承認インターフェイスへと導き、送り手から承認インターフェイスを介して承認を受信したことに応答して、支払いファシリテータに支払い取引を完了させる。【選択図】図３Ａ

Description

（関連出願）
この出願は、２００９年９月９日に出願された“支払いアプリケーションフレームワーク”と題した米国出願第１２/２０７，３８３の利益を主張するものであり、該出願の内容は参照によりその全体が本明細書中に組み込まれる。

本出願は全般的に電子支払いの分野に関し、一つの特定の例示の実施形態では、支払いアプリケーション開発のためのフレームワークに関する。

電子支払いシステムは、異なる支払いプロバイダまたはファシリテータによるサービスの導入を伴いつつ過去数年にわたり発展してきた。これらの支払いファシリテータは、支払いアプリケーションを開発するために異なる独自のプログラミングインターフェイスを用いることがある。各アプリケーションは互いに独立に開発され得る。従来の電子支払いシステムの一例が特許文献１に記載されている。

特開２００４−４６３７７号公報

上述した従来のアプローチは、新しい特徴および要求がサービスに依存して個別に実装されなくてはならず、問題であり得る。このアプローチは、不必要な重複する努力という結果をもたらすこともあるし、新しい支払いアプリケーション／サービスを市場に投入する時間を遅らせることもある。

上記の課題を解決するために、本発明の方法は、支払いファシリテータで要求を受信することであって、前記要求は、送り手から１つ以上の受け手への値の転送を示す支払い取引に関連付けられている、ことと、前記支払いファシリテータで前記要求を処理することであって、前記処理することは、前記要求に対応する支払いキーを生成することを含み、前記支払いキーは前記送り手による前記要求の承認に使用される、ことと、前記送り手のクライアントマシンを、前記支払いキーをパラメータとして、前記支払いファシリテータの承認インターフェイスへと導くことと、前記送り手から前記承認インターフェイスを介して前記承認を受信したことに応答して、前記支払いファシリテータに前記支払い取引を完了させることと、を含むことを特徴とする。

また、本発明の機械読み取り可能な記憶デバイスは、機械の少なくとも１つのプロセッサによって実行された場合に前記機械に動作を実行させる命令を格納する機械読み取り可能な記憶デバイスであって、前記動作が、支払いファシリテータで要求を受信することであって、前記要求は、送り手から１つ以上の受け手への値の転送を示す支払い取引に関連付けられている、ことと、前記支払いファシリテータで前記要求を処理することであって、前記処理することは、前記要求に対応する支払いキーを生成することを含み、前記支払いキーは前記送り手による前記要求の承認に使用される、ことと、前記送り手のクライアントマシンを、前記支払いキーをパラメータとして、前記支払いファシリテータの承認インターフェイスへと導くことと、前記送り手から前記承認インターフェイスを介して前記承認を受信したことに応答して、前記支払いファシリテータに前記支払い取引を完了させることと、を含むことを特徴とする。

更に、本発明のシステムは、命令を格納する機械読み取り可能な記憶媒体と、前記機械読み取り可能な記憶媒体に格納された前記命令によって動作を実行するように構成された１つ以上のプロセッサと、を含むシステムであって、前記動作が、要求を受信することであって、前記要求は、送り手から１つ以上の受け手への値の転送を示す支払い取引に関連付けられている、ことと、前記要求を処理することであって、前記処理することは、前記要求に対応する支払いキーを生成することを含み、前記支払いキーは前記送り手による前記要求の承認に使用される、ことと、前記送り手のクライアントマシンを、前記支払いキーをパラメータとして、前記支払いファシリテータの承認インターフェイスへと導くことと、前記送り手から前記承認インターフェイスを介して前記承認を受信したことに応答して、前記支払いファシリテータに前記支払い取引を完了させることと、を含むことを特徴とする。

幾つかの実施形態を例示として図示し、それらは以下の添付の図面の図に限定されない。
例示の実施形態に従う、クライアントサーバアーキテクチャーを有するシステムを示すネットワークダイアグラムを示している。 幾つかの例示の実施形態に従う、図１Ａのシステムに関連し得るアプリケーションの例を示すブロックダイアグラムである。 幾つかの例示の実施形態に従う、図１Ａのシステム中に含まれるデータベースに関連し得るテーブルの例を示している。 幾つかの例示の実施形態に従う、図１Ａのシステム中に含まれるデータベースに関連し得るテーブルの例を示している。 幾つかの例示の実施形態に従う、支払いアプリケーションフレームワークの高レベル図を示すブロック図である。 幾つかの例示の実施形態に従う、支払いシナリオにおけるメタファーのアプリケーションを示す図である。 幾つかの例示の実施形態に従う、支払いシナリオにおけるメタファーの別のアプリケーションを示す図である。 幾つかの例示の実施形態に従う、メタファーに含まれるフェーズを示す図である。 幾つかの例示の実施形態に従う、事前承認が存在するフェーズの例を示す図である。 幾つかの例示の実施形態に従う、承認フローの例を示す流れ図である。 幾つかの例示の実施形態に従う、事前承認フローの例を示す流れ図である。 幾つかの例示の実施形態に従う、本支払いアプリケーションフレームワークを用いる送金シナリオの例を示している。 幾つかの例示の実施形態に従う、本支払いアプリケーションフレームワークを用いるチェックアウトシナリオの例を示している。 幾つかの例示の実施形態に従う、並行支払いおよび連鎖支払いの例を示す図を示している。 幾つかの例示の実施形態に従う、並行支払いおよび連鎖支払いの例を示す図を示している。 幾つかの例示の実施形態に従う、本明細書中で議論される任意の一つ以上の方法を機械に実行させる命令の組が実行され得るコンピュータシステムの形態での機械の図表示を示している。

幾つかの例示の実施形態に対して、支払アプリケーションフレームワークを用いる支払アプリケーションを開発する方法およびシステムが開示される。支払アプリケーションフレームワークは、メタファーおよびコンストレイントを含み得る。メタファーはアクターとオブジェクトを含み得る。アクターおよびオブジェクトは幾つかの支払取引のコンポーネントである。コンストレイントは支払取引を処理するために経ても良い規則を含み得る。

以下の既述では、説明の目的のために、例示の実施形態の完全な理解を提供することを目的に、多くの特定の詳細が記述される。しかしながら、当業者には明らかであろうが、本発明はこれら特定の詳細なしに実施され得る。

例示の実施形態では、アプリケーションによって構成されたコンピュータシステム（たとえば、クライアントマシン、サーバマシン、他）は、本明細書中に記載されるようなある動作を実施するように構成され動作する“モジュール”を構成する。したがって、用語“モジュール”は、有形のエンティティを包含すると理解されるべきであり、そのエンティティは、本明細書に記載されているある動作をある方法で動作させ、実行するように物理的に構成され、永久的に構成され（たとえば、配線され）、または一時的に構成されている（たとえばプログラミングされている）と理解されるべきである。
（オーバービュー）
支払アプリケーションフレームワークは、一組の規格を用いて支払アプリケーションの開発を許容し得る。支払アプリケーションは、たとえば、チェックアウト、送金（ｓｅｎｄ ｍｏｎｅｙ）、請求（ｒｅｑｕｅｓｔ ｍｏｎｅｙ）、分割支払い、一括支払い、定期的支払いおよびレミッタンスを含む、異なる支払いのシナリオを包囲し得る。シナリオの例は、一人以上の送付者または支払者および一人以上の受領者を含み得る。支払取引は、一つ以上の貨幣での資金の移転（転送）に関わり得る。支払取引は、貴重品または商品の移転に関わり得る。たとえば、支払取引はまた、一人以上の送付者および一人以上の受領者によってある可測値を有するものとして認められるポイント、マイレージ、報酬、または任意の有形または無形のオブジェクトまたはサービスに関わり得る。

支払アプリケーションフレームワークは、メタファーおよびコンストレイントを含み得る。メタファーおよびコンストレイントと共に使用される、またはメタファーおよびコンストレイントに適用されるフローおよびサービスが存在し得る。支払アプリケーションフレームワークを用いて、新しい支払いアプリケーションの開発は簡単化され得る。

図１Ａは例示の実施形態に従う、クライアントサーバアーキテクチャーを有するシステム１００を示すネットワークダイアグラムを示している。ネットワークベースシステム１１２の形態の例では、システムは、ネットワーク１１４（たとえば、インターネット、公衆もしくは私設電話、有線もしくは無線ネットワーク、ＢｌｕｅｔｏｏｔｈもしくはＩＥＥＥ ８０２．１１ｘのような技術を用いる私設無線セットワークまたは他のネットワーク）を介して、一つ以上のクライアントへサーバ側機能を提供する。図１Ａは、たとえば、クライアントマシン１２０上で走るウェブクライアント１１６（たとえば、ＭＩＣＲＯ
ＳＯＦＴ（登録商標）によって開発されたＩＮＴＥＲＮＥＴ ＥＸＰＬＯＲＥＲ（登録商標）ブラウザなどのブラウザ）を示している。デバイスアプリケーション１１７は、クライアントマシン１２１上で走る。プログラマティッククライアント１１８はクライアントマシン１２２上で走る。クライアントマシン１２０〜１２２のそれぞれは、ネットワークベースマシンと呼ばれることもある。さらに、図１Ａ中に示されているシステム１００はクライアントサーバアーキテクチャーを使用するが、実施形態はもちろんそのようなアーキテクチャーに限定されず、分散またはピアトゥピアのアーキテクチャーシステムに同様に用途をよく見出し得る。

クライアントマシン１２０〜１２２は、携帯デバイス、パームトップコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、パーソナルデジタルアシスタント、携帯電話、コミニュケーションデバイス、無線電話、固定電話、コントロールシステム、カメラ、スキャナ、テレビ、テレビケーブル、ウェブブラウザ付き電話、ファクシミリマシン、プリンター、ページャ、および／またはパーソナルトラスティッドデバイスを含み得る。クライアントマシン１２０〜１２２は、スマートカード、磁気カード、および／またはキーカードのようなカードを含み得る。クライアントマシン１２０〜１２２は、電話、または、ショートメッセージングサービス（ＳＭＳ）をやりとりすること、マルチメディアメッセージングサービス（ＭＭＳ）をやりとりすること、および／またはデュアルトーンマルチ周波数（ＤＴＭＦ）音声などのオーディオ音声を生成することが可能な任意のデバイスを含み得る。

クライアントマシン１２０〜１２２は、ブラウザイネーブルドであり得る。クライアントマシン１２０〜１２２は、ＳＭＳ、電子メール、拡張可能ハイパーテキストマークアップ言語（ｘＨＴＭＬ）、無線アプリケーションプロトコル（ＷＡＰ）、ウェブ、音声自動応答（ＩＶＲ）および／または他の携帯インターフェイスのような対話型メッセージおよび／またはオープンコミュニケーションセッションに組み合わせ得る。クライアントマシン１２０〜１２２とネットワークベースシステム１１２の間のコミュニケーションセッションは、複数の技術モダリティを含み得る。たとえば、クライアントマシン１２０、１２１または１２２のユーザは、ＳＭＳを介してネットワークベースシステム１１２を組み合わせ、クライアントマシン１２０、１２１、または１２２をＷＡＰまたはウェブページに導く（誘導する）埋め込まれたハイパーリンクされたＵＲＬを用いてＳＭＳとしての応答通信を受け得る。ハイパーリンクされたＵＲＬはアプリケーションサーバ（複数のアプリケーションサーバ）１２８からクライアントマシン１２０〜１２２に直接的に送達され得て、ウェブサイトまたは、ＷＡＰサイトのようなマイクロブラウザにアクセスするために用いられ得る。クライアントマシン１２０〜１２２は、携帯ビデオフォン通信、デジタルテレビ信号、および／またはデジタルラジオ信号をイネーブル化し得る。クライアントマシン１２０〜１２２は、近距離無線通信を受信するためにレシーバを含み得る。

特にネットワークベースシステム１１２に目を向けると、アプリケーションプログラムインターフェイス（ＡＰＩ）サーバ１２４、およびウェブサーバ１２６は一つ以上のアプリケーションサーバ１２８に結合され得て、プログラマティックインターフェイスおよびウェブインターフェイスを一つ以上のアプリケーションサーバ１２８に提供し得る。クライアントマシン１２０〜１２２は、アプリケーションサーバ（複数のアプリケーションサーバ）１２８にアクセスするために、一つ以上のこれらのインターフェイスを使用し得る。

たとえば、ウェブクライアント１１６は、ウェブサーバ１２６によってサポートされているウェブインターフェイスを介してアプリケーションサーバ（複数のアプリケーションサーバ）１２８にアクセスし得る。ウェブインターフェイスは、ウェブブラウザまたはｘＨＴＭＬまたはＷＡＰのようなマイクロブラウザを含み得る。同様に、プログラマティッククライアント１１８は、ＡＰＩサーバ１２４によって提供されるプログラマティックインターフェイスを介して、および／またはウェブサーバ１２６によって提供されるウェブインターフェイスを介して、アプリケーションサーバ（複数のアプリケーションサーバ）１２８によって提供される様々なサービスおよび機能にアクセスし得る。追加の実施形態では、アプリケーションサーバ（複数のアプリケーションサーバ）１２８の一つ以上のアプリケーションによってサポートされるアプリケーションは、クライアントマシン１２０〜１２２にダウンロード可能であり得る。

クライアントマシン１２０〜１２２は、アプリケーションサーバ（複数のアプリケーションサーバ）１２８の一つ以上のアプリケーションに関連するインターフェイスをホストし得る。クライアントマシン１２０〜１２２上のインターフェイスは、ＡＰＩインターフェイス、ＳＭＳインターフェイス、ウェブインターフェイス、および／またはＩＶＲインターフェイスであり得る。Ｊａｖａ２プラットフォームマイクロエディション（Ｊ２ＭＥ）、Ｊ２ＳＥおよびＪ２ＥＥなどの市販の無線デバイスプラットフォームは、クライアントマシン１２０〜１２２のためのアプリケーションおよびプログラムを生成するためにＪａｖａおよび無線ツールキットをデベロッパが使用することを許容する。Ｊ２ＭＥインターフェイスは、クライアントマシン１２０〜１２２に対するＡＰＩを含み得る。プログラマティッククライアント１１８のアプリケーションはまた、たとえば、無線バイナリランタイム環境（ＢＲＥＷ）を用いてネットワーク１１４にアクセスし得る。

クライアントマシン１２１上で実行されるデバイスアプリケーション１１７は、ウェブサーバ１２６のウェブインターフェイスを介してアプリケーションサーバ（複数のアプリケーションサーバ）１２８にアクセスし得る。デバイスアプリケーション１１７は、クライアントマシン１２１上で選択され得て、バックグラウンドでラウンチされ得る。デバイスアプリケーション１１７は、追加でまたは代替で、ＡＰＩサーバ１２４のプログラマティックインターフェイスを介してサーバ（複数のサーバ）にアクセスし得る。実施形態では、本明細書中に記載されているダウンロード可能なアプリケーションは、デバイスアプリケーション１１７を含み得る。

アプリケーションサーバ（複数のアプリケーションサーバ）１２８は、一つ以上の管理モジュール１３０および一つ以上の支払いモジュール１３２をホストし得る。アプリケーションサーバ（複数のアプリケーションサーバ）は、次に、一つ以上のデータベース１３６にアクセスするのを容易にする一つ以上のデータベースサーバ１３４に結合されるように図示されている。アカウント管理モジュール（複数のアカウント管理モジュール）１３０は、本明細書中でより詳細に議論されるように、様々なアカウントの管理を提供し得る。

サードパーティーサーバー１４０の上で走るサードパーティーアプリケーション１３８は、クライアントマシン１２０〜１２２のユーザに商品およびサービスを提供し得る。サードパーティーアプリケーション１３８は、ＡＰＩサーバ１２４によって提供されるプログラマティックインターフェイスを介してのネットワークベースシステム１１３へのプログラマティックアクセスを有し得る。サードパーティーアプリケーション１３８は、ベンダ、マーチャント、またはクライアントマシン１２０〜１２２のユーザとの取引を行い得る任意の組織と関連し得る。幾つかの例示の実施形態では、サードパーティーアプリケーション１３８は、オンラインマーケットプレイス（たとえば、カリフォルニア州サンノゼのｅＢａｙ，Ｉｎｃ．）と関連し得る。

支払いモジュール（複数の支払いモジュール）１３２は、クライアントマシン１２０〜１２２のユーザに幾つかの支払いサービスおよび機能を提供し得る。支払いモジュール（複数の支払いモジュール）１３２は、ユーザに勘定の（たとえば、米ドルのような商業通貨、または“ポイント”のような独自通貨での）値を積み立て、そして後に幾つかの可能な方法を介して積み立てた値を清算することを許容し得る。支払いモジュール（複数の支払いモジュール）１３２はまた、ユーザにクレジットを提供しても良いし、および／または取引を完了するために他のファンディングソース（資金源）にアクセスを有しても良い。ファンディングソースの例は、クレジットカード、銀行口座、および／またはクレジットラインを含む。支払いモジュール（複数の支払いモジュール）１３２は、資金送金者として働き得る。

サードパーティーアプリケーション１３８に関連するサードパーティーはユーザとの取引を行っても良いし、支払いモジュール（複数の支払いモジュール）１３２から情報を受け取っても良い。情報は、製品、サービス、ギフト、寄付、他のためのオーダーに関する情報を含み得る。情報はまた、ユーザによって指定された送付先アドレスおよび支払い確認を含む支払い状況を含み得る。支払いモジュール（複数の支払いモジュール）１３２は、サードパーティーに関するユーザの金融情報を保護し得る。

クライアントマシン１２０、１２１、または１２２は、アプリケーションサーバ（複数のアプリケーションサーバ）１２８の支払いモジュール（複数の支払いモジュール）１３２に関連するインターフェイスをホスト（提供）し得る。ウェブクライアント１１６、デバイスアプリケーション１１７、および／またはプログラマティッククライアント１１８は、アカウント管理モジュール（複数のアカウント管理モジュール）１３０および／または支払いモジュール（複数の支払いモジュール）１３２に関連し得る。

支払いモジュール（複数の支払いモジュール）１３２はまた、ネットワーキング能力を必ずしも有することはないスタンドアロンソフトウェアプログラムとして実装され得る。この実施形態では、クライアントマシン１２０〜１２２は、ネットワーク１１４を用いることなく、直接的に支払いモジュール（複数の支払いモジュール）１３２に接続され得る。

支払いモジュール（複数の支払いモジュール）１３２は、データベースサーバ（複数のデータベースサーバ）１３４に接続され得るデータベース１３６へのアクセスを有し得る。データベース１３６はユーザアカウント情報を含み得る。ユーザアカウント情報は、支払い情報、クレジットカード情報、当座預金情報、アドレス情報、他を含み得る。

ウェブクライアント１１６、デバイスアプリケーション１１７、および／またはプログラマティッククライアント１１８は、一つ以上のデータベースサーバ１３４によってサポートされるプログラムを動作させ得る。データベースサーバ（複数のデータベースサーバ）１３４は、たとえば、ウェブクライアント１１６を用いて、クライアントマシン１２０〜１２２のユーザインターフェイス上の一つ以上のアカウント情報リンクをサポートし得る。データベースサーバ（複数のデータベースサーバ）１３４にアクセスすることによって、ユーザは、たとえば、送付先アドレス、支払い方法、他を含む自分自身のアカウント情報を追加、修正、または削除し得る。

ネットワーク１１４は、携帯電話ネットワーク、広域無線ネットワーク（ＷＷＡＮ）、有線電話ネットワーク、無線ローカルエリアネットワーク（無線ＬＡＮまたはＷＬＡＮ）、無線都市規模ネットワーク（ＭＡＮ）、および／または無線パーソナルエリアネットワーク（ＰＡＮ）（たとえば、ブルートゥース（登録商標）ネットワーク）を含み得る。接続するために用いられ得る他のネットワークベース技術は、ＰＯＮ、ＶＳＡＴ衛星、マイクロインパルスレーダ、電波による個体識別（ＲＦＩＤ）、ウルトラワイドバンド、および／または赤外を含む。クライアントマシン１２０〜１２２は、たとえば、無線アプリケーションプロトコル（ＷＡＰ）および／またはハイパーテキスト転送プロトコル（ＨＴＴ
Ｐ）のような携帯インターネット交換プロトコルを用いて、ウェブに接続し得る。
＜マーケットプレイスアプリケーション＞
図１Ｂは、一実施形態ではネットワークシステム１１２の一部として与えられる複数のアプリケーション１３０および１３２を示すブロック図である。アプリケーション１３０および１３２は、サーバマシン間の通信を可能とするために通信で接続されている（図示されていない）専用のまたは共有のサーバマシン上にホストされ得る。アプリケーション１３０および１３２はそれら自身、互いに、様々なデータソースに通信で接続されており、情報がアプリケーション間でパスされること、またはアプリケーション１３０および１３２が共通データを共有し共通データにアクセスすることが許容する。アプリケーション１３０および１３２はさらに、データベースサーバ１３４を介して一つ以上のデータベース１３６にアクセスし得る。

ネットワークシステム１１２は、幾つかの、公表機構、リスト機構、および価格設定機構を提供し得るが、それによって売り手は販売のための商品またはサービスをリスト（または販売のための商品またはサービスに関する情報を公表）し得て、買い手はそのような商品またはサービスへの興味を表現するまたは購入の希望を示すことができ、その商品またはサービスに関係する取引のために価格が設定され得る。この目的のために、マーケットプレイスアプリケーション１３０は、オークションフォーマットリスティングおよび価格設定機構（たとえば、イングリッシュオークション、ダッチオークション、ヴィックレイオークション、チャイニーズオークション、ダブルオークション、逆オークション、他）をサポートする少なくとも一つの公表アプリケーション１４０および一つ以上のオークションアプリケーション１４２を含むように示されている。様々なオークションアプリケーション１４２はまた、そうしたオークションフォーマットリストをサポートする幾つかのフィーチャ、例えば、それによって売り手がリストに関係する最低競売価格を特定し得る最低競売価格フィーチャおよび、それによって入札者が自動プロキシ入札をし得るプロキシ入札フィーチャなどを提供し得る。

幾つかの固定価格アプリケーション１４４は、固定価格リストフォーマット（たとえば、伝統的にクラス分けされた広告型リストまたはカタログリスト）およびバイアウト型リストをサポートする。特に、（たとえば、カリフォルニア州サンノゼのｅＢａｙ．Ｉｎｃ．によって開発された）バイアウト型リストは、オークションフォーマットリストと共に提供され得て、買い手がオークションを介した販売のためにも提供される商品またはサービスを、一般的にはオークションの開始価格より高い固定価格で購入することを許容する。

ストアアプリケーション１４６は、売り手によって、および売り手に対してマークされるか、さもなければパーソナライズ化され得る、“仮想”ストア内でリストをグループ化することを許容する。そのような仮想ストアはまた、関連する売り手に対して、特定の、パーソナライズ化されたプロモーション、インセンティブ、およびフィーチャを提供し得る。

評判アプリケーション１４８は、ユーザが、ネットワークシステム１１２を用いて、取引先となる可能性のあるパートナーが入手可能で、彼らに対して公表され得る評判を確立、構築、保持することを許容する。たとえば、ネットワークシステム１１２が個人から個人への取引をサポートすることを考えると、そうしなければユーザは、取引先となる可能性のあるパートナーの信頼性および信用性が評価され得る履歴または他の参照情報を有さないかも知れない。評判アプリケーション１４８は、ユーザに、たとえば他の取引パートナーによって提供されたフィードバックを介して、時間の経過とともにネットワークシステム１１２内の評判を確立することを許容する。他の取引先となる可能性のあるパートナーは、よって、信頼性および信用性の評価の目的のためにそれらの評判を参照し得る。

パーソナル化アプリケーション１５０は、ネットワークシステム１１２のユーザが、ネットワークシステム１１２とのインターアクション（やり取り）の様々な面をパーソナル化することを許容する。たとえば、ユーザは、適切なパーソナル化アプリケーション１５０を利用して、ユーザが関係者である（または関係者であった）取引に関連する情報が閲覧され得るパーソナル化された参照ページを生成し得る。さらに、パーソナル化アプリケーション８１０は、ユーザがリストおよびネットワークシステム１１２および他の関係者とのインターアクションの他の面をパーソナル化することを可能とし得る。

ネットワークシステム１１２は、たとえば、特定の地理的領域に対してカスタマイズされた幾つかのマーケットプレイスをサポートし得る。ネットワークシステム１１２のあるバージョンは、英国に対してカスタマイズされ得るが、ネットワークシステム１１２の別のバージョンは、合衆国に対してカスタマイズされ得る。これらのバージョンの各々は、独立のマーケットプレイスとして動作し、または共通の基礎的マーケットプレイスのカスタマイズされた（または国際化された）表現であり得る。ネットワークシステム１１２は、したがって、所定の基準（たとえば、地理的、人口統計的、またはマーケットプレイス基準）にしたがって、ネットワークシステム１１２により、情報（および／または情報の表現）をカスタマイズする幾つかの国際化アプリケーション１５２を含み得る。たとえば、国際化アプリケーション１５２は、ネットワークシステム１１２によって動作し、それぞれのウェブサーバ１２６を介してアクセス可能な幾つかの地域ウェブサイトに対する情報のカスタム化をサポートするために使用され得る。

ネットワークシステム１１２のナビゲーションは、一つ以上のナビゲーションアプリケーション１５４によって利用され得る。たとえば、（ナビゲーションアプリケーションの例としての）検索アプリケーションは、ネットワークシステム１１２を介して公表されたリストのキーワード検索を可能とし得る。ブラウズアプリケーションは、ユーザが、リストがネットワークシステム１１２内で区分され得る、様々なカテゴリ、カタログ、または在庫データ構造をブラウズすることを許容し得る。様々な他のナビゲーションアプリケーションは、検索およびブラウズアプリケーションを補足するために備えられ得る。

ネットワークシステム１１２を介して入手可能なリストを、できるだけ視覚的に情報を伝達し、且つ魅惑的なものとするために、マーケットプレイスアプリケーション１３０は、ユーザがそれを使ってリスト内に含ませるための画像をアップロードし得る一つ以上の画像アプリケーション１５６を含み得る。画像アプリケーション１５６はまた、閲覧リスト内に画像を組みいれるように動作し得る。画像アプリケーション１５６はまた、可能性のある買い手に対して表示される画像ギャラリーのような、一つ以上の宣伝用フィーチャをサポートし得る。たとえば、売り手は、宣伝されたアイテムに対する画像のギャラリー内に含まれる画像を所有するために追加の料金を支払っても良い。

リスト生成アプリケーション１５８は、売り手に、ネットワークシステム１１２を介して取引したいと希望する商品またはサービスに関連する別のリストを便利に提供することを許容し、リスト管理アプリケーション１６０は、売り手がそのようなリストを管理することを許容する。特に、特定の売り手が、多くのリストを著しおよび／または公表している場合、そのようなリストの管理は、挑戦的様相を呈する。リスト管理アプリケーション１６０は、そのようなリストの管理の際に売り手を援助するための幾つかのフィーチャ（たとえば、自動再リスト作成、在庫レベルモニタ、他）を提供する。一つ以上の投稿リスト管理アプリケーション１６２はまた、一般的には投稿リストを生じる幾つかのアクティビティで売り手を支援する。たとえば、一つ以上のオークションアプリケーション１４２によって容易になったオークションの完了の際、売り手は、特定の買い手に関するフィードバックを残したいと希望するかも知れない。この目的のために、投稿リスト管理アプリケーション１６２は、一つ以上の評判アプリケーション１４８へインターフェイスを提供し、売り手が、評判アプリケーション１４８に複数の買い手に関するフィードバックを便利に提供するようにし得る。

紛争解決アプリケーション１６４は、それによって取引関係者の間に生じる紛争が解決され得る機構を提供する。たとえば、紛争解決アプリケーション１６４は、関係者が紛争を解決しようという試みにおける幾つかのステップを通して案内される、案内手順を提供し得る。紛争が案内手順を介して解決され得ない場合は、紛争は第三者調停者または仲裁人に処理事項として上げられ得る。

幾つかの不正防止アプリケーション１６６は、ネットワークシステム１１２内の不正の発生を減らすために、不正検出および防止機構を実施する。

メッセージアプリケーション１６８は、ネットワークシステム１１２のユーザに対し、ネットワークシステム１１２におけるリストの状況に関してユーザに助言をする（たとえば、オークション工程の間に入札者に対して“アウトビッド（競り合い）”の通知を与える、またはユーザに対して、販売促進およびマーチャンダイジング情報を与える）メッセージのような、メッセージの生成および配信を担う。それぞれのメッセージアプリケーション１６８は、ユーザにメッセージを配信するために、任意の数のメッセージ配信ネットワークおよびプラットフォームを利用し得る。たとえば、メッセージアプリケーション１６８は、電子メール（ｅ−ｍａｉｌ)、インスタントメッセージ（ＩＭ）、ショートメッセージサービス（ＳＭＳ）、テキスト、ファクシミリ、または音声（例えば、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）メッセージを、有線（たとえば、インターネット）、旧来の音声通話サービス（ＰＯＴＳ）、または無線（たとえば、携帯、セル式、ＷｉＦｉ、ＷｉＭＡＸ）のネットワークを介して配信し得る。

マーチャンダイジングアプリケーション１７０は、売り手に対して、売り手がネットワークシステム１１２を介して販売を増やせるようにすることを可能とする様々なマーチャンダイジング機能をサポートする。マーチャンダイジングアプリケーション１７０はまた、売り手によって呼び出され得て、売り手によって使用される一連のマーチャンダイジング戦略をモニタおよび追跡し得る様々なマーチャンダイジングフィーチャを動作する。

ネットワークシステム１１２はそれ自体、またはネットワークシステム１１２を介して処理される一つ以上のパーティは、一つ以上のロイヤリティ／販売促進アプリケーション１７２によってサポートされるロイヤリティプログラムを動かし得る。たとえば、買い手は特定の売り手と確立したおよび／または合意した各契約に対してロイヤリティまたは販売促進ポイントを得ることができ、積算されたロイヤリティポイントが引き換えられ得る報酬を与えられ得る。

支払フレームワークアプリケーション１７４は、支払いアプリケーションの開発ができるようにするために支払アプリケーション開発者との対話を担う。支払フレームワークアプリケーション１７４は、支払取引のコンポーネントを送金者から受領者へのバリュー（価格）の転送をできるようにするフローに沿って、送金エンティティ（または送金者）、受領エンティティ（または受領者）、支払システム（または支払ファシリテータ）に関する所定のツールを含む少なくとも幾つかの所定のツールの組に関連付けることができる動作を実施し得る。支払フレームワークアプリケーション１７４は、データベース１３６中に記憶された情報にアクセスすることを可能にし得る。
＜データ構造＞
図１Ｃは、データベース１３６中に保持され得て、アプリケーション１３０および１３２によって利用され、アプリケーション１３０および１３２をサポートする様々なテーブル１８０を示す、ハイレベルエンティティ関係図である。ユーザテーブル１８１は、ネットワークシステム１１２の各々の登録ユーザに対する記録を含み、各々の登録ユーザに関する識別子、アドレスおよび金融商品情報を含み得る。ユーザは、ネットワークシステム１１２内において、売り手、買い手、または両方として動作し得る。実施形態の一例では、買い手は積算値（累積値）（たとえば、商業通貨または独自通貨）を有し、したがってネットワークシステム１１２によって販売が提供されたアイテムに対して、積算値を換金することができるユーザであり得る。

ユーザテーブル１８１は、図１Ｂ中に記載された支払フレームワークアプリケーション１７４によって使用され得る一人以上の送り手および受け手と関連し得る。

テーブル１８０はまた、ネットワークシステム１１２を介して取引されることが可能な、または取引されてきた商品およびサービスの記録が保持されている品目テーブル１８２を含む。品目テーブル１８２内の各項目記録はさらに、ユーザテーブル１８１内の一つ以上のユーザ記録とリンクされ、一人の売り手と一人以上の実際の買い手または可能性のある買い手を各品目記録に関連付け得る。

取引テーブル１８３は、品目テーブル１８２内に記録が存在する品目に関係する各取引（たとえば、購入または販売取引）に対する記録を含む。

注文テーブル１８７は、注文記録であって、各注文記録は注文に付随する注文記録が集められている。よって、各注文は、記録が取引テーブル１８３内に存在する一つ以上の取引に関し得る。

ビッド（入札）テーブル１８８内のビッド記録はそれぞれ、オークションアプリケーション１４２によってサポートされているオークションフォーマットリストに関連してネットワークシステム１１２で受けられるビッドに関係する。フィードバックテーブル１８４は、一実施形態では、ユーザに関する評判情報を構成し、保持するために、一つ以上の評判アプリケーション１４８によって利用される。履歴テーブル１８５は、ユーザが関係者であった取引の履歴を保持する。一つ以上の属性テーブル１８６は、品目テーブル１８２内に記録が存在する品目に関する属性情報を記録する。そのような属性の単なる一つの例を考えると、属性テーブル１８６は、特定の品目に関わり、売り手によって特定された際に関連品目に対する通貨価格を識別する通貨属性を示し得る。支払いフレームワークテーブル１９０は、支払いフレームワークアプリケーション１７４によって用いられ得る情報を含み得る。

図１Ｄは、データベース１３６内に保持されるだろう図１Ｃ中に示されている支払いフレームワークテーブルに関するさらなる詳細を与える。図示されているように、支払いフレームワークテーブル１９０は、複数のフィールドを含み得る。フィールドの各々は、以下でさらに詳細に記載するように、たとえば、メタファー１９１、オブジェクト１９２、およびコンストレイント１９３のような幾つかのユーザ情報に関連し得る。
（支払いアプリケーションフレームワーク）
幾つかの例示の実施形態に対しては、支払いアプリケーションフレームワークを用いて開発された支払いアプリケーションは、一般的に（送り手と称される）ある関係者に付随するアカウントから（受け手と称される）別の関係者に付随する別のアカウントにバリュー（たとえば、資金、報酬ポイント、など）の移転（転送）を可能にする。バリューの移転を実施するために、支払いアプリケーションの実行は、一つ以上の承認フローを基になされ得る。このことは、これらの承認フローを開始し、支払いファシリテータのサー
ビスを使うためのアクセス、またはその権利を有することを必要とし得る。支払いファシリテータの一例は、カリフォルニア州サンノゼのＰａｙＰａｌ，Ｉｎｃ．によって提供されるサービスである。アクセスを有することは、送り手のアカウントにはないバリューを移転する承認を有することを含まなくても良い。承認を有することは、アクセスを有することを明示的に含み得る。このことは、以下で議論される、事前承認の状況に適用可能であり得る。

支払いアプリケーションは支払い要求を生成し得る。支払い要求は支払取引に関連する。支払い要求は、一つ以上の支払取引のセットアップまたは定義のために支払いファシリテータ（または支払いファシリテータ中の支払処理ロジック）に提供される命令を含む。たとえば、分割払いシナリオでは、単一の支払い要求が、一つの支払取引または複数の支払取引を参照することができる。支払い要求は、支払取引をセットアップするために開発者によって使用されるツールと見ても良い。支払い要求は、送り手および受け手には明白であって良い。支払取引は、送り手および受け手により見易く、認識可能であっても良い。

図２は、幾つかの実施形態に従う、支払いアプリケーションフレームワークのハイレベル図を示すブロック図である。支払いアプリケーションフレームワーク２００は、システム１００中に記載される一つ以上の支払いモジュール１３２を形成し得る支払いアプリケーションを開発するために用いられ得る。支払いアプリケーションフレームワーク２００は、コンストレイントライブラリ２０５およびメタファーライブラリ２１０を含み得る。支払いアプリケーションフレームワーク２００はまた、支払いアプリケーション２２０がカスタマイズされた情報２１５を受けることを可能にする。カスタマイズされた情報２１５は、コンストレイントライブラリ２０５および／またはメタファーライブラリ２１０中に含まれる情報を修正する、置き換える、または補足する情報を含み得る。

幾つかの実施形態に対しては、メタファーライブラリ２１０は、より詳細な支払い関連概念のハイレベル図を表すメタファーを含み得る。メタファーは、異なるタイプの支払いアプリケーション２２０を理解し、異なるタイプの支払いアプリケーション２２０にわたって整合性を確保することを可能とするために、単純かつ容易であるように設計され得る。幾つかの実施形態に対しては、コンストレイントライブラリ２０５は、支払い規則に関連するコンストレイントを含み得る。幾つかのコンストレイントは、デフォルト値に関連し得る。コンストレイントの幾つかの例は、支払いの頻度、支払いに付随する通貨、他を含む。

幾つかの例示の実施形態に対しては、支払いアプリケーションフレームワーク中のメタファーは、アクター、オブジェクト、及びフレーズを含み得る。アクター、オブジェクト、及びフレーズは、支払いアプリケーションフレームワーク２００を用いて開発された複数の支払いアプリケーションにわたって同様な方法で互いに対話し得る。支払いアプリケーションは、異なるタイプの支払取引を処理するために開発され得る。
（メタファー：アクター）
図３Ａは、幾つかの例示の実施形態に従う、支払いシナリオにおけるメタファーのアプリケーションを示す図である。本例では、図３００は、送り手３０５、受け手３１０、および支払いファシリテータ（または支払いネットワーク）３１５を含む。送り手３０５、受け手３１０、および支払いファシリテータ３１５は、支払いアプリケーションフレームワーク２００内で支払取引に係わるアクターであると考えられる。
（Ａ／送り手）
幾つかの例示の実施形態に対しては、送り手３０５は、支払いファシリテータ３１５のアカウントのアカウント所有者である。支払いは、送り手３０５のアカウント（口座）から引き落とされるであろう。送り手３０５は、アカウントを実際に有する任意の人、複数の人、またはエンティティを表し得る。送り手３０５はまた、実際のオーナー（所有者）の名義のアカウントにアクセスするための承認を受けた任意の個人、複数の人、またはエンティティを表し得る。送り手３０５は、一つ以上の支払取引に係わり得る。幾つかの例示の実施形態に対しては、送り手３０５は、支払いファシリテータ３１５に関連する電子メールアドレスに係わり得る。たとえば、支払いファシリテータ３１５は、カリフォルニア州のサンノゼのＰａｙＰａｌ，Ｉｎｃ．であり、ＰａｙＰａｌ，Ｉｎｃ．に関する電子メールアドレスは、ＳｅｎｄｅｒＩＤ＠ＰａｙＰａｌ．ｃｏｍであり得る。幾つかの実施形態に対しては、電子メールアドレスは、携帯電話番号またはアカウントへの他のそのような独自の参照で置き換えられ得る。幾つかの例示の実施形態に対しては、支払取引で一つの受け手３１０に支払いを送る複数の送り手３０５が存在し得る。この支払いシナリオは、集計支払いと呼ばれる。
（Ｂ／受け手）
幾つかの例示の実施形態に対しては、受け手３１０は支払いファシリテータ３１５のアカウントのアカウント所有者である。受け手３１０は、アカウントを実際に有する任意の個人、複数の人、またはエンティティを表し得る。受け手３１０はまた、実際のオーナー（所有者）の名義のアカウントにアクセスするための承認を受けた任意の人、複数の人、またはエンティティを表し得る。受け手３１０は、一つ以上の支払取引に係わり得る。幾つかの例示の実施形態に対しては、受け手３１０は、支払いファシリテータ３１５に関連する電子メールアドレスに係わり得る。幾つかの例示の実施形態に対しては、一つの送り手３０５から支払いを受ける複数の受け手３１０が存在し得る。この支払いシナリオは、分割支払いと呼ばれる。幾つかの例示の実施形態に対しては、支払取引に複数の送り手３０５および複数の受け手３１０が存在し得る。
（Ｃ／支払いファシリテータ）
幾つかの例示の実施形態に対しては、支払いファシリテータ３１５は、送り手３０５から支払い要求２３０を受け得る。支払い要求３２０は、支払い要求を詳細に記載する一つ以上の品目名を有し得る。支払いファシリテータ３１５は、支払い要求３２０を処理し得て、送り手３０５のアカウントから受け手３１０のアカウントに送られるであろう支払い３２５を引き起し得る。支払いファシリテータ３１５は、送り手３０５に、異なる支払い道具を用いることを可能とする。たとえば、支払い道具は、クレジットカード、デビットカード、当座預金口座、普通預金口座、他を含み得る。

図３Ｂは、幾つかの例示の実施形態に従う、支払いシナリオにおけるメタファーの別のアプリケーションを示す図である。本例で記載される支払いシナリオはまた、支払い猶予と呼ばれ得る。図３９０は、送り手３０５、受け手３１０、支払い要求３５０、および支払い３５５を含む。幾つかの例示の実施形態に対しては、支払いアプリケーションフレームワーク２００は、支払い３５５が第１の支払いファシリテータまたは支払いネットワーク３６０から第２の支払いファシリテータまたは支払いネットワーク３６５に送られることを可能とし得る。支払いファシリテータ３６０および支払いファシリテータ３６５は、同一の支払いファシリテータであっても良いし、異なるファシリテータであっても良い。同様に、“フロム（ｆｒｏｍ）”支払いネットワークおよび“トゥー（ｔｏ）”支払いネットワークは同一の支払いネットワークであっても良いし、異なる支払いネットワークであっても良い。支払いネットワークの例には、自動資金決済センター（ＡＣＨ）、デビット、スイフト、および仮想通貨を含み得る。本例では、支払いネットワークはまた、支払いアプリケーションフレームワーク２００内の支払取引に係るアクターとして考えられ得る。

以下の議論では、支払いファシリテータによって処理される支払いを参照する例を用いるが、これらの議論はまた、一つ以上の支払いファシリテータおよび／または一つ以上の支払いネットワークに適用し得ることに注意すべきであろう。
（メタファー：オブジェクト）
幾つかの例示の実施形態に対しては、オブジェクトは、支払い要求、支払いキー、および支払い要求および支払いキーに関連するパラメータを含み得る。支払い要求は、支払いを定義する情報を含み得る。支払いキーは、暗号化され、承認を要求する、または承認を示すために用いられ得る。今後議論されるように、承認は、承認フローまたは事前承認フローに関連し得る。パラメータは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）メッセージ中に含まれ得る。ＨＴＴＰメッセージは、支払いアプリケーション間で送付され得るし、支払いファシリテータによって処理され得る。

図３Ａ中に示された例を参照すると、支払い要求３２０は、量、送り手に関する情報、受け手に関する情報、および通貨を含み得る。支払い要求３２０はまた、たとえば処理費用のような、他の関連する情報を含み得る。処理費用は、支払取引を処理するために支払いファシリテータ３１５によって課金された料金である。処理費用は、送り手３０５または受け手３１０によって支払われ得る。

支払い要求３２０は、支払いファシリテータ３１５に送付され、支払いファシリテータ３１５によって処理される。支払いファシリテータ３１５は、支払い要求３２０の受け取りに応答して、支払いキーを発行し得る。支払いファシリテータ３１５は、支払いキーを送り手３０５に送っても良い。支払いキーは、承認のために用いられ得る。幾つかの例示の実施形態に対しては、支払い要求３２０は、送り手３０５が支払い要求３２０を承認するまで処理されない。送り手３０５は、承認フローに基づいて承認（または承認のしるし）を提供し得る。送り手３０５から受けた承認のしるしは、ポジティブな承認であっても、ネガティブな承認であっても良い。

支払いキーは、支払い要求と一意に関連付けられ、支払い要求に関するその後の支払取引で用いられ得る。幾つかの例示の実施形態に対しては、もし承認が所定の期間後に受け取られなければ、送り手からの承認を待つ支払い要求は失効し得る。支払い要求が失効しないようにするために期間延長が発行されてもよい。支払いキーの例は図４Ａ中の支払いキー４２０として示されている。

幾つかの例示の実施形態に対しては、承認は、支払いがなされる前に送り手３０５によって提供され得る。これは事前承認と呼ばれる。事前承認の状況では、事前承認要求が生成され、支払いファシリテータに送付され得る。支払いファシリテータは、事前承認要求を処理し得て、事前承認キーを返し得る。次に、事前承認支払いと共に支払い要求が、処理のために支払いファシリテータに送付され得る。

幾つかの例示の実施形態に対しては、事前承認キーは、将来の一回払いのため、または一組の将来の繰り返し払いのために発行され得る。事前承認キーは、事前承認要求に一意のものであり得る。送り手３０５は、事前承認フローに基づいて事前承認を提供し得る。事前承認フローは、一組の規則を含み得る。幾つかの例示の実施形態に対しては、事前承認要求は、猶予（延長）されない限り、所定の期間後に失効し得る。事前承認キーの例は、図４Ｂ中に事前承認キー４６５として示されている。

支払いファシリテータは、承認要求および事前承認要求を扱う機能を実施し得る。支払いファシリテータはまた、他の支払い関係の要求を扱う機能を実行し得る。これらの機能の幾つかは、毎回の支払取引で要求され得るが、幾つかはオプションであり得る。支払いファシリテータのサービスおよび／または可能性を限定することなく、以下の表（表１）は機能の幾つかの例を強調して示す。
［表１］
（サービスまたは可能性名：利用）
−支払い：個々の支払取引で用いられる。
−支払い状況取得：支払いの状況を画定するために用いられる。
−事前承認取得：将来の一回または繰り返し支払いの承認を得るために用いられる。
−事前承認状況取得：送り手が事前承認要求を承認したかどうかを画定するために用いられる。
−キャプチャ：支払いのために確保されている資金を獲得するために用いられる。部分払いは許容されないかも知れないが、分割払いの範囲内で、支払い要求の特定のセグメントまたは処理のキャプチャが可能である。
−払い戻し：払い戻し機能が用いられると直ちに、複数の受け手からの払い戻しが作動される複雑な分割支払いシナリオで用いられる。この機能は、サードパーティーアクセス権を要求し得る。払い戻し処理は、払い戻し関数を呼ぶことによって、受け手によって実行され得る。受け手は支払いキーおよび送り手に払い戻しされるであろう許可された払い戻し量を許可し得る。
−対話型音声応答（ＩＶＲ）承認：支払いの承認を得るために登録された支払いファシリテータのユーザの携帯電話番号に電話をするために、支払いファシリテータのＩＶＲサービスを作動するために用いられる。
−支払い要求詳細取得：支払いキーに基づいて支払い要求に関する情報を取得するために用いられる。支払いキーは、一つ以上の取引きにマップされ得る。
−事前承認要求詳細取得：事前承認キーに基づいて支払い要求についての情報を取得するために用いられる。
（メタファー：フェーズ）
図４Ａは、幾つかの例示の実施形態に従う、メタファーに含まれるフェーズを示す図である。図４００は、支払いアプリケーションフレームワークのメタファーの一部であり得るフェーズを示している。２つのフェーズがある。一つのフェーズは、支払いフェーズ４０５と呼ばれ、もう一つは承認フェーズ４１０と呼ばれる。支払いフェーズ４０５の間、コンストレイントが定義され、支払いファシリテータ３１５に提示され得る。承認フェーズ４１０の間、承認は送り手３０５によって提供され、支払いファシリテータ３１５を用いて送り手のアカウントからの資金の引き落としを承認し得る。図４Ｂ中に記載されるように、承認フェーズの変形例は事前承認フェーズ４５５である。

幾つかの例示の実施形態に対しては、支払いフェーズ４０５は、承認フェーズより前に生じ得る。一例は、支払い要求が送り手による承認の次に起こる単純なチェックアウトシナリオである。示されているように、支払い要求は、パラメータとして支払いキー４２０を含み得る。承認フェーズ４１０に係る動作は、承認フローに基づき得る。承認フローは、送り手３０５を支払いファシリテータ３１５のウェブサイトに導いても良い。支払いファシリテータ３１５のウェブサイトは、承認に必要な情報を提供するために、送り手３０５に対するインターフェイスを提供し得る。例えば、送り手３０５は、小売商（業者）のウェブサイトでひとつの品物を購入する顧客であり得る。送り手３０５は、小売商のウェブサイトから、支払いファシリテータのウェブサイトにリダイレクト（再誘導）され得る。このリダイレクトは、支払いファシリテータのウェブサイト（たとえば、ＰａｙＰａｌウェブサイト）によって提示されるインターフェイスに係わるユニフォームリソースロケータ（ＵＲＬ）リンクを介し得る。送り手３０５が支払いの承認を与えることに基づいて、送り手３０５は、小売商のウェブサイトにリダイレクトされ得る。このシナリオでは、リダイレクトＵＲＬリンク（たとえば、小売商のウェブサイトへのリンク）は、パラメータとして送られ得て、送り手３０５は、承認フローの完了に引き続いて、小売商のウェブサイトの特定のページにリダイレクトされる。

幾つかの例示の実施形態に対しては、承認フェーズ４１０は承認通知フローに関連し得る。承認通知フローは、パラメータとして通知ＵＲＬリンクを用い得る。通知ＵＲＬリンクは、小売商に関連し得る。たとえば、送り手３０５が承認を与えるとき、小売商は通知を受け、小売商のウェブサイトでの送り手３０５の購入処理は、次のステップに進むことができる。本例での小売商は、受け手３１０の役割を果たす。幾つかの例示の実施形態に対しては、承認フェーズ４１０は、資金が送り手のアカウントの外に移転したときに、送り手３０５に通知を送ることを含み得る。このことは、電子メール、無線通信、または送り手３０５に通知することが可能であり得る任意の他の通信形式を介して実施され得る。類似の通知はまた、受け手３１０に送られても良い。

図４Ｂは、幾つかの例示の実施形態に従う、事前承認が存在するフェーズの例を示す図である。図４５０は、事前承認フェーズ４５５および支払いフェーズ４６０を示している。事前承認シナリオでは、事前承認フェーズ４５５は、支払いフェーズ４６０より前に生じ得る。事前承認フェーズ４５５は、事前承認フローに基づいても良い。

事前承認要求は、開始され、送り手３０５に送付され得る。事前承認要求は、受け手（たとえば、小売商）３１０によって開始され得る。事前承認キー４６５もまた、送られ得る。送り手３０５は、支払いファシリテータ３１５に係わる事前承認インターフェイスを介して事前承認要求をレビューし得る。送り手３０５は、受け手３１０に事前承認を与え得る。上述のように、事前承認キー４６５は、一意のもので、将来の一回払いまたは将来の繰り返し払いのための事前承認に係わり得る。幾つかの例示の実施形態に対しては、事前承認キー４６５は暗号化されたデータを用いて送られ得る。
（コンストレイント）
コンストレイントは、より効率的に支払いアプリケーションを開発するために開発者によって用いられ得る規則を含み得る。規則は支払いフローに実装され得る。支払いフローは承認フローおよび／または事前承認フローに係わり得る。パラメータは、支払いフローで用いられ得る。パラメータはデフォルト値を有し得る。幾つかの例示の実施形態に対しては、パラメータの中には、デフォルト値を変えないまま支払いフロー中で用いられ得るものもある。以下の表（表２）は、使用され得る支払いフローの要約の例を示している。

受け手３１０が支払いフローを用いるために、受け手３１０は支払いファシリテータ３１５によって提供されるサービスにアクセスをする必要があるかも知れない。上述のように、アクセスをすることは、受け手３１０が支払い要求を支払いファシリテータ３１５に送ることを可能とし得る。送り手３０５が支払いの事前承認を与える場合には、送り手３０５は暗黙のうちに、受け手３１０（事前承認を開始した関係者）に、送り手３０５の代わりに送り手３０５のアカウントにアクセスさせ得る。このことは、事前承認がアクティブである期間に制限され得る。幾つかの例示の実施形態に対しては、受け手３０１は、資金を確保するためだけに支払い要求を開始し得る。これらの状況では、確保された資金に関する動作だけを完了し、資金の移転（転送）は、（上述の）キャプチャが存在するまで待っても良い。キャプチャは、パラメータとして支払いキーを含み得る。
（コンストレイント：承認フロー）
図５は、幾つかの例示の実施形態に従う、承認フローの例を示す流れ図である。承認フローは、支払い要求３２０を送り、送り手３０５に支払い要求３２０に対する承認を与えさせるための規則を含み得る。図５００中の処理は、ブロック５０５で始まり得る。

ブロック５０５では、支払い要求３２０が送り手３０５によって受けられる。支払い要求３２０は、支払いキー４２０に関連する。支払いキー４２０は、セキュリティのために暗号化され得る。支払いキー４２０は、ウェブページリダイレクト、電子メール、ショートメッセージサービス（ＳＭＳ）メッセージ、他を介して送り手３０５に送られ得る。支払いキー４２０は、送り手３０５が支払い要求についての特定の情報を取り出すことを可能とし得る。幾つかの例示の実施形態に対しては、承認フローは、支払い要求３２０に基づく支払いの特定の詳細を示す承認インターフェイスに関連し得る。インターフェイスは、送り手３０５に提示され得る。たとえば、送り手３０５は、インターフェイスに関連するウェブページに導かれ得る。ウェブページは、支払いファシリテータ３１５に関連するウェブサイトの一部であっても良い。送り手は、ログインすることが必要であっても良い。このことはブロック５１０中に示されている。

送り手３０５がログインしたあと、支払い要求３２０についての特定の情報が表示され得る。ブロック５１５では、送り手３０５は、支払い要求３２０をレビューし得る。ブロック５２０では、送り手３０５は承認を与え得る。送り手３０５が承認を与えることを根拠に、処理は完了する。送り手３０５は、支払い要求３２０の開始を引き起すウェブページに導かれて戻り得る。
（コンストレイント：対話型音声応答（ＩＶＲ）承認フロー）
対話型音声応答（ＩＶＲ）は、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して携帯アプリケーション中で使用される技術である。ＩＶＲ承認フローは、送り手３０５の携帯電話を介して送り手３０５から承認を得るために用いられ得る。送り手３０５は、支払いファシリテータ３１５によって確認される送り手電話番号を有する必要があっても良い。幾つかの例示の実施形態に対しては、支払いファシリテータ３１５は、支払いファシリテータ３１５によって以前に登録された送り手電話番号を用いて送り手３０５に電話をする処理ロジックを含み得る。図５中に示されているように、支払い要求３２０および支払いキー４２０は、承認のために送り手３０５に送られ得る。しかしながら、送り手３０５をウェブページに導く代わりに、ＩＶＲシステムは承認を得るために電話で送り手３０５を呼び出し得る。送り手３０５は、個人識別番号（ＰＩＮ）を用い、送り手の電話を介して承認を与え得る。
（コンストレイント：事前承認フロー）
図６は、幾つかの例示の実施形態に従う、事前承認フローの例を示す流れ図である。事前承認フローは、将来の一回または繰り返し払いで提示されるコンストレイントを承認するために用いられ得る。図６００中の処理は、ブロック６０５で始まり得る。ブロック６０５では、事前承認要求が送り手３０５によって受けられる。事前承認要求は、事前承認キー４６５と共に受けられ得る。事前承認キー４６５は、セキュリティのために暗号化され得る。事前承認キー４６５は、ウェブページリダイレクト、電子メール、ショートメッセージサービス（ＳＭＳ）メッセージ、他を介して送り手３０５に送られ得る。

幾つかの例示の実施形態に対しては、事前承認要求に含まれるコンストレイントは、事前承認フローとは別に、送り手３０５と受け手３１０との間における交渉を必要とし得る。幾つかの例示の実施形態に対しては、事前承認フローは、事前承認要求の特定の詳細を示す事前承認インターフェイスに関連し得る。事前承認インターフェイスは、支払いファシリテータ３１５に関連し得て、送り手３０５に提示され得る。たとえば、このことは、ＵＲＬを介して実施され得て、送り手３０５は、ＵＲＬに関連するウェブページに導かれ得る。ウェブページは、支払いファシリテータ３１５に関連するウェブサイトの一部であっても良い。送り手は、ログインすることが必要であっても良い。このことはブロック６１０中に示されている。ブロック６１５では、送り手３０５は、事前承認要求３２０をレビューし得る。ブロック６２０では、送り手３０５は事前承認を与え得る。事前承認を有することは、受け手３１０が、支払い要求を提出する必要なく、将来の支払いを受けることを許容する。

幾つかの例示の実施形態に対しては、送り手３０５によって与えられた事前承認は、送り手３０５によってキャンセルされ得る。このことは、支払いファシリテータ３１５の事前承認管理インターフェイスを介して実施され得る。事前承認管理インターフェイスは、送り手３０５によって与えられる全ての事前承認を一覧にし得る。事前承認管理インターフェイスは、送り手３０５に一つ以上の事前承認を選択しキャンセルすることを可能にし得る。

事前承認フローは、承認フェーズが支払いフェーズの前に起こるが故に、および、単一の事前承認が複数の支払いに適用され得るが故に、通常の承認フローとは異なり得る。事前承認フローは多くの異なる支払いシナリオ（たとえば、分割支払い、チェックアウト、送金支払い、他）に適用され得る。以下は、事前承認フローが適用され得る幾つかのコンストレイントの例示である：
−実行毎の最大量
−全実行（和）に対する最大量
−本事前承認が支払いを処理するために用いられ得る全回数
−使用の頻度（一日毎、月毎、および年毎）
−満了日
−（電子メールアドレスによる）受け手の特定
−料金を支払うための送り手または受け手の特定最大量および満了日パラメータは、事前承認フローに関連する支払取引に含まれるリスクを軽減するために用いられ得る。
（送金アプリケーション）
図７は、幾つかの例示の実施形態に従う、本支払いアプリケーションフレームワークを用いる送金シナリオの例を示している。本シナリオでは、送り手３０５は、送り手のアカウントから支払いファシリテータを用いて受け手３１０に送金するために支払取引を開始したい。送金シナリオはしばしば、ピアトゥピア処理に係わり、事前承認を必要としても良いし、しなくても良い。

ブロック７０５では、送り手３０５は支払い要求を提出する。送り手３０５は、支払い要求を提出するために支払いファシリテータ３１５にアクセスする必要があるかも知れない。本例では、送り手３０５は、実際のアカウントの所有者、または送り手３０５の代わりにアカウントにアクセスする権利を有する誰かであり得る。支払いファシリテータ３１５は、支払い要求を処理し、支払いキーを生成する。

送金シナリオの例は、公共料金の請求書に対するオンライン支払いをすることを含み得る。支払いフェーズの間、公益事業会社（受け手）のウェブサイトを訪問する人（送り手）は、公共料金の請求書に対する支払いをする。公益事業会社のウェブサイトは、支払いファシリテータに対して、支払いの詳細と共にプログラム呼び出し（支払い要求）をする。支払いキーが生成される。支払いキーは、公益事業会社に対して送られ得る。承認フェーズの間、人は支払いキーおよびリダイレクトＵＲＬをパラメータとして用いて公益事業会社のウェブサイトから支払いファシリテータ（たとえば、ＰａｙＰａｌ）のウェブサイトにリダイレクトされる。人は、承認フローを行うことで、支払いを承認する。人は次に、ＵＲＬパラメータを用いて公益事業会社のウェブサイトにリダイレクトされ戻される。支払いは、よって、人のアカウントから公益事業会社のアカウントに移転される。公益事業会社のアカウントは支払いファシリテータを備えていても良い。

本例は、送金シナリオをカバーし、よっていかなる準備資金機能を実施する必要がないかも知れないことを留意し得る。しかしながら、もし準備資金機能が要求されるなら、本情報は、支払い要求の中に含まれるであろう。準備資金はよって、承認が与えられた後で実施されるであろう。次に、再徴収機能が、支払いファシリテータを用いて資金を人のアカウントに移転するために実施される必要があり得る。

公益事業会社はまた、支払いの状況をチェックするために、支払い状況機能を用いたいかもしれない。これは、支払いファシリテータにもう一回プログラム呼び出しを行い、支払い状況をチェックすることにより実施され得る。プログラム呼び出しは、支払いキーをパラメータとして含み、プログラム呼び出しからの返却ステータスは承認情報および資金移転（転送）情報を含み得る。通知オプションが支払い要求に含まれているなら、支払い通知は、公益事業会社のウェブサイトに送られ得る。

ある状況では、送金シナリオは、事前承認フローに係わり得る。これらのシナリオは、事前承認送金と呼ばれ得る。これは、送り手が事前承認と、制限つきで将来、送り手のアカウントから送金する権利を与えることにより生じ得る。送り手３０５は、支払いのコンストレイントと共に事前承認要求を生成し、支払いファシリテータ３１５に要求を送り得る。続いて、事前承認キーは、支払いファシリテータ３１５によって生成され、送り手３０５は、事前承認支払いに対する取り決めを見るために、および生成するために事前承認フローを行う。次に、送り手３０５（または送り手の代理をする誰か）は、支払い要求を提出し、事前承認キーとともに、支払い要求を支払いファシリテータ３１５に送り得る。送り手が承認を与えることに基づき、支払いは移転される。通知はまた、支払いが移転したときに、送り手３０５に通知するために支払い要求中に含まれ得る。
（チェックアウトアプリケーション）
図８は、幾つかの例示の実施形態に従う、本支払いアプリケーションフレームワークを用いるチェックアウトシナリオの例を示している。チェックアウトシナリオは、通常は受け手３１０によって始められるので、送金シナリオとは異なり得る。チェックアウトシナリオは、マーチャントフローまたはイーコマース処理と呼ばれることもある。チェックアウトシナリオと送金シナリオの間におけるもうひとつの違いは、送金シナリオは、チェックアウトシナリオほど送り手３０５と受け手３１の間の相互作用を含まないことである。チェックアウトシナリオでは、デジタル商品またはすぐに出荷することが可能な商品のいずれかが入手可能であると仮定される。

このシナリオでは、消費者（送り手３０５）は小売商（受け手３１０）に小売商のウェブサイトで、消費者が購入をしたいことを表し得る。一般的な例としては、消費者が小売商のウェブサイト上で買い物かごを満たすこと、およびチェックアウトかごを選択することを含むだろう。小売商は次に、ブロック８０５に示されているように、支払い要求を生成し、それを支払いファシリテータ３１５に送る。

ブロック８１０では、支払いファシリテータ３１５から支払いキーを受ける。小売商は次に、ブロック８１５中に示されているように、支払いキーをパラメータとして、支払いファシリテータ３１５のウェブサイトに消費者をリダイレクトする。消費者は、ブロック８２０中に示されているように、承認フローを行うことで、支払いを承認する。資金は次に、ブロック８２５中に示されているように、小売商に移転される。

ある状況では、チェックアウトシナリオは、事前承認チェックアウトと呼ばれる、事前承認フローと係わり得る。これは、消費者（送り手）および小売商（受け手）が、たとえば、小売商のウェブサイト上のフォームに必要事項を書き入れることによって、事前承認シナリオに同意すると、生じる。小売商はその後、支払いのコンストレイントとともに事前承認要求を生成し、次にそれを支払いファシリテータ３１５に送る。支払いファシリテータ３１５から事前承認キーを受ける。消費者は次に、支払いファシリテータ３１５にリダイレクトされ、事前承認フローを行う。消費者は次に、事前承認支払いへの同意書を見て、生成する。引き続き、小売商は、支払い要求を生成し、支払いのために、事前承認キーとともに支払い要求を支払いファシリテータ３１５に送り得る。支払いキーは支払いファシリテータ３１５によって小売商に送られ得る。
（分割支払い）
図９Ａ〜９Ｂは、幾つかの例示の実施形態に従う、分割支払いシナリオの例を示している。分割支払いシナリオは、一つの支払いを複数の受け手の間で分割する可能性を提供する。この状況では、複数の支払取引が存在し得るが、支払いキーはひとつだけである。分割支払いシナリオは、（図９Ａ中に示されている）並行支払いシナリオおよび（図９Ｂ中に示されている）連鎖支払いシナリオを含み得る。

図９Ａを参照すると、一つの支払い要求は一人の送り手９０５から複数の受け手９２０〜９３０に資金を移転するために用いられ得る。この例では、３人の受け手９２０、９２５、９３０が存在するので、３つの別々の処理が存在し得る。並列支払いでは、主たる受け手を指定する必要がないかも知れない。送り手９０５または任意の受け手９２０〜９３０が、支払い要求を始めることができる。このことは、一つの受け手が確保した資金機能を用いて支払い要求をしたいが、一つの受け手がキャプチャ機能を用いるように指定されているときに有利である。送り手が支払い要求をレビューし、承認を与えるときには、並行支払い内の全てのセグメントまたは取引は、承認のために送り手９０５から見ることができることが必要であろう。したがって、受け手９２０〜９３０は、全ての並列支払いシナリオに対する最終販売責任を持つ小売商である。

並列支払いシナリオの例は、ショッピングモール内の複数の売り手からの商品／サービスを購入し、一つのチェックアウトフローでその商品／サービスに対する支払いをする消費者を含む。送り手９０５（消費者）は、支払いファシリテータ９３５にリダイレクトされ、係わりのある複数の受け手９２０〜９３０（売り手）が存在したとしても一つの承認を与える必要だけがあり得る。承認が送り手９０５によって与えられると、資金はそれぞれの受け手９２０〜９３０に移転され得る。複数の受け手がいる並行支払いシナリオでの承認フローは、一つの受け手に対する承認フローと同一の動作（たとえば、支払い要求、支払いキー、リダイレクト、承認、および支払い）を含み得ることに留意しても良い。違いは、並列支払いシナリオでは、支払いは３つの受け手に分割されることである。受け手９２０〜９３０のそれぞれにいくら支払うのか、の詳細は支払い要求のパラメータに含まれても良く、特定の売り手から購入される品目のコストに基づく。受け手９２０〜９３０の一人がある品目をキャンセルする必要がある状況では、キャンセルされる品目に関連する金額に対する払い戻しが実施される。支払取引の一つが失敗する（たとえば、不十分な資金によって）状況では、次に不履行動作は、全ての支払取引を取り消すまたは取り下げることを含み得る。

図９Ｂを参照すると、連鎖支払いシナリオは、払い戻し、手数料、および資金流動を取り巻く特定の状況ゆえに、並列支払いシナリオと異なり得る。これは、資金の主たる受け手への移動は、資金が追加の受け手に送られる前に起こる必要があり得るからである。連鎖支払いシナリオは、支払取引に対する全ての資金を最初に受け取る主たる受け手９４０を含み得る。支払取引が完了したあと、資金は次に、一つ以上の副たる受け手のアカウントに移動される。幾つかの例示の実施形態に対しては、連鎖支払いシナリオは、追加の受け手９４５〜９５０からなる一つのグループに送る一つの主たる受け手９４０だけを有しても良い。幾つかの例示の実施形態に対しては、任意の所与の支払い要求に受け手の数（主たるおよび副たる受け手）に限定が置かれても良い。連鎖支払いシナリオでの支払取引の送り手９０５は、承認フローおよび任意の支払取引履歴では、主たる受け手９４０のみを見ることができればよい。したがって、主たる受け手９４０は、全ての連鎖支払いシナリオに対する最終販売責任を持つ小売商である。

連鎖支払いシナリオの例は、サービス提供者の代わりに資金を受けるブローカーを含む。ブローカーは、主たる受け手９４０であり、サービス提供者は副たる受け手９４５〜９５０である。ブローカーの例は、飛行機部分、ホテル部分、イベント部分他を含む旅行パッケージの全ての面に対して授権を与えるＴｒａｖｅｌｏｃｉｔｙ．ｃｏｍであっても良い。これらの部分の各々は、異なるサービス提供者に関連し得る。副たる受け手９４５〜９５０は、自分たちのアカウントに資金を移転するために、主たる受け手９４０のサードパーティーへ自分たちのアカウントへのアクセスを提供する必要があり得る。このことはまた、主たる受け手に、副たる受け手９４５〜９５０の代わりに送り手９０５に払い戻しをすることを許容し得る。

支払いフェーズの間、送り手９０５（消費者）は、主たる受け手９４０（たとえば、Ｔｒａｖｅｌｏｃｉｔｙ．ｃｏｍ）のウェブサイトを訪問する。送り手９０５は、副たる受け手９４５〜９５０によって提供されるサービス（たとえば、ホテル、車のレンタル、飛行保険、ツアーパッケージ、他）を含むパッケージを選択する。主たる受け手９４０は、支払い要求を生成し、支払い要求を支払いファシリテータ９３５に送る。支払いキーが生成され、支払いファシリテータ９３５によって主たる受け手９４０に提供される。

承認フェースの間、主たる受け手９４０は送り手９０５を支払いファシリテータ９０５にリダイレクトする。送り手９０５は、支払い要求をレビューし、承認フローに基づいて承認を与える。支払いキーは、主たる受け手９４０のウェブサイトに戻るためにリダイレクトＵＲＬとともに送られる。送り手９０５が支払いを承認すると、送り手９０５は、リダイレクトＵＲＬを用いて主たる受け手９４０のウェブサイトにリダイレクトされ戻される。次に資金が送り手のアカウントから主たる受け手９４０のアカウントに移転される。そして、資金は、主たる受け手９４０のアカウントから副たる受け手９４５〜９５０のアカウントに送られる。これらのアカウントの全ては、支払いファシリテータ９０５に関連し得る。
（コンピュータシステム）
図１０は、本明細書中で議論される任意の一つ以上の方法を機械に実行させる命令の組が実行され得るコンピュータシステム１０００の形態での機械の図表示を示している。代替の実施形態では、機械は、スタンドアロンデバイスとして動作しても良いし、他の機械に接続（たとえば、ネットワーク）されていても良い。ネットワーク配置では、機械は、サーバ−クライアントネットワーク環境においてはサーバまたはクライアントマシンの機能で動作し、ピアトゥピア（または分散）ネットワーク環境においてはピアマシンとして動作し得る。機械は、サーバコンピュータ、クライアントユーザコンピュータ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、パーソナルデジタルアシスタント（ＰＤＡ）、携帯電話、携帯デバイス、パームトップコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、パーソナルデジタルアシスタント、通信デバイス、無線電話、固定電話、コントロールシステム、カメラ、スキャナ、ファクシミリ機、プリンター、テレビ、テレビケーブルページャ、パーソナルトラスティッドデバイス、ウェブアプライアンス、ネットワークルータ、スイッチまたはブリッジ、またはその機械によって行われる動作を特定する（逐次のまたは他の）命令の組を実行することが可能な任意の機械であり得る。

さらに、一つの機械が示されているが、用語“機械”はまた、本明細書中で議論される任意の一つ以上の方法を実施するために電気的にコーディングされた命令の組（複数の組）を個々に、または連結して実行する任意の機械の集合を含むように用いられるであろう。

例示のコンピュータシステム８００は、互いにバス８０８によって通信される、プロセッサ１００２（たとえば、中央処理装置（ＣＰＵ）、グラフィックプロセッシングユニット（ＧＰＵ）、または両方）、メインメモリ１００４およびスタティックメモリ１００６を含む。コンピュータシステム１０００はさらに、ビデオ表示ユニット１０１０（たとえば、液晶ディスプレイ（ＬＣＤ）またはブラウン管）を含み得る。コンピュータシステム１０００はまた、入力デバイス１０１２（たとえば、キーボード）、カーソルコントロールデバイス１０１４（たとえば、マウス）、ディスクドライブユニット１０１６、信号生成デバイス１０１８（たとえば、スピーカ）およびネットワークインターフェイスデバイス１０２０を含む。

ディスクドライブユニット１０１６は、本明細書中に記載された任意の一つ以上の方法または機能を具体化する電気的にコーディングされた命令のひとつ以上の組を記憶する機械読み取り可能媒体１０２２を含む。命令１０２４はまた、それらがコンピュータシステム１０００によって実行される間、メインメモリ１００４、スタティックメモリ１００６、および／またはプロセッサ１００２中に、完全にまたは少なくとも部分的に存在しても良い。メインメモリ１００４およびプロセッサ１００２はまた、機械読み取り可能媒体を構成し得る。

命令１０２４はさらに、ネットワークインターフェイスデバイス１０２０を介してネットワーク１０２６上で送信または受信され得る。

様々な実施形態の装置およびシステムを含み得るアプリケーションは、様々な電気的およびコンピュータシステムを広く含む。幾つかの実施形態では、相互に接続された二つ以上の特定のハードウェアモジュールまたはデバイス中の機能を、モジュール間でおよびモジュールを介して通信される関連する制御およびデータ信号とともに、またはアプリケーション専用集積回路の一部として、実施する。

機械読み取り可能媒体１０２２は例示の実施例中に一つの媒体として示されているが、用語“機械読み取り可能媒体”は、一つ以上の命令の組を記憶する一つのまたは複数の媒体（たとえば、集中または分散データベース、および／または関連するキャッシュおよびサーバ）を含むように用いられるであろう。用語“機械読み取り可能媒体”はまた、機械によって実行するための命令の組を記憶、コード化、または運ぶことができ、機械に本発明の任意の一つ以上の方法を実施させる任意の媒体を含むように用いられるであろう。用語“機械読み取り可能媒体”はしたがって、限定はされないが、固体メモリ、光学的または磁気的媒体、および搬送波信号を含むように用いられるであろう。

本明細書中に記載された例示の実施形態は、様々な実施形態の構成の全般的な理解を与えることを意図とし、本明細書中に記載された構成の使用をし得る装置およびシステムの全構成要素および特徴の完全な記載として役立つことは意図されていない。多くの他の実施形態は上の記載をレビューした当業者には明らかであろう。他にも複数の実施形態が利用され、本明細書中に記載された例示の実施形態から導かれ得るが、本開示の範囲から逸脱することなく構成的および論理的置き換えおよび変更がなされ得る。図１乃至１０は、単に具体例に過ぎず、一定の比率の縮尺で描かれてはいないかも知れない。その特定の部分は、他の部分が過小化されている一方で、誇張されているかも知れない。

本発明は特定の例示の実施形態を参照しつつ記載されているが、本発明の最も広く解釈された精神および範囲から逸脱することなく、これらの実施形態に様々な修正および変更がされて得たことは明らかであろう。したがって、明細書および図面は、限定的な意味ではなくむしろ、例示としてみなされるべきである。

記載は、記述的な目的のみに用いられ、限定としての構成要素とはならない、“上”、“下”、“上のほう”、“下のほう”、“第一の”、“第二の”他のような用語を含む。構成要素、物質、幾何形状、大きさ、および動作の順序は、特定のアプリケーションに適するようにすべて変更され得る。幾つかの実施形態の一部は、他の実施形態の一部に含まれ得るし、置き換えられ得る。大きさおよび範囲の例は典型的なものであると考えられるが、様々な実施形態はそのような大きさまたは範囲には限定されない。

要約は読者が技術的開示の特性および要旨を容易に理解することができるために、３７Ｃ．Ｆ．Ｒ．１．７４（ｂ）に応じて提供される。要約はクレームの要旨または意味を解釈するまたは限定するために用いられないだろうことを理解していることを申し述べる。詳細な記載では、開示の簡略化の目的のために一つの実施形態に、様々な特徴が一まとまりにされている。この開示の方法は、クレームされた実施形態は、各請求項に明確に引用された以上の特徴を有するという意図を反映していると解釈されるべきではない。よって、以下のクレームはここに、詳細な記載中に組み込まれ、各クレームはそれ自身、別個の実施形態である。

１００ システム
１１２ ネットワークベースシステム
１１４ ネットワーク
１１６ ウェブクライアント
１１７ デバイスアプリケーション
１１８ プログラマティッククライアント
１２０、１２１、１２２ クライアントマシン
１２４ ＡＰＩサーバ
１２６ ウェブサーバ
１２８ アプリケーションサーバ
１３０ マーケットプレイスアプリケーション
１３２ 支払いアプリケーション
１３４ データベースサーバ
１３６ データベース
１４０ 公表アプリケーション
１４２ オークションアプリケーション
１４４ 固定価格アプリケーション
１４６ ストアアプリケーション
１４８ 評判アプリケーション
１５０ パーソナル化アプリケーション
１５２ 国際化アプリケーション
１５４ ナビゲーションアプリケーション
１５６ 画像アプリケーション
１５８ リスト生成アプリケーション
１６０ リスト管理アプリケーション
１６２ 投稿リスト管理アプリケーション
１６４ 紛争解決アプリケーション
１６６ 不正防止アプリケーション
１６８ メッセージアプリケーション
１７０ マーチャンダイジングアプリケーション
１７２ ロイヤリティ販売促進アプリケーション
１７４ 支払フレームワークアプリケーション
１８０ テーブル
１８１ ユーザテーブル
１８２ 品目テーブル
１８３ 取引テーブル
１８４ フィードバックテーブル
１８５ 履歴テーブル
１８６ 属性テーブル
１８７ 注文テーブル
１８８ ビッドテーブル
１９０ 支払いフレームワークテーブル
１９１ メタファー
１９２ オブジェクト
１９３ コンストレイント
２００ 支払いアプリケーションフレームワーク
２０５ コンストレイントライブラリ
２１０ メタファライブラリ
２１５ カスタマイズされた情報
２２０ 支払いアプリケーション
３０５ 送り手
３１０ 受け手

Claims (18)

1. 支払いファシリテータで要求を受信することであって、前記要求は、送り手から１つ以上の受け手への値の転送を示す支払い取引に関連付けられている、ことと、
   前記支払いファシリテータで前記要求を処理することであって、前記処理することは、前記要求に対応する支払いキーを生成することを含み、前記支払いキーは前記送り手による前記要求の承認に使用される、ことと、
   前記送り手のクライアントマシンを、前記支払いキーをパラメータとして、前記支払いファシリテータの承認インターフェイスへと導くことと、
   前記送り手から前記承認インターフェイスを介して前記承認を受信したことに応答して、前記支払いファシリテータに前記支払い取引を完了させることと、
   を含む方法。
2. 前記支払いファシリテータに前記支払い取引を完了させることは、前記支払いファシリテータに、前記支払いファシリテータによって処理された前記要求に基づき、前記送り手のアカウントからの１つの支払いを、前記１つ以上の受け手の少なくとも１つのそれぞれのアカウントへ直接転送させることを含む、請求項１に記載の方法。
3. 前記少なくとも１つのそれぞれのアカウントで受信された前記１つの支払いの第１の部分を、前記要求に基づき、第２の受け手の少なくとも１つのアカウントへ転送することを更に含む、請求項２に記載の方法。
4. 前記１つの支払いの第２の部分が前記少なくとも１つのそれぞれのアカウントに残っている、請求項３に記載の方法。
5. 前記クライアントマシンを承認インターフェイスへと導くことは、
   前記支払いキーに基づき、前記要求に関連付けられた詳細にアクセスすることと、
   前記要求に関連付けられた前記詳細を、前記送り手による検討及び承認のために表示させることと、
   を含む、請求項１に記載の方法。
6. 前記クライアントマシンを前記承認インターフェイスへと導くことは、前記クライアントマシンを、前記１つ以上の受け手のうちの１つの受け手に関連付けられたウェブサイトから、前記支払いファシリテータに関連付けられた前記承認インターフェイスへと導くことを含む、請求項１に記載の方法。
7. 前記承認を受信した後、前記クライアントマシンを、前記１つ以上の受け手のうちの前記１つの受け手に関連付けられた前記ウェブサイトへとリダイレクトして戻すことを更に含む、請求項６に記載の方法。
8. 前記支払いキーを送信することを更に含み、前記送信することは、ウェブページリダイレクト、電子メール、又はショートメッセージサービス（ＳＭＳ）メッセージのうちの１つを含む、請求項１に記載の方法。
9. 前記１つ以上の受け手のうちの１つの受け手からプログラム呼び出しを受信することであって、前記プログラム呼び出しは前記支払いキーを含む、ことと、
   前記受け手にステータスを戻すことと、
   を更に含む、請求項１に記載の方法。
10. 前記ステータスは承認情報又は資金転送情報を含む、請求項９に記載の方法。
11. 機械の少なくとも１つのプロセッサによって実行された場合に前記機械に動作を実行させる命令を格納する機械読み取り可能な記憶デバイスであって、前記動作は、
    支払いファシリテータで要求を受信することであって、前記要求は、送り手から１つ以上の受け手への値の転送を示す支払い取引に関連付けられている、ことと、
    前記支払いファシリテータで前記要求を処理することであって、前記処理することは、前記要求に対応する支払いキーを生成することを含み、前記支払いキーは前記送り手による前記要求の承認に使用される、ことと、
    前記送り手のクライアントマシンを、前記支払いキーをパラメータとして、前記支払いファシリテータの承認インターフェイスへと導くことと、
    前記送り手から前記承認インターフェイスを介して前記承認を受信したことに応答して、前記支払いファシリテータに前記支払い取引を完了させることと、
    を含む、機械読み取り可能な記憶デバイス。
12. 前記支払いファシリテータに前記支払い取引を完了させることは、前記支払いファシリテータに、前記支払いファシリテータによって処理された前記要求に基づき、前記送り手のアカウントからの１つの支払いを、前記１つ以上の受け手の少なくとも１つのそれぞれのアカウントへ直接転送させることを含む、請求項１１に記載の機械読み取り可能な記憶デバイス。
13. 前記動作は、前記少なくとも１つのそれぞれのアカウントで受信された前記１つの支払いの第１の部分を、前記要求に基づき、第２の受け手の少なくとも１つのアカウントへ転送することを更に含む、請求項１２に記載の機械読み取り可能な記憶デバイス。
14. 前記クライアントマシンを承認インターフェイスへと導くことは、
    前記支払いキーに基づき、前記要求に関連付けられた詳細にアクセスすることと、
    前記要求に関連付けられた前記詳細を、前記送り手による検討及び承認のために表示させることと、
    を含む、請求項１１に記載の機械読み取り可能な記憶デバイス。
15. 前記クライアントマシンを前記承認インターフェイスへと導くことは、前記クライアントマシンを、前記１つ以上の受け手のうちの１つの受け手に関連付けられたウェブサイトから、前記支払いファシリテータに関連付けられた前記承認インターフェイスへと導くことを含む、請求項１１に記載の機械読み取り可能な記憶デバイス。
16. 前記動作は、前記支払いキーを送信することを更に含み、前記送信することは、ウェブページリダイレクト、電子メール、又はショートメッセージサービス（ＳＭＳ）メッセージのうちの１つを含む、請求項１１に記載の機械読み取り可能な記憶デバイス。
17. 前記動作は、
    前記１つ以上の受け手のうちの１つの受け手からプログラム呼び出しを受信することであって、前記プログラム呼び出しは前記支払いキーを含む、ことと、
    前記受け手にステータスを戻すことと、
    を更に含む、請求項１１に記載の機械読み取り可能な記憶デバイス。
18. 命令を格納する機械読み取り可能な記憶媒体と、
    前記機械読み取り可能な記憶媒体に格納された前記命令によって動作を実行するように構成された１つ以上のプロセッサと、
    を含むシステムであって、前記動作は、
    要求を受信することであって、前記要求は、送り手から１つ以上の受け手への値の転送を示す支払い取引に関連付けられている、ことと、
    前記要求を処理することであって、前記処理することは、前記要求に対応する支払いキーを生成することを含み、前記支払いキーは前記送り手による前記要求の承認に使用される、ことと、
    前記送り手のクライアントマシンを、前記支払いキーをパラメータとして、支払いファシリテータの承認インターフェイスへと導くことと、
    前記送り手から前記承認インターフェイスを介して前記承認を受信したことに応答して、前記支払いファシリテータに前記支払い取引を完了させることと、
    を含む、システム。