Patent Publication Number: US-2019180286-A1

Title: System and method for providing software-based contactless payment

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     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. 
    
    
     FIELD OF THE DISCLOSURE 
     The present disclosure relates to a system and method for providing a software-based approach to contactless payments. 
     BACKGROUND OF THE DISCLOSURE 
     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. 
     These and other drawbacks exist. 
     SUMMARY OF THE DISCLOSURE 
     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. 
     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. 
     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. 
     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. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Various embodiments of the present disclosure, together with further objects and advantages, may best be understood by reference to the following description taken in conjunction with the accompanying drawings, in the several Figures of which like reference numerals identify like elements, and in which: 
         FIG. 1  depicts an exemplary embodiment of a contactless payment system; 
         FIG. 2  depicts an exemplary embodiment of a contactless payment system; 
         FIG. 3  depicts an exemplary embodiment of a contactless payment system; and 
         FIG. 4  depicts an exemplary method for contactless payment. 
     
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
     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. 
     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. 
     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. 
     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. 
       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&#39;s iOS operating system, any device running Google&#39;s Android® operating system, any device running Microsoft&#39;s Windows® Mobile operating system, and/or any other smartphone or like device. 
     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 . 
     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. 
       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 . 
       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 . 
     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. 
     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&#39;s network, a cable television network, corporate networks, and home networks. 
     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. 
     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. 
     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 . 
     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. 
     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. 
       FIG. 4  depicts an exemplary method  400  for a software-based approach to contactless payment. Method  400  may begin in block  401 . 
     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&#39;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. 
     In block  403 , the token may be sent to a customer&#39;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. 
     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. 
     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. 
     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 . 
     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. 
     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. 
     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&#39;s account and ensure payment to the merchant. 
     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.