(en)Disclosed herein are systems, methods, and non-transitory computer-readable storage media for transmitting, as part of a polling loop, a value added services (VAS) command that includes capability data corresponding to a payment terminal. For example, the payment terminal can transmit a VAS command that advertises the payment terminal's capabilities as part of a polling loop. The payment terminal can listen for a response to the VAS command and, after receiving a response, the payment terminal may initiate a VAS protocol. The VAS command can also specify a mode in which the payment terminal is operating, such as a payment-only mode, a VAS mode, a payment-plus-VAS mode, etc.

1.ApplicationNumber: US-201615170724-A
1.PublishNumber: US-2016358159-A1
2.Date Publish: 20161208
3.Inventor: KHAN AHMER ALI
TUCKER BRIAN J.
CHUNG Ho Cheung
LINDE JOAKIM
ROSEN ZACHARY A.
SCOTT Gordon Y.

4.Inventor Harmonized: KHAN AHMER ALI(US)
TUCKER BRIAN J(US)
CHUNG Ho Cheung(US)
LINDE JOAKIM(SE)
ROSEN ZACHARY A(US)
SCOTT GORDON Y(US)

5.Country: US
6.Claims:
(en)Disclosed herein are systems, methods, and non-transitory computer-readable storage media for transmitting, as part of a polling loop, a value added services (VAS) command that includes capability data corresponding to a payment terminal. For example, the payment terminal can transmit a VAS command that advertises the payment terminal's capabilities as part of a polling loop. The payment terminal can listen for a response to the VAS command and, after receiving a response, the payment terminal may initiate a VAS protocol. The VAS command can also specify a mode in which the payment terminal is operating, such as a payment-only mode, a VAS mode, a payment-plus-VAS mode, etc.

7.Description:
(en)CROSS-REFERENCE TO RELATED APPLICATION
This application claims priority to: U.S. Provisional Patent Application No. 62/171,851, entitled “Value Added Services Polling,” filed Jun. 5, 2015, the entire contents of which are incorporated herein by reference.


FIELD
The present disclosure relates to short-range communications between an object and a terminal, including to a near field communication terminal that can inform a communication device of enabled features.
BACKGROUND
Existing near-field communication (NFC) payment terminals operate according to a standard provided by Europay, MasterCard, Visa (EMVCo). This standard involves a Layer 1 transaction wherein the reader executes a polling loop that advertises available communication protocols, and when one of those advertisements is responded to, performs a handshake between the NFC terminal and a portable communication device. The standard also includes a Level 2 transaction wherein a specific payment-processing kernel is executed (e.g., Visa, MasterCard, Amex, etc.).
SUMMARY
Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.
Disclosed are systems, methods, and non-transitory computer-readable storage media for transmitting, as part of a polling loop, a value added services (VAS) command that includes capability data for the payment terminal.
In some embodiments of the present technology, a payment terminal can transmit a VAS command that advertises the payment terminal's capabilities as part of a polling loop. The payment terminal can listen for a response to the VAS command and, after receiving a response, the payment terminal can initiate a VAS protocol. The VAS command can also specify a current or present mode in which the payment terminal is operating. For example, the payment terminal can be currently operating in a payment-only mode, a VAS mode, a payment-plus-VAS mode, etc.
In some embodiments, the payment terminal can store instructions including Level 1 polling instructions and Level 2 instructions effective to transmit and receive communications according to one of a plurality of protocols that includes a VAS protocol. The instructions can cause the payment terminal to directly enter the VAS protocol upon initiation of the Level 2 instructions.
In some embodiments a communication device can receive a VAS command from a payment terminal and can detect the payment terminal capabilities data that was transmitted within the VAS command. Based at least in part on the detected payment terminal capabilities data, the communication device can prepare to initiate a transaction with the payment terminal and can initiate a transaction with the payment terminal by responding to the VAS command. For example, preparing to initiate a transaction with the payment terminal can include configuring the communication device to operate in accordance with an appropriate VAS protocol that corresponds to the VAS command.



BRIEF DESCRIPTION OF THE DRAWINGS
In order to describe the manner in which the above-recited features, and other advantages and features, of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:
FIG. 1A illustrates an example method of polling for devices that have value added services (VAS) capabilities;
FIG. 1B illustrates an example of a payment terminal configured with Level 1 polling kernels and Level 2 payment kernels;
FIG. 1C illustrates an example of information transmitted by the VAS-Up kernel;
FIG. 2 illustrates an example method of waiting to determine whether a VAS-Up command is detected before initiating a payment transaction;
FIG. 3 illustrates a system for discovering a payment terminal's capabilities and performing a VAS transaction; and
FIG. 4A and FIG. 4B illustrate exemplary possible system embodiments.



DETAILED DESCRIPTION
Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure.
The present disclosure addresses the need in the art for a payment terminal having the ability to perform a polling loop to communicate its capabilities to other communication devices. Systems, methods and non-transitory computer-readable media are disclosed which transmit, as part of a polling loop, a value added services (VAS) command that includes capability data for the payment terminal. Also, systems, methods, and non-transitory computer-readable media are disclosed which receive and respond to a VAS command that includes capability data for the payment terminal.
Payment terminals can communicate with an electronic device using a contactless communication interface and a radio link with a contactless communication interface of the electronic device. For example, a payment terminal can use near field communication (NFC) technology to communicate with an NFC-enabled device, e.g., having a storage medium that contains encrypted payment information. According to the present technology, the payment terminal can also be configured to perform one or more additional value added services. For example, in addition to storing payment information, an electronic device can store information relating to one or more consumer loyalty programs. A consumer loyalty program can provide advantages to a consumer, such as affecting a price of an item, resulting in the accrual of loyalty points, trigger special offers, etc.
Payment terminals can also operate in a variety of modes depending on a number of factors including the type of transaction, the type of merchant, a customer preference, etc. For example, in some cases, a payment terminal can be in a VAS-only mode and can perform VAS-only transactions (e.g., determining whether the consumer is entitled to redeem a loyalty reward) before subsequently processing a payment. Also, a terminal can be in a VAS-plus-payment mode and can perform a VAS-transaction and a payment transaction in a single interaction, e.g., using a loyalty card to obtain deals and automatically processing a payment using a card linked with the loyalty program. In some cases, a payment terminal that is VAS-enabled can also operate in a Payment-only mode.
As introduced above, there is a need for a payment terminal to be able to communicate its capabilities to an NFC-enabled device before a handshake between the payment terminal and the device. This allows the device communicating with the terminal to prepare to transmit the appropriate VAS information and/or payment information, depending on whether the payment terminal supports VAS transactions and depending on the mode in which the payment terminal is operating. Accordingly, some embodiments of the present technology introduce a VAS command that also includes a message advertising the payment terminal's capabilities into the payment terminal's polling loop. The VAS command can be read by a payment device, but a handshake with the payment device may not be initiated until the payment device responds to the VAS command. By causing the terminal to wait for a response to the VAS command, the electronic device may be able to prepare to perform a VAS transaction with the payment terminal according to the mode in which the payment terminal is operating. FIG. 1 illustrates an example method 100 of polling for devices that have VAS capabilities, according to some embodiments of the present technology.
As illustrated in FIG. 1A , the method can progress through two levels, Level 1 and Level 2. In some embodiments these levels can correspond to a standard established by EMVCo for processing payment transactions using an NFC card reader and an NFC-enabled payment object. The EMVCo standard sets forth that, in Level 1, a payment terminal can advertise communication protocols supported by the card reader in a polling loop. These protocols can be advertised as commands, such as a Wake-Up-A command or Wake-Up-B command, corresponding to communication protocols A & B, respectively. Other protocols, such as Type-F (of FeliCa) also can be supported. Once a card or other NFC-enabled object responds to one of the advertised communication protocols, the card reader and NFC-enabled object may initiate a communication session using the communication protocol that is designated in the advertised command. The EMVCo standard sets forth that, in Level 2, one or more payment kernels can be advertised, e.g., kernels for Visa, MasterCard, AMEX, etc. The NFC-enabled object can respond to the advertisement corresponding to the issuer of the payment object that is to be used in the transaction.
The present technology can work within existing standards, but can add an additional advertisement to the Level 1 polling loop, herein called a VAS-Up command or VAS command. The VAS-Up command can utilize an existing communication protocol, such as communication protocol Type-A (or Type-B or Type-F), but also include additional data. An NFC-enabled object that also supports VAS can respond to the VAS-Up command, if it is available. The present technology can also utilize a new kernel added to Level 2 for VAS.
The method 100 of FIG. 1A involves a payment terminal performing a polling loop 105 as part of Level 1 to advertise the type(s) of communication protocol(s) supported by the payment terminal. The polling loop can involve advertising a communication standard by transmitting commands using the advertised protocol(s) and listening for responses. A response can indicate that a device is trying to communicate with the payment terminal using the standard that was last advertised by the payment terminal. One example standard known to those of skill in the art, ISO14443, defines at least two communication standards—type A and type B. Additionally, as recognized by the present technology, further poll signals can be employed to communicate that the terminal has certain other capabilities. For example, a VAS-Up command can be used to specify that the terminal supports VAS. The VAS-Up command can also be used to specify a mode the terminal is operating in, e.g., VAS-only mode, VAS-plus-payment mode, payment only mode, etc.
The polling loop can iterate until an electronic device is brought into communication range, receives a command, and responds to the command to indicate that the electronic device understands a protocol used to communicate the command. For example, the polling loop can involve transmitting a Wake-Up A command, waiting for a predetermined period of time for a response, transmitting a Wake-Up B command, waiting for a predetermined period of time for a response, transmitting a VAS-Up command, waiting for a predetermined period of time for a response, and iterating the steps until a response is received. In other implementations, different sequences can be employed involving more, fewer, and/or different protocols, different transmissions, different periods, etc.
FIG. 1B illustrates an example of a payment terminal 199 configured with Level 1 polling commands and Level 2 payment kernels according to some embodiments of the present technology. The Level 1 polling commands can include a Wake-Up A command 197 , a Wake-Up B command 196 , and a VAS-Up command 195 . In other implementations, more, fewer, or different polling commands can be used. The Level 2 payment kernels can include, for example, a VISA kernel 194 , a MasterCard kernel 193 , an American Express kernel 192 , a crypto-currency kernel 191 , and one or more further payment processing kernels 190 that are now known or developed later. In other implementations, more, fewer, or different payment kernels can be used.
The EMVCo standard can also involve certifying payment terminals before they are authorized to process a payment. In some embodiments of the present technology, the VAS-Up command 195 can be added to a certified payment terminal without the need to have the terminal re-certified by EMVCo. For example, the VAS-Up command 195 can be added to the payment terminal and the payment terminal can be configured to transmit a VAS-Up command having a standard ISO format with an extra byte that indicates that the payment terminal can perform VAS transactions and indicating the VAS mode in which the terminal is operating. Likewise, a VAS transaction command 180 can be added to the Level 2 kernels for performing Level 2 VAS transactions.
FIG. 1C illustrates an example of a byte 189 transmitted in the VAS-Up command 195 . As illustrated, the byte 189 specifies the mode that the terminal is operating in, e.g., VAS-only mode, VAS-plus-payment mode, payment only mode, etc.
Referring again to FIG. 1A , Level 1 of the method 100 can involve receiving a response to the VAS-Up command 110 from a device 120 and performing a handshake with the device 120 to set up a VAS session. Additionally, Level 1 of the method 100 can involve receiving a response to the Wake-Up A or Wake-Up B commands 115 , performing a handshake 116 , performing one or more other loyalty transactions 117 , performing a VAS transaction 118 and progressing to a Level 2 payment polling loop 155 as discussed below.
When a VAS session is set up, e.g., after receiving a response to the VAS-Up command 110 and performing a handshake with a device 120 , method 100 may involve executing a VAS kernel as part of the Level 2 services. Executing a VAS kernel can involve transmitting a VAS identifier (e.g., a merchant identifier) to the electronic device, receiving VAS data (e.g., loyalty card information for a merchant associated with the merchant identifier) and performing a VAS transaction 135 according to the mode in which the terminal is operating. (Note that a benefit of the terminal receiving a response to the VAS-UP command is that it can go directly to a VAS protocol and can bypass all ‘other’ loyalty protocols.)
When the terminal is in a VAS only mode, executing the VAS kernel 135 can involve performing a VAS transaction (e.g., determining that the customer is entitled to a free or discounted item) and resetting the communication field 145 .
When the terminal is in a VAS-plus-payment mode, executing the VAS kernel 135 can involve performing a VAS transaction (e.g., applying a discount per a loyalty program), resetting the communication field 150 , and progressing to a Level 2 payment polling loop 155 .
The ISO14443 standard also specifies a Level 2 transaction in which a specific payment-processing kernel is executed (e.g., Visa, MasterCard, Amex, etc.). Accordingly, the payment polling loop 155 can involve polling the device with payment type commands corresponding to the supported payment-processing kernels. Note that method 100 may involve receiving a response to the payment polling command 160 and performing a handshake 165 to set up a payment session. Once the payment session is set up, method 100 can involve performing a payment transaction 170 and resetting the communication field 145 .
FIG. 2 illustrates an example of a method 200 in which an electronic device listens for a VAS-Up command 205 , detects another known communication protocol command 210 , and waits to determine whether a VAS-Up command is detected 215 . For example, waiting to determine whether a VAS-Up command is detected 215 can involve receiving and not responding to one or more protocol commands until the VAS-Up command is detected or until the known communication protocol command is received a subsequent time (e.g., a second time) without having detected a VAS-Up command. For example, an electronic device can wait until it either receives a VAS-Up command or has observed at least one complete polling loop before responding. In another example, waiting to determine whether a VAS-Up command is detected 215 can involve waiting a predetermined period of time. In other examples, waiting to detect a VAS-Up command can include both waiting a predetermined period of time and detecting a known command at least twice.
When a VAS-Up command is detected, method 200 may involve determining the terminal's capabilities 220 based on data transmitted as part of the VAS-Up command (as shown in FIG. 1C for example) and preparing the device for a VAS transaction 225 . For example, preparing the device for a VAS transaction can involve the device activating an application that stores VAS data, caching one or more frequently used VAS loyalty card, etc.
Next, the method involves performing a VAS transaction 230 . When a VAS protocol signal is not detected, method 200 may involve performing a payment transaction using the known payment protocol 235 . Note that the VAS transaction may be performed prior to the payment transaction.
FIG. 3 illustrates an example of a system 300 for sending VAS commands between a payment terminal 310 and an electronic device 320 , e.g., to discover the terminal's 310 and the device's 320 respective capabilities, as well as performing a VAS transaction according to some embodiments of the present technology. The payment terminal 310 includes a processor 311 , a contactless communications interface 315 , and a storage medium 313 having instructions stored thereon for performing a polling loop and for performing VAS and payment transactions. In some embodiments, the instructions cause the payment terminal to transmit VAS commands as part of the polling loop. The VAS commands can include a VAS protocol signal that specifies a mode that the payment terminal is operating in, e.g., VAS-only transaction mode, VAS-plus-payment transaction mode, etc.
Note that electronic device 320 can be any device configured to communicate with the contactless network interface 315 . For example, electronic device 320 can be a phone, a smart phone, a wearable electronic device, a tablet computer, a notebook (or laptop) computer, any other such portable computing device, a programmable universal card, etc.
Moreover, electronic device 320 includes a processor 321 , a communications interface 325 , and a storage medium 323 having instructions stored thereon for detecting payment and VAS-Up commands, and for performing VAS and payment transactions. When electronic device 320 detects a known payment protocol signal poll, electronic device 320 can wait to determine whether a VAS-Up command is subsequently detected. If a VAS-Up command is detected, electronic device 320 can determine the payment terminal's 310 capabilities, prepare for a VAS transaction, and initiate a VAS transaction by responding to payment terminal 310 with a VAS protocol signal. Furthermore, electronic device 320 can perform the VAS transaction before performing a payment transaction.
FIG. 4A and FIG. 4B illustrate examples of possible system embodiments. Persons of ordinary skill in the art will also readily appreciate that other system embodiments are possible.
FIG. 4A illustrates an example of a system-bus computing system architecture 400 in which the components of the system are in electrical communication with each other using a bus 405 . In particular, system 400 may include a processing unit (CPU or processor) 410 and a system bus 405 that couples various system components including system memory 415 , such as read-only memory (ROM) 420 and random-access memory (RAM) 425 , to processor 410 . Moreover, system 400 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of processor 410 . Furthermore, system 400 can copy data from memory 415 and/or storage device 430 to cache 412 for quick access by processor 410 . In this way, cache 412 can provide a performance boost that avoids processor 410 delays while waiting for data. These and other modules can control or be configured to control processor 410 to perform various actions. Other system memory 415 may be available for use as well. Note that memory 415 can include multiple different types of memory with different performance characteristics. In addition, processor 410 can include any general purpose processor and a hardware module or software module, such as module 1 432 , module 2 434 , and module 3 436 stored in storage device 430 , configured to control processor 410 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 410 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.
To enable user interaction with computing device 400 , an input device 445 can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. Moreover, an output device 435 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with computing device 400 . Furthermore, communications interface 440 , including NFC interface 442 , can generally govern and manage the user input and system output. For example, via NFC interface 442 , system 400 may receive a VAS command as part of a polling loop, where the VAS command includes payment terminal capabilities data that allows system 400 to determine whether the payment terminal supports VAS operation. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.
Storage device 430 may be a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random-access memories (RAMs) 425 , read-only memory (ROM) 420 , and hybrids thereof.
Additionally, storage device 430 can include software modules 432 , 434 , 436 to control processor 410 . Other hardware or software modules are contemplated. Note that storage device 430 can be connected to system bus 405 . In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 410 , bus 405 , display 435 , and so forth, to carry out this and/or other functions.
FIG. 4B illustrates an example of a computer system 450 having a chipset architecture that can be used in executing the described method and generating and displaying a graphical user interface (GUI). Computer system 450 is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology. System 450 can include a processor 455 , representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Processor 455 can communicate with a chipset 460 that can control input to and output from processor 455 . In this example, chipset 460 outputs information to output 465 , such as a display, and can read and write information to storage device 470 , which can include magnetic media, and solid state media, for example. Chipset 460 can also read data from and write data to RAM 475 . A bridge 480 for interfacing with a variety of user-interface components 485 can be provided for interfacing with chipset 460 . Such user interface components 485 can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on. In general, inputs to system 450 can come from any of a variety of sources, machine generated and/or human generated.
Chipset 460 can also interface with one or more communication interfaces 490 that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. For example, via NFC interface 492 , computer system 450 may receive a VAS command as part of a polling loop, where the VAS command includes payment terminal capabilities data that allows computer system 450 to determine whether the payment terminal supports VAS operation. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or may be generated by the machine itself, e.g., by processor 455 , to analyze data stored in storage 470 or 475 . Furthermore, the machine can receive inputs from a user via user-interface components 485 and may execute appropriate functions, such as browsing functions by interpreting these inputs using processor 455 .
It can be appreciated that systems 400 and 450 can have more than one processor 410 or be part of a group or cluster of computing devices networked together to provide greater processing capability.
For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.
In some embodiments the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.
Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to the described embodiments, may include: magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.
Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.
The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.
Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.
The various embodiments described above are provided by way of illustration only and should not be construed to limit the scope of the disclosure. Those skilled in the art will readily recognize various modifications and changes that may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.