JP6254204B2 - Payment selection and approval by mobile devices - Google Patents

Payment selection and approval by mobile devices Download PDF

Info

Publication number
JP6254204B2
JP6254204B2 JP2016037781A JP2016037781A JP6254204B2 JP 6254204 B2 JP6254204 B2 JP 6254204B2 JP 2016037781 A JP2016037781 A JP 2016037781A JP 2016037781 A JP2016037781 A JP 2016037781A JP 6254204 B2 JP6254204 B2 JP 6254204B2
Authority
JP
Japan
Prior art keywords
payment
user
request
merchant
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016037781A
Other languages
Japanese (ja)
Other versions
JP2016131033A (en
Inventor
ハンソン ロバート
ハンソン ロバート
エル.シーリー ブラッド
エル.シーリー ブラッド
Original Assignee
アマゾン テクノロジーズ インコーポレイテッド
アマゾン テクノロジーズ インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US13/170,121 priority Critical
Priority to US13/170,121 priority patent/US10055740B2/en
Priority to US13/170,144 priority patent/US20120330788A1/en
Priority to US13/170,144 priority
Application filed by アマゾン テクノロジーズ インコーポレイテッド, アマゾン テクノロジーズ インコーポレイテッド filed Critical アマゾン テクノロジーズ インコーポレイテッド
Publication of JP2016131033A publication Critical patent/JP2016131033A/en
Application granted granted Critical
Publication of JP6254204B2 publication Critical patent/JP6254204B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4012Verifying personal identification numbers [PIN]
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • G06Q20/40145Biometric identity checks
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Description

多くの商人は、顧客がクレジットカード、デビットカード、および他の種類の銀行カードまたは電子口座(例えば、ギフトカードなど)で支払うことを可能にしている。顧客がこれらの種類の支払い方式を使用し、支払い要求を満たすとき、商人は通常、検証プロセスを行う。検証プロセスは、識別子がカードから(例えば、スワイプカードリーダ、無線周波数識別子(RFID)リーダ、マイクロチップリーダなどを介して)読み込まれた後に電子的に生じることが多い。検証プロセスはしばしば、カードの発行者または発行者の代理人と連絡を取り、要求された購入要求の金額を承認するかどうかを決定する。   Many merchants allow customers to pay with credit cards, debit cards, and other types of bank cards or electronic accounts (eg, gift cards). When a customer uses these types of payment methods and satisfies a payment request, the merchant typically performs a verification process. The verification process often occurs electronically after the identifier is read from the card (eg, via a swipe card reader, a radio frequency identifier (RFID) reader, a microchip reader, etc.). The verification process often contacts the card issuer or the issuer's agent to determine whether to approve the requested purchase amount.

いくつかの支払い方式は、支払い方式の無承認の使用から保護するために個人識別番号(PIN)または他の暗号を使用する。例えば、販売時点情報管理システム(POS)で、ユーザがスワイプカードリーダを使用してユーザのデビットカードをスワイプし、次いでカードリーダのキーボードに関連したPINを入力してもよい。カードリーダおよびキーボードは通常むきだしで、店員を含む他の人々に見え、したがってPINの秘密性を危険にさらす可能性がある。現金自動預け払い機などの一部の場合では、キーボードは、他のユーザによってキーボードの視界を阻むかまたは制限するためのフードによって少なくとも部分的に覆われている。   Some payment schemes use a personal identification number (PIN) or other encryption to protect against unauthorized use of the payment scheme. For example, in a point-of-sale information management system (POS), a user may use a swipe card reader to swipe the user's debit card and then enter a PIN associated with the card reader's keyboard. Card readers and keyboards are usually bare and visible to other people, including store clerk, and can therefore jeopardize the confidentiality of the PIN. In some cases, such as an automated teller machine, the keyboard is at least partially covered by a hood to block or limit keyboard visibility by other users.

人々は、一群のクレジットカード、デビットカード、ギフトカード、および他のカードまたは支払い方式などの、複数の支払い方式を有することが多い。財布の中に複数のカードを入れて持ち歩くのは不便であり得る。加えて、複数のカードを持ち歩くことは同時に、一群のカードが紛失されるか、置き忘れられるか、または盗まれる場合、個人を大きなリスクおよび/または不便にさらす。   People often have multiple payment methods, such as a group of credit cards, debit cards, gift cards, and other cards or payment methods. It can be inconvenient to carry multiple cards in your wallet. In addition, carrying multiple cards at the same time exposes individuals to great risk and / or inconvenience if a group of cards is lost, misplaced, or stolen.

本PCT出願は、2011年6月27日に出願された「Payment Selection and Authorization by a Mobile Device」と題する米国特許出願第13/170,144号に対する優先権を主張する。米国特許出願第13/170,144号は、この参照によりその全体が本明細書に組み込まれる。   This PCT application claims priority to US Patent Application No. 13 / 170,144, filed June 27, 2011, entitled “Payment Selection and Authorization by a Mobile Device”. US patent application Ser. No. 13 / 170,144 is hereby incorporated by reference in its entirety.

本PCT出願は、2011年6月27日に出願された「Payment Selection and Authorization」と題する米国特許出願第13/170,121号に対する優先権を主張する。米国特許出願第13/170,121号は、この参照によりその全体が本明細書に組み込まれる。   This PCT application claims priority to US Patent Application No. 13 / 170,121, filed June 27, 2011, entitled “Payment Selection and Authorization”. US patent application Ser. No. 13 / 170,121 is hereby incorporated by reference in its entirety.

詳細な説明が、添付の図を参照しながら記載される。図中、参照番号の一番左の桁(複数)は、参照番号が最初に現れる図を識別する。異なる図の同じ参照番号は、類似または同一の品目を示す。
モバイル決済の選択および承認を提供する例示的なコンピューティング環境の概略図である。 図1のコンピューティング環境に含まれる様々な構成要素の例示的なコンピューティングアーキテクチャのブロック図である。 図1のコンピューティング環境に含まれる様々な構成要素の例示的なコンピューティングアーキテクチャのブロック図である。 図1のコンピューティング環境に含まれる様々な構成要素の例示的なコンピューティングアーキテクチャのブロック図である。 モバイルデバイスアプリケーションで支払いを承認する例示的なプロセスのフロー図である。 図1に示されるコンピューティング環境から様々な関係者間の相互作用を示す例示的なプロセスのフロー図である。 支払い承認の間に電子支払い方式を選択する例示的なプロセスのフロー図である。 支払い要求の穏やかな拒否を開始する例示的なプロセスのフロー図である。 モバイルデバイスアプリケーションによる使用の承認方式を選択する例示的なプロセスのフロー図である。 支払い選択および承認を可能にする例示的なユーザインターフェース(UI)である。 ホストからの承認メッセージの管理を可能にする例示的なUIである。
The detailed description is described with reference to the accompanying figures. In the figure, the leftmost digit (s) of a reference number identifies the figure in which the reference number first appears. The same reference numbers in different figures indicate similar or identical items.
1 is a schematic diagram of an exemplary computing environment that provides mobile payment selection and authorization. FIG. FIG. 2 is a block diagram of an exemplary computing architecture of various components included in the computing environment of FIG. FIG. 2 is a block diagram of an exemplary computing architecture of various components included in the computing environment of FIG. FIG. 2 is a block diagram of an exemplary computing architecture of various components included in the computing environment of FIG. FIG. 4 is a flow diagram of an example process for authorizing payments in a mobile device application. FIG. 2 is an exemplary process flow diagram illustrating the interaction between various parties from the computing environment shown in FIG. FIG. 5 is a flow diagram of an exemplary process for selecting an electronic payment method during payment authorization. FIG. 6 is a flow diagram of an exemplary process for initiating a gentle rejection of a payment request. FIG. 5 is a flow diagram of an example process for selecting an approval scheme for use by a mobile device application. 2 is an exemplary user interface (UI) that enables payment selection and approval. FIG. 4 is an exemplary UI that enables management of acknowledgment messages from hosts. FIG.

本開示は、クレジットカード、デビットカード、ギフトカード、または他の種類の電子支払いなどの電子支払い方式を使用するときに、安全性、秘匿性、および利便性を高める技法およびシステムを提供する。電子支払い方式で支払いを行うときに、ユーザは、ユーザのモバイルコンピューティングデバイス(例えば、携帯電話、タブレットコンピュータなど)との通信を通じて持ち主であることの追加の検証を提供することができる。例えば、ユーザは、小売商人の小売店で(直接またはオンラインで)ユーザのクレジットカードを挿入するかまたはスワイプしてもよい。次に、小売商人は、カードが有効であるか、十分な資金を有するか、および/または他の理由かどうかを検証するゲートウェイを通じてクレジットカード情報を処理してもよい。ゲートウェイは、発行者(「ホスト」)への要求を転送してもよい。様々な実施形態によれば、ホストは、モバイルコンピューティングデバイスで動作するモバイルアプリケーションを介してユーザに要求を送信してもよく、ユーザに購入要求を承認するかまたは拒否するのを求めてもよい。様々な実施形態では、ホストの要求は、要求を承認するモバイルアプリケーションを介してユーザに個人および/または認証情報(例えば、PIN、パスワード、生体認証など)を入力するのを求めてもよい。   The present disclosure provides techniques and systems that increase safety, confidentiality, and convenience when using electronic payment schemes such as credit cards, debit cards, gift cards, or other types of electronic payments. When making a payment with an electronic payment method, the user can provide additional verification of ownership through communication with the user's mobile computing device (eg, cell phone, tablet computer, etc.). For example, the user may insert or swipe the user's credit card at the retailer's retail store (directly or online). The merchant may then process the credit card information through a gateway that verifies whether the card is valid, has sufficient funds, and / or for other reasons. The gateway may forward the request to the issuer (“host”). According to various embodiments, the host may send a request to the user via a mobile application running on the mobile computing device and may ask the user to approve or reject the purchase request. . In various embodiments, the host request may require the user to enter personal and / or authentication information (eg, PIN, password, biometric, etc.) via a mobile application that approves the request.

いくつかの実施形態では、ホストは、ユーザの一群の電子支払い方式を管理してもよい。ホストは、ユーザが承認プロセスの間、モバイルアプリケーションを介してホストからユーザに利用可能な様々な電子支払い方式にわたって支払額を分割するかまたは配分することを可能にしてもよい。例えば、ユーザは、ホストから要求を受信し、商人に最初に提供されるカードとは異なるカードを選択し、次いで支払い要求を承諾してもよい。商人の観点からすれば、支払いは、商人によって受信され、かつこのプロセスを開始された支払い方式を使用して処理されてもよい。しかしながら、ホストは、モバイルアプリケーションを介してユーザによって選択される支払い方式(複数)を使用して実際の支払いを商人に提供してもよい。   In some embodiments, the host may manage a group of users' electronic payment schemes. The host may allow the user to divide or distribute payment amounts across various electronic payment schemes available to the user from the host via the mobile application during the approval process. For example, the user may receive a request from the host, select a card that is different from the card originally provided to the merchant, and then accept the payment request. From the merchant's point of view, payments may be processed using the payment method received by the merchant and initiated this process. However, the host may provide the actual payment to the merchant using the payment method (s) selected by the user via the mobile application.

本明細書に記載される技法およびシステムは、多くの様式で実践されてもよい。以下の図を参照しながら実例の実践が以下に提供される。   The techniques and systems described herein may be practiced in many ways. Illustrative practices are provided below with reference to the following figures.

図1は、モバイル決済の選択および承認を提供する例示的なコンピューティング環境100の概略図である。環境100は、商人104と相互作用するユーザ102を含む。商人104は、従来型実店舗の場所および/または1つ以上のネットワーク(複数)106を介してユーザ102にアクセス可能である電子市場を有してもよい。例えば、電子市場は、ユーザ102が商品および/またはサービスを購入することを可能にするウェブサイトであってもよく、あるいは販売され、貸し出され、賃借され、そうでなければまたは別の様式で商人104から入手可能となる品目をユーザが閲覧することを可能にするカタログによるサービスであってもよい。   FIG. 1 is a schematic diagram of an exemplary computing environment 100 that provides for mobile payment selection and authorization. The environment 100 includes a user 102 that interacts with a merchant 104. The merchant 104 may have a conventional physical store location and / or an electronic market that is accessible to the user 102 via one or more network (s) 106. For example, the electronic marketplace may be a website that allows the user 102 to purchase goods and / or services, or sold, rented, rented, otherwise or otherwise merchant It may be a catalog service that allows a user to browse items that are available from 104.

商人104は、電子支払い方式(EPT)108を使用してユーザ102からの支払いを承諾してもよく、他の支払い方式(例えば、現金、個人小切手、為替など)も承諾してもよい。EPT108は、クレジットカードおよびデビットカード、ならびにギフトカード、ストアドバリューカード、または任意の他の種類の電子支払いなどの銀行カードを含み得る支払い方法である。EPT108は、モバイルコンピューティングデバイス110(「ユーザデバイス」)を使用してユーザ102がEPT108の使用を承認することを可能にする後述される一連の事象を通じて処理されてもよい。ユーザデバイス110は、ネットワーク(複数)106への接続性を含み、かつユーザ入力を可能にする、携帯電話、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、ネットブック、携帯情報端末(PDA)、ゲーミングデバイス、メディアプレーヤ、または任意の他のモバイルコンピューティングデバイスであってもよい。   The merchant 104 may approve payments from the user 102 using an electronic payment method (EPT) 108 and may accept other payment methods (eg, cash, personal checks, money orders, etc.). EPT 108 is a payment method that may include credit and debit cards and bank cards such as gift cards, stored value cards, or any other type of electronic payment. The EPT 108 may be processed through a series of events described below that allow the user 102 to authorize the use of the EPT 108 using the mobile computing device 110 (“user device”). User device 110 includes connectivity to network (s) 106 and allows user input, mobile phone, smartphone, tablet computer, laptop computer, netbook, personal digital assistant (PDA), gaming device, It may be a media player or any other mobile computing device.

商人104の販売時点情報管理システム(POS)112および/または商人サーバ114を介してユーザ102からEPT108を受信した後、商人は、承認に対する要求116をゲートウェイ118に送信してもよい。ゲートウェイ118は、商人104の代理の金融機関および/または経路指定の関係者であってもよく、それは、EPT108をユーザ102に発行したか、および/またはユーザに対してEPT108のアカウントを管理する関係者であるホスト120へ商人からの要求116の経路指定をする。   After receiving the EPT 108 from the user 102 via the point of sale information management system (POS) 112 and / or the merchant server 114 of the merchant 104, the merchant may send a request 116 for approval to the gateway 118. The gateway 118 may be a financial institution on behalf of the merchant 104 and / or a routing party that issued the EPT 108 to the user 102 and / or a relationship that manages the EPT 108 account for the user. The request 116 from the merchant is routed to the host 120, who is the seller.

1つ以上の実施形態によれば、ホスト120は、要求116を受信し、要求を処理し、次いで修正された要求124をユーザ102と関連付けられるユーザデバイス110に送信し得るホストサーバ122を含む。処理の間、ホストサーバ122は、ホスト120によって維持されるアカウントデータ126からEPT108に関する情報を取り出してもよい。アカウントデータ126は、修正された要求124を生成するための規則、ユーザ102のための選択肢、ユーザに利用可能な電子支払い方式、記憶されたユーザ選好、ならびにEPT108および/またはユーザ102に関する他のデータを含んでもよく、修正された要求124を生成するために使用されてもよい。   According to one or more embodiments, the host 120 includes a host server 122 that can receive the request 116, process the request, and then send the modified request 124 to the user device 110 associated with the user 102. During processing, host server 122 may retrieve information regarding EPT 108 from account data 126 maintained by host 120. Account data 126 includes rules for generating modified request 124, options for user 102, electronic payment methods available to the user, stored user preferences, and other data related to EPT 108 and / or user 102. And may be used to generate a modified request 124.

ユーザデバイス110は、通常、商人104がEPT108の識別子を受信した直後に修正された要求124を受信してもよい。修正された要求は、EPT108を商人104に送信するために使用される通信経路とは異なる通信経路を使用してユーザデバイス110によって受信されてもよい。修正された要求124は、ユーザデバイス110で動作する支払いアプリケーションによって処理されてもよく、そのデバイスは、ユーザインターフェース128を使用して他の可能な選択肢の中からユーザ102が情報を受信し、かつ修正された要求124を承諾するかまたは拒否することを可能にする。支払いアプリケーションは、再びEPT108を商人104に送信するために使用される通信経路とは異なる通信経路を使用してホストサーバ122に戻すように送信される拡張された回答130(すなわち、応答)を生成してもよい。拡張された回答130は、承諾、特殊コード(例えば、個人識別番号(PIN)、パスワード、または他の個人情報)、および場合により指定された電子支払い方式に関連した選択(例えば、EPTが修正された要求124を満たすために使用する選択)を含む。ホスト120は、PINが正しく、かつユーザが要求116を承諾するかどうかを検証するなど、拡張された回答130の情報を検証してもよい。次に、ホストサーバ122は、回答132をゲートウェイ118に送信してもよく、その回答は、比較的短い時間量後に商人サーバ114および/または商人104のPOSシステム112に転送されてもよい。拡張された回答130と違って、回答132は、より少ない情報を含み、ホスト120に向けられる特殊コードまたは他の情報を含むのではなく支払い要求116の承諾または拒否に主に関連してもよい。   The user device 110 may typically receive a modified request 124 immediately after the merchant 104 receives the identifier of the EPT 108. The modified request may be received by user device 110 using a communication path that is different from the communication path used to send EPT 108 to merchant 104. The modified request 124 may be processed by a payment application running on the user device 110, which uses the user interface 128 to allow the user 102 to receive information from among other possible options, and Allows the modified request 124 to be accepted or rejected. The payment application generates an extended answer 130 (ie, a response) that is sent back to the host server 122 using a different communication path than that used to send the EPT 108 to the merchant 104 again. May be. The expanded answer 130 may include acceptance, special codes (eg, personal identification number (PIN), password, or other personal information), and options related to the electronic payment method specified (eg, EPT modified). Selection to be used to satisfy request 124). The host 120 may verify the extended answer 130 information, such as verifying whether the PIN is correct and the user accepts the request 116. The host server 122 may then send the answer 132 to the gateway 118, which may be forwarded to the merchant server 114 and / or the POS system 112 of the merchant 104 after a relatively short amount of time. Unlike the extended answer 130, the answer 132 includes less information and may be primarily related to accepting or rejecting the payment request 116 rather than including a special code or other information directed to the host 120. .

ユーザデバイス110と併用してEPTを使用することによって、ユーザ102は、EPTの誤用に対してより大きな安全性を経験することができる。例えば、EPT108(またはEPT108の識別子)が盗まれ、商人104または上述された技法を用いる他の商人から品目を購入するために使用される場合、ユーザ102は、不正購入から保護するために購入要求を単純に拒否することができる。修正された要求がPINまたは他の特殊コードを要求する状況では、ユーザ102は、泥棒(または他の権限のない人物)がユーザデバイス110を保有するときでさえ不正使用に対して保護されることが可能である。加えて、セキュリティコードを入力するユーザデバイス110を使用することによって、ユーザが詐欺(例えば、カードスキミング、偽のPINパッドなど)を受けやすいような現金自動預け払い機と相互作用するときなど、セキュリティコードの盗用がより困難になり得る。   By using EPT in conjunction with user device 110, user 102 can experience greater safety against EPT misuse. For example, if EPT 108 (or an identifier of EPT 108) is stolen and used to purchase items from merchant 104 or other merchants using the techniques described above, user 102 may request purchase to protect against fraudulent purchases. Can simply be rejected. In situations where the modified request requires a PIN or other special code, the user 102 is protected against unauthorized use even when a thief (or other unauthorized person) holds the user device 110. Is possible. In addition, by using the user device 110 to enter a security code, such as when interacting with an automated teller machine where the user is susceptible to fraud (eg, card skimming, fake PIN pads, etc.) Code theft can be more difficult.

いくつかの実施形態では、商人104は、ホスト120と直接通信してもよく、かつ/あるいはホスト120が、ゲートウェイ118の一部またはすべての操作を行ってもよい。したがって、いくつかの実施形態では、環境100は、本明細書に記載される技法に影響を与えなければゲートウェイ118を含まなくてもよい。   In some embodiments, the merchant 104 may communicate directly with the host 120 and / or the host 120 may perform some or all operations of the gateway 118. Thus, in some embodiments, environment 100 may not include gateway 118 as long as it does not affect the techniques described herein.

ネットワーク(複数)106は、環境100に記載される様々なコンピューティングデバイス間の高速通信を可能にする有線および/またはワイヤレスネットワークを含んでもよい。いくつかの実施形態では、ネットワーク(複数)は、様々なコンピューティングデバイス(すなわち、商人サーバ114、ホストサーバ122、およびユーザデバイス110)間の通信を容易にするように、場合により互いに併用して使用されるローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、携帯電話ネットワーク(MTN)、および他の種類のネットワークを含んでもよい。コンピューティングデバイスは、以下の図を参照しながらさらに詳細に記載される。   The network (s) 106 may include wired and / or wireless networks that allow high-speed communication between the various computing devices described in the environment 100. In some embodiments, the network (s) are optionally combined with each other to facilitate communication between various computing devices (ie, merchant server 114, host server 122, and user device 110). It may include local area networks (LANs), wide area networks (WANs), cellular phone networks (MTNs), and other types of networks that are used. The computing device is described in further detail with reference to the following figures.

図2a〜2cは、図1のコンピューティング環境に含まれる様々なコンピューティングデバイスの例示的なコンピューティングアーキテクチャを示す。   2a-2c illustrate an exemplary computing architecture for various computing devices included in the computing environment of FIG.

図2aは、商人サーバ114、POSシステム112、または両方の例示的なコンピューティングアーキテクチャを示す。このアーキテクチャは、プロセッサ202およびメモリ204を含んでもよい。メモリ204は、様々なモジュール、アプリケーション、プログラム、または他のデータを記憶してもよい。メモリ204は、プロセッサ202によって実行されるときに、プロセッサに商人104に対して本明細書に記載される操作を行わせる命令を含んでもよい。いくつかの実施形態では、メモリ204は、トランザクションマネージャ206、およびトランザクションマネージャの一部またはトランザクションマネージャとは別個の承認モジュール208を格納してもよい。トランザクションマネージャ206は、ユーザ102との取引を処理し、EPT108を受信してもよい。承認モジュール208は、EPTが回答132によって示されるように承認されるかどうかを決定するように、上述されるようにゲートウェイ118を介してまたは直接ホスト120を通じてEPT108を承認してもよい。いくつかの実施形態では、トランザクションマネージャ206、承認モジュール208、またはそれぞれの部分は、POSシステム112および商人サーバ114などの複数のコンピューティングシステムにわたって分布させられてもよい。   FIG. 2a shows an exemplary computing architecture of merchant server 114, POS system 112, or both. This architecture may include a processor 202 and memory 204. Memory 204 may store various modules, applications, programs, or other data. Memory 204 may include instructions that, when executed by processor 202, cause the processor to perform the operations described herein on merchant 104. In some embodiments, the memory 204 may store a transaction manager 206 and an authorization module 208 that is part of the transaction manager or separate from the transaction manager. Transaction manager 206 may process transactions with user 102 and receive EPT 108. The approval module 208 may approve the EPT 108 via the gateway 118 or directly through the host 120 as described above to determine whether the EPT is approved as indicated by the answer 132. In some embodiments, transaction manager 206, approval module 208, or respective portions may be distributed across multiple computing systems, such as POS system 112 and merchant server 114.

図2bは、ホストサーバ122の例示的なコンピューティングアーキテクチャを示す。このアーキテクチャは、プロセッサ(複数)210およびメモリ212を含んでもよい。メモリ212は、様々なモジュール、アプリケーション、プログラム、または他のデータを記憶してもよい。メモリ212は、プロセッサ(複数)210によって実行されるときに、プロセッサにホスト120に対して本明細書に記載される操作を行わせる命令を含んでもよい。いくつかの実施形態では、メモリ212は、アカウントマネージャ214および承認マネージャ216を格納してもよい。アカウントマネージャ214は、ホスト120とのアカウントを有するそれぞれのユーザに対する様々な規則、設定、EPT、および他のデータを記憶するアカウントデータ126を管理してもよい。承認マネージャ216は、少なくとも部分的にユーザデバイス110とのユーザの相互作用に基づき、支払い要求を承諾するかまたは拒否するかのいずれかであるように、場合によりゲートウェイ118を介して商人104からの通信を処理してもよい。   FIG. 2 b shows an exemplary computing architecture of the host server 122. This architecture may include processor (s) 210 and memory 212. The memory 212 may store various modules, applications, programs, or other data. Memory 212 may include instructions that, when executed by processor (s) 210, cause the processor to perform operations described herein on host 120. In some embodiments, the memory 212 may store an account manager 214 and an authorization manager 216. Account manager 214 may manage account data 126 that stores various rules, settings, EPTs, and other data for each user having an account with host 120. The authorization manager 216 may optionally accept the payment request from the merchant 104 via the gateway 118 to either accept or reject the payment request based at least in part on the user's interaction with the user device 110. Communication may be processed.

図2cは、ユーザデバイス110の例示的なコンピューティングアーキテクチャを示す。このアーキテクチャは、プロセッサ(複数)218およびメモリ220を含んでもよい。メモリ220は、様々なモジュール、アプリケーション、プログラム、または他のデータを記憶してもよい。メモリ220は、プロセッサ(複数)218によって実行されるときに、プロセッサにユーザ102に対して本明細書に記載される操作を行わせる命令を含んでもよい。いくつかの実施形態では、メモリ220は、ホストサーバ122の承認マネージャ216および/またはアカウントマネージャ214と相互作用し得る支払いアプリケーション222を格納してもよい。支払いアプリケーション222は、検証モジュール224、条件モジュール226、および選択モジュール228をさらに含んでもよい。それぞれのモジュールが順に記載される。   FIG. 2 c shows an exemplary computing architecture of user device 110. This architecture may include processor (s) 218 and memory 220. Memory 220 may store various modules, applications, programs, or other data. Memory 220 may include instructions that, when executed by processor (s) 218, cause the processor to perform the operations described herein for user 102. In some embodiments, the memory 220 may store a payment application 222 that may interact with the authorization manager 216 and / or the account manager 214 of the host server 122. The payment application 222 may further include a validation module 224, a condition module 226, and a selection module 228. Each module is listed in turn.

様々な実施形態によれば、検証モジュール224は、ホストサーバ122の承認マネージャ216から受信された修正された要求124に基づき、承認のためのセキュリティコード要求(例えば、UIなど)を生成するかどうかを決定してもよい。ホストサーバ122によって(または場合により支払いアプリケーション222によって)要求されるときに、検証モジュール224は、商人104から生じ、かつホストサーバ122を通って送信された支払い要求を承諾するために、PIN、パスワード、生体データ、または他の個人情報などのセキュリティコードをユーザに入力することを求めてもよい。   According to various embodiments, the validation module 224 determines whether to generate a security code request (eg, UI) for authorization based on the modified request 124 received from the authorization manager 216 of the host server 122. May be determined. When requested by the host server 122 (or possibly by the payment application 222), the verification module 224 may request a PIN, password, to accept a payment request originating from the merchant 104 and transmitted through the host server 122. The user may be asked to enter a security code, such as biometric data or other personal information.

条件モジュール226は、ユーザデバイス110に関する情報を提供し、セキュリティコードの使用に対して条件を適用し、および/または修正された支払い要求124もしくは他の種類の情報に関連する他のものの自動承認もしくは拒絶してもよい。例えば、承認マネージャ216は、ユーザデバイス110の場所を要求してもよく、全地球測位システム(GPS)、三角測量、または他の情報を使用して提供されてもよい。この情報が商人の場所、ユーザ102の既知の場所(例えば、自宅、仕事場など)、または別の指定または学習された場所と一致すると、承認マネージャ216は、支払いを承諾するように(例えば、セキュリティコードの要件を取り除くなど)、ユーザによって必要とされる応答を調節してもよい。   The condition module 226 provides information regarding the user device 110, applies conditions to the use of the security code, and / or automatically approves the payment request 124 or other types of information related to other types of information. You may refuse. For example, the authorization manager 216 may request the location of the user device 110 and may be provided using a global positioning system (GPS), triangulation, or other information. If this information matches the merchant's location, a known location of user 102 (eg, home, workplace, etc.), or another designated or learned location, authorization manager 216 may request payment (eg, security). The response required by the user may be adjusted, such as removing code requirements).

選択モジュール228は、ユーザに利用可能であり、かつアカウントデータ126に記憶される他のEPT間の支払いをユーザ102が選択し、配分することを可能にしてもよい。例えば、アカウントデータ126は、多くの異なる種類のユーザのEPT間の関連性を含んでもよく、EPTのうちのいずれか1つが商人104に呈示されるときにアクセス可能であってもよい。次に、ホストは、選択モジュール228を介して選択されたEPTのうちの1つを使用して商人104によって支払い要求116を満たしてもよい。ユーザ102は、比率、支払額、または他の配分に基づき複数のEPT間の資金を配分してもよい。   The selection module 228 may allow the user 102 to select and distribute payments between other EPTs that are available to the user and stored in the account data 126. For example, account data 126 may include relationships between EPTs of many different types of users and may be accessible when any one of the EPTs is presented to merchant 104. The host may then satisfy the payment request 116 by the merchant 104 using one of the EPTs selected via the selection module 228. User 102 may allocate funds among multiple EPTs based on ratios, payments, or other allocations.

図3は、モバイルデバイスのアプリケーションで支払いを承認する例示的なプロセス300のフロー図である。プロセス300は、ハードウェア、ソフトウェア、またはこれらの組み合わせで実践され得る一連の操作を表す論理的なフローグラフにおける一群のブロックとして示される。このブロックの群は、ブロックに記載される様々な操作を行い得るそれぞれの関係者の下で整理される。ソフトウェアの状況では、ブロックは、1つ以上のプロセッサによって実行されるときに、記載された操作を行う1つ以上のコンピュータ可読記憶媒体に記憶されるコンピュータ実行可能命令を表す。概して、コンピュータ実行可能命令は、特定の機能を行うかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。操作が記載される順は、限定して解釈されるものではなく、記載されたブロックのあらゆる番号は、プロセスを実践するためにあらゆる順および/または並行して組み合わせることができる。プロセス300に加えて、本開示を通して記載される他のプロセスは、それに応じて解釈されるべきであろう。   FIG. 3 is a flow diagram of an example process 300 for authorizing payments at an application on a mobile device. Process 300 is shown as a group of blocks in a logical flow graph that represents a series of operations that may be implemented in hardware, software, or a combination thereof. This group of blocks is organized under each party that can perform the various operations described in the block. In the software context, a block represents computer-executable instructions that are stored in one or more computer-readable storage media that perform the operations described when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not to be construed as limiting, and any number of the described blocks can be combined in any order and / or in parallel to practice the process. In addition to process 300, other processes described throughout this disclosure should be construed accordingly.

プロセス300は、環境100を参照しながら説明され、ホストサーバ122、POSシステム112、および/または商人サーバ114のうちのいずれか1つ以上と協働してユーザデバイス110によって行われてもよい。言うまでもなく、プロセス300(および本明細書に記載される他のプロセス)は、他の類似および/または異なる環境で行われてもよい。   Process 300 is described with reference to environment 100 and may be performed by user device 110 in cooperation with any one or more of host server 122, POS system 112, and / or merchant server 114. Of course, the process 300 (and other processes described herein) may be performed in other similar and / or different environments.

302では、ユーザ102は、EPT108を使用して支払いを商人104に提供してもよい。例えば、ユーザ102は、従来型実店舗の場所の商人104と相互作用し、EPTを直接商人104に提出してもよい。ユーザはまた、ネットワーク(複数)106を使用してアクセス可能な電子市場を通じて商人104と相互作用してもよい。場合によっては、ユーザは、ユーザデバイス110を使用してブラウザまたはアプリケーションを介してEPT108を転送してもよい。   At 302, user 102 may provide payment to merchant 104 using EPT 108. For example, the user 102 may interact with a merchant 104 at a conventional physical store location and submit an EPT directly to the merchant 104. The user may also interact with merchant 104 through an electronic market accessible using network (s) 106. In some cases, the user may transfer the EPT 108 via a browser or application using the user device 110.

304では、ユーザデバイス110は、支払いアプリケーション222を使用して購入を承認する要求(すなわち、修正された要求124)を受信してもよく、商人サーバ114からゲートウェイ118および/またはホストサーバ122を通ってユーザデバイス110に達するように経路指定されてもよい。支払いアプリケーション222は、EPT108を商人に(例えば、ブラウザなどを介して)転送するために使用され得るアプリケーションとは異なってもよい。この要求は、コードに対する要件、利用可能な電子支払い方式、支払うべき金額などの要求の詳細、取引に含まれる品目などの追加情報を含んでもよい。   At 304, user device 110 may receive a request to approve a purchase using payment application 222 (ie, modified request 124) from merchant server 114 through gateway 118 and / or host server 122. May be routed to reach the user device 110. Payment application 222 may be different from an application that may be used to transfer EPT 108 to a merchant (eg, via a browser or the like). This request may include additional information such as requirements for the code, available electronic payment methods, request details such as the amount to be paid, and items included in the transaction.

306では、支払いアプリケーション222は、少なくとも部分的にユーザデバイス110を使用して提供されるユーザ102からの入力に基づき、支払いを承認するかまたは拒否するかを決定してもよい。ユーザ102が支払いを拒否することを決定すると、308では(「いいえ」経路に従って)、支払いアプリケーション222は、支払いを拒否するように応答をホストサーバ122に送信してもよい。しかしながら、ユーザが支払い要求を承認することを決定すると(決定操作306から「はい」経路に従って)、310でプロセス300が継続してもよい。   At 306, payment application 222 may determine whether to approve or reject the payment based at least in part on input from user 102 provided using user device 110. If the user 102 decides to decline the payment, at 308 (according to the “No” path), the payment application 222 may send a response to the host server 122 to decline the payment. However, if the user decides to approve the payment request (according to the “yes” path from decision operation 306), process 300 may continue at 310.

310では、支払いアプリケーション222は、要求に対する応答(または回答)を生成してもよい。応答は、1つ以上のEPTの選択(操作302で使用されたEPTを含むかまたは異なる)を含んでもよく、選択モジュール228によって収集されるか、および/または処理されてもよい。応答はまた、PIN、パスワード、生体感知データ、または検証モジュール224によって収集されるか、および/または処理され得る他の個人情報などのコードを含む。場合によっては、応答は、ユーザ102が支払い要求を拒絶することを望むときに拒絶コマンドを含んでもよい。応答はまた、ユーザデバイス110の場所などの条件情報を含んでもよく、条件モジュール226によって収集されるか、および/または処理されてもよい。   At 310, payment application 222 may generate a response (or answer) to the request. The response may include a selection of one or more EPTs (including or different from the EPT used in operation 302) and may be collected and / or processed by the selection module 228. The response also includes a code such as a PIN, password, biometric data, or other personal information that can be collected and / or processed by the verification module 224. In some cases, the response may include a reject command when the user 102 wishes to reject the payment request. The response may also include condition information, such as the location of the user device 110, and may be collected and / or processed by the condition module 226.

312では、支払いアプリケーションは、応答および関連情報をホスト120のホストサーバ122に送信してもよい。次に、ホストサーバ122は、応答がホスト120からの要求に含まれるコードおよび/または条件要件を満たすときなど、応答が正しいときに、応答をゲートウェイ118および/または商人104に中継してもよい。   At 312, the payment application may send the response and related information to the host server 122 of the host 120. The host server 122 may then relay the response to the gateway 118 and / or merchant 104 when the response is correct, such as when the response meets the code and / or condition requirements included in the request from the host 120. .

図4は、図1に示される環境100から様々な関係者間の相互作用を示す例示的なプロセス400のフロー図である。プロセス400に示される操作は、それぞれの操作を行い得る関係者の下で示されるが、操作は、他の構成では、少なくとも部分的に他の関係者によって行われてもよい。例えば、商人サーバ114下で指定される操作の一部またはすべてが、POSシステム112によって行われてもよい。操作は、それぞれの関係者間で送信される情報の安全性に対するデータの暗号化/復号化を含んでもよい。   FIG. 4 is a flow diagram of an exemplary process 400 illustrating the interaction between various parties from the environment 100 shown in FIG. The operations shown in process 400 are shown under the parties that can perform the respective operations, but in other configurations, the operations may be performed at least partially by other parties. For example, some or all of the operations specified under merchant server 114 may be performed by POS system 112. The operation may include encryption / decryption of data with respect to the security of information transmitted between the respective parties.

402では、商人サーバ114は、ユーザ102からEPT108を介して支払いを受信してもよい。   At 402, merchant server 114 may receive payment from user 102 via EPT 108.

404では、商人サーバ114は、資金を検証するか、電子支払い方式を認証するか、または他の理由のために操作402で受信された支払いに対する承認を要求してもよい。   At 404, merchant server 114 may request authorization for the payment received at operation 402 for verifying funds, authenticating an electronic payment scheme, or for other reasons.

406では、商人104の代理の金融機関または別の関係者であり得るゲートウェイ118は、支払いを承認する発行者(すなわち、ホスト120)を識別してもよい。   At 406, the gateway 118, which may be a financial institution on behalf of the merchant 104 or another party, may identify an issuer (ie, host 120) that approves payment.

408では、アカウントマネージャ214を介するホストサーバ122は、操作404および406からの承認メッセージおよび支払いと関連付けられるユーザ102を決定してもよい。ホストサーバ122は、アカウントデータ126を介してEPT108の識別番号をユーザ102に一致させてもよい。   At 408, the host server 122 via the account manager 214 may determine the user 102 associated with the approval message and payment from the operations 404 and 406. The host server 122 may match the identification number of the EPT 108 with the user 102 via the account data 126.

410では、ホストサーバ122は、承認パラメータを決定してもよい。承認パラメータは、自動的に承認される購入品(例えば、ホワイトリストに載せられたもの、所定の金額未満のものなど)または支払い要求を処理する承認に対する特定の要件(例えば、承諾に加えてセキュリティコードが必要とされるどうかなど)などの承認に対する規則に基づいてもよい。   At 410, the host server 122 may determine an approval parameter. Approval parameters can be automatically approved purchases (eg, whitelisted, less than a predetermined amount) or specific requirements for authorization to process payment requests (eg, security in addition to consent) It may be based on rules for approval, such as whether a code is required.

412では、ホストサーバ122は、ユーザがEPT108を使用する資格があるかどうかを決定してもよい。例えば、ホストサーバ122は、使用者のアカウントが支払いを成立させるのに必要な資金を有するかどうかを決定してもよく、かつ/あるいはホストサーバは、要求が不正リスクにより拒否されるべきかどうかを決定する様々な不正検査を行ってもよい。ユーザがEPTもしくは他のEPTを使用する資格があること、および/または不正リスクが許容範囲(閾値点数未満など)であることをホストサーバ122が決定すると、414で処理が継続してもよい。   At 412, the host server 122 may determine whether the user is eligible to use the EPT 108. For example, the host server 122 may determine whether the user's account has the necessary funds to complete the payment and / or the host server may determine whether the request should be rejected due to fraud risk. Various fraud checks may be performed to determine If the host server 122 determines that the user is eligible to use an EPT or other EPT and / or the fraud risk is acceptable (eg, less than a threshold score), processing may continue at 414.

414では、承認が必要とされると、承認マネージャ216を介するホストサーバ122は、修正された要求(例えば、修正された要求124)をユーザ102と関連付けられるユーザデバイス110に送信してもよい。場合によっては、ユーザ102は、家族の一員、取引先、同僚、友人などの別の人物に承認または購買(EPTの使用)を委託してもよい。したがって、ユーザデバイス110を操作するユーザ102は、必ずしもEPT108を商人104に呈示するユーザでなくてもよい。   At 414, when approval is required, the host server 122 via the approval manager 216 may send a modified request (eg, the modified request 124) to the user device 110 associated with the user 102. In some cases, the user 102 may entrust approval or purchase (use of EPT) to another person, such as a family member, business partner, colleague, friend, or the like. Therefore, the user 102 who operates the user device 110 is not necessarily a user who presents the EPT 108 to the merchant 104.

416では、支払いアプリケーション222を介するユーザデバイス110は、承認パラメータを含む承認メッセージを処理してもよい。例えば、支払いアプリケーション222は、検証モジュール224を介してコードを要求するかどうかを決定するか、条件モジュール226を使用して条件(例えば、ユーザデバイスの場所など)を決定するか、またはユーザ102への要求の呈示の前もしくは呈示中に他の可能な操作を行ってもよい。加えて、支払いアプリケーション222を介するユーザデバイス110は、選択モジュール228を使用して操作402で開始される購入を満たす他のまたは追加のEPTをユーザ102が選択することを可能にしてもよい。   At 416, the user device 110 via the payment application 222 may process an approval message that includes an approval parameter. For example, the payment application 222 determines whether to request a code via the verification module 224, uses the condition module 226 to determine a condition (eg, the location of the user device), or to the user 102 Other possible operations may be performed before or during the presentation of the request. In addition, the user device 110 via the payment application 222 may allow the user 102 to select other or additional EPTs that satisfy the purchase initiated at operation 402 using the selection module 228.

418では、ユーザデバイス110は、応答(回答)をホストサーバ122に戻すように送信してもよい。応答は、承諾または拒否、コード、指定されたEPT(複数)、および条件情報のうちの少なくとも1つ以上を含んでもよい。   At 418, the user device 110 may send a response (answer) back to the host server 122. The response may include at least one or more of accept or reject, code, specified EPT (s), and condition information.

420では、承認モジュール216を介するホストサーバ420は、ユーザが支払いを承諾するときに応答を検証してもよい。例えば、承認モジュール216は、コードが正しいこと、条件が満たされることなどを検証してもよく、アカウントデータ126を使用して行われてもよい。   At 420, the host server 420 via the authorization module 216 may verify the response when the user accepts the payment. For example, the authorization module 216 may verify that the code is correct, the condition is met, etc., and may be performed using the account data 126.

422では、承認モジュール216は、応答が承認される(すなわち、承諾され、かつ正しい)かどうか、ユーザ102が支払いのための十分な資金を有するかどうか、かつ支払いが不正であり得ないかどうかを決定してもよい。応答がユーザから承認され、情報(例えば、コード、条件など)が正しいとき、または承認が決定操作414から必要とされないとき、かつ十分な資金が利用可能であり、または不正のリスクが低い(例えば、閾値点数未満など)とき、承諾応答は、424で商人サーバ114に送信されてもよく、426でゲートウェイを介して転送されてもよい。応答がユーザ102から拒否され、ユーザが十分な資金を欠き、および/または不正リスクが高いと、拒絶(拒否)応答は、428で商人サーバ114に送信されてもよく、430でゲートウェイを介して転送されてもよい。支払いはまた、ユーザデバイス110を介するユーザ102からの承認のための通信より前に、所定の要因に基づき、ユーザのアカウントが十分な資金を欠き、および/または支払いが不正であり得ることをホストサーバ122が決定すると、決定操作414から経路「いいえ」に従って拒否されてもよい。   At 422, the approval module 216 determines whether the response is approved (ie, accepted and correct), whether the user 102 has sufficient funds for payment, and whether the payment can be fraudulent. May be determined. When the response is approved by the user and the information (eg, code, condition, etc.) is correct, or when approval is not required from the decision operation 414, and sufficient funds are available or the risk of fraud is low (eg, The acceptance response may be sent to the merchant server 114 at 424 and forwarded via the gateway at 426. If the response is rejected by the user 102, the user lacks sufficient funds, and / or the fraud risk is high, a rejection (rejection) response may be sent to the merchant server 114 at 428 via the gateway at 430. May be forwarded. Payment also hosts that the user's account lacks sufficient funds and / or the payment may be fraudulent based on predetermined factors prior to communication for approval from user 102 via user device 110. Once the server 122 decides, it may be rejected from the decision operation 414 according to the route “No”.

図5は、支払い承認の間にEPTを選択する例示的なプロセス500のフロー図である。プロセス500は、以下の記載において支払いアプリケーション222を介してユーザデバイス110によって行われると記載されるが、プロセス500はまた、アカウントデータ126に記憶される規則に基づいて決定が選択されるときなど、アカウントマネージャ214を介してホストサーバ122によって部分的または全体的に行われてもよい。   FIG. 5 is a flow diagram of an example process 500 for selecting an EPT during payment authorization. The process 500 is described as being performed by the user device 110 via the payment application 222 in the description below, but the process 500 may also be selected when a decision is selected based on rules stored in the account data 126, etc. This may be done in part or in whole by the host server 122 via the account manager 214.

502では、支払いアプリケーション222は、承認メッセージを受信してもよい。承認メッセージは、支払うべき金額、条件、コードに対する要件、および/または他の情報を含んでもよい。   At 502, payment application 222 may receive an approval message. The approval message may include the amount to be paid, conditions, code requirements, and / or other information.

504では、支払いアプリケーション222の選択モジュール228は、ユーザ102による選択に対するEPTを提供してもよく、商人104に提供されるEPT108(例えば、操作302における)とは異なってもよい。   At 504, the selection module 228 of the payment application 222 may provide an EPT for selection by the user 102 and may be different from the EPT 108 (eg, at operation 302) provided to the merchant 104.

506では、選択モジュール228は、支払うべき金額の少なくとも一部分を満たすEPTの選択を受信してもよい。   At 506, the selection module 228 may receive an EPT selection that satisfies at least a portion of the amount to be paid.

508では、選択モジュール228は、操作506で選択されたEPTと関連付けられる金額(または割合など)を受信してもよい。   At 508, the selection module 228 may receive an amount (or percentage, etc.) associated with the EPT selected at operation 506.

510では、選択モジュール228は、追加のEPTが使用されるべきか、またはユーザ102によって選択されるべきであるかどうかを決定してもよい。例えば、支払うべき金額が操作508での選択後に依然としてそのままである場合、ユーザ102は、別のEPTおよび/または別の金額を入力するよう促されてもよく、「はい」経路に従う操作506(または操作508)に戻るようにプロセスに指示してもよい。   At 510, the selection module 228 may determine whether additional EPT should be used or selected by the user 102. For example, if the amount to be paid is still intact after selection at operation 508, user 102 may be prompted to enter another EPT and / or another amount, and operation 506 following the “yes” path (or The process may be instructed to return to operation 508).

他のEPTが使用されるべきではなく、操作510から「いいえ」経路に従うと、支払いアプリケーション222は、操作502からの承認メッセージを満たすために512で承認をホストに送信してもよい。   If no other EPT should be used and following the “No” path from operation 510, payment application 222 may send an approval to the host at 512 to satisfy the approval message from operation 502.

様々な実施形態では、支払いアプリケーション222は、ホストサーバ122からの金融情報(例えば、残高情報など)を依頼し、貸越またはEPTの信用限度の超過を防ぐことを試みてもよい。貸越が起こり得るかまたは可能性があることを支払いアプリケーション222が決定すると、支払いアプリケーションは、ユーザを促し、および/または決定操作510で別のEPTの使用を要求してもよい。   In various embodiments, payment application 222 may request financial information (eg, balance information, etc.) from host server 122 and attempt to prevent overdraft or EPT credit limits being exceeded. Once the payment application 222 determines that overdraft can occur or is possible, the payment application may prompt the user and / or request the use of another EPT in the decision operation 510.

いくつかの実施形態では、アカウントデータ126は、ユーザに対するEPTを選択する特定の規則を含んでもよい。例えば、アカウントデータ126は、指定された商人に対する特定のEPTを使用する規則を含んでもよい。特定のEPTは、指定された商人に対する追加の報酬(点数、マイルなど)を含むクレジットカードであってもよい。これらの規則は、ユーザによって生成されるか、ユーザ102の過去の取引から取り出されるか、そうでなければユーザに対して生成されてもよい。いくつかの実施形態では、好ましいEPT(または場合により複数のEPT)は、アカウントマネージャ214によってユーザに予め選択され、かつ予め選択するプロセスを介するなど、支払いアプリケーション222を介してユーザの確認の対象になってもよい。   In some embodiments, account data 126 may include specific rules for selecting an EPT for the user. For example, account data 126 may include rules that use a specific EPT for a designated merchant. A particular EPT may be a credit card that includes additional rewards (points, miles, etc.) for a designated merchant. These rules may be generated by the user, retrieved from the user's 102 past transactions, or otherwise generated for the user. In some embodiments, the preferred EPT (or possibly multiple EPTs) is subject to user confirmation via the payment application 222, such as through a pre-selection process and a pre-selection process by the account manager 214. It may be.

図6は、支払い要求の穏やかな拒否を開始する例示的なプロセス600のフロー図である。穏やかな拒否は、承認プロセスが停止される時間(例えば、深夜など)の間に要求されるとき、および/またはユーザ102が要求に応答しないときに使用されてもよい。プロセス600は、ホストサーバ122によって行われてもよいが、他の関係者またはコンピューティングデバイスがプロセスを実践するために使用されてもよい。   FIG. 6 is a flow diagram of an example process 600 for initiating a mild refusal of a payment request. A gentle rejection may be used when requested during a time when the approval process is stopped (eg, late at night) and / or when the user 102 does not respond to the request. Process 600 may be performed by host server 122, but may be used by other parties or computing devices to practice the process.

602では、ホストサーバ122は、商人104から生じる購入を承認する要求を受信し、場合によりゲートウェイ118を介して中継されてもよい。   At 602, the host server 122 receives a request to approve a purchase that originates from the merchant 104 and may optionally be relayed through the gateway 118.

604では、承認マネージャ216を介するホストサーバ122は、ユーザデバイス110を介してユーザ102へ伝達せずに購入要求に対する自動返信を可能にする規則が存在するかどうかを決定してもよい。例えば、承認マネージャ216は、要求に自動的に返信するかどうかを決定するアカウントデータ126に記憶される設定または規則を決定するように、アカウントマネージャ214によって提供される情報を使用してもよい。規則は、一部の購入額が自動的に承認されること(例えば、カテゴリ、商人に限り、またはこれらに限らない閾値未満など)を示してもよく、ユーザデバイス110を介してユーザ102との相互作用なしに自動承諾をもたらしてもよい。規則はまた、一部の購入をブラックリストに載せてもよく、ユーザデバイス110を介してユーザ102との相互作用なしに自動拒否をもたらしてもよい。要求が自動返信に対して資格がないとき、決定操作604によって決定されるように、606で処理が継続してもよい。   At 604, the host server 122 via the authorization manager 216 may determine whether there is a rule that allows an automatic reply to a purchase request without communicating to the user 102 via the user device 110. For example, the authorization manager 216 may use the information provided by the account manager 214 to determine the settings or rules stored in the account data 126 that determines whether to automatically reply to the request. The rules may indicate that some purchase amounts are automatically approved (eg, categories, merchants only, or less than a threshold, etc.) and may be communicated with user 102 via user device 110. May lead to automatic consent without interaction. The rules may also blacklist some purchases and may result in automatic rejection without interaction with the user 102 via the user device 110. When the request is not eligible for automatic reply, processing may continue at 606 as determined by decision operation 604.

606では、承認マネージャ216は、場合によりアカウントデータ126に記憶された規則または設定に従って、要求がユーザデバイス110を介してユーザ102に送信され得るかどうかを決定してもよい。例えば、ユーザ102は、深夜から早朝(または他の日、他の時間など)など、ある時間帯に承認メッセージを受信するのを停止することを決定してもよい。承認マネージャ216が、停止された時間であることを決定すると、承認マネージャは、608で穏やかな拒否を発行してもよく、602で受信された要求に対する一時的な拒絶として機能してもよい。この場合、ホストサーバ122は、610で遅延を行ってもよく、停止時間が経過したかどうか(遅延後)再び決定してもよい。   At 606, the authorization manager 216 may determine whether a request can be sent to the user 102 via the user device 110 according to rules or settings optionally stored in the account data 126. For example, the user 102 may decide to stop receiving an approval message at some time, such as from midnight to early morning (or other day, other time, etc.). If the approval manager 216 determines that it is a suspended time, the approval manager may issue a gentle rejection at 608 and may act as a temporary rejection for the request received at 602. In this case, the host server 122 may delay at 610 and may determine again whether the stop time has elapsed (after the delay).

606で停止がないと(「いいえ」経路に従って)、612で処理が継続してもよい。612では、承認マネージャ216を介するホストサーバ122は、支払いアプリケーション222に対してユーザデバイス110を介して要求をユーザ102に送信してもよい。   If there is no stop at 606 (according to the “No” route), processing may continue at 612. At 612, the host server 122 via the authorization manager 216 may send a request to the user 102 via the user device 110 to the payment application 222.

614では、ホストサーバ122は、所定の時間量内にユーザ102から応答が受信されたかどうかを決定してもよい。所定の時間量内に応答が受信されると、616(操作614の決定に先行してもよい)で応答が受信され、次いで応答を商人104に(場合によりゲートウェイ118を介して)転送する。   At 614, the host server 122 may determine whether a response has been received from the user 102 within a predetermined amount of time. If a response is received within a predetermined amount of time, the response is received at 616 (which may precede the decision of operation 614) and then forwarded to merchant 104 (possibly via gateway 118).

しかしながら、614で所定の時間量内に応答が受信されないと(「いいえ」経路に従って)、承認マネージャ216を介するホストサーバ122は、622で再びユーザに連絡することを試みるかどうかを決定する620の規則(複数)を適用してもよい。例えば、規則は、所定の金額まで、および/または他の基準に基づき、承認された商人からの支払い要求を承認するようにホスト120に指示してもよい。同様に、規則はまた、規則に規定された様々な理由のために支払いを拒否するようにホスト120に指示してもよい。規則はまた、決定操作622で再び試みないと決定する前に行うホスト120に対するいくつか試みを示してもよい。承認マネージャ216が決定操作622で再び試みると、穏やかな拒否を発行することによって操作608で処理が再開し、次いで、上述され、かつ図5に示されるように操作610の遅延によって処理が進んでもよい。   However, if a response is not received within a predetermined amount of time at 614 (following the “No” path), then the host server 122 via the authorization manager 216 determines 620 whether to attempt to contact the user again at 622. Rule (s) may apply. For example, rules may instruct host 120 to approve payment requests from approved merchants up to a predetermined amount and / or based on other criteria. Similarly, the rules may also instruct host 120 to refuse payment for various reasons set forth in the rules. The rule may also indicate some attempts to host 120 before deciding not to try again in decision operation 622. When authorization manager 216 tries again at decision operation 622, processing resumes at operation 608 by issuing a gentle rejection, and then processing proceeds due to the delay of operation 610 as described above and shown in FIG. Good.

規則によって限度に達したかもしくは越えたとき、または規則に含まれる他の理由のためなど、操作622の決定が再び試みるべきでないとき、承認マネージャ216は、支払い要求を満たすかまたは支払い要求を拒否するかのいずれかである応答を操作620からの規則を使用して決定してもよい。次に、応答は、場合によりゲートウェイ118を介して618で商人に転送されてもよい。   When the limit of operation 622 should not be retried, such as when the limit is reached or exceeded by the rule, or for other reasons included in the rule, the authorization manager 216 satisfies the payment request or rejects the payment request. A response that is either may be determined using the rules from operation 620. The response may then be forwarded to the merchant at 618, possibly via the gateway 118.

図7は、モバイルデバイスアプリケーションによる使用のための承認方式を選択する例示的なプロセス700のフロー図である。プロセス700は、ホストサーバ122よって行われてもよいが、他の関係者またはコンピューティングデバイスがプロセスを実践するために使用されてもよい。プロセス700は、ユーザデバイス110にある支払いアプリケーション222の条件モジュール226と協働して操作してもよい。後述されるように、プロセス700は、ユーザデバイス110の場所と関連付けられる条件を参照しながら記載されるが、他の条件がプロセス700を使用して実践されてもよい。   FIG. 7 is a flow diagram of an example process 700 for selecting an approval scheme for use by a mobile device application. Process 700 may be performed by host server 122, but may be used by other parties or computing devices to practice the process. Process 700 may operate in conjunction with payment application 222 conditions module 226 at user device 110. As described below, process 700 is described with reference to conditions associated with the location of user device 110, although other conditions may be practiced using process 700.

702では、ホストサーバ122は、購入を承認する要求を受信してもよい。   At 702, the host server 122 may receive a request to approve purchases.

704では、ホストサーバ122は、承認が、商人104の場所に対するユーザデバイス110の場所などの条件の対象となるかどうかを決定してもよい。承認が決定操作704の条件の対象となると、「はい」経路に従って、706で処理が継続してもよい。   At 704, the host server 122 may determine whether the approval is subject to conditions such as the location of the user device 110 relative to the merchant 104 location. If approval is subject to the conditions of the decision operation 704, processing may continue at 706 along a “yes” path.

706では、ホストサーバ122は、条件モジュール226を介してユーザデバイス110の場所を要求してもよく、ユーザデバイス110のGPS受信部などを介して場所(または他の情報)を取得してもよい。   At 706, the host server 122 may request the location of the user device 110 via the condition module 226, and obtain the location (or other information) via the GPS receiver of the user device 110 or the like. .

ユーザデバイス110から条件情報を受信した後に、708では、ホストサーバ122は、ユーザデバイス110の場所を商人104の場所またはユーザ102と関連付けられた既知の場所(例えば、ユーザの家、事務所、頻繁に訪れた場所など)と比較してもよい。710では、ホストサーバ122は、デバイスの場所が商人の場所または既知の場所と一致するかどうかの比較に基づいて決定してもよい。712で不一致が記録されてもよいが、714で一致が記録されてもよい。   After receiving the condition information from the user device 110, at 708, the host server 122 changes the location of the user device 110 to the location of the merchant 104 or a known location associated with the user 102 (eg, the user's home, office, frequent Compared to places visited in At 710, the host server 122 may determine based on a comparison of whether the device location matches the merchant location or a known location. Although a mismatch may be recorded at 712, a match may be recorded at 714.

716では、承認マネージャ216を介するホストサーバ122は、承認要件を決定してもよい。いくつかの実施形態では、この承認は、結果(すなわち、操作712および714)に基づいてもよい。この決定は、他の関連要因を含んでもよい。例えば、関連要因は、支払いが遠隔取引(例えば、オンライン、電話によるなど)または従来型実店舗の場所での手が届く距離の取引に対するかどうかを含んでもよい。後者の状況では、ユーザデバイスの場所と商人の場所との一致(操作714)が、軽減された承認プロセス(簡略化または皆無)をもたらしてもよい。前者の状況(遠隔取引)では、ユーザデバイス110の場所は、既知および/または頻度が高い場所(自宅、仕事場、学校など)と比較されてもよく、次いで承認プロセスを選択するために使用されてもよい。例えば、ユーザデバイス110が未知の場所(例えば、自宅ではないなど)に位置するときに、より困難な承認プロセス(例えば、コードに対する要求を含む)が使用されてもよい。   At 716, the host server 122 via the approval manager 216 may determine approval requirements. In some embodiments, this approval may be based on the results (ie, operations 712 and 714). This determination may include other related factors. For example, relevant factors may include whether payment is for a remote transaction (eg, online, by phone, etc.) or a distance transaction within reach of a traditional physical store location. In the latter situation, matching the user device location to the merchant location (operation 714) may result in a reduced approval process (simplified or none). In the former situation (remote transaction), the location of the user device 110 may be compared to a known and / or frequent location (home, workplace, school, etc.) and then used to select an approval process. Also good. For example, a more difficult approval process (eg, including a request for a code) may be used when the user device 110 is located in an unknown location (eg, not at home).

718では、承認マネージャ216を介するホストサーバ122は、承認メッセージをユーザデバイスに送信してもよい。   At 718, the host server 122 via the approval manager 216 may send an approval message to the user device.

720では、承認マネージャ216を介するホストサーバ122は、応答を受信し、検証してもよい。722で応答が承認され、正しい(例えば、(要求される場合)正しいコードが受信されるなど)とき(「はい」経路に従って)、ホストサーバ122は、場合によりゲートウェイ118を介して724で承認を商人に送信してもよい。応答が拒否されるとき、もしくは場合によりコードが正しくないとき、または722で過度の遅延(例えば、図6の操作620)の後(「いいえ」経路に従って)、ホストサーバ122は、場合によりゲートウェイ118を介して726で拒絶を商人に送信してもよい。   At 720, the host server 122 via the authorization manager 216 may receive and verify the response. When the response is approved at 722 and is correct (eg, the correct code is received (if requested)) (according to the “yes” path), the host server 122 may optionally approve at 724 via the gateway 118. It may be sent to the merchant. When the response is rejected, or possibly the code is incorrect, or after an excessive delay (eg, operation 620 of FIG. 6) at 722 (according to the “No” path), the host server 122 may optionally be gateway 118. A rejection may be sent to the merchant at 726 via.

いくつかの実施形態では、操作708〜714から決定される場所情報は、支払い要求を満たすかどうかを決定するホストサーバ122によって別のチェックポイントとして使用されてもよい。例えば、プロセス700は、場所情報に対する要求の前または同時に、承認メッセージ718をユーザデバイス110に送信することを含んでもよい。操作720は、支払いを承認するためにユーザの決定を場合により覆すかどうかを決定する操作712〜714からの情報を使用してもよい。例えば、712で場所が異なり、不正が起こり得る(例えば、誰かがユーザデバイス110を盗んだなど)ことをホストサーバ122が決定すると、ホストサーバ122は、承認メッセージが支払いを承認する意図を有するユーザデバイス110から受信され、かつ正しいコード(要求される場合)を含むときであっても支払いを拒否してもよい。   In some embodiments, the location information determined from operations 708-714 may be used as another checkpoint by host server 122 that determines whether to satisfy a payment request. For example, process 700 may include sending an approval message 718 to user device 110 before or at the same time as the request for location information. Operation 720 may use information from operations 712-714 that determine whether to overturn the user's decision to approve payment. For example, if the host server 122 determines that the location is different at 712 and fraud may occur (eg, someone has stolen the user device 110), the host server 122 may have a user whose authorization message is intended to approve payment. Payment may be refused even when received from device 110 and includes the correct code (if required).

図8は、支払い選択および承認を可能にする例示的なユーザインターフェース(UI)800である。UI800は、ユーザデバイス110で動作する支払いアプリケーション222を介してユーザ102に呈示されてもよい。UI800は、情報セクション802、支払い選択セクション804、コードセクション806、決定セクション808、またはこれらの任意の組み合わせを含んでもよい。それぞれのセクションが順に記載される。   FIG. 8 is an exemplary user interface (UI) 800 that enables payment selection and approval. The UI 800 may be presented to the user 102 via a payment application 222 that runs on the user device 110. The UI 800 may include an information section 802, a payment selection section 804, a code section 806, a decision section 808, or any combination thereof. Each section is listed in turn.

情報セクション802は、支払うべき金額810、ならびに場合により、商人の識別子812および/または説明814などの支払取引の説明を提供してもよく、支払取引の品目/サービスまたは他の詳細を表示してもよい。いくつかの実施形態では、説明は、より多くの情報へのリンクを含んでもよい。   The information section 802 may provide a description of the payment transaction, such as the amount 810 to be paid, and possibly a merchant identifier 812 and / or description 814, and may display items / services or other details of the payment transaction. Also good. In some embodiments, the description may include links to more information.

支払い選択セクション804は、部分的に選択モジュール228によって事前設定され、図5に示されるプロセス500に従う選択肢を含んでもよい。支払い選択セクション804は、少なくとも部分的にホストサーバ122にアクセス可能なアカウントデータ126の情報に基づき、ユーザに利用可能であるEPT816を含んでもよい。加えて、支払い選択セクション804は、購入額818の割合および/または支払うべき金額820など、EPT816のそれぞれに対して含める金額の選択を含んでもよい。第1のEPTに対する購入額の100%の入力を示す例示的なデータが図8に示される。いくつかの実施形態では、これは、ユーザ102に対して利便性のために既定の入力として選択モジュール228によって事前設定されてもよい。選択モジュール228は、ユーザがそれぞれのEPTから特別な報酬を取得することを可能にするなどのため、一部の商人または製品カテゴリに対する特定のEPTの選好を生成する、アカウントデータに記憶される規則などの規則に基づく既定の入力を生成してもよい。   The payment selection section 804 may be preconfigured in part by the selection module 228 and may include options in accordance with the process 500 shown in FIG. The payment selection section 804 may include an EPT 816 that is available to the user based at least in part on information in the account data 126 that is accessible to the host server 122. In addition, the payment selection section 804 may include a selection of amounts to include for each of the EPTs 816, such as a percentage of the purchase amount 818 and / or an amount 820 to be paid. Exemplary data showing input of 100% of the purchase amount for the first EPT is shown in FIG. In some embodiments, this may be preset by the selection module 228 as a default input for the user 102 for convenience. The selection module 228 creates rules that are stored in account data that generate specific EPT preferences for some merchants or product categories, such as to allow users to obtain special rewards from their respective EPTs, etc. A default input based on such a rule may be generated.

コードセクション806は、承認メッセージによって必要とされるときに、コードを入力する1つ以上の選択肢を含んでもよい。場合によっては、複数の選択肢が図8に示されるようなコードセクションに含まれてもよい。しかしながら、場合によっては、コードセクション806は、PIN822、生体認証824、パターン826、または他の種類のコードなどのある種類のコードのみを可能にしてもよい。   The code section 806 may include one or more options for entering a code when required by an approval message. In some cases, multiple options may be included in a code section as shown in FIG. However, in some cases, code section 806 may only allow certain types of codes, such as PIN 822, biometric 824, pattern 826, or other types of codes.

決定セクション808は、支払い要求を拒絶する拒絶コマンド828と、支払い要求を承諾する承諾コマンド830とを含んでもよい。いくつかの実施形態では、コードが必要とされないとき、コードセクション806は、省略され、グレーアウト表示され、そうでなければ利用されない場合がある。この状況では、ユーザは、要求された支払いを承認する承諾コマンド830を選択することしか必要とされなくてもよい。   Decision section 808 may include a reject command 828 that rejects the payment request and an accept command 830 that accepts the payment request. In some embodiments, the code section 806 may be omitted and grayed out when no code is needed, otherwise it may not be utilized. In this situation, the user may only need to select an accept command 830 to approve the requested payment.

UI800はまた、追加の情報を含んでもよい。例えば、これは、ユーザがUI800を介してメッセージを受信するユーザ102ではない(例えば、代理人が承認しているユーザ102の代理としてEPTを使用しているなど)ときに、支払いを開始するユーザからの個人メッセージ(テキスト、音声、映像などによる)を含んでもよい。   The UI 800 may also include additional information. For example, this is the user who initiates payment when the user is not the user 102 receiving the message via the UI 800 (eg, using EPT on behalf of the user 102 authorized by the agent). Personal messages (by text, audio, video, etc.).

図9は、ホストからの承認メッセージの管理を可能にする例示的なUI900である。UI900は、ホストサーバ122によって供給され、かつユーザデバイス(例えば、ユーザデバイス110または別のコンピューティングデバイス)を介してアクセス可能なアカウントマネージャ214を介してユーザ102に呈示されてもよい。UI900は、最近の活動セクション902、規則セクション904、メニューセクション906、またはこれらの任意の組み合わせを含んでもよい。それぞれのセクションが順に記載される。   FIG. 9 is an exemplary UI 900 that enables management of approval messages from hosts. The UI 900 may be presented to the user 102 via an account manager 214 that is supplied by the host server 122 and accessible via the user device (eg, the user device 110 or another computing device). The UI 900 may include a recent activity section 902, a rules section 904, a menu section 906, or any combination thereof. Each section is listed in turn.

最近の活動セクション902は、ユーザ102が未来の取引の発生または類似の取引に対する規則を容易に作成することを可能にし得る前回の取引を含んでもよい。最近の活動セクション902は、取引のエンティティ指定子908および日付910を含んでもよい。それぞれの取引では、最近の活動セクション902は、関係者、カテゴリ、分野などからの承認メッセージを自動的に承認するホワイトリスト選択肢912を含んでもよく、指定された期間につき指定された取引額(例えば、1週間に$50、1回の取引に$100など)まで含んでもよい。選択肢はまた、関係者、カテゴリ、分野などに対する承認メッセージを自動的に拒否するブラックリスト選択肢914を含んでもよい。加えて、最近の活動セクション902は、ユーザ102が関係者、カテゴリ、および/または分野に対する承認の種類916を選択することを可能にしてもよい。いくつかの実施形態では、最近の活動選択はまた、EPTセレクタ918を使用してユーザ102がEPTを関係者、カテゴリ、および/または分野に関連付けることを可能にしてもよい。   Recent activity section 902 may include previous transactions that may allow user 102 to easily create rules for future transaction occurrences or similar transactions. Recent activity section 902 may include a transaction entity specifier 908 and a date 910. For each transaction, the recent activity section 902 may include a whitelist option 912 that automatically approves approval messages from interested parties, categories, domains, etc., for a specified transaction amount (eg, Up to $ 50 per week, $ 100 per transaction, etc.). The options may also include a blacklist option 914 that automatically rejects approval messages for parties, categories, areas, etc. In addition, the recent activity section 902 may allow the user 102 to select an approval type 916 for the parties, categories, and / or areas. In some embodiments, recent activity selections may also use the EPT selector 918 to allow the user 102 to associate EPTs with parties, categories, and / or areas.

規則セクション904は、ユーザ102が承認メッセージを自動的に承諾するかまたは拒絶するように適用され得る規則を生成することを可能にしてもよい。規則は、説明920、許容額922、および/または承認種類924を含んでもよい。例えば、許容額922は、期間を含んでもよい。規則セクション904は、追加の規則を追加する「さらに追加」コマンド926を含んでもよい。ユーザはまた、規則を削除するか、そうでなければUI900を介して規則を管理することができてもよい。   Rules section 904 may allow user 102 to generate rules that can be applied to automatically accept or reject an approval message. The rules may include a description 920, an allowance 922, and / or an approval type 924. For example, the allowable amount 922 may include a period. Rules section 904 may include an “add more” command 926 to add additional rules. The user may also be able to delete rules or otherwise manage the rules via the UI 900.

メニューセクション906は、ユーザがUI900を操作することを可能にするコマンドを含んでもよい。コマンドは、閉じるコマンド928と、ヘルプコマンド930と、および/またはホストサーバ122による使用のためのアカウントデータ126にUI900によって取得される情報を保存する保存コマンド932とを含んでもよい。   Menu section 906 may include commands that allow a user to operate UI 900. The commands may include a close command 928, a help command 930, and / or a save command 932 that saves information obtained by the UI 900 in the account data 126 for use by the host server 122.

付記
1.モバイルデバイスを使用して支払いを承認する方法であって、
実行可能命令で構成されるモバイルデバイスの制御下で、ホストからモバイルデバイスを介して、関連した銀行カード識別子を有する銀行カードを使用する支払いを承認する要求を受信することであって、銀行カード識別子が、商人の場所で、または要求を受信するために使用される通信経路とは異なる通信経路を電子的に通って、商人に送信されることと、
モバイルデバイスのユーザに少なくとも商人の名前および支払額を含む要求の説明を呈示することと、
ユーザから、要求に対する応答を受信することであって、応答が、ユーザによって入力されるセキュリティコードを含むことと、
要求に応じてセキュリティコードを含む応答をホストに送信することであって、応答が、セキュリティコードが正しいときに銀行カードを有する商人に支払いを承認するようにホストに要求することと、を含む、方法。
Supplementary notes 1. A method of authorizing payment using a mobile device,
Receiving a request to approve payment using a bank card having an associated bank card identifier from a host via the mobile device under control of the mobile device comprising executable instructions, the bank card identifier Is sent to the merchant electronically through a communication path that is different from the communication path used at the merchant location or to receive the request;
Presenting a description of the request to the user of the mobile device, including at least the merchant name and payment amount;
Receiving a response to the request from the user, the response including a security code entered by the user;
Sending a response including a security code to the host upon request, the response requesting the host to approve payment to a merchant with a bank card when the security code is correct; Method.

2.モバイルデバイスの場所を含む場所情報を決定することをさらに含み、場所が、承認された場所と比較され、ユーザからのセキュリティコードに対する要求を動作させること、または取引の不正リスクを識別することの少なくとも1つのために使用される、付記1に記載の方法。   2. Determining at least location information including the location of the mobile device, wherein the location is compared with the authorized location, operating a request for a security code from the user, or identifying fraud risk of the transaction The method according to appendix 1, used for one.

3.呈示することは、商人の名前と、支払いと関連付けられる取引に含まれる品目またはサービスの説明とを呈示することをさらに含む、付記1に記載の方法。   3. The method of claim 1, wherein presenting further comprises presenting a merchant name and a description of an item or service included in the transaction associated with the payment.

4.商人に提供された銀行カードの代用として電子支払い方式の選択をユーザから受信することであって、電子支払い方式が、商人への支払いを成立させることをさらに含み、応答を送信することは、電子支払い方式をホストに送信することを含む、付記1に記載の方法。   4). Receiving a selection of an electronic payment method from a user as a substitute for a bank card provided to the merchant, the electronic payment method further comprising establishing a payment to the merchant, and sending the response is electronic The method of claim 1, comprising sending a payment method to the host.

5.商人への支払いを成立させる銀行カードを含むかまたは除く追加の電子支払い方式のうちの1つ以上の選択をユーザから受信することをさらに含み、応答を送信することは、追加の電子支払い方式をホストに送信することを含む、付記1に記載の方法。   5. Further comprising receiving from the user a selection of one or more of the additional electronic payment methods including or excluding the bank card that establishes payment to the merchant, and sending the response includes the additional electronic payment method The method of claim 1, comprising sending to a host.

6.1つ以上のプロセッサで実行されるときに、
ホストからモバイルデバイスを介して、商人への支払いの提示から生じる支払いを承認する要求を、該要求を受信するために使用される銀行カードの処理経路とは異なる通信経路を使用して受信することと、
モバイルデバイスのユーザに少なくとも支払額を含む要求の説明を呈示することと、
ユーザから、要求に対する応答を受信することであって、応答が、要求の少なくとも承諾または拒絶を含むことと、
要求に対する回答として応答をホストに送信することであって、回答が、支払いの提示から生じる商人への支払いを承認することまたは拒絶することであることと、を含む行為を行うコンピュータ実行可能命令を記憶する、1つ以上のコンピュータ可読記憶媒体。
6. When executed on one or more processors,
Receiving a request from a host via a mobile device to approve a payment resulting from the presentation of payment to the merchant using a communication path that is different from the processing path of the bank card used to receive the request. When,
Presenting a description of the request, including at least the payment amount, to the user of the mobile device;
Receiving a response to the request from a user, the response including at least an acceptance or rejection of the request;
Sending a response to the host as an answer to the request, wherein the answer is to approve or deny payment to the merchant resulting from the presentation of the payment; One or more computer-readable storage media for storing.

7.要求は、少なくとも部分的に商人または支払額に基づいて選択される一意の識別子に対する要求を含み、一意の識別子が、支払いを承諾するためにユーザによって正確に入力されるべきコードを含む、付記6に記載の1つ以上のコンピュータ可読媒体。   7). The request includes a request for a unique identifier selected based at least in part on the merchant or payment amount, and the unique identifier includes a code that should be accurately entered by the user to authorize the payment. One or more computer-readable media according to claim 1.

8.行為は、
モバイルデバイスの場所を決定することと、
モバイルデバイスの場所をホストに送信することと、をさらに含み、要求は、商人の場所に対するモバイルデバイスの場所に少なくとも部分的に基づく、付記6に記載の1つ以上のコンピュータ可読媒体。
8). The act is
Determining the location of the mobile device,
The one or more computer-readable media of claim 6, further comprising: transmitting the mobile device location to the host, wherein the request is based at least in part on the location of the mobile device relative to the merchant location.

9.モバイルデバイスの場所を決定することは、全地球測位システム(GPS)または三角測量を使用して行われる、付記8に記載の1つ以上のコンピュータ可読媒体。   9. The one or more computer-readable media of claim 8, wherein determining the location of the mobile device is performed using a global positioning system (GPS) or triangulation.

10.呈示することは、支払いと関連付けられる取引に含まれる商人の識別子および品目またはサービスの説明を呈示することをさらに含む、付記6に記載の1つ以上のコンピュータ可読媒体。   10. The one or more computer-readable media of claim 6, wherein presenting further comprises presenting a merchant identifier and an item or service description included in the transaction associated with the payment.

11.要求は、第2の要求であり、行為は、第2の要求の前に第1の要求を受信することをさらに含み、モバイルデバイスが、閾値時間量より前に第1の要求に応答せず、第2の要求の受信の前に支払いの穏やかな拒否をもたらす、付記6に記載の1つ以上のコンピュータ可読媒体。   11. The request is a second request and the act further includes receiving the first request before the second request, and the mobile device does not respond to the first request before the threshold amount of time. The one or more computer-readable media of claim 6, wherein the one or more computer-readable media provide a gentle refusal of payment prior to receipt of the second request.

12.行為は、支払いを成立させるように選択のための追加の電子支払い方式をユーザに呈示することさらに含む、付記6に記載の1つ以上のコンピュータ可読媒体。   12 The one or more computer-readable media of claim 6, wherein the act further comprises presenting an additional electronic payment method for selection to the user to finalize the payment.

13.追加の電子支払い方式のうちの1つが、電子支払い方式と関連付けられる報酬を得るために、少なくとも部分的にそれぞれの電子支払い方式を商人と関連付ける規則に基づきユーザに対して予め選択される、付記12に記載の1つ以上のコンピュータ可読媒体。   13. Appendix 12 wherein one of the additional electronic payment methods is preselected for the user based on rules that at least partially associate each electronic payment method with a merchant to obtain a reward associated with the electronic payment method. One or more computer-readable media according to claim 1.

14.行為は、購入に対する応答を満たすように追加の電子支払い方式の選択をユーザから受信することをさらに含み、応答を送信することは、追加の電子支払い方式をホストに送信することを含む、付記6に記載の1つ以上のコンピュータ可読媒体。   14 The act further includes receiving a selection of an additional electronic payment method from the user to satisfy the response to the purchase, and sending the response includes transmitting the additional electronic payment method to the host. One or more computer-readable media according to claim 1.

15.支払いの提示は、最初の電子支払い方式と関連付けられ、行為は、処理されるときに、商人への支払いを集合的に成立させるそれぞれの電子支払い方式の資金の配分を受信することをさらに含む、付記14に記載の1つ以上のコンピュータ可読媒体。   15. The presentation of payment is associated with an initial electronic payment method, and the act further includes receiving an allocation of funds for each electronic payment method that collectively establishes payment to the merchant when processed. One or more computer-readable media according to appendix 14.

16.行為は、支払いの提示と関連付けられた電子支払い方式の代わりに、異なる電子支払い方式の選択をユーザから受信することをさらに含み、異なる電子支払い方式が、商人への支払いを成立させる、付記6に記載の1つ以上のコンピュータ可読媒体。   16. The act of appendix 6, wherein the act further includes receiving a selection of a different electronic payment method from the user instead of the electronic payment method associated with the presentation of the payment, wherein the different electronic payment method establishes the payment to the merchant. One or more computer-readable media as described.

17.支払いの提示は、最初の電子支払い方式と関連付けられ、行為は、商人への支払いを成立させる最初の電子支払い方式を含むかまたは除く追加の電子支払い方式を選択することをさらに含む、付記6に記載の1つ以上のコンピュータ可読媒体。   17. The presentation of payment is associated with an initial electronic payment method, and the act further includes selecting an additional electronic payment method that includes or excludes the initial electronic payment method that establishes the payment to the merchant. One or more computer-readable media as described.

18.
実行可能命令を有するモバイルデバイスの制御下で、モバイルデバイスで、ユーザから商人に提供される電子支払いを承認する要求を受信することであって、電子支払いが、要求を受信するために使用される銀行カードの処理経路とは異なる通信経路を使用して商人に提供されることと、
ユーザから、要求に対する応答を受信することであって、応答が、要求の少なくとも承諾または拒絶を含むことと、
要求に対する回答として応答をホストに送信することであって、回答が、支払いの提示から生じる商人への支払いを承認することまたは拒絶することであることと、を含む、方法。
18.
Receiving a request to approve an electronic payment provided by a user to a merchant at a mobile device under control of the mobile device having executable instructions, wherein the electronic payment is used to receive the request Being provided to the merchant using a different communication path than the bank card processing path,
Receiving a response to the request from a user, the response including at least an acceptance or rejection of the request;
Sending a response to the host as an answer to the request, the answer including authorizing or rejecting the merchant payment resulting from the presentation of the payment.

19.モバイルデバイスのユーザに少なくとも支払額および商人の表示を含む要求の説明を呈示することをさらに含む、付記18に記載の方法。   19. The method of claim 18 further comprising presenting a description of the request including at least a payment amount and a merchant indication to a user of the mobile device.

20.要求は、支払いを承諾するためにユーザによって正確に入力されるべきセキュリティコードに対する要求を含む、付記18に記載の方法。   20. The method of clause 18 wherein the request includes a request for a security code to be accurately entered by a user to authorize payment.

21.
実行可能命令を有する1つ以上のサーバの制御下で、商人からの支払いを承認する要求を受信することであって、支払いが、銀行カードを使用し、かつ取引の成立でユーザによって商人に提供され、要求が、少なくとも支払い識別子および金額を含むことと、
支払い識別子と関連付けられたユーザのモバイルデバイスを識別することと、
少なくとも部分的に金額に基づきユーザに課す承認要件を決定することと、
承認要件を含む承認メッセージをモバイルデバイスに送信することであって、承認メッセージが、ユーザが支払いを承認する要求を承諾するかまたは拒絶することを可能にすることと、
少なくとも部分的に承認メッセージの送信に基づき、モバイルデバイスを介してユーザからのユーザ応答を受信することであって、応答が、商人に支払いを送信するために使用されるアプリケーションとは異なる支払いアプリケーションとの通信から受信されることと、
少なくとも部分的にユーザ応答に基づき、承認要件が満たされるかどうかを決定することと、
商人への支払いの承諾または拒絶のうちの1つを含む応答を商人に送信することであって、承諾が、承認要件の達成に左右されることと、
ユーザの代理として支払額を商人のアカウントに転送することと、を含む、方法。
21.
Receiving a request to approve a payment from a merchant under the control of one or more servers having executable instructions, wherein the payment is provided to the merchant by the user using a bank card and the closing of the transaction. The request includes at least a payment identifier and an amount;
Identifying the user's mobile device associated with the payment identifier;
Determining authorization requirements to be imposed on users based at least in part on the amount,
Sending an approval message containing approval requirements to the mobile device, which allows the user to accept or reject the request to approve the payment;
A payment application that receives a user response from a user via a mobile device, based at least in part on sending an authorization message, wherein the response is different from the application used to send the payment to the merchant Being received from
Determining whether approval requirements are met, based at least in part on user response;
Sending a response to the merchant that includes one of accepting or rejecting the merchant's payment, where the acceptance depends on meeting approval requirements;
Transferring the payment amount on behalf of the user to the merchant's account.

22.承認メッセージは、承認要件を満たす個人識別番号(PIN)または生体データのうちの少なくとも1つに対する要求を含む、付記21に記載の方法。   22. The method of claim 21, wherein the approval message includes a request for at least one of a personal identification number (PIN) or biometric data that satisfies the approval requirements.

23.ユーザ応答は、支払い識別子を有する銀行カード以外の電子支払い方式の選択を含み、電子支払い方式が、取引のために商人に支払われるべき金額の少なくとも一部分を満たすために使用される、付記21に記載の方法。   23. The user response includes a selection of an electronic payment method other than a bank card having a payment identifier, wherein the electronic payment method is used to satisfy at least a portion of the amount to be paid to the merchant for the transaction. the method of.

24.承認要件を決定する少なくとも1つの規則を適用することをさらに含む、付記21に記載の方法。   24. The method of claim 21, further comprising applying at least one rule for determining approval requirements.

25.少なくとも1つの規則は、少なくとも部分的にユーザからの入力に基づいて生成される、付記24に記載の方法。   25. The method of claim 24, wherein the at least one rule is generated based at least in part on input from a user.

26.
実行可能命令を有する1つ以上のサーバの制御下で、
商人からの支払いを承認する要求を受信することであって、支払いが、ユーザによって取引の成立で商人に提供され、要求が、少なくとも支払い識別子および金額を含むことと、
支払い識別子と関連付けられたユーザのモバイルデバイスを識別することと、
少なくとも部分的に金額に基づきユーザに課す承認要件を決定することと、
承認要件を含む承認メッセージをモバイルデバイスに送信することであって、承認メッセージが、ユーザが支払いを承認する要求を承諾するかまたは拒絶することを可能にすることと、
少なくとも部分的に承認メッセージの送信に基づき、モバイルデバイスを介してユーザからのユーザ応答を受信することと、
少なくとも部分的にユーザ応答に基づき、承認要件が満たされるかどうかを決定することと、
商人に、
承認要件が満たされ、ユーザが支払いを承認する要求を承諾するときに、商人への支払いの承諾、
または商人への支払いの拒絶のうちの1つを含む応答を送信することと、を含む、方法。
26.
Under the control of one or more servers having executable instructions,
Receiving a request to approve a payment from the merchant, wherein the payment is provided to the merchant by the user upon completion of the transaction, and the request includes at least a payment identifier and an amount;
Identifying the user's mobile device associated with the payment identifier;
Determining authorization requirements to be imposed on users based at least in part on the amount,
Sending an approval message containing approval requirements to the mobile device, which allows the user to accept or reject the request to approve the payment;
Receiving a user response from a user via a mobile device based at least in part on sending an approval message;
Determining whether approval requirements are met, based at least in part on user response;
To the merchant,
Accepting payment to the merchant when authorization requirements are met and the user accepts the request to approve the payment,
Or sending a response including one of the refusals to pay the merchant.

27.ユーザの代理として支払額を商人のアカウントに転送することをさらに含む、付記26に記載の方法。   27. 27. The method of clause 26, further comprising transferring the payment amount on behalf of the user to the merchant account.

28.ユーザから応答を受信することは、商人に支払いを送信するために使用されるアプリケーションとは異なる支払いアプリケーションと通信して行われる、付記26に記載の方法。   28. 27. The method of clause 26, wherein receiving the response from the user is done in communication with a payment application different from the application used to send the payment to the merchant.

29.ユーザ要求は、承認要件を満たすための個人識別番号(PIN)または生体データのうちの少なくとも1つを含む、付記26に記載の方法。   29. 27. The method of clause 26, wherein the user request includes at least one of a personal identification number (PIN) or biometric data to satisfy the approval requirement.

30.承認要件を決定する少なくとも1つの規則を生成することをさらに含み、少なくとも1つの規則が、少なくとも部分的にユーザからのユーザ入力に基づいて生成される、付記26に記載の方法。   30. 27. The method of clause 26, further comprising generating at least one rule for determining approval requirements, wherein the at least one rule is generated based at least in part on user input from a user.

31.規則は、指定された期間の閾値支払額と関連するホワイトリストに掲載かまたはブラックリストに掲載の商人、カテゴリ、または分野のうちの少なくとも1つを含む、付記30に記載の方法。   31. The method of claim 30, wherein the rules include at least one of a whitelisted or blacklisted merchant, category, or field associated with a threshold payment amount for a specified period of time.

32.
ユーザのモバイルデバイスの場所を要求することと、
モバイルデバイスの場所を受信することと、をさらに含み、
場所情報は、商人への支払いと関連付けられる承認要件または不正リスクを決定するために使用される、付記26に記載の方法。
32.
Requesting the user's mobile device location;
Receiving a location of the mobile device; and
27. The method of clause 26, wherein the location information is used to determine authorization requirements or fraud risk associated with merchant payment.

33.ユーザ応答は、支払い識別子を有する支払い方式以外の電子支払い方式の選択を含み、電子支払い方式が、取引のために商人に支払われるべき金額の少なくとも一部分を満たすために使用される、付記26に記載の方法。   33. 27. The user response includes a selection of an electronic payment method other than a payment method having a payment identifier, wherein the electronic payment method is used to satisfy at least a portion of the amount to be paid to the merchant for the transaction. the method of.

34.承認メッセージは、第2の承認メッセージであり、行為は、
第2の承認メッセージより前に第1の承認メッセージをユーザに送信することと、
第2の承認メッセージをユーザに送信するより前に、支払いを少なくとも一時的に拒絶する穏やかな拒否通知を商人に送信することと、をさらに含む、付記26に記載の方法。
34. The approval message is the second approval message, and the action is
Sending the first approval message to the user prior to the second approval message;
27. The method of clause 26, further comprising: sending a gentle rejection notice to the merchant that at least temporarily rejects the payment prior to sending the second approval message to the user.

35.
ユーザが、少なくとも部分的に所定の規則に基づき、現在の時間に承認メッセージを受信することができないかどうかを決定することと、
ユーザが、少なくとも部分的に所定の規則に基づき、現在の時間に承認メッセージを受信することができないときに、ユーザへの承認メッセージの送信を遅延させることと、をさらに含む、付記26に記載の方法。
35.
Determining whether the user is unable to receive an approval message at the current time based at least in part on predetermined rules;
The user further comprising: delaying transmission of the approval message to the user when the user is unable to receive the approval message at the current time based at least in part on a predetermined rule. Method.

36.1つ以上のプロセッサで実行されるときに、
商人からの支払いを承認する要求を受信することであって、要求が、少なくとも支払い識別子および金額を含むことと、
支払い識別子と関連付けられるユーザを識別することと、
少なくとも部分的に金額に基づきユーザに課す承認要件を決定することと、
承認メッセージをユーザに送信することであって、承認メッセージが、少なくとも金額を含み、承認要件が、ユーザが支払いを承認する要求を承諾するかまたは拒絶することを可能にすることと、
少なくとも部分的に承認メッセージの送信に基づき、モバイルデバイスを介してユーザからのユーザ応答を受信することと、
少なくとも部分的にユーザ応答に基づき、承認要件が満たされるかどうかを決定することと、
商人への支払いの承諾または拒絶のうちの1つを含む応答を商人に送信することであって、承諾が、承認要件の達成に左右されることと、を含む行為を行うコンピュータ実行可能命令を記憶する、1つ以上のコンピュータ可読記憶媒体。
36. When executed on one or more processors,
Receiving a request to approve payment from a merchant, the request including at least a payment identifier and an amount;
Identifying the user associated with the payment identifier;
Determining authorization requirements to be imposed on users based at least in part on the amount,
Sending an approval message to the user, wherein the approval message includes at least an amount and the approval requirement allows the user to accept or reject the request to approve the payment;
Receiving a user response from a user via a mobile device based at least in part on sending an approval message;
Determining whether approval requirements are met, based at least in part on user response;
Sending a response to the merchant that includes one of accepting or rejecting the merchant's payment, wherein the acceptance depends on meeting the approval requirements, One or more computer-readable storage media for storing.

37.承認メッセージは、第2の承認メッセージであり、行為は、
第2の承認メッセージより前に第1の承認メッセージをユーザに送信することと、
第2の承認メッセージをユーザに送信するより前に、支払いを少なくとも一時的に拒絶する穏やかな拒否通知を商人に送信することと、をさらに含む、付記36に記載の1つ以上のコンピュータ可読媒体。
37. The approval message is the second approval message, and the action is
Sending the first approval message to the user prior to the second approval message;
37. The one or more computer-readable media of claim 36, further comprising: sending a gentle rejection notice to the merchant that at least temporarily rejects the payment prior to sending the second approval message to the user. .

38.行為は、
ユーザが、少なくとも部分的に所定の規則に基づき、現在の時間に承認メッセージを受信することができないかどうかを決定することと、
ユーザが、少なくとも部分的に所定の規則に基づき、現在の時間に承認メッセージを受信することができないときに、ユーザへの承認メッセージの送信を遅延させることと、をさらに含む、付記36に記載の1つ以上のコンピュータ可読媒体。
38. The act is
Determining whether the user is unable to receive an approval message at the current time based at least in part on predetermined rules;
37. The appendix 36, further comprising: delaying transmission of the approval message to the user when the user is unable to receive the approval message at the current time based at least in part on a predetermined rule. One or more computer readable media.

39.ユーザ応答は、支払い識別子と関連付けられた初期の電子支払い方式とは異なる第2の電子支払い方式の選択を含み、行為は、第2の電子支払い方式を使用して商人への支払いを行うことをさらに含む、付記36に記載の1つ以上のコンピュータ可読媒体。   39. The user response includes a selection of a second electronic payment method that is different from the initial electronic payment method associated with the payment identifier, and the act is to make a payment to the merchant using the second electronic payment method. The one or more computer readable media of claim 36, further comprising:

40.承認要件は、少なくとも部分的に支払額および商人に基づき認証プロセスを選択する規則に基づき、認証プロセスのうちの少なくとも1つの選択は、ユーザ応答で個人識別番号(PIN)を提供するようにユーザに要求することを含む、付記36に記載の1つ以上のコンピュータ可読媒体。   40. The authorization requirement is based on rules that select an authentication process based at least in part on the payment amount and merchant, and the selection of at least one of the authentication processes prompts the user to provide a personal identification number (PIN) in the user response. 37. One or more computer readable media of clause 36, including requesting.

結論
主題が構造的特徴および/または方法論的行為に特有の言葉で記載されたが、添付の特許請求の範囲に定義される主題は、必ずしも記載された特定の特徴または行為に限定されないことが理解されるべきである。むしろ、特定の特徴および行為は、特許請求の範囲を実践する例示的な形態として開示される。
Conclusion Although the subject matter has been described in language specific to structural features and / or methodological acts, it is understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. It should be. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims.

Claims (15)

  1. コンピュータ実行可能命令を記憶する1つまたは複数のコンピュータ可読記憶媒体であって、前記コンピュータ実行可能命令は、1つまたは複数のプロセッサにより実行されると、前記プロセッサに、
    ホストからモバイルデバイスを介して、商人への支払いを承認するための要求を、受信することと、
    前記モバイルデバイスのユーザに少なくとも前記支払いの額を含む前記要求の詳細を提示することであって、前記要求の詳細は、支払い承認コードのプロンプトとともに提示され、前記支払い承認コードは、少なくとも部分的には前記商人の識別子または前記商人のカテゴリに基づいて複数の支払い承認コードから予め選択される、提示することと、
    前記ユーザから、前記要求への応答を受信することであって、前記応答が、少なくとも部分的に前記支払い承認コードの正しい入力に基づいて前記要求の承諾を示す、受信することと、
    前記要求に対する回答として前記応答を前記ホストに送信することであって、前記回答が、前記商人への前記支払いを承認することである、送信することと、
    前記モバイルデバイスの場所を前記ホストに送信することであって、前記ホストは、前記支払いが遠隔取引または実店舗取引に対するものか判定し、前記遠隔取引の場合は前記モバイルデバイスの前記場所と既知および/または頻度が高い場所との比較に基づいて前記応答を調節し前記実店舗取引の場合は前記モバイルデバイスの前記場所と前記商人の場所との比較に基づいて前記応答を調節する、送信することと
    を含む行為を行わせることを特徴とする1つまたは複数のコンピュータ可読記憶媒体。
    One or more computer-readable storage media storing computer-executable instructions, wherein the computer-executable instructions when executed by one or more processors include:
    Receiving a request from the host via the mobile device to authorize payment to the merchant;
    Presenting the request details including at least the payment amount to a user of the mobile device, wherein the request details are presented with a prompt for a payment authorization code, wherein the payment authorization code is at least partially Presenting, preselected from a plurality of payment authorization codes based on the merchant identifier or the merchant category;
    Receiving a response to the request from the user, wherein the response indicates acceptance of the request based at least in part on a correct entry of the payment authorization code;
    Sending the response to the host as an answer to the request, wherein the answer is authorizing the payment to the merchant;
    Sending the location of the mobile device to the host, wherein the host determines whether the payment is for a remote transaction or a physical store transaction, and in the case of the remote transaction, the location of the mobile device is known and Adjusting the response based on a comparison with a high frequency location, and adjusting the response based on a comparison between the location of the mobile device and the merchant location in the case of a real store transaction One or more computer-readable storage media characterized by causing an action including:
  2. 前記要求は、第2の要求であり、前記行為は、前記第2の要求より前に第1の要求を受信することをさらに含み、前記モバイルデバイスが、閾値の時間より前に前記第1の要求に応答せず、前記第2の要求の前記受信より前に前記支払いの穏やかな拒否をもたらすことを特徴とする請求項1に記載の1つまたは複数のコンピュータ可読記憶媒体。 The request is a second request, and the act further includes receiving a first request prior to the second request, wherein the mobile device is configured to receive the first request prior to a threshold time. One or more computer-readable storage media as recited in claim 1, wherein the one or more computer-readable storage media of claim 1 does not respond to a request and results in a gentle refusal of the payment prior to the receipt of the second request.
  3. 前記行為は、前記要求に対する前記応答を満たすように追加の電子支払い方式の選択を前記ユーザから受信することをさらに含み、前記応答を送信することは、前記追加の電子支払い方式を前記ホストに送信することを含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ可読記憶媒体。 The act further comprises receiving a selection of an additional electronic payment scheme from the user to satisfy the response to the request, wherein transmitting the response transmits the additional electronic payment scheme to the host. One or more computer readable storage media as recited in claim 1, wherein:
  4. 前記支払いの提示は、最初の電子支払い方式と関連付けられ、前記行為は、処理される場合に、前記商人への前記支払いを集合的に成立させる前記それぞれの電子支払い方式の資金の配分を受信することをさらに含むことを特徴とする請求項3に記載の1つまたは複数のコンピュータ可読記憶媒体。 The presentation of the payment is associated with an initial electronic payment method, and the action receives a distribution of funds for the respective electronic payment method that collectively establish the payment to the merchant when processed. One or more computer-readable storage media as recited in claim 3, further comprising:
  5. 前記行為は、前記支払いの提示と関連付けられた電子支払い方式の代わりに、異なる電子支払い方式の選択を前記ユーザから受信することをさらに含み、前記異なる電子支払い方式が、前記商人への前記支払いを成立させることを特徴とする請求項1に記載の1つまたは複数のコンピュータ可読記憶媒体。 The act further comprises receiving a selection of a different electronic payment method from the user instead of an electronic payment method associated with the presentation of the payment, the different electronic payment method receiving the payment to the merchant. One or more computer-readable storage media as recited in claim 1, wherein the storage medium is established.
  6. コンピュータ実行可能命令を有する1つ以上のサーバの制御下において、
    商人から、支払いを承認する要求を受信するステップであって、前記支払いが、ユーザによって取引の成立で前記商人に提供され、前記要求が、少なくとも支払い識別子および金額を含む、ステップと、
    予め定められた規則に基づいて、前記要求に対して承諾または拒否を含む応答を送信するかどうかを決定するステップと、
    予め定められた規則に基づいて、前記要求に対して承諾または拒否を含む応答を送信することを決定した場合に、決定された前記承諾または前記拒否を含む応答を送信するステップと、
    前記支払い識別子と関連付けられた前記ユーザのモバイルデバイスを識別するステップと、
    少なくとも部分的に前記金額に基づき前記ユーザに課す承認要件を決定するステップと、
    前記承認要件を含む承認メッセージを前記モバイルデバイスに送信するステップであって、前記承認メッセージが、前記ユーザが前記支払いを承認する前記要求を承諾することを可能にし、前記承認メッセージは、前記ユーザの前記モバイルデバイスにおいて支払い承認コードのプロンプトとともに提示される前記要求の詳細を含み、前記支払い承認コードは、少なくとも部分的には前記商人の識別子または前記商人のカテゴリに基づいて複数の支払い承認コードから予め選択される、ステップと、
    少なくとも部分的に前記承認メッセージの前記送信に基づき、前記モバイルデバイスを介して前記ユーザからのユーザ応答を受信するステップであって、前記ユーザ応答が、少なくとも部分的に前記支払い承認コードの正しい入力に基づいて前記要求の承諾を示す、ステップと、
    少なくとも部分的に前記ユーザ応答に基づき、前記承認要件が満たされるかどうかを決定するステップと、
    前記商人に、前記承認要件が満たされ、前記ユーザが前記支払いを承認する前記要求を承諾する場合に、前記商人への前記支払いの承諾を含む応答を送信するステップであって、前記応答を送信するステップは、
    前記ユーザの前記モバイルデバイスの場所を要求するステップと、
    前記モバイルデバイスの前記場所を受信するステップと、
    前記支払いが遠隔取引または実店舗取引に対するものか判定するステップと、
    前記遠隔取引の場合は前記モバイルデバイスの前記場所と既知および/または頻度が高い場所との比較に基づいて前記応答を調節するステップと、
    前記実店舗取引の場合は前記モバイルデバイスの前記場所と前記商人の場所との比較に基づいて前記応答を調節するステップと
    を含む、ステップと
    を備えたことを特徴とする方法。
    Under control of one or more servers having computer- executable instructions,
    Receiving a request from a merchant to approve a payment, wherein the payment is provided to the merchant by a user upon completion of a transaction, the request including at least a payment identifier and an amount;
    Determining whether to send a response including acceptance or rejection to the request based on predetermined rules;
    Transmitting a response including the determined acceptance or rejection when it is determined to transmit a response including acceptance or rejection to the request based on predetermined rules;
    Identifying the user's mobile device associated with the payment identifier;
    Determining approval requirements to be imposed on the user based at least in part on the amount;
    Sending an approval message including the approval requirement to the mobile device, the approval message allowing the user to approve the request to approve the payment, the approval message comprising: Including details of the request presented with a payment authorization code prompt at the mobile device, wherein the payment authorization code is pre-determined from a plurality of payment authorization codes based at least in part on the merchant identifier or the merchant category. Selected step, and
    Receiving a user response from the user via the mobile device based at least in part on the transmission of the authorization message, the user response at least partially in a correct entry of the payment authorization code. Indicating acceptance of said request based on, and
    Determining whether the approval requirement is satisfied based at least in part on the user response;
    Sending to the merchant a response including acceptance of the payment to the merchant if the approval requirements are met and the user accepts the request to approve the payment , the response being sent The steps to do are
    Requesting the user's location of the mobile device;
    Receiving the location of the mobile device;
    Determining whether the payment is for a remote transaction or a physical store transaction;
    Adjusting the response based on a comparison of the location of the mobile device with a known and / or more frequent location in the case of the remote transaction;
    Adjusting the response based on a comparison between the location of the mobile device and the merchant location in the case of the physical store transaction;
    A method comprising the steps of :
  7. 前記ユーザから前記応答を受信することは、前記商人に前記支払いを送信するために使用されるアプリケーションとは異なる支払いアプリケーションと通信して行われることを特徴とする請求項6に記載の方法。   The method of claim 6, wherein receiving the response from the user is performed in communication with a payment application different from an application used to send the payment to the merchant.
  8. 前記ユーザ応答は、前記承認要件を満たすための個人識別番号(PIN)または生体データのうちの少なくとも1つを含むことを特徴とする請求項6に記載の方法。   The method of claim 6, wherein the user response includes at least one of a personal identification number (PIN) or biometric data to satisfy the approval requirement.
  9. 前記承認要件を決定する少なくとも1つの規則を生成するステップをさらに備え、前記少なくとも1つの規則が、少なくとも部分的に前記ユーザからのユーザ入力に基づいて生成されることを特徴とする請求項6に記載の方法。   7. The method of claim 6, further comprising generating at least one rule for determining the approval requirement, wherein the at least one rule is generated based at least in part on user input from the user. The method described.
  10. 記場所は、前記商人への前記支払いと関連付けられる前記承認要件または不正リスクを決定するために使用されることを特徴とする請求項6に記載の方法。 Before Symbol Location method according to claim 6, characterized in that it is used to determine the said authorization requirements or fraud risk associated with payment to the merchant.
  11. 前記ユーザ応答は、前記支払い識別子を有する支払い方式以外の電子支払い方式の選択を含み、前記電子支払い方式が、前記取引のために前記商人に支払われるべき前記金額の少なくとも一部分を満たすために使用されることを特徴とする請求項6に記載の方法。   The user response includes a selection of an electronic payment method other than a payment method having the payment identifier, and the electronic payment method is used to satisfy at least a portion of the amount to be paid to the merchant for the transaction. The method according to claim 6.
  12. 前記承認メッセージは、第2の承認メッセージであり、前記方法は、
    前記第2の承認メッセージより前に第1の承認メッセージを前記ユーザに送信するステップと、
    前記第2の承認メッセージを前記ユーザに送信する前に、前記支払いを少なくとも一時的に拒絶する穏やかな拒否通知を前記商人に送信するステップと
    をさらに備えたことを特徴とする請求項6に記載の方法。
    The approval message is a second approval message, and the method includes:
    Sending a first approval message to the user prior to the second approval message;
    7. The method of claim 6, further comprising: sending a gentle rejection notice to the merchant that at least temporarily rejects the payment before sending the second approval message to the user. the method of.
  13. 前記ユーザが、少なくとも部分的に予め定められた規則に基づき、現在の時間に前記承認メッセージを受信することができないかどうかを決定するステップと、
    前記ユーザが、少なくとも部分的に前記予め定められた規則に基づき、前記現在の時間に前記承認メッセージを受信することができない場合に、前記ユーザへの前記承認メッセージの送信を遅延させるステップ
    をさらに備えたことを特徴とする請求項6に記載の方法。
    Determining whether the user is unable to receive the approval message at a current time based at least in part on predetermined rules;
    The user, based at least in part on the predetermined rule, wherein when it is not possible to receive the acknowledgment message to the current time, further delaying the transmission of the approval message to the user The method according to claim 6, further comprising:
  14. 請求項6から13のいずれか一項に記載の方法を実行するためのコンピュータ実行可能命令を備えたことを特徴とするコンピュータ可読記憶媒体。   A computer-readable storage medium comprising computer-executable instructions for performing the method of any one of claims 6-13.
  15. 請求項6から13のいずれか一項に記載の方法を実行するように構成されたことを特徴とするシステム。   14. A system configured to perform the method of any one of claims 6-13.
JP2016037781A 2011-06-27 2016-02-29 Payment selection and approval by mobile devices Active JP6254204B2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/170,121 2011-06-27
US13/170,121 US10055740B2 (en) 2011-06-27 2011-06-27 Payment selection and authorization
US13/170,144 US20120330788A1 (en) 2011-06-27 2011-06-27 Payment selection and authorization by a mobile device
US13/170,144 2011-06-27

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2014518926 Division 2012-06-26

Publications (2)

Publication Number Publication Date
JP2016131033A JP2016131033A (en) 2016-07-21
JP6254204B2 true JP6254204B2 (en) 2017-12-27

Family

ID=47424510

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2014518926A Active JP5957524B2 (en) 2011-06-27 2012-06-26 Payment selection and approval by mobile devices
JP2016037781A Active JP6254204B2 (en) 2011-06-27 2016-02-29 Payment selection and approval by mobile devices

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2014518926A Active JP5957524B2 (en) 2011-06-27 2012-06-26 Payment selection and approval by mobile devices

Country Status (5)

Country Link
EP (1) EP2724523A4 (en)
JP (2) JP5957524B2 (en)
CN (1) CN103765861B (en)
CA (1) CA2839150C (en)
WO (1) WO2013003372A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7744288B2 (en) 2007-12-11 2010-06-29 Adc Telecommunications, Inc. Hardened fiber optic connector compatible with hardened and non-hardened fiber optic adapters
US7805044B2 (en) 2004-11-03 2010-09-28 Adc Telecommunications, Inc. Fiber drop terminal
US8755663B2 (en) 2010-10-28 2014-06-17 Corning Cable Systems Llc Impact resistant fiber optic enclosures and related methods
US8770862B2 (en) 2007-01-24 2014-07-08 Adc Telecommunications, Inc. Hardened fiber optic connector
US8873926B2 (en) 2012-04-26 2014-10-28 Corning Cable Systems Llc Fiber optic enclosures employing clamping assemblies for strain relief of cables, and related assemblies and methods

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9082119B2 (en) 2012-10-17 2015-07-14 Royal Bank of Canada. Virtualization and secure processing of data
CN104703124B (en) * 2013-12-06 2018-10-16 阿里巴巴集团控股有限公司 Object information preparation method and system
CN105450583B (en) 2014-07-03 2019-07-05 阿里巴巴集团控股有限公司 A kind of method and device of authentification of message
CN105446992A (en) 2014-07-08 2016-03-30 阿里巴巴集团控股有限公司 Method and device for building goods object recovery information database and determining value information
CN105450411B (en) 2014-08-14 2019-01-08 阿里巴巴集团控股有限公司 The method, apparatus and system of authentication are carried out using card feature
CN105354190A (en) * 2014-08-18 2016-02-24 阿里巴巴集团控股有限公司 Numerical information transfer method and apparatus
CN105590211B (en) * 2014-10-21 2019-11-15 腾讯科技(深圳)有限公司 A kind of method, apparatus and system of data transfer
CN105719183A (en) 2014-12-03 2016-06-29 阿里巴巴集团控股有限公司 Directional transfer method and apparatus
CN105654293B (en) * 2014-12-03 2020-01-17 阿里巴巴集团控股有限公司 Payment method and device
CN105869043A (en) 2015-01-19 2016-08-17 阿里巴巴集团控股有限公司 Disperse hot spot database account transfer-in and transfer-out accounting method and device
US20160210626A1 (en) * 2015-01-19 2016-07-21 Royal Bank Of Canada Secure processing of electronic payments
CN105989467A (en) 2015-02-03 2016-10-05 阿里巴巴集团控股有限公司 Wireless payment method, apparatus, vehicle ride fee check method and system
CN106570009B (en) 2015-10-09 2020-07-28 阿里巴巴集团控股有限公司 Navigation category updating method and device
EP3179431A1 (en) * 2015-12-11 2017-06-14 Mastercard International Incorporated User authentication for transactions
EP3179432A1 (en) * 2015-12-11 2017-06-14 Mastercard International Incorporated Delegation of transactions
CN106651379A (en) * 2016-11-17 2017-05-10 北京小米移动软件有限公司 Payment method and device
WO2019108130A1 (en) * 2017-11-29 2019-06-06 Mastercard Asia/Pacific Pte. Ltd. A payment transaction system for processing a tokenized transaction over a domestic switch

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI108813B (en) * 1999-03-08 2002-03-28 Sonera Smarttrust Oy Method and system in the communication system
WO2002007110A2 (en) * 2000-07-17 2002-01-24 Connell Richard O System and methods of validating an authorized user of a payment card and authorization of a payment card transaction
JP2002092320A (en) * 2000-09-14 2002-03-29 Ntt Electornics Corp Electronic settling system, electronic settling method, and portable telephone having electronic settling function
JP2003168063A (en) * 2001-11-30 2003-06-13 Hitachi Ltd Method and system for approving payment in card payment method
JP2004110352A (en) * 2002-09-18 2004-04-08 Hitachi Software Eng Co Ltd Credit card settlement service system
JP2005141503A (en) * 2003-11-06 2005-06-02 Nec Computertechno Ltd System and method for charge settlement, and recording medium
JP2005174207A (en) * 2003-12-15 2005-06-30 Nippon Shinpan Co Ltd Server with settlement check function, and settlement check method
JP2006127174A (en) * 2004-10-29 2006-05-18 Hitachi Omron Terminal Solutions Corp Personal authentication system in credit settlement
US7357310B2 (en) * 2005-03-11 2008-04-15 Gerry Calabrese Mobile phone charge card notification and authorization method
JP5172240B2 (en) * 2007-08-09 2013-03-27 株式会社日本総合研究所 Electronic commerce system and computer program
US20090254479A1 (en) * 2008-04-02 2009-10-08 Pharris Dennis J Transaction server configured to authorize payment transactions using mobile telephone devices
US8244643B2 (en) * 2008-11-08 2012-08-14 Fonwallet Transaction Solutions, Inc. System and method for processing financial transaction data using an intermediary service
WO2011040401A1 (en) * 2009-09-30 2011-04-07 楽天株式会社 Credit card fraud prevention system

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7805044B2 (en) 2004-11-03 2010-09-28 Adc Telecommunications, Inc. Fiber drop terminal
US8770862B2 (en) 2007-01-24 2014-07-08 Adc Telecommunications, Inc. Hardened fiber optic connector
US10877224B2 (en) 2007-01-24 2020-12-29 Commscope Technologies Llc Fiber optic adapter
US8202008B2 (en) 2007-12-11 2012-06-19 Adc Telecommunications, Inc. Hardened fiber optic connection system with multiple configurations
US8414196B2 (en) 2007-12-11 2013-04-09 Adc Telecommunications, Inc. Optical fiber connection system with locking member
US7744288B2 (en) 2007-12-11 2010-06-29 Adc Telecommunications, Inc. Hardened fiber optic connector compatible with hardened and non-hardened fiber optic adapters
US7959361B2 (en) 2007-12-11 2011-06-14 Adc Telecommunications, Inc. Hardened fiber optic connection system
US8755663B2 (en) 2010-10-28 2014-06-17 Corning Cable Systems Llc Impact resistant fiber optic enclosures and related methods
US8873926B2 (en) 2012-04-26 2014-10-28 Corning Cable Systems Llc Fiber optic enclosures employing clamping assemblies for strain relief of cables, and related assemblies and methods

Also Published As

Publication number Publication date
JP2014522022A (en) 2014-08-28
EP2724523A1 (en) 2014-04-30
CN103765861B (en) 2016-08-17
EP2724523A4 (en) 2014-12-03
CN103765861A (en) 2014-04-30
CA2839150A1 (en) 2013-01-03
JP5957524B2 (en) 2016-07-27
WO2013003372A1 (en) 2013-01-03
JP2016131033A (en) 2016-07-21
CA2839150C (en) 2018-02-13

Similar Documents

Publication Publication Date Title
US10692076B2 (en) Device pairing via trusted intermediary
EP3405862B1 (en) Network node authentication
US10318948B2 (en) Cloud-based application security
US10748147B2 (en) Adaptive authentication options
US20190102776A1 (en) Methods and systems for using physical payment cards in secure e-commerce transactions
US10785212B2 (en) Automated access data provisioning
US20190188677A1 (en) Enrollment and registration of a device in a mobile commerce system
US20180240115A1 (en) Methods and systems for payments assurance
US20190188607A1 (en) Mobile commercial systems and methods
US20180357637A1 (en) Authentication token for wallet based transactions
JP2018200712A (en) Network token system
CA2961515C (en) Systems and methods for providing risk based decisioning service to a merchant
US20200226568A1 (en) Marketing messages in mobile commerce
US20190347646A1 (en) Nfc mobile wallet processing systems and methods
RU2713703C2 (en) Advance authorization of digital requests
US9530125B2 (en) Method and system for secure mobile payment transactions
US10366212B2 (en) Verification system for secure transmission in a distributed processing network
US9390412B2 (en) Dynamic point of sale system integrated with reader device
US20180089662A1 (en) Method of processing payment transactions
US9530129B2 (en) Secure authentication and payment system
US8924290B2 (en) Method and apparatus enabling improved protection of consumer information in electronic transactions
JP5575935B2 (en) System and method for validating financial instruments
JP5696253B2 (en) Allow real-time payment
US20180293569A1 (en) Method and system for controlling access to a financial account
US20180012226A1 (en) Methods for risk management in payment device system

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170327

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170418

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170718

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20171031

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171129

R150 Certificate of patent or registration of utility model

Ref document number: 6254204

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250