JP2016532963A - 電子商取引の支払を容易に行わせる方法およびシステム - Google Patents

Abstract

金銭取引を容易に行わせる方法は、精算プロセスの容易性および速度の促進あるいは向上を含む。特に、１つまたは複数の実施態様は、商取引アプリケーションと支払ゲートウェイとの間の仲介手段として作用する電子商取引支払ファシリテータを含む。電子商取引支払ファシリテータは、ユーザによる少数の簡単な選択に基づいて、記憶された支払情報を商取引アプリケーションに提供可能である。これによりユーザは、商取引を簡単かつ安全に完了できるため、ユーザの精算作業が簡素化されるとともに、購入障壁が低くなる。さらに、電子商取引支払ファシリテータは、商取引アプリケーションの支払ゲートウェイに対して、支払明細を受け渡すことができる。上記のほか、方法は、ネットワークアプリケーションより記憶された支払情報を使用するオプションのユーザへの動的かつ知的な提供を含む。

Description

本発明の１つまたは複数の実施形態は、一般的には支払処理に関する。より詳細には、本発明の１つまたは複数の実施形態は、電子商取引アプリケーションを用いた支払の容易さを増大するシステムおよび方法に関する。

商取引アプリケーションによれば、ユーザは、通信ネットワーク上で現実世界の金銭取引を行うことができる。商取引アプリケーションの例としては、ウェブサイトおよびネイティブアプリケーションが挙げられる。商取引アプリケーションによれば、ユーザは、仮想買い物かごおよび精算プロセスを用いて、商品および／またはサービスを購入することができる。精算プロセスには、支払情報（クレジットカードまたはデビットカード情報等）を商取引アプリケーションへ提供することで注文の完了となることがある。通常、支払情報の提出後、商取引アプリケーションは、支払ゲートウェイを用いることによって、支払許可を取得するとともに、支払プロセッサに対して支払情報を安全に受け渡す。

商取引アプリケーションによれば、買い物を容易化可能であるとともに、ユーザは、実店舗を訪れることなく買い物することができるものの、多くの商取引アプリケーションの精算プロセスは、不便な可能性がある。たとえば、商取引アプリケーションでは通常、ユーザが詳細な支払情報を提供する必要がある。ユーザは、最大２０個の情報フィールドに入力することが必要となる場合が多い。一般的に、商取引精算プロセスを利用する潜在的消費者は、支払情報の入力が困難であるか、時間がないか、または疑問を持ち、あるいは、精算プロセスに苛立ちを感じる。このような苛立ちにより、潜在的消費者は、その商取引を断念することが多い。商取引精算プロセスに対する苛立ちは、モバイルデバイスを使用する際に増すことが多い。画面が小さく、大量の情報を打ち込むのが困難なためである。

精算プロセスに伴う問題を軽減するため、いくつかの商取引アプリケーションによれば、ユーザは、「口座（アカウント）」を作成することによって、一旦、支払情報を商取引アプリケーションに提供すれば、上記支払情報をアプリケーションに保存して後々使用することができる。たとえば、ユーザは、最初の購入時に、支払情報と併せてユーザ名およびパスワードを提供するようにしてもよく、支払情報は、ユーザに関連付けられている「口座」に保存される。上記商取引ウェブサイトを次に訪れた際、ユーザは、ユーザ名およびパスワードの組み合わせを入力してそれらの口座にアクセスし、支払情報の再入力を求められることなく、さらに買い物するようにしてもよい。これは、精算プロセスで生じる煩雑さの一部を抑えるのに役立つが、このようなシステムでは、商取引アプリケーションがクレジットカード業界（「ＰＣＩ」）準拠であることが求められるとともに、通常は、単一のウェブサイトにおいて有効であるに過ぎない。

上記問題を考慮して、いくつかの商取引アプリケーションは、「仮想財布」サービスを提供するサードパーティと一体化しており、ＰａｙＰａｌ（商標）およびＧｏｏｇｌｅ Ｗａｌｌｅｔ（商標）支払サービス等が挙げられるが、これらに限定されない。これらの仮想財布サービスによれば、ユーザは、２つ以上の商取引アプリケーションで使用可能な支払情報を記憶した口座を作成可能である。通常、商取引アプリケーションは、精算の途中で、仮想財布認証情報の入力および／または記憶された支払情報の見直しが可能な仮想財布サービスのページへのユーザのリダイレクトを可能とすることにより、このような仮想財布サービスと「一体化」する必要がある。仮想財布サービスは、金融ネットワークを用いて金銭的精算自体を行った後、商取引アプリケーションを提供している業者の口座を
信任する。仮想財布手法は、いくつかの利点をもたらし得るが、多くの商取引アプリケーションでは、仮想財布サービスとの明示的な一体化または仮想財布サービスによる支払ゲートウェイを通じた取引の実行を望んでいない。また、仮想財布サービスを伴う精算プロセスは、分かりにくく、困惑を招く可能性が高い。商取引アプリケーションで買い物をしようとしているユーザは、仮想財布サービスを用いて取引を完了するため、全く異なるウェブサイトへと突然リダイレクトされるからである。

上記のほか、仮想財布では通常、商取引アプリケーションが仮想買い物かごごとに「仮想財布で購入」ボタンを表示する必要がある。ほとんどのユーザは仮想財布を事前登録していないため、この表示は分かりにくく、未登録ユーザが従来の商取引で買い物しようとしている際に誤って仮想財布の「購入」ボタンを選択してしまった場合には、買い物かごを放棄する可能性がある。「仮想財布で購入」ボタンの配置が必要となる不都合は、画面スペースが重要となるモバイル商取引アプリケーションにおいて顕著になることが多い。

以上から、商取引精算および支払処理においては、考慮すべきことが非常に多い。

本発明の第１の実施形態に係る方法は、ユーザ識別情報を含む要求および購入のために選択した１つまたは複数の商品またはサービスに関する商取引アプリケーションからのクレジット払い額を受信するステップと、ネットワークアプリケーションを実行する１つまたは複数のサーバコンピューティングデバイスにより、非一時的記憶媒体に記憶されたユーザの支払カード明細を参照する支払トークンを生成するステップと、ネットワークアプリケーションを実行する１つまたは複数のサーバコンピューティングデバイスにより、支払トークンを商取引アプリケーションに送信するステップと、支払トークンを含むクレジット払い要求を商取引アプリケーションから受信するステップと、支払トークンの受信に応答して、ネットワークアプリケーションを実行する１つまたは複数のサーバコンピューティングデバイスが、商取引アプリケーションに関連付けられている支払ゲートウェイシステムに支払のクレジット払い要求を送信するステップであって、上記支払のクレジット払いは、支払カード明細、クレジット払い額、および商取引アプリケーションに代わってクレジット払い要求を提出する許可を示す標識を含む、ステップとを含む。

この方法の一実施形態において、商取引アプリケーションから要求を受信するステップは、１つまたは複数の支払フィールドを自動的に埋めることを可能とするためのユーザの支払情報を求めるグラフＡＰＩに対するクライアントサイドの呼び出しを受信することを含む。この方法は、ユーザの支払情報を商取引アプリケーションに送信して、商取引アプリケーションが１つまたは複数の支払フィールドを自動的に埋めることを可能とするステップをさらに含み、支払情報は、支払カードラベル、有効期限、氏名、および請求先住所を含むのが好ましい。特に、この方法はユーザの支払情報を商取引アプリケーションに送信する前に、支払情報を商取引アプリケーションに提供する許可をユーザから受信するステップをさらに含む。

本発明の別の態様によれば、この方法は、支払ゲートウェイシステムから取引識別子を受信するステップと、取引識別子を商取引アプリケーションに送信するステップと、をさらに含む。

本発明のさらに別の態様によれば、この方法は、変換関数をユーザのＩＤに適用することによって、ユーザのＩＤをネットワークアプリケーションのユーザのユーザ識別情報にマッピングするステップをさらに含む。

この方法の別の実施形態において、商取引アプリケーションに代わってクレジット払い
要求を提出する許可を示す標識を送信するステップは、支払ゲートウェイシステムから商取引アプリケーションに提供された秘密鍵を用いて支払のクレジット払い要求の少なくとも一部を暗号化することを含む。

さらに別の実施形態において、この方法は、支払のクレジット払い要求を支払ゲートウェイシステムに送信する前に、商取引アプリケーションに関連付けられているサーバコンピューティングデバイスにクレジット払い要求が由来することを検証するステップを含む。

本発明に係る別の実施形態においては、商取引アプリケーションの少なくとも第１の部分を実行するクライアントコンピューティングデバイスから、ネットワークアプリケーションを実行する１つまたは複数のサーバコンピューティングデバイスに情報要求を送信するステップであって、上記要求が、ユーザ識別情報およびユーザが購入のために選択した注文に対するクレジット払い額を含むステップと、１つまたは複数のサーバコンピューティングデバイスから、支払カードラベル、支払トークン、およびユーザの支払情報を受信するステップと、少なくとも１つのプロセッサを用いて、精算ユーザインターフェースの支払フィールドを、支払カードラベルおよびユーザの支払情報により自動的に埋めるステップと、クレジット払い要求を１つまたは複数のサーバコンピュータに送信するステップであって、クレジット払い要求が、支払トークンを含む、ステップと、を含む方法が提供される。

一実施形態において、情報要求を１つまたは複数のサーバコンピューティングデバイスに送信するステップは、ネットワークアプリケーションのグラフＡＰＩを呼び出すことを含む。

別の実施形態において、支払トークンを１つまたは複数のサーバコンピューティングデバイスに送信するステップは、商取引アプリケーションの少なくとも第２の部分を実行するサーバコンピューティングデバイスのネットワークインターフェースからネットワークアプリケーションの支払ＡＰＩを呼び出すことを含む。

さらに別の実施形態において、この方法は、コンピューティングデバイスの共有メモリ領域から商取引アプリケーションにより、ユーザ識別情報にアクセスするステップをさらに含み、ユーザ識別情報は、ネットワークアプリケーションと対話するクライアントネットワークアプリケーションによって共有メモリ領域に初期に記憶されたものである。

この方法は、ネットワークアプリケーションからの支払情報を用いて注文を完了可能であることを示す選択可能な精算オプションのレンダリングを行うステップをさらに含んでいてもよい。

本発明の別の態様によれば、ネットワークアプリケーションを実行する１つまたは複数のサーバコンピューティングデバイスと、非一時的記憶媒体であって、複数のユーザの支払情報を有するプロフィール記憶モジュールであり、各ユーザの支払情報は、ユーザの氏名、支払カード番号、支払カードの有効期限、ユーザの配送先住所、およびユーザの請求先住所のうちの１つまたは複数を含む、プロフィール記憶モジュールと、１つまたは複数のサーバコンピューティングデバイスにより実行された場合に、商取引アプリケーションからの要求を識別するステップであって、上記要求は、商取引アプリケーションの買い物かご中の１つまたは複数の商品またはサービスに対するクレジット払い額を含み、上記１つまたは複数の商品が、ユーザにより選択されたものである、ステップと、ユーザに関連付けられている支払情報を識別するステップと、ユーザに関連付けられている支払カード番号を参照する支払トークンを生成するステップと、支払トークン、カードラベル、およ
びユーザの支払情報を商取引アプリケーションに送信するステップと、商取引アプリケーションから支払トークンを受信した場合に、商取引アプリケーションに関連付けられている支払ゲートウェイシステムに支払のクレジット払い要求を送信することであり、支払要求が、支払カード番号、クレジット払い額、および商取引アプリケーションに代わってクレジット払い要求を提出する許可を示す標識を含む、ステップとを上記システムに行わせる命令とを含む、非一時的記憶媒体とを備えたシステムが提供される。

このシステムの一実施形態において、上記命令は、１つまたは複数のサーバコンピューティングデバイスにより実行された場合に、商取引アプリケーションの買い物かご中の１つまたは複数の商品またはサービスの購入をユーザが完了していないことを判定するステップと、１つまたは複数の商品またはサービスに関する詳細および１つまたは複数の商品またはサービスを購入するオプションを含むメッセージを生成するステップと、上記メッセージをユーザに提供するステップとを上記システムにさらに行わせる。

別の実施形態において、上記命令は、１つまたは複数のサーバコンピューティングデバイスにより実行された場合に、ソーシャルネットワーキングシステムのニュースフィードにおいて上記メッセージをユーザに提供することを上記システムに行わせる。

さらに別の実施形態において、上記命令は、１つまたは複数のサーバコンピューティングデバイスにより実行された場合に、商取引アプリケーションからの要求にて受信したユーザのＩＤに変換関数を適用することによって、ユーザのＩＤをユーザ識別情報にマッピングすることを上記システムにさらに行わせる。

別の実施形態において、上記命令は、１つまたは複数のサーバコンピューティングデバイスにより実行された場合に、支払ゲートウェイシステムから商取引アプリケーションに提供された秘密鍵を用いて支払のクレジット払い要求の少なくとも一部を暗号化することにより、商取引アプリケーションに代わってクレジット払い要求を提出する許可を示す標識を提供することを上記システムにさらに行わせる。

上記方法またはシステムのすべての実施形態において、ネットワークアプリケーションは、ソーシャルネットワーキングシステムを含むのが好ましい。
本発明の実施形態は、商取引の支払および精算プロセスを容易化および効率化する方法およびシステムによって、利益の提供および／または当技術分野における上記もしくは他の問題のうちの１つもしくは複数の解決を図る。特に、１つまたは複数の実施形態は、ユーザの支払情報を提供することによって、精算の不都合および関連する取引の断念を低減するのに役立つ。さらに、上記１つまたは複数の実施形態は、支払ゲートウェイとの既存の関係を用いた商取引アプリケーションによる取引の処理を可能としつつ、この利益をもたらすことができる。

これにより、１つまたは複数の実施形態は、精算中に支払情報を提供するユーザの負担を削減または排除する改良された精算フローの商取引アプリケーションによる提供を可能とすることができる。さらに、この改良された精算フローは、容易に商取引アプリケーションに組み込むことができ、ユーザは、簡単かつ迅速に認証を行うとともに、複数の商取引アプリケーションで商品および／またはサービスの支払を行うことができる。また、１つまたは複数の実施形態は、購入の可能性を高めることが期待される場合に、記憶された支払情報を使用するオプションを知的かつ動的に提供可能である。さらに、記憶された支払情報を使用するオプションによって、購入の可能性を高めることが期待されない場合は、上記オプションを提供せずに、グラフィカルインターフェースの煩雑さを抑えるようにしてもよい。

本発明の例示的な実施形態の別の特徴および利点については、以下の説明において示すとともに、その一部は、上記説明から明らかとなるか、またはこのような例示的な実施形態の実施によって得られる可能性がある。このような実施形態の特徴および利点は、添付の特許請求の範囲において特に挙げられる手段および組み合わせによって実現および取得される可能性がある。これらおよび他の特徴は、以下の説明および添付の特許請求の範囲によって、より完全に明らかとなるか、または以下に示すように、このような例示的な実施形態の実施によって得られる可能性がある。

本発明の１つまたは複数の実施形態に係る、商取引アプリケーションを用いて購入を容易に行わせるシステムを示した模式図。 本発明の１つまたは複数の実施形態に係る、図１のシステムの商取引アプリケーション、ネットワークアプリケーション、および支払ネットワークを示した詳細な模式図。 本発明の１つまたは複数の実施形態に係る、図２の商取引アプリケーション、ネットワークアプリケーション、および支払ネットワーク間の対話を示したシーケンスフロー図。 本発明の１つまたは複数の実施形態に係る、図２の商取引アプリケーション、ネットワークアプリケーション、および支払ネットワーク間の対話を示したシーケンスフロー図。 本発明の１つまたは複数の実施形態に係る、ネットワークアプリケーションにより記憶された支払情報を使用するオプションを動的に提供する方法を示したシーケンスフロー図。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションを用いて金銭取引を完了するユーザインターフェースを示した図。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションを用いて金銭取引を完了するユーザインターフェースを示した図。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションを用いて金銭取引を完了するユーザインターフェースを示した図。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションを用いて金銭取引を完了するユーザインターフェースを示した図。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションを用いて金銭取引を完了するユーザインターフェースを示した図。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションを用いて金銭取引を完了するユーザインターフェースを示した図。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションを用いて金銭取引を完了するユーザインターフェースを示した図。 本発明の１つまたは複数の実施形態に係る、以前に断念した商取引アプリケーションの仮想買い物かごの購入をユーザが完了できるようにする購入メッセージを示した図。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションでの金銭取引を容易に行わせる方法における一連の行為を示したフローチャート。 本発明の１つまたは複数の実施形態に係る、商取引アプリケーションでの金銭取引を容易に行わせる別の方法における一連の行為を示したフローチャート。 本発明の１つまたは複数の実施形態に係る、ネットワークアプリケーションより記憶された支払情報を使用するオプションをユーザに動的かつ知的に提供する方法における一連の行為を示したフローチャート。 本発明の１つまたは複数の実施形態に係る、ネットワークアプリケーションより記憶された支払情報を使用するオプションをユーザに動的かつ知的に提供する別の方法における一連の行為を示したフローチャート。 本発明の１つまたは複数の実施形態に係る、例示的なコンピューティングデバイスを示したブロック図。 本発明の１つまたは複数の実施形態に係る、ソーシャルネットワーキングシステムの例示的なネットワーク環境を示した図。

本発明の上記および他の利点および特徴が得られる様態を説明するため、添付の図面に示す具体的な実施形態を参照することによって、上記概説した本発明をより詳細に説明する。図面は縮尺通りにレンダリングされておらず、図面全体を通して、類似構造または機能の要素は、説明のために同じ参照番号で大略表していることに留意するものとする。以下の図面において、括弧付きテキストおよび破線（たとえば、長破線、短破線、鎖線、点線）の境界付きブロックは、本発明の実施形態に付加的な特徴を追加する任意選択としての特徴または動作を示すために使用している。ただし、このような表記は、これらが唯一の選択肢もしくは任意選択としての動作であることおよび／または実線の境界付きブロックが本発明の特定の実施形態において任意選択ではないことを意味するものと捉えるべきではない。これらの図面が本発明の代表的な実施形態を示しているに過ぎず、その範囲を制限するものと考えるべきではないことを理解することにより、本発明は、添付の図面の使用によって、さらに厳密かつ詳細に記述および説明されることになる。

本発明の１つまたは複数の実施形態は、商取引の支払および精算プロセスを容易化および効率化する。特に、１つまたは複数の実施形態は、ユーザの支払情報を提供することによって、精算の不都合および関連する取引の断念を低減するのに役立つ。さらに、上記１つまたは複数の実施形態は、支払ゲートウェイとの既存の関係を用いた商取引アプリケーションによる取引の処理を可能としつつ、この利益をもたらすことができる。

これにより、１つまたは複数の実施形態は、精算中に支払情報を提供するユーザの負担を削減または排除する改良された精算フローの商取引アプリケーションによる提供を可能とすることができる。さらに、この改良された精算フローは、容易に商取引アプリケーションに組み込むことができ、ユーザは、簡単かつ迅速に認証を行うとともに、複数の商取引アプリケーションで商品および／またはサービスの支払を行うことができる。また、１つまたは複数の実施形態は、購入の可能性を高めることが期待される場合に、記憶された支払情報を使用するオプションを知的かつ動的に提供可能である。さらに、記憶された支払情報を使用するオプションによって、購入の可能性を高めることが期待されない場合は、上記オプションを提供せずに、グラフィカルインターフェースの煩雑さを抑えるようにしてもよい。

特に、本発明の１つまたは複数の実施形態は、商取引アプリケーションと支払ゲートウェイとの間の仲介手段として対話する電子商取引支払ファシリテータを含む。電子商取引支払ファシリテータは、ユーザによる少数の簡単な選択に基づいて、記憶された支払情報を商取引アプリケーションに提供可能である。これによりユーザは、商取引を簡単かつ安全に完了できるため、ユーザの精算作業が簡素化されるとともに、購入障壁が低くなる。さらに、電子商取引支払ファシリテータは、商取引アプリケーションの支払ゲートウェイに対して、支払明細を受け渡すことができる。これにより、電子商取引支払ファシリテータが提供する取引によって、商取引アプリケーションの提供者が対応に慣れている同じチャンネルおよびネットワークを用いた取引への資金提供および精算が可能である。

たとえば、図１は、本発明の一実施形態に係るシステム１００を示した模式図である。以下、図１に関して、システム１００の概要を説明する。その後、他の図面に関して、システム１００の構成要素およびプロセスをより詳細に説明する。

図１に示すように、システム１００は、ユーザ１０２、商取引アプリケーション１０４、電子商取引支払ファシリテータ１０６、および支払ネットワーク１１６を含むことができる。商取引アプリケーションは、電子商取引支払ファシリテータ１０６と対話することにより、商取引アプリケーション１０４でのユーザ１０２の精算作業を簡素化することができる。金銭取引を完了するため、電子商取引支払ファシリテータ１０６は、支払ネットワーク１１６を用いた支払の処理を目的として、支払ゲートウェイシステム１０８と対話してもよい。支払ネットワーク１１６は、支払ゲートウェイシステム１０８、支払処理システム１１０、カードネットワークシステム１１２、および発行銀行システム１１４を備える。ただし、他の実施形態において、支払ネットワーク１１６は、より多数または少数のアクターを備えるが、本発明のほとんどの実施形態において、支払ネットワーク１１６は、少なくとも支払ゲートウェイシステム１０８を備える。以下により詳しく説明する通り、システムの各構成要素は、１つもしくは複数のコンピューティングデバイス上での実行および／または１つもしくは複数のコンピューティングデバイスによる実装が可能である。

図１に示す実施形態は、商取引アプリケーション１０４にアクセスするユーザ１０２を含む。以下により詳しく説明する通り、商取引アプリケーション１０４は、ウェブアプリケーションまたはネイティブアプリケーション等のネットワークアプリケーションを含むことができる。商取引アプリケーション１０４は、商品および／またはサービスの販売をユーザ１０２に提示可能である。ユーザ１０２は、商取引アプリケーション１０４を通じて提示された１つまたは複数の商品またはサービスを選択することによって、注文を開始するようにしてもよい。注文を完了するため、ユーザ１０２は従来、自身のファーストネーム、ミドルネーム、ラストネーム、支払カード（クレジットカード、デビットカード等）番号、支払カードの有効期限（年および／または月）、支払カードに関連付けられている請求先住所（街路名、番地、市、州または県、郵便番号、国等を含む）、支払カードに関連付けられている電話番号、および１つまたは複数の配送先住所（請求先住所と同様のフィールドを含む）等、最大２０個の異なる支払フィールドに入力する必要があった。

電子商取引支払ファシリテータ１０６は、ユーザ１０２の支払情報を記憶可能であるとともに、上記情報の少なくとも一部を商取引アプリケーション１０４に提供して、ユーザ１０２の精算作業を簡素化することができる。より具体的には、商取引アプリケーション１０４は、電子商取引支払ファシリテータ１０６により維持された支払情報を使用する選択可能なオプションを表示あるいは提供することができる。ユーザ１０２が選択可能なオプションを選択した場合、商取引アプリケーションは、電子商取引支払ファシリテータ１０６の助けを借りて取引を完了することができる。たとえば、商取引アプリケーション１０４は、電子商取引支払ファシリテータ１０６から支払情報を要求することができる。この要求に応答して、電子商取引支払ファシリテータ１０６は、支払情報および支払トークンを商取引アプリケーション１０４に提供することができる。

商取引アプリケーション１０４は、支払情報により精算支払フィールドを自動的に埋めることが可能である。上述の通り、電子商取引支払ファシリテータ１０６からの支払情報を用いて支払フィールドを自動的に埋めることによって、ユーザの精算プロセスを容易に行わせることが可能である。少なくとも１つの実施形態において、電子商取引支払ファシリテータ１０６は、商取引アプリケーション１０４に完全な支払カード番号を送信しない。その代りに、電子商取引支払ファシリテータ１０６は、カード番号ラベル（すなわち、支払カードの下数桁を除く全桁が「Ｘ」）および支払トークンを送信することができる。支払トークンおよび支払カードラベルを使用することによって、商取引アプリケーション１０４は、ＰＣＩ準拠である必要性を回避可能とすることができる。さらに、商取引アプリケーション１０４がユーザ１０２の完全な支払カード番号を受信しないようにすることによって、電子商取引支払ファシリテータ１０６は、支払カード番号を一度も商取引アプ
リケーションに提供することなく、１つまたは複数の支払カードを用いて、任意数の商取引アプリケーションからユーザ１０２が商品を購入できるようにすることで、セキュリティを高めるとともに詐欺行為を抑制することができる。

自動的に埋められた支払情報を受信した場合、ユーザ１０２は、上記注文の購入を許可することができる。商取引アプリケーション１０４は、この許可を支払トークンと併せて電子商取引支払ファシリテータ１０６に転送可能である。許可および支払トークンを受信した場合、電子商取引支払ファシリテータ１０６は、支払情報（完全な支払カード番号を含む）を取引として（通常、通信ネットワーク上で）支払ゲートウェイシステム１０８に受け渡すことができる。以下により詳しく説明する通り、支払トークンは、支払カード番号にマッピング可能であり、電子商取引支払ファシリテータ１０６は、支払カード番号を見つけて支払ゲートウェイシステム１０８に送信することができる。

電子商取引支払ファシリテータ１０６から取引を受信すると、支払ゲートウェイシステム１０８は、業者の加盟店銀行（アクワイアラ）が使用するプロセッサ（たとえば、支払処理システム１１０）に上記取引を受け渡す。支払カードの種類に基づいて、支払処理システム１１０は、上記取引を適当なカードネットワークシステム１１２に伝送可能である。そして、カードネットワークシステム１１２は、支払カードをユーザ１０２に発行した発行銀行システム１１４に上記取引を受け渡すことができる。

発行銀行システム１１４は、上記取引を承認または拒否して、この決定をカードネットワークシステム１１２に送り返す。その後、上記決定は、カードネットワークシステム１１２から加盟店銀行が優先する支払処理システム１１０へと送り返される。そして、支払処理システム１１０は、上記決定を支払ゲートウェイシステム１０８に送り返すことができる。１つまたは複数の実施形態において、支払ゲートウェイシステム１０８は、取引に関する詳細および決定を記憶した後、上記決定を電子商取引支払ファシリテータ１０６に受け渡す。

また、支払ゲートウェイシステム１０８は、加盟店銀行が優先する支払処理システム１１０を通じてキャプチャした取引の日常的な精算バッチを加盟店銀行に提出すること等の精算タスクを実行可能である。そして、支払処理システム１１０は、精算バッチを加盟店銀行のサーバ（図示せず）に受け渡し、上記サーバは、ユーザ１０２／商取引アプリケーション１０４取引による資金を業者の口座に預ける。その後、加盟店銀行は、この注文の支払資金の要求を支払処理システム１１０に送信し、上記支払処理システム１１０は、この資金提供要求を適当なカードネットワークシステム１１２に受け渡し、上記カードネットワークシステム１１２は、この資金提供要求を発行銀行システム１１４に受け渡す。その後、発行銀行システム１１４は、上記取引をユーザ１０２の口座に記帳するとともに、放出資金をカードネットワークシステム１１２に受け渡す。この放出資金はその後、支払処理システム１１０に、次いで、加盟店銀行に受け渡される。

本明細書の開示を踏まえれば、電子商取引支払ファシリテータ１０６は、ユーザ１０２および商取引アプリケーション１０４の両者に多くの利益をもたらすことが理解される。たとえば、電子商取引支払ファシリテータ１０６は、支払フィールドを自動的に埋めた情報を提供することによって、ユーザ１０２が精算プロセス中に多くの支払フィールドに入力する必要性を低減または排除することができる。これにより、ユーザ１０２の精算プロセスは、大幅に容易化および迅速化されることができる。ユーザ１０２にとっての容易化によって、買い物かごの放棄を減らすことにより、商取引アプリケーション１０４のための販売を増やすことができる。

また、電子商取引支払ファシリテータ１０６によれば、ユーザ１０２は、仮想的に任意
の商取引アプリケーション１０４で記憶された支払情報を用いることにより、商取引アプリケーション１０４のいずれにも完全な支払カード（クレジットカード、デビットカード等）情報を提供することなく買い物することができる。これにより、電子商取引支払ファシリテータ１０６は、セキュリティを高めつつ、商取引アプリケーション１０４を用いた買い物の容易さを増大することができる。

図２は、本発明の一実施形態に係るシステム１００ａを示した模式図である。システム１００ａは、システム１００の例示的な一実施形態を示している。特に、図２は、商取引アプリケーション１０４ａおよび電子商取引支払ファシリテータ１０６ａの一実施形態を示している。図２に示すように、ユーザ１０２は、コンピューティングデバイス２０２を用いて商取引アプリケーション１０４ａにアクセスすることができる。商取引アプリケーション１０４ａがウェブアプリケーションである実施形態において、ユーザ１０２は、ウェブブラウザ２０４アプリケーションまたはユーザ商取引アプリケーション２０６（本明細書の以下では、専用クライアントアプリケーションとも称する）を用いて商取引アプリケーション１０４ａとインターフェース接続してもよく、これらのアプリケーションは、商取引アプリケーション１０４ａの一部として考慮されてもよいし、されなくてもよい。

商取引アプリケーション１０４ａがウェブアプリケーションである実施形態において、商取引アプリケーション１０４ａのバックエンド（すなわち、商取引アプリケーション１０４ａにデータおよびロジックを提供するアプリケーションのセット）には、ウェブアプリケーションサーバ２０８（アパッチ・ソフトウェア財団（Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎ）によるＡｐａｃｈｅＨＴＴＰサーバ、マイクロソフト・コーポレーション（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）によるインターネット・インフォーメーション・システム（ＩＩＳ）、ＮＧＩＮＸ社（ＮＧＩＮＸ，Ｉｎｃ．）によるｎｇｉｎｘ、オープンソースｌｉｇｈｔｔｐｄウェブサーバ、およびグーグル社（Ｇｏｏｇｌｅ Ｉｎｃ．）によるグーグル・ウェブ・サーバ（ＧＷＳ）が挙げられるが、これらに限定されない）および任意選択としてリレーショナルデータベースまたは非リレーショナルデータベース２１０（オラクル・コーポレーション（Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ）によるＭｙＳＱＬ、ＰｏｓｔｇｒｅＳＱＬ Ｇｌｏｂａｌ Ｄｅｖｅｌｏｐｍｅｎｔ ＧｒｏｕｐによるＰｏｓｔｇｒｅＳＱＬ、アパッチ・ソフトウェア財団によるＡｐａｃｈｅ Ｃａｓｓａｎｄｒａ、アパッチ・ソフトウェア財団によるＨＢａｓｅ、および１０ｇｅｎによるＭｏｎｇｏＤＢが挙げられるが、これらに限定されない）を含んでいてもよい。

商取引アプリケーション１０４ａがネイティブアプリケーションである実施形態において、ユーザ１０２は、ユーザ商取引アプリケーション２０６を利用するが、これは、別個のサーバコンピューティングデバイス２１４のアプリケーションサーバ２１２（たとえば、Ｊａｖａ（登録商標）アプリケーションサーバ）および／またはデータベース２０８を利用するので、ネットワークアプリケーションと見なしてもよいし、アプリケーションサーバ２１２もデータベース２１０も利用しないので「スタンドアロン」アプリケーションと見なしてもよい。このため、「商取引アプリケーション」という用語は、その文脈に応じて、ユーザのコンピューティングデバイス２０２および／またはサーバコンピューティングデバイス２１４上で実行されるソフトウェアを表していてもよい。特に、商取引アプリケーションソフトウェアの少なくとも第１の部分は、ユーザのコンピューティングデバイス２０２上で実行可能であり、商取引アプリケーションソフトウェアの少なくとも第２の部分は、１つまたは複数のサーバコンピューティングデバイスのセット２１４において実行可能である。

商取引アプリケーション１０４ａは、電子商取引支払ファシリテータ１０６ａと対話することにより、ユーザ１０２等のユーザの支払情報を取得することができる。また、電子
商取引支払ファシリテータ１０６ａは、支払ネットワーク１１６の支払ゲートウェイシステム１０８と対話することにより、図１に関して上述した通りに取引を処理することができる。図示の実施形態は、単一の支払ゲートウェイシステム１０８および単一の支払ネットワーク１１６を示している。本明細書の開示を踏まえれば、本発明はこれに限定されず、電子商取引支払ファシリテータ１０６ａは、任意数の異なる支払ゲートウェイシステムおよび支払ネットワークと対話することによって、支払および金銭取引を処理することが理解される。たとえば、電子商取引支払ファシリテータ１０６ａは、第１の商取引アプリケーション１０４ａに関しては第１の支払ゲートウェイシステム１０８と、第２の商取引アプリケーションに関しては第２の支払ゲートウェイシステムと対話してもよい。

図２に示す実施形態のシステム１００ａは、電子商取引支払ファシリテータ１０６ａを含むネットワークアプリケーション２１８を提供する１つまたは複数のサーバコンピューティングデバイスのセット２１６を備える。本発明の１つまたは複数の実施形態において、ネットワークアプリケーション２１８は、ソーシャルネットワーキングシステム２２０（フェースブック（登録商標）が挙げられるが、これに限定されない）を含むが、他の実施形態においては、別の種類のアプリケーションを含んでいてもよく、電子メールアプリケーション、検索エンジンアプリケーション、バンキングアプリケーション、またはユーザアカウントを利用する任意数の他種アプリケーションが挙げられるが、これらに限定されない。ネットワークアプリケーション２１８がソーシャルネットワーキングシステム２２０を含む１つまたは複数の実施形態において、ネットワークアプリケーション２１８は、複数のユーザおよびコンセプトを表現および解析するソーシャルグラフモジュール２２２を備える。ソーシャルグラフモジュール２２２のノード記憶モジュール２２４は、ユーザのノード、コンセプトのノード、および商品のノードを含むノード情報を記憶可能である。ソーシャルグラフモジュール２２２のエッジ記憶モジュール２２６は、ノードおよび／またはソーシャルネットワーキングシステム２２０内で発生するアクション間の関係を含むエッジ情報を記憶可能である。ソーシャルネットワーキングシステム、ソーシャルグラフ、エッジ、およびノードの詳細については、図１２に関して以下に提示する。

ネットワークアプリケーション２１８の電子商取引支払ファシリテータ１０６ａは、ネットワークアプリケーション２１８のユーザの支払情報を記憶可能なプロフィール記憶モジュール２２８を備え得る。たとえば、ユーザ１０２は、ネットワークアプリケーション２１８に「口座」を作成可能であって、これによりユーザは、支払情報をネットワークアプリケーション２１８に提供することができる。そして、ネットワークアプリケーション２１８は、上記支払情報をプロフィール記憶モジュール２２８に保存することができる。１つまたは複数の実施形態において、プロフィール記憶モジュール２２８は、ユーザ１０２に関して、ファーストネーム、ミドルネーム、ラストネーム、支払カード番号（たとえば、クレジットカード、デビットカード）、支払カードの有効期限（年および／または月）、支払カードのカードセキュリティコード（たとえば、カード検証値（ＣＶＶまたはＣＶＶ２））、クレジットカードに関連付けられている請求先住所（街路名、番地、市、州または県、郵便番号、国等を含む）、クレジットカードに関連付けられている電話番号、１つまたは複数の配送先住所（請求先住所と同様のフィールドを含む）のうちの１つまたは複数を記憶することができる。支払カードがデビットカードを含む場合、プロフィール記憶モジュールは、上記デビットカードの個人識別番号（ＰＩＮ）も記憶可能である。ネットワークアプリケーション２１８がソーシャルネットワーキングシステム２２０を含む一実施形態において、プロフィール記憶モジュール２２８に記憶された支払情報は、ユーザ１０２を表すノード記憶モジュール２２４のノードと関連付けられていてもよい。

また、図示の実施形態において、電子商取引支払ファシリテータ１０６ａは、支払ゲートウェイ識別モジュール２３０も備える。商取引アプリケーション１０４ａからクレジット払い要求を受信した場合、支払ゲートウェイ識別モジュール２３０は、複数の支払ゲー
トウェイシステムのうちのどの支払ゲートウェイシステム１０８を用いてクレジット払い要求を処理するかを決定することができる。一実施形態において、支払ゲートウェイ識別モジュール２３０は、クレジット払い要求およびプロフィール記憶モジュール２２８に記憶された情報を利用して、この決定を行う。

たとえば、本発明の一実施形態において、プロフィール記憶モジュール２２８は、商取引アプリケーション１０４ａおよび上記商取引アプリケーション１０４ａを操作する業者の一方または両方に関して、上記商取引アプリケーションまたは業者のクレジット払い要求の処理に用いる支払ゲートウェイシステムを示す支払ゲートウェイ識別子を受信および／または記憶するようにさらに構成されている。また、プロフィール記憶モジュール２２８は、識別された支払ゲートウェイシステムと対話してユーザ１０２からの資金が支払われる口座を識別する際に用いられるアプリケーション識別子（または、業者識別子、口座識別子）を含んでいてもよい。本発明のいくつかの実施形態において、支払ゲートウェイ識別モジュール２３０は、受信したクレジット払い要求自体に含まれる情報に部分的または排他的に基づいて、支払ゲートウェイシステム１０８を識別する。

図２に示すように、１つまたは複数の実施形態において、電子商取引支払ファシリテータ１０６ａは、取引データベース２３２を備える。取引データベース２３２は、各ユーザおよび／または各商取引アプリケーションに関して開始および／または完了となった取引の詳細を記憶可能である。したがって、取引データベース２３２によれば、ユーザは、電子商取引支払ファシリテータ１０６ａの助けを得て行ったすべての購入の詳細を取り出すことができる。これによりユーザは、ネットワークアプリケーション２１８にログインして、任意数の異なる商取引アプリケーション上で行った購入に関する取引詳細を取り出すことが理解される。これにより、有意な利点がもたらされる。電子商取引支払ファシリテータ１０６ａを利用しないユーザは、ユーザ名およびパスワードを思い出すとともに複数の商取引アプリケーションにログインして、取引データベース２３２が提供可能な情報および詳細を入手することが必要となり得るからである。

取引データベース２３２は、各取引（試行または完了）、日付、取引が完了した商取引アプリケーションを示す標識、取引の金額、取引の一部として購入された商品／サービス（任意選択として、オープングラフ製品のＵＲＬ）、取引の状態（完了、配送、進行中、返品、拒否等）、ユーザが商取引アプリケーションに提供して取引を参照するための取引ＩＤ等の詳細を提供することができる。

取引データベース２３２によれば、ユーザまたは商取引アプリケーションを操作する業者は、上記取引詳細のうちの１つまたは複数を含む取引の履歴等、取引に関する詳細を取り出すことができる。ネットワークアプリケーション２１８がソーシャルネットワークを含む場合、取引データベース２３２は、商取引アプリケーション１０４ａから商品を購入したユーザに関して、ソーシャルグラフから引き出された付加的な人口統計学的情報（ユーザの地理的位置、ユーザの年齢、ユーザの性別等）を提供することができる。

上記のほか、電子商取引支払ファシリテータ１０６ａは、トークン生成器２３４も備える。トークン生成器２３４は、電子商取引支払ファシリテータ１０６ａが支払カード番号の代わりとして商取引アプリケーション１０４ａに送信可能な支払トークンを生成することができる。トークン生成器２３４は、元の支払カード番号へのポインタとして、「トークン」と称するランダムな文字列を返すことができる。トークンは、（単に解読アルゴリズムをトークンに適用すること等によって）支払カード番号がトークン自体に基づいて導出されることがないように、元の支払カード番号とのアルゴリズム的関係を有していないのが好ましい。したがって、このトークンは、トークン生成器２３４およびプロフィール記憶モジュール２２８を用いなければ元のカード名義人データを推定できないランダムな
文字列であり、支払カード番号および対応するトークンの一覧を含むものであるので、カード名義人データとはみなされない。トークン生成器２３４により生成された支払トークンによれば、商取引アプリケーション１０４ａは、以下に説明するＰＣＩ ＤＳＳ標準等の規制標準に準拠することなく支払を処理可能である。

図２に示す実施形態において、電子商取引支払ファシリテータ１０６ａは、サービス利用規約（ＴＯＳ）モジュール２３５を備える。ＴＯＳモジュール２３５は、ある要求において識別されたユーザ１０２が、商取引アプリケーション１０４ａ内で精算を行うことを目的として、支払プロフィール記憶モジュール２２８により記憶された支払情報を商取引アプリケーション１０４ａが利用できるようにする旨をネットワークアプリケーション２１８に対して示したかを判定することができる。１つまたは複数の実施形態において、許可値とは、ユーザの支払情報を利用する能力をユーザ１０２が上記特定の商取引アプリケーション１０４ａに与えたか否かを示す商取引アプリケーション識別子に関連付けられているブール値である。

１つまたは複数の実施形態において、ユーザ１０２が商取引アプリケーション１０４ａで精算フローを開始すると、商取引アプリケーション１０４ａの承認を求めてユーザ１０２の支払情報にアクセスするユーザインターフェース要素がユーザ１０２に提示される。ユーザが肯定的に応答した場合、コンピューティングデバイス１０２上で実行されるユーザネットワーキングアプリケーション２３６および／またはユーザネットワーキングアプリケーションソフトウェア開発キット（ＳＤＫ）ライブラリ２３８のライブラリ（両方とも、本明細書の以下に詳述）は、更新許可メッセージを電子商取引支払ファシリテータに伝送して、上記ユーザ１０２の許可値、つまり、上記商取引アプリケーション１０４ａの許可値をＴＯＳモジュール２３５に更新させることができる。別の実施形態において、ＴＯＳモジュール２３５は、商取引アプリケーション１０４ａからユーザ１０２のクレジット払い要求を受信すると、許可値を利用して、クレジット払い要求を支払ゲートウェイに発行し続けるべきか否かを判定する。いずれにしろ、ＴＯＳモジュール２３５は、ユーザの支払情報の提供に先立って、ユーザがネットワークアプリケーションに対して、支払情報の商取引アプリケーション１０４ａへの提供を許可することを確実にすることができる。

また、図２の実施形態には、ユーザネットワーキングアプリケーション２３６も含む。ネットワークアプリケーション２１８がソーシャルネットワーキングシステム２２０を含む一実施形態において、ユーザネットワーキングアプリケーション２３６は、ユーザ１０２によるソーシャルネットワーキングシステム２２０の利用を可能とする。ユーザネットワーキングアプリケーション２３６は、クライアントデバイス上で動作するネイティブソーシャルネットワーキングアプリケーションを含み得る。たとえば、１つまたは複数の実施形態において、ユーザネットワーキングアプリケーション２３６は、フェースブック（登録商標）ネイティブアプリケーションを含み得る。別の実施形態において、ユーザネットワーキングアプリケーション２３６は、厳密にソーシャルネットワーキングを目的としていなくてもよい。ユーザネットワーキングアプリケーション２３６は、コンピューティングデバイス２０２上で実行され、ユーザ１０２のネットワークアプリケーション２１８との対話を可能とする任意のネイティブアプリケーションを表すことができる。１つまたは複数の実施形態において、ユーザ１０２は、ユーザネットワーキングアプリケーション２３６を利用して、ソーシャルネットワーキングシステム２２０にログインすることにより、コンピューティングデバイス２０２の共有メモリの一部への難読化ユーザ識別子の記憶を上記コンピューティングデバイス２０２に行わせる。この難読化ユーザ識別子は、後で商取引アプリケーション１０４ａが利用することにより、ユーザ１０２の支払情報が使用可能となるか否かを判定することができる。また、１つまたは複数の実施形態において、ユーザネットワーキングアプリケーション２３６は、ユーザによって利用されることに
よって、商取引アプリケーション１０４ａがその精算フローにおいてネットワークアプリケーション２１８からのユーザ１０２の支払情報を利用する許可を付与または無効化する。また、ユーザ１０２がその支払情報の利用をネットワークアプリケーション２１８に許可しており、このような支払情報をネットワークアプリケーション２１８に提供していない場合は、ユーザ１０２がユーザネットワーキングアプリケーション２３６を利用することによって、最初に上記情報を提供するようにしてもよい。

また、図示の実施形態には、ユーザネットワーキングアプリケーションＳＤＫライブラリ２３８を含む。ユーザネットワーキングアプリケーションＳＤＫライブラリ２３８は、ユーザ商取引アプリケーション１０４ａがネットワークアプリケーション２１８と対話するために利用されるルーチンのセットを提供する。一実施形態においては、商取引アプリケーション１０４ａと電子商取引支払ファシリテータ１０６ａとの間のすべての対話がユーザネットワーキングアプリケーションＳＤＫライブラリ２３８を通じて流れる。商取引アプリケーション１０４ａの少なくとも一部がサーバコンピューティングデバイス２１４上で実行される１つまたは複数の実施形態において、サーバコンピューティングデバイス２１４は、ユーザネットワーキングアプリケーションＳＤＫライブラリ２３８と同じ目的をもって機能するか、または協働する商取引ネットワークアプリケーションＳＤＫライブラリ２４０を備える。

ここで図３Ａおよび図３Ｂを参照すると、シーケンスフロー図は、支払情報を商取引アプリケーション１０４ａに提供する電子商取引支払ファシリテータ１０６ａの一実施形態を示している。図３Ａおよび図３Ｂの図は、本発明の一実施形態に係る、商取引アプリケーション１０４ａ、電子商取引支払ファシリテータ１０６ａ、および支払ゲートウェイシステム１０８の対話を示したタイムラインの一実施形態を示している。

図示のように、商取引アプリケーション１０４ａは、支払ゲートウェイシステム１０８に口座を設定可能である。別の実施形態において、商取引アプリケーション１０４ａと支払ゲートウェイシステム１０８との間の口座／関係は、事前に存在可能である。ある時点で、支払ゲートウェイシステム１０８は、業者識別子（ＭＩＤ）および／または公開鍵および秘密鍵を商取引アプリケーション１０４ａに提供可能である（３０２）。たとえば、業者が商取引アプリケーション１０４ａに支払ゲートウェイシステム１０８を登録した場合、支払ゲートウェイシステム１０８は、商取引アプリケーション１０４ａおよび／または業者にＭＩＤおよび／または公開鍵／秘密鍵を提供することができる。ＭＩＤおよび／または公開鍵／秘密鍵によれば、商取引アプリケーション１０４ａは、支払ゲートウェイシステム１０８との対話によって、取引を処理するとともに、業者または商取引アプリケーション１０４ａに関連付けられている口座に資金を預けることができる。ＭＩＤおよび／または公開鍵／秘密鍵によれば、支払ゲートウェイシステム１０８は、商取引アプリケーション１０４ａおよび任意の関連する処理パラメータ（すなわち、商取引アプリケーション１０４ａ、支払処理システム１１０、カードネットワークシステム１１２、および銀行システムに関連付けられている口座）の識別を検証することができる。

そして、商取引アプリケーション１０４ａは、選択した支払ゲートウェイシステムのゲートウェイ情報を電子商取引支払ファシリテータ１０６ａに提供する（３０４）。ゲートウェイ情報（３０４）には、商取引アプリケーション１０４ａ発行のクレジット払い要求に利用すべく選択した支払ゲートウェイシステム１０８を示す標識と、クレジット払い金額が預けられる金融口座を示す口座情報（たとえば、口座識別子）とを含み得る。商取引アプリケーション１０４ａは、電子商取引支払ファシリテータ１０６ａとの最初の対話時に、選択した支払ゲートウェイ情報を提供可能である（３０４）。あるいは、商取引アプリケーション１０４ａを操作する業者がゲートウェイ情報を手動で提供することができる（３０４）。たとえば業者は、ネットワークアプリケーション２１８のウェブサイトまた
はネットワークアプリケーション２１８のネイティブアプリケーションを用いて、この情報を電子商取引支払ファシリテータ１０６ａに提供するようにしてもよい。

また、ゲートウェイ情報には、商取引アプリケーション１０４ａに代わって、選択された支払ゲートウェイシステム１０８に電子商取引支払ファシリテータ１０６ａが連通することにより金銭取引の処理を可能とするＭＩＤおよび公開／秘密鍵を示す標識を含み得る。１つまたは複数の実施形態において、商取引アプリケーション１０４ａは、ネットワークアプリケーション２１８の口座からではなく支払ゲートウェイシステム１０８から直接、商取引アプリケーション１０４ａを操作する業者の口座に金額が支払われるように、商取引アプリケーション１０４ａに代わって、商取引支払ファシリテータ１０６ａがクレジット払い要求を発行できるように好適な支払ゲートウェイシステム１０８を設定する。あるいは、商取引アプリケーション１０４ａを操作する業者が支払ゲートウェイシステムを手動で設定することができる。たとえば、業者は、支払ゲートウェイシステム１０８のウェブサイトまたは支払ゲートウェイシステム１０８のネイティブアプリケーションを使用することができる。

上記のほか、電子商取引支払ファシリテータ１０６ａまたはネットワークアプリケーション２１８は、アプリケーションアクセストークンまたは事前合意暗号を商取引アプリケーション１０４ａに提供することができる。アプリケーションアクセストークンまたは事前合意暗号によれば、商取引アプリケーション１０４ａは、ＡＰＩ呼び出し時に、電子商取引支払ファシリテータ１０６ａおよび／またはネットワークアプリケーション２１８に対して、その同一性および信頼性を証明することができる。１つまたは複数の実施形態において、電子商取引支払ファシリテータ１０６ａまたはネットワークアプリケーション２１８は、サーバ間呼び出しによって、アプリケーションアクセストークンまたは事前合意暗号を提供する。

３０６に示すように、ユーザは、商取引アプリケーション１０４ａを用いて精算プロセスを開始することができる。特にユーザは、商取引アプリケーション１０４ａにより提示された１つまたは複数の商品またはサービスを仮想買い物かごに入れることができる。１つまたは複数の実施形態において、ユーザは、（たとえば、精算ボタンまたは他のオプションを選択することによって）精算希望を商取引アプリケーション１０４ａに示すことができる。

この時点またはそれ以前に、商取引アプリケーション１０４ａは、ネットワークアプリケーション２１８用のユーザのユーザ識別子を取得、識別、あるいは発見可能である（３０８）。たとえば、商取引アプリケーション１０４ａは、ユーザのコンピューティングデバイス２０２上に存在するユーザの難読化（たとえば、ハッシュ化、暗号化、あるいはアルゴリズム的に変換した）ユーザ識別子にアクセスすることができる。このユーザ識別子は、ネットワークアプリケーション２１８（たとえば、ソーシャルネットワーキングアプリケーション）の上記ユーザのプロフィール／アカウントを識別可能である。本発明の１つまたは複数の実施形態において、ユーザ識別子は、ネットワークアプリケーション２１８がアクセスまたは予約する共有メモリの一部からのアクセスを受けるとともに、ユーザがネットワークアプリケーション２１８に現時点で「ログオン」となっている場合にのみ存在していてもよい。１つまたは複数の他の実施形態において、ユーザ識別子は、ユーザのコンピューティングデバイス２０２上のクッキー（たとえば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）クッキー）またはアプリケーションキャッシュ（たとえば、ハイパーテキストマークアップ言語ｖｅｒ．５（ＨＴＭＬ５）アプリケーションキャッシュ）からのアクセスを受ける。

このプロセスは、ユーザの認証として機能するようになっていてもよい。ユーザのコン
ピューティングデバイス２０２上におけるネットワークアプリケーション２１８の適正な難読化ユーザ識別子の存在は、ユーザがネットワークアプリケーション２１８によって既に認証済みであるため、商取引アプリケーション１０４ａがこの以前の認証に依存可能であることを示しているからである。また、精算プロセスのこの時点においては、単に難読化ユーザ識別子を有している商取引アプリケーション１０４ａに対して、ユーザの詳細のセキュリティまたはプライバシー漏れは発生していない。

ユーザが精算プロセスを開始すると（３０６）、商取引アプリケーション１０４ａは任意選択として、ユーザ識別情報および買い物かご情報を電子商取引支払ファシリテータ１０６ａに送信可能である（３１０）。本発明の１つまたは複数の実施形態において、商取引アプリケーション１０４ａは、精算画面のレンダリングに先立って、ユーザ識別情報および買い物かご情報を送信することができる（３１０）。ユーザ識別情報および買い物かご情報の送信（３１０）のほか、商取引アプリケーション１０４ａは、商取引アプリケーション１０４ａの同一性の確認をネットワークアプリケーション２１８に行わせるアプリケーションアクセストークンまたは事前合意暗号も送信することができる。１つまたは複数の実施形態において、買い物かご情報には、商取引アプリケーション１０４ａの仮想買い物かご中の商品／サービスの総額を含み得る。

また、１つまたは複数の実施態様において、買い物かご情報には、買い物かご中の商品に関する詳細な情報をさらに含み得る。たとえば、買い物かご情報には、買い物かご商品のＪＳＯＮ符号化アレイを含み得る。アレイの各ＪＳＯＮオブジェクトには、商品の名称、商品の金額、商品の数量、およびユーザが購入を望む製品のＵＲＬのうちの１つまたは複数を含み得る。さらに別の実施形態において、買い物かご情報には、製品名、製品番号（たとえば、最小在庫管理単位（ＳＫＵ）、シリアル番号、型式番号）、製品価格、製品量、注文日、請求書番号、および適用される税を含み得る。一実施形態において、買い物かご中の商品に関する詳細な情報は、ステップ３１０で提供される。この追加または代替として、買い物かご中の商品に関する詳細な情報は、（たとえば、ステップ３１６において）電子商取引支払ファシリテータ１０６ａに提供される。

商取引アプリケーション１０４ａは、ユーザがネットワークアプリケーション２１８／電子商取引支払ファシリテータ１０６ａを利用して、商取引アプリケーション１０４ａの仮想買い物かご中の商品の購入を完了可能であることを示すグリフ（すなわち、マーク、アイコン、グラフィック、テキストの一部等）を含む精算オプション３１２を提供可能である。精算オプションには、商取引アプリケーション１０４ａの精算ユーザインターフェースに表示されるボタン、商取引アプリケーション１０４ａの精算ユーザインターフェース上に現れる選択可能なオーバーレイ、プラグイン、ポップアップ等の選択可能なオプションを含み得る。たとえば、商取引アプリケーション１０４ａがウェブアプリケーションを含む場合等の１つまたは複数の実施形態においては、ウェブページを規定するコードにＩフレームが追加されていてもよい。この追加または代替として、商取引アプリケーション１０４ａは、選択可能なオプションをレンダリングするＳＤＫ機能を呼び出すことができる。精算オプションの一例については、要素５１４として図５Ｃに示す。精算オプションの別の例については、要素６０２として図６に示す。

本明細書の開示を踏まえれば、ＳＤＫ機能またはＩフレームの使用は、精算オプションをレンダリングまたは呼び出す方法の２つの例であることが理解される。ただし、本発明の実施形態は、ＳＤＫ機能またはＩフレームの使用に限定されない。たとえば、ウェブベースの商取引アプリケーションに関する別の実施形態において、ネットワークアプリケーション２１８／電子商取引支払ファシリテータ１０６ａは、Ｉフレームを使用する代わりに、支払情報を商取引アプリケーション１０４ａに受け渡すことができ、そして、商取引アプリケーション１０４ａがこの支払情報をレンダリング可能である。

より詳細には、構造化文書を扱うブラウザ（たとえば、ウェブブラウザ）等のアプリケーションクライアントとの関連で動作または実行されるプラグインソフトウェアアプリケーションではなく、本明細書に記載の機能をプラグインとは対照的に、ブラウザクライアントアプリケーションに直接組み込むことができる。たとえば、オープングラフプロトコルによれば、任意のウェブページをソーシャルグラフに組み入れることができる。特定の実施形態においては、構造化文書内に基本的なメタデータが存在することで、構造化文書内のオブジェクトがグラフオブジェクトまたはノードになれる。ウェブページをグラフオブジェクトに変化させるため、上記ウェブページには、オープングラフプロトコルの＜ｍｅｔａ＞タグおよび精算オプション（および／または支払情報）が含まれる（３１４）。オープングラフプロトコルは、タイトル、種類、画像、ＵＲＬという４つの特性を規定する。

さらに別の実施形態においては、ＸＦＢＭＬまたはＨＴＭＬ５を使用して、精算オプション（および／または支払情報）を実装、レンダリング、または呼び出すようにしてもよい（３１４）。ＸＦＢＭＬおよびＨＴＭＬ５では、Ｊａｖａｓｃｒｉｐｔ（登録商標）ＳＤＫを呼び出すページをコードに追加可能であることが必要となる場合がある。特定の実施形態においては、Ｊａｖａｓｃｒｉｐｔ ＳＤＫによって、ウェブページから支払情報および／または精算オプションの一部または全部にアクセス可能となる（３１４）。さらに、商取引アプリケーション１０４ａは、精算オプションがクリックあるいは選択されたタイミングを実時間で把握できるように、Ｊａｖａｓｃｒｉｐｔ ＳＤＫを使用してイベントをリッスンすることができる（３１４）。

したがって、精算オプション（および／または支払情報）は、任意数の方法またはプロトコルによって、実装、レンダリング、または呼び出し可能である（３１４）ことが理解される。このような方法およびプロトコルの例は、２０１１年５月２６日に出願された米国特許出願第１３／１１６，９４５号「ソーシャル・データ・インプット（Ｓｏｃｉａｌ
Ｄａｔａ Ｉｎｐｕｔｓ）」の「いいねボタン（Ｌｉｋｅ Ｂｕｔｔｏｎ）」の項に詳しく記載されている。上記出願のすべての内容を漏れなく本明細書に援用する。

ユーザが精算オプションを選択すると（３１４）、支払情報に対する要求がネットワークアプリケーション２１８に送信される可能性がある（３１６）。言い換えると、ユーザがネットワークアプリケーション２１８を用いて購入を完了することを選択したことを示す標識が電子商取引支払ファシリテータ１０６ａに送信される可能性がある。

たとえば、（商取引アプリケーション１０４ａがネイティブアプリケーションを含む場合等の）１つまたは複数の実施形態において、商取引アプリケーション１０４ａは、ユーザ１０２の支払情報を求めるネットワークアプリケーション２１８のグラフＡＰＩの呼び出しを行うことができる。支払情報を求めるグラフＡＰＩ呼び出しは、商取引アプリケーション１０４ａを動作させるクライアントデバイス２０２を由来とすることができ、ステップ３０８において事前に取得されたユーザ識別子を含むことができる。あるいは、支払情報を求めるグラフＡＰＩ呼び出しは、商取引アプリケーション１０４ａを動作させるサーバコンピューティングデバイス２１４を由来とすることができる。さらに別の実施形態において、ユーザネットワーキングアプリケーション２３６（すなわち、モバイルデバイス上のネイティブＳＮＳアプリケーション）は、ユーザ１０２の支払情報を求めるネットワークアプリケーション２１８の呼び出しを行うことができる。また、グラフＡＰＩ呼び出しは任意選択として、アプリケーションアクセストークンまたは事前合意暗号を含み得る。１つまたは複数の実施形態において、商取引アプリケーション１０４ａは、ステップ３１０に関して上述した買い物かごの商品に関する詳細な情報をグラフＡＰＩ呼び出しに含めることができる。

別の実施形態において（商取引アプリケーション１０４ａがウェブアプリケーションを含む場合等）、ウェブブラウザ２０４は、支払情報を求める要求のネットワークアプリケーション２１８への送信を行わせるウィジェットを実行可能である。ウェブブラウザ２０４は、ウィジェットからの１つまたは複数のパラメータを識別して、ファシリテータエンゲージメント要求とともに（４０２）、上記１つまたは複数のパラメータをネットワークアプリケーション２１８に送信することができる。上記１つまたは複数のパラメータには、商取引アプリケーション１０４ａのＩＤ（すなわち、アプリケーションアクセストークンまたは事前合意暗号）、仮想買い物かご中の商品／サービスの金額、本明細書に記載の通りにユーザを認証するクッキーを含み得る。

支払情報の要求（３１６）に応答して、ネットワークアプリケーション２１８は、ＩＤを使用することによって、支払プロフィール記憶モジュール２２４により記憶されたユーザ１０２の支払情報の識別および／またはユーザのノード記憶モジュール２２０により記憶されたユーザノードの識別を行うことができる。ユーザ識別情報が難読化ユーザ識別子を含む場合、ネットワークアプリケーション２１８は、変換関数を使用してユーザ識別情報を非難読化ユーザ識別子に変換可能であり、対称鍵暗号関数の難読化ユーザ識別子への適用、公開鍵（非対称鍵）暗号関数の難読化ユーザ識別子への適用、または非難読化ユーザ識別子にマッピングされた難読化ユーザ識別子の一覧に対する難読化ユーザ識別子の比較が挙げられるが、これらに限定されない。

電子商取引支払ファシリテータ１０６ａは、ユーザの任意の利用可能な支払情報を含む応答を提供可能である（３１８）。支払情報には、氏名（たとえば、ファースト、ミドル、ラスト）、支払カードの有効期限（年および／または月）、支払カードに関連付けられている請求先住所（街路名、番地、市、州または県、郵便番号、国等を含む）、支払カードに関連付けられている電話番号、および１つまたは複数の配送先住所（請求先住所と同様のフィールドを含む）等に関する任意の利用可能な情報を含み得る。電子商取引支払ファシリテータ１０６ａは、ユーザの支払カード番号を商取引アプリケーション１０４ａに提供することはない。その代りに、電子商取引支払ファシリテータ１０６は、支払カードラベル（すなわち、支払カードの下数桁を除く全桁が「Ｘ」）およびトークン生成器２３４により生成された支払トークンを提供する。

以下に説明する支払トークンは、支払の処理に先立って、電子商取引支払ファシリテータ１０６ａによって要求される場合がある。支払トークンは、商取引アプリケーション１０４ａ、ユーザ、金額、および／または買い物かご固有（すなわち、特定の商取引アプリケーション、ユーザ、金額、および／または買い物かごに関してのみ有効）とすることができる。さらに別の実施形態において、支払トークンは、ユーザ／商取引アプリケーションの組み合わせ固有とすることができる。また、電子商取引支払ファシリテータ１０６ａは、任意数の異なるユーザパラメータを関連付けることができる。たとえば、支払トークンとしては、単一のユーザトークンが可能である。したがって、支払トークンは、１回の使用により無効となり得る。また、電子商取引支払ファシリテータ１０６ａは、それ以降に支払トークンが無効となる有効性ウィンドウ（たとえば、１０分、１時間、１日）を支払トークンに割り当てることができる。さらに、電子商取引支払ファシリテータ１０６ａは任意選択として、支払トークンに有効期間（ＴＴＬ）を割り当てることができる。電子商取引支払ファシリテータ１０６ａは、詳細な買い物かご情報を支払トークンに結び付けることができる。これは、支払トークンを買い物かごの購入についてのみ有効とするのに役立ち得る。また、これによって、電子商取引支払ファシリテータ１０６ａは、買い物かごの購入が完了したか否かを把握することができる。

ネットワークアプリケーション２１８を用いて精算プロセスを完了することをユーザが
望むことを示すこと（３１６）の一部または追加ステップとして、商取引アプリケーション１４０ａは、ネットワークアプリケーション２１８がユーザ１０２の支払情報を商取引アプリケーション１０４ａに提供することをユーザ１０２が許可しているか否かを示す標識を求めるＴＯＳ ＡＰＩ呼び出しを電子商取引支払ファシリテータ１０６ａに発行可能である。電子商取引支払ファシリテータ１０６ａは、ＴＯＳモジュール２３５に記憶されたその許可を確認可能である。商取引アプリケーション１０４ａが支払情報にアクセスする許可をユーザが与えている場合、電子商取引支払ファシリテータ１０６ａは、上述の通り、支払情報、支払トークン、およびカードラベルを提供することができる（３１８）。

商取引アプリケーション１０４ａが支払情報にアクセスする許可をユーザが与えていない場合、プロセスは、ユーザに許可を求めることによって継続するようにしてもよい。特に、許可ユーザインターフェースは、ネットワークアプリケーション２１８により記憶された支払情報に商取引アプリケーション１０４ａがアクセスする許可を付与するオプションをユーザに与えることができる。許可ユーザインターフェースは、コンピューティングデバイス２０２のオペレーティングシステムまたはユーザネットワークアプリケーション２０２内のユーザインターフェース要素によって与えられるようになっていてもよい。ユーザが許可を付与している場合、電子商取引支払ファシリテータ１０６ａは、ＴＯＳモジュール２３５によりその許可を更新可能であるとともに、上述の通り、支払情報、支払トークン、およびカードラベルを提供することができる（３１８）。

任意選択として、３２０に示すように、電子商取引支払ファシリテータ１０６ａは、買い物かごの金額に関して、ユーザの支払カードに対する許可要求を支払ゲートウェイシステム１０８に送信することができる。支払ゲートウェイシステム１０８は、支払ネットワーク（たとえば、図１に示すような支払ネットワーク１１６）に沿って許可要求を転送することができ、支払ネットワークは、支払カード許可を承認または拒否することができる。そして、支払ゲートウェイシステム１０８は、３２２に示すように、支払カード許可応答を電子商取引支払ファシリテータ１０６ａに転送することができる。任意選択としての許可要求は、タイムラインにおいて、より早く行うこともできるし、より遅く行うこともできることが理解される。別の実施態様において、電子商取引支払ファシリテータ１０６ａは、買い物かごの金額に関して、ユーザの支払カードに対する許可要求をクレジット払い要求の送信（３２８）の一部として支払ゲートウェイシステム１０８に送信することができる。同様に、支払ゲートウェイシステム１０８は、支払のクレジット払い要求の送信（３３０）の一部として、支払カード許可応答を電子商取引支払ファシリテータ１０６ａに転送することができる。

１つまたは複数の実施形態において、電子商取引支払ファシリテータ１０６ａから支払情報および支払カードラベルを受信した場合、商取引アプリケーション１０４ａは、電子商取引支払ファシリテータ１０６ａから受信した支払情報を精算画面にレンダリングすることができる。たとえば、商取引アプリケーション１０４ａは、受信した任意の支払情報により精算画面の支払フィールドを自動的に埋めることができる。本明細書の開示を踏まえれば、電子商取引支払ファシリテータ１０６は、商取引アプリケーション１０４ａの精算画面の支払フィールドそれぞれの情報を有していなくてもよいし、古い情報を含んでいてもよいことが理解される。このような場合、ユーザは、１つまたは複数の支払フィールドを自動的に埋められた情報の変更または任意の空白の支払フィールドへの情報の追加が可能である。

別の実施形態において（商取引アプリケーション１０４ａがウェブアプリケーションを含む場合等）、上述のウィジェットを実行した場合、ウェブブラウザ２０４は、フレーム（たとえば、Ｉフレーム）を作成可能である。支払情報の要求（３１６）に対する応答（３１８）には、フレームに含める内容（すなわち、支払情報およびカードラベル）を含み
得る。そして、ウェブブラウザ２０４は、電子商取引支払ファシリテータ１０６ａからの応答（３１８）にて受信した情報（および、いくつかの実施形態では、商取引アプリケーションにより生成された情報）を用いて精算画面（フレームを包含または備える）をレンダリングするとともに、電子商取引支払ファシリテータ１０６ａからの情報がフレームに表示された状態で、精算画面および上記フレームを表示する。商取引アプリケーション１０４ａのウェブページを記述するマークアップ言語文書にウィジェットを含めることによって、電子商取引支払ファシリテータ１０６ａからの支払情報をウェブページとともに表示することができる。このような実施形態において、商取引アプリケーション１０４ａは、支払フィールドを自動的に埋めるのではなく、フレームのレンダリング時に支払情報もレンダリングする。

支払情報を支払フィールドに含む精算画面を商取引アプリケーション１０４ａがレンダリングしたら、ユーザは、注文の購入の確認（３２６）あるいはわずか１回のクリックまたはユーザ入力での取引の完了が可能である。たとえば、必要な支払フィールドそれぞれの情報を電子商取引支払ファシリテータ１０６ａが提供している場合、ユーザは、「支払（ｐａｙ）」もしくは「注文（ｏｒｄｅｒ）」ボタンまたは他の選択可能なオプションを選択することによって、取引を完了することができる。別の実施形態において、ユーザは、データが提供されなかった１つまたは複数の支払フィールドすべてへの入力あるいは付加的な動作の実行によって、取引を完了することが必要となる場合がある。

ユーザが注文を確認すると（３２６）、商取引アプリケーション１０４ａは、クレジット払い要求を電子商取引支払ファシリテータ１０６ａに送信することができる（３２８）。特に、商取引アプリケーション１０４ａは、クレジット払い要求を含むネットワークアプリケーション２１８の支払ＡＰＩを呼び出すことができる。クレジット払い要求には、商取引アプリケーション１０４ａに以前提供された支払トークンおよびユーザが取引の完了を選択した旨の確認を含み得る。この代替または追加として、クレジット払い要求には、買い物かご情報の識別または買い物かご情報へのマッピングを行う注文ＩＤを含み得る。さらに、クレジット払い要求には、ステップ３０８で取得されたユーザ識別情報および／またはアプリケーションアクセストークンもしくは事前合意暗号を含み得る。

任意選択として、クレジット払い要求には、ステップ３１０に関して上述した買い物かご情報のいずれかをさらに含み得る。たとえば、電子商取引支払ファシリテータ１０６ａには、クレジット払い要求の一部として、注文の１つまたは複数の詳細（上述の支払情報のいずれか、難読化ユーザ識別子、商取引アプリケーションおよび／またはネットワークアプリケーションの取引番号、ユーザにクレジット（信用）払いする金額、商取引アプリケーションの識別子等が挙げられるが、これらに限定されない）が伝送される。本明細書の開示を踏まえれば、クレジット払い要求とともに支払情報が送信された場合、電子商取引支払ファシリテータ１０６ａは、提供された支払情報に対してユーザが情報の更新または追加を行ったかを判定できることが理解される。ユーザが情報の追加または変更を行った場合、電子商取引支払ファシリテータ１０６ａは、プロフィール記憶モジュール２２８に記憶されたユーザの支払プロフィールを更新することができる。１つまたは複数の実施形態において、ユーザは、電子商取引支払ファシリテータ１０６ａが追加／変更情報のいずれかを記憶するのに先立って、電子商取引支払ファシリテータ１０６ａにより支払プロフィールを更新する許可を与えることができる。

本発明の１つまたは複数の実施態様において、電子商取引支払ファシリテータ１０６ａは、クレジット払い要求を含むネットワークアプリケーション２１８の支払ＡＰＩの呼び出しが、商取引アプリケーション１０４ａを動作させるサーバコンピューティングデバイス２１４を由来とし、ネットワークアプリケーション２１８を動作させるサーバコンピューティングデバイス２１６を対象とする旨を求めることができる。本明細書の発明を踏ま
えれば、サーバ間呼び出しを求めることによって、取引のセキュリティを向上可能であることが理解される。

クレジット払い要求を受信した場合、電子商取引支払ファシリテータ１０６ａは、クレジット払い要求にて受信した支払トークンを使用して、プロフィール記憶モジュール２２８から支払カード情報を取り出すことができる。そして、電子商取引支払ファシリテータ１０６ａは、上述の支払ゲートウェイＩＤモジュール２３０により選定された支払ゲートウェイシステムを識別することができる。あるいは、クレジット払い要求には、支払のクレジット払い要求を送信すべき支払ゲートウェイシステムを示す標識を含み得る。そして、電子商取引支払ファシリテータ１０６ａは、選択された支払ゲートウェイシステム１０８に支払のクレジット払い要求を送信することができる（３３０）。支払のクレジット払い要求には、ユーザの完全な支払カード番号、支払カードの有効期限、ユーザの請求先／配送先住所、商取引アプリケーション１０４ａを示す標識（たとえば、ＭＩＤ等の識別子）、商取引アプリケーション１０４ａに代わってクレジット払い要求を提出する許可を示す標識を含み得る。この許可を示す標識には、支払ゲートウェイシステム１０８により商取引アプリケーション１０４ａに提供された秘密鍵、暗号鍵、もしくは他の識別子を用いて要求の１つもしくは複数の部分を符号化することまたは商取引アプリケーション１０４ａ（もしくは、業者）に代わって、電子商取引支払ファシリテータ１０６ａが作用している支払ゲートウェイシステム１０８に合図することを示す別の標識を含み得る。

支払ゲートウェイシステム１０８は、図１に関して上述した通り、支払ネットワーク１１６を用いて支払のクレジット払い要求を処理することができる。支払ゲートウェイシステム１０８は、３３２に示すように、取引ＩＤおよびクレジット払い応答を電子商取引支払ファシリテータ１０６ａに返すことができる。取引ＩＤによれば、支払ゲートウェイシステム１０８は、取引に関する更新情報（資金提供、拒否、返品等）によって、電子商取引支払ファシリテータ１０６ａまたは商取引アプリケーション１０４ａを更新することができる。そして、電子商取引支払ファシリテータ１０６ａは、取引ＩＤを商取引アプリケーション１０４ａに転送することができる（３３４）。取引ＩＤによれば、商取引アプリケーション１０４ａは、必要に応じて、取引に関する問い合わせを支払ゲートウェイシステム１０８に行うことができる。

本明細書の開示を踏まえれば、支払のクレジット払い要求の金額は、ネットワークアプリケーション２１８または電子商取引支払ファシリテータ１０６ａの口座からではなく、支払ネットワーク１１６から直接、商取引アプリケーション１０４ａの口座に支払い可能であることが理解される。このように、商取引アプリケーション１０４ａの観点から、決済の結果は、ユーザが商取引アプリケーション１０４ａの既存の精算システムを利用して精算プロセスを完了したかのように見える（すなわち、支払ネットワーク１１６の構成要素から、同じ口座に資金を預けることができる）。また、商取引アプリケーション１０４ａは、買い物かごの「放棄」の低減およびユーザの幸福感の点で、電子商取引支払ファシリテータが提供するより迅速かつ容易な認証および精算の利益を享受可能である。

図３Ａおよび図３Ｂの図は、ネットワークアプリケーション２１８（すなわち、電子商取引支払ファシリテータ１０６ａ）を用いた精算のオプションを商取引アプリケーション１０４ａが常に表示する一実施形態を示している。ただし、本発明は、これに限定されない。別の実施形態において、電子商取引支払ファシリテータは、記憶された支払情報を使用するオプションを知的かつ動的に提供可能である。たとえば、オプションは、ユーザが購入または取引を完了できる可能性を高めることが期待される場合に提供可能である。さらに、記憶された支払情報を使用するオプションによって、購入の可能性を高めることが期待されない場合は、上記オプションを提供しない。本明細書の開示を踏まえれば、電子商取引支払ファシリテータ１０６ａを使用するオプションを動的に配置することによって
、グラフィカルインターフェースの煩雑さを抑えることができ、これは、モバイル商取引アプリケーションにおいて重要となる可能性があることが理解される。

図４は、図３Ａおよび図３Ｂの図と同様のシーケンスフロー図を示している。図４のシーケンスフロー図は、電子商取引支払ファシリテータ１０６ａを使用することにより、商取引アプリケーション１０４ａを用いた取引を完了する動的なオプションを提供する一実施形態を示している。図４のシーケンスフロー図は、図３Ａおよび図３Ｂに関して上述したステップおよび構成要素の多くを含む。簡素化のため、これらのステップについては、図４に関して再び詳述することはしない。ただし、図３Ａおよび図３Ｂに関して行ったこれらステップの説明は、図４にも同様に適用可能であることが理解される。

図４は、上述の通り、商取引アプリケーション１０４ａにおいてユーザが精算を開始可能であることを示している（３０６）。そして、商取引アプリケーション１０４ａは、上述の通り、ネットワークアプリケーション用のユーザ識別情報を取得することができる（３０８）。ネットワークアプリケーション用のユーザ識別情報を取得するステップは、ユーザが精算を開始した後に実行可能であることが理解される。あるいは、商取引アプリケーション１０４ａは、ユーザが精算プロセスを開始する前に、ネットワークアプリケーション用のユーザ識別情報を取得することができる。

図示のように、商取引アプリケーション１０４ａは、ファシリテータエンゲージメント要求をネットワークアプリケーション２１８に送信可能である（４０２）。たとえば、商取引アプリケーション１０４ａがネイティブアプリケーションを含む場合、ファシリテータエンゲージメント要求としては、クライアントサイドまたはサーバサイド商取引アプリケーション１０４ａからのＡＰＩ呼び出しが可能である。ファシリテータエンゲージメント要求には、ユーザ識別情報、商取引アプリケーション１０４ａのＩＤ（すなわち、アプリケーションアクセストークンまたは事前合意暗号）、および仮想買い物かご中の商品／サービスの金額を含み得る。

あるいは、商取引アプリケーション１０４ａがウェブアプリケーションを含む場合、ウェブブラウザ２０４は、ファシリテータエンゲージメント要求のネットワークアプリケーション２１８への送信（４０２）を行わせるウィジェットを実行可能である。ウェブブラウザ２０４は、ウィジェットからの１つまたは複数のパラメータを識別して、ファシリテータエンゲージメント要求とともに（４０２）、上記１つまたは複数のパラメータをネットワークアプリケーション２１８に送信することができる。上記１つまたは複数のパラメータには、商取引アプリケーション１０４ａのＩＤ（すなわち、アプリケーションアクセストークンまたは事前合意暗号）および仮想買い物かご中の商品／サービスの金額を含み得る。

また、１つまたは複数の実施形態において、ファシリテータエンゲージメント要求は（ウェブブラウザから送信されたＡＰＩ呼び出しまたは要求のいずれであっても）、買い物かご中の商品に関する詳細な情報を含み得る。たとえば、買い物かご情報には、買い物かご商品のＪＳＯＮ符号化アレイを含み得る。アレイの各ＪＳＯＮオブジェクトには、商品の名称、商品の金額、商品の数量、およびユーザが購入を望むオープングラフ製品のＵＲＬのうちの１つまたは複数を含み得る。

１つまたは複数の実施形態において、ネットワークアプリケーション２１８に対するファシリテータエンゲージメント要求（４０２）には、商取引アプリケーション１０４ａの平均転換率（仮想買い物かごに入れた商品を購入するユーザの割合）を示す標識を含み得る。ファシリテータエンゲージメント要求の一部として平均転換率を提供することにより、商取引アプリケーション１０４ａは、この平均転換率を最新のものとして保証すること
ができる。あるいは、商取引アプリケーション１０４ａは、ステップ３０４において転換率を提供することも可能であるし、電子商取引支払ファシリテータ１０６ａに口座を設定する際に転換率を提供することも可能である。

ファシリテータエンゲージメント要求を受信した場合、ネットワークアプリケーション２１８は、ステップ４０４に示すように、電子商取引支払ファシリテータ１０６ａを用いて精算プロセスを完了するオプションを商取引アプリケーション１０４ａがユーザに提供すべきか否かを知的かつ動的に判定することができる。判定において、ネットワークアプリケーション２１８は、（１）ユーザがネットワークアプリケーションにアカウントを有するか否か、（２）ユーザが現時点でネットワークアプリケーションにログインしているか否か、（３）ユーザが利用可能な支払情報（配送先住所、請求先住所等）、（４）ユーザの支払カードが記録されているか否か、（５）オプションが商取引アプリケーション１０４ａまたは他の商取引アプリケーションに対する電子商取引支払ファシリテータのオプションである場合のユーザの転換率、（６）ユーザの以前の購入履歴、（７）ユーザが利用可能なソーシャルネットワーキングシステム２２０からの人口統計学的情報（年齢、性別等）、（８）ネットワークアプリケーション２１８に対するユーザのアクティビティ履歴（同じ商取引アプリケーション１０４ａまたは異なる商取引アプリケーションを用いた他の購入の前に、ユーザ１０２が電子商取引支払ファシリテータ１０６ａを利用したか否か等が挙げられるが、これらに限定されない）、（９）ソーシャルネットワーキングシステム２２０が示すユーザの関心、（１０）ユーザのリスクスコアといった情報または因子のうちの１つもしくは複数またはその組み合わせを使用することができる。

１つまたは複数の実施形態において、電子商取引支払ファシリテータ１０６ａを使用するオプションをユーザに提供するか否かの判定は、データが利用可能な上記因子のすべてに基づいて行うことができる。他の実施形態においては、これら因子のうちの１つ、２つ、３つ、４つ、５つ、６つ、７つ、８つ、または９つを用いて判定を行うことができる（４０４）。この追加または代替として、電子商取引支払ファシリテータ１０６ａは、これら因子のうちの１つまたは複数を他の因子よりも重視可能である。各因子には、商取引アプリケーション固有、ユーザ固有、または別の判定に基づく重要性を適用可能である。

一実施形態において、ネットワークアプリケーション２１８は、ファシリテータエンゲージメント要求の提供（４０２）を受けたユーザ識別情報による判定として、ユーザがネットワークアプリケーション２１８に口座を有する場合にのみ、電子商取引支払ファシリテータ１０６ａを使用するオプションを商取引アプリケーション１０４ａが提供すべきと判定することができる。たとえば、商取引アプリケーション１０４ａがウェブアプリケーションである場合、ネットワークアプリケーション２１８は、コンピューティングデバイス２０２について、クッキーを確認することができる。ネットワークアプリケーション２１８によるクッキーの確認に応答して、コンピューティングデバイス２０２は、上記クッキーまたはクッキーに関連付けられているメッセージをネットワークアプリケーション２１８に送信することができる。上述の通り、１つまたは複数の実施形態において、クッキーの存在は、コンピューティングデバイス２０２のユーザ１０２がネットワークアプリケーション２１８のユーザであるかどうか（たとえば、ユーザがソーシャルネットワーキングシステム２２０の有効なアカウントを有するかどうか）を示し得る。コンピューティングデバイス２０２のユーザ１０２がネットワークアプリケーション２１８のユーザである場合、クッキーには、ユーザがネットワークアプリケーション２１８にログインしているか否か（たとえば、ユーザがソーシャルネットワーキングシステム２２０と現時点で有効なセッション中であるか否か）を示す情報を含んでいてもよい。このように、ユーザデバイス２０２に関してクッキーを確認することにより、ネットワークアプリケーション２１８は、ユーザセッションを認証することができる。他の実施形態において、ネットワークアプリケーション２１８は、ユーザがネットワークアプリケーション２１８にログインし
ているか否かを判定することなく、たとえばクッキーの存在を確認することによって、ユーザがネットワークアプリケーション２１８のユーザであるか否かの判定のみを行うようにしてもよい。本明細書においては、ユーザおよび／またはユーザセッションを認証するクッキーを説明しているが、その他のユーザまたはセッション識別または認証方法（物理トークンの認識等）を使用するようにしてもよい。ネットワークアプリケーション２１８に口座を有さない場合に、ユーザが電子商取引支払ファシリテータ１０６ａを用いて精算を完了する確率は、低くなる可能性があることが理解される。したがって、電子商取引支払ファシリテータ１０６ａを使用するボタンまたは他の選択可能なオプションを提供しないことで、商取引アプリケーション１０４ａは、ユーザインターフェースの煩雑さを抑えることができる。

この追加または代替として、ネットワークアプリケーション２１８は、ユーザが現時点でネットワークアプリケーション２１８にログインしている場合にのみ、電子商取引支払ファシリテータ１０６ａを使用するオプションを商取引アプリケーション１０４ａが提供すべきと判定することができる。また、ネットワークアプリケーション２１８は、ファシリテータエンゲージメント要求とともに送信されたユーザ識別子に基づいて、ユーザがログインしているか否かを判定することができる。たとえば、ネットワークアプリケーション２１８は、ユーザ識別子を使用することにより、ユーザがログインしているか否かを示すユーザに対応したソーシャルグラフモジュール中のノードへのマッピングを行うことができる。したがって、このような実施態様においては、ファシリテータエンゲージメント要求にユーザ識別子（すなわち、上述のようなユーザ識別情報のハッシュ）が存在することによって、ユーザが現時点でネットワークアプリケーション２１８にログインしている旨を示すことができる。あるいは、商取引アプリケーション１０４ａは、クッキーを用いた上述の通り、ユーザがネットワークアプリケーション２１８にログインしている場合にのみ、ユーザ識別子を取得することができる。

さらに別の実施形態において、ネットワークアプリケーション２１８は、オプションの提供によってユーザが取引を完了できる確率が高くなると判断した場合、電子商取引支払ファシリテータ１０６ａを使用するオプションを商取引アプリケーション１０４ａが提供すべきと判定することができる。特に、電子商取引支払ファシリテータ１０６ａは、商取引アプリケーション１０４ａおよび上記因子のうちの１つまたは複数に基づいて、ユーザの予測転換率を決定することができる。商取引アプリケーション１０４ａが提供する平均転換率よりも予測転換率が大きい場合、ネットワークアプリケーション２１８は、商取引アプリケーション１０４ａがオプションを提供すべきと判定することができる。商取引アプリケーション１０４ａが提供する平均転換率よりも予測転換率が小さい場合、ネットワークアプリケーション２１８は、商取引アプリケーション１０４ａがオプションを提供すべきでないと判定することができる。

たとえば、商取引アプリケーション１０４ａが提供する平均転換率には、商品またはサービスを買い物かごに追加した後、上記商品またはサービスの購入を完了した商取引アプリケーション１０４ａのユーザの割合に等しい０〜１００の整数を含み得る。予測転換率は、任意の商取引アプリケーションを用いることにより、ネットワークアプリケーション２１８を使用するオプションが提示された場合の精算をユーザが完了した回数の割合、任意の商取引アプリケーションを使用するネットワークアプリケーション２１８のユーザが、電子商取引支払ファシリテータ１０６ａを使用するオプションが提示された場合の精算を完了した回数の割合、商取引アプリケーション１０４ａを使用するネットワークアプリケーション２１８のユーザが、電子商取引支払ファシリテータ１０６ａを使用するオプションが提示された場合の精算を完了した回数の割合、ユーザに共通の年齢、性別等の人口統計学的情報が類似するユーザが、電子商取引支払ファシリテータ１０６ａを使用するオプションを提示された場合の精算を完了した回数の割合、支払情報の量が類似するユーザ
が、電子商取引支払ファシリテータ１０６ａを使用するオプションを提示された場合の精算を完了した回数の割合、支払カードを記録されたユーザが、電子商取引支払ファシリテータ１０６ａを使用するオプションを提示された場合の精算を完了した回数の割合、これら割合の組み合わせ、または別の経験則を用いて計算された別の割合と等しくすることができる。電子商取引支払ファシリテータ１０６ａは、ソーシャルグラフモジュール２２２、取引データベース２３２、および／またはプロフィール記憶モジュール２２８の情報を活用して、予測転換率を決定できることが理解される。

また、電子商取引支払ファシリテータ１０６ａを使用するオプションの提供によってユーザが取引を完了できる確率が高くなるか否かの判定は、決定モデルの適用に基づいて行うことができ、この決定モデルは、機械学習アルゴリズムによって生成される。これにより、本発明の一実施形態において、電子商取引支払ファシリテータ１０６ａは、ネットワークアプリケーション２１８の他のユーザによる電子商取引支払ファシリテータ１０６ａの実際の使用を解析することによって決定モデルを作成するように構成された機械学習アルゴリズムを含む。たとえば、機械学習アルゴリズムは、電子商取引支払ファシリテータ１０６ａの他の使用に基づいて、特定種類の店舗で買い物する特定の年齢範囲の特定の性別のユーザが、商取引アプリケーション１０４ａを用いて注文しつつ、ネットワークアプリケーション２１８により記憶された支払情報を利用する可能性が非常に高いと判定するようにしてもよい。これらの測定基準は一例に過ぎず、実際の機械学習アルゴリズムは、ユーザおよび／または注文状況（日時、商取引アプリケーション１０４ａの種類等）を記述した指標のさまざまな組み合わせを連続して判定することにより、決定モデルを生成できることが理解される。一実施形態において、決定モデルは、分類子である。

上述の通り、電子商取引支払ファシリテータ１０６ａを使用するオプションの提供によってユーザが取引を完了できる確率が高くなるか否かの判定における上記因子のうちの１つは、上記ユーザのリスクスコアである。このリスクスコアには、ユーザ１０２が注文を完了できないリスク、無効な支払情報を提供するリスク、商品を返品しようとするリスク、または別の望ましくないアクションを起こすリスクがどの程度考えられるかについての予測を含み得る。一実施形態において、リスクスコアは、０〜１００の整数である。別の実施形態において、リスクスコアは、「Ａ」〜「Ｆ」の文字であるが、他の実施形態では、他の尺度が用いられる。電子商取引支払ファシリテータ１０６ａは、予測転換率に関して上述したのと同様の機械学習アルゴリズムにより生成された決定モデルを用いてリスクスコアを計算することができる。

リスクスコアは、支払カードに関連付けられているリスクデータおよびユーザに関連付けられているリスクデータに基づくことができる。たとえば、支払カードのリスク因子としては、カードが新しいか否か、カードの以前の使用に問題がなかったか、ユーザがカードの追加および削除を頻繁に行っているか否か、カードのチャージバックが多いか否か等が挙げられる。ユーザのリスク因子としては、ユーザがネットワークアプリケーション２１８のアカウントを有していた時間の長さ、ユーザがネットワークアプリケーション２１８を用いて如何にアクティブであったか、他のユーザが上記ユーザの誕生日を祝うか否か、上記ユーザが他のユーザに対してメッセージを送受信するか否か等、ユーザの友達および友達を表すメタデータの数（ネットワークアプリケーション２１８がソーシャルネットワーキングシステム２２０を含む一実施形態において）、ユーザの写真の数、ユーザの地理的位置、またはユーザに関連付けられているデバイス等が挙げられる。

ソーシャルグラフモジュール２２２に関連付けられている情報によれば、潜在的な詐欺行為に対する有用な洞察の提供または盗難の識別がリスクスコアにより可能であることが理解される。たとえば、ユーザが短期間に膨大な数の購入を行おうとした場合、買い物パターンを大幅に変化させた場合、現在位置（ソーシャルネットワーキングシステムへの報
告に基づく）と異なる位置（ＩＰアドレスに基づく）で商取引アプリケーションにアクセスしている場合等に、リスクスコアは高くなる可能性がある。

１つまたは複数の実施形態において、電子商取引支払ファシリテータ１０６ａは、リスクスコアが閾値を上回る場合に、上記電子商取引支払ファシリテータ１０６ａを使用するオプションの提供を決定することができる。この閾値は、取引の金額に基づくことができる。たとえば、取引が第１の金銭的価値である場合、電子商取引支払ファシリテータ１０６ａがオプションを提供しないと決定するリスク閾値としては、第１の値が可能である。取引が第１の金銭的価値よりも高い第２の金銭的価値である場合、電子商取引支払ファシリテータ１０６ａがオプションを提供しないと決定するリスク閾値としては、第１の値よりも低い第２の値が可能である。さらに別の実施形態において、電子商取引支払ファシリテータ１０６ａは、リスクスコアを商取引アプリケーション１０４ａに返して、ユーザの取引完了を可能とするか否かを商取引アプリケーション１０４ａが判定できるようにすることが可能である。

図４のステップ４０６に示すように、電子商取引支払ファシリテータ１０６ａは、エンゲージメント応答を商取引アプリケーション１０４ａに提供可能である。エンゲージメント応答は、電子商取引アプリケーション１０４ａを用いて取引を完了するオプションを上記商取引アプリケーション１０４ａがユーザに提供すべきか否かを示すことができる。たとえば、支払情報の提供によって、商取引アプリケーション１０４ａからの１つまたは複数の商品またはサービスの購入をユーザが完了できる確率が高くなる可能性がある場合、電子商取引支払ファシリテータ１０６ａは、肯定的エンゲージメント応答を送信することができる。一方、支払情報の提供によって、商取引アプリケーション１０４ａからの１つまたは複数の商品またはサービスの購入をユーザが完了できる確率が高くなる可能性がない場合、電子商取引支払ファシリテータ１０６ａは、否定的エンゲージメント応答を送信することができる。一実施形態において、エンゲージメント応答には、電子商取引支払ファシリテータ１０６ａを使用するオプションを提供すべきか否かを示すブール値（すなわち、真または偽）を含む。この追加または代替として、エンゲージメント応答には、リスクスコアを含み得る。

エンゲージメント応答に基づいて、商取引アプリケーション１０４ａは、図３Ａに関して上述した精算オプションの提供（３１２）、ユーザがすべての支払情報を入力する必要があるデフォルトの精算オプションの提供、またはリスクスコアに基づいて、取引のリスクが高過ぎることによる精算要求の拒否が可能である。電子商取引支払ファシリテータ１０６ａを用いて精算を行うオプションが提供された場合、図４のタイムラインフローは、図３Ａのステップ３１４に継続可能である。

さらに別の実施形態において、記憶された支払情報を使用するオプションの知的かつ動的な提供は、図３Ａおよび図３Ｂに関して上述した以外の他の支払方法／インフラに関連して使用可能である。特に、１つまたは複数の実施形態において、電子商取引支払ファシリテータ１０６ａは、支払ゲートウェイシステムとして作用し、ユーザの支払情報を支払処理システムに直接転送することができる。このような実施態様において、取引の金額は、ネットワークアプリケーション２１８または電子商取引支払ファシリテータ１０６ａから直接、商取引アプリケーション１０４ａの口座に支払い可能である。

上記説明を踏まえると、電子商取引支払ファシリテータ１０６ａは、従来の商取引アプリケーションの支払プロセスおよび精算プロセスに対して、多大な利益をもたらすことが理解される。上述の通り、電子商取引支払ファシリテータ１０６ａは、商取引アプリケーション１０４ａに自動的に埋められる支払情報を提供することによって、精算プロセスの容易化および迅速化が可能である。図５Ａ〜図５Ｇは、電子商取引支払ファシリテータ１
０６ａを利用した商取引アプリケーション１０４ａの精算プロセスのユーザインターフェースを示している。

特に、図５Ａ〜図５Ｇのユーザインターフェースは、モバイルデバイス５００により提示されるようになっていてもよい。モバイルデバイス５００は、携帯電話機である。ただし、付加的または代替的な例において、図５Ａ〜図５Ｇのユーザインターフェースを提示可能な別のモバイルまたは非モバイルデバイスとしては、携帯電話機、携帯機器、ラップトップコンピュータ、個人用デジタル補助デバイス、および／またはその他任意の適当な機器等が挙げられるが、これらに限定されない。モバイルデバイス５００は、ユーザインターフェースの提示および／またはユーザ入力の受け付けおよび／もしくは検出が可能なタッチスクリーン５０２を備えることおよび／またはそのようなタッチスクリーン５０２との関連付けが可能である。この追加または代替として、モバイルデバイス５００は、その他任意の適当な入力デバイス（たとえば、キーパッド、１つまたは複数の入力ボタン等）を備えてもよい。いくつかの例において、ユーザは、タッチスクリーン５０２を利用して、１つもしくは複数のタッチジェスチャの提供、インターフェースとの対話、および／または支払情報の提供を行うようにしてもよい。

図５Ａは、ユーザが１つまたは複数の商品またはサービスの購入のために選択可能な商取引アプリケーション１０４ａのユーザインターフェース５０４を示している。特に、図５Ａは、ユーザが１ポンドのリンゴの購入を選択可能であることを示している。ユーザが選択可能なオプション５０６（たとえば、「Ａｄｄ ｔｏ ｓｈｏｐｐｉｎｇ ｃａｒｔ（買い物かごに追加）」ボタン）を選択すると、図５Ｂに示すように、第２のユーザインターフェース５０８が表示され得る。第２すなわち仮想買い物かごのユーザインターフェース５０８は、ユーザが購入を望む商品および／またはサービスを示した仮想買い物かごのビューを提供可能である。この例において、仮想買い物かごは、第２のユーザインターフェース５０８に示すように、１ポンドのリンゴ、税、ならびに送料および手数料を含み、合計＄７．１７である。

第２のユーザインターフェース５０８は、ユーザが操作して「精算」を行う（たとえば、買い物かご中の商品の購入を完了する）ことができるユーザ選択可能な要素（たとえば、ボタン５１０）を含む。図３Ａに関して上述した通り、ユーザがボタン５１０を選択すると、商取引アプリケーション１０４ａは、ユーザ識別情報および買い物かご情報を電子商取引支払ファシリテータ１０６ａに送信することができる。

あるいは、図４に関して上述した通り、ユーザが精算ボタン５１０を選択すると、商取引アプリケーション１０４ａは、ファシリテータエンゲージメント要求を送信することができる（４０２）。これに対して、電子商取引支払ファシリテータ１０６ａは、記憶した情報を使用して仮想買い物かごの精算を完了するオプションを提供するか否かを判定することができる（４０４）。この特定の実施形態において、電子商取引支払ファシリテータ１０６ａは、正（商取引アプリケーション１０４ａがオプションを提供すべきであることを示す）または負（商取引アプリケーション１０４ａがオプションを提供すべきでないことを示す）のエンゲージメント応答を提供する（４０６）。

エンゲージメント応答（４０６）に応答して、商取引アプリケーション１０４ａは、図５Ｃに示すように、精算ユーザインターフェース５１２をレンダリング可能である。精算ユーザインターフェース５１２には、ユーザの支払情報を入力可能な複数の支払フィールド５１３を含み得る。また、精算ユーザインターフェース５１２には、ユーザがネットワークアプリケーション２１８に関連付けられている電子商取引支払ファシリテータ１０６ａを利用して、商取引アプリケーション１０４ａの仮想買い物かご中の商品の購入を完了可能であることを示すグリフ（すなわち、マーク、アイコン、グラフィック、テキストの
一部等）を含む選択可能な精算オプション５１４を含み得る。図示の実施形態において、グリフは、フェースブック（登録商標）アイコンを含む。

図５Ｃに示すように、少なくとも１つの実施形態において、選択可能な精算オプション５１４には、精算ユーザインターフェース５１２の一部を覆う選択可能なオーバーレイを含み得る。商取引アプリケーション１０４ａは、オーバーレイの選択可能な精算オプション５１４をレンダリングするＳＤＫ機能を呼び出すことができる。本明細書の開示を踏まえれば、オーバーレイの選択可能な精算オプション５１４は、多くの利点をもたらし得る。たとえば、オーバーレイの選択可能な精算オプション５１４は、精算ユーザインターフェース５１２上で動くことが可能であることが理解される。これにより、オーバーレイの選択可能な精算オプション５１４が商取引アプリケーション１０４ａから分離していることをユーザに通知し、オーバーレイの選択可能な精算オプション５１４をより目立たせ、ひいてはオーバーレイの選択可能な精算オプション５１４の選択率の向上に役立つことができる。別の実施形態において、選択可能な精算オプション５１４には、オーバーレイの代わりに、プラグイン、ポップアップ、埋め込みボタン等の選択可能なオプションを含み得る。

図５Ｃは、選択可能な精算オプション５１４がキャンセルまたは最小化を選択可能なオプション５１６（図５Ｃに「ｘ」と示す）を含み得ることを示している。ユーザは、ネットワークアプリケーション２１８による精算プロセスの完了を好まない場合、キャンセルまたは最小化を選択可能なオプション５１６を選択することができる。キャンセルまたは最小化を選択可能なオプション５１６を選択することによって、図５Ｄに示すように、オーバーレイの選択可能な精算オプション５１４を選択可能なアイコン等の要素５１８へと最小化することができる。特に、図５Ｄは、選択可能なアイコン５１８が鉛筆のアイコンを含み得ることを示している。ユーザが選択可能なアイコン５１８を選択すると、選択可能な精算オプション５１４は、図５Ｃに示すように、再現、最大化、あるいはオープン可能である。ユーザが選択可能な精算オプション５１４を選択すると、商取引アプリケーション１０４ａは、図３Ｂに関して上述した通り、精算オプションの選択を示す標識を提供することができる（３１６）。

エンゲージメント応答（４０６）が負である場合、商取引アプリケーション１０４ａは、ネットワークアプリケーション２１８からの情報を用いて注文を完了するための選択可能な精算オプション５１４を伴わない精算ユーザインターフェース５１２を提供することができる。このような実施形態において、ユーザは、支払フィールド５１３に手動で情報を入力して注文の購入を完了することが必要となる場合がある。

この時点で、ネットワークアプリケーション２１８／電子商取引支払ファシリテータ１０６ａから支払情報を受信する許可をユーザが商取引アプリケーション１０４ａに付与していない場合は、図５Ｅに示すように、許可ユーザインターフェース５２０をユーザに提示して、商取引アプリケーション１０４ａとの支払情報の共有に関するユーザの許可を得ることができる。図５Ｅに示すように、許可ユーザインターフェース５２０としては、ネットワークアプリケーション２１８（この場合は、フェースブック（登録商標））のインターフェースが可能である。したがって、アプリケーションの切り替えにより、許可ユーザインターフェース５２０を提示することができる。別の実施態様において、許可ユーザインターフェース５２０には、アプリケーションの切り替えが不要となるように、オーバーレイ、ポップアップ、または商取引アプリケーション１０４ａのインターフェースを含み得る。さらに、商取引アプリケーション１０４ａがウェブベースのアプリケーションを含む実施態様において、許可ユーザインターフェースには、プラグイン、Ｉフレーム、ポップアップ等のインターフェースを含み得る。たとえば、商取引アプリケーション１０４ａ上でＩフレームを使用することにより、商取引アプリケーション１０４ａとの支払情報
の供給をユーザに指示することができる。Ｉフレームによって、ユーザネットワーキングアプリケーション２３６（すなわち、モバイルデバイス上のネイティブＳＮＳアプリケーション）は、許可ＵＩ５２０を提示可能である。商取引アプリケーション１０４ａとの支払情報の共有の許可をユーザが付与すると、ユーザネットワーキングアプリケーション２３６は、ネットワークアプリケーション２１８を呼び出して支払情報をフェッチすることができ、その後、商取引アプリケーション１０４ａの精算ＵＩには、この支払情報が自動的に埋められるあるいは入力される。別の実施形態においては、ユーザネットワーキングアプリケーション２３６ではなく商取引アプリケーション１０４ａがネットワークアプリケーション２１８を呼び出して、支払情報を要求することができる。

図５Ｅを再び参照して、許可ユーザインターフェース５２０は、ユーザの支払情報を商取引アプリケーション１０４ａに提供する許可をネットワークアプリケーション２１８に付与する選択可能なオプション５２２を提供することができる。許可ユーザインターフェース５２０には、ユーザの支払情報に対する商取引アプリケーション１０４ａのアクセスを拒否するようにユーザが選択できる選択可能なオプション５２４をさらに含み得る。

ユーザの支払情報を商取引アプリケーション１０４ａに提供する許可をネットワークアプリケーション２１８に付与する選択可能なオプション５２２をユーザが選択すると、電子商取引支払ファシリテータ１０６ａは、（上述のグラフＡＰＩ呼び出しによって）支払情報、支払トークン、およびカードラベルを商取引アプリケーション１０４ａに提供することができる。商取引アプリケーション１０４ａは、図５Ｆおよび図５Ｇに示すように、電子商取引支払ファシリテータ１０６ａから受信したユーザの支払情報により自動的に埋められた精算ユーザインターフェース５２６を表示することができる。ユーザが選択可能なオプション５２２を選択して精算ユーザインターフェース５２６を表示した後には、第２のアプリケーション切り替えによって、ネットワークアプリケーション２１８を商取引アプリケーション１０４ａに戻せることが理解される。ネットワークアプリケーション２１８がユーザの支払情報を商取引アプリケーション１０４ａに提供する許可をユーザが以前に提供済みである場合は、選択可能な精算オプション５１４をユーザが選択した直後とする。

精算ユーザインターフェース５２６には、支払カードラベル５２８等、ユーザの支払情報が自動的に埋められた支払フィールド５１３を含み得る。精算ユーザインターフェース５２６には、支払買い物かごセレクタ５２７をさらに含み得る。これによりユーザは、電子商取引支払ファシリテータ１０６ａにより上記ユーザに関して記憶された複数の支払カードの中から、支払カードを選択することができる。精算ユーザインターフェース５２６には、選択可能な支払オプション５３０をさらに含み得る。ユーザが選択可能な支払オプション５３０を選択して注文の購入を確認すると、商取引アプリケーション１０４ａは、上述の通り、クレジット払い要求を電子商取引支払ファシリテータ１０６ａに送信することができる。

図５Ｇは、支払情報をネットワークアプリケーション２１８（この例では、フェースブック（登録商標））に保存するオプション（５３２）を精算ユーザインターフェース５２６が含み得ることをさらに示している。これにより、精算ユーザインターフェース５２６においてユーザが追加／変更した任意の更新情報または支払情報を保存する許可をネットワークアプリケーション２１８に与えることができる。たとえば、１つまたは複数の実施態様において、電子商取引支払ファシリテータ１０６ａは、ユーザの氏名および住所の情報のみを有していてもよい。したがって、電子商取引支払ファシリテータ１０６ａにより提供された支払情報が支払フィールド５１３に自動的に埋められた後であっても、ユーザは依然として、支払カードの情報を入力する必要がある。支払情報を保存するオプション（５３２）が選択された場合、ユーザが精算ユーザインターフェース５２６に入力した支
払カード情報は、ネットワークアプリケーションによって、ユーザのプロフィールに保存されることになる。これにより、電子商取引支払ファシリテータ１０６ａは、商取引アプリケーション１０４ａまたは別の商取引アプリケーションを用いることにより、後々の購入において、この支払カード情報を提供することができる。

上記開示を踏まえれば、電子商取引支払ファシリテータ１０６ａは、商取引アプリケーション１０４ａからの買い物の容易さを大幅に増大できることが理解される。精算プロセスの迅速化および容易化によって、電子商取引支払ファシリテータ１０６ａは、購入の拡大および買い物かごの放棄の低減に役立ち得る。また、本発明の１つまたは複数の実施形態では、放棄された買い物かごの取り戻しがさらに可能である。特にユーザは、時間不足、ネットワーク接続の喪失等の理由によって、買い物かご中の商品の購入を完了できない場合が多い。１つまたは複数の実施形態では、放棄した買い物かご中の商品を後で購入する機会をユーザに与えることができる。これによりユーザは、商品／サービスを買い物かごに再び入れる煩わしさが減り、ユーザにとってのリマインダとして機能するとともに、放棄された買い物かごを業者が取り戻すことができる。

より具体的には、電子商取引支払ファシリテータ１０６ａは、商取引アプリケーション１０４ａから詳細な買い物かご情報を受信した場合（たとえば、ステップ３１６参照）、この詳細な情報を未完了取引として取引データベース２３２に記憶することができる。ユーザが取引を完了すると、電子商取引支払ファシリテータ１０６ａは、取引データベースにおいて、上記取引に完了のマーク付けを行うことができる。取引が完了していない場合（すなわち、電子商取引支払ファシリテータ１０６ａが適用可能な支払トークンとともにクレジット払い要求を受信していない場合または支払カードが拒否された場合）、ネットワークアプリケーション２１８は、買い物かご中の商品の購入を完了する別の機会をユーザに与えることができる。

特に、ネットワークアプリケーション２１８は、ソーシャルネットワークを含む場合、購入メッセージをユーザに送信することができる。たとえば、図６は、ユーザに対するニュースフィードに含まれた例示的な購入メッセージ６００を示している。別の実施態様において、ネットワークアプリケーション２１８は、テキストメッセージ、電子メール、または上記ネットワークアプリケーション２１８により可能な他の通信形態によって、購入メッセージ６００をユーザに送信することができる。購入メッセージ６００には、放棄された買い物かご中の商品の詳細（商品名、商品価格等）を含み得る。購入メッセージ６００には、商取引アプリケーション１０４ａを示す標識および買い物かごの購入の試行時間をさらに含み得る。購入メッセージ６００には、断念した取引をユーザが完了できる選択可能な購入オプション（図６に示す購入ボタン６０２等）をさらに含み得る。

より具体的には、選択可能な購入オプション６０２をユーザが選択することによって、買い物かご中の商品の購入をユーザが完了できる仮想買い物かごのユーザインターフェース５０８（図５Ｂ参照）へとユーザを誘導するディープリンクを起動することができる。このような実施態様において、商取引アプリケーション１０４ａは、買い物かごが有効な時間の長さを示す標識を電子商取引支払ファシリテータ１０６ａに提供することができる。この情報は、上述のグラフＡＰＩ呼び出しに含まれ得る。

あるいは、選択可能な購入オプション６０２の選択によって、ユーザは、商取引アプリケーション１０４ａへのリダイレクトの必要なく、ネットワークアプリケーション２１８から直接、商品の購入を完了することができる。このような実施形態において、ネットワークアプリケーション２１８は、記憶されたユーザの支払情報を用いて、取引を完了することができる。ネットワークアプリケーション２１８は、ユーザが以前に断念した取引を完了するオプションを上記ユーザに提供することができる。

この追加または代替として、ネットワークアプリケーション２１８は、放棄された買い物かごまたは完了した買い物かご中の商品をユーザのプロフィールと関連付けることができる。そして、この情報を用いることにより、商取引アプリケーションの業者または同様の業者が提供する類似商品またはサービスのターゲット広告をユーザに提示することができる。

図１〜図６、対応するテキスト、および上記例は、商取引アプリケーションの購入を容易に行わせる多くの異なるシステムおよびデバイスを提供する。上記のほか、本発明の実施形態は、特定の結果を実現する方法の行為およびステップを含むフローチャートの観点で記載することもできる。たとえば、図７〜図１０は、本発明の１つまたは複数の実施形態に係る、例示的な方法のフローチャートを示している。

図７は、電子商取引支払ファシリテータ１０６ａまたはネットワークアプリケーション２１８の観点から、商取引アプリケーションにおける購入を容易に行わせる例示的な方法７００のフローチャートを示している。方法７００には、商取引アプリケーションからの要求を受信する行為７０２を含み得る。特に、行為７０２には、商取引アプリケーション１０４ａからの要求（３１６）の受信を含み得る。要求（３１６）には、ユーザのユーザ識別情報および商取引アプリケーション１０４ａから購入が選択された１つまたは複数の商品またはサービスに対するクレジット払い額を含み得る。１つまたは複数の実施形態において、要求（３１６）の受信には、ユーザによる１つまたは複数の支払フィールド５１３を自動的に埋めるための支払情報を求めるクライアントサイドのグラフＡＰＩ要求（すなわち、コンピューティングデバイス２０２またはデバイス５００からのＡＰＩ呼び出し）を受信することを含み得る。

また、方法７００は、支払トークンを生成する行為７０４を含んでいてもよい。特に、行為７０４には、非一時的記憶媒体に記憶されたユーザの支払カード明細を参照する支払トークンの生成を伴い得る。より具体的には、サーバコンピューティングデバイス２１６のトークン生成器２３４は、電子商取引支払ファシリテータ１０６ａのプロフィール記憶モジュール２２８に記憶された１つまたは複数の支払カード番号を参照する支払トークンを生成することができる。

方法７００には、ネットワークアプリケーション２１８のユーザのユーザ識別情報に対する上記ユーザのＩＤのマッピングをさらに含み得ることが理解される。これにより、電子商取引支払ファシリテータ１０６ａは、プロフィール記憶モジュール２２８に記憶されたユーザのプロフィールを識別することができる。１つまたは複数の実施形態において、ユーザのＩＤのマッピングには、ユーザ１０２のＩＤに対する変換関数の適用を伴い得る。

図７は、支払トークンを商取引アプリケーションに送信する行為７０６を方法７００が含み得ることをさらに示している。より具体的には、行為７０６には、クライアントサイドのグラフＡＰＩ要求に対する応答（３１８）において、サーバコンピューティングデバイス２１６が支払トークンを商取引アプリケーション１０４ａに送信することを伴い得る。支払トークンの送信のほか、応答（３１８）には、ユーザ１０２の支払情報および支払カードラベル５２８をさらに含み得る。

また、方法７００には、支払トークンを含むクレジット払い要求を受信する行為７０８を含み得る。特に、行為７０８には、支払トークンを含むクレジット払い要求の商取引アプリケーション１０４ａからの受信（３２８）を伴い得る。たとえば、行為７０８には、サーバサイドの支払ＡＰＩ要求のサーバコンピューティングデバイス２１４からの受信を
伴い得る。より具体的には、行為７０８には、任意選択として、商取引アプリケーション１０４ａに関連付けられているサーバコンピューティングデバイス２１４にクレジット払い要求（３２８）が由来することの検証を伴い得る。

上記のほか、方法７００には、支払のクレジット払い要求を支払ゲートウェイシステムに送信する行為７１０を含み得る。具体的に、行為７１０には、ネットワークアプリケーション２１８を実行するサーバコンピューティングデバイス２１６によって、商取引アプリケーション１０４ａに関連付けられている支払ゲートウェイシステム１０８に支払のクレジット払い要求を送信すること（３３０）を伴い得る。支払のクレジット払い要求（３３０）には、支払カード明細（すなわち、番号および有効期限）、クレジット払い額、および商取引アプリケーション１０４ａに代わってクレジット払い要求を提出する許可を示す標識を含み得る。この許可を示す標識には、支払ゲートウェイシステム１０８から商取引アプリケーション１０４ａに提供された秘密鍵を用いて支払のクレジット払い要求（３３０）の少なくとも一部を暗号化することまたは商取引アプリケーション１０４ａに代わって、電子商取引支払ファシリテータ１０６ａが作用していることを示す他の方法のうちの１つを含み得る。

ここで、図８は、商取引アプリケーションの観点から、上記商取引アプリケーションにおける購入を容易に行わせる例示的な方法８００のフローチャートを示している。図示のように、方法８００には、ユーザ識別情報および注文に対するクレジット払い額を含む情報要求を送信する行為８０２を含み得る。たとえば、行為８０２には、サーバコンピューティングデバイス２１６への情報要求の送信（３１０または３１６）を伴い得る。この要求は、商取引アプリケーション１０４ａの少なくとも第１の部分を実行するクライアントコンピューティングデバイス２０２から送信可能である。要求（３１０／３１６）には、ユーザのユーザ識別情報および商取引アプリケーション１０４ａを用いてユーザが購入のために選択した注文に対するクレジット払い額を含み得る。１つまたは複数の実施形態において、行為８０２には、ネットワークアプリケーション２１８のグラフＡＰＩの呼び出しを含み得る。

方法８００には、支払カードラベル、支払トークン、および支払情報を受信する行為８０４をさらに含み得る。具体的に、行為８０４には、サーバコンピューティングデバイス２１６による支払カードラベル、支払トークン、および支払情報の商取引アプリケーション１０４ａへの送信（３１８）を伴い得る。そして、方法８００には、支払カードラベルおよび支払情報により支払フィールドを自動的に埋める行為８０６を含み得る。たとえば、商取引アプリケーション１０４ａは、支払カードラベル５２８および任意の付加的な支払情報により精算ユーザインターフェース５１２の支払フィールド５１３を自動的に埋めることができる。

図８に示すように、方法８００には、支払トークンを含むクレジット払い要求を送信する行為８０８を含み得る。より具体的には、行為８０８には、サーバコンピューティングデバイス２１６へのクレジット払い要求の送信（３２８）を伴い得る。たとえば、行為８０８には、サーバコンピューティングデバイス２１４によるネットワークアプリケーション２１８の支払ＡＰＩの呼び出しを伴い得る。

ここで、図９は、電子商取引支払ファシリテータ１０６ａまたはネットワークアプリケーション２１８の観点から、ネットワークアプリケーションを使用して支払取引を支援するオプションを知的かつ動的に提供する方法９００を示している。方法９００には、ユーザを示す標識を含むエンゲージメント要求を受信する行為９０２を含み得る。特に、行為９０２には、商取引アプリケーション１０４から１つまたは複数の商品またはサービスの購入を選択したユーザを示す標識を含む商取引アプリケーション１０４ａからのエンゲー
ジメント要求の受信（４０６）を伴い得る。たとえば、行為９０２には、ネットワークアプリケーション２１８のグラフＡＰＩのエンゲージメント呼び出しの受信（４０６）を伴い得る。

方法９００には、支払情報の提供によって購入の確率が高くなる可能性があるか否かを判定する行為９０４をさらに含み得る。より具体的には、行為９０４には、支払情報の提供によって、商取引アプリケーション１０４ａからの１つまたは複数の商品またはサービスの購入をユーザが完了できる確率が高くなる可能性があるか否かの判定（４０４）を伴い得る。たとえば、行為９０４には、図４に関して上述した、支払オプションを提供するか否かの判定（４０４）を行う方法のいずれかを含み得る。たとえば、行為９０４には、予測転換率の決定および上記予測転換率が商取引アプリケーション１０４ａの平均転換率よりも大きいか否かの判定を含み得る。この追加または代替として、行為９０４には、ユーザ１０２が支払情報を利用可能であるか否かの判定を伴い得る。

また、方法９００には、エンゲージメント応答の提供（４０６）を行う行為９０６を含み得る。行為９０６には、肯定的エンゲージメント応答を提供するステップ９０６ａまたは否定的エンゲージメント応答を提供するステップ９０６ｂを伴い得る。ステップ９０６ａには、支払情報の提供によって、商取引アプリケーション１０４ａからの１つまたは複数の商品またはサービスの購入をユーザ１０２が完了できる確率が高くなる可能性がある場合に、肯定的エンゲージメント応答の提供（４０６）を含み得る。一方、ステップ９０６ｂには、支払情報の提供によって、商取引アプリケーション１０４ａからの１つまたは複数の商品またはサービスの購入をユーザ１０２が完了できる確率が高くなる可能性がない場合に、否定的エンゲージメント応答の提供（４０６）を含み得る。

図１０は、商取引アプリケーション１０４ａの観点から、ネットワークアプリケーションを使用して支払取引を支援するオプションを知的かつ動的に提供する方法１０００を示している。図示のように、方法１０００には、ユーザ識別情報を含むエンゲージメント要求を送信する行為１００２を含み得る。より具体的には、行為１００２には、商取引アプリケーション１０４ａの少なくとも第１の部分を実行するクライアントコンピューティングデバイス２０２から、ネットワークアプリケーション２１８を実行するサーバコンピューティングデバイス２１６にエンゲージメント要求を送信すること（５０２）を伴い得る。たとえば、行為１００２には、ネットワークアプリケーション２１８のグラフＡＰＩのエンゲージメント呼び出しの送信（４０６）を伴い得る。

方法１０００には、精算ユーザインターフェースを提供する行為１００４をさらに含み得る。行為１００４には、ステップ１００４ａまたはステップ１００４ｂを伴い得る。ステップ１００４ａには、ネットワークアプリケーションからの情報を用いて注文を完了するオプションの提供を含み得る。特に、ステップ１００４ａには、ユーザがネットワークアプリケーション２１８／電子商取引支払ファシリテータ１０６ａを利用して、商取引アプリケーション１０４ａの仮想買い物かご中の商品の購入を完了可能であることを示す選択可能な精算オプション５１４のレンダリングを伴い得る。たとえば、上述の通り、商取引アプリケーション１０４ａは、選択可能な精算オプション５１４をレンダリングするＳＤＫ機能を呼び出すことができる。

一方、ステップ１００４ｂには、ネットワークアプリケーションからの支払情報を用いて注文を完了するオプションを備えていない精算ユーザインターフェースの提供を伴い得る。特に、商取引アプリケーション１０４ａは、支払フィールド５１３を含む精算ユーザインターフェース５１２をレンダリング可能である。商取引アプリケーション１０４ａは、選択可能な精算オプション５１４のレンダリングあるいは提供を行わずに、精算ユーザインターフェース５１２をレンダリング可能である。

また、方法１００には、ユーザによるオプションの選択に際して、ネットワークアプリケーションからの支払情報により支払フィールドを自動的に埋める行為１００６を含み得る。特に、行為１００６には、ネットワークアプリケーション２１８から受信した支払情報を精算ユーザインターフェース５１２の支払フィールド５１３に入力することを伴い得る。支払情報には、氏名、請求先住所、および支払カードラベル５２８を含み得る。支払情報は、商取引アプリケーション１０４ａから送信された支払ＡＰＩ呼び出しに応答して、ネットワークアプリケーション２１８から受信可能である。

本発明の実施形態では、以下に詳述する通り、たとえば１つまたは複数のプロセッサおよびシステムメモリ等のコンピュータハードウェアを備えた専用または汎用コンピュータを備えるか、または利用するようにしてもよい。また、本発明の範囲内の実施形態には、コンピュータ実行可能な命令および／またはデータ構造を搬送または記憶する物理的なコンピュータ可読媒体および他のコンピュータ可読媒体を含む。特定の実施形態において、本明細書に記載のプロセスのうちの１つまたは複数は、非一時的コンピュータ可読媒体にて具現化され、１つまたは複数のコンピューティングデバイス（たとえば、本明細書に記載のメディアコンテンツアクセスデバイスのいずれか）により実行可能な命令として、その少なくとも一部が実装されていてもよい。一般的には、プロセッサ（たとえば、マイクロプロセッサ）が非一時的コンピュータ可読媒体（たとえば、メモリ等）から命令を受け取り、これらの命令を実行することによって、本明細書に記載のプロセスのうちの１つまたは複数等、１つまた複数のプロセスを実行する。

コンピュータ可読媒体としては、汎用または専用コンピュータシステムによりアクセス可能な任意の利用可能な媒体が可能である。コンピュータ実行可能な命令を記憶するコンピュータ可読媒体は、非一時的コンピュータ可読記憶媒体（デバイス）である。コンピュータ実行可能な命令を搬送するコンピュータ可読媒体は、伝送媒体である。このように、非限定的な一例として、本発明の実施形態には、非一時的コンピュータ可読記憶媒体（デバイス）および伝送媒体という少なくとも２つの明確に異なる種類のコンピュータ可読媒体を含み得る。

非一時的コンピュータ可読記憶媒体（デバイス）としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、固体ドライブ（「ＳＳＤ」）（たとえば、ＲＡＭベース）、フラッシュメモリ、相変化メモリ（「ＰＣＭ」）、他の種類のメモリ、他の光ディスクストレージ、磁気ディスクストレージ等の磁気ストレージデバイス、またはコンピュータ実行可能な命令もしくはデータ構造の形態の所望のプログラムコード手段の記憶に使用可能であるとともに、汎用もしくは専用コンピュータによりアクセス可能なその他任意の媒体が挙げられる。

「ネットワーク」は、コンピュータシステムおよび／またはモジュールおよび／または他の電子機器間で電子データを伝送可能な１つまたは複数のデータリンクとして定義されている。情報がネットワークまたは別の通信接続（有線、無線、または有線もしくは無線の組み合わせ）上でコンピュータに転送または提供される場合、上記コンピュータは、その接続を厳密に伝送媒体と見なす。伝送媒体としては、コンピュータ実行可能な命令またはデータ構造の形態の所望のプログラムコード手段の搬送に使用可能であるとともに、汎用または専用コンピュータによりアクセス可能なネットワークおよび／またはデータリンクが挙げられる。また、上記の組み合わせについても、コンピュータ可読媒体の範囲に含まれるものとする。

さらに、コンピュータシステムのさまざまな構成要素に到達した際に、コンピュータ実行可能な命令またはデータ構造の形態のプログラムコード手段は、伝送媒体から非一時的
コンピュータ可読記憶媒体（デバイス）へと自動的に転送可能である（その逆も可能である）。たとえば、ネットワークまたはデータリンク上で受信されたコンピュータ実行可能な命令またはデータ構造は、ネットワークインターフェースモジュール（たとえば、「ＮＩＣ」）内のＲＡＭにバッファリングした後、最終的には、コンピュータシステムＲＡＭおよび／またはコンピュータシステムにおける低揮発性コンピュータ記憶媒体（デバイス）に転送可能である。したがって、非一時的コンピュータ可読記憶媒体（デバイス）は、伝送媒体も（または、主として）利用するコンピュータシステムの構成要素に含み得ることが了解されるものとする。

コンピュータ実行可能な命令としては、たとえばプロセッサで実行された場合に、特定の機能または機能群を汎用コンピュータ、専用コンピュータ、または専用処理デバイスに実行させる命令およびデータが挙げられる。いくつかの実施形態においては、コンピュータ実行可能な命令が汎用コンピュータ上で実行されることにより、上記汎用コンピュータは、本発明の要素を実装した専用コンピュータへと変化する。コンピュータ実行可能な命令は、たとえばバイナリ、アセンブリ言語等の中間フォーマット命令、あるいはソースコードであってもよい。以上、構造的特徴および／または方法論的行為に固有の表現で主題を説明したが、添付の特許請求の範囲に規定の主題は、必ずしも上述の特徴または行為に限定されないことが了解されるものとする。むしろ、上記特徴および行為は、特許請求の範囲を実施する例示的な形態として開示している。

当業者であれば、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、メッセージプロセッサ、携帯機器、マルチプロセッサシステム、マイクロプロセッサベースの家庭用電化製品またはプログラム可能な家庭用電化製品、ネットワークＰＣ、マイクロコンピュータ、メインフレームコンピュータ、携帯電話、ＰＤＡ，タブレット、ポケベル、ルータ、スイッチ等、さまざまな種類のコンピュータシステム構成のネットワークコンピュータ環境において実現されるようになっていてもよいことが認識されよう。また、本発明は、ネットワークを通じて（有線データリンク、無線データリンク、または有線および無線データリンクの組み合わせにより）リンクしたローカルメモリストレージデバイスおよび遠隔コンピュータシステムがともにタスクを実行する分散システム環境において実現されるようになっていてもよい。分散システム環境においては、ローカルメモリストレージデバイスおよび遠隔メモリストレージデバイスの両者にプログラムモジュールが配置されていてもよい。

また、本発明の実施形態は、クラウドコンピュータ環境において実装可能である。本明細書および以下の特許請求の範囲において、「クラウドコンピューティング」は、設定可能なコンピュータリソースの共有プールに対するオンデマンドネットワークアクセスを可能とするモデルとして定義されている。たとえば、クラウドコンピューティングは、設定可能なコンピュータリソースの共有プールに対するユビキタスかつ便利なオンデマンドアクセスを提供する市場で採用可能である。設定可能なコンピュータリソースの共有プールは、仮想化によって迅速にセットアップ可能であるとともに、わずかな管理労力またはサービスプロバイダ対話で解放可能であるため、これに応じてスケーリング可能である。

クラウドコンピューティングモデルは、たとえばオンデマンドセルフサービス、ブロードネットワークアクセス、リソースプーリング、ラピッドエラスティシティ、メジャードサービス等のさまざまな特性で構成可能である。また、クラウドコンピューティングモデルは、たとえばサービス型ソフトウェア（ＳａａＳ）、サービス型プラットフォーム（ＰａａＳ）、およびサービス型インフラ（ＩａａＳ）等のさまざまなサービスモデルを提供可能である。また、クラウドコンピューティングモデルは、プライベートクラウド、コミュニティクラウド、パブリッククラウド、ハイブリッドクラウド等のさまざまな展開モデルを用いて展開可能である。本明細書および特許請求の範囲において、「クラウドコンピ
ュータ環境」は、クラウドコンピューティングを採用する環境である。

図１１は、上述のプロセスのうちの１つまたは複数を実行するように構成できる例示的なコンピューティングデバイス１１００をブロック図の形態で示している。コンピューティングデバイス２０２、サーバコンピューティングデバイス２１５、サーバコンピューティングデバイス２１６、およびモバイルデバイス５００はそれぞれ、データコンピューティングデバイス１１００の実施態様を含み得ることが理解される。図１１に示すように、コンピューティングデバイスは、プロセッサ１１０２、メモリ１１０４、ストレージデバイス１１０６、Ｉ／Ｏインターフェース１１０８、および通信インターフェース１１１０を備えることができる。図１１には、例示的なコンピューティングデバイス１１００を示しているが、図１１に示す構成要素は、何ら限定を意図したものではない。他の実施形態においては、付加的または代替的な構成要素を使用するようにしてもよい。さらに、特定の実施形態において、コンピューティングデバイス１１００は、図１１よりも少ない構成要素を備える。以下、図１１に示すコンピューティングデバイス１１００の構成要素について、さらに詳しく説明する。

特定の実施形態において、プロセッサ１１０２は、コンピュータプログラムを構成する命令等を実行するハードウェアを備えてもよい。非限定的な一例として、プロセッサ１１０２は、命令を実行するため、内部レジスタ、内部キャッシュ、メモリ１１０４、またはストレージデバイス１１０６から命令を取り出す（または、フェッチする）とともに、上記命令を復号化して実行するようにしてもよい。特定の実施形態において、プロセッサ１１０２は、データ、命令、またはアドレス用の１つまたは複数の内部キャッシュを備えてもよい。非限定的な一例として、プロセッサ１１０２は、１つまたは複数の命令キャッシュ、１つまたは複数のデータキャッシュ、および１つまたは複数のトランスレーション・ルックアサイド・バッファ（ＴＬＢ）を備えてもよい。命令キャッシュ中の命令は、メモリ１１０４またはストレージデバイス１１０６中の命令のコピーであってもよい。

コンピューティングデバイス１１００は、プロセッサ１１０２に結合されたメモリ１１０４を備える。メモリ１１０４は、データ、メタデータ、およびプロセッサが実行するプログラムの記憶に使用してもよい。メモリ１１０４は、ランダムアクセスメモリ（「ＲＡＭ」）、リードオンリーメモリ（「ＲＯＭ」）、固体ディスク（「ＳＳＤ」）、フラッシュ、相変化メモリ（「ＰＣＭ」）、または他の種類のデータストレージ等、揮発性および不揮発性メモリのうちの１つまたは複数を備えていてもよい。また、メモリ１１０４は、内部メモリであってもよいし、分散メモリであってもよい。

コンピューティングデバイス１１００は、データまたは命令を記憶するストレージを備えたストレージデバイス１１０６を備える。非限定的な一例として、ストレージデバイス１１０６は、上述の非一時的記憶媒体を備えることができる。ストレージデバイス１１０６としては、ハードディスクドライブ（ＨＤＤ）、フロッピー（登録商標）ディスクドライブ、フラッシュメモリ、光ディスク、光磁気ディスク、磁気テープ、ユニバーサルシリアルバス（ＵＳＢ）ドライブ、またはこれらのうちの２つ以上の組み合わせが挙げられる。ストレージデバイス１１０６は、必要に応じて、取り外し可能媒体を備えていてもよいし、取り外し可能できない（すなわち、固定）媒体を備えていてもよい。また、ストレージデバイス１１０６は、コンピューティングデバイス１１００の内部であってもよいし、外部であってもよい。特定の実施形態において、ストレージデバイス１１０６は、不揮発性の固体メモリである。特定の実施形態において、ストレージデバイス１１０６は、リードオンリーメモリ（ＲＯＭ）を含む。必要に応じて、このＲＯＭは、マスクプログラムＲＯＭ、プログラム可能ＲＯＭ（ＰＲＯＭ）、消去可能ＰＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、電気的書き換え可能ＲＯＭ（ＥＡＲＯＭ）、フラッシュメモリ、またはこれらのうちの２つ以上の組み合わせであってもよい。

また、コンピューティングデバイス１１００は、上記コンピューティングデバイス１１００に対するユーザの入力付与、出力受容、あるいはデータ転送を可能にする１つまたは複数の入力または出力（「Ｉ／Ｏ」）デバイス／インターフェース１１０８を備える。これらのＩ／Ｏデバイス／インターフェース１１０８としては、マウス、キーパッドもしくはキーボード、タッチスクリーン、カメラ、光学スキャナ、ネットワークインターフェース、モデル、その他既知のＩ／Ｏデバイス、またはこのようなＩ／Ｏデバイス／インターフェース１１０８の組み合わせが挙げられる。タッチスクリーンは、スタイラスペンまたは指で駆動されるようになっていてもよい。

Ｉ／Ｏデバイス／インターフェース１１０８は、出力をユーザに提示する１つまたは複数の機器を備えていてもよく、グラフィックスエンジン、ディスプレイ（たとえば、表示画面）、１つまたは複数の出力ドライバ（たとえば、ディスプレイドライバ）、１つまたは複数の音声スピーカ、および１つまたは複数の音声ドライバが挙げられるが、これらに限定されない。特定の実施形態において、デバイス／インターフェース１１０８は、グラフィックデータをディスプレイに提供して、ユーザに提示するように構成されている。グラフィックデータは、特定の実施態様に役立ち得る１つもしくは複数のグラフィカルユーザインターフェースおよび／またはその他任意のグラフィックコンテンツを代表するものであってもよい。

コンピューティングデバイス１１００は、通信インターフェース１１１０をさらに備えてもよい。通信インターフェース１１１０は、ハードウェア、ソフトウェア、または両者を含み得る。通信インターフェース１１１０は、コンピューティングデバイスと１つもしくは複数の他のコンピューティングデバイス１１００または１つもしくは複数のネットワークとの間の通信（たとえば、パケットベースの通信等）のための１つまたは複数のインターフェースを提供可能である。非限定的な一例として、通信インターフェース１１１０としては、イーサネット（登録商標）等の有線ネットワークと連通するネットワークインターフェースコントローラ（ＮＩＣ）もしくはネットワークアダプタまたはＷｉ−Ｆｉ等の無線ネットワークと連通する無線ＮＩＣ（ＷＮＩＣ）もしくは無線アダプタが挙げられる。

本開示では、任意の適当なネットワークおよび任意の適当な通信インターフェース１１１０を想定している。非限定的な一例として、コンピューティングデバイス１１００は、アドホックネットワーク、パーソナルエリアネットワーク（ＰＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、インターネットの１つもしくは複数の部分、またはこれらのうちの２つ以上の組み合わせと連通するようになっていてもよい。これらネットワークのうちの１つまたは複数の１つまたは複数の部分は、有線であってもよいし、無線であってもよい。一例として、コンピュータシステム１１００は、無線ＰＡＮ（ＷＰＡＮ）（たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標）ＷＰＡＮ等）、Ｗｉ−Ｆｉネットワーク、Ｗｉ−ＭＡＸネットワーク、携帯電話ネットワーク（たとえば、汎欧州デジタル移動電話通信（ＧＳＭ（登録商標））ネットワーク等）、他の適当な無線ネットワーク、またはこれらの組み合わせと連通するようになっていてもよい。コンピューティングデバイス１１００は、必要に応じて、これらネットワークのいずれかに対する任意の適当な通信インターフェース１１１０を備えていてもよい。

コンピューティングデバイス１１００は、バス１１１２をさらに備えてもよい。バス１１１２は、コンピューティングデバイス１１００の構成要素を互いに結合するハードウェア、ソフトウェア、または両者を備えることができる。非限定的な一例として、バス１１１２は、アクセラレイテッドグラフィックスポート（ＡＧＰ）等のグラフィックスバス、
拡張業界標準アーキテクチャ（ＥＩＳＡ）バス、フロントサイドバス（ＦＳＢ）、ハイパートランスポート（ＨＴ）相互接続、業界標準アーキテクチャ（ＩＳＡ）バス、インフィニバンド相互接続、ロウピンカウント（ＬＰＣ）バス、メモリバス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、周辺機器相互接続（ＰＣＩ）バス、ＰＣＩエクスプレス（ＰＣＩｅ）バス、シリアルアドバンストテクノロジーアタッチメント（ＳＡＴＡ）バス、ビデオエレクトロニクス標準協会ローカル（ＶＬＢ）バス、その他適当なバス、またはこれらの組み合わせを含んでいてもよい。

上述の通り、ネットワークアプリケーション２１８は、ソーシャルネットワーキングシステムを含み得る。ソーシャルネットワーキングシステムによれば、そのユーザ（人または組織等）は、システムと、および互いに対話が可能である。ソーシャルネットワーキングシステムは、ユーザからの入力により、ユーザに関連付けられているユーザプロフィールを作成して上記ソーシャルネットワーキングシステムに記憶するようにしてもよい。ユーザプロフィールには、人口統計学的情報、通信チャンネル情報、およびユーザの個人的関心に関する情報を含んでいてもよい。また、ソーシャルネットワーキングシステムは、ユーザからの入力により、上記ユーザのソーシャルネットワーキングシステムの他ユーザとの関係のレコードを作成して記憶するとともに、ユーザ間の社会的対話を容易に行わせるサービス（たとえば、ウォール投稿、写真共有、イベント統合、メッセージング、ゲーム、または広告）を提供するようにしてもよい。

ソーシャルネットワーキングシステムは、複数のノードおよび上記ノードをつなげる複数のエッジを含むソーシャルグラフにおいて、ユーザおよびユーザ間の関係のレコードを記憶するようにしてもよい。ノードは、複数のユーザノードおよび複数のコンセプトノードを含んでいてもよい。ソーシャルグラフのユーザノードは、ソーシャルネットワーキングシステムのユーザに対応していてもよい。ユーザは、個人（人間のユーザ）であってもよいし、団体（たとえば、企業、事業所、またはサードパーティアプリケーション）であってもよいし、グループ（たとえば、個人または団体のグループ）であってもよい。ユーザに対応するユーザノードには、ユーザが提供した情報およびソーシャルネットワーキングシステム等のさまざまなシステムが収集した情報を含んでいてもよい。

たとえば、ユーザは、自身の氏名、プロフィール写真、居住市、連作先情報、誕生日、性別、結婚歴、家族状況、職業、学歴、好み、関心、およびユーザノードに含める他の人口統計学的情報を提供するようにしてもよい。ソーシャルグラフの各ユーザノードは、対応するウェブページ（通常、プロフィールページとして知られている）を有していてもよい。ユーザ名を含む要求に応答して、ソーシャルネットワーキングシステムは、上記ユーザ名に対応したユーザノードにアクセスするとともに、氏名、プロフィール写真、およびユーザに関連付けられている他の情報を含むプロフィールページを構築することができる。第１のユーザのプロフィールページは、第１のユーザによる１つまたは複数のプライバシー設定および第１のユーザと第２のユーザとの間の関係に基づいて、第１のユーザの情報の全部または一部が第２のユーザに表示されるようになっていてもよい。

コンセプトノードは、ソーシャルネットワーキングシステムのコンセプトに対応していてもよい。たとえば、コンセプトは、映画、歌曲、スポーツチーム、有名人、グループ、レストラン、または場所もしくは位置等、現実世界に存在する人や物を表すことができる。コンセプトに対応するコンセプトノードを管理するユーザは、（たとえば、オンラインフォームの記入によって）コンセプトの情報を提供し、上記情報とコンセプトノードとの関連付けをソーシャルネットワーキングシステムに行わせることによって、コンセプトノードの作成または更新を行うようにしてもよい。非限定的な一例として、コンセプトに関連付けられている情報としては、名称またはタイトル、１つまたは複数の画像（たとえば、書籍の表紙の画像）、ウェブサイト（たとえば、ＵＲＬアドレス）、または連絡先情報
（たとえば、電話番号、電子メールアドレス）が挙げられる。ソーシャルグラフの各コンセプトノードは、ウェブページに対応していてもよい。たとえば、名称を含む要求に応答して、ソーシャルネットワーキングシステムは、上記名称に対応したコンセプトノードにアクセスするとともに、上記名称およびコンセプトに関連付けられている他の情報を含むウェブページを構築することができる。

一対のノード間のエッジは、上記ノード対間の関係を表していてもよい。たとえば、２つのユーザノード間のエッジは、２人のユーザ間の友達関係を表すことができる。別の例として、ソーシャルネットワーキングシステムは、１つまたは複数の選択可能なボタン（たとえば、「いいね」、「登録」）を組み込んだコンセプトノード（たとえば、レストラン、有名人）のウェブページ（または、構造化文書）を構築するようにしてもよい。ユーザは、ユーザのクライアントデバイスがホスティングするウェブブラウザを用いて上記ページにアクセスし、選択可能なボタンを選択することによって、ユーザのユーザノードとコンセプトのコンセプトノードとの間に、ユーザとコンセプトとの関係を示すエッジを作成する要求のソーシャルネットワーキングシステムへの送信をクライアントデバイスに行わせることができる（たとえば、ユーザは、レストランを登録するか、または有名人を「いいね」する）。

一例として、ユーザは、自身の居住市を提供（または変更）することによって、ユーザに対応するユーザノードとユーザが自身の居住市として宣言した市に対応するコンセプトノードとの間のエッジの作成をソーシャルネットワーキングシステムに行わせるようにしてもよい。また、任意の２つのノード間の分離度は、一方のノードから他方へとソーシャルグラフを横切るのに必要な最小ホップ数として規定される。２つのノード間の分離度は、ユーザ間またはソーシャルグラフにおいて上記２つのノードが表すコンセプト間の関連性の尺度と考えられる。たとえば、エッジによって直接つながった（すなわち、第１の程度のノードである）ユーザノードを有する２人のユーザは、「つながったユーザ」または「友達」として表すことができる。同様に、別のユーザノードを通じてのみつながった（すなわち、第２の程度のノードである）ユーザノードを有する２人のユーザは、「友達の友達」と表すことができる。

ソーシャルネットワーキングシステムは、写真共有、オンラインカレンダおよびイベント、ゲーム、インスタントメッセージング、ならびに広告等、多様なアプリケーションに対応していてもよい。たとえば、ソーシャルネットワーキングシステムは、メディア共有機能を備えていてもよい。また、ソーシャルネットワーキングシステムによって、ユーザは、自身のプロフィールページへの写真および他のマルチメディアファイルの投稿（通常、「ウォール投稿」または「タイムライン投稿」として知られている）またはフォトアルバムへの投稿が可能であってもよく、いずれもユーザのプライバシー設定に応じて、上記ソーシャルネットワーキングシステムの他のユーザがアクセス可能であってもよい。また、ソーシャルネットワーキングシステムによって、ユーザは、イベントを設定可能であってもよい。たとえば、第１のユーザは、イベントに対して、上記イベントの日時、上記イベントの場所、および上記イベントに招待された他のユーザを含む属性を設定するようにしてもよい。招待されたユーザは、上記イベントへの招待を受信し、（招待の受諾または辞退等によって）応答するようにしてもよい。さらに、ソーシャルネットワーキングシステムによって、ユーザは、個人用カレンダを維持可能であってもよい。イベントと同様に、カレンダエントリには、時間、日付、場所、および他のユーザの同一性を含んでいてもよい。

図１２は、ソーシャルネットワーキングシステムの例示的なネットワーク環境を示している。特定の実施形態において、ソーシャルネットワーキングシステム１２００は、１つまたは複数のデータストアを備えていてもよい。特定の実施形態において、ソーシャルネ
ットワーキングシステム１２００は、上述の通り、ユーザノード、コンセプトノード、およびノード間のエッジを含むソーシャルグラフを記憶していてもよい。各ユーザノードには、ユーザに関連付けられている情報またはユーザを記述した情報に対応する１つまたは複数のデータオブジェクトを含んでいてもよい。各コンセプトノードには、コンセプトに関連付けられている情報に対応する１つまたは複数のデータオブジェクトを含んでいてもよい。一対のノード間の各エッジには、上記ノード対に対応するユーザ間（または、ユーザとコンセプト間もしくはコンセプト間）の関係に関連付けられている情報に対応する１つまたは複数のデータオブジェクトを含んでいてもよい。

特定の実施形態において、ソーシャルネットワーキングシステム１２００は、上記ソーシャルネットワーキングシステムの動作を対象とした機能をホスティングする１つまたは複数のコンピューティングデバイス（たとえば、サーバ）を備えていてもよい。ソーシャルネットワーキングシステム１２００のユーザは、クライアントデバイス１２０６等のクライアントデバイスを用いて、上記ソーシャルネットワーキングシステム１２００にアクセスするようにしてもよい。特定の実施形態において、クライアントデバイス１２０６は、ネットワーク１２０４を通じて、ソーシャルネットワーキングシステム１２００と対話してもよい。

クライアントデバイス１２０６は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、個人用デジタル補助デバイス（ＰＤＡ）、車載もしくは車外ナビゲーションシステム、スマートフォン等の携帯電話、モバイルゲーム機、他のモバイルデバイス、または他の適当なコンピューティングデバイスであってもよい。クライアントデバイス１２０６は、ウェブブラウザ（たとえば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｍｏｚｉｌｌａ Ｆｉｒｅｆｏｘ、Ａｐｐｌｅ Ｓａｆａｒｉ、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ、Ｏｐｅｒａ等）またはネイティブもしくは専用クライアントアプリケーション（たとえば、ｉＰｈｏｎｅ（登録商標）またはｉＰａｄ（登録商標）用フェースブック、Ａｎｄｒｏｉｄ（登録商標）用フェースブック等）といった１つまたは複数のクライアントアプリケーションを実行することにより、ネットワーク１２０４を通じてコンテンツにアクセスし、閲覧するようにしてもよい。

ネットワーク１２０４は、クライアントデバイス１２０６がソーシャルネットワーキングシステム１２００にアクセス可能なネットワークまたはネットワークのセット（インターネット、企業イントラネット、仮想プライベートネットワーク（ＶＰＮ）、ローカルエリアネットワーク（ＬＡＮ）、無線ローカルエリアネットワーク（ＷＬＡＮ）、セルラーネットワーク、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、または２つ以上のこのようなネットワークの組み合わせ等）を表していてもよい。

これらの方法、システム、およびユーザインターフェースでは、公的に入手可能な情報およびソーシャルネットワーキングシステムのユーザが提供する情報の両者を利用するが、このような情報の使用はすべて、関ったユーザのすべてのプライバシー設定およびソーシャルネットワーキングシステム全体の個人情報保護方針の影響を明示的に受けるものとする。

上記明細においては、特定の例示的な実施形態を参照して本発明を説明した。本発明の種々実施形態および態様についても、本明細書に記載の詳細を参照して記述され、添付の図面は、これら種々の実施形態を示している。上記説明および図面は、本発明の一例に過ぎず、本発明を制限するものと解釈されるべきではない。多くの具体的詳細の記述によって、本発明の種々の実施形態の十分な理解が得られる。

本発明は、その主旨または本質的特性から逸脱することなく、他の特定の形態で具現化されるようになっていてもよい。上記実施形態は、あらゆる点において一例に過ぎず、何ら限定的なものではないと解釈されるべきである。たとえば、本明細書に記載の方法は、より少数または多数のステップ／行為で実行されるようになっていてもよいし、これらのステップ／行為は、異なる順序で実行されるようになっていてもよい。また、本明細書に記載のステップ／行為は、反復されるようになっていてもよいし、互いに並列に実行されるようになっていてもよいし、同一または類似ステップ／行為の異なるインスタンスと並列に実行されるようになっていてもよい。したがって、本発明の範囲は、上記説明ではなく、添付の特許請求の範囲によって指定される。特許請求の範囲と同等の意味および範囲に含まれるすべての変更は、上記請求の範囲に包含されるものとする。

方法のすべての実施形態および特徴は、システム請求項において同等に請求可能であり、その逆も可能である。本明細書に記載または図示の実施形態および特徴のいずれかは、別個の請求項での請求および／または本明細書に記載もしくは図示の任意の実施形態もしくは特徴との任意の組み合わせもしくは添付の特許請求の範囲の特徴のいずれかとの任意の組み合わせでの請求が可能である。請求可能な主題には、添付の特許請求の範囲に示すような特徴の組み合わせのみならず、特許請求の範囲の特徴のその他任意の組み合わせも含み、特許請求の範囲に記載の各特徴は、特許請求の範囲または上記明細のその他任意の特徴または特徴の組み合わせと組み合わせることができる。

Claims (20)

1. ユーザのユーザ識別情報を含む要求を受信する、要求受信ステップと、
   ネットワークアプリケーションを実行する１以上のサーバコンピューティングデバイスが、非一時的記憶媒体に記憶された前記ユーザの支払カード明細を参照する支払トークンを生成するステップと、
   前記ネットワークアプリケーションを実行する前記１以上のサーバコンピューティングデバイスが、前記支払トークンを前記商取引アプリケーションに送信するステップと、
   前記支払トークンを含むクレジット払い要求を前記商取引アプリケーションから受信するステップと、
   前記支払トークンの受信に応答して、前記ネットワークアプリケーションを実行する前記１以上のサーバコンピューティングデバイスが、前記商取引アプリケーションに関連付けられている支払ゲートウェイシステムに支払のクレジット払い要求を送信するステップであって、前記支払のクレジット払い要求は、前記支払カード明細、クレジット払い額、および前記商取引アプリケーションに代わってクレジット払い要求を提出する許可を示す標識を含む、ステップとを備える、方法。
2. 前記要求受信ステップは、１以上の支払フィールドを自動的に埋めることを可能とするための前記ユーザの支払情報を求めるグラフＡＰＩに対するクライアントサイドの呼び出しを受信することを含む、請求項１に記載の方法。
3. 前記ユーザの支払情報を前記商取引アプリケーションに送信して、前記商取引アプリケーションが１以上の支払フィールドを自動的に埋めることを可能とするステップをさらに備え、前記支払情報は、支払カードラベル、有効期限、氏名、および請求先住所を含む、請求項２に記載の方法。
4. 前記ユーザの前記支払情報を前記商取引アプリケーションに送信する前に、前記支払情報を前記商取引アプリケーションに提供する許可を前記ユーザから受信するステップをさらに備える、請求項３に記載の方法。
5. 前記支払ゲートウェイシステムから取引識別子を受信するステップと、
   前記取引識別子を前記商取引アプリケーションに送信するステップと、
   をさらに備える、請求項１〜４のいずれか一項に記載の方法。
6. 前記ユーザの識別情報に変換関数を適用することによって、前記ユーザの前記識別情報を前記ネットワークアプリケーションのユーザのユーザＩＤにマッピングするステップをさらに含む、請求項１〜５のいずれか一項に記載の方法。
7. 前記商取引アプリケーションに代わってクレジット払い要求を提出する許可を示す標識を送信するステップは、前記支払ゲートウェイシステムから前記商取引アプリケーションに提供された秘密鍵を用いて前記支払のクレジット払い要求の少なくとも一部を暗号化することを含む、請求項１〜６のいずれか一項に記載の方法。
8. 前記支払のクレジット払い要求を前記支払ゲートウェイシステムに送信する前に、前記商取引アプリケーションに関連付けられているサーバコンピューティングデバイスに前記クレジット払い要求が由来することを検証するステップをさらに備える、請求項１〜７のいずれか一項に記載の方法。
9. 前記ネットワークアプリケーションは、ソーシャルネットワーキングシステムを含む、請求項１〜８のいずれか一項に記載の方法。
10. 商取引アプリケーションの少なくとも第１の部分を実行するクライアントコンピューティングデバイスから、ネットワークアプリケーションを実行する１以上のサーバコンピューティングデバイスに情報の要求を送信するステップであって、前記要求は、ユーザのユーザ識別情報および前記ユーザが購入のために選択した注文に対するクレジット払い額を含む、情報要求送信ステップと、
    前記１以上のサーバコンピューティングデバイスから、支払カードラベル、支払トークン、および前記ユーザの支払情報を受信するステップと、
    少なくとも１つのプロセッサを用いて、精算ユーザインターフェースの支払フィールドを、前記支払カードラベルおよび前記ユーザの前記支払情報により自動的に埋めるステップと、
    クレジット払い要求を前記１以上のサーバコンピューティングに送信するステップであって、前記クレジット払い要求は、前記支払トークンを含む、ステップとを備える、方法。
11. 前記情報要求送信ステップは、前記ネットワークアプリケーションのグラフＡＰＩの呼び出しを行うことを含む、請求項１０に記載の方法。
12. 前記支払トークンを前記１以上のサーバコンピューティングデバイスに送信するステップは、前記商取引アプリケーションの少なくとも第２の部分を実行するサーバコンピューティングデバイスのネットワークインターフェースから前記ネットワークアプリケーションの支払ＡＰＩの呼び出しを行うことを含む、請求項１１に記載の方法。
13. 前記コンピューティングデバイスの共有メモリ領域内の前記商取引アプリケーションが、前記ユーザ識別情報にアクセスするステップをさらに備え、前記ユーザ識別情報は、前記ネットワークアプリケーションと対話するクライアントネットワークアプリケーションによって前記共有メモリ領域に初期に記憶されている、請求項１０〜１２のいずれか一項に記載の方法。
14. 前記ネットワークアプリケーションからの支払情報を用いて前記注文を完了可能であることを示す選択可能な精算オプションをレンダリングするステップをさらに備える、請求項１０〜１３のいずれか一項に記載の方法。
15. ネットワークアプリケーションを実行する１以上のサーバコンピューティングデバイスと、
    非一時的記憶媒体とを備えるシステムであって、前記非一時的記憶媒体は、
    複数のユーザの支払情報を有するプロフィール記憶モジュールであり、各ユーザの前記支払情報が、前記ユーザの氏名、支払カードの番号、前記支払カードの有効期限、前記ユーザの配送先住所、および前記ユーザの請求先住所のうちの１以上を含む、プロフィール記憶モジュールと、
    命令とを含み、前記命令は、前記１以上のサーバコンピューティングデバイスによって実行されたとき、
    商取引アプリケーションからの要求を識別するステップであって、前記要求は、前記商取引アプリケーションの買い物かご中の１以上の商品またはサービスに対するクレジット払い額を含み、前記１以上の商品は、ユーザによって選択されたものである、ステップと、
    前記ユーザに関連付けられている支払情報を識別するステップと、
    前記ユーザに関連付けられている前記支払カードの番号を参照する支払トークンを生成するステップと、
    前記支払トークン、カードラベル、および前記ユーザの支払情報を前記商取引アプリケ
    ーションに送信するステップと、
    前記商取引アプリケーションからの前記支払トークンの受信に際し、前記商取引アプリケーションに関連付けられている支払ゲートウェイシステムに支払のクレジット払い要求を送信するステップであって、前記支払の要求は、前記支払カード番号、前記クレジット払い額、および前記商取引アプリケーションに代わってクレジット払い要求を提出する許可を示す標識を含む、ステップと、を前記システムに行わせる、非一時的記憶媒体と、を備える、システム。
16. 前記命令は、前記１以上のサーバコンピューティングデバイスによって実行されたとき、
    前記商取引アプリケーションの前記買い物かご中の前記１以上の商品またはサービスの購入を前記ユーザが完了していないことを判定するステップと、
    前記１以上の商品またはサービスに関する詳細と、前記１以上の商品またはサービスを購入するオプションとを含むメッセージを生成するステップと、
    前記メッセージを前記ユーザに提供するステップと、を前記システムにさらに行わせる、請求項１５に記載のシステム。
17. 前記ネットワークアプリケーションは、ソーシャルネットワーキングシステムである、請求項１５または１６に記載のシステム。
18. 前記命令は、前記１以上のサーバコンピューティングデバイスによって実行されたとき、前記ソーシャルネットワーキングシステムのニュースフィードにおいて前記メッセージを前記ユーザに提供するステップを前記システムに行わせる、請求項１７に記載のシステム。
19. 前記命令は、前記１以上のサーバコンピューティングデバイスによって実行されたとき、前記ユーザの識別情報に変換関数を適用することによって、前記商取引アプリケーションからの前記要求により受信した前記ユーザの識別情報をユーザＩＤにマッピングするステップを前記システムにさらに行わせる、請求項１５〜１８のいずれか一項に記載のシステム。
20. 前記命令は、前記１以上のサーバコンピューティングデバイスによって実行されたとき、前記支払ゲートウェイシステムから前記商取引アプリケーションに提供された秘密鍵を用いて前記支払のクレジット払い要求の少なくとも一部を暗号化して、前記商取引アプリケーションに代わってクレジット払い要求を提出する許可を示す前記標識を提供するステップを前記システムにさらに行わせる、請求項１５〜１９のいずれか一項に記載のシステム。