U.S. patent application number 14/667496 was filed with the patent office on 2015-08-20 for card reader emulation for cardless transactions.
The applicant listed for this patent is Square, Inc.. Invention is credited to Robert Lee.
Application Number | 20150235195 14/667496 |
Document ID | / |
Family ID | 53054728 |
Filed Date | 2015-08-20 |
United States Patent
Application |
20150235195 |
Kind Code |
A1 |
Lee; Robert |
August 20, 2015 |
CARD READER EMULATION FOR CARDLESS TRANSACTIONS
Abstract
Disclosed are method and apparatus that enable a cardless
payment transaction to be executed from a merchant point-of-sale
(POS) system. A user is enabled to check in at a merchant by using
a mobile device of the user and then to pay by simply appearing at
the merchant and mentioning his name. By emulating card read events
and intercepting receipt printer outputs, the technique cleanly
integrates into a conventional merchant POS system, without the
need for customized software or hardware to accommodate individual
POS vendor-proprietary application programming interfaces
(APIs).
Inventors: |
Lee; Robert; (San Francisco,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Square, Inc. |
San Francisco |
CA |
US |
|
|
Family ID: |
53054728 |
Appl. No.: |
14/667496 |
Filed: |
March 24, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14187049 |
Feb 21, 2014 |
9037491 |
|
|
14667496 |
|
|
|
|
61909282 |
Nov 26, 2013 |
|
|
|
61921374 |
Dec 27, 2013 |
|
|
|
Current U.S.
Class: |
705/17 ;
705/39 |
Current CPC
Class: |
G06Q 20/204 20130101;
G06Q 20/351 20130101; G06Q 20/20 20130101; G06Q 30/06 20130101;
G06Q 20/40 20130101; G06Q 20/322 20130101; G06Q 20/209 20130101;
G06Q 30/02 20130101; G06Q 20/34 20130101; G06Q 20/10 20130101; G06Q
20/00 20130101; G06Q 30/00 20130101 |
International
Class: |
G06Q 20/20 20060101
G06Q020/20; G06Q 20/34 20060101 G06Q020/34 |
Claims
1. A method comprising: detecting, at a processing system, user
input indicative of an intent to initiate a transaction associated
with a person; and initiating the transaction in response to the
user input by emulating reading of a physical card associated with
the person, without any actual card read event occurring for the
transaction.
2. A method as recited in claim 1, wherein the transaction is a
financial transaction.
3. A method as recited in claim 2, wherein the transaction is a
payment transaction.
4. A method as recited in claim 1, wherein said emulating comprises
sending data that emulates output of a physical card reader to an
application, in a protocol of the physical card reader.
5. An apparatus as recited in claim 1, wherein said emulating
comprises invoking a card reader application programming interface
(API) associated with a physical card reader.
6. A method as recited in claim 1, further comprising: detecting a
signal indicative that the transaction has been approved; and in
response to the signal, preventing generation of a printed record
of the transaction; and causing a message to be sent to a mobile
device of the person, to enable the mobile device to output a
virtual record of the transaction to the person.
7. A method as recited in claim 6, wherein preventing generation of
a printed record of the transaction comprises intercepting a print
signal for activating a printer, the print signal including data
for enabling a record of the transaction to be printed by the
printer.
8. An apparatus comprising: a card reader emulator to detect user
input indicative of an intent to initiate a payment transaction
involving a consumer and, in response thereto, to initiate the
payment transaction by outputting data that emulates a card read
event for the payment transaction without an actual card read event
having occurred for the payment transaction; and a receipt manager
to prevent generation of a printed receipt for the payment
transaction by preventing a print signal from being communicated to
a printer in relation to said payment transaction, and to cause a
message to be sent to a mobile device of the consumer, to enable
the mobile device to output a virtual receipt for the payment
transaction.
9. An apparatus as recited in claim 8, wherein the card reader
emulator is configured to emulate output of a physical card reader
by invoking a card reader application programming interface
(API).
10. An apparatus as recited in claim 8, wherein the receipt manager
is configured to parse receipt data in the print signal to identify
semantic elements of the receipt data.
11. A point-of-sale (POS) system comprising: a processor; a memory
coupled to the processor and storing a POS module executable by the
processor, the POS module configured to process payment
transactions, including to receive card data resulting from card
read events from a physical card reader and to cause the card data
to be sent to a remote authorization entity over a network in
response to the card read events; a user input device coupled to
the processor, to receive user input specifying a consumer, the
user input being indicative of an intent to initiate a payment
transaction involving the consumer; and a card read emulator (CRE)
module configured to detect the user input and, in response
thereto, to emulate the physical card reader by outputting, to the
POS module, card read event data for the payment transaction
without an actual card read event having occurred for the payment
transaction.
12. A POS system as recited in claim 11, wherein the CRE module is
further configured to prevent generation of a printed receipt for
the payment transaction by preventing a print signal from being
communicated to the printer in relation to said payment
transaction, and to send a first message from the POS system to
cause a second message to be sent to a mobile device of the
consumer, the second message for enabling the mobile device to
output a virtual receipt for the payment transaction to the
consumer.
13. A POS system as recited in claim 12, wherein the CRE module is
configured to cause the second message to be sent to the mobile
device of the consumer by sending the first message to a remote
entity via a network, to cause the remote entity to send the second
message to the mobile device of the consumer, the second message
containing data representing the virtual receipt.
14. A POS system as recited in claim 11, wherein the CRE module is
configured to emulate output of a physical card reader by invoking
a card reader application programming interface (API).
15. A POS system as recited in claim 11, wherein the CRE module is
configured to emulate output of a physical card reader by providing
to the POS module a one-time-use account identifier for use only
for said payment transaction involving the consumer, wherein the
one-time-use account identifier is not an account identifier of a
payment card of the consumer but is in an account identifier format
recognizable by the POS module.
16. A POS system as recited in claim 11, wherein the CRE module is
further configured to parse the receipt data in the print signal to
identify semantic elements of the receipt data.
17. A POS system as recited in claim 11, wherein the CRE module is
a component of the POS module.
18. A POS system as recited in claim 11, wherein the CRE module is
logically separate from the POS module.
19. An apparatus as recited in claim 8, wherein the card reader
emulator and the receipt manager are configured to operate as part
of, or separately from but local to, a POS system at a physical
retail location of a merchant.
20. An apparatus as recited in claim 8, wherein the receipt manager
is configured to cause the message to be sent to the mobile device
of the consumer by sending the first message to a remote entity via
a network, to cause the remote entity to send the message to the
mobile device of the consumer.
21. An apparatus as recited in claim 8, wherein the card reader
emulator is configured to emulate output of a physical card reader
by outputting a one-time-use account identifier for use only for
said payment transaction, wherein the one-time-use account
identifier is not an account identifier of a payment card of the
consumer but is in a format of a payment card account.
Description
[0001] This application is a divisional of U.S. patent application
Ser. No. 14/187,049 filed on Feb. 21, 2014, which claims the
benefit of U.S. provisional patent application No. 61/909,282,
filed on Nov. 26, 2013, and U.S. provisional patent application No.
61/921,374, filed on Dec. 27, 2013, each of which is incorporated
herein by reference in their entirety.
BACKGROUND
[0002] The traditional manner of paying by credit card in a
restaurant or other full-service retail establishment is
inefficient and time-consuming. For example, when a customer in a
restaurant wishes to pay by credit card, he typically does so by
first getting the waiter's attention and then requesting a check.
The customer then waits several minutes for the check. After the
waiter brings the check, the customer waits several more minutes
for the waiter to return and collect the customer's credit card,
and then waits several more minutes for the waiter to return with a
printed receipt. While the customer is waiting for the receipt, the
waiter brings the credit card to a point-of-sale (POS) terminal,
runs the card through a card reader, and waits for an authorization
signal to come back and for a paper receipt to be printed. When the
customer receives the printed receipt from the waiter, the customer
writes any tip (gratuity) that he wishes to add onto the receipt
and then signs the receipt. The waiter then collects the signed
receipt (typically after the customer has left the establishment)
and enters the total amount of the transaction (including tip) into
the POS system.
[0003] This process is very time-consuming and inefficient, from
the perspectives of the customer, who may be in a hurry to leave
the restaurant, the waiter, who may be busy serving other
customers, and the restaurant owner, who may require high
efficiency from service employees in order to remain
profitable.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] One or more embodiments of the present invention are
illustrated by way of example and not limitation in the figures of
the accompanying drawings, in which like references indicate
similar elements.
[0005] FIG. 1 illustrates an environment in which the card
emulation technique introduced here can be implemented.
[0006] FIGS. 2A and 2B illustrate different embodiments of a
merchant POS system.
[0007] FIG. 3 illustrates an example of a card read emulator (CRE)
module used in a POS system.
[0008] FIG. 4 is a flow diagram illustrating an example of a
process for setting up and initiating a cardless payment
transaction, according to a first embodiment.
[0009] FIG. 5 illustrates an example of a graphical user interface
(GUI) display generated by a merchant POS system.
[0010] FIG. 6A illustrates operations performed in a cardless
payment transaction, according to the first embodiment.
[0011] FIG. 6B illustrates a process that can be performed by the
card read emulator (CRE) module.
[0012] FIG. 7 illustrates operations performed in a cardless
payment transaction, according to the second embodiment.
[0013] FIG. 8 illustrates operations performed in connection with
specifying a tip for a cardless payment transaction.
[0014] FIG. 9 is a high-level block diagram showing an example of a
processing system in which at least some operations related to a
cardless transaction can be implemented.
DETAILED DESCRIPTION
[0015] References in this description to "an embodiment", "one
embodiment", or the like, mean that the particular feature,
function, structure or characteristic being described is included
in at least one embodiment of the present invention. Occurrences of
such phrases in this specification do not necessarily all refer to
the same embodiment. On the other hand, the embodiments referred to
also are not necessarily mutually exclusive.
[0016] Introduced here is a technique that enables more efficient
payment by use of a payment account, such as a credit card or debit
card account. The technique eliminates the need for a customer to
carry a physical payment card (e.g., a credit card or debit card)
and eliminates the need to do a physical card swipe (or other
similar physical card read event) when performing a payment card
transaction. The technique is particularly advantageous when
applied to a full-service retail establishment, such as a
restaurant; in particular, the technique facilitates a
"pay-by-name" paradigm in which a customer can pay essentially by
just telling the merchant his name. Additionally, by emulating card
read events and intercepting receipt printer outputs, as described
further below, the technique introduced here can cleanly integrate
into essentially any conventional POS system, without the need for
customized software or hardware to accommodate individual POS
vendors' proprietary application programming interfaces (APIs).
[0017] In the following description, the example of a restaurant is
used, for illustrative purposes only, to explain various aspects of
the technique. Note, however, that the technique introduced here is
not limited in applicability to restaurants or to any other
particular kind of business. Additionally, the technique introduced
here is not limited to use with payment cards or even to financial
transactions. The technique can be employed with essentially any
transaction that traditionally would be initiated by or involve the
use of a physical card reader. Hence, the term "sale", as in
point-of-sale (POS), refers to any type of payment-oriented
transaction, including a lease or rental for example, and is not
limited to an actual purchase. Note also that in this description,
the term "user" generally refers to a customer (as opposed to a
merchant), except where otherwise indicated, and except that the
term "user interface" does not necessarily refer to an interface
used by a customer, as will be apparent from the context.
[0018] In certain embodiments, the technique introduced here
involves the following sequence of actions, as described more fully
below. Initially, a customer registers with a cardless payment
service. At some later time, the customer visits a merchant and
"checks in" to the merchant by using a mobile payment application
on the customer's mobile device (e.g., a smartphone or tablet
computer). The check-in action triggers a sequence of messages and
other actions that cause the customer's name and photo to appear
relatively immediately on a display device of the merchant's POS
terminal.
[0019] When the customer is ready to pay, he simply tells the
merchant that he wants to pay with the payment service (preferably
mentioning the service by its advertised trade name). The merchant
then closes the ticket, or "tab", in the merchant POS system in the
traditional way. However, when it is time to swipe a credit card
through the merchant's card reader, the waiter instead simply taps
the customer's name or photo displayed on the merchant POS
terminal. The term "swipe" here refers to any manner of triggering
a physical card reader to read a physical card, such as passing a
card through a magnetic stripe reader, smartcard reader, optical
code reader, radio frequency identification (RFID) reader, etc.
[0020] A card read emulator (CRE) module in the merchant POS system
enables the cardless payment technique to cleanly integrate into
essentially any conventional POS system. It does so by emulating
physical card read events and intercepting receipt printer output
at the merchant POS system. More specifically, and as described in
detail below, the CRE module responds to the merchant's triggering
input by sending a virtual card swipe to the main POS software in
the POS system. The CRE module also intercepts the receipt printing
once the transaction has been authorized. Instead of printing a
physical receipt, the CRE module causes a virtual copy of the
receipt to be sent to the customer's mobile device, where it is
displayed to the customer by the mobile payment application. For
print operations that are not associated with a cardless
transaction, the CRE module simply allows those to pass unaffected
to the printer.
[0021] After some time, the customer may input a tip amount into
the mobile payment application on his mobile device. The CRE module
then instructs the merchant to enter the tip into their POS
terminal as if it were a "virtual merchant copy." Other ways of
inputting the tip amount and variations upon the disclosed
technique are also described below.
[0022] As described further below, the CRE module may be integrated
within the merchant POS terminal, or it may be a separate device.
If it is integrated within the POS terminal, it may be an integral
part of the main POS software application, or it may be a separate
add-on software application or hardware device. The CRE module
emulates the output of a physical card reader used by the merchant,
where no actual card read event occurs in relation to the payment
transaction. It does so by invoking the POS system's (well
published) card reader API associated with the particular card
reader used by the merchant, and sending the data that emulates the
output of the card reader to the main POS application in the output
protocol used by the card reader. The card reader can be, for
example, a conventional magnetic stripe card reader, a smartcard
(integrated circuit (IC) card) reader, barcode reader, quick
response (QR) code reader, RFID card reader, or the like.
[0023] After the transaction has been approved by a remote payment
processing entity, the CRE module prevents generation of a printed
receipt by using the POS terminal's (well published) printer API to
intercept a print signal generated by the main POS application (for
print operations that are not associated with a cardless
transaction, the CRE module simply allows those to pass unaffected
to the printer). In response to the print signal, the CRE module
causes a message to be sent from the merchant POS system to a
remote computer system of the cardless payment service, which
responds by sending a message to the consumer's mobile device to
cause the mobile payment application to display a virtual receipt
for the transaction.
[0024] FIG. 1 illustrates an environment in which the cardless
payment technique can be implemented. The environment includes a
merchant POS system of a merchant 100 and a mobile device 102 of a
user 101 (also referred to as "customer" or "consumer"). The mobile
device 102 can be, for example, a smart phone, tablet computer,
notebook computer, or any other form of mobile processing device. A
mobile payment application 120 runs on the user's mobile device
102. The environment also includes a computer system 114 of the
merchant's acquirer, a computer system 118 of an issuing bank, a
computer system 116 of a card payment network, and a computer
system 108 of a payment service (hereinafter "payment service
system 108"). Each of the aforementioned computer systems can
include one or more distinct physical computers and/or other
processing devices which, in the case of multiple devices, can be
connected to each other through one or more wired and/or wireless
networks. All of the aforementioned devices are coupled to each
other through an internetwork 106, which can be or include the
Internet and one or more wireless networks (e.g., a WiFi network
and or a cellular telecommunications network).
[0025] The environment illustrated in FIG. 1 can accommodate both
traditional payment card transactions (i.e., those involving
reading of physical card of the customer at the merchant's
location), as well as cardless transactions according to the
technique introduced here. In a traditional credit card
transaction, for example, the merchant swipes the user's credit
card through a card reader at the POS system 104. The POS system
104 sends data read from the card (e.g., the cardholders name,
credit card number, expiration date and card verification value
(CVV)) to the computer system 114 of the merchant's acquirer
(hereinafter "acquirer 114"). The acquirer 114 sends this data to
the computer system 116 of the card payment network (e.g., Visa or
MasterCard) (hereinafter "card payment network 116"), which
forwards the data to the computer system 118 of the issuing bank
(hereinafter "issuer 118). If the transaction is approved by the
issuer 118, a payment authorization message is sent from the issuer
118 to the merchant POS system 104 via a path opposite of that
described above.
[0026] A cardless payment service operates the payment service
system 108 to facilitate cardless payment transactions. The user's
mobile device 102 can communicate with the payment service system
108 over internetwork 106. The payment service system 108 includes
one or more server computers programmed to process payment
transactions involving users registered with the cardless payment
service. It also stores information such as registered credit card
numbers, debit card numbers, bank accounts, user accounts, user
identifying information or other sensitive information. The payment
service system 108 is also responsible for sending information
about merchants who have accounts with the cardless payment system
to the user's mobile device 102.
[0027] FIGS. 2A and 2B illustrate different embodiments of the
merchant POS system 104. Note that certain components that are not
germane to this description may not be shown. Referring first to
FIG. 2A, the merchant POS system 104 includes a main POS module 201
and a display 202. The main POS module 201 may be a software
application, e.g., a main POS application 201, as henceforth
assumed herein to facilitate description. Alternatively, it could
be a hardware component (which may include a POS application and/or
other POS software). The display 202 can be, for example, a
touchscreen display, or a traditional non-touch display (in which
case the merchant POS system 104 likely also includes a separate
keyboard or other input device). The merchant POS system 104 also
includes a card reader 204, such as a magnetic stripe card reader
or a smartcard reader, and a receipt printer 205 for printing
transaction receipts.
[0028] In accordance with the technique introduced here, the POS
system 104 also includes a CRE module 203 that communicates with
the main POS application 201. The CRE module 203 may also
communicate with the display 202, either directly or through the
main POS application 201. The CRE module 203 can be software,
hardware, or a combination thereof. As illustrated in FIG. 2A, the
CRE module 203 can be logically separate from the main POS module
but operate "along side" it. Alternatively, the CRE module 203 can
be an integral part of the main POS application 201, as shown in
FIG. 2B. Other alternatives include binding virtual USB devices or
implementing the CRE module 203 as a separate hardware device that
connects between the merchant POS terminal and the card reader 204
and printer 205.
[0029] The CRE module 203 has two main functions. Firstly, it
emulates card read events to the main POS module, by using a
protocol and API associated with the card reader. Secondly, it
intercepts print signals generated by the main POS application 201
for the printer 205, by using an API of the printer 205, and
triggers a sequence of operations to cause a virtual receipt to be
sent to the user's mobile device 102. These functions enable the
customer to pay by credit or debit in a cardless transaction,
without the need to customize software or hardware to accommodate
individual POS vendor-proprietary APIs.
[0030] Accordingly, as shown in FIG. 3, in certain embodiments the
CRE module 203 includes a card reader emulator 301 and a receipt
manager 302. The card reader emulator 301 is responsible for
emulating card read events to the main POS application 201. The
receipt manager 302 is responsible for intercepting print signals
generated by the main POS application 201 and triggering the
sequence of operations to cause a virtual receipt to be sent to the
user's mobile device 102. Dynamic-link library (DLL) injection can
be used to intercept and modify communications between the main POS
application 201 and the standard Windows USB APIs (e.g., used for a
magnetic stripe card reader) and printer APIs.
[0031] Note that certain POS systems might integrate with a card
processing terminal instead of a magnetic stripe reader. In those
cases, the CRE module 203 can simply emulate the card processing
terminal.
[0032] Before a cardless transaction between the user and the
merchant can be performed, the mobile payment application 120 is
installed on the user's mobile device 102 (e.g., through an online
application store) and the CRE module 203 is installed on the
merchant POS system 104. Additionally, the user is required to
create a user account with the payment service system 108. The user
can do so from the mobile device 102 by using the mobile payment
application 120 or a mobile web browser, or by using another
processing device such as a home computer with a conventional web
browser.
[0033] In certain embodiments, the user enters a name, account
password, and contact information, e.g., email address. Before a
cardless payment transaction can be performed, the user also enters
financial account information sufficient to conduct the transaction
into the payment service system 108. For example, in the case of a
credit card account, the user can enter the credit card issuer,
credit card number and expiration date into the payment service
system 108; the CVV and mailing address may also be required.
However, the financial account could also be associated with a
debit card or pre-paid card, or another third party financial
account.
[0034] In some embodiments, the payment service requires that the
user provide additional personal identifying information before a
cardless transaction will be allowed, such as a photo of the user.
The photo of the user would later be provided to the merchant
(e.g., via the CRE module 203) so that the merchant can compare the
photo to the person at the merchant's location. In addition, the
payment service can require a personal identification number (PIN)
be entered by the user. Other requirements can also be added to
increase security. The data associated with the user's account can
be stored in a database (not shown) at the payment service system
108.
[0035] In operation, the user carries the mobile device 102 with
the mobile payment application 120 installed, and the merchant uses
the POS system 104 as described above. The mobile payment
application 120, CRE module 203, payment service 108 and main POS
application 201 interact to enable the user to pay by a cardless
transaction. This is accomplished, in part, by determining a
relative location between the user's mobile device 102 and the
merchant. The system includes the ability to determine the current
location of the user's mobile device 102 with a relatively high
degree of accuracy. For example, the mobile device 102 may have an
internal geolocation device, such as a global positioning system
(GPS) receiver. Alternatively, the location of the mobile device
102 may be determined by the wireless network, e.g. using radio
frequency (RF) signal triangulation or other known technique. The
location of the merchant is assumed to be well known and pre-stored
within the payment service system 108.
[0036] The cardless payment service can predetermine a distance,
e.g., a radius, from the location of a merchant, such as 500 feet,
such that if the mobile device 102 is within that distance from a
given merchant and the checks in to the merchant, the system can
reliably assume that the user is in fact present at the merchant.
If the user is located within the predetermined distance from a
merchant, the user will be allowed to "check in" at the merchant by
using the mobile payment application 120. This may be done by, for
example, the user pressing a simple "check in" button or the like
on a display of the mobile device 102. The check-in function may be
considered to be an indication of the user's consent to perform a
cardless transaction with that particular merchant and effectively
"opens a tab" with the merchant. Alternatively, the mobile payment
application 120 may be configured to automatically check in the
user when the user is within the predetermined distance of the
merchant. If, on the other hand, the mobile device 102 is located
beyond the predetermined distance from a particular merchant, the
user will not be allowed to check in at that merchant. In that
case, the user device 102 will indicate to the user that it is too
far from the merchant to check-in.
[0037] FIG. 4 illustrates an example of a process of setting up and
initiating a cardless payment transaction, according to a first
embodiment of the technique introduced here. The process involves
relationships between the user's mobile device 102, the payment
service system 108, and the merchant POS system 104. The payment
service system 108 can be configured to send and receive
communications to and from the mobile device 102 and the merchant
POS system 104. The communications can be encrypted using secure
protocols built into the mobile device 102, payment service system
108, and merchant POS system 104. In some embodiments, this process
is implemented through the mobile payment application 120 installed
on the mobile device 102 and the CRE module 203 on the merchant POS
system 104.
[0038] Initially, the user inputs a request into the mobile device
102 to identify a merchant that can perform cardless payment
transactions. The request may be sent automatically, for example,
when the user opens the mobile payment application 120 on the
mobile device 102. The mobile device 102 sends the request to the
payment service system 108 via the internetwork 106. The request
can be accompanied by location information of the mobile device
102, e.g., as determined by the mobile device 102. The payment
service system 108 receives the request and selects one or more
merchants based on the location information from the customer and
the stored location information for the merchant. An identification
of the merchant and the location information for the merchant is
sent to the mobile device 102.
[0039] In some embodiments, the user checks in at the merchant by
interacting with the mobile payment application 120 running on the
user's mobile device 102 (step 402). When the user checks in, an
identification of the merchant and the location information for the
merchant is sent to the mobile device 102. The mobile device 102
determines whether it is within the predetermined distance from the
merchant (step 404). If the mobile device 102 does not know the
current location of the merchant, or if the merchant recently
updated its location information, the merchant location can be
pushed or pulled into the mobile device 102. Alternatively, if the
user opts in to sharing of location information, the location
information of the mobile device 102 can be provided to the payment
service system 108, which determines the 30 distance between the
merchant and the mobile device 102.
[0040] As described above, if the mobile device 102 determines the
user's mobile device 102 is not within the predetermined distance
(e.g. 500 feet), the mobile device 102 displays a message
indicating its inability to check in the user (step 408). In that
case, the merchant cannot charge the user's financial account by
using a cardless payment transaction. On the other hand, if the
mobile device 102 is within the predetermined distance, the mobile
device 102 sends an indication of proximity to the payment service
system 108 (step 406).
[0041] After the payment service system 108 receives this
indication of proximity, it sends the indication of the mobile
device 102's presence and personal identifying information to the
merchant POS system 104 (step 410). In some embodiments, the
personal identifying information sent to the merchant POS system
104 includes the user's name, photo and financial account number
(e.g., credit or debit card number). The financial account number
may be encrypted such that it can only be decrypted by the CRE
module 203, such that it cannot be displayed by the POS system or
otherwise accessed by the merchant.
[0042] Upon receipt of this information, the merchant POS system
104 displays a tab (a list of items the customer has ordered) (step
412) and the user's identifying information (e.g., name and photo)
(step 414) on a graphical user interface (GUI) on its display 202.
An example of such a GUI is shown in FIG. 5. In the illustrated
example, the right-hand portion 501 of the display is a customer
tab section that includes a separate subsection 502 for each
customer who has checked in at the merchant via the cardless
payment service. The customer tab section 501 can be generated by
the CRE module 203, for example, or by other merchant-side POS
software. The amount each customer owes can be displayed in the
corresponding subsection 502 for that customer on the display.
[0043] The left-hand portion 503 of the GUI is generated by the
main POS application 201 and contains, for example, names and
images of the items that can be ordered/purchased and their prices.
In other embodiments, the user information displayed by the CRE
module 203 can be provided in a completely separate window from
that of the main POS application 201. Hence, in some embodiments,
through the GUI the merchant can select items that a customer has
requested to purchase. The GUI can be configured to associate
individual prices with each of the merchant's items and can
automatically sum the total transaction amount that the customer
owes.
[0044] In some embodiments, displaying of the customer tab section
502 may be triggered automatically when a customer who is
registered with the cardless payment service checks in at the
merchant. Alternatively, it may be triggered by a soft-button on
the GUI generated by the main POS application 201. Such a soft
button may be generated by the CRE module 203 and may automatically
change appearance when a user registered with the cardless payment
service checks in at the merchant.
[0045] In yet another embodiment, a hardware button or other
similar physical control is provided on a separate hardware module
(not shown) that connects externally to the merchant POS terminal
(e.g., via a USB port or other conventional interface) and
communicates with the CRE module 203 to trigger the display of the
customer tab portion 502. The separate hardware module can emulate
a USB keyboard and generate a key combination that causes the
merchant POS system 104 to enter the desired state as mentioned
above. In an extension of this approach, the hardware module can
also contain a storage device (e.g., a USB flash drive) that
contains the CRE module 203. Activation of the button or other
control on the separate hardware module can cause notifications to
be displayed on the display of the POS system 104 and/or light up
the button when a customer checks in at the merchant.
[0046] A customer (user) can authorize payment for his tab by
orally notifying the merchant. For example, a user named John Smith
can simply tell the merchant, "Put this on John Smith." Before or
after the user authorizes payment for the tab, the merchant
verifies the user's identity (step 416), for example by confirming
that the photo displayed on the merchant POS system 104 matches the
user who is present in person. Assuming the photo matches, the
merchant then selects the user's tab (e.g., by tapping the
corresponding section 501 on the GUI) to trigger a cardless payment
transaction (step 418) when the customer is ready to pay.
[0047] In one embodiment, the cardless payment transaction involves
the following operations, as illustrated in FIG. 6. In response to
the merchant providing a user input 601 to trigger the cardless
payment transaction, the CRE module 203 emulates the card reader by
sending, to the main POS application 201, card read event data 602
associated with the consumer. The card read event data 602 appears
to the main POS application 201 to be data resulting from a card
read event, although no actual card read event has occurred. The
CRE module 203 does this by invoking the main POS application's
card reader API and sending the data in the output protocol of the
card reader 204. In an embodiment consistent with FIG. 4, the CRE
module 203 previously received from the payment service system 108
a real payment card account number (e.g., credit card number) of
the customer when the customer checked in at the merchant.
Accordingly, that account number as well as the consumer's name,
card expiration date and CVV are provided by the CRE module 203 to
the main POS application 201 in the protocol of the card reader
204. In another embodiment, which is discussed further below, the
CRE module 203 or the payment service system 108 generates a
one-time-use payment card number for the transaction, and passes
that to the main POS application 201 instead of a real payment card
number of the consumer. It is not necessary for the CRE module 203
to implement the entire protocol of the card reader, since it only
needs to be able to inject simulated card swipes to the main POS
application 201. In one embodiment, the CRE module 203 is
programmed with DUKPT (Derived Unique Key Per Transaction) keys for
the merchant's acquirer, for the purpose of emulating a card swipe.
Other data related to the customer may also be provided, if
required by the API of the card reader 204.
[0048] The main POS application 201, upon receiving the card read
event data 602 from the CRE module 203, sends the card read event
data in a standard payment authorization request 603 that is
forwarded to the issuer 118. In practice, the payment authorization
request 603 may actually be sent first to the merchant's acquirer
114, which forwards the request or sends a corresponding new
request to the card payment network 116, which then forwards the
request or sends a corresponding new request to the issuer 118;
however, these intermediate communications are omitted from FIG. 6
to simplify explanation.
[0049] If the transaction is approved by the issuer 118, the issuer
118 sends a standard payment authorization (approval) message 604
back to the merchant's main POS application 201, using a
communication path opposite of that mentioned above. The main POS
application 201 responds to the payment authorization message by
generating a print message 605 for the local receipt printer 205 of
the merchant POS system 104. However, the CRE module 203, by having
access to the main POS application 201's printer API, intercepts
the print signal before it can reach the printer 205. In response
to detecting the print signal, the CRE module 203 also sends a
message 606 to the payment service system 108 (via the internetwork
106) indicating that a payment authorization message has been
received. The payment service system 108 responds by sending a
message 607 containing a virtual receipt for the transaction to the
user's mobile device 102. The mobile payment application 120 on the
mobile device 102 then displays the virtual receipt to the user.
The virtual receipt can include all of the information that a
printed card transaction receipt would include, including the
amount charged, name of the consumer, date and time of the
transaction, etc. The user can then optionally input a tip amount.
Different ways of handling tips in this process are discussed
further below.
[0050] In certain embodiments, the payment service system 108
parses the receipt data before sending the virtual receipt to the
mobile payment application 120, to determine whether the
transaction processed successfully or not. It can also parse the
receipt data to identify various semantic elements, including the
total amount of the transaction and items ordered by the customer.
Consequently, in such embodiments the virtual receipt that the
payment service system 108 sends to the mobile device 102 also
contains an itemization of these elements, which can be displayed
to the user. Alternatively, the parsing can be performed by the CRE
module 203.
[0051] Note that most POS systems use relational databases, such as
Sybase or Microsoft's SQL Server, to store their payment card
transaction data. The payment service system 108 can capture most
if not all essential transaction data by parsing receipts as
described above. Nonetheless, it might be desirable to synchronize
a merchant's POS database with a database of the payment service
system 108. Among other benefits, that would allow the payment
service 108 to provide backup storage for merchants.
[0052] FIG. 6B illustrates an example of a process that can be
performed by the CRE module 203 in the embodiment described above.
The process begins when the CRE module 203 detects a user input
specifying a checked-in customer and being indicative of an intent
to initiate a payment transaction involving the customer (step
622). In response to the user input, the CRE module 203 initiates
the payment transaction by outputting, to the main POS application
201, data that emulates output of the card reader 204, without an
actual card read event having occurred in relation to the payment
transaction (step 624). After the transaction has been approved by
a payment processing entity (e.g., the issuer 118), when the CRE
module 203 detects a print signal generated by the main POS module
201 for generating a transaction receipt (step 626), the CRE module
203 prevents generation of a printed receipt by intercepting the
print signal (step 628). The print signal includes receipt data for
enabling a receipt to be printed by the receipt printer 205. In
response to the print signal, the CRE module 203 sends a first
message to the payment service system 108 (step 630), including at
least some of the receipt data, to cause the payment service system
108 to send a second message to the customer's mobile device 102.
The second message enables the mobile device 102 to output a
virtual receipt for the payment transaction to the consumer.
[0053] In the embodiment described above, the CRE module 203
receives from the payment service system 108 an actual payment card
number of the user, and passes that number to the main POS
application 201 when a transaction is initiated. In another
embodiment, however, the cardless payment service generates a
one-time-use payment card number for the transaction, and passes
that to the main POS application 201 instead of a real payment card
number of the consumer, as noted above. The one-time-use card
number can be generated by the payment service system 108 or by the
CRE module 203 in response to the user checking in at the merchant.
In this embodiment, the payment service which operates the payment
service system 108 essentially acts as the credit card issuer from
the perspective of the merchant. The merchant POS system 104
charges the one-time-use credit card number, and the payment
service later charges the consumer's actual credit card number
which is stored in the payment service system 108. The initial
set-up process in this embodiment can be substantially identical to
that of FIG. 4, except that in step 410, the payment service system
108 sends the one-time-use payment account number to the merchant
POS system 104 instead of sending the consumer's actual credit card
number. The one-time-use account number has a format recognizable
by the merchant POS system 104, e.g., a standard credit or debit
card format.
[0054] A cardless transaction using the one-time use payment
account number can involve the following operations, as illustrated
in FIG. 7. In response to the merchant 100 providing a user input
701 to trigger the cardless payment transaction, the CRE module 203
emulates the card reader 204 by sending, to the main POS
application 201, data 702 associated with the consumer that appears
to the main POS application 201 to be associated with a card read
event, although no actual card read event has occurred. This can be
done in the manner described above. The one-time-use payment
account number as well as the consumer's name, account expiration
date and CVV are provided by the CRE module 203 to the main POS
application 201 in the protocol of the card reader. Other data
related to the may also be provided if required by the API of the
card reader.
[0055] The main POS application 201, upon receiving the card read
event data 702 from the CRE module 203, sends the card read event
data in a standard payment authorization request 703 that, in this
embodiment, is forwarded to the payment service system 108, which
represents the issuer. In practice, the payment authorization
request 703 may actually be sent first to the merchant's acquirer
114, which forwards the request or sends a corresponding new
request to the card payment network 116, which then forwards the
request or generates a corresponding new request to the payment
service system 108; however, these intermediate communications are
omitted from FIG. 7 to simplify explanation.
[0056] If the transaction is approved by the payment service system
108, the payment service system 108 sends a standard payment
authorization (approval) message 704 back to the merchant's main
POS application 201, using a communication path opposite of that
mentioned above. The main POS application 201 responds to the
payment authorization message 704 by generating a print signal 705
for the local receipt printer 205 of the merchant POS system 104.
However, the CRE module 203 intercepts the print signal 705 and
prevents it from reaching the printer 205, as described above. In
this embodiment, the payment service system 108 does not need to
receive a signal from the CRE module 203 before sending send the
virtual receipt, since it already knows the transaction is
approved. Accordingly, at approximately the same time that the
payment service system 108 sends the payment authorization signal
704, or shortly thereafter, it also sends a message 706 containing
a virtual receipt for the transaction to the mobile device 102 of
the customer. The mobile payment application 120 on the customer's
mobile device 102 then displays the virtual receipt to the
user.
[0057] At some later time, the payment system 108 sends a payment
request 707 to the issuer 118 of an actual payment card of the
customer. The information of that actual payment card was
previously received and stored by the payment service system 108
when the customer registered for the cardless payment service. The
payment service system 108 subsequently receives payment 708 from
the issuer 118.
[0058] The technique introduced here also enables a customer to tip
the merchant (e.g., a waiter). There are various ways of
accomplishing that. In one approach, illustrated in FIG. 8, when
the virtual receipt is displayed to the customer 101 by the mobile
device 102, the customer is prompted (801) by the mobile payment
application 120 running on the mobile device 102 to input a tip
amount. Accordingly, the customer inputs (802) a tip amount into
the mobile payment application 120. The mobile payment application
120 then sends a message 803 to the payment service system 108
including the tip amount. The payment service system 108 than sends
a message 804 to the CRE module 203 in the merchant POS system 104
indicating the tip amount. The CRE module 203 then triggers the
display of the merchant POS system 104 to display the tip amount on
the display of the merchant POS system (805). The merchant 100 sees
the displayed tip amount and then inputs (806) the total
transaction amount (e.g., amount charged plus tip) into the main
POS application 201 in the traditional manner. The main POS
application 201 then processes the transaction according to the
traditional transaction capture process (807).
[0059] In another approach, rather than requiring the merchant to
copy over the tip amount into the main POS application 201, the CRE
module 203 simulates a sequence of user inputs (e.g., a sequence of
touchscreen or keypad presses) to the main POS application 201, to
cause the main POS application 201 to enter an appropriate state
for inputting the tip amount (or total transaction amount), and
then simulates the proper user input sequence to input that amount
into the main POS application 201. For example, the CRE module 203
can invoke an API of an input device of the POS system (e.g., a
touchscreen or keyboard/keypad) to communicate the tip amount to
the main POS application 201, such that the tip amount appears to
the main POS application 201 to have been input by a human
user.
[0060] In yet another approach, the waiter pre-registers with the
payment service system 108 as a merchant (or merchant employee, as
the case may be) and identifies himself to the CRE module 203 via
the GUI when he arrives at work each day. After a cardless payment
transaction has been authorized as described above, the CRE module
203 causes the display to output a prompt asking which waiter
should receive the tip. The waiter taps his own name on the
display. The CRE module 203 then sends a message indicating this
selection to the payment service system 108. The payment service
system 108 then pushes the tip directly to the waiter, via
automated clearing house (ACH) or debit, for example.
[0061] FIG. 9 is a high-level block diagram showing an example of a
processing device 900 that can represent any of the devices
described above, such as the mobile device 102, the merchant POS
system 104, payment service system 108, acquirer system 114, card
payment network 116, or issuer system 118. As noted above, any of
these systems may include two or more processing devices such as
represented in FIG. 9, which may be coupled to each other via a
network or multiple networks.
[0062] In the illustrated embodiment, the processing system 900
includes one or more processors 910, memory 911, a communication
device 912, and one or more input/output (I/O) devices 913, all
coupled to each other through an interconnect 914. The interconnect
914 may be or include one or more conductive traces, buses,
point-to-point connections, controllers, adapters and/or other
conventional connection devices. The processor(s) 910 may be or
include, for example, one or more general-purpose programmable
microprocessors, microcontrollers, application specific integrated
circuits (ASICs), programmable gate arrays, or the like, or a
combination of such devices. The processor(s) 910 control the
overall operation of the processing device 900. Memory 911 may be
or include one or more physical storage devices, which may be in
the form of random access memory (RAM), read-only memory (ROM)
(which may be erasable and programmable), flash memory, miniature
hard disk drive, or other suitable type of storage device, or a
combination of such devices. Memory 911 may store data and
instructions that configure the processor(s) 910 to execute
operations in accordance with the techniques described above. The
communication device 912 may be or include, for example, an
Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver,
Bluetooth transceiver, or the like, or a combination thereof.
Depending on the specific nature and purpose of the processing
device 900, the I/O devices 913 can include devices such as a
display (which may be a touch screen display), audio speaker,
keyboard, mouse or other pointing device, microphone, camera,
etc.
[0063] Unless contrary to physical possibility, it is envisioned
that (i) the methods/steps described above may be performed in any
sequence and/or in any combination, and that (ii) the components of
respective embodiments may be combined in any manner.
[0064] The techniques introduced above can be implemented by
programmable circuitry programmed/configured by software and/or
firmware, or entirely by special-purpose circuitry, or by a
combination of such forms. Such special-purpose circuitry (if any)
can be in the form of, for example, one or more
application-specific integrated circuits (ASICs), programmable
logic devices (PLDs), field-programmable gate arrays (FPGAs),
etc.
[0065] Software or firmware to implement the techniques introduced
here may be stored on a machine-readable storage medium and may be
executed by one or more general-purpose or special-purpose
programmable microprocessors. A "machine-readable medium", as the
term is used herein, includes any mechanism that can store
information in a form accessible by a machine (a machine may be,
for example, a computer, network device, cellular phone, personal
digital assistant (PDA), manufacturing tool, any device with one or
more processors, etc.). For example, a machine-accessible medium
includes recordable/non-recordable media (e.g., read-only memory
(ROM); random access memory (RAM); magnetic disk storage media;
optical storage media; flash memory devices; etc.), etc.
[0066] Note that any and all of the embodiments described above can
be combined with each other, except to the extent that it may be
stated otherwise above or to the extent that any such embodiments
might be mutually exclusive in function and/or structure.
[0067] Although the present invention has been described with
reference to specific exemplary embodiments, it will be recognized
that the invention is not limited to the embodiments described, but
can be practiced with modification and alteration within the spirit
and scope of the appended claims. Accordingly, the specification
and drawings are to be regarded in an illustrative sense rather
than a restrictive sense.
* * * * *