(57)【要約】  デバイスから支払いリクエストを受信し、デバイスに支払いプラグインがインストールされていないという通知を受信し、デバイスにインストールされるように構成されている支払いプラグインをデバイスが受信していることを決定し、デバイスに関連付けられている少なくとも１つの属性を含むアクティベーションメッセージを支払いプラグインから受信し、デバイスに関連付けられている属性に合致する、記憶されているユーザアカウントを決定し、合致するユーザアカウントに少なくとも一部基づく支払いリクエストの処理を実行するための確定を支払いプラグインから受信することを含む、支払いプラグインを使用する支払いの実行が開示される。【選択図】図２
2014535121.tif 000002
【特許請求の範囲】
【請求項１】
支払いプラグインを使用して支払いを行うための支払いサーバであって、
１または複数のプロセッサであって、
デバイスから支払いリクエストを受信し、
前記デバイスに前記支払いプラグインがインストールされていないという通知を受信し、
前記デバイスにインストールされるように構成されている前記支払いプラグインを前記デバイスが受信していることを決定し、
前記デバイスに関連付けられている少なくとも１つの属性を含むアクティベーションメッセージを前記支払いプラグインから受信し、
前記デバイスに関連付けられている前記属性に合致する、記憶されているユーザアカウントを決定し、
前記合致するユーザアカウントに少なくとも一部基づく前記支払いリクエストの処理を実行するための確定を前記支払いプラグインから受信する
ように構成されている、１または複数のプロセッサと、
前記１つまたは複数のプロセッサに接続され、前記１つまたは複数のプロセッサに命令を提供するように構成されている１つまたは複数のメモリと、を備える支払いサーバ。
【請求項２】
請求項１に記載の支払いサーバにおいて、前記デバイスに前記支払いプラグインがインストールされていないという前記通知は、ウェブブラウザによって決定される、支払いサーバ。
【請求項３】
請求項２に記載の支払いサーバにおいて、前記ウェブブラウザは、前記支払いプラグインを呼び出すように構成されているタグを検出するように構成されている、
支払いサーバ。
【請求項４】
請求項３に記載の支払いサーバにおいて、前記タグは、前記支払いプラグインのダウンロードに関連付けられているリンクに関連付けられている、支払いサーバ。
【請求項５】
請求項１に記載の支払いサーバにおいて、前記デバイスに関連付けられている前記属性は、前記デバイスに関連付けられている電話番号、前記デバイスに関連付けられている加入者識別モジュール（ＳＩＭ）カード番号、デバイスシリアル番号、デバイス製造業者、デバイスモデル識別子、またはデバイスのブランドの１つまたは複数を含む、支払いサーバ。
【請求項６】
請求項１に記載の支払いサーバにおいて、前記合致するユーザアカウントは、前記デバイスに関連付けられている前記属性に合致する複数のユーザアカウントのうちの１つを含む、支払いサーバ。
【請求項７】
請求項１に記載の支払いサーバにおいて、前記１つまたは複数のプロセッサは、さらに、前記合致するユーザアカウントに関連付けられている支払い情報に少なくとも一部基づいて前記支払いリクエストを処理するように構成されている、支払いサーバ。
【請求項８】
請求項１に記載の支払いサーバにおいて、前記１つまたは複数のプロセッサは、さらに、前記支払いリクエストに関連付けられている支払いのサイズが第１のしきい値未満であると判断し、前記判断に少なくとも一部基づいて、前記支払いリクエストに関連付けられているユーザからのさらなるアクションを必要とせずに前記支払いリクエストを処理するように構成されている、支払いサーバ。
【請求項９】
請求項１に記載の支払いサーバにおいて、前記１つまたは複数のプロセッサは、さらに、前記支払いリクエストに関連付けられている支払いのサイズが第１のしきい値以上であるが前記第２のしきい値未満であると判断し、前記判断に少なくとも一部基づいて、前記合致するユーザアカウントに関連付けられているパスワードを要求するリクエストを送信するように構成されており、前記第２のしきい値は、前記第１のしきい値よりも大きい、支払いサーバ。
【請求項１０】
請求項１に記載の支払いサーバにおいて、前記１つまたは複数のプロセッはが、さらに、前記支払いリクエストに関連付けられている支払いのサイズが第２のしきい値以上であると判断し、前記判断に少なくとも一部基づいて、前記支払いプラグインからの検証メッセージを要求するように構成されている、支払いサーバ。
【請求項１１】
支払いプラグインを使用して支払いを行うための方法であって、
デバイスから支払いリクエストを受信し、
前記デバイスに前記支払いプラグインがインストールされていないという通知を受信し、
前記デバイスにインストールされるように構成されている前記支払いプラグインを前記デバイスが受信していることを決定し、
前記デバイスに関連付けられている少なくとも１つの属性を含むアクティベーションメッセージを前記支払いプラグインから受信し、
前記デバイスに関連付けられている前記属性に合致する、記憶されているユーザアカウントを決定し、
前記合致するユーザアカウントに少なくとも一部基づく前記支払いリクエストの処理するための確定を前記支払いプラグインから受信すること
を備える方法。
【請求項１２】
請求項１１に記載の方法において、前記デバイスに前記支払いプラグインがインストールされていないという前記通知は、ウェブブラウザによって決定される、方法。
【請求項１３】
請求項１２に記載の方法において、前記ウェブブラウザは、前記支払いプラグインを呼び出すように構成されているタグを検出するように構成されている、方法。
【請求項１４】
請求項１３に記載の方法において、前記タグは、前記支払いプラグインのダウンロードに関連付けられているリンクに関連付けられている、方法。
【請求項１５】
請求項１１に記載の方法において、前記デバイスに関連付けられている前記属性は、前記デバイスに関連付けられている電話番号、前記デバイスに関連付けられている加入者識別モジュール（ＳＩＭ）カード番号、デバイスシリアル番号、デバイス製造業者、デバイスモデル識別子、またはデバイスのブランドの１つまたは複数を含む、方法。
【請求項１６】
支払いプラグインを使用して支払いを行うためのデバイスであって、
１つまたは複数のプロセッサであって、
支払いリクエストを送信し、
前記デバイスに前記支払いプラグインがインストールされていないという通知を送信し、
前記デバイスにインストールされるように構成されている前記支払いプラグインを受信し、
前記支払いプラグインを使用して、前記デバイスに関連付けられている少なくとも１つの属性を含むアクティベーションメッセージを送信し、
前記デバイスに関連付けられている前記属性に合致する、記憶されているユーザアカウントを確認し、
前記支払いプラグインを使用して、前記合致するユーザアカウントに少なくとも一部基づく前記支払いリクエストの処理を実行するための確定を送信する
ように構成されている１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサに接続され、前記１つまたは複数のプロセッサに命令を提供するように構成されている１つまたは複数のメモリを備える、デバイス。
【請求項１７】
請求項１６に記載のデバイスにおいて、前記デバイスに前記支払いプラグインがインストールされていないという前記通知は、前記支払いプラグインを呼び出すように構成されているタグを検出するように構成されているウェブブラウザによって決定される、
デバイス。
【請求項１８】
請求項１６に記載のデバイスにおいて、前記合致するユーザアカウントは、第１の合致するユーザアカウントを含み、前記１つまたは複数のプロセッサは、さらに、複数の合致するユーザアカウントの中から、前記第１の合致するユーザアカウントに関連付けられているユーザ選択を受信するように構成されている、デバイス。
【請求項１９】
支払いプラグインを使用して支払いを行うための方法であって、
支払いリクエストを送信し、
前記デバイスに前記支払いプラグインがインストールされていないという通知を送信し、
前記デバイスにインストールされるように構成されている記支払いプラグインを受信し、
前記支払いプラグインを使用して、前記デバイスに関連付けられている少なくとも１つの属性を含むアクティベーションメッセージを送信し、
前記デバイスに関連付けられている前記属性に合致する、記憶されているユーザアカウントを確認し、
前記支払いプラグインを使用して、前記合致するユーザアカウントに少なくとも一部基づく前記支払いリクエストの処理を実行するための確定を送信すること
を含む方法。
【請求項２０】
請求項１９に記載の方法において、前記デバイスに前記支払いプラグインがインストールされていないという前記通知は、前記支払いプラグインを呼び出すように構成されたタグを検出するように構成されたウェブブラウザによって決定される、方法。
【請求項２１】
請求項１９に記載の方法において、前記合致するユーザアカウントは、第１の合致するユーザアカウントを含み、方法はさらに、複数の合致するユーザアカウントの中から前記第１の合致するユーザアカウントのユーザ選択を受信すること、を備える、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、全ての目的のために参照により本明細書に組み込まれる、２０１１年１２月１３日出願の発明の名称を「Ａ  ＭＥＴＨＯＤ  ＡＮＤ  ＤＥＶＩＣＥ  ＴＯ  ＲＥＡＬＩＺＥ  ＳＥＣＵＲＥ  ＰＡＹＭＥＮＴ  ＵＳＩＮＧ  ＡＮ  ＥＬＥＣＴＲＯＮＩＣ  ＴＥＲＭＩＮＡＬ（電子端末を使用する安全な支払いを実現するための方法および装置）」とする中華人民共和国特許出願第２０１１１０４１５５０３．１号に基づく優先権を主張する。
【０００２】
本出願は、オンラインセキュリティの分野に関する。特に、本出願は、安全な支払いをオンラインで行うための技法に関する。
【背景技術】
【０００３】
ネットワーク技術の継続的な発展に伴って、ウェブブラウジング、情報探索、および支払い取引などの活動は、もはやラップトップコンピュータまたはデスクトップコンピュータに制限されなくなっている。いまや、そのような活動は、移動電話やタブレットデバイスなどのモバイルデバイス上で、ワイヤレスアプリケーションプロトコル（ＷＡＰ）ウェブページにログオンすることによって行うことができる。
【０００４】
しかし、ＷＡＰウェブページを使用して支払い取引を行う従来の技術には、少なくとも以下の欠点がある。
【０００５】
第１に、ほとんどの従来のモバイルデバイスブラウザは、ウェブページにアクセスできるだけである。したがって、モバイルデバイスブラウザを使用する取引の実施も、ＷＡＰウェブページに基づかなければならない。ＷＡＰウェブページを使用する際、ＨＴＴＰＳセキュアウェブリンクを用いたとしても、ほとんどのモバイルデバイスブラウザは、デバイスを使用しているユーザが、実際に、現在ログインされているアカウントに関連付けられているユーザ本人であるかを検証するために正確なデータを送信することができない。ユーザのアカウント情報（例えば、ログイン名およびパスワード）が盗難されると、アカウントを盗難されたユーザのデバイス以外のモバイルデバイス上で盗難されたアカウントにログインすることによって行われる支払いにより、ユーザが損害を被ることになる。
【０００６】
第２に、ほとんどの従来のモバイルデバイスブラウザは、ユーザのログイン名およびパスワードを要求するＷＡＰページプロンプトを使用して支払いを行い、これは、ユーザにとって面倒な支払いプロセスとなることがある。
【０００７】
本発明の様々な実施形態を、以下の詳細な説明および添付図面で開示する。
【図面の簡単な説明】
【０００８】
【図１】支払いプラグインを使用して支払いを行うためのシステムの一実施形態を示す図である。
【０００９】
【図２】支払いプラグインを使用して支払いを行うためのプロセスの一実施形態を示す図である。
【００１０】
【図３】モバイルデバイス上の一連の例示的なユーザインターフェースを示す図である。
【００１１】
【図４】支払いプラグインを使用して支払いを行うためのシステムの一実施形態を示す図である。
【発明を実施するための形態】
【００１２】
本発明は、プロセス、装置、システム、物質組成（composition of matter）、コンピュータ可読記憶媒体上で具現化されるコンピュータプログラム製品、および／またはプロセッサ、例えば、結合されたメモリに記憶されている命令および／またはメモリによって提供される命令を実行するように構成された処理装置としての形を含めた多くの形で実装することができる。本明細書では、これらの実装形態、または本発明が取ることができる任意の他の形態を、技法と呼ぶことがある。一般に、開示するプロセスのステップの順序は、本発明の範囲内で変更することができる。特に断りのない限り、タスクを実施するように構成されているものとして述べる処理装置またはメモリなどの構成要素は、所与の時間にタスクを実施するように一時的に構成された汎用構成要素、またはタスクを実施するように製造された専用構成要素として実装することができる。本明細書で使用するとき、用語「プロセッサ」は、コンピュータプログラム命令などのデータを処理するように構成された１つまたは複数のデバイス、回路、および／または処理コアを表す。
【００１３】
以下、本発明の原理を例示する添付図面と共に、本発明の１つまたは複数の実施形態の詳細な説明を行う。そのような実施形態に関連付けて本発明を説明するが、本発明は、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲のみによって限定され、本発明は、複数の変形形態、修正形態、および均等形態を包含する。本発明を完全に理解できるように、以下の説明では複数の具体的な詳細を述べる。これらの詳細は例示の目的で提供されるものであり、本発明は、これらの具体的な詳細のいくつかまたはすべてを含まなくても、特許請求の範囲に従って実施することができる。分かりやすくするために、本発明を不要に曖昧にしないように、本発明に関係する技術分野において既知の技術要素については詳細には説明していない。
【００１４】
以下、添付図面に照らし合わせて主要な原理の詳細な説明を行う。本出願の実施形態、特定の実施形態、およびそれらの実施形態から実現することができる対応する有益な効果で、技術的解決策が実現される。
【００１５】
ここでは、支払いプラグインを使用する支払いの実行を述べる。いくつかの実施形態では、プラグインは、エンドユーザデバイス（例えば、スマートフォン、タブレットデバイス、パーソナルコンピュータなど）に実装されてインストールされる。このプラグインは、エンドユーザデバイスでのウェブブラウザアプリケーションと協働し、安全な支払いを可能にする。デバイス（装置）から支払いリクエストが受信される。例えば、支払いリクエストは、ウェブサイトで販売されている商品に対する支払いの実行を選択した、デバイスを使用しているユーザに成り代わって送信される。いくつかの実施形態では、まず、プラグインがデバイスにインストールされているか否かが判断される。インストールされていない場合、プラグインが、デバイスに送信されてインストールされる。プラグインは、アクティベーション（起動、有効化）段階中に、アクティベーションメッセージを支払いサーバに送信し、アクティベーションメッセージは、デバイスに関連付けられている少なくとも１つの属性を含む。属性は、サーバ側で、他のユーザアカウント情報と共に記憶される。その後、ユーザがプラグインを介して支払いを行うことを試行するとき、デバイスに関連付けられている属性情報が支払いサーバに送信され、支払いサーバは、デバイスに関連付けられている属性情報に合致する、記憶されているユーザアカウントの有無を判断する。合致するアカウントが見つかり、支払い処理の確定がユーザによって行われた場合、支払いが処理される。
【００１６】
図１は、支払いプラグインを使用して支払いを行うためのシステムの一実施形態を示す図である。この例では、システム１００は、デバイス１０２と、ネットワーク１０４と、支払いサーバ１０６と、データベース１０８とを含む。ネットワーク１０４は、高速データおよび／または電気通信ネットワークを含むことがある。デバイス１０２は、ネットワーク１０４を介して支払いサーバ１０６と通信する。
【００１７】
デバイス１０２の例として、移動電話、タブレットデバイス、ラップトップコンピュータ、デスクトップコンピュータ、および／または任意の他の計算デバイスを挙げることができる。様々な実施形態において、ウェブブラウザアプリケーションがデバイス１０２にインストールされており、ユーザがウェブサイトをブラウズするために使用することができる。例えば、ユーザは、支払いサーバ１０６に関連付けられている１つまたは複数のウェブサーバ（図示せず）によってサポートされる電子商取引ウェブサイトをブラウズすることがある。ブラウジング中、ユーザは、ある商品に関連付けられているウェブページに達することがあり、その商品を購入することを望む。ユーザは、ウェブページの「支払いを行う」ボタンを選択することができる。ユーザによる「支払いを行う」ボタンの選択に応答して、支払いリクエストが、デバイス１０２から支払いサーバ１０６に送信される。いくつかの実施形態では、デバイス１０２のウェブブラウザは、支払いサーバ１０６を介する安全な支払いの実施に関連付けられる支払いプラグインがデバイス１０２にインストールされているか否か判断する。様々な実施形態において、支払いプラグインは、その支払いプラグインがインストールされているデバイスを認証し、そのデバイスを使用した安全な支払いを円滑に行うためのアプリケーション（例えば、ウェブブラウザなど別のアプリケーションと共に動作するように構成されたアプリケーション）を備える。いくつかの実施形態では、ウェブブラウザは、支払いプラグインの呼出しに関連付けられている１つまたは複数のタグをウェブブラウザに検出させるための何らかのコンピュータコードを有するように特別に構成または修正されている。いくつかの実施形態では、支払いプラグインの呼出しに応答して、デバイス１０２内に支払いプラグインが存在しないことに関連付けられているエラー／例外または他のアクションが生じた場合、ウェブブラウザは、支払いプラグインがデバイス１０２にインストールされていないことを示す通知を支払いサーバ１０６に送信することがある。そのような通知に応答して、支払いサーバ１０６は、支払いプラグインのダウンロードをユーザに求めるようにデバイス１０２を促すように構成される。ユーザが、支払いプラグインのダウンロードに関連付けられている要素を選択する場合、支払いサーバ１０６は、デバイス１０２に支払いプラグインを送信するように構成されている。いくつかの実施形態では、ダウンロードされた支払いプラグインは、デバイス１０２に自動的にインストールされる。
【００１８】
デバイス１０２で、新たにインストールされた支払いプラグインは、支払いサーバ１０６にアクティベーションメッセージを自動的に送信するように構成される。様々な実施形態において、アクティベーションメッセージ（例えば、テキストメッセージ）は、デバイス１０２に関連付けられている少なくとも１つの属性を含むことがある。デバイス１０２に関連付けられている属性の例としては、デバイスに関連付けられている電話番号、加入者識別モジュール（ＳＩＭ）カード番号、デバイスシリアル番号、デバイス製造業者、デバイスモデル識別子、およびデバイス商標を挙げることができる。属性情報は、アプリケーションプログラミングインターフェース（ＡＰＩ）コールを呼び出すことによって得ることができる。支払いサーバ１０６は、受信されたアクティベーションメッセージから属性を抽出して、それらの属性を様々な記憶されているユーザアカウントと比較するように構成される。例えば、各ユーザアカウントは、電子商取引ウェブサイトでの登録ユーザに関連付けられ、アカウントを作成するためにユーザによって提示された情報を含む。ユーザアカウント作成プロセス中、ウェブサイトは、ユーザがウェブサイトで商品を購入するために使用することがあるデバイスに関連付けられている１つまたは複数の属性を要求していることがある。したがって、支払いサーバ１０６は、デバイスに関連付けられている属性に合致する、記憶されているユーザアカウントを見つけ出すように構成される。合致するユーザアカウントが見つかった場合、デバイス１０２は認証され、合致するユーザアカウントに対応付けられる。例えば、合致するユーザアカウントにデバイス１０２を対応付けることは、デバイス１０２とユーザアカウントとの間の対応関係を記録することを含む。デバイス１０２にインストールされている支払いプラグインは、支払いを確定するユーザによる選択を受信することができる。支払いプラグインは、次いで、その確定を支払いサーバ１０６に送信するように構成され、支払いサーバ１０６は、デバイス１０２に対応付けられたユーザアカウントに少なくとも一部基づいて支払いリクエストを処理するように構成される。
【００１９】
支払いプラグインを使用することによって、ユーザは、認証されたデバイスを使用して、望みの支払いを進めることができる。認証されたデバイスにある支払いプラグインを使用した支払いの確定は、ウェブページを介して機密情報を送信することに関連付けられるセキュリティのリスクをなくす。
【００２０】
図２は、支払いプラグインを使用して支払いを行うためのプロセスの一実施形態を示す図である。いくつかの実施形態では、プロセス２００は、図１のシステム１００などのシステムで実施されることがある。
【００２１】
ステップ２０２では、デバイスから支払いリクエストが受信される。例えば、支払いリクエストは、支払いサーバ、例えば図１のシステム１００の支払いサーバ１０６で受信されることがある。例えば、ユーザは、モバイルデバイスを使用して電子商取引ウェブサイトをブラウズすることがあり、ウェブサイトで宣伝されている商品を購入することに決める。例えば、モバイルデバイスは、移動電話またはタブレットデバイスを含み得る。ユーザは、デバイスにインストールされているウェブブラウザアプリケーションを使用して電子商取引ウェブサイトをブラウズすることができる。購入プロセスを開始するために、ユーザは、望みの商品に関連付けられるウェブページで「支払いを行う」ボタンを選択することができる。ユーザが「支払いを行う」ボタンを選択したのに応答して、支払いリクエストが送信される。例えば、支払いリクエストは、ユーザに関連付けられている情報と、支払い量（例えば、希望する商品の価格）と、希望する商品に関連付けられている情報とを含むことがある。
【００２２】
ステップ２０４では、支払いプラグインがデバイスにインストールされていないという通知が受信される。いくつかの実施形態では、デバイスのウェブブラウザによって、支払いプラグインが既にインストールされているかどうか判断される。様々な実施形態において、支払いプラグインは、少なくとも、記憶されているユーザアカウントにデバイスを関連付けることによって、安全で効率的な支払いプロセスを円滑に行うように構成され、例えば、以下にさらに述べるように、ユーザアカウントに関連付けられていない別のデバイスで、関連付けられているユーザアカウントと共に記憶されている支払い情報（例えばクレジットカード情報）を使用して支払いが行われないようにすることができる。
【００２３】
いくつかの実施形態では、支払いプラグインがデバイスにインストールされているか否かは、ユーザが使用するウェブブラウザアプリケーションによって判断される。いくつかの実施形態では、ウェブブラウザは、所定のコンピュータコードを含むように修正されることにより、支払いプラグインを呼び出すように特別に構成されることがある。例えば、そのようなコンピュータコードは、ユーザによるウェブページの「支払いを行う」ボタンの選択に応答して実行され、支払いプラグインを呼び出すように構成されているタグがその選択されたボタンに関連付けられているか否かをウェブブラウザに判断させる。ウェブブラウザは、そのようなタグを検出するように修正されている場合には、そのタグを使用して支払いプラグインを呼び出すことができ、ここで、支払いプラグインがインストールされている場合には支払いプラグインが開かれるが、支払いプラグインがインストールされていない場合には、ウェブブラウザは、支払いプラグインがまだインストールされていないという判断に関連付けられて通知を送信することがある。いくつかの実施形態では、タグは、支払いプラグインをダウンロードすることができるセキュアリンクに関連付けられる。例えば、以下は、そのようなコンピュータコードの一例である。
【００２４】
<!--ALIPAYMSP[v=“1.0”&submit_img_url= “http://mobile.alipay.com/msplogo.png”][partner=”2088002007260245”&seller=”2088002007260245”&out_trade_no=”500000006548”&subject=”Product name”&body=”Product description”&total_fee=”30”&notify_url=”http://notify.java.jpxx.org/index.jsp”&sign=”kU2Fa3x6V985g8ayTozI1eJ5fHtm8%2FJGeJQf9in%2BcVmRJjHaExbirnGGKJ%2F7B63drqc4Kjlk%2FSg6vtSIkOtdvVBrRDpYaKxXVqkJTzRYgUwrrpMudbIj9aMS2O3dHG0GpyL4Zb6jKDYXHabGG0aBJY3QA7JuTJ23t6SqV%2B5f1xg%3D”&sign_type=”MD5”]-->
【００２５】
この例では、ウェブブラウザは、特別なコメントタグを検出するコードを含む。コメントタグが見つかったとき、ウェブブラウザは、プラグインを呼び出すことができるか、それともプラグインをインストールすべきか判断する。
【００２６】
ステップ２０６では、支払いプラグインがデバイスに送信され、デバイスにインストールされる。いくつかの実施形態では、支払いプラグインがデバイスにまだインストールされていないと判断されると、プロンプトがデバイスに送信され、ユーザが支払いプラグインをダウンロードすることを望むか否かを尋ねるためにユーザに対して表示さる。例えば、プロンプトは、ポップアップメッセージとして表され、支払いプラグインのダウンロードの同意に関連付けられている第１の選択可能な要素（例えば第１のボタン）と、支払いプラグインのダウンロードの拒否に関連付けられている第２の選択可能な要素（例えば第２のボタン）とが、メッセージに関連付けられて表示される。ユーザが、支払いプラグインのダウンロードの同意に関連付けられている要素を選択する場合、支払いプラグインがデバイスにダウンロード／送信される。いくつかの実施形態では、支払いプラグインは、支払いサーバまたは別のサーバによって送信されることがある。いくつかの実施形態では、ダウンロードされた支払いプラグインは、デバイスに自動的にインストールされる。
【００２７】
しかし、ユーザが、支払いプラグインのダウンロードの拒否に関連付けられている要素を選択する場合、支払いプラグインはデバイスにダウンロード／送信されず、支払いリクエストは、１つまたは複数の従来のウェブページベースのプロセス（さらには説明しない）を使用して処理される。
【００２８】
ステップ２０８では、支払いプラグインからアクティベーションメッセージが受信され、アクティベーションメッセージは、デバイスに関連付けられている少なくとも１つの属性を含む。いくつかの実施形態では、最近ダウンロードされた支払いプラグインは、支払いプラグインをアクティベーションするために、デバイスの認証のためにアクティベーションメッセージを自動的に送信するように構成される。いくつかの実施形態では、アクティベーションメッセージは、テキストメッセージ（例えば、ショートメッセージサービス（ＳＭＳ）メッセージ）を含むことがある。いくつかの実施形態では、アクティベーションメッセージは、デバイスに関連付けられている少なくとも１つの属性を含むことがある。例えば、デバイスに関連付けられている属性としては、デバイスに関連付けられている電話番号、加入者識別モジュール（ＳＩＭ）カード番号、デバイスシリアル番号、デバイス製造業者、デバイスモデル識別子、およびデバイス商標を挙げることができる。
【００２９】
いくつかの実施形態では、アクティベーションメッセージに含まれる属性の少なくともいくつかは、事前にウェブサイトでのアカウント作成プロセス中にユーザに要求された属性である。例えば、電子商取引ウェブサイトでユーザアカウントを作成するために、ユーザ名、住所、連絡先情報、ログイン識別名、ログインパスワード、および支払い情報（例えば、クレジットカード情報、銀行口座情報、および／または他の支払い資金情報）の１つまたは複数など、情報がユーザに要求されることがある。さらに、このユーザアカウント作成プロセス中、ユーザは、ウェブサイトにアクセスするために使用することがある少なくとも１つのデバイスに関連付けられる情報／属性を提供するように要求されることがある。例えば、ユーザは、デバイスに関連付けられる電話番号、加入者識別モジュール（ＳＩＭ）カード番号、デバイスシリアル番号、デバイス製造業者、デバイスモデル識別子、およびそのようなデバイスそれぞれに関するデバイスのブランド（名称）など、１つまたは複数の属性を提供するように要求されることがある。ユーザアカウントの作成に成功すると、ユーザによって提供された情報は、ユーザアカウントと共に、支払いサーバに関連付けられるデータベースに記憶される。
【００３０】
ステップ２１０では、デバイスに関連付けられている属性に合致する、記憶されているユーザアカウントが見つけ出される。いくつかの実施形態では、アクティベーションメッセージが解析され、デバイスに関連付けられている属性が、データベースに記憶されているユーザアカウントと比較される。属性が、１つまたは複数の記憶されているユーザアカウントにおける対応する属性に合致する場合、そのような各ユーザアカウントが、合致するユーザアカウントとみなされる。
【００３１】
例えば、アクティベーションメッセージに２つの属性が含まれており、そのような属性が、電話番号（４０８）５５５−０９８７と、デバイスモデルｉＰｈｏｎｅ（登録商標）５であったと仮定する。そのような属性は、記憶されているユーザアカウントの電話番号およびデバイスモデルと比較され、電話番号が（４０８）５５５−０９８７に合致し、かつデバイスモデルがｉＰｈｏｎｅ（登録商標）５に合致する１つまたは複数のユーザアカウントはそれぞれ、合致するユーザアカウントを構成する。
【００３２】
いくつかの実施形態では、合致するユーザアカウントが複数見つかった場合、プロンプトがデバイスに送信され、現在の支払いリクエストを処理するために使用するユーザアカウントを、合致するユーザアカウントの中から１つ選択するようユーザに求める。様々な実施形態において、各ユーザアカウントと共に、少なくとも１組の支払い情報（例えば、クレジットカード情報、銀行口座情報、および／または他の支払い資金情報）が記憶されている。したがって、選択された合致するユーザアカウントは、支払いリクエストを処理するために使用されるべき関連付けられている１組の支払い情報を有するユーザアカウントである。選択された合致するユーザアカウントについての複数組の支払い情報が存在する場合、別のプロンプトがデバイスに送信されることがあり、支払いリクエストを処理するためにユーザが使用したい１組の支払い情報を選択するようユーザに求める。
【００３３】
いくつかの実施形態では、１つの合致するユーザアカウントが見つけ出される、および／または複数の合致するユーザアカウントの中から選択されると、デバイスは、そのユーザアカウントに対応付けられ（例えば、デバイスとユーザアカウントとの間の対応関係が記録され）、デバイスにインストールされている支払いプラグインを使用して支払いを円滑に行うことができる。いくつかの実施形態では、デバイスをユーザアカウントに対応付ける前に、さらなる検証が行われる。例えば、さらなる検証は、合致するユーザアカウントのパスワードの提示をユーザに促すことを含むことがある。次いで、ユーザが正しいパスワードを提示することができた場合にのみ、支払いプラグインをアクティベーションして、デバイスを合致するユーザアカウントに対応付けることができる。
【００３４】
しかし、属性が、記憶されているいずれかのユーザアカウントに対応する属性に合致する属性が発見されない場合には、支払いプラグインは正常にアクティベーションされ得ず、支払いリクエストの処理を円滑に行うために使用され得ない。
【００３５】
いくつかの実施形態では、アクティベーションメッセージ中の属性に合致する属性を含む記憶されているユーザアカウントを見つけることによって、デバイスの認証が行われ、そのデバイスが、ユーザアカウントを事前に作成しているユーザに知られているデバイスであることを確認する。そのような検証は、支払いプラグインを正常にアクティベーションし、記憶されている支払い情報を使用して支払いリクエストを完了するために、ユーザによる非認証のデバイス（すなわち、設定されているユーザアカウントと共に記憶されていない属性を有するデバイス）の使用を防止することができ得る。
【００３６】
ステップ２１２では、合致するユーザアカウントに少なくとも一部基づく支払いリクエストの処理の確定が、支払いプラグインから受信される。いくつかの実施形態では、アクティベーションされている支払いプラグインに関連付けられているユーザインターフェースがデバイスに表示される。例えば、ユーザインターフェースは、支払いリクエストに関連付けられている情報（例えば、商品の価格、および／または商品に関連付けられている他の情報）、ユーザに関連付けられている情報（例えば、ユーザに関連付けられている識別情報）、販売者に関連付けられている情報（例えば、ユーザに関連付けられている識別情報、および／または利用可能な資金／クレジットの量）、販売者への支払いの確定に関連付けられている選択可能な要素、および販売者への支払いのキャンセルに関連付けられている選択可能な要素を含むことがある。ユーザが、支払いの確定に関連付けられている選択可能な要素を選択する場合、（例えば、支払いの完了前のユーザの利用可能な資金／クレジットが商品の価格を超えていたと仮定して）支払いは正常に完了し、少なくとも商品のコストが、ユーザの利用可能な資金／クレジットから差し引かれる。
【００３７】
いくつかの実施形態では、ユーザが、支払いの確定に関連付けられている選択可能な要素を選択した後、支払いが完了される前に、支払いのサイズ（例えば、望みの商品の価格）が査定される。いくつかの実施形態では、支払いのサイズが第１のしきい値以下である場合、ユーザからのさらなるアクションを必要とせずに支払いが完了される。いくつかの実施形態では、支払いのサイズが、第１のしきい値よりも大きいが、（第１のしきい値よりも大きい）第２のしきい値以下である場合、ユーザは、対応付けられたユーザアカウントに関連付けられているパスワードの提示を促され、ユーザが正しいパスワードを提示するという条件が満たされると、支払いが完了される。しかし、ユーザが正しいパスワードを提示しない場合、支払いは完了されない。いくつかの実施形態では、支払いのサイズが第２のしきい値よりも大きい場合、支払いプラグインは、自動的に検証メッセージ（例えばテキストメッセージ）を送信するように構成され、このメッセージは、デバイスが、支払いの実施に用いるユーザアカウントに合致する属性を有するデバイスであることを確認するために、そのデバイスの少なくとも１つの属性を含む。次いで、デバイスを再び検証することができる場合、支払いが完了される。
【００３８】
いくつかの実施形態では、支払いの正常な完了に応答して、支払いプラグインは、取引の確定に関連付けられているウェブページにウェブブラウザをディレクトし、その後、支払いプラグインが閉じる。
【００３９】
しかし、ユーザが、支払いのキャンセルに関連付けられている選択可能な要素を選択する場合には、支払いは完了しない。
【００４０】
図３は、モバイルデバイス上の一連の例示的なユーザインターフェースを示す。以下に述べるように、ユーザインターフェース３０２〜３１６は、図２のプロセス２００などのプロセスを使用してモバイルデバイス（例えばスマートフォン）で行われるオンライン支払いを円滑に行うために、支払いプラグインが呼び出されて使用される例を示す。様々な実施形態において、ユーザインターフェース３０２〜３１６は、電子商取引ウェブサイトをブラウズするためにデバイスの使用者が使用しているウェブブラウザアプリケーションに関連付けられる。ユーザインターフェース３０２は、１００ドルで販売されている１組のイヤリングに関する商品情報に関連付けられているウェブページを示す。モバイルデバイスを使用するユーザは、イヤリングを購入したいと思い、したがって「支払いを行う」ボタン３５２を選択する。ユーザが「支払いを行う」ボタン３５２を選択したのに応答して、ユーザインターフェース３０４が表示される。ユーザインターフェース３０４は、ポップアップメッセージ３５４を示し、ポップアップメッセージ３５４は、モバイルデバイスに支払いプラグインがインストールされていないことをユーザに知らせ、支払いプラグインをダウンロードしてインストールしたいか否かユーザに尋ねる。ユーザは、支払いプラグインをダウンロードしてインストールすることに決め、したがって「ダウンロード」リンク３５６を選択する。ユーザが「ダウンロード」リンク３５６を選択すると、ユーザインターフェース３０６が現れる。ユーザインターフェース３０６は、支払いプラグインのダウンロードに関連付けられているプログレスバーを示す。支払いプラグインのダウンロードが完了されると、ユーザインターフェース３０８が現れる。ユーザインターフェース３０８は、支払いプラグインがインストールされていることを示す表示を含む。支払いプラグインがインストールされた後、ユーザインターフェース３１０が現れる。ユーザインターフェース３１０は、モバイルデバイスを認証するためにモバイルデバイスから支払いサーバにテキストメッセージが自動的に送信されていることを示す表示を含む。例えば、テキストメッセージは、電話番号などモバイルデバイスの属性を含むことがある。時として、テキストメッセージを送信した後、ユーザインターフェース３１２が現れる。ユーザインターフェース３１２は、現在のモバイルデバイスの移動電話番号（１３６＊＊＊＊９８０９）に合致することが判明している２つのアカウントに関連付けられている識別情報（電子メール）、すなわちSunny_***@hotmail.comとClover.***@gmail.comを含む。例えば、現在のモバイルデバイスの移動電話番号（１３６＊＊＊＊９８０９）に合致する電話番号を各ユーザアカウントが含むので、Sunny_***@hotmail.comとClover.***@gmail.comが特定されることがある。ユーザは、そのようなユーザアカウントの中から、モバイルデバイスを対応付けるユーザアカウントを選択するように促される。あるいは、ユーザは、必要に応じて、別のユーザアカウントを入力することもできる。この例では、ユーザは、モバイルデバイスを対応付けるために、ユーザアカウントSunny_***@hotmail.comに関連付けられるボタン３５８を選択する。ユーザがボタ��３５８を選択したのに応答して、ユーザインターフェース３１４が現れる。ユーザインターフェース３１４は、販売者に関連付けられる情報（販売者のＩＤは、may1235である）、商品の価格に関連付けられる情報（１００ドル）、取引を完了するために使用されるユーザアカウント（ユーザアカウントは、電子メールSunny_***@hotmail.comによって識別される）、および電子メールSunny_***@hotmail.comによって識別されるユーザアカウントに関連付けられる利用可能な資金（１０００ドル）を含む。いくつかの実施形態では、ユーザはまた、追加認証（図示せず）のために自分が選択した特定のアカウントに関連付けられているパスワード情報の入力を促される。この例では図示されていないが、いくつかの実施形態では、ユーザは、ユーザインターフェース３１４が示される前に、対応付けられたユーザアカウントに関連付けられている複数組の支払い情報（例えば、様々なクレジットカード情報や、様々な銀行口座）の中から選択するように促されることがある。利用可能な資金からの１００ドルの支払いを確定するために、ユーザは、「確定」リンク３６０を選択する。ユーザが「確定」リンク３６０を選択したのに応答して、ユーザインターフェース３１６が現れる。図示されていないが、支払いプラグインは、支払いの完了を円滑に行う。ユーザインターフェース３１６は、取引の正常完了および残りの利用可能な資金（９００ドル）に関連付けられているウェブページを示す。次いで、例えば、購入されたイヤリングが、電子メールSunny_***@hotmail.comによって識別される対応付けられたユーザアカウントに関連付けられている住所に宛てて、ユーザに発送されることがある。
【００４１】
図４は、支払いプラグインを使用して支払いを行うためのシステムの一実施形態を示す図である。この例では、システム４００は、支払いリクエストモジュール４０２と、支払いプラグイン配信モジュール４０４と、アクティベーションモジュール４０６と、取引モジュール４０８とを含む。いくつかの実施形態では、図１のシステム１００の支払いサーバ１０６は、システム４００を備えるように実装されることがある。
【００４２】
モジュールは、１つまたは複数のプロセッサ（処理装置）上で実行されるソフトウェアコンポーネントとして、特定の機能を実施するように設計されたプログラマブル論理デバイスおよび／または特定用途向け集積回路などのハードウェアとして、またはそれらの組合せとして実装することができる。いくつかの実施形態では、モジュールは、本発明の実施形態で述べる方法をコンピュータデバイス（例えば、パーソナルコンピュータ、サーバ、ネットワーク機器など）に実施させるためのいくつかの命令を含む、不揮発性記憶媒体（例えば、光ディスク、フラッシュ記憶デバイス、モバイルハードディスクなど）に記憶することができるソフトウェア製品の形態で具現化することができる。モジュールは、単一のデバイス上に実装することができ、または複数のデバイスにわたって分散させることもできる。
【００４３】
支払いリクエストモジュール４０２は、デバイスから支払いリクエストを受信するように構成される。例えば、デバイスは、移動電話やタブレットデバイスなどのモバイルデバイスを備えることがある。また、例えば、支払いリクエストは、ウェブサイトで販売されている商品の購入に関連付けられている選択可能な要素をユーザが選択したことに関連付けられているリクエストを備えることがある。
【００４４】
支払いプラグイン配信モジュール４０４は、支払いリクエストの送信元のデバイスに支払いプラグインがインストールされているかどうかに関連付けられる通知を受信するように構成される。受信された通知が、支払いプラグインがデバイスにまだインストールされていないことを示す場合、支払いプラグイン配信モジュール４０４は、デバイスにプロンプトメッセージを送信するように構成され、プロンプトメッセージは、支払いプラグインのダウンロードに同意するかどうかユーザに尋ねる。ユーザが、支払いプラグインのダウンロードの同意に関連付けられる選択を行った場合、支払いプラグイン配信モジュール４０４は、支払いプラグインをデバイスに送信するように構成されるか、または、支払いプラグイン配信モジュール４０４は、デバイスへの支払いプラグインの送信を別のエンティティに行わせるように構成される。しかし、受信された通知が、支払いプラグインがデバイスに既にインストールされていることを示す場合、支払いプラグイン配信モジュール４０４は、デバイスにプロンプトメッセージまたは支払いプラグインを送信しないように構成される。
【００４５】
アクティベーションモジュール４０６は、まず、支払いプラグインを最近インストールしたデバイスからアクティベーションメッセージを受信するように構成される。様々な実施形態において、アクティベーションメッセージは、デバイスに関連付けられる少なくとも１つ属性を含む。アクティベーションモジュール４０６は、アクティベーションメッセージに含まれる属性を、記憶されているユーザアカウントと比較して、アクティベーションの属性に合致する属性を含む記憶されているユーザアカウントがあるかどうか判断する。合致するユーザアカウントを見つけることができなかった場合、アクティベーションモジュール４０６は、デバイスにアクティベーション失敗メッセージを送信するように構成される。逆に、１つまたは複数の合致するユーザアカウントが見つかった場合、アクティベーションモジュール４０６は、そのような合致するユーザアカウントそれぞれに関連付けられているいくつかの識別情報をデバイスに送信し、次いで、（複数の合致するユーザアカウントがある場合には）デバイスを対応付ける１つの合致するユーザアカウントを選択するようにユーザに促すように構成される。アクティベーションモジュール４０６は、デバイスを対応付ける合致するユーザアカウントのユーザ選択を受信するように構成され、アクティベーションモジュール４０６は、選択された合致するユーザアカウントとデバイス（またはその属性）との間の対応関係を記録するように構成される。
【００４６】
取引モジュール４０８は、支払いリクエストの送信元のデバイスに対応付けられるユーザアカウントに基づいて支払いリクエストを処理するように構成される。取引モジュール４０８は、支払いリクエストの処理の確定をデバイスから受信するように構成され、いくつかの実施形態では、対応付けられたユーザアカウントに関連付けられている利用可能な資金の量が、支払いリクエストに関連付けられている商品の価格以上であるか否か判断するように構成される。対応付けられたユーザアカウントに関連付けられている利用可能な資金の量が、支払いリクエストに関連付けられている商品の価格以上である場合、取引モジュール４０８は、利用可能な資金から商品の価格を差し引き、販売を知らせるメッセージを商品の販売者に送信し、取引の正常完了を示すウェブページをデバイスに送信するように構成される。しかし、対応付けられたユーザアカウントに関連付けられている利用可能な資金の量が、支払いリクエストに関連付けられる商品の価格未満である場合には、取引モジュール４０８は、取引失敗メッセージをデバイスに送信するように構成される。
【００４７】
明らかに、本発明の趣旨および範囲から逸脱することなく、当業者は本出願を修正および変更することができる。したがって、本出願のそれらの修正および変更が本出願の特許請求の範囲および均等技術の範囲内にある場合、本出願は、それらの修正および変更も網羅するものとする。
【００４８】
理解しやすくするために、上記の実施形態をいくぶん詳細に説明してきたが、本発明は、提示した詳細に限定されない。本発明を実施する多くの代替方法がある。開示した実施形態は例示であり、限定ではない。
【図１】
2014535121.tif 000003
【図２】
2014535121.tif 000004
【図４】
2014535121.tif 000005
【図３】
2014535121.tif 000006
【国際調査報告】
2014535121.tif 000007
2014535121.tif 000008