JP2016131033A - モバイルデバイスによる支払い選択および承認 - Google Patents

Abstract

【課題】クレジットカード、デビットカード、および他の種類の銀行カードまたは電子口座での支払い方式は、支払い方式の無承認の使用から保護するために個人識別番号（ＰＩＮ）または他の暗号を使用する。カードリーダおよびキーボードは通常むきだしで、店員を含む他の人々に見え、したがってＰＩＮの秘密性を危険にさらす可能性がある。財布の中に複数のカードを入れて持ち歩くのは不便であり得る。加えて、複数のカードを持ち歩くことは同時に、一群のカードが紛失されるか、置き忘れられるか、または盗まれる場合、個人を大きなリスクおよび／または不便にさらす。
【解決手段】電子支払い方式で支払いを行うとき、ユーザは、ユーザのモバイルコンピューティングデバイスとの通信を通じて持ち主であることの追加の検証を提供することができる。ホストは、モバイルコンピューティングデバイス上で動作するモバイルアプリケーションを介してユーザに要求を送信してもよく、それが、ユーザに購入要求の承認または拒否を要求することができる。
【選択図】図１

Description

多くの商人は、顧客がクレジットカード、デビットカード、および他の種類の銀行カードまたは電子口座（例えば、ギフトカードなど）で支払うことを可能にしている。顧客がこれらの種類の支払い方式を使用し、支払い要求を満たすとき、商人は通常、検証プロセスを行う。検証プロセスは、識別子がカードから（例えば、スワイプカードリーダ、無線周波数識別子（ＲＦＩＤ）リーダ、マイクロチップリーダなどを介して）読み込まれた後に電子的に生じることが多い。検証プロセスはしばしば、カードの発行者または発行者の代理人と連絡を取り、要求された購入要求の金額を承認するかどうかを決定する。

いくつかの支払い方式は、支払い方式の無承認の使用から保護するために個人識別番号（ＰＩＮ）または他の暗号を使用する。例えば、販売時点情報管理システム（ＰＯＳ）で、ユーザがスワイプカードリーダを使用してユーザのデビットカードをスワイプし、次いでカードリーダのキーボードに関連したＰＩＮを入力してもよい。カードリーダおよびキーボードは通常むきだしで、店員を含む他の人々に見え、したがってＰＩＮの秘密性を危険にさらす可能性がある。現金自動預け払い機などの一部の場合では、キーボードは、他のユーザによってキーボードの視界を阻むかまたは制限するためのフードによって少なくとも部分的に覆われている。

人々は、一群のクレジットカード、デビットカード、ギフトカード、および他のカードまたは支払い方式などの、複数の支払い方式を有することが多い。財布の中に複数のカードを入れて持ち歩くのは不便であり得る。加えて、複数のカードを持ち歩くことは同時に、一群のカードが紛失されるか、置き忘れられるか、または盗まれる場合、個人を大きなリスクおよび／または不便にさらす。

本ＰＣＴ出願は、２０１１年６月２７日に出願された「Ｐａｙｍｅｎｔ Ｓｅｌｅｃｔｉｏｎ ａｎｄ Ａｕｔｈｏｒｉｚａｔｉｏｎ ｂｙ ａ Ｍｏｂｉｌｅ Ｄｅｖｉｃｅ」と題する米国特許出願第１３／１７０，１４４号に対する優先権を主張する。米国特許出願第１３／１７０，１４４号は、この参照によりその全体が本明細書に組み込まれる。

本ＰＣＴ出願は、２０１１年６月２７日に出願された「Ｐａｙｍｅｎｔ Ｓｅｌｅｃｔｉｏｎ ａｎｄ Ａｕｔｈｏｒｉｚａｔｉｏｎ」と題する米国特許出願第１３／１７０，１２１号に対する優先権を主張する。米国特許出願第１３／１７０，１２１号は、この参照によりその全体が本明細書に組み込まれる。

詳細な説明が、添付の図を参照しながら記載される。図中、参照番号の一番左の桁（複数）は、参照番号が最初に現れる図を識別する。異なる図の同じ参照番号は、類似または同一の品目を示す。
モバイル決済の選択および承認を提供する例示的なコンピューティング環境の概略図である。 図１のコンピューティング環境に含まれる様々な構成要素の例示的なコンピューティングアーキテクチャのブロック図である。 図１のコンピューティング環境に含まれる様々な構成要素の例示的なコンピューティングアーキテクチャのブロック図である。 図１のコンピューティング環境に含まれる様々な構成要素の例示的なコンピューティングアーキテクチャのブロック図である。 モバイルデバイスアプリケーションで支払いを承認する例示的なプロセスのフロー図である。 図１に示されるコンピューティング環境から様々な関係者間の相互作用を示す例示的なプロセスのフロー図である。 支払い承認の間に電子支払い方式を選択する例示的なプロセスのフロー図である。 支払い要求の穏やかな拒否を開始する例示的なプロセスのフロー図である。 モバイルデバイスアプリケーションによる使用の承認方式を選択する例示的なプロセスのフロー図である。 支払い選択および承認を可能にする例示的なユーザインターフェース（ＵＩ）である。 ホストからの承認メッセージの管理を可能にする例示的なＵＩである。

本開示は、クレジットカード、デビットカード、ギフトカード、または他の種類の電子支払いなどの電子支払い方式を使用するときに、安全性、秘匿性、および利便性を高める技法およびシステムを提供する。電子支払い方式で支払いを行うときに、ユーザは、ユーザのモバイルコンピューティングデバイス（例えば、携帯電話、タブレットコンピュータなど）との通信を通じて持ち主であることの追加の検証を提供することができる。例えば、ユーザは、小売商人の小売店で（直接またはオンラインで）ユーザのクレジットカードを挿入するかまたはスワイプしてもよい。次に、小売商人は、カードが有効であるか、十分な資金を有するか、および／または他の理由かどうかを検証するゲートウェイを通じてクレジットカード情報を処理してもよい。ゲートウェイは、発行者（「ホスト」）への要求を転送してもよい。様々な実施形態によれば、ホストは、モバイルコンピューティングデバイスで動作するモバイルアプリケーションを介してユーザに要求を送信してもよく、ユーザに購入要求を承認するかまたは拒否するのを求めてもよい。様々な実施形態では、ホストの要求は、要求を承認するモバイルアプリケーションを介してユーザに個人および／または認証情報（例えば、ＰＩＮ、パスワード、生体認証など）を入力するのを求めてもよい。

いくつかの実施形態では、ホストは、ユーザの一群の電子支払い方式を管理してもよい。ホストは、ユーザが承認プロセスの間、モバイルアプリケーションを介してホストからユーザに利用可能な様々な電子支払い方式にわたって支払額を分割するかまたは配分することを可能にしてもよい。例えば、ユーザは、ホストから要求を受信し、商人に最初に提供されるカードとは異なるカードを選択し、次いで支払い要求を承諾してもよい。商人の観点からすれば、支払いは、商人によって受信され、かつこのプロセスを開始された支払い方式を使用して処理されてもよい。しかしながら、ホストは、モバイルアプリケーションを介してユーザによって選択される支払い方式（複数）を使用して実際の支払いを商人に提供してもよい。

本明細書に記載される技法およびシステムは、多くの様式で実践されてもよい。以下の図を参照しながら実例の実践が以下に提供される。

図１は、モバイル決済の選択および承認を提供する例示的なコンピューティング環境１００の概略図である。環境１００は、商人１０４と相互作用するユーザ１０２を含む。商人１０４は、従来型実店舗の場所および／または１つ以上のネットワーク（複数）１０６を介してユーザ１０２にアクセス可能である電子市場を有してもよい。例えば、電子市場は、ユーザ１０２が商品および／またはサービスを購入することを可能にするウェブサイトであってもよく、あるいは販売され、貸し出され、賃借され、そうでなければまたは別の様式で商人１０４から入手可能となる品目をユーザが閲覧することを可能にするカタログによるサービスであってもよい。

商人１０４は、電子支払い方式（ＥＰＴ）１０８を使用してユーザ１０２からの支払いを承諾してもよく、他の支払い方式（例えば、現金、個人小切手、為替など）も承諾してもよい。ＥＰＴ１０８は、クレジットカードおよびデビットカード、ならびにギフトカード、ストアドバリューカード、または任意の他の種類の電子支払いなどの銀行カードを含み得る支払い方法である。ＥＰＴ１０８は、モバイルコンピューティングデバイス１１０（「ユーザデバイス」）を使用してユーザ１０２がＥＰＴ１０８の使用を承認することを可能にする後述される一連の事象を通じて処理されてもよい。ユーザデバイス１１０は、ネットワーク（複数）１０６への接続性を含み、かつユーザ入力を可能にする、携帯電話、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、ネットブック、携帯情報端末（ＰＤＡ）、ゲーミングデバイス、メディアプレーヤ、または任意の他のモバイルコンピューティングデバイスであってもよい。

商人１０４の販売時点情報管理システム（ＰＯＳ）１１２および／または商人サーバ１１４を介してユーザ１０２からＥＰＴ１０８を受信した後、商人は、承認に対する要求１１６をゲートウェイ１１８に送信してもよい。ゲートウェイ１１８は、商人１０４の代理の金融機関および／または経路指定の関係者であってもよく、それは、ＥＰＴ１０８をユーザ１０２に発行したか、および／またはユーザに対してＥＰＴ１０８のアカウントを管理する関係者であるホスト１２０へ商人からの要求１１６の経路指定をする。

１つ以上の実施形態によれば、ホスト１２０は、要求１１６を受信し、要求を処理し、次いで修正された要求１２４をユーザ１０２と関連付けられるユーザデバイス１１０に送信し得るホストサーバ１２２を含む。処理の間、ホストサーバ１２２は、ホスト１２０によって維持されるアカウントデータ１２６からＥＰＴ１０８に関する情報を取り出してもよい。アカウントデータ１２６は、修正された要求１２４を生成するための規則、ユーザ１０２のための選択肢、ユーザに利用可能な電子支払い方式、記憶されたユーザ選好、ならびにＥＰＴ１０８および／またはユーザ１０２に関する他のデータを含んでもよく、修正された要求１２４を生成するために使用されてもよい。

ユーザデバイス１１０は、通常、商人１０４がＥＰＴ１０８の識別子を受信した直後に修正された要求１２４を受信してもよい。修正された要求は、ＥＰＴ１０８を商人１０４に送信するために使用される通信経路とは異なる通信経路を使用してユーザデバイス１１０によって受信されてもよい。修正された要求１２４は、ユーザデバイス１１０で動作する支払いアプリケーションによって処理されてもよく、そのデバイスは、ユーザインターフェース１２８を使用して他の可能な選択肢の中からユーザ１０２が情報を受信し、かつ修正された要求１２４を承諾するかまたは拒否することを可能にする。支払いアプリケーションは、再びＥＰＴ１０８を商人１０４に送信するために使用される通信経路とは異なる通信経路を使用してホストサーバ１２２に戻すように送信される拡張された回答１３０（すなわち、応答）を生成してもよい。拡張された回答１３０は、承諾、特殊コード（例えば、個人識別番号（ＰＩＮ）、パスワード、または他の個人情報）、および場合により指定された電子支払い方式に関連した選択（例えば、ＥＰＴが修正された要求１２４を満たすために使用する選択）を含む。ホスト１２０は、ＰＩＮが正しく、かつユーザが要求１１６を承諾するかどうかを検証するなど、拡張された回答１３０の情報を検証してもよい。次に、ホストサーバ１２２は、回答１３２をゲートウェイ１１８に送信してもよく、その回答は、比較的短い時間量後に商人サーバ１１４および／または商人１０４のＰＯＳシステム１１２に転送されてもよい。拡張された回答１３０と違って、回答１３２は、より少ない情報を含み、ホスト１２０に向けられる特殊コードまたは他の情報を含むのではなく支払い要求１１６の承諾または拒否に主に関連してもよい。

ユーザデバイス１１０と併用してＥＰＴを使用することによって、ユーザ１０２は、ＥＰＴの誤用に対してより大きな安全性を経験することができる。例えば、ＥＰＴ１０８（またはＥＰＴ１０８の識別子）が盗まれ、商人１０４または上述された技法を用いる他の商人から品目を購入するために使用される場合、ユーザ１０２は、不正購入から保護するために購入要求を単純に拒否することができる。修正された要求がＰＩＮまたは他の特殊コードを要求する状況では、ユーザ１０２は、泥棒（または他の権限のない人物）がユーザデバイス１１０を保有するときでさえ不正使用に対して保護されることが可能である。加えて、セキュリティコードを入力するユーザデバイス１１０を使用することによって、ユーザが詐欺（例えば、カードスキミング、偽のＰＩＮパッドなど）を受けやすいような現金自動預け払い機と相互作用するときなど、セキュリティコードの盗用がより困難になり得る。

いくつかの実施形態では、商人１０４は、ホスト１２０と直接通信してもよく、かつ／あるいはホスト１２０が、ゲートウェイ１１８の一部またはすべての操作を行ってもよい。したがって、いくつかの実施形態では、環境１００は、本明細書に記載される技法に影響を与えなければゲートウェイ１１８を含まなくてもよい。

ネットワーク（複数）１０６は、環境１００に記載される様々なコンピューティングデバイス間の高速通信を可能にする有線および／またはワイヤレスネットワークを含んでもよい。いくつかの実施形態では、ネットワーク（複数）は、様々なコンピューティングデバイス（すなわち、商人サーバ１１４、ホストサーバ１２２、およびユーザデバイス１１０）間の通信を容易にするように、場合により互いに併用して使用されるローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、携帯電話ネットワーク（ＭＴＮ）、および他の種類のネットワークを含んでもよい。コンピューティングデバイスは、以下の図を参照しながらさらに詳細に記載される。

図２ａ〜２ｃは、図１のコンピューティング環境に含まれる様々なコンピューティングデバイスの例示的なコンピューティングアーキテクチャを示す。

図２ａは、商人サーバ１１４、ＰＯＳシステム１１２、または両方の例示的なコンピューティングアーキテクチャを示す。このアーキテクチャは、プロセッサ２０２およびメモリ２０４を含んでもよい。メモリ２０４は、様々なモジュール、アプリケーション、プログラム、または他のデータを記憶してもよい。メモリ２０４は、プロセッサ２０２によって実行されるときに、プロセッサに商人１０４に対して本明細書に記載される操作を行わせる命令を含んでもよい。いくつかの実施形態では、メモリ２０４は、トランザクションマネージャ２０６、およびトランザクションマネージャの一部またはトランザクションマネージャとは別個の承認モジュール２０８を格納してもよい。トランザクションマネージャ２０６は、ユーザ１０２との取引を処理し、ＥＰＴ１０８を受信してもよい。承認モジュール２０８は、ＥＰＴが回答１３２によって示されるように承認されるかどうかを決定するように、上述されるようにゲートウェイ１１８を介してまたは直接ホスト１２０を通じてＥＰＴ１０８を承認してもよい。いくつかの実施形態では、トランザクションマネージャ２０６、承認モジュール２０８、またはそれぞれの部分は、ＰＯＳシステム１１２および商人サーバ１１４などの複数のコンピューティングシステムにわたって分布させられてもよい。

図２ｂは、ホストサーバ１２２の例示的なコンピューティングアーキテクチャを示す。このアーキテクチャは、プロセッサ（複数）２１０およびメモリ２１２を含んでもよい。メモリ２１２は、様々なモジュール、アプリケーション、プログラム、または他のデータを記憶してもよい。メモリ２１２は、プロセッサ（複数）２１０によって実行されるときに、プロセッサにホスト１２０に対して本明細書に記載される操作を行わせる命令を含んでもよい。いくつかの実施形態では、メモリ２１２は、アカウントマネージャ２１４および承認マネージャ２１６を格納してもよい。アカウントマネージャ２１４は、ホスト１２０とのアカウントを有するそれぞれのユーザに対する様々な規則、設定、ＥＰＴ、および他のデータを記憶するアカウントデータ１２６を管理してもよい。承認マネージャ２１６は、少なくとも部分的にユーザデバイス１１０とのユーザの相互作用に基づき、支払い要求を承諾するかまたは拒否するかのいずれかであるように、場合によりゲートウェイ１１８を介して商人１０４からの通信を処理してもよい。

図２ｃは、ユーザデバイス１１０の例示的なコンピューティングアーキテクチャを示す。このアーキテクチャは、プロセッサ（複数）２１８およびメモリ２２０を含んでもよい。メモリ２２０は、様々なモジュール、アプリケーション、プログラム、または他のデータを記憶してもよい。メモリ２２０は、プロセッサ（複数）２１８によって実行されるときに、プロセッサにユーザ１０２に対して本明細書に記載される操作を行わせる命令を含んでもよい。いくつかの実施形態では、メモリ２２０は、ホストサーバ１２２の承認マネージャ２１６および／またはアカウントマネージャ２１４と相互作用し得る支払いアプリケーション２２２を格納してもよい。支払いアプリケーション２２２は、検証モジュール２２４、条件モジュール２２６、および選択モジュール２２８をさらに含んでもよい。それぞれのモジュールが順に記載される。

様々な実施形態によれば、検証モジュール２２４は、ホストサーバ１２２の承認マネージャ２１６から受信された修正された要求１２４に基づき、承認のためのセキュリティコード要求（例えば、ＵＩなど）を生成するかどうかを決定してもよい。ホストサーバ１２２によって（または場合により支払いアプリケーション２２２によって）要求されるときに、検証モジュール２２４は、商人１０４から生じ、かつホストサーバ１２２を通って送信された支払い要求を承諾するために、ＰＩＮ、パスワード、生体データ、または他の個人情報などのセキュリティコードをユーザに入力することを求めてもよい。

条件モジュール２２６は、ユーザデバイス１１０に関する情報を提供し、セキュリティコードの使用に対して条件を適用し、および／または修正された支払い要求１２４もしくは他の種類の情報に関連する他のものの自動承認もしくは拒絶してもよい。例えば、承認マネージャ２１６は、ユーザデバイス１１０の場所を要求してもよく、全地球測位システム（ＧＰＳ）、三角測量、または他の情報を使用して提供されてもよい。この情報が商人の場所、ユーザ１０２の既知の場所（例えば、自宅、仕事場など）、または別の指定または学習された場所と一致すると、承認マネージャ２１６は、支払いを承諾するように（例えば、セキュリティコードの要件を取り除くなど）、ユーザによって必要とされる応答を調節してもよい。

選択モジュール２２８は、ユーザに利用可能であり、かつアカウントデータ１２６に記憶される他のＥＰＴ間の支払いをユーザ１０２が選択し、配分することを可能にしてもよい。例えば、アカウントデータ１２６は、多くの異なる種類のユーザのＥＰＴ間の関連性を含んでもよく、ＥＰＴのうちのいずれか１つが商人１０４に呈示されるときにアクセス可能であってもよい。次に、ホストは、選択モジュール２２８を介して選択されたＥＰＴのうちの１つを使用して商人１０４によって支払い要求１１６を満たしてもよい。ユーザ１０２は、比率、支払額、または他の配分に基づき複数のＥＰＴ間の資金を配分してもよい。

図３は、モバイルデバイスのアプリケーションで支払いを承認する例示的なプロセス３００のフロー図である。プロセス３００は、ハードウェア、ソフトウェア、またはこれらの組み合わせで実践され得る一連の操作を表す論理的なフローグラフにおける一群のブロックとして示される。このブロックの群は、ブロックに記載される様々な操作を行い得るそれぞれの関係者の下で整理される。ソフトウェアの状況では、ブロックは、１つ以上のプロセッサによって実行されるときに、記載された操作を行う１つ以上のコンピュータ可読記憶媒体に記憶されるコンピュータ実行可能命令を表す。概して、コンピュータ実行可能命令は、特定の機能を行うかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。操作が記載される順は、限定して解釈されるものではなく、記載されたブロックのあらゆる番号は、プロセスを実践するためにあらゆる順および／または並行して組み合わせることができる。プロセス３００に加えて、本開示を通して記載される他のプロセスは、それに応じて解釈されるべきであろう。

プロセス３００は、環境１００を参照しながら説明され、ホストサーバ１２２、ＰＯＳシステム１１２、および／または商人サーバ１１４のうちのいずれか１つ以上と協働してユーザデバイス１１０によって行われてもよい。言うまでもなく、プロセス３００（および本明細書に記載される他のプロセス）は、他の類似および／または異なる環境で行われてもよい。

３０２では、ユーザ１０２は、ＥＰＴ１０８を使用して支払いを商人１０４に提供してもよい。例えば、ユーザ１０２は、従来型実店舗の場所の商人１０４と相互作用し、ＥＰＴを直接商人１０４に提出してもよい。ユーザはまた、ネットワーク（複数）１０６を使用してアクセス可能な電子市場を通じて商人１０４と相互作用してもよい。場合によっては、ユーザは、ユーザデバイス１１０を使用してブラウザまたはアプリケーションを介してＥＰＴ１０８を転送してもよい。

３０４では、ユーザデバイス１１０は、支払いアプリケーション２２２を使用して購入を承認する要求（すなわち、修正された要求１２４）を受信してもよく、商人サーバ１１４からゲートウェイ１１８および／またはホストサーバ１２２を通ってユーザデバイス１１０に達するように経路指定されてもよい。支払いアプリケーション２２２は、ＥＰＴ１０８を商人に（例えば、ブラウザなどを介して）転送するために使用され得るアプリケーションとは異なってもよい。この要求は、コードに対する要件、利用可能な電子支払い方式、支払うべき金額などの要求の詳細、取引に含まれる品目などの追加情報を含んでもよい。

３０６では、支払いアプリケーション２２２は、少なくとも部分的にユーザデバイス１１０を使用して提供されるユーザ１０２からの入力に基づき、支払いを承認するかまたは拒否するかを決定してもよい。ユーザ１０２が支払いを拒否することを決定すると、３０８では（「いいえ」経路に従って）、支払いアプリケーション２２２は、支払いを拒否するように応答をホストサーバ１２２に送信してもよい。しかしながら、ユーザが支払い要求を承認することを決定すると（決定操作３０６から「はい」経路に従って）、３１０でプロセス３００が継続してもよい。

３１０では、支払いアプリケーション２２２は、要求に対する応答（または回答）を生成してもよい。応答は、１つ以上のＥＰＴの選択（操作３０２で使用されたＥＰＴを含むかまたは異なる）を含んでもよく、選択モジュール２２８によって収集されるか、および／または処理されてもよい。応答はまた、ＰＩＮ、パスワード、生体感知データ、または検証モジュール２２４によって収集されるか、および／または処理され得る他の個人情報などのコードを含む。場合によっては、応答は、ユーザ１０２が支払い要求を拒絶することを望むときに拒絶コマンドを含んでもよい。応答はまた、ユーザデバイス１１０の場所などの条件情報を含んでもよく、条件モジュール２２６によって収集されるか、および／または処理されてもよい。

３１２では、支払いアプリケーションは、応答および関連情報をホスト１２０のホストサーバ１２２に送信してもよい。次に、ホストサーバ１２２は、応答がホスト１２０からの要求に含まれるコードおよび／または条件要件を満たすときなど、応答が正しいときに、応答をゲートウェイ１１８および／または商人１０４に中継してもよい。

図４は、図１に示される環境１００から様々な関係者間の相互作用を示す例示的なプロセス４００のフロー図である。プロセス４００に示される操作は、それぞれの操作を行い得る関係者の下で示されるが、操作は、他の構成では、少なくとも部分的に他の関係者によって行われてもよい。例えば、商人サーバ１１４下で指定される操作の一部またはすべてが、ＰＯＳシステム１１２によって行われてもよい。操作は、それぞれの関係者間で送信される情報の安全性に対するデータの暗号化／復号化を含んでもよい。

４０２では、商人サーバ１１４は、ユーザ１０２からＥＰＴ１０８を介して支払いを受信してもよい。

４０４では、商人サーバ１１４は、資金を検証するか、電子支払い方式を認証するか、または他の理由のために操作４０２で受信された支払いに対する承認を要求してもよい。

４０６では、商人１０４の代理の金融機関または別の関係者であり得るゲートウェイ１１８は、支払いを承認する発行者（すなわち、ホスト１２０）を識別してもよい。

４０８では、アカウントマネージャ２１４を介するホストサーバ１２２は、操作４０４および４０６からの承認メッセージおよび支払いと関連付けられるユーザ１０２を決定してもよい。ホストサーバ１２２は、アカウントデータ１２６を介してＥＰＴ１０８の識別番号をユーザ１０２に一致させてもよい。

４１０では、ホストサーバ１２２は、承認パラメータを決定してもよい。承認パラメータは、自動的に承認される購入品（例えば、ホワイトリストに載せられたもの、所定の金額未満のものなど）または支払い要求を処理する承認に対する特定の要件（例えば、承諾に加えてセキュリティコードが必要とされるどうかなど）などの承認に対する規則に基づいてもよい。

４１２では、ホストサーバ１２２は、ユーザがＥＰＴ１０８を使用する資格があるかどうかを決定してもよい。例えば、ホストサーバ１２２は、使用者のアカウントが支払いを成立させるのに必要な資金を有するかどうかを決定してもよく、かつ／あるいはホストサーバは、要求が不正リスクにより拒否されるべきかどうかを決定する様々な不正検査を行ってもよい。ユーザがＥＰＴもしくは他のＥＰＴを使用する資格があること、および／または不正リスクが許容範囲（閾値点数未満など）であることをホストサーバ１２２が決定すると、４１４で処理が継続してもよい。

４１４では、承認が必要とされると、承認マネージャ２１６を介するホストサーバ１２２は、修正された要求（例えば、修正された要求１２４）をユーザ１０２と関連付けられるユーザデバイス１１０に送信してもよい。場合によっては、ユーザ１０２は、家族の一員、取引先、同僚、友人などの別の人物に承認または購買（ＥＰＴの使用）を委託してもよい。したがって、ユーザデバイス１１０を操作するユーザ１０２は、必ずしもＥＰＴ１０８を商人１０４に呈示するユーザでなくてもよい。

４１６では、支払いアプリケーション２２２を介するユーザデバイス１１０は、承認パラメータを含む承認メッセージを処理してもよい。例えば、支払いアプリケーション２２２は、検証モジュール２２４を介してコードを要求するかどうかを決定するか、条件モジュール２２６を使用して条件（例えば、ユーザデバイスの場所など）を決定するか、またはユーザ１０２への要求の呈示の前もしくは呈示中に他の可能な操作を行ってもよい。加えて、支払いアプリケーション２２２を介するユーザデバイス１１０は、選択モジュール２２８を使用して操作４０２で開始される購入を満たす他のまたは追加のＥＰＴをユーザ１０２が選択することを可能にしてもよい。

４１８では、ユーザデバイス１１０は、応答（回答）をホストサーバ１２２に戻すように送信してもよい。応答は、承諾または拒否、コード、指定されたＥＰＴ（複数）、および条件情報のうちの少なくとも１つ以上を含んでもよい。

４２０では、承認モジュール２１６を介するホストサーバ４２０は、ユーザが支払いを承諾するときに応答を検証してもよい。例えば、承認モジュール２１６は、コードが正しいこと、条件が満たされることなどを検証してもよく、アカウントデータ１２６を使用して行われてもよい。

４２２では、承認モジュール２１６は、応答が承認される（すなわち、承諾され、かつ正しい）かどうか、ユーザ１０２が支払いのための十分な資金を有するかどうか、かつ支払いが不正であり得ないかどうかを決定してもよい。応答がユーザから承認され、情報（例えば、コード、条件など）が正しいとき、または承認が決定操作４１４から必要とされないとき、かつ十分な資金が利用可能であり、または不正のリスクが低い（例えば、閾値点数未満など）とき、承諾応答は、４２４で商人サーバ１１４に送信されてもよく、４２６でゲートウェイを介して転送されてもよい。応答がユーザ１０２から拒否され、ユーザが十分な資金を欠き、および／または不正リスクが高いと、拒絶（拒否）応答は、４２８で商人サーバ１１４に送信されてもよく、４３０でゲートウェイを介して転送されてもよい。支払いはまた、ユーザデバイス１１０を介するユーザ１０２からの承認のための通信より前に、所定の要因に基づき、ユーザのアカウントが十分な資金を欠き、および／または支払いが不正であり得ることをホストサーバ１２２が決定すると、決定操作４１４から経路「いいえ」に従って拒否されてもよい。

図５は、支払い承認の間にＥＰＴを選択する例示的なプロセス５００のフロー図である。プロセス５００は、以下の記載において支払いアプリケーション２２２を介してユーザデバイス１１０によって行われると記載されるが、プロセス５００はまた、アカウントデータ１２６に記憶される規則に基づいて決定が選択されるときなど、アカウントマネージャ２１４を介してホストサーバ１２２によって部分的または全体的に行われてもよい。

５０２では、支払いアプリケーション２２２は、承認メッセージを受信してもよい。承認メッセージは、支払うべき金額、条件、コードに対する要件、および／または他の情報を含んでもよい。

５０４では、支払いアプリケーション２２２の選択モジュール２２８は、ユーザ１０２による選択に対するＥＰＴを提供してもよく、商人１０４に提供されるＥＰＴ１０８（例えば、操作３０２における）とは異なってもよい。

５０６では、選択モジュール２２８は、支払うべき金額の少なくとも一部分を満たすＥＰＴの選択を受信してもよい。

５０８では、選択モジュール２２８は、操作５０６で選択されたＥＰＴと関連付けられる金額（または割合など）を受信してもよい。

５１０では、選択モジュール２２８は、追加のＥＰＴが使用されるべきか、またはユーザ１０２によって選択されるべきであるかどうかを決定してもよい。例えば、支払うべき金額が操作５０８での選択後に依然としてそのままである場合、ユーザ１０２は、別のＥＰＴおよび／または別の金額を入力するよう促されてもよく、「はい」経路に従う操作５０６（または操作５０８）に戻るようにプロセスに指示してもよい。

他のＥＰＴが使用されるべきではなく、操作５１０から「いいえ」経路に従うと、支払いアプリケーション２２２は、操作５０２からの承認メッセージを満たすために５１２で承認をホストに送信してもよい。

様々な実施形態では、支払いアプリケーション２２２は、ホストサーバ１２２からの金融情報（例えば、残高情報など）を依頼し、貸越またはＥＰＴの信用限度の超過を防ぐことを試みてもよい。貸越が起こり得るかまたは可能性があることを支払いアプリケーション２２２が決定すると、支払いアプリケーションは、ユーザを促し、および／または決定操作５１０で別のＥＰＴの使用を要求してもよい。

いくつかの実施形態では、アカウントデータ１２６は、ユーザに対するＥＰＴを選択する特定の規則を含んでもよい。例えば、アカウントデータ１２６は、指定された商人に対する特定のＥＰＴを使用する規則を含んでもよい。特定のＥＰＴは、指定された商人に対する追加の報酬（点数、マイルなど）を含むクレジットカードであってもよい。これらの規則は、ユーザによって生成されるか、ユーザ１０２の過去の取引から取り出されるか、そうでなければユーザに対して生成されてもよい。いくつかの実施形態では、好ましいＥＰＴ（または場合により複数のＥＰＴ）は、アカウントマネージャ２１４によってユーザに予め選択され、かつ予め選択するプロセスを介するなど、支払いアプリケーション２２２を介してユーザの確認の対象になってもよい。

図６は、支払い要求の穏やかな拒否を開始する例示的なプロセス６００のフロー図である。穏やかな拒否は、承認プロセスが停止される時間（例えば、深夜など）の間に要求されるとき、および／またはユーザ１０２が要求に応答しないときに使用されてもよい。プロセス６００は、ホストサーバ１２２によって行われてもよいが、他の関係者またはコンピューティングデバイスがプロセスを実践するために使用されてもよい。

６０２では、ホストサーバ１２２は、商人１０４から生じる購入を承認する要求を受信し、場合によりゲートウェイ１１８を介して中継されてもよい。

６０４では、承認マネージャ２１６を介するホストサーバ１２２は、ユーザデバイス１１０を介してユーザ１０２へ伝達せずに購入要求に対する自動返信を可能にする規則が存在するかどうかを決定してもよい。例えば、承認マネージャ２１６は、要求に自動的に返信するかどうかを決定するアカウントデータ１２６に記憶される設定または規則を決定するように、アカウントマネージャ２１４によって提供される情報を使用してもよい。規則は、一部の購入額が自動的に承認されること（例えば、カテゴリ、商人に限り、またはこれらに限らない閾値未満など）を示してもよく、ユーザデバイス１１０を介してユーザ１０２との相互作用なしに自動承諾をもたらしてもよい。規則はまた、一部の購入をブラックリストに載せてもよく、ユーザデバイス１１０を介してユーザ１０２との相互作用なしに自動拒否をもたらしてもよい。要求が自動返信に対して資格がないとき、決定操作６０４によって決定されるように、６０６で処理が継続してもよい。

６０６では、承認マネージャ２１６は、場合によりアカウントデータ１２６に記憶された規則または設定に従って、要求がユーザデバイス１１０を介してユーザ１０２に送信され得るかどうかを決定してもよい。例えば、ユーザ１０２は、深夜から早朝（または他の日、他の時間など）など、ある時間帯に承認メッセージを受信するのを停止することを決定してもよい。承認マネージャ２１６が、停止された時間であることを決定すると、承認マネージャは、６０８で穏やかな拒否を発行してもよく、６０２で受信された要求に対する一時的な拒絶として機能してもよい。この場合、ホストサーバ１２２は、６１０で遅延を行ってもよく、停止時間が経過したかどうか（遅延後）再び決定してもよい。

６０６で停止がないと（「いいえ」経路に従って）、６１２で処理が継続してもよい。６１２では、承認マネージャ２１６を介するホストサーバ１２２は、支払いアプリケーション２２２に対してユーザデバイス１１０を介して要求をユーザ１０２に送信してもよい。

６１４では、ホストサーバ１２２は、所定の時間量内にユーザ１０２から応答が受信されたかどうかを決定してもよい。所定の時間量内に応答が受信されると、６１６（操作６１４の決定に先行してもよい）で応答が受信され、次いで応答を商人１０４に（場合によりゲートウェイ１１８を介して）転送する。

しかしながら、６１４で所定の時間量内に応答が受信されないと（「いいえ」経路に従って）、承認マネージャ２１６を介するホストサーバ１２２は、６２２で再びユーザに連絡することを試みるかどうかを決定する６２０の規則（複数）を適用してもよい。例えば、規則は、所定の金額まで、および／または他の基準に基づき、承認された商人からの支払い要求を承認するようにホスト１２０に指示してもよい。同様に、規則はまた、規則に規定された様々な理由のために支払いを拒否するようにホスト１２０に指示してもよい。規則はまた、決定操作６２２で再び試みないと決定する前に行うホスト１２０に対するいくつか試みを示してもよい。承認マネージャ２１６が決定操作６２２で再び試みると、穏やかな拒否を発行することによって操作６０８で処理が再開し、次いで、上述され、かつ図５に示されるように操作６１０の遅延によって処理が進んでもよい。

規則によって限度に達したかもしくは越えたとき、または規則に含まれる他の理由のためなど、操作６２２の決定が再び試みるべきでないとき、承認マネージャ２１６は、支払い要求を満たすかまたは支払い要求を拒否するかのいずれかである応答を操作６２０からの規則を使用して決定してもよい。次に、応答は、場合によりゲートウェイ１１８を介して６１８で商人に転送されてもよい。

図７は、モバイルデバイスアプリケーションによる使用のための承認方式を選択する例示的なプロセス７００のフロー図である。プロセス７００は、ホストサーバ１２２よって行われてもよいが、他の関係者またはコンピューティングデバイスがプロセスを実践するために使用されてもよい。プロセス７００は、ユーザデバイス１１０にある支払いアプリケーション２２２の条件モジュール２２６と協働して操作してもよい。後述されるように、プロセス７００は、ユーザデバイス１１０の場所と関連付けられる条件を参照しながら記載されるが、他の条件がプロセス７００を使用して実践されてもよい。

７０２では、ホストサーバ１２２は、購入を承認する要求を受信してもよい。

７０４では、ホストサーバ１２２は、承認が、商人１０４の場所に対するユーザデバイス１１０の場所などの条件の対象となるかどうかを決定してもよい。承認が決定操作７０４の条件の対象となると、「はい」経路に従って、７０６で処理が継続してもよい。

７０６では、ホストサーバ１２２は、条件モジュール２２６を介してユーザデバイス１１０の場所を要求してもよく、ユーザデバイス１１０のＧＰＳ受信部などを介して場所（または他の情報）を取得してもよい。

ユーザデバイス１１０から条件情報を受信した後に、７０８では、ホストサーバ１２２は、ユーザデバイス１１０の場所を商人１０４の場所またはユーザ１０２と関連付けられた既知の場所（例えば、ユーザの家、事務所、頻繁に訪れた場所など）と比較してもよい。７１０では、ホストサーバ１２２は、デバイスの場所が商人の場所または既知の場所と一致するかどうかの比較に基づいて決定してもよい。７１２で不一致が記録されてもよいが、７１４で一致が記録されてもよい。

７１６では、承認マネージャ２１６を介するホストサーバ１２２は、承認要件を決定してもよい。いくつかの実施形態では、この承認は、結果（すなわち、操作７１２および７１４）に基づいてもよい。この決定は、他の関連要因を含んでもよい。例えば、関連要因は、支払いが遠隔取引（例えば、オンライン、電話によるなど）または従来型実店舗の場所での手が届く距離の取引に対するかどうかを含んでもよい。後者の状況では、ユーザデバイスの場所と商人の場所との一致（操作７１４）が、軽減された承認プロセス（簡略化または皆無）をもたらしてもよい。前者の状況（遠隔取引）では、ユーザデバイス１１０の場所は、既知および／または頻度が高い場所（自宅、仕事場、学校など）と比較されてもよく、次いで承認プロセスを選択するために使用されてもよい。例えば、ユーザデバイス１１０が未知の場所（例えば、自宅ではないなど）に位置するときに、より困難な承認プロセス（例えば、コードに対する要求を含む）が使用されてもよい。

７１８では、承認マネージャ２１６を介するホストサーバ１２２は、承認メッセージをユーザデバイスに送信してもよい。

７２０では、承認マネージャ２１６を介するホストサーバ１２２は、応答を受信し、検証してもよい。７２２で応答が承認され、正しい（例えば、（要求される場合）正しいコードが受信されるなど）とき（「はい」経路に従って）、ホストサーバ１２２は、場合によりゲートウェイ１１８を介して７２４で承認を商人に送信してもよい。応答が拒否されるとき、もしくは場合によりコードが正しくないとき、または７２２で過度の遅延（例えば、図６の操作６２０）の後（「いいえ」経路に従って）、ホストサーバ１２２は、場合によりゲートウェイ１１８を介して７２６で拒絶を商人に送信してもよい。

いくつかの実施形態では、操作７０８〜７１４から決定される場所情報は、支払い要求を満たすかどうかを決定するホストサーバ１２２によって別のチェックポイントとして使用されてもよい。例えば、プロセス７００は、場所情報に対する要求の前または同時に、承認メッセージ７１８をユーザデバイス１１０に送信することを含んでもよい。操作７２０は、支払いを承認するためにユーザの決定を場合により覆すかどうかを決定する操作７１２〜７１４からの情報を使用してもよい。例えば、７１２で場所が異なり、不正が起こり得る（例えば、誰かがユーザデバイス１１０を盗んだなど）ことをホストサーバ１２２が決定すると、ホストサーバ１２２は、承認メッセージが支払いを承認する意図を有するユーザデバイス１１０から受信され、かつ正しいコード（要求される場合）を含むときであっても支払いを拒否してもよい。

図８は、支払い選択および承認を可能にする例示的なユーザインターフェース（ＵＩ）８００である。ＵＩ８００は、ユーザデバイス１１０で動作する支払いアプリケーション２２２を介してユーザ１０２に呈示されてもよい。ＵＩ８００は、情報セクション８０２、支払い選択セクション８０４、コードセクション８０６、決定セクション８０８、またはこれらの任意の組み合わせを含んでもよい。それぞれのセクションが順に記載される。

情報セクション８０２は、支払うべき金額８１０、ならびに場合により、商人の識別子８１２および／または説明８１４などの支払取引の説明を提供してもよく、支払取引の品目／サービスまたは他の詳細を表示してもよい。いくつかの実施形態では、説明は、より多くの情報へのリンクを含んでもよい。

支払い選択セクション８０４は、部分的に選択モジュール２２８によって事前設定され、図５に示されるプロセス５００に従う選択肢を含んでもよい。支払い選択セクション８０４は、少なくとも部分的にホストサーバ１２２にアクセス可能なアカウントデータ１２６の情報に基づき、ユーザに利用可能であるＥＰＴ８１６を含んでもよい。加えて、支払い選択セクション８０４は、購入額８１８の割合および／または支払うべき金額８２０など、ＥＰＴ８１６のそれぞれに対して含める金額の選択を含んでもよい。第１のＥＰＴに対する購入額の１００％の入力を示す例示的なデータが図８に示される。いくつかの実施形態では、これは、ユーザ１０２に対して利便性のために既定の入力として選択モジュール２２８によって事前設定されてもよい。選択モジュール２２８は、ユーザがそれぞれのＥＰＴから特別な報酬を取得することを可能にするなどのため、一部の商人または製品カテゴリに対する特定のＥＰＴの選好を生成する、アカウントデータに記憶される規則などの規則に基づく既定の入力を生成してもよい。

コードセクション８０６は、承認メッセージによって必要とされるときに、コードを入力する１つ以上の選択肢を含んでもよい。場合によっては、複数の選択肢が図８に示されるようなコードセクションに含まれてもよい。しかしながら、場合によっては、コードセクション８０６は、ＰＩＮ８２２、生体認証８２４、パターン８２６、または他の種類のコードなどのある種類のコードのみを可能にしてもよい。

決定セクション８０８は、支払い要求を拒絶する拒絶コマンド８２８と、支払い要求を承諾する承諾コマンド８３０とを含んでもよい。いくつかの実施形態では、コードが必要とされないとき、コードセクション８０６は、省略され、グレーアウト表示され、そうでなければ利用されない場合がある。この状況では、ユーザは、要求された支払いを承認する承諾コマンド８３０を選択することしか必要とされなくてもよい。

ＵＩ８００はまた、追加の情報を含んでもよい。例えば、これは、ユーザがＵＩ８００を介してメッセージを受信するユーザ１０２ではない（例えば、代理人が承認しているユーザ１０２の代理としてＥＰＴを使用しているなど）ときに、支払いを開始するユーザからの個人メッセージ（テキスト、音声、映像などによる）を含んでもよい。

図９は、ホストからの承認メッセージの管理を可能にする例示的なＵＩ９００である。ＵＩ９００は、ホストサーバ１２２によって供給され、かつユーザデバイス（例えば、ユーザデバイス１１０または別のコンピューティングデバイス）を介してアクセス可能なアカウントマネージャ２１４を介してユーザ１０２に呈示されてもよい。ＵＩ９００は、最近の活動セクション９０２、規則セクション９０４、メニューセクション９０６、またはこれらの任意の組み合わせを含んでもよい。それぞれのセクションが順に記載される。

最近の活動セクション９０２は、ユーザ１０２が未来の取引の発生または類似の取引に対する規則を容易に作成することを可能にし得る前回の取引を含んでもよい。最近の活動セクション９０２は、取引のエンティティ指定子９０８および日付９１０を含んでもよい。それぞれの取引では、最近の活動セクション９０２は、関係者、カテゴリ、分野などからの承認メッセージを自動的に承認するホワイトリスト選択肢９１２を含んでもよく、指定された期間につき指定された取引額（例えば、１週間に＄５０、１回の取引に＄１００など）まで含んでもよい。選択肢はまた、関係者、カテゴリ、分野などに対する承認メッセージを自動的に拒否するブラックリスト選択肢９１４を含んでもよい。加えて、最近の活動セクション９０２は、ユーザ１０２が関係者、カテゴリ、および／または分野に対する承認の種類９１６を選択することを可能にしてもよい。いくつかの実施形態では、最近の活動選択はまた、ＥＰＴセレクタ９１８を使用してユーザ１０２がＥＰＴを関係者、カテゴリ、および／または分野に関連付けることを可能にしてもよい。

規則セクション９０４は、ユーザ１０２が承認メッセージを自動的に承諾するかまたは拒絶するように適用され得る規則を生成することを可能にしてもよい。規則は、説明９２０、許容額９２２、および／または承認種類９２４を含んでもよい。例えば、許容額９２２は、期間を含んでもよい。規則セクション９０４は、追加の規則を追加する「さらに追加」コマンド９２６を含んでもよい。ユーザはまた、規則を削除するか、そうでなければＵＩ９００を介して規則を管理することができてもよい。

メニューセクション９０６は、ユーザがＵＩ９００を操作することを可能にするコマンドを含んでもよい。コマンドは、閉じるコマンド９２８と、ヘルプコマンド９３０と、および／またはホストサーバ１２２による使用のためのアカウントデータ１２６にＵＩ９００によって取得される情報を保存する保存コマンド９３２とを含んでもよい。

付記
１．モバイルデバイスを使用して支払いを承認する方法であって、
実行可能命令で構成されるモバイルデバイスの制御下で、ホストからモバイルデバイスを介して、関連した銀行カード識別子を有する銀行カードを使用する支払いを承認する要求を受信することであって、銀行カード識別子が、商人の場所で、または要求を受信するために使用される通信経路とは異なる通信経路を電子的に通って、商人に送信されることと、
モバイルデバイスのユーザに少なくとも商人の名前および支払額を含む要求の説明を呈示することと、
ユーザから、要求に対する応答を受信することであって、応答が、ユーザによって入力されるセキュリティコードを含むことと、
要求に応じてセキュリティコードを含む応答をホストに送信することであって、応答が、セキュリティコードが正しいときに銀行カードを有する商人に支払いを承認するようにホストに要求することと、を含む、方法。

２．モバイルデバイスの場所を含む場所情報を決定することをさらに含み、場所が、承認された場所と比較され、ユーザからのセキュリティコードに対する要求を動作させること、または取引の不正リスクを識別することの少なくとも１つのために使用される、付記１に記載の方法。

３．呈示することは、商人の名前と、支払いと関連付けられる取引に含まれる品目またはサービスの説明とを呈示することをさらに含む、付記１に記載の方法。

４．商人に提供された銀行カードの代用として電子支払い方式の選択をユーザから受信することであって、電子支払い方式が、商人への支払いを成立させることをさらに含み、応答を送信することは、電子支払い方式をホストに送信することを含む、付記１に記載の方法。

５．商人への支払いを成立させる銀行カードを含むかまたは除く追加の電子支払い方式のうちの１つ以上の選択をユーザから受信することをさらに含み、応答を送信することは、追加の電子支払い方式をホストに送信することを含む、付記１に記載の方法。

６．１つ以上のプロセッサで実行されるときに、
ホストからモバイルデバイスを介して、商人への支払いの提示から生じる支払いを承認する要求を、該要求を受信するために使用される銀行カードの処理経路とは異なる通信経路を使用して受信することと、
モバイルデバイスのユーザに少なくとも支払額を含む要求の説明を呈示することと、
ユーザから、要求に対する応答を受信することであって、応答が、要求の少なくとも承諾または拒絶を含むことと、
要求に対する回答として応答をホストに送信することであって、回答が、支払いの提示から生じる商人への支払いを承認することまたは拒絶することであることと、を含む行為を行うコンピュータ実行可能命令を記憶する、１つ以上のコンピュータ可読記憶媒体。

７．要求は、少なくとも部分的に商人または支払額に基づいて選択される一意の識別子に対する要求を含み、一意の識別子が、支払いを承諾するためにユーザによって正確に入力されるべきコードを含む、付記６に記載の１つ以上のコンピュータ可読媒体。

８．行為は、
モバイルデバイスの場所を決定することと、
モバイルデバイスの場所をホストに送信することと、をさらに含み、要求は、商人の場所に対するモバイルデバイスの場所に少なくとも部分的に基づく、付記６に記載の１つ以上のコンピュータ可読媒体。

９．モバイルデバイスの場所を決定することは、全地球測位システム（ＧＰＳ）または三角測量を使用して行われる、付記８に記載の１つ以上のコンピュータ可読媒体。

１０．呈示することは、支払いと関連付けられる取引に含まれる商人の識別子および品目またはサービスの説明を呈示することをさらに含む、付記６に記載の１つ以上のコンピュータ可読媒体。

１１．要求は、第２の要求であり、行為は、第２の要求の前に第１の要求を受信することをさらに含み、モバイルデバイスが、閾値時間量より前に第１の要求に応答せず、第２の要求の受信の前に支払いの穏やかな拒否をもたらす、付記６に記載の１つ以上のコンピュータ可読媒体。

１２．行為は、支払いを成立させるように選択のための追加の電子支払い方式をユーザに呈示することさらに含む、付記６に記載の１つ以上のコンピュータ可読媒体。

１３．追加の電子支払い方式のうちの１つが、電子支払い方式と関連付けられる報酬を得るために、少なくとも部分的にそれぞれの電子支払い方式を商人と関連付ける規則に基づきユーザに対して予め選択される、付記１２に記載の１つ以上のコンピュータ可読媒体。

１４．行為は、購入に対する応答を満たすように追加の電子支払い方式の選択をユーザから受信することをさらに含み、応答を送信することは、追加の電子支払い方式をホストに送信することを含む、付記６に記載の１つ以上のコンピュータ可読媒体。

１５．支払いの提示は、最初の電子支払い方式と関連付けられ、行為は、処理されるときに、商人への支払いを集合的に成立させるそれぞれの電子支払い方式の資金の配分を受信することをさらに含む、付記１４に記載の１つ以上のコンピュータ可読媒体。

１６．行為は、支払いの提示と関連付けられた電子支払い方式の代わりに、異なる電子支払い方式の選択をユーザから受信することをさらに含み、異なる電子支払い方式が、商人への支払いを成立させる、付記６に記載の１つ以上のコンピュータ可読媒体。

１７．支払いの提示は、最初の電子支払い方式と関連付けられ、行為は、商人への支払いを成立させる最初の電子支払い方式を含むかまたは除く追加の電子支払い方式を選択することをさらに含む、付記６に記載の１つ以上のコンピュータ可読媒体。

１８．
実行可能命令を有するモバイルデバイスの制御下で、モバイルデバイスで、ユーザから商人に提供される電子支払いを承認する要求を受信することであって、電子支払いが、要求を受信するために使用される銀行カードの処理経路とは異なる通信経路を使用して商人に提供されることと、
ユーザから、要求に対する応答を受信することであって、応答が、要求の少なくとも承諾または拒絶を含むことと、
要求に対する回答として応答をホストに送信することであって、回答が、支払いの提示から生じる商人への支払いを承認することまたは拒絶することであることと、を含む、方法。

１９．モバイルデバイスのユーザに少なくとも支払額および商人の表示を含む要求の説明を呈示することをさらに含む、付記１８に記載の方法。

２０．要求は、支払いを承諾するためにユーザによって正確に入力されるべきセキュリティコードに対する要求を含む、付記１８に記載の方法。

２１．
実行可能命令を有する１つ以上のサーバの制御下で、商人からの支払いを承認する要求を受信することであって、支払いが、銀行カードを使用し、かつ取引の成立でユーザによって商人に提供され、要求が、少なくとも支払い識別子および金額を含むことと、
支払い識別子と関連付けられたユーザのモバイルデバイスを識別することと、
少なくとも部分的に金額に基づきユーザに課す承認要件を決定することと、
承認要件を含む承認メッセージをモバイルデバイスに送信することであって、承認メッセージが、ユーザが支払いを承認する要求を承諾するかまたは拒絶することを可能にすることと、
少なくとも部分的に承認メッセージの送信に基づき、モバイルデバイスを介してユーザからのユーザ応答を受信することであって、応答が、商人に支払いを送信するために使用されるアプリケーションとは異なる支払いアプリケーションとの通信から受信されることと、
少なくとも部分的にユーザ応答に基づき、承認要件が満たされるかどうかを決定することと、
商人への支払いの承諾または拒絶のうちの１つを含む応答を商人に送信することであって、承諾が、承認要件の達成に左右されることと、
ユーザの代理として支払額を商人のアカウントに転送することと、を含む、方法。

２２．承認メッセージは、承認要件を満たす個人識別番号（ＰＩＮ）または生体データのうちの少なくとも１つに対する要求を含む、付記２１に記載の方法。

２３．ユーザ応答は、支払い識別子を有する銀行カード以外の電子支払い方式の選択を含み、電子支払い方式が、取引のために商人に支払われるべき金額の少なくとも一部分を満たすために使用される、付記２１に記載の方法。

２４．承認要件を決定する少なくとも１つの規則を適用することをさらに含む、付記２１に記載の方法。

２５．少なくとも１つの規則は、少なくとも部分的にユーザからの入力に基づいて生成される、付記２４に記載の方法。

２６．
実行可能命令を有する１つ以上のサーバの制御下で、
商人からの支払いを承認する要求を受信することであって、支払いが、ユーザによって取引の成立で商人に提供され、要求が、少なくとも支払い識別子および金額を含むことと、
支払い識別子と関連付けられたユーザのモバイルデバイスを識別することと、
少なくとも部分的に金額に基づきユーザに課す承認要件を決定することと、
承認要件を含む承認メッセージをモバイルデバイスに送信することであって、承認メッセージが、ユーザが支払いを承認する要求を承諾するかまたは拒絶することを可能にすることと、
少なくとも部分的に承認メッセージの送信に基づき、モバイルデバイスを介してユーザからのユーザ応答を受信することと、
少なくとも部分的にユーザ応答に基づき、承認要件が満たされるかどうかを決定することと、
商人に、
承認要件が満たされ、ユーザが支払いを承認する要求を承諾するときに、商人への支払いの承諾、
または商人への支払いの拒絶のうちの１つを含む応答を送信することと、を含む、方法。

２７．ユーザの代理として支払額を商人のアカウントに転送することをさらに含む、付記２６に記載の方法。

２８．ユーザから応答を受信することは、商人に支払いを送信するために使用されるアプリケーションとは異なる支払いアプリケーションと通信して行われる、付記２６に記載の方法。

２９．ユーザ要求は、承認要件を満たすための個人識別番号（ＰＩＮ）または生体データのうちの少なくとも１つを含む、付記２６に記載の方法。

３０．承認要件を決定する少なくとも１つの規則を生成することをさらに含み、少なくとも１つの規則が、少なくとも部分的にユーザからのユーザ入力に基づいて生成される、付記２６に記載の方法。

３１．規則は、指定された期間の閾値支払額と関連するホワイトリストに掲載かまたはブラックリストに掲載の商人、カテゴリ、または分野のうちの少なくとも１つを含む、付記３０に記載の方法。

３２．
ユーザのモバイルデバイスの場所を要求することと、
モバイルデバイスの場所を受信することと、をさらに含み、
場所情報は、商人への支払いと関連付けられる承認要件または不正リスクを決定するために使用される、付記２６に記載の方法。

３３．ユーザ応答は、支払い識別子を有する支払い方式以外の電子支払い方式の選択を含み、電子支払い方式が、取引のために商人に支払われるべき金額の少なくとも一部分を満たすために使用される、付記２６に記載の方法。

３４．承認メッセージは、第２の承認メッセージであり、行為は、
第２の承認メッセージより前に第１の承認メッセージをユーザに送信することと、
第２の承認メッセージをユーザに送信するより前に、支払いを少なくとも一時的に拒絶する穏やかな拒否通知を商人に送信することと、をさらに含む、付記２６に記載の方法。

３５．
ユーザが、少なくとも部分的に所定の規則に基づき、現在の時間に承認メッセージを受信することができないかどうかを決定することと、
ユーザが、少なくとも部分的に所定の規則に基づき、現在の時間に承認メッセージを受信することができないときに、ユーザへの承認メッセージの送信を遅延させることと、をさらに含む、付記２６に記載の方法。

３６．１つ以上のプロセッサで実行されるときに、
商人からの支払いを承認する要求を受信することであって、要求が、少なくとも支払い識別子および金額を含むことと、
支払い識別子と関連付けられるユーザを識別することと、
少なくとも部分的に金額に基づきユーザに課す承認要件を決定することと、
承認メッセージをユーザに送信することであって、承認メッセージが、少なくとも金額を含み、承認要件が、ユーザが支払いを承認する要求を承諾するかまたは拒絶することを可能にすることと、
少なくとも部分的に承認メッセージの送信に基づき、モバイルデバイスを介してユーザからのユーザ応答を受信することと、
少なくとも部分的にユーザ応答に基づき、承認要件が満たされるかどうかを決定することと、
商人への支払いの承諾または拒絶のうちの１つを含む応答を商人に送信することであって、承諾が、承認要件の達成に左右されることと、を含む行為を行うコンピュータ実行可能命令を記憶する、１つ以上のコンピュータ可読記憶媒体。

３７．承認メッセージは、第２の承認メッセージであり、行為は、
第２の承認メッセージより前に第１の承認メッセージをユーザに送信することと、
第２の承認メッセージをユーザに送信するより前に、支払いを少なくとも一時的に拒絶する穏やかな拒否通知を商人に送信することと、をさらに含む、付記３６に記載の１つ以上のコンピュータ可読媒体。

３８．行為は、
ユーザが、少なくとも部分的に所定の規則に基づき、現在の時間に承認メッセージを受信することができないかどうかを決定することと、
ユーザが、少なくとも部分的に所定の規則に基づき、現在の時間に承認メッセージを受信することができないときに、ユーザへの承認メッセージの送信を遅延させることと、をさらに含む、付記３６に記載の１つ以上のコンピュータ可読媒体。

３９．ユーザ応答は、支払い識別子と関連付けられた初期の電子支払い方式とは異なる第２の電子支払い方式の選択を含み、行為は、第２の電子支払い方式を使用して商人への支払いを行うことをさらに含む、付記３６に記載の１つ以上のコンピュータ可読媒体。

４０．承認要件は、少なくとも部分的に支払額および商人に基づき認証プロセスを選択する規則に基づき、認証プロセスのうちの少なくとも１つの選択は、ユーザ応答で個人識別番号（ＰＩＮ）を提供するようにユーザに要求することを含む、付記３６に記載の１つ以上のコンピュータ可読媒体。

結論
主題が構造的特徴および／または方法論的行為に特有の言葉で記載されたが、添付の特許請求の範囲に定義される主題は、必ずしも記載された特定の特徴または行為に限定されないことが理解されるべきである。むしろ、特定の特徴および行為は、特許請求の範囲を実践する例示的な形態として開示される。

Claims (15)

1. コンピュータ実行可能命令を記憶する１つまたは複数のコンピュータ可読記憶媒体であって、前記コンピュータ実行可能命令は、１つまたは複数のプロセッサにより実行されると、前記プロセッサに、
   ホストからモバイルデバイスを介して、商人への支払いを承認するための要求を、受信することと、
   前記モバイルデバイスのユーザに少なくとも前記支払いの額を含む前記要求の詳細を提示することであって、前記要求の詳細は、支払い承認コードのプロンプトとともに提示され、前記支払い承認コードは、少なくとも部分的には前記商人の識別子または前記商人のカテゴリに基づいて複数の支払い承認コードから予め選択される、提示することと、
   前記ユーザから、前記要求への応答を受信することであって、前記応答が、少なくとも部分的に前記支払い承認コードの正しい入力に基づいて前記要求の承諾を示す、受信することと、
   前記要求に対する回答として前記応答を前記ホストに送信することであって、前記回答が、前記商人への前記支払いを承認することである、送信することと、
   前記モバイルデバイスの場所を前記ホストに送信することであって、前記ホストは、前記モバイルデバイスの前記場所に基づいて、前記応答を調節する、送信することと
   を含む行為を行わせることを特徴とする１つ以上のコンピュータ可読記憶媒体。
2. 前記要求は、第２の要求であり、前記行為は、前記第２の要求より前に第１の要求を受信することをさらに含み、前記モバイルデバイスが、閾値の時間より前に前記第１の要求に応答せず、前記第２の要求の前記受信より前に前記支払いの穏やかな拒否をもたらす、請求項１に記載の１つ以上のコンピュータ可読記憶媒体。
3. 前記行為は、前記要求に対する前記応答を満たすように追加の電子支払い方式の選択を前記ユーザから受信することをさらに含み、前記応答を送信することは、前記追加の電子支払い方式を前記ホストに送信することを含む、請求項１に記載の１つ以上のコンピュータ可読記憶媒体。
4. 前記支払いの提示は、最初の電子支払い方式と関連付けられ、前記行為は、処理される場合に、前記商人への前記支払いを集合的に成立させる前記それぞれの電子支払い方式の資金の配分を受信することをさらに含む、請求項３に記載の１つ以上のコンピュータ可読記憶媒体。
5. 前記行為は、前記支払いの提示と関連付けられた電子支払い方式の代わりに、異なる電子支払い方式の選択を前記ユーザから受信することをさらに含み、前記異なる電子支払い方式が、前記商人への前記支払いを成立させる、請求項１に記載の１つ以上のコンピュータ可読記憶媒体。
6. 実行可能命令を有する１つ以上のサーバの制御下において、
   商人から、支払いを承認する要求を受信するステップであって、前記支払いが、ユーザによって取引の成立で前記商人に提供され、前記要求が、少なくとも支払い識別子および金額を含む、ステップと、
   予め定められた規則に基づいて、前記要求に対して承諾または拒否を含む応答を送信するかどうかを決定するステップと、
   予め定められた規則に基づいて、前記要求に対して承諾または拒否を含む応答を送信することを決定した場合に、決定された前記承諾または前記拒否を含む応答を送信するステップと、
   前記支払い識別子と関連付けられた前記ユーザのモバイルデバイスを識別するステップと、
   少なくとも部分的に前記金額に基づき前記ユーザに課す承認要件を決定するステップと、
   前記承認要件を含む承認メッセージを前記モバイルデバイスに送信するステップであって、前記承認メッセージが、前記ユーザが前記支払いを承認する前記要求を承諾することを可能にし、前記承認メッセージは、前記ユーザの前記モバイルデバイスにおいて支払い承認コードのプロンプトとともに提示される前記要求の詳細を含み、前記支払い承認コードは、少なくとも部分的には前記商人の識別子または前記商人のカテゴリに基づいて複数の支払い承認コードから予め選択される、ステップと、
   少なくとも部分的に前記承認メッセージの前記送信に基づき、前記モバイルデバイスを介して前記ユーザからのユーザ応答を受信するステップであって、前記ユーザ応答が、少なくとも部分的に前記支払い承認コードの正しい入力に基づいて前記要求の承諾を示す、ステップと、
   少なくとも部分的に前記ユーザ応答に基づき、前記承認要件が満たされるかどうかを決定するステップと、
   前記商人に、前記承認要件が満たされ、前記ユーザが前記支払いを承認する前記要求を承諾する場合に、前記商人への前記支払いの承諾を含む応答を送信するステップと、
   を備えたことを特徴とする方法。
7. 前記ユーザから前記応答を受信することは、前記商人に前記支払いを送信するために使用されるアプリケーションとは異なる支払いアプリケーションと通信して行われることを特徴とする請求項６に記載の方法。
8. 前記ユーザ応答は、前記承認要件を満たすための個人識別番号（ＰＩＮ）または生体データのうちの少なくとも１つを含むことを特徴とする請求項６に記載の方法。
9. 前記承認要件を決定する少なくとも１つの規則を生成するステップをさらに備え、前記少なくとも１つの規則が、少なくとも部分的に前記ユーザからのユーザ入力に基づいて生成されることを特徴とする請求項６に記載の方法。
10. 前記ユーザの前記モバイルデバイスの場所を要求するステップと、
    前記モバイルデバイスの前記場所を受信するステップと
    をさらに備え、前記場所は、前記商人への前記支払いと関連付けられる前記承認要件または不正リスクを決定するために使用されることを特徴とする請求項６に記載の方法。
11. 前記ユーザ応答は、前記支払い識別子を有する支払い方式以外の電子支払い方式の選択を含み、前記電子支払い方式が、前記取引のために前記商人に支払われるべき前記金額の少なくとも一部分を満たすために使用されることを特徴とする請求項６に記載の方法。
12. 前記承認メッセージは、第２の承認メッセージであり、前記方法は、
    前記第２の承認メッセージより前に第１の承認メッセージを前記ユーザに送信するステップと、
    前記第２の承認メッセージを前記ユーザに送信する前に、前記支払いを少なくとも一時的に拒絶する穏やかな拒否通知を前記商人に送信するステップと
    をさらに備えたことを特徴とする請求項６に記載の方法。
13. 前記ユーザが、少なくとも部分的に予め定められた規則に基づき、現在の時間に前記承認メッセージを受信することができないかどうかを決定するステップと、
    前記ユーザが、少なくとも部分的に前記予め定められた規則に基づき、前記現在の時間に前記承認メッセージを受信することができない場合に、前記ユーザへの前記承認メッセージの送信を遅延させるステップを
    さらに備えたことを特徴とする請求項６に記載の方法。
14. 請求項６から１３のいずれか一項に記載の方法を実行するためのコンピュータ実行可能命令を備えたことを特徴とするコンピュータ可読記憶媒体。
15. 請求項６から１３のいずれか一項に記載の方法を実行するように構成されたことを特徴とするシステム。