System and method for providing software-based contactless payment

[0001] This application claims priority to U.S. Provisional Patent Application No. 61/547,910, filed Oct. 17, 2011, which is hereby incorporated by reference in its entirety.

[0002] The present disclosure relates to a system and method for providing a software-based approach to contactless payments.

[0003] Near Field Communications, or NFC, allows for wireless communication between two devices in close proximity to each other. Many smartphones contain embedded NFC chips that can send encrypted data a short distance (“near field”) to a reader located, for instance, next to a retail cash register. To complete a payment transaction, a customer must have their credit card information stored in a secure element of an NFC-enabled smartphone. This hardware-based solution presents numerous complications for a credit card issuer.

[0004] These and other drawbacks exist.

[0005] Various embodiments of the disclosure provide systems and methods for software-based contactless payment. In an exemplary embodiment, a method for software-based contactless payment includes providing, via a network, a token to a mobile device of a customer for use with a transaction, receiving, via a network, the token in association with a transaction, and processing the token using a processor to determine whether to authorize the transaction.

[0006] The method may further include communicating, via a network, an authorization decision to the merchant and/or receiving, via a network, a request for the token from the customer. In various embodiments, the token may be received as track data in a credit card transaction. The method may further include receiving an identifier associated with the mobile device; and utilizing the identifier in the authorization determination.

[0007] A system for software-based contactless payment may include a token manager that generates a token and provides the token to a mobile device of a customer for use with a transaction, a communication interface that receives the token in association with a transaction, and a processor that processes the token using to determine whether to authorize the transaction.

[0008] The system may also include a payment processor to process the transaction and/or a database that stores a list of provided tokens, and wherein the authorization determination is based on a comparison of the received token to the list of provided tokens. The token manager may receive an identifier associated with the mobile device, and the processor may utilize the identifier in the authorization determination.

[0014] The following description is intended to convey a thorough understanding of the embodiments described by providing a number of specific exemplary embodiments and details involving systems and methods for providing a software-based approach to contactless payment. It should be appreciated, however, that the present disclosure is not limited to these specific embodiments and details, which are exemplary only. It is further understood that one possessing ordinary skill in the art, in light of known systems and methods, would appreciate the use of the invention for its intended purposes and benefits in any number of alternative embodiments, depending on specific design and other needs. A financial institution and system supporting a financial institution are used as examples for the disclosure. The disclosure is not intended to be limited to financial institutions only.

[0015] According to the various embodiments of the present disclosure, systems and methods are provided to enable a software-based approach to contactless payments. Such embodiments may provide, for example, a token-based, dynamic solution to contactless payments. In various embodiments, the token-based solution could be provided in an online environment, whereby, for example, a mobile device such as a smartphone could receive a token in “real-time” or near “real-time” via a communication network. The token-based solution could also be used in an offline manner, whereby a previously-provided token could be used for a certain period of time, regardless of whether the smartphone is connected to a communication network at the time of use. This token-based solution could eliminate the need for storing a credit card number and a cv code, for example, within a secure element on a smartphone. In effect, the tokens could serve as single-use, or limited-use credit card numbers.

[0016] The token-based solution could also allow credit-card issuers, for example, or any other token-issuer to set different types of parameters around the token. For example, transaction limits, use limits, time limits, and the like could be applied to the tokens. In other words, exemplary tokens could apply only to transactions of $100 or less, and/or only to 3 separate transactions before it expires, and only for 3 days.

[0017] In various embodiments, a token may be, for example, a multifaceted token, which may include, for example, numbers, letters and/or symbols that can be displayed on and/or typed into a mobile device. For example, the token could be a six- or eight-digit number re alphanumeric combination. The token may be randomly generated by a token manager or other entity for use by the token manager.

[0018] FIG. 1 depicts an exemplary system 100 for use with the token-based software solution for contactless payment. As depicted in FIG. 1, system 100 may include a mobile device 102. Mobile device 102 may be any mobile device capable of executing the software-based solution for contactless payment. For example, mobile device 102 could be an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS operating system, any device running Google's Android® operating system, any device running Microsoft's Windows® Mobile operating system, and/or any other smartphone or like device.

[0019] Mobile device 102 may include for example, a Subscriber Identity Module (SIM) card 104, an NFC module 106, and an App Processor. SIM card 104 may be an integrated circuit that securely stores the service-subscriber key (IMSI) used to identify a subscriber on mobile telephony devices (such as mobile phones and computers). NFC module 106 may be an embedded NFC chip that can send encrypted data a short distance (“near field”) to a reader located, for instance, next to a retail cash register. App Processor 108 may enable execution of software applications on mobile device 102. In various embodiments, app processor 108 may cooperate with NFC module 106 to enable a software-based approach to contactless payment using mobile device 102.

[0020] Mobile device 102 may also include various software components to facilitate software-based contactless payments. For example, mobile device 102 may include an operating system such as, for example, the iOS operating system from Apple, the Google Android operating system, and the Windows Mobile operating system from Microsoft. Mobile device 102 may also include, without limitation, software applications such as mobile banking applications to facilitate software-based contactless payment, an NFC application programming interface, and software to enable touch sensitive displays. Mobile device manufacturers may provide software stacks (APIs) which allow software applications to be written on top of the software stacks. For example, mobile device manufacturers may provide, without limitation, a card emulation API to enable NFC card emulation mode, a logic link control protocol (LLCP) API for peer-to-peer communication between mobile devices, and a real-time data (RTD) API and a NFC Data Exchange Format (NDEF) API for reading/writing.

[0021] FIG. 2 also depicts an exemplary system 200 for use with the token-based software solution for contactless payment. System 200 may include a mobile device 202. Mobile device 202 may include a display 204 which may display software, including software applications, executing on mobile device 202. By way of a non-limiting example, one of the software applications executing on mobile device 204 may include a mobile payments application 206. In various exemplary embodiments, mobile payments application 206 may enable a software-based solution to contactless payments. A user may select mobile payments application 206, by for example, touching display 204, which may then launch or otherwise cause the execution of mobile payments application 206.

[0022] FIG. 3 depicts an exemplary system 300 for use with the token-based software solution for contactless payment. System 300 may include an issuer system 302, a mobile device 304, a network 306, and a merchant system 308. In various embodiments, mobile device 304 may be similar to those described above with respect to FIGS. 1 and 2.

[0023] Network 306 may enable communication between mobile device 304, issuer 302, and merchant 308. For example, Network 306 may be one or more of a wireless network, a wired network or any combination of wireless network and wired network. For example, network 105 may include one or more of a fiber optics network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless LAN, a Global System for Mobile Communication (“GSM”), a Personal Communication Service (“PCS”), a Personal Area Network (“PAN”), D-AMPS, Wi-Fi, Fixed Wireless Data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g or any other wired or wireless network for transmitting and receiving a data signal.

[0024] In addition, network 306 may include, without limitation, telephone lines, fiber optics, IEEE Ethernet 902.3, a wide area network (“WAN”), a local area network (“LAN”), or a global network such as the Internet. Also network 306 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network 105 may further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. Network 306 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 306 may translate to or from other protocols to one or more protocols of network devices. Although network 306 is depicted as a single network, it should be appreciated that according to one or more embodiments, network 306 may comprise a plurality of interconnected networks, such as, for example, the Internet, a service provider's network, a cable television network, corporate networks, and home networks.

[0025] Issuer system 302 may include, for example, a token manager 314, an account database 316, a communication module 318, and an authorization module 320. Token manager may generate, maintain, and provide information relating to the tokens used in the software-based solution for contactless payments. In various embodiments, token manager 314 may be integrated into issuer system 302 as depicted in FIG. 3. Token manager 314 may also be a third-party system that works in cooperation with issuer system 302 to generate, maintain, and provide tokens for use in the software-based solution for contactless payments. Account database 316 may maintain information relating to the accounts of customers associated with an issuer. As referred to herein, an issuer may include, for example, a credit card issuer, or any other issuer of tokens for contactless payment. Account database 316 may also include an association of tokens with respective customers. For example, account database 316 may include an association of a token “123456” with account number “1234 5678 9012 3456,” which belongs to John Q. Cardholder. As will be described in more detail below, account database 316 may be accessed for authorizing transactions and or payment requests.

[0026] Communication module 318 may enable communication between the components of system 300. Communication module 318 may include hardware, software, and firmware that may enable communication between an issuer system 302 and other components of system 300 using network 306, for example.

[0027] Authorization module 320 may include business logic used to determine whether a transaction or payment request should be authorized. For example, authorization module 320 may include executable programs that determine whether the token is associated with the correct mobile device and/or issuer account and whether the token use is within the limiting parameters before authorizing a particular transaction. Authorization module 320 may cooperate with communication module 318 to communicate authorization decisions to merchant 308 and/or mobile device 304.

[0028] Merchant 308 may include a Point of Sale (PoS) device 312 and a payment processing system 310. In various embodiments, PoS 312 may be any device that may receive NFC communication, for example and can be utilized to process payment transactions. PoS device 312 may be for example, PoS devices made by VeriFone® and/or any other like devices. As illustrated in FIG. 3 by the dotted line connecting mobile device 304 to PoS device 312, mobile device 304 may be communicatively coupled with PoS device 312 using near field communication, or NFC.

[0029] Payment processing system 310 may allow merchant 308 to request and process payments, for example. Payment processing system 310 may utilize network 306 to communicate payment requests to issuer system 302 and receive authorization requests. In doing so, payment processing system 310 may transmit information to issuer system 302 using, for example, networks maintained by Visa®, MasterCard®, Discover®, American Express® and the like. Also, payment processing system 310 may be capable of communicating token information using data standards defined by the above-described networks as will be describe in detail below.

[0030] FIG. 4 depicts an exemplary method 400 for a software-based approach to contactless payment. Method 400 may begin in block 401.

[0031] In block 402, a customer may initiate a request for a token. In various embodiments, a customer may utilize a mobile device enables for software-based contactless payment to “tap” a PoS device, for example to initiate the request for a token at the time of a transaction. A customer may also initiate a request by requesting a token through a mobile payments application using a mobile device. In various embodiments, a customer may request a token before or at the time of purchase to enable or facilitate the customer's purchase. A customer may use a software application, such as a mobile banking or like application to facilitate the request for a token. To access the software application, a user may be required to enter a personal identification number (PIN) to unlock the access and/or unlock the software application. The customer may also present responses to multifactor authentication requests or challenges. In this way, the token associated with a PIN and/or multifactor authentication may provide additional security for a transaction.

[0032] In block 403, the token may be sent to a customer's mobile device. For example, a token manager may send a token to mobile device using a communication network and/or various communications similar to those described in FIG. 3. Also, a token manager may transmit a token to a mobile device via, for example, authorization networks and/or a network associated with a PoS device. The token may be received at the mobile device and then processed by a software application executing on the mobile device to facilitate software-based contactless payment. The software application may, for example, display the token to the customer on the mobile device.

[0033] In block 404, a customer may provide the token to a PoS device. This token could be provided at the time of purchase. For example, a could input the token on a keypad of the PoS device. The customer may also utilize the NFC features on the mobile device to transmit the token to the PoS device wirelessly. Upon receipt of the token at the mobile device, the token may be displayed to the customer and then the customer may touch a “transmit” button appearing on the display of the mobile device to transmit the token via NFC. Other methods of communicating the toke may be used.

[0034] Upon receipt of the token, the merchant, using a payment processing system, for example, in cooperation with the PoS device, may format the token into a data format that may be utilized by one of the various authorization networks. For example, an exemplary 6-digit token may be inserted into one of the “tracks” of data utilized by the Visa or other authorization networks to transmit and receive data. A token may also be transmitted in a data packet via a communication network associated with a merchant, for example. In various embodiments, a customer may be required to input a PIN and/or respond to a multifactor authentication challenge before transmitting or providing the token to a PoS device.

[0035] In block 405, the merchant may send the token to the issuer for authorization. For example, the merchant may send a token to the issuer using a communication network and/or various communications similar to those described in FIG. 3.

[0036] In block 406, the issuer and/or token manager may verify the token and/or transaction utilizing the token. For example, the issuer may use the token to look up the account of the customer and determine whether the transaction should be authorized. The issuer and/or token manager may also check the token against certain parameters to determine, for example, whether the transaction complies with certain parameters or the token has expired. In various embodiments, the issuer and/or token manager may receive and utilize location information or identification information associated with the customers mobile device to determine whether to authorize the transaction. For example, the issuer and/or token manager may receive and utilize the MAC address of a smartphone and/or the merchant location to determine whether to authorize the transaction.

[0037] In block 407, the issuer and/or token manager may communicate the authorization to the merchant. The authorization may indicate, for example, that the token provided by the customer matches the token provided to the customer upon request by the customer and/or the token matches a limited use token. The authorization may also indicate that the customer may have sufficient funds to make a purchase.

[0038] In block 408, the transaction may be processed. For example, the transaction may be processed by an issuer to post the transaction to the customer's account and ensure payment to the merchant.

[0039] In the preceding specification, various preferred have been described with references to the accompanying drawings. Although the above description references an “issuer” it will be understood that the term issuer could apply to issuers of credit, debit, and like payment mechanisms. It will also be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded as an illustrative rather than restrictive sense.