阅读说明：本技术 处理支付 (Processing payments ) 是由 马尼卡瓦萨甘·嵩抹孙达冉 于 2018-07-02 设计创作，主要内容包括：一种操作支付终端的方法,所述方法包括：接收激活输入,并且响应于此,输出用于与第一类型的外部支付设备进行通信的第一无线信号、以及用于与第二类型的外部支付设备进行通信的第二无线信号。所述第一无线信号和所述第二无线信号被以各自互不相同的第一协议和第二协议来格式化。所述方法进一步包括：接收对所述第一无线信号和所述第二无线信号中的一者的应答,并响应于所述应答,终止输出所述第一无线信号和所述第二无线信号中的另一者。(A method of operating a payment terminal, the method comprising: an activation input is received and, in response thereto, a first wireless signal for communicating with a first type of external payment device and a second wireless signal for communicating with a second type of external payment device are output. The first wireless signal and the second wireless signal are formatted in a first protocol and a second protocol, respectively, that are different from each other. The method further comprises: receiving an acknowledgement to one of the first wireless signal and the second wireless signal, and terminating outputting the other of the first wireless signal and the second wireless signal in response to the acknowledgement.)

1. A method of operating a payment terminal, the method comprising: -receiving an activation input and, in response thereto, outputting a first wireless signal for communication with an external payment device of a first type and a second wireless signal for communication with an external payment device of a second type, wherein the first and second wireless signals are formatted with respective mutually different first and second protocols, to receive an answer to one of the first and second wireless signals and, in response to the answer, to terminate outputting the other of the first and second wireless signals.

2. The method of claim 1, further comprising: processing the reply to authenticate the external payment device to establish a communication channel.

3. The method of claim 1, further comprising: processing the reply to authenticate the external payment device, and performing the terminating step after the processing step.

4. The method of claim 1, wherein the wireless signals comprise NFC signals and bluetooth signals.

5. The method of claim 1, further comprising: processing the reply to authenticate the external payment device to establish a communication channel, and receiving data indicative of a user from the communication channel; data indicative of the transaction amount is received at the input and the data indicative of the user and the data indicative of the transaction amount are transmitted to the server.

6. The method of claim 1, further comprising: processing the reply to authenticate the external payment device to establish a communication channel and receiving data indicative of the user and a one-time passcode identifying the current transaction from the communication channel; data indicative of the transaction amount is received at the input, and data indicative of the user, data indicative of the one-time passcode, and data indicative of the transaction amount are transmitted to the server.

7. The method of claim 6, further comprising: outputting a new one-time passcode over the communication channel.

8. The method of claim 1, further comprising: communicating information with a server indicating which of the first wireless signal and the second wireless signal is responsive.

9. A payment terminal for wireless communication with an external device, the payment terminal having a processing device and a memory means holding instructions for controlling the processing device to cause the payment terminal to output a first wireless signal for communication with a first type of external payment device and a second wireless signal for communication with a second type of external payment device in response to an activation input, wherein the first and second wireless signals are formatted in first and second protocols that are each different from one another, and to terminate output of one of the first and second wireless signals in response to receipt of a reply to the other of the first and second wireless signals.

10. The payment terminal of claim 9, further having: a keypad for providing an activation signal; a display for displaying information under control of the processing device; and an output device for communicating with the server.

11. The payment terminal of claim 9, having a first wireless device configured to output the first wireless signal under control of the processing device, and a second wireless device configured to output the second wireless signal under control of the processing device.

12. The payment terminal of claim 9, further having a security device comprising storage for a security key, the security device being configured to use the key to encrypt or decrypt data for use by the terminal.

13. The payment terminal of claim 9, having a personal area network device configured to output the first wireless signal.

14. The payment terminal of claim 9, having a near field communication device configured to output the second wireless signal.

Technical Field

The invention belongs to the technical field of payment.

Background

Cashless payments are becoming more and more frequently used, primarily because of convenience. Such payment may involve a card or a mobile phone. Internet connectivity is a limitation when using mobile phones to conduct cashless electronic transactions.

Even if the range of the internet is expanding, it cannot be determined whether the user using the mobile device is always connected to the internet. Moreover, the use of the internet may not be affordable to most societies in parts of the world. In such a case, it may not be feasible to complete the electronic transaction via the mobile phone.

Furthermore, often, merchants may have to deploy different types of payment terminals to support different types of digital payments. For example, a merchant may have to deploy a certain payment terminal to accept payment using a card. In addition, the merchant may have to deploy another terminal to support payment via the mobile phone. Even if such additional terminals are deployed, the terminals may only support mobile phones using a particular type of communication technology (such as NFC).

There is a need to improve this situation.

Disclosure of Invention

In a first aspect, a payment terminal is configured to output signals corresponding to two communication protocols or methods so that communication can occur when a device capable of responding to one of the two protocols or methods is in proximity to the terminal.

In a second aspect, a payment terminal is provided that is capable of communicating using two different communication methods. In use, the payment terminal outputs signals relating to both methods in order to initiate communication with a payment device, such as a mobile phone or payment card, by one of the two methods. When communication is established by one of the two methods, the other method is terminated.

In a third aspect, there is provided a method of operating a payment terminal, the method comprising: receiving an activation input and, in response thereto, outputting a first wireless signal for communication with a first type of external payment device and a second wireless signal for communication with a second type of external payment device, wherein the first and second wireless signals are formatted with respective mutually different first and second protocols to receive an answer to one of the first and second wireless signals and, in response to the answer, terminating outputting the other of the first and second wireless signals.

The method may further comprise processing the reply to authenticate the external payment device, thereby establishing a communication channel.

The method may further comprise processing the response to authenticate the external payment device and performing the terminating step after the processing step.

The wireless signals may include NFC signals and bluetooth signals.

The method may further comprise: processing the reply to authenticate the external payment device to establish a communication channel, and receiving data indicative of a user from the communication channel; data indicative of the transaction amount is received at the input and the data indicative of the user and the data indicative of the transaction amount are transmitted to the server.

The method may further comprise: processing the reply to authenticate the external payment device to establish a communication channel and receiving data indicative of the user and a one-time passcode identifying the current transaction from the communication channel; data indicative of the transaction amount is received at the input, and data indicative of the user, data indicative of the one-time passcode, and data indicative of the transaction amount are transmitted to the server.

The method may further include outputting a new one-time passcode over the communication channel.

The method may further include communicating information with a server indicating which of the first wireless signal and the second wireless signal is responsive.

In a fourth aspect, a payment terminal for wireless communication with an external device is disclosed, the payment terminal having a processing device and a memory device holding instructions for controlling the processing device to cause the payment terminal to output a first wireless signal for communication with a first type of external payment device and a second wireless signal for communication with a second type of external payment device in response to an activation input, wherein the first and second wireless signals are formatted in first and second protocols, respectively, that are different from each other, and to terminate outputting one of the first and second wireless signals in response to receiving a reply to the other of the first and second wireless signals.

The payment terminal may further include: a keypad for providing an activation signal; a display for displaying information under control of the processing device; and an output device for communicating with the server.

The payment terminal may further include: a first wireless device configured to output the first wireless signal under control of the processing device, and a second wireless device configured to output the second wireless signal under control of the processing device.

The payment terminal may further comprise a security device comprising storage means for a security key, the security device being configured to use the key to encrypt or decrypt data for use by the terminal.

The personal area network device may be configured to output a first wireless signal.

The near field communication device may be configured to output the second wireless signal.

In a fifth aspect, a system for processing payment is provided. The system comprises a payment terminal, wherein the payment terminal comprises a first wireless communication module and a second wireless communication module. The first module is capable of initiating and establishing proximity communication using a first communication method different from a second communication method. The second module is capable of initiating and establishing proximity communication using a second communication method. The payment terminal is configured to: receiving an input for initiating a transaction; causing the first module and the second module to attempt to initiate communication using their respective methods. An external entity with which communication is possible by one of the first and second methods may be in proximity to a payment terminal such that communication may be initiated between the payment terminal and the external entity depending on which communication module was successful.

The first wireless communication module may be a personal area network module. The second wireless communication module may be a near field communication module. The payment terminal may be further configured to terminate attempts to establish a communication channel with any other external entity using the first wireless communication module and the second wireless communication module until the transaction is ended. The external entity may be one of a card and a portable communication device, wherein the payment terminal may be further configured to identify whether the established communication is with one of a near field communication tag of the card, a near field communication module of the portable communication device or a personal area network module of the portable communication device. The payment terminal may be further configured to communicate to a server whether the established communication is with one of a near field communication tag of the card, a near field communication module of the portable communication device, or a personal area network module of the portable communication device. The external entity may be a portable communication device, wherein the payment terminal may be configured to: prior to establishing communication with the portable communication device, receiving at least data identifying a user attempting to make a payment related to a transaction; and communicating at least the data identifying the user, the data identifying the merchant, and the data identifying the payment amount to a server to process the transaction such that the portable communication device can make the payment without using the internet. The payment terminal may be further configured to: receiving location verification data from the external entity; verifying whether the payment terminal can be used to accept payment based on the location verification data; and to reject the transaction if it is confirmed that payment cannot be accepted or to process the transaction if it is confirmed that payment can be accepted. The external entity may be a card with which near field communication can be established, the payment terminal being configured to: reading data identifying a user and data to be used as a one-time passcode from the card; writing a new one-time passcode into the card; and communicating data identifying the user and data to be used as a one-time passcode to a server, wherein the one-time passcode is used to verify whether the one-time passcode is the passcode expected by the card for the current transaction to deny the transaction or to continue the transaction. The payment terminal may be further configured to communicate a unique one-time passcode to a server for each transaction, wherein the one-time passcode may be used to verify whether the one-time passcode is the passcode expected by the payment terminal for the current transaction, to deny the transaction or to continue the transaction. The external entity may be a portable communication device, and the payment terminal may be configured to: receiving data identifying a user and data to be used as a one-time passcode from the portable communication device; updating, in the portable communication device, a new one-time passcode; and communicating data identifying the user and data to be used as a one-time passcode to a server, wherein the one-time passcode is used to verify whether the one-time passcode is a passcode expected by the portable communication device for the current transaction to deny the transaction or to continue the transaction.

In another aspect, a method for processing payment is provided. The method includes receiving an input at a payment terminal for initiating a transaction. Thereafter, the first wireless communication module and the second wireless communication module provided in the payment terminal attempt to establish a communication channel with an external entity. The first wireless communication module is capable of establishing proximity communication using a first communication channel that is different from a second communication channel that the second wireless communication module is capable of establishing. The method further comprises: establishing a communication channel with the external entity using one of the communication modules based on which of the first wireless communication module and the second wireless communication module successfully established the communication channel with the external entity.

In yet another aspect, a system for processing payment is provided. The system includes a payment terminal including a Personal Area Network (PAN) module. The payment terminal is configured to cause the PAN module to propagate an identifier. The system further includes a portable communication device. The device is configured to: receiving an identifier propagated by the payment terminal; automatically sending a request to establish a communication channel with a PAN module of the payment terminal if the signal strength of the propagated identifier exceeds a first threshold; and, once the communication channel is established, continuing to maintain communication with the PAN module of the payment terminal until the end of the transaction even if the signal strength between the device and the PAN module of the payment terminal falls below the first threshold.

In yet another aspect, a method for processing payment is provided. The method comprises the following steps: propagating, by a personal area network module of the payment terminal, the identifier; receiving, by a portable communication device, an identifier propagated by the payment terminal; automatically sending, by the portable communication device, a request to establish a communication channel with a personal area network module of the payment terminal if the signal strength of the propagated identifier exceeds a first threshold. The method further comprises: once the communication channel is established, communication between the portable communication device and the personal area network module of the payment terminal is maintained until the end of the transaction, even if the signal strength between the portable communication device and the personal area network module of the payment terminal falls below the first threshold.

Also disclosed is a system for processing payments, the system comprising: a payment terminal comprising a personal area network module, wherein the payment terminal is configured to cause the personal area network module to propagate an identifier; and a portable communication device configured to: receiving an identifier propagated by the payment terminal; automatically sending a request to establish a communication channel with a personal area network module of the payment terminal if the signal strength of the propagated identifier exceeds a first threshold; and, once the communication channel is established, continuing to maintain communication with the personal area network module of the payment terminal until the end of the transaction even if the signal strength between the portable communication device and the personal area network module of the payment terminal falls below the first threshold.

The first threshold may be configured such that the portable communication device and the payment terminal are within 20 centimeters of each other to establish a communication channel. The first threshold may be configured such that the portable communication device and the payment terminal are within 10 centimeters of each other to establish a communication channel.

The first threshold may be configured such that the portable communication device and the payment terminal are within a preconfigured distance of each other to establish a communication channel.

At least one of the payment terminal or the portable communication device may be configured to terminate the established communication channel if the signal strength between the portable communication device and the personal area network module of the payment terminal falls below a second threshold.

The second threshold may be remotely reconfigurable.

The payment terminal may be configured to: prior to establishing the communication channel, receiving at least data identifying a user attempting to make a payment related to the transaction; and communicating at least the data identifying the user, the data identifying the merchant, and the data identifying the payment amount to a server to process the transaction such that the portable communication device can make the payment without using the internet.

The payment terminal may be further configured to: receiving data from a server corresponding to an account balance of a user making a payment using the portable communication device; and communicate data corresponding to the account balance to the portable communication device via the communication channel.

The payment terminal may be further configured to: receiving data corresponding to the transaction information from the server; and communicating at least a portion of the data corresponding to the transaction information to the portable communication device via the communication channel.

The payment terminal may not be able to display the user's account balance; and the portable communication device is configured to display the user's account balance after the transaction.

The identifier may comprise data identifying compatibility, wherein if the identifier received by the portable communication device comprises data identifying compatibility, the portable communication device is configured to consider the payment terminal to automatically request establishment of a communication channel.

The payment terminal may be configured to: receiving input indicating an amount to be transferred; after receiving input indicative of the amount, receiving input to begin propagating identifiers; and communicating data corresponding to the amount and a merchant connected to the payment terminal to the portable communication device once the communication channel is established, wherein the amount and information corresponding to the merchant are displayed on the portable communication device.

The first threshold may be remotely reconfigurable.

The personal area network module may be one of a bluetooth low energy module or a bluetooth module.

Also disclosed is a method for processing payments, the method comprising: propagating, by a personal area network module of the payment terminal, the identifier; receiving, by a portable communication device, an identifier propagated by the payment terminal; automatically sending, by the portable communication device, a request to establish a communication channel with a personal area network module of the payment terminal if the signal strength of the propagated identifier exceeds a first threshold; and once the communication channel is established, maintaining communication between the portable communication device and the personal area network module of the payment terminal until the end of the transaction, even if the signal strength between the portable communication device and the personal area network module of the payment terminal falls below the first threshold.

Drawings

In each figure:

FIG. 1 illustrates a system 100 for processing payments;

FIG. 2 is a block diagram of the payment terminal 102 of the system 100;

3A-3F are flow diagrams of exemplary methods of processing payments by the system 100;

figure 4A shows the amount entered in the payment terminal 102,

fig. 4B illustrates a user interface of an application of the smartphone 104B opened by the user to make a payment;

fig. 4C illustrates a user interface of the smartphone 104b searching for applications of the payment terminal 102;

figure 4D illustrates the smartphone 104b paired with the payment terminal 102 via a BLE channel after bringing the smartphone 104b in proximity to the payment terminal 102;

FIG. 4E illustrates a user interface of an application of the smartphone 104b in which the user is providing input to approve payment;

FIG. 4F illustrates a user interface of an application of the smartphone 104b, showing a transaction being processed;

fig. 4G illustrates a user interface of an application of the smartphone 104b in which transaction information is displayed after a successful transaction;

FIG. 5A shows a highly schematic diagram of an exemplary transaction packet;

FIG. 5B shows another transaction packet; and is

Fig. 6 shows a schematic diagram of an embodiment of a payment terminal showing how certain connections to the payment terminal may be performed.

Detailed Description

In the following description, reference to a telephone (phone) or smart phone (smartphone) is not intended to be limited to a particular type of portable communication device; these terms are used for convenience and are intended to encompass any type of portable communication device.

A system is disclosed that is capable of processing payments without requiring the use of the Internet by a user making the payment. For example, the payment may be made using a Near Field Communication (NFC) enabled card or a smartphone with NFC or Bluetooth Low Energy (BLE) technology.

Payment is facilitated by a payment terminal deployed at a merchant location. The payment terminal may include a personal area network module (BLE module) and an NFC module. In an embodiment, upon initiating a transaction, the payment terminal is configured to attempt to initiate communication with an external entity presented by the consumer/user using both BLE and NFC simultaneously to make a payment. The external entity may be an NFC enabled card or a smartphone with NFC or Bluetooth Low Energy (BLE) technology in which an application for conducting transactions with the payment terminal is installed.

In another embodiment, the transaction terminal is configured to attempt one of BLE and NFC for a period of time, and then attempt the other of BLE and NFC if unsuccessful, and repeat attempting BLE and NFC again and again if necessary.

In an embodiment, once the payment terminal successfully establishes a communication channel with the external entity via one of BLE and NFC, the payment terminal is configured to disable (attempt to establish communication with any other external entity) another technique until the initiated transaction is over.

In another embodiment, the payment terminal stops transmitting one of the two outputs upon detecting a return of the signal from the other output. This can save battery power in the battery-driven terminal.

In an embodiment, a communication channel is established with the payment terminal via NFC, wherein a user brings a card or NFC enabled smartphone into proximity with the payment terminal. The payment terminal reads data from the phone's card/NFC module and passes the data to the back-end server to process the initiated payment transaction. Note that the merchant is not indicating which communication means the payment terminal is to use, but is automatically decided by the payment terminal itself.

In an embodiment, a communication channel is established with the payment terminal via BLE, wherein the user brings a smart phone supporting BLE into proximity of the payment terminal. The payment terminal receives data from the BLE module of the phone and communicates the data to the backend server to process the initiated payment transaction. Note that even in this case, the merchant is not instructing which communication means the payment terminal is to use, but is automatically decided by the payment terminal itself.

In the case of BLE, the payment terminal communicates transaction information (received from the backend server) such as the amount of money to be deducted and the balance in the user's account to the user's smartphone over the communication channel established via BLE. Thus, the user is not only able to make payments without using the internet or relying on SMS or similar alternatives, but is also able to obtain updates regarding transactions and accounts.

Referring to fig. 1, a system 100 for processing payment has a payment terminal 102 that can receive payment via external entities such as an NFC enabled card 104a and a portable communication device 104 b. The in-use payment terminal 102 communicates with the server 106 via the communication network 108.

The payment terminal 102 may be, for example, a card reader, a smart phone, a POS system, a tablet computer, a tablet phone, a computer and laptop computer, and other computing devices.

Referring now to fig. 2, an embodiment of payment terminal 102 includes a processing module 202, a memory module 204, an input module 206, an output module 208, a WIFI module 210, a communication module 212, a security module 213, a first wireless communication module 214, and a second wireless communication module 216. The memory module 204 is connected to a bus that connects it to the processor module 202. The processing module 202 is connected to all other modules by a bus 123. The processing module 202 operates under the control of executable instructions stored in the memory module 204 to perform the functions of the payment terminal 102 and typically invokes other modules of the device to perform the functions of those modules.

Referring now to fig. 6, in this embodiment, input module 206 is connected to a keypad 601 and a stylus 603. The output module 208 is connected to a display 605 and a printer 607. The WiFi module is shown connected to the server 106 via a wireless link and the communication module 212 is shown connected to the server 106 via a wired link. It will be appreciated that only one of the links to the server 106 may be employed in use. The first wireless communication module 214 is connected to the NFC antenna, and the second wireless communication module is connected to the bluetooth antenna 611. In some embodiments, the antennas are integral with the respective wireless communication modules.

Returning to fig. 2, the processing module 202 is implemented in the form of one or more processors and may be suitably implemented in hardware, computer-executable instructions, firmware, or a combination thereof. The computer-executable or firmware embodiments of the processing module 202 may include computer-executable or machine-executable instructions written in any suitable programming language for performing the various functions described.

In an embodiment, the memory module 204 includes a persistent memory, such as a hard drive, eMMC, SSD, or EEPROM. The memory modules may be configured to store data and executable program instructions implemented by the processor 202. The memory module 204 may be implemented in the form of a primary memory and a secondary memory, where the primary memory is a hardwired memory and the secondary memory is a removable memory (such as an SD card). Memory module 204 may store additional data as well as program instructions that may be loaded and executed on processor 202, as well as data generated during execution of these programs. Further, the memory module 204 may be volatile memory (such as random access memory and/or a disk drive) or non-volatile memory. The memory module 204 may include removable memory such as compact flash cards, memory sticks, smart media, multimedia cards, secure digital memory, or any other memory storage.

In the presently described embodiment, the input module 206 provides an interface for input devices such as a keypad, touch screen, mouse, microphone, and stylus, among other input devices. Output module 208 provides an interface for output devices such as a display screen, speakers, printer, and haptic feedback devices, among others.

In the presently described embodiment, the input module 206 and the output module 208 are also used to exchange data between the payment terminal 102 and to exchange data obtained by the terminal from the NFC enabled card 104a, the portable communication device 104b with the server 106.

In one embodiment, payment terminal 102 communicates with server 106 via communication network 108 using a WIFI module.

In one embodiment, the payment terminal 102 communicates with the server 106 via the communication network 108 using the communication module 212. In one embodiment, the communication module 212 is a GPRS module. In other embodiments, other modules that enable remote communication are employed.

In an embodiment, the communication module 212 includes a modem, a network interface card (such as an ethernet card), a communication port or a Personal Computer Memory Card International Association (PCMCIA) slot, or the like. In one embodiment, the communication module 212 includes devices that support both wired and wireless protocols. In one embodiment, data in the form of electronic signals is transmitted via the communication module 212. In other embodiments, one or more of electromagnetic signals, optical signals, and other signals are used.

In an embodiment, the payment terminal uses a digital key to encrypt, decrypt, and authenticate data exchanged between the terminal 102 and the external entity 104. In this embodiment, the key is held in the security module 213. This security module contains all the keys to be used by the device and is a write-once device. The key is written to the security module 213 in the secure environment. The security module 213 is designed such that the key cannot be read directly from the module. When encryption is required, the data is sent to the security module 213 which returns the encrypted data after processing using the key. The key cannot be accessed directly from the security module 213, thereby ensuring the security of the key. Also, to decrypt the data, the data is sent to the security module 213, which processes the data using the key to return the decrypted data.

The security module 213 may be deployed in the form of software, firmware, hardware, or a combination thereof.

In an embodiment, the first wireless communication module 214 is a personal area network module (hereinafter referred to as a PAN module). In the presently described embodiment, the PAN module is a Bluetooth Low Energy (BLE) module. In other embodiments, techniques similar to BLE in the present context may be used.

In an embodiment, the second wireless communication module 216 is a near field communication module (hereinafter referred to as an NFC module). In other embodiments, techniques similar to NFC in the present context may be used.

Thus, it may be noted that the payment terminal 102 has a first wireless communication module 214 that is capable of establishing proximity communication with the external entity 104 using a first communication channel or protocol (e.g., BLE) that is different from a second communication channel or protocol (e.g., NFC) that the second wireless communication module 216 is capable of establishing.

A high level description will now be given regarding an embodiment of the payment terminal in the operation of fig. 2 and 6.

Initially, the processor of the processing module 202 is in an idle state, and in this embodiment, the two wireless communication modules 214, 216 are also idle. The terminal is "woken up" by an input from the keypad 601 to its input module 206, which interrupts the idle process of the processing module 202 via the bus 123. The processing module retrieves instructions from the memory module 204 via the bus 123 and processes the instructions to provide an output to the first wireless communication module 214 and the second wireless communication module 216 via the bus 123, which thereby begin transmitting their respective interrogation signals (i.e., BLE signal and NFC signal, respectively) to seek the external device 104. The interrogation signal is emitted via the respective antenna 609, 611.

When one of the two antennas 609, 611 receives a response to one of the two interrogation signals, the corresponding wireless communication module invokes the processing module 202 via bus 123, and based on the stored instructions in the memory module 204, the processing module 202 instructs the other corresponding wireless communication module to cease transmitting its interrogation signal. For simplicity, it is assumed that the first wireless communication module (BLE module 214) receives the response, and thus the second wireless communication module 216 is instructed to enter the idle state.

Data received from external device 104 via antenna 609 is passed along bus 123 to security module 213, which decrypts the data using a digital key stored in the security module under the control of processing module 202, as described elsewhere in this document. This enables the payment terminal to authenticate the external device 104 (e.g., a phone application or card). Where appropriate, and after authentication is performed, some information is sent to screen 605 for display, for example instructing the user/merchant to perform operations such as "enter amount", "enter personal identification number", etc.

The input module 206 receives a response to any such instruction, for example, an input to the keypad 601. This is then processed by the processing module 202 and, depending on the results of the processing, more information is displayed on the screen 605 to facilitate further instruction and response rounds, or the transaction information is sufficient to be sent to the server 106.

When appropriate, the processing module 202 instructs one of the WiFi module 210 and the communication module 212 to interact with the server 106 based on data received and processed by the terminal 102.

In response to data received from the terminal 102, the server 106 returns data via one of the WiFi module 210 and the communication module 212. This data is processed by the processing module 202 via the bus 123 and, where appropriate, information derived from the data is displayed on the display 605 and/or printer 607 via the output module 208.

At the end of the transaction, the processing module returns to its idle state.

At some time during the transaction process, the terminal 102 may transmit data to the external device 104, typically such data being encrypted by a key stored in the security module 213. As described elsewhere, the data sent to the external device may include, for example, a one-time code for security purposes.

In fig. 3A-3F, tasks performed by one embodiment of payment terminal 102, external entity 104 (in some cases, the type of external entity 104a, 104b is referred to as external entity 104 to facilitate easier reading of the present document), and server 106 are discussed.

At step 302, the payment terminal 102 receives input indicating an amount to be charged. By way of example, the merchant receives input indicating an amount to be charged using a physical or numeric keypad disposed in or on payment terminal 102. By way of example, referring to FIG. 4A, the merchant enters an amount Rs.350 that the merchant intends to receive from the user/customer.

At step 304, the payment terminal 102 receives input for initiating a transaction with the external entity 104. As an example, referring again to fig. 4A, after the amount is entered, the user of the payment terminal 102 presses the back key to provide an immediate input. It may be noted that pressing the return key may be interpreted as a confirmation of the amount discussed in the previous step and the input discussed in the current step.

At step 306, in response to the initiation input, the payment terminal 102 (e.g., the processing module 202 of the payment terminal 102) causes the first wireless communication module 214 (hereinafter BLE module 214 to facilitate easier reading of the document) and the second wireless communication module 216 (hereinafter NFC module 216 to facilitate easier reading of the document) to attempt to establish communication with the external entity 104. As an example, the modules 214, 216 may each be opened in response to an initiation input and thereafter attempt to establish a communication channel. Alternatively, the modules 214, 216 may both have been turned on (but in a "sleep" or "power save" mode), but in this case, begin attempting to initiate and thus establish a communication channel with the external entity 104.

At step 308, both BLE module 214 and NFC module 216 attempt to establish a communication channel. As an example, in the case of BLE module 214, BLE module 214 may begin propagating its identifier. On the other hand, in the case of the NFC module 216, the NFC module 216 generates an electromagnetic field. It may be noted that the merchant does not specify which of the modules 214, 216 should be used, but rather configures the payment terminal 102 to use both modules 214, 216 to attempt to establish a communication channel and, when appropriate, to establish a communication channel via the appropriate one of the modules 214, 216 after authentication.

Referring to step 310 in fig. 3B, it may be noted that although it appears as if the external entity 104 is deciding whether the external entity 104 supports NFC or BLE, it will be well understood that step 310 is given for explanatory purposes only. It is to be appreciated that the external entity 104 can be an NFC enabled card 104a (such as a credit card, debit card, access card, company card, or meal card) or a portable communication device 104b (e.g., a smartphone) having one or more of BLE functionality or NFC functionality, as previously discussed. Later, we will discuss the transaction flow in case of a BLE enabled portable communication device 104 b. We now discuss scenarios in which the external entity 104 is an NFC enabled card 104a or an NFC enabled portable communication device 104 b. It may be noted that in case of a portable communication device 104b with NFC functionality and BLE functionality, which of these functionalities should be used may be defined by default application settings, user defined settings in the application or availability of modules.

Referring to step 312, the external entity 104 is in close proximity to the payment terminal 102 for detection. As an example, once the merchant prepares payment terminal 102 to accept payment, the user/customer may bring NFC card 104a or NFC device 104b in proximity to payment terminal 102 (to the extent required by NFC).

By way of explanation, in some embodiments, the NFC cards/ devices 104a, 104b carry encrypted data so that only the payment terminal 102 of the present embodiment can properly interact with the NFC cards/devices of the present embodiment. This causes a phenomenon known as "locking" the card/device.

Referring to step 314, the payment terminal 102 detects and attempts to unlock the external entity by authenticating the external entity 104. Establishing a communication channel upon successful execution of the authentication; that is, the transaction data is only sent after the authentication is successful.

Thus, after detecting the NFC card 104a or the NFC device 104b, the payment terminal 102 has established a communication channel with the external entity 104 using one of the communication modules 214, 216 based on which of the first wireless communication module 214 and the second wireless communication module 216 successfully initiates the communication channel with the external entity 104. In this case, the payment terminal 102 has established a communication channel with the external entity 104 using the second wireless communication module 216(NFC module 216). Thus, the communication channel thus established may be referred to as an NFC channel.

In this embodiment, upon receiving a response to one of the BLE signal and the NFC signal, the payment terminal 102 terminates any attempt to establish a communication channel with any other external entity using the first wireless communication module 214 and the second wireless communication module 216 until the end of the transaction.

In another embodiment, upon establishing the communication channel, the payment terminal not only receives a response to the output signal from the payment terminal, but also authenticates the external device so that data communication can begin, and the payment terminal terminates further output by the further non-responsive communication module until the current transaction is completed.

Using the established NFC channel, payment terminal 102 coordinates with external entity 104 to unlock external entity 104. Known (or possibly developed in the future) security techniques deployed at the card/device level and payment terminal 102 may be used to unlock the NFC card 104a or NFC device 104 b. In case the payment terminal 102 fails to unlock, in this embodiment, the transaction is then terminated (transaction end).

Referring to step 316, once the unlocking is successful, the payment terminal 102 reads the user token from the card memory. A user token is data similar to a card number on a credit card that identifies a user attempting to make a payment related to a transaction.

In one embodiment, in addition to reading the user token, the external entity 104 also stores data that is used as a one-time passcode. In this embodiment, the payment terminal 102 also reads the stored one-time passcode to improve security.

A one-time passcode may be understood as data that is unique to each transaction that is attempted. It may also be noted that in the case of NFC card 104a, whenever payment terminal 102 reads an existing one-time passcode to process a transaction, a new one-time passcode may be written to card 104 a. It may also be noted that some smartphones may not allow this data to be written to their NFC module, in which case the provision of the one-time passcode implemented in the above example may not be provided.

By way of explanation, referring to FIG. 5A, a transaction data packet 500 generally contains a customer token 501, a customer identifier 503, a transaction amount 505, and a merchant ID 507. If a hacker is able to listen to the data when the user pays or attempts to pay the bill on the terminal, the hacker may pay the same amount multiple times on the same terminal. This is sometimes referred to as a "replay attack". Therefore, it is desirable to distinguish legitimate transactions from replay attacks.

In this embodiment, a security mechanism for detecting "replay attacks" is present in place. In a replay attack, a hacker would listen to the data being exchanged between the two devices and then replay the data multiple times. In order for the system to be able to detect and flag such attacks, it is necessary to introduce fresh things into the data packet each time. In this embodiment, referring to fig. 5B, this is achieved by one or both of the following operations: a) maintaining and incrementing a counter on the card after each transaction, and b) sending a timestamp on the payment device as part of the data packet.

Thus, the packet 520 of the present embodiment includes not only the customer token 501, customer identifier 503, transaction amount 505, and merchant ID 507, but also a counter number 509 stored on the card/device and a timestamp 511 of the transaction.

In embodiments, the data read from the NFC card 104a or the NFC module of the mobile device 104b (or data communicated via BLE) includes data that enables the payment terminal 102 to identify whether the data it is collecting is from the NFC card 104a or from the NFC module of the mobile device 104b (or via BLE of the mobile device). Thus, the payment terminal 102 (or the server 106, or both) is able to identify whether the established communication is with one of the near field communication tag of the card 104a, the near field communication module of the portable communication device 104b, or the personal area network module 214 of the portable communication device 104 b. It may be noted that this provision enables the server 106 to establish the data sets required to process the transaction. As an example, in the case of the NFC card 104a, a one-time passcode is required, whereas in the case of the NFC module from the mobile device 104b, a one-time passcode may not be required (due to the constraints discussed above) to process the transaction.

In an embodiment, the data read from the NFC card/ device 104a, 104b or received via BLE includes location verification data. In other words, the payment terminal 102 receives location verification data from the external entity 104. The location verification data is used to verify whether payment can be accepted using the payment terminal 102.

In one embodiment, data is written to the external entity 104 (e.g., card 104a) and the terminal is set to reject the card carrying the code unless it is the case that the terminal is located at the site of interest. In a fully closed corporate payment environment (such as a corporate canteen), it is contemplated that the payment device only accepts payments from one (or more) companies, with the bill being completed locally at the payment device level itself. If the device does not find a customer card containing a specific identifier (identifying the company), the transaction is immediately rejected. No server calls are required.

In the event that the payment is determined to be unacceptable, the transaction is denied. On the other hand, if the payment is verified to be acceptable, the transaction is processed. The verification in question may be performed by the payment terminal 102.

Alternatively, the verification may be performed by the server 106 or both.

In other cases where the payment device is located in a general retail, the billing occurs at the server 106. The client identifier is also part of the data packet sent to the server. A rule is set at the backend that prohibits a customer with a particular customer identifier from making a payment at a certain location (e.g., the location identified by the merchant ID 507 that will be recalled and that is also part of the transaction data packet).

As an example of an implementation, a company may have issued an NFC card 104a to its employees for use within a food service area deployed within the employee's campus. In the case where payment is made at the payment terminal 102 outside the campus using the card 104a, the payment terminal 102 (or the server 106) may reject the transaction after reading the location verification data.

Referring now to step 318, payment terminal 102 writes the new one-time passcode to external entity 104. As an example, a new one-time passcode is written to the NFC card 104 a. In the event that the NFC module of the mobile device 104b allows such writing, in an embodiment, a new one-time passcode is written to the NFC module of the mobile device 104b even in the case of an NFC enabled mobile device 104 b. The new one-time passcode is used for the next transaction. The new one-time passcode may be a pre-configured increment/decrement compared to the existing one-time passcode. Alternatively, the one-time passcode may be a randomly generated code, which may be based on known logic. In an embodiment, a new one-time passcode is generated by the payment terminal 102. At step 320, the new one-time passcode is recorded in the NFC module of the NFC card 104a or the mobile device 104b (if such provisions are provided).

It should be noted that the one-time passcode adds freshness to the data collected from the external entity 104 for each transaction. As an example, in the case where only user tokens are collected (as is the conventional case), which is also constant, a malicious system having access to the user tokens may misuse the user tokens to perform a transaction.

Referring to step 322, the payment terminal 102 binds the user token, the one-time passcode (if any), the merchant ID, the terminal ID, the one-time passcode of the payment terminal 102, the source (NFC card/mobile phone or BLE) for obtaining user data and transaction information. In an embodiment, the payment terminal 102 may also bind a new one-time passcode. It may be noted that there may be a one-time passcode for the payment terminal 102 in addition to the one-time passcode corresponding to the external entity 104. Thus, a malicious system with information about the payment terminal 102 (e.g., merchant ID or terminal ID) may still be protected against abuse conditions. In an embodiment, the user may also have to communicate a PIN to the payment terminal 102 to authorize the transaction. In some embodiments, only transactions that exceed a certain preconfigured amount may require a PIN.

In addition, the payment terminal 102 may bundle authentication and security data, as well as other data, together to enhance security features.

Referring to step 324, the payment terminal 102 sends the bundled information to the server 106. Payment terminal 102 may use WIFI module 2 to send information to server 106. Alternatively, the payment terminal 102 may use a GPRS module to send information to the server 106. Alternatively, the payment terminal may encrypt the bundled information using the security module 213 for security purposes before communicating the bundled information to the server 106.

Referring to step 326, the server 106 receives the bundled information from the payment terminal 102.

Referring to step 328, the server 106 processes the transaction. The conventional steps involved in processing the transaction are not discussed to prevent diverting attention from steps that may be irregular. The one-time passcode of the external entity 104 and the one-time passcode of the payment terminal 102 are used to decide whether the payment request should be rejected or further processed. The one-time passcode (corresponding to the payment terminal 102) is used to verify whether it is the passcode that the payment terminal 102 expects for the current transaction, to deny the transaction or to continue the transaction. Likewise, the one-time passcode (corresponding to the external entity 104) is used to verify whether the one-time passcode is the passcode that the external entity 104 expects for the current transaction, to deny the transaction or to continue the transaction.

In an embodiment, the payment terminal 102 may even communicate a new one-time passcode corresponding to the external entity 104 to the server 106, so that the server 106 knows the one-time passcode expected by the external entity 104 in the next transaction.

In an embodiment, the new one-time passcode of the external entity 104 or payment terminal 102 is a known change compared to the previous one-time passcode. Thus, the server 106 may only need to verify the one-time passcode with the previous passcode to deny or continue the transaction.

In an embodiment, the server 106 communicates a new one-time passcode for the payment terminal 102 for the next transaction.

In the event that the one-time passcode from the external entity 104 is not present (which is the expected case) or the one-time passcode is incorrect, the server 106 may prevent the external entity 104 from conducting the transaction until the problem is resolved. The same is true for the payment terminal 102.

Referring to step 330, the server 106 transmits the transaction information to the payment terminal 102. The transaction information may include information corresponding to a successful payment or a payment denied. The transaction information may also include information corresponding to the amount paid to the merchant account and/or selected information about the user/customer making the payment, among other information.

Referring to step 332, the payment terminal 102 receives transaction information from the server 106. Certain information received may be output (e.g., displayed) by the payment terminal 102. In some embodiments, certain transaction information may be prevented from being output by payment terminal 102, and such information may be output on external device 104 (e.g., a phone).

Referring to step 334, once the transaction is over, the payment terminal 102 may prepare for the next transaction (e.g., beginning at 302).

Referring now to block 310, as may be recalled, the description we previously provided considers that the user/customer may be making a payment using an NFC card 104a or an NFC enabled smart phone 104 b. We now refer to a scenario in which a user is making a payment using a BLE-enabled portable communication device 104b (e.g., a smartphone).

It should be understood that BLE is not essential to the invention and other protocols will work as well, such as "normal" bluetooth or WiFi.

We can now also refer to fig. 3E together with the other figures in the fig. 3 series. As explained previously, with reference to step 308, both the NFC module 216 and the BLE module 214 of the payment terminal may be attempting to establish a communication channel. As explained previously, in the case of BLE module 214, BLE module 214 may begin propagating its identifier. The identifier may include data identifying the compatibility.

As an example, referring also to fig. 3E and 4B, the user opens the payment application in the portable communication device 104B and activates the "pay now" icon. The application causes the BLE module of BLE enabled smartphone 104b to search (see figure 4C) for payment terminal 102.

In embodiments where there are multiple payment terminals, the payment terminals typically radiate signals at the same intensity, but of course there is little likelihood that the two terminals will be equidistant from any particular portable communication device (smartphone). Radiation of a signal indicating readiness to connect (pair) is sometimes referred to in the art as "advertising" and generally involves transmitting a data packet. The term "pairing" is not intended to be limiting.

The signal strength received at the portable communication device (smartphone) is measured by the smartphone (e.g., by an application running on the smartphone) and used to determine the location of the smartphone relative to each payment terminal available nearby.

As a first step of pairing, step 30 of fig. 3E, the application scans the vicinity and makes a list of "qualified candidates" with which a connection can be established. The application is configured to ensure that the portable communication device (smartphone) is paired only with the intended payment terminal. For example, the merchant asks the customer to open an application and place the phone near payment terminal a to initiate payment. The application then takes over and decides which payment terminal (among all eligible payment terminals) is closest to the phone. Since the merchant has required the customer to place their phone close to payment terminal a, the application will see payment terminal a only a few inches away, while the other terminals are a few meters away, and thus will require pairing with payment terminal a.

The signal strength logic (establishing a connection with the nearest available payment terminal) is only used to establish a connection.

Once the phone is paired with the payment terminal and a connection is thus established, the connection will remain active until the application decides to disconnect the connection. Even if the phone is pulled away from the terminal, the connection remains active and the application continues to talk to the terminal to complete the transaction. Once the application determines that the transaction is complete, the application disconnects and releases the terminal.

The terminal is configured such that it cannot be paired with 2 phones simultaneously. Once the phones are paired or connected to the terminals, the communication channels between the phones and the terminals are mutually exclusive. That is, no other phone may be paired with or otherwise in communication with the terminal. The terminal is actually locked to the phone and can only be unlocked (disconnected from the phone) by an application or by physically resetting the payment terminal.

In an embodiment, this "locking" is performed by configuring the terminal to stop the advertisement when pairing occurs. In one example, an application on a smart phone issues an instruction to the terminal to stop the advertisement; in another example, the terminal is configured to stop the advertisement without input from the smartphone once pairing has occurred.

The processor of the payment terminal receives the instruction and processes the instruction in response to the stored instruction and temporarily disables the pairing capabilities and presence of the advertisement thereto.

In an embodiment, the application of the smartphone 104b looks for a compatible payment terminal 102 by looking at the data identifying the compatibility present in the identifier. For example, there may be multiple BLE devices or bluetooth devices that may be advertising, but the application is only interested in identifying payment terminals 102 that may be considered for payment (and therefore for sending pairing requests).

The user has moved the portable communication device into the proximity of the payment terminal such that the signal strength is above the first threshold, as shown in step 31 of fig. 3E, the smartphone 104b sends a request to the payment terminal 102 for pairing.

In one embodiment, the pairing request is issued only when the signal strength from the payment terminal 102 is above a first threshold.

In another embodiment, the pairing request is issued upon user activation of an "pay immediately" icon, or similarly instructing the smartphone to begin a transaction.

In a further embodiment, the application displays an indication of one or more terminals with which it is possible to pair, for example on its display screen, and the user selects one of these terminals, the selection causing the pairing request sequence to start.

As an example, consider a merchant location with multiple compatible payment terminals 102. The application of the smartphone 104b will identify and list all of these payment terminals 102, but it must decide which of these payment terminals the pairing request has to be sent to.

In an embodiment, even in case a single payment terminal 102 is identified, no pairing request is sent unless the signal strength is above the first threshold. In practice, even using BLE as a payment channel, the user experience will be similar to "pay-per-click" (tap-and-pay). The user bringing the smartphone 104b close (see fig. 4D) to the payment terminal 102 causes the signal strength to increase, thereby causing the application to request pairing with the payment terminal 102. It will therefore be appreciated that if the signal strength of the propagated identifier exceeds the first threshold, the smartphone 104b automatically sends a request to establish a communication channel with the personal area network module 214 of the payment terminal 102.

The first threshold is configured such that the portable communication device 104a and the payment terminal 102 are within a preconfigured distance of each other to establish a communication channel. The first threshold may be reconfigured remotely via a software update or may be configured at the payment terminal 102.

In an embodiment, the first threshold is configured such that the portable communication device 104b and the payment terminal 102 are within about 20 centimeters of each other to establish the communication channel.

In another embodiment, the first threshold is configured such that the portable communication device 104b and the payment terminal 102 are within about 10 centimeters of each other to establish the communication channel.

It should be appreciated that with the configuration of the first threshold, we are able to set an approximate distance between the portable communication device 104b and the payment terminal 102 for pairing.

At step 32 of fig. 3E, the payment terminal 102 receives the pairing request. The payment terminal 102, upon receiving the request, coordinates with the smartphone 104b using well-known protocols to successfully pair or reject the request. In case the pairing is successful, the payment terminal 102 has established a communication channel (BLE channel) with the external entity 104 using the first wireless communication module 214(BLE module 214). Thus, the communication channel thus established may be referred to as a BLE channel.

Once the communication channel is established (paired), if the signal strength between the smartphone 104b and the personal area network module 214 of the payment terminal 102 drops below the first threshold, the smartphone continues to maintain communication with the personal area network module of the payment terminal 102. In effect, the user brings the smartphone 104b in proximity to the payment terminal 102, thereby pairing the smartphone 104b with the payment terminal 102. Thereafter, the user may withdraw the smartphone 104b, but the communication channel will be maintained, thereby improving the user's experience and making the transaction process more reliable.

In an embodiment, at least one of the payment terminal 102 or the smartphone 104b is configured to terminate the established communication channel if the signal strength in the channel between the smartphone 104b and the personal area network module 214 of the payment terminal 102 falls below a second threshold. The second threshold may be controllable. The second threshold may be reconfigured remotely or on the device.

At step 33 of fig. 3E, the payment terminal 102 sends the transaction information to the smartphone 104 b. The information is transmitted via a BLE channel. Such information may include the amount to be transferred and merchant information, among other things.

At step 34 of fig. 3E and fig. 4D and 4E, the smart phone 104b receives the transaction information sent by the payment terminal 102.

At step 35 of fig. 3E and fig. 4E, the user may activate the icon, causing smartphone 104b to send payment approval and communicate data to facilitate the transaction. The communicated data (in addition to the relevant data discussed in the context of NFC) may also include real-time data. The real-time data may include data corresponding to time. The one-time passcode may be generated by the smartphone 104 b. In an embodiment, the user may also have to communicate a PIN to authorize the transaction. In some embodiments, only transactions that exceed a certain preconfigured amount may require a PIN.

At step 36 of fig. 3F, the payment terminal 102 receives the approval and data, and may perform the steps previously discussed in connection with step 322, as well as subsequent steps, which may be applicable to such a transaction mode.

Referring now specifically to steps 332 (fig. 3D), 37 and 38 (fig. 3F), payment terminal 102 receives transaction information from server 106. It may be noted that, as previously discussed, the server 106 knows that the payment terminal 102 received data via the BLE channel based on the received data. Accordingly, the BLE channel may be used to provide updates to the user corresponding to the transaction. Thus, in addition to the typical data sent by the server 106, the server 106 sends and the payment terminal 102 receives data corresponding to the account balance of the user making the payment using the smartphone 104 b. The payment terminal 102 communicates data corresponding to the account balance to the smartphone 104b via the BLE channel (see figure 4G). Thus, the user is not only able to make payments without using the internet, but is also able to obtain updates regarding the transaction without using the internet.

Upon completion of step 38, the application running on smartphone 104 sends a command over the communication channel with payment terminal 102. The command instructs the terminal to start advertising so that further transactions can be made with other smart phones. The command is received by the payment terminal and processed by processing circuitry of the payment terminal according to instructions stored in a memory of the terminal, thereby recovering the advertisement.

In one embodiment, terminal 102 is also provided with a physical reset device (e.g., a reset key) so that the merchant can re-enable the advertisement as needed. In another embodiment, the reset may be performed remotely, but in some cases this may not be as secure as using a physical reset device.

The reset key, when operated, may cause the payment terminal to restart to a quiescent state where advertising may begin, or may simply override the "stop advertising" command and send a "resume advertising" command to the processing circuitry.

In an embodiment, the payment terminal 102 is further configured to receive data corresponding to the transaction information from the server 106 and communicate at least a portion of the data corresponding to the transaction information to the smartphone 104b via the communication channel.

In an embodiment, the payment terminal 102 is unable to display the user's account balance; however, the portable communication device 104b is configured to display the user's account balance after the transaction. The data corresponding to the account balance may be encrypted so that only the user's smartphone 104b can decrypt the data.

It should be noted that some of the encryption, decryption, authentication, and security techniques that are typically used at different steps are not discussed in order to not unnecessarily obscure aspects of the embodiments.

The above described process is described as a series of steps, which are done for illustrative purposes only. Thus, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be rearranged, or some steps may be performed concurrently.

The example embodiments described herein may be implemented in an operating environment that includes software installed on a computer, hardware, or a combination of software and hardware.

Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the systems and methods described herein. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

It should be understood that the present invention has been described by way of example only. Various modifications may be made to the techniques described herein without departing from the spirit and scope of the appended claims. The disclosed techniques include techniques that may be provided in an independent manner or in combination with one another. Thus, features described with respect to one technique may also be present in combination with another technique.