US20160078428A1 - Pairing electronic wallet with specified merchants - Google Patents

Pairing electronic wallet with specified merchants Download PDF

Info

Publication number
US20160078428A1
US20160078428A1 US14/485,139 US201414485139A US2016078428A1 US 20160078428 A1 US20160078428 A1 US 20160078428A1 US 201414485139 A US201414485139 A US 201414485139A US 2016078428 A1 US2016078428 A1 US 2016078428A1
Authority
US
United States
Prior art keywords
wallet
merchant
cardholder
token
holder
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.)
Abandoned
Application number
US14/485,139
Inventor
Scott Moser
Amyn Mohamed Dhala
David James Lim
Ryan Bartholomew Joseph Crowe
Nathaniel David Byrd
Eric Ray Kitchen
Adam David Gluck
Prashant Sharma
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mastercard International Inc
Original Assignee
Mastercard International Inc
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 US37295510P priority Critical
Priority to US201161468847P priority
Application filed by Mastercard International Inc filed Critical Mastercard International Inc
Priority to US14/485,139 priority patent/US20160078428A1/en
Assigned to MASTERCARD INTERNATIONAL INCORPORATED reassignment MASTERCARD INTERNATIONAL INCORPORATED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BYRD, Nathaniel David, GLUCK, ADAM DAVID, KITCHEN, ERIC RAY, SHARMA, Prashant, CROWE, RYAN BARTHOLOMEW JOSEPH, DHALA, AMYN MOHAMED, LIM, DAVID JAMES, MOSER, SCOTT
Priority claimed from PCT/US2015/048102 external-priority patent/WO2016040070A2/en
Publication of US20160078428A1 publication Critical patent/US20160078428A1/en
Application status is Abandoned legal-status Critical

Links

Images

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/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 transaction
    • 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/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • 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/22Payment schemes or models
    • G06Q20/227Payment schemes or models characterized in that multiple accounts are available to the payer
    • 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
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223Realising banking transactions through 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/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/351Virtual cards
    • 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
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
    • 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
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
    • G06Q20/363Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes with the personal data files for a user
    • 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
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes involving intelligent token, e.g. electronic purse
    • 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
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes involving intelligent token, e.g. electronic purse
    • G06Q20/3674Payment architectures, schemes or protocols characterised by the use of specific devices using electronic wallets or electronic money safes involving intelligent token, e.g. electronic purse involving authentication
    • 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
    • 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
    • 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 number [PIN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to network resources

Abstract

A system and method for facilitating use of a digital electronic wallet by a cardholder for cashless transactions. The method comprises receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein an electronic representation of at least one payment device usable to fund a cashless transaction, and verifying the cardholder's identity. Thereafter, facilitating a communication between the first cardholder and the first wallet holder to record consent by the first cardholder to share wallet information with the first merchant. The present disclosure further comprises receiving from the first wallet holder authorization to generate a wallet token usable for acquiring wallet information on behalf of the first merchant, using the first digital wallet as selected by the first cardholder, and preparing a merchant token corresponding to the wallet token. The merchant token is provided to the first merchant, for presentation to access wallet information, including payment card information on a cashless transaction.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application is related to non-provisional U.S. Utility patent application Ser. No. 13/209,312 entitled “MULTI-COMMERCE CHANNEL WALLETS FOR AUTHENTICATED TRANSACTIONS”, and also International PCT Application Serial No. PCT/US2011/047678 having the same title, both filed 12 Aug. 2011, both of which in turn claim the priority benefit of U.S. Provisional Application Ser. No. 61/372,955 filed 12 Aug. 2010 and also of U.S. Provisional Application Ser. No. 61/468,847 filed 29 Mar. 2011.
  • This application is further related to U.S. Provisional Application Ser. No. 61/588,505 (Attorney Docket No. 1788-82P) entitled “SYSTEM TO ENABLE A NETWORK OF WALLETS”, filed 19 Jan. 2012.
  • This application is further related to U.S. Provisional Application Ser. No. 61/642,729 (Attorney Docket No. 1788-82P2), entitled “SYSTEM AND METHOD TO ENABLE A NETWORK OF DIGITAL WALLETS”, and filed on even date herewith.
  • The complete disclosures of all related applications cited above and any of their corresponding priority applications are hereby incorporated in their entirety for all purposes by this reference.
  • BACKGROUND
  • 1. Field of the Disclosure
  • The present invention relates to cashless transactions for payment of goods/services and, more particularly, to an electronic interface protocol facilitating purchaser access to a network of electronic wallets from which the purchaser may choose.
  • 2. Brief Discussion of Related Art
  • Electronic wallets are becoming a more prevalent counterpart to electronic forms of cashless payment for a wide variety of transactions. Generally speaking, an electronic wallet is a system by which a credit card, debit card, pre-paid card, etc., are stored where a single electronic application provides access to them, analogous to the way in which one might store corresponding physical payment cards in a tangible wallet.
  • The disclosure in the application entitled “MULTI-COMMERCE CHANNEL WALLETS FOR AUTHENTICATED TRANSACTIONS”, and also the related application entitled “SYSTEM AND METHOD TO ENABLE A NETWORK OF DIGITAL WALLETS”, includes a federated network of electronic wallets. The purchaser may select this network of wallets, which includes wallet partners who are members of the federation, each of whom provide electronic wallet services. One option presented to the purchaser may be the option to use an electronic wallet maintained and provided by the payment processing entity, e.g., MasterCard International, which is also operating the network of wallets.
  • A problem is presented to present the purchaser with a consistent and desirable or pleasing checkout experience using their chosen electronic wallet across multiple vendor websites, and multiple platforms (e.g., web, mobile, tablet, etc.). The present state of the art is therefore wanting.
  • SUMMARY
  • At least one benefit to be realized according to the present disclosure is that the user's shopping experience is improved by the merchant having access, during the shopping process, to user wallet data which would ordinarily be shared with the merchant only later in the process. For example, at the collection of payment by cashless means, which would ordinarily occur at the conclusion of the sale, the merchant would receive the user's wallet data.
  • Features of the disclosure will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed as an illustration only and not as a definition of the limits of this disclosure.
  • The present disclosure is directed to a method of facilitating use of a digital electronic wallet by a cardholder for cashless transactions. The presently disclosed method comprises receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein an electronic representation of at least one payment device usable to fund a cashless transaction, and further may include other information to facilitate completing the transaction, including without limitation a shipping address, or loyalty account identifiers. Thereafter, facilitating a communication between the first cardholder and the first wallet holder to record consent by the first cardholder to discreetly share payment device, profile, shipping address, and rewards information with the first merchant. Upon consent, the present disclosure further facilities a communication between the first wallet holder and first merchant by providing a wallet token usable for accessing wallet information, including payment card information for acquiring payment on behalf of the first merchant from the first cardholder using the at least one payment device in the first digital wallet as selected by the first cardholder, and preparing a long lived merchant token corresponding to the provided wallet token. The merchant token is provided to the first merchant, for presentation to the network operator (e.g., the instant Applicant, under the trademark MASTERPASS) to access wallet information from the first wallet holder.
  • In still a further embodiment of the present disclosure, the merchant is provide, together with the merchant token, additional information associated with the first digital wallet, including as least one of a shipping address, a loyalty account, product-related preference (e.g., without limitation, airline seating preference) and a scope of cardholder consent.
  • The present disclosure further provides for a more particular method to include receiving, from the first wallet holder, a request to disable the previously received wallet token. Responsive to receipt from the first wallet holder to disable the token, corresponding merchant token provided to the first merchant is disabled. Optionally, the presently disclosed method provides for receiving postback data from the first merchant concerning any cashless transaction concluded using the merchant token.
  • Also provided according to the present disclosure are a system including a network-enabled processor for communication among at least a first merchant and a first wallet holder, and a machine-readable recording medium storing thereon a program of instructions which, when executed by a processor, cause the processor to carry out a method described above.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • In addition to the above aspects of the present disclosure, additional aspects, objects, features and advantages will be apparent from the embodiments presented in the following description and in connection with the accompanying drawings,
  • FIG. 1 is a schematic illustration of a representative cycle of transaction processing by a payment network of an electronic cashless sale;
  • FIG. 2 is a flow diagram representation of a communication flow for facilitating consumer use of their electronic wallet in remote electronic transactions according to a particular embodiment of the present disclosure;
  • FIG. 3 is a flow diagram representation of a communication flow for facilitating consumer use of their electronic wallet in remote electronic transactions according to an alternate embodiment of the present disclosure;
  • FIG. 4 is a flow diagram representation of a communication flow for facilitating consumer use of their electronic wallet in remote electronic transactions where a cardholder had already paired their electronic wallet credentials with a merchant, for example as depicted in either FIG. 2 or FIG. 3, according to a particular embodiment of the present disclosure;
  • FIG. 5 is a flow diagram representation of a communication flow for facilitating a cardholder unpairing their electronic wallet from any merchant with which they had previously consented to pairing, according to a particular embodiment of the present disclosure; and
  • FIG. 6 illustrates schematically a representative system operative to carry out the method described in accordance with the present disclosure.
  • DETAILED DESCRIPTION OF THE EMBODIMENTS
  • The following sections describe particular embodiments. It should be apparent to those skilled in the art that the described embodiments provided herein are illustrative only and not limiting, having been presented by way of example only. All features disclosed in this description may be replaced by alternative features serving the same or similar purpose, unless expressly stated otherwise. Therefore, numerous other embodiments of the modifications thereof are contemplated as falling within the scope of the present method and system as defined herein and equivalents thereto.
  • Throughout the description, where items are described as having, including, or comprising one or more specific components, or where methods are described as having, including, or comprising one or more specific steps, it is contemplated that, additionally, there are items of the present disclosure that consist essentially of, or consist of, the one or more recited components, and that there are methods according to the present disclosure that consist essentially of, or consist of, the one or more recited processing steps.
  • It should also be understood that the order of steps or order for performing certain actions is immaterial, as long as the method remains operable. Moreover, two or more steps or actions may be conducted simultaneously.
  • The term “transaction data” is used herein to refer to data associated with any recorded cashless transaction, including any transaction using a payment device, for example, a credit card, debit card, PIN debit card, ATM card, electronic funds transfer (EFT), near field communications (NFC) payments, smartphone wallet transactions, and so on, as well as those electronic payments using ACH and electronic wire. Transaction data may further include, without limitation, information identifying the source of funds for the transaction, the amount or value of the transaction, the parties to the transaction, their names, addresses, other identifying information, an identification of the purchaser derived from the payment device used in the transaction, among any other pieces of information as may be relevant to the transaction.
  • The term “payment network” generally refers to a payment network for handling cashless transactions and is often associated with a single payment card issuer, such as a credit card issuer. However, the term “payment network” as used herein can encompass both single card issuer networks and a network, such as a network of wallets that includes multiple card issuers.
  • The various methods of the present disclosure are preferably implemented as executable programs stored on a server device and executed by a processing device associated with the server device. Such server devices may be maintained and operated by a payment network operator, or by a third-party hosting operator. The flow of various embodiments of the method of the present disclosure for imputing a personal holiday date associated with a consumer from payment card transaction data into an individualized forecasting model is preferably directed by the hosted executable program code running on the server device or on any appropriate device known in the art for providing the embodiments of the methods of the present disclosure.
  • Referring to FIG. 1, in one embodiment of a typical cashless transaction a device holder 12 presents a payment instrument 14 to a merchant 16 for payment. Though the payment instrument is shown as a payment card, it can also be a transponder device, NFC-enabled smart phone, or any digital wallet selected for remote or on-line payment or provided as a mobile device app. In cases where the merchant 16 has an established merchant account with an acquiring bank (also called the acquirer) 20, the merchant communicates with the acquirer to secure payment on the transaction by sending a transaction request 21. An acquirer 20 is a party or entity, typically a bank, which is authorized by the network operator 22 to acquire network transactions on behalf of customers of the acquirer 20 (e.g., merchant 16). The merchant 16 may alternatively secure payment on a transaction through a third-party payment provider 18 authorized by the acquirer 20 and the network operator 22 to acquire payments on network transactions on behalf of the merchants. In this way, the merchant 16 can be authorized and able to accept the payment device 14 from a device holder 12, without having a merchant account with the acquirer 20.
  • The acquirer 20 typically populates and routes the transaction request 21 from the merchant to a network operating system (also referred to as “network operator”) 22 controlled by the network operations entity (for example, MasterCard International Incorporated, assignee of the instant application). The data included in the transaction request identifies the source of funds, or type of payment, used for the transaction. With this information, the network operator 22 routes the transaction to an issuer 24, typically a bank, which is authorized by the network operator 22 to issue payment devices 14 on behalf of its customers (e.g., device holder 12), for use in payment transactions within the payment network. The issuer 24 also typically funds the transaction that it approves. The issuer 24 may approve or authorize the transaction request based on criteria such as a device holder's credit limit, account balance, or in certain instances more detailed and particularized criteria including transaction amount, merchant classification and so on.
  • The issuer 24 decision to authorize or decline the transaction is routed through the network operator 22 and acquirer 20, and ultimately to the merchant 16 at the point of sale. This entire process is carried out by electronic communication, and under routine circumstances (i.e., valid device, adequate funds, etc.) can be completed in a matter of seconds. It permits the merchant 16 to engage in transactions with a device holder 12, and the device holder 12 to partake of the benefits of cashless electronic payment, while the merchant 16 can be assured that payment is secured.
  • The issuer 24 may also periodically generate a statement of the cashless transactions 25 for the benefit of the device holder 12 that lists all of the device holder's 12 purchases with the payment device 14 over a specified period of time.
  • The transaction request from the merchant, which includes details of the payment transaction for authorization, is generally further populated by the acquirer 20 with merchant information and then forwarded to the issuer. A central database, or data warehouse 26, is also associated with and maintained by the payment network for storing and augmenting this payment transaction data on a regular basis for use in marketing, macroeconomic reporting, and so on.
  • Each payment card transaction record that is stored in the data warehouse 26 is associated with a consumer, and includes at least a date and time of the transaction, an account number, cardholder ID, and/or other identifying data of the cardholder making the purchase, a merchant ID and/or merchant name, and, generally, other merchant location and/or identification information of the merchant associated with the transaction, along with additional details of the purchase. Such additional purchase information recorded in the transaction records typically includes the number, type, and cost of each good purchased. Accordingly, for any particular cardholder/consumer, a time-stamped listing of the consumer's purchasing activity can be obtained, including information on a type of good, number of each type of good purchased, and the cost of each good.
  • With the advent of the digital wallet, an additional party, a wallet holder 28 (see, e.g., FIG. 2) plays a part in the transaction. The wallet holder 28 stores a cardholder's 12 card credentials electronically, much as a physical wallet would hold a cardholder's 12 transaction devices 14 (e.g., payment cards).
  • Referring now to FIG. 2, illustrated is a communication flow, generally 100, for facilitating consumer use of their electronic wallet in remote electronic transactions. This method and communication flow will be applicable across any means of electronic interaction between the merchant 16 and their cardholder 12 customer, whether internet web-based e-commerce platforms, mobile device platforms, or app-based platforms, and the precise interface between the cardholder 12 and the merchant 16 will be considered as interchangeable for the purposes of the following discussion. At least one purpose of the interaction is to persistently associate a particular electronic wallet, and more particularly a payment card 14 therein, with a given merchant 16 to facilitate future uses of that wallet while completing a checkout for the current transaction.
  • The cardholder 12 will interact 102 with the merchant 16, for example via the merchant 16 website or the like. The merchant 16 will then, where possible, recognize 104 the cardholder 12. Among the means of recognition 104, the cardholder 12 may log into the merchant 16 site via credential established for that purpose. Alternately, the cardholder will have consented to a ‘cookie’ placed on their computer from a prior visit to the merchant 16 website which the merchant can use to recognize 104 the cardholder 12. Other methods of recognition are within the scope of this disclosure. During the course of the cardholder's 12 interaction with the merchant 16 the cardholder 12 will initiate a transaction 106 to purchase goods or services from the merchant, and will further choose to use their electronic wallet managed by the network operator 22 in order to pay for the transaction. Additionally the merchant also requests that persistent access be granted to the card holder's wallet data.
  • The merchant 16 redirects the wallet selection request 108 to the network operator 22. In some embodiments of the present disclosure, the network operator requests information 110 of the cardholder 12 to verify their location, as part of a security measure. The network operator 22 validates the cardholder's response 114 against known data, and presuming successful validation, displays to the cardholder their electronic wallet or wallets 116 available from which to choose. The cardholder 12 makes their selection of wallet 118 from among the available wallets presented 116 by the network operator 22. The network operator 22 at action 120 redirects the cardholder 12 selection of electronic wallet to the corresponding wallet holder 28.
  • It should be noted here that, consistent with Applicant's prior Network of Wallets filings referenced above and incorporated herein by reference, in certain instances, the network operator 22, or a related entity, will also perform the wallet holder 28. In other cases, the network operator 22 will host an electronic wallet on behalf of a wallet holder 28, for use by customers of that wallet holder 28. This case is also referred to as a “white label” wallet, which is branded by the wallet partner, but functionally operated by the network operator. The Network of Wallets framework further contemplates the wallet being hosted by a wallet holder 28 independent of the network operator. In any case, the communications described herein as with the wallet holder 28 are made with whichever entity is responsible for hosting the electronic wallet.
  • The wallet partner displays a login page 122 to the cardholder 12, who responds by logging into their wallet 124. The wallet partner validates the login 126, and at 128 presents a page to the cardholder 12 requesting, inter alia, consent to persistently share the consent to share the cardholder's 12 the electronic wallet particulars with the merchant 16. Also to be selected by the cardholder for the purposes of the current transaction is one card within the electronic wallet to be used for the current transaction 16, an address for shipment of goods, and any merchant-linked or other loyalty discounts cards or programs that the cardholder 12 wishes to provide to the particular merchant 16. In certain embodiments of the present disclosure, the provided information may include, without limitation, one or more of payment card information, shipping address information, loyalty account information, cardholder personal profile information and purchase preference information. Purchase preference information may be defined by the merchant, and the information shared may be limited to a particular merchant's needs, or may be more universal with cardholder consent. Merely one example of purchase preference information, taking for instance airline travel merchants, may be seat preference (aisle or window) or meal preference.
  • The cardholder's 12 selection 130 is provided to the wallet holder 28. The wallet holder 28 will record the cardholder's consent for persistent access by the merchant 132, the additional selections for the current transaction, and issue a confirmation notification 134 to the cardholder 12, for example via e-mail. For the current transaction, the wallet provider will generate a token and provide this token to the network operator. The wallet partner will also authorize the network operator to generate a long lived pairing token for persistent access at 136. A “token” in this context is a data file, and/or a reference to a specific data file, that securely represents the cardholder's 12 primary account number (PAN), or other confidential wallet account information. Optionally, the token is usable only by a particular merchant 16 to obtain funds on the account of a particular linked cardholder 12. The token is thus a data security measure.
  • For the current transaction, the network operator 22 thus receives at 136 from the wallet holder 28 a authorization to generate a wallet token and typically, though not necessarily, retrieval URI to access the token 12. The network operator then generates a token 138 and optionally a URI to be shared with the merchant 16. The network operator 22 sends the checkout package 140 to the merchant 16. A checkout package will include a merchant token the merchant can use to access payment consistent with the scope of the token. The merchant can respond by presenting the checkout retrieval token to the network operator 22 at 142. The network operator 22 then issues to the merchant 16 a checkout retrieval URI, 144, which the merchant can access to conclude the checkout. The merchant will then access the checkout retrieval URI, 146. The cardholder makes their final review of the transaction, and places their order by indication to the merchant 16 at 152. The merchant will send a postback 154 of the completed transaction to the network operator 22.
  • Based on the consent to grant the merchant persistent access to the cardholder's wallet information, the network operator provides a long lived access token to the merchant. The merchant will map this token to their identified consumer to be used to request cardholder information for a future transaction.
  • According to a further embodiment of the present disclosure, the pairing between a particular cardholder's 12 electronic wallet and a particular merchant 16 may provide for varying scope of authority to the merchant 16. This is to say that the token generated by the network operator 22 may be used by a specific merchant 16 to obtain payment on subsequent unspecified transactions, rather than a specific transaction involved in the pairing, as compared with a token that is linked to a particular transaction, transaction amount, and/or short timeframe. In this way, a more permissive scope token can be used by a merchant 16 to enable purchases by the cardholder 12 by executing only a single mouse click, using their pre-selected electronic wallet with no further authentication required.
  • As a result of the foregoing process, in addition to completing the transaction contemplated between the cardholder 12 and the merchant 16, one of the cardholder's electronic wallet(s) will be associated, or paired, with a particular merchant 16, during the checkout of a transaction. Additionally, as depicted in FIG. 3, and described below, the cardholder 12 may pair their card with the merchant directly, outside the context of a pending transaction.
  • The foregoing description with respect to FIG. 2 presumed the pairing between wallet and merchant was formed during the checkout of a transaction in which the cardholder 12 chose to both use their electronic wallet for payment and also form the pairing between wallet and merchant. Referring now to FIG. 3, illustrated is illustrated is a communication flow, generally 200, for facilitating consumer use of their electronic wallet in remote electronic transactions by pairing the wallet with the merchant in as part of steps deliberately undertaken for that purpose, as compared to accomplishing the pairing during the course of a transaction checkout using the electronic wallet. In view of the similarities with the foregoing communication flow 100 described in FIG. 2, the present description will not include each and every detail already mentioned above.
  • The cardholder 12 will interact 202 with the merchant 16, for example via the merchant 16 website or the like. The merchant 16 will then, where possible, recognize 204 the cardholder 12. The cardholder 16 will initiate a request 206 to pair their electronic wallet with the merchant 16. The merchant 16 redirects the wallet selection request 208 to the network operator 22.
  • In response, the network operator may request information 210 of the cardholder 12 to verify their location, as described above. The cardholder 12 responds 212 with the requested information. The network operator 22 validates the cardholder's response 214 against known data, and presuming successful validation, displays 216 to the cardholder their electronic wallet or wallets available from which the cardholder 12 may choose. The cardholder 12 makes their selection of wallet 218 from among the available wallets presented 216 by the network operator 22. The network operator 22 at action 220 redirects the cardholder 12 selection of electronic wallet to the corresponding wallet holder 28.
  • The wallet partner displays a login page 222 to the cardholder 12, who responds by logging into their wallet 224. The wallet partner validates the login 226, and at 228 presents a page to the cardholder 12 requesting, inter alia, consent to share the consent to share the cardholder's 12 the electronic wallet particulars with the merchant 16. The wallet holder 28 will record the cardholder's consent 232, and issues a confirmation notification 234 to the cardholder 12, for example via e-mail. The wallet partner will authorize the network operator to generate a wallet token
  • The network operator 22 thus provides a wallet token to the wallet holder The network operators then generates a token 238 to be shared with the merchant 16 at 240. The merchant 16 maps the merchant token to the cardholder ID at 250, for use in future purchases.
  • Referring then to FIG. 4, illustrated is a communication flow, generally 300, for facilitating consumer use of their electronic wallet in remote electronic transactions where, as depicted in either FIG. 2 or FIG. 3, the cardholder 12 had already paired their electronic wallet credentials with the merchant 16. Notably, the communication flow 300 is characterized by a greatly reduced need for information from the cardholder 12.
  • The cardholder 12 will interact 302 with the merchant 16, for example via the merchant 16 website or the like. The merchant 16 will then, where possible, recognize 304 the cardholder 12. The merchant will also retrieve a previously received merchant token 304 that is mapped to the recognized cardholder 12 from a previous pairing. The merchant 16 presents the corresponding merchant token to the network operator 22 along with the requested data at 306. The requested data can only be the same or a subset of the data previously consented by the cardholder. The network operator 22 at 308 validates the merchant token, and resolves the merchant token to the corresponding wallet holder and wallet token 28. The network operator then at 310 presents the wallet token to wallet holder 28. At 312, the wallet holder 28 validates the wallet token, retrieves the scope of prior cardholder 21 authorization with respect to the merchant 16. The wallet holder 28 sends to the network operator 22 at 314 the requested data. This is received by the network operator at 316. Concurrently, the wallet holder 28 may issue a confirmation notification 334 to the cardholder 12, for example via e-mail, confirming that the merchant has accessed the cardholder's 12 electronic wallet in accordance with a prior consent.
  • The network operator 22 sends the requested data (i.e. pre-checkout data) 340 to the merchant 16. The merchant then can display to the cardholder 350 the provided data on the merchant site/app, including available card(s), address(es), loyalty programs, cardholder personal profile information, etc along with the cardholder's default preferences. The cardholder 12 makes their selection (or accepts a prior default selection) and places their order 352, and the merchant 16 then in turn requests the payment particulars 354 (e.g., PAN) from the network operator 22 for the card selected by the cardholder 12.
  • The network operator 22 will then provide the merchant 16 with the PAN for the selected payment card 349. The merchant uses the supplied PAN to obtain payment for the transaction. Alternately, the network operator 22 will then request the PAN of the selected payment card from the wallet holder and redirects the cardholder to the previously paired wallet holder. The wallet partner displays a login page 222 to the cardholder 12, who responds by logging into their wallet. The wallet holder will provide the network operator with the selected PAN and the network operator will then provide the merchant 16 with the selected PAN 349. The merchant uses the supplied PAN to obtain payment for the transaction. In either case, the merchant 16 may also send a verification to the wallet operator 21 upon consummation of the transaction. The merchant 16 may send a postback 354 of the completed transaction to the network operator 22 as well.
  • Referring now to FIG. 5, illustrated is a communication flow, generally 500, by which a cardholder 12 may unpair their electronic wallet from any merchant 16 with which they had previously consented to pairing. In this example, the cardholder 12 logs into their electronic wallet 501 directly with the wallet provider 21. The wallet provider 21, having validated the login, displays 503 to the cardholder 12 wallet information, including payment cards, addresses, profile information, default preferences selected, inter alia, and at least a list of any connected merchants. The cardholder 12 selects an option 505 to review connected merchants. The wallet holder 28 then displays 507 to the cardholder 12 their connected merchants. The interface provided to the cardholder 12 may also include an ability to deselect a merchant connection, for example depicted as a toggle switch, or any other suitable graphic interface means. In some embodiments of the present disclosure, the user is given the opportunity to review a connection history.
  • The cardholder, using the provided interface, may deselect a merchant connection 509 for one or more connected merchants. The wallet holder 28 may optionally prompt the cardholder 12 for confirmation, which the cardholder 12 may confirm 513. The wallet holder 28 records the cardholder's 12 confirmed selection at 515, and will disable any previously provided token pairing the cardholder's 12 electronic wallet with the merchant 16. The wallet partner will optionally send a confirmation 517, e.g., by email, to the cardholder to confirm the unpairing operation by a separate communication channel. The wallet holder 28 communicates the disabling of the prior issued the wallet token 519 to the network operator 22. The network operator receives this communication 521, and in turn disables any corresponding merchant token.
  • Thereafter, on a subsequent visit to the merchant 16 site by the cardholder 12, at 523, the cardholder may likewise recognize the cardholder 12 at 525. The merchant 16 communicates with the network operator 22 at 527 by submitting a previously issued merchant token corresponding to the cardholder 12. The network operator 22 will validate the merchant token at 529, recognizing the unpairing. The network operator will thus communicate the unpairing 531 to the merchant 16.
  • The foregoing figures have contemplated interaction and/or pairing between a cardholder's 12 digital wallet and a particular merchant 16 providing goods or services. In still a further embodiment of the present disclosure, the cardholder 12 may wish to pair their digital wallet with an app, website or the like provided by the wallet holder 28. In this scenario, the cardholder 12 may use the wallet services interface to perform so-called CRUD functions, i.e., Create, Read, Update and Delete, using the app. This makes the digital wallet more usable to the cardholder 12, and also to the digital wallet operator.
  • In most respects, the interaction of the wallet services app provided by wallet partner 28 will be largely similar to that of a merchant 16 as described in the foregoing embodiments and communications diagrams. One key difference being that the scope of the authority granted by the cardholder and encoded into a corresponding token with one of administrative functionality (i.e., CRUD) with the electronic wallet, as compared with incurring charges for purchase of goods or services. In this way, the pairing process between wallet and will be seen to most resemble that of FIG. 3, describes above, and the unpairing process will most resemble that of FIG. 5. On an ongoing basis, administrative action undertaken once paired will resemble the communications depicted in FIG. 4, with reduced interaction required of the cardholder 12.
  • It will be appreciated by those skilled in the art that the methods as described above may be operated by a machine operator having a suitable interface mechanism, and/or more typically in an automated manner, for example by operation of a network-enabled computer system including a processor executing a system of instructions stored on a machine-readable medium, RAM, hard disk drive, or the like. The instructions will cause the processor maintained by the network operator 22 to operate in accordance with the present disclosure.
  • Turning then to FIG. 6, illustrated schematically is a representative computer 616 of the system, generally 600. The computer 616 includes at least a processor or CPU 622 which is operative to act on a program of instructions stored on a computer-readable medium 624. Execution of the program of instruction causes the processor 622 to carry out, for example, the methods described above according to the various embodiments. It may further or alternately be the case that the processor 622 comprises application-specific circuitry including the operative capability to execute the prescribed operations integrated therein. The computer 616 will in many cases include a network interface 626 for communication with an external network 612. Optionally or additionally, a data entry device 628 (e.g., keyboard, mouse, trackball, pointer, etc.) facilitates human interaction with the server, as does an optional display 630. In other embodiments, the display 630 and data entry device 628 are integrated, for example a touch-screen display having a GUI.
  • Variants of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.

Claims (10)

What is claimed is:
1. A method of facilitating use of a digital electronic wallet by a cardholder for cashless transactions, the method comprising:
receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein wallet information including an electronic representation of at least one payment device usable to fund a cashless transaction;
facilitating a communication between the first cardholder and the first wallet holder to record consent by the first cardholder to wallet information with the first merchant;
generating a wallet token usable for accessing the wallet information from the first wallet holder for the first digital wallet as selected by the first cardholder;
preparing a merchant token corresponding to the received wallet token; and
providing the merchant token to the first merchant, to access the wallet information.
2. The method according to claim 1, wherein the wallet information further comprises at least one of a shipping address, a loyalty account identifier, merchant-specified personal preferences, cardholder personal profile information, and a scope of cardholder consent.
3. The method according to claim 1, further comprising:
receiving from the first wallet holder a request to disable the previously generated wallet token;
responsive to receipt from the first wallet holder of a disabling token, disabling a corresponding merchant token provided to the first merchant.
4. The method according to claim 1, further comprising:
receiving from the first merchant postback data concerning any cashless transaction concluded using the merchant token.
5. The method according to claim 1, further comprising:
verifying a cardholder a cardholder location.
6. A system for facilitating use of a digital electronic wallet by a cardholder for cashless transactions, the system comprising a network-enabled processor for communication among at least a first merchant and a first wallet holder, and a machine-readable recording medium storing thereon a program of instructions which, when executed by a processor, cause the processor to carry out a method comprising:
receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein wallet information including an electronic representation of at least one payment device usable to fund a cashless transaction;
facilitating a communication between the first cardholder and the first wallet holder to record consent by the first cardholder to share wallet information, including payment device information, with the first merchant;
generating a wallet token usable for accessing the wallet information from the first wallet holder for the first digital wallet as selected by the first cardholder;
preparing a merchant token corresponding to the received wallet token; and
providing the merchant token to the first merchant, to access the wallet information.
7. The system according to claim 6, wherein the wallet information further comprises at least one of a shipping address, a loyalty account identifier, merchant-specified personal preferences, cardholder personal profile information, and a scope of cardholder consent.
8. The system according to claim 6, wherein the method further comprises:
receiving from the first wallet holder a request to disable the previously generated wallet token;
responsive to receipt from the first wallet holder of a disabling token, disabling a corresponding merchant token provided to the first merchant.
9. The system according to claim 6, wherein the method further comprises:
receiving from the first merchant postback data concerning any cashless transaction concluded using the merchant token.
10. The system according to claim 6, wherein the method further comprises:
verifying a cardholder location.
US14/485,139 2010-08-12 2014-09-12 Pairing electronic wallet with specified merchants Abandoned US20160078428A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US37295510P true 2010-08-12 2010-08-12
US201161468847P true 2011-03-29 2011-03-29
US14/485,139 US20160078428A1 (en) 2010-08-12 2014-09-12 Pairing electronic wallet with specified merchants

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US14/485,139 US20160078428A1 (en) 2010-08-12 2014-09-12 Pairing electronic wallet with specified merchants
PCT/US2015/048102 WO2016040070A2 (en) 2014-09-12 2015-09-02 Pairing electronic wallet with specified merchants
CA2960704A CA2960704C (en) 2014-09-12 2015-09-02 Pairing electronic wallet with specified merchants
KR1020177009852A KR20170069222A (en) 2014-09-12 2015-09-02 Pairing electronic wallet with specified merchants
AU2015315602A AU2015315602A1 (en) 2010-08-12 2015-09-02 Pairing electronic wallet with specified merchants
EP15839282.9A EP3192033A4 (en) 2014-09-12 2015-09-02 Pairing electronic wallet with specified merchants

Publications (1)

Publication Number Publication Date
US20160078428A1 true US20160078428A1 (en) 2016-03-17

Family

ID=45568233

Family Applications (4)

Application Number Title Priority Date Filing Date
US13/209,312 Abandoned US20120143752A1 (en) 2010-08-12 2011-08-12 Multi-commerce channel wallet for authenticated transactions
US14/485,139 Abandoned US20160078428A1 (en) 2010-08-12 2014-09-12 Pairing electronic wallet with specified merchants
US15/481,114 Pending US20170243219A1 (en) 2010-08-12 2017-04-06 Multi-commerce channel wallet for authenticated transactions
US15/481,077 Pending US20170243218A1 (en) 2010-08-12 2017-04-06 Multi-commerce channel wallet for authenticated transactions

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US13/209,312 Abandoned US20120143752A1 (en) 2010-08-12 2011-08-12 Multi-commerce channel wallet for authenticated transactions

Family Applications After (2)

Application Number Title Priority Date Filing Date
US15/481,114 Pending US20170243219A1 (en) 2010-08-12 2017-04-06 Multi-commerce channel wallet for authenticated transactions
US15/481,077 Pending US20170243218A1 (en) 2010-08-12 2017-04-06 Multi-commerce channel wallet for authenticated transactions

Country Status (7)

Country Link
US (4) US20120143752A1 (en)
EP (1) EP2603892A4 (en)
AU (3) AU2011289180B2 (en)
CA (3) CA2958140C (en)
IL (1) IL224685A (en)
SG (2) SG187832A1 (en)
WO (1) WO2012021864A2 (en)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016040070A2 (en) * 2014-09-12 2016-03-17 Mastercard International Incorporated Pairing electronic wallet with specified merchants
US20130212012A1 (en) * 2010-10-15 2013-08-15 34 Solutions, Llc System And Method For Mobile Electronic Purchasing
US20120095865A1 (en) * 2010-10-15 2012-04-19 Ezpayy, Inc. System And Method For Mobile Electronic Purchasing
CN102769846A (en) * 2011-05-04 2012-11-07 中国银联股份有限公司 User terminal and payment system
US8412631B2 (en) * 2011-05-13 2013-04-02 American Express Travel Related Services Company, Inc. Cloud enabled payment processing system and method
US8538845B2 (en) 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
US9208488B2 (en) 2011-11-21 2015-12-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
EP2805295A4 (en) * 2012-01-19 2015-08-12 Mastercard International Inc System and method to enable a network of digital wallets
US20130198066A1 (en) * 2012-01-27 2013-08-01 Google Inc. Fraud Protection for Online and NFC Purchases
US9767453B2 (en) * 2012-02-23 2017-09-19 XRomb Inc. System and method for processing payment during an electronic commerce transaction
US9092776B2 (en) 2012-03-15 2015-07-28 Qualcomm Incorporated System and method for managing payment in transactions with a PCD
US9818098B2 (en) * 2012-03-20 2017-11-14 First Data Corporation Systems and methods for facilitating payments via a peer-to-peer protocol
US20130297509A1 (en) * 2012-05-07 2013-11-07 Infosys Limited Mobile payment using dynamic authorization code and multi-payer shared card number
US20130347075A1 (en) * 2012-06-22 2013-12-26 Tyfone, Inc. Method and apparatus for secure consolidation of cloud services
US20130346223A1 (en) * 2012-06-26 2013-12-26 Rajen S. Prabhu Processing point-of-sale transactions using a mobile card and mobile phone
US10192216B2 (en) * 2012-09-11 2019-01-29 Visa International Service Association Cloud-based virtual wallet NFC apparatuses, methods and systems
US20140074704A1 (en) * 2012-09-11 2014-03-13 Cashstar, Inc. Systems, methods and devices for conducting transactions with electronic passbooks
US9092828B2 (en) 2012-09-19 2015-07-28 Mastercard International Incorporated Purchase Data sharing platform
US20140129435A1 (en) * 2012-11-05 2014-05-08 Mastercard International Incorporated Electronic wallet apparatus, method, and computer program product
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
EP2936406A1 (en) * 2012-12-19 2015-10-28 Deutsche Telekom AG Method and system for terminal device-based communication between third-party applications and an electronic wallet
KR20140095745A (en) * 2013-01-25 2014-08-04 삼성전자주식회사 Supporting Method For Payment and System thereof
US9965756B2 (en) * 2013-02-26 2018-05-08 Digimarc Corporation Methods and arrangements for smartphone payments
US9830588B2 (en) * 2013-02-26 2017-11-28 Digimarc Corporation Methods and arrangements for smartphone payments
US9830202B1 (en) * 2013-04-24 2017-11-28 Google Llc Storage and process isolated web widgets
US20140365363A1 (en) * 2013-06-07 2014-12-11 Prairie Cloudware, Inc Secure integrative vault of consumer payment instruments for use in payment processing system and method
US10229400B2 (en) * 2013-06-07 2019-03-12 Swoop Ip Holdings Llc System and method for two-click validation
EP2824628A1 (en) * 2013-07-10 2015-01-14 Vodafone Holding GmbH Direct debit procedure
US9818101B2 (en) 2013-09-05 2017-11-14 Mastercard International Incorporated System and method for socially connecting payment card holders
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
JP6353537B2 (en) * 2013-12-02 2018-07-04 マスターカード インターナショナル インコーポレーテッド Method and system for performing secure authentication of users and mobile devices without using a secure element
CN106031207A (en) 2013-12-02 2016-10-12 万事达卡国际股份有限公司 Method and system for secure tranmission of remote notification service messages to mobile devices without secure elements
WO2015095771A1 (en) * 2013-12-19 2015-06-25 Visa International Service Association Cloud-based transactions methods and systems
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
NZ721223A (en) * 2014-04-14 2018-02-23 Mastercard International Inc Method and system for generating an advanced storage key in a mobile device without secure elements
EP3132405A4 (en) * 2014-04-16 2017-10-18 Nucleus Software Exports Limited Device, system and method for efficiently servicing high volume electronic transactions
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US20160078444A1 (en) * 2014-09-16 2016-03-17 Mastercard International Incorporated Systems and methods for providing fraud indicator data within an authentication protocol
SG10201406521TA (en) * 2014-10-10 2016-05-30 Mastercard Asia Pacific Pte Ltd Methods and systems for secure online payment
WO2016068871A1 (en) * 2014-10-28 2016-05-06 Total System Services, Inc. Automated payment information update with vendors
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
CA2974151A1 (en) * 2015-01-19 2016-07-28 Royal Bank Of Canada Secure processing of electronic payments
US10178088B2 (en) * 2015-03-12 2019-01-08 Tejas Networks Ltd. System and method for managing offline and online password based authentication
SG10201507756RA (en) * 2015-09-17 2017-04-27 Mastercard Asia Pacific Pte Ltd Method of associating a customer's mobile computer device with an order for goods and/or services taken by a waiter in a merchant's venue
US20170262850A1 (en) * 2016-03-14 2017-09-14 Jpmorgan Chase Bank, N.A. Systems and Methods for Device Authentication
WO2017165576A1 (en) * 2016-03-22 2017-09-28 Visa International Service Association Adaptable authentication processing

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7343351B1 (en) * 1999-08-31 2008-03-11 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US7111789B2 (en) * 2001-08-31 2006-09-26 Arcot Systems, Inc. Enhancements to multi-party authentication and other protocols
US20030074660A1 (en) * 2001-10-12 2003-04-17 Liberate Technologies System method and apparatus for portable digital identity
US20030195963A1 (en) * 2002-04-10 2003-10-16 Yu Song Session preservation and migration among different browsers on different devices
US7707120B2 (en) * 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US7360694B2 (en) * 2003-01-23 2008-04-22 Mastercard International Incorporated System and method for secure telephone and computer transactions using voice authentication
JP2007517272A (en) * 2003-06-10 2007-06-28 マスターカード インターナシヨナル インコーポレーテツド Guaranteed payment transaction system and method using the format of the data structure
KR20050045157A (en) 2003-11-10 2005-05-17 소프트포럼 주식회사 Electronic payment system and method thereof
WO2005053345A1 (en) * 2003-11-25 2005-06-09 Xius India Ltd. Method and system for accessing wireless networks
US8762283B2 (en) * 2004-05-03 2014-06-24 Visa International Service Association Multiple party benefit from an online authentication service
WO2006102270A2 (en) * 2005-03-22 2006-09-28 Cooper Kim A Performance motivation systems and methods for contact centers
US7540408B2 (en) * 2006-06-22 2009-06-02 Hip Consult Inc. Apparatus and method for facilitating money or value transfer
EP1978477A3 (en) * 2006-07-06 2011-03-02 Firethorn Holdings, LLC Methods and systems for making a payment via a stored value card in a mobile environment
US7720783B2 (en) * 2007-03-28 2010-05-18 Palo Alto Research Center Incorporated Method and system for detecting undesired inferences from documents
JP5520813B2 (en) * 2007-04-17 2014-06-11 ビザ ユー.エス.エー.インコーポレイテッド Personal authentication method for transaction, server, and program storage medium for executing the method
KR20090012897A (en) * 2007-07-31 2009-02-04 주식회사 퍼스트포켓 Method and system for providing financial service by using electronic wallet apparatus, integration electronic wallet server, electronic wallet supportive terminal
EP2218043A4 (en) * 2007-12-05 2012-09-19 Google Inc On-line payment transactions
US9208485B2 (en) * 2008-03-24 2015-12-08 American Express Travel Related Services Company, Inc. System and method for facilitating online transactions
KR20100084068A (en) * 2009-01-15 2010-07-23 정태우 System and method for online commerce
US8468545B2 (en) * 2010-08-18 2013-06-18 8X8, Inc. Interaction management

Also Published As

Publication number Publication date
SG187832A1 (en) 2013-03-28
AU2015213354A1 (en) 2015-09-03
WO2012021864A2 (en) 2012-02-16
US20170243219A1 (en) 2017-08-24
AU2011289180B2 (en) 2015-05-28
CA2958140A1 (en) 2012-02-16
IL224685A (en) 2017-04-30
US20170243218A1 (en) 2017-08-24
AU2015315602A1 (en) 2017-04-06
CA2958140C (en) 2019-05-07
CA2915867A1 (en) 2012-02-16
EP2603892A2 (en) 2013-06-19
SG10201506319WA (en) 2015-09-29
CA2915867C (en) 2018-03-13
WO2012021864A3 (en) 2012-04-19
US20120143752A1 (en) 2012-06-07
AU2015213354B2 (en) 2017-03-16
EP2603892A4 (en) 2015-09-02
AU2011289180A1 (en) 2013-03-14
CA2823685C (en) 2017-03-07
CA2823685A1 (en) 2012-02-16

Similar Documents

Publication Publication Date Title
US10068220B2 (en) Systems and methods for brokered authentication express seller links
US8600883B2 (en) Mobile barcode generation and payment
US9805368B2 (en) End-to end secure payment processes
US9262781B2 (en) System and method for facilitating secure self payment transactions of retail goods
US10275764B2 (en) Transaction data tokenization
AU2008201859B2 (en) Distributed System for Commerce
US8028896B2 (en) Authentication methods for use in financial transactions and information banking
US9390412B2 (en) Dynamic point of sale system integrated with reader device
KR20090045400A (en) Method and system for processing internet purchase transactions
US20130346302A1 (en) Remote Portal Bill Payment Platform Apparatuses, Methods and Systems
US20140122331A1 (en) System and Method for Providing a Security Code
US20110208659A1 (en) Method and apparatus for making secure transactions using an internet accessible device and application
KR20150082564A (en) Electronic wallet apparatus, method, and computer program product
US10235692B2 (en) Consumer presence based deal offers
US20120166311A1 (en) Deferred payment and selective funding and payments
US20060273155A1 (en) System and method for on-line commerce operations
US20140351006A1 (en) System and method for generating and utilizing global information from transaction records
US9965757B2 (en) Method and system for controlling access to a financial account
US20130054336A1 (en) System and method for incorporating one-time tokens, coupons, and reward systems into merchant point of sale checkout systems
KR20130086205A (en) Smart wallet
US20150348006A1 (en) Smart wallet
US10387862B2 (en) Methods and systems for wallet enrollment
US20140058938A1 (en) eWallet choice
US20100114773A1 (en) Systems, Methods, And Apparatus For Using A Contactless Transaction Device Reader With A Computing System
US20130304642A1 (en) System and Method for Using Intelligent Codes to Add a Stored-Value Card to an Electronic Wallet

Legal Events

Date Code Title Description
AS Assignment

Owner name: MASTERCARD INTERNATIONAL INCORPORATED, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MOSER, SCOTT;DHALA, AMYN MOHAMED;LIM, DAVID JAMES;AND OTHERS;SIGNING DATES FROM 20141001 TO 20150623;REEL/FRAME:036107/0725

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION