U.S. patent number 10,614,450 [Application Number 14/455,287] was granted by the patent office on 2020-04-07 for controlled emulation of payment cards.
This patent grant is currently assigned to Squre, Inc.. The grantee listed for this patent is Square, Inc.. Invention is credited to Paul Aaron, Andrew Borovsky, Jesse L. Dorogusker, Alexey Kalinichenko, Thomas Templeton.
![](/patent/grant/10614450/US10614450-20200407-D00000.png)
![](/patent/grant/10614450/US10614450-20200407-D00001.png)
![](/patent/grant/10614450/US10614450-20200407-D00002.png)
![](/patent/grant/10614450/US10614450-20200407-D00003.png)
![](/patent/grant/10614450/US10614450-20200407-D00004.png)
![](/patent/grant/10614450/US10614450-20200407-D00005.png)
![](/patent/grant/10614450/US10614450-20200407-D00006.png)
United States Patent |
10,614,450 |
Templeton , et al. |
April 7, 2020 |
Controlled emulation of payment cards
Abstract
A technique for a proxy card to emulate each of a plurality of
payment cards according to emulation rules associated with the
payment card. The proxy card initially selects one of the plurality
of payment cards for emulation based on one or more selection rules
or a user instruction. Next, the proxy card emulates the selected
payment card according to one or more emulation rule associated
with the selected payment card, each relating to how emulation is
performed with respect to time, location, business, or other
factors.
Inventors: |
Templeton; Thomas (San
Francisco, CA), Kalinichenko; Alexey (San Francisco, CA),
Borovsky; Andrew (New York, NY), Aaron; Paul (San
Francisco, CA), Dorogusker; Jesse L. (Palo Alto, CA) |
Applicant: |
Name |
City |
State |
Country |
Type |
Square, Inc. |
San Francisco |
CA |
US |
|
|
Assignee: |
Squre, Inc. (San Francisco,
unknown)
|
Family
ID: |
70056355 |
Appl.
No.: |
14/455,287 |
Filed: |
August 8, 2014 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q
20/105 (20130101); G06Q 20/34 (20130101); G06Q
20/405 (20130101); G06Q 20/351 (20130101); G06Q
20/367 (20130101); G06Q 20/204 (20130101); G06Q
20/354 (20130101); G06Q 20/3572 (20130101) |
Current International
Class: |
G06Q
20/00 (20120101); G06Q 20/34 (20120101); G06Q
20/10 (20120101); G06Q 20/20 (20120101) |
Field of
Search: |
;705/16,41 ;235/492 |
References Cited
[Referenced By]
U.S. Patent Documents
Foreign Patent Documents
|
|
|
|
|
|
|
H05333966 |
|
Dec 1993 |
|
JP |
|
2015/061005 |
|
Apr 2015 |
|
WO |
|
2016/003831 |
|
Jan 2016 |
|
WO |
|
Other References
Non-Final Office Action dated Aug. 23, 2017, for U.S. Appl. No.
14/455,225, of Templeton, T., et al., filed Aug. 8, 2014. cited by
applicant .
Final Office Action dated Sep. 29, 2017, for U.S. Appl. No.
14/455,220, of Templeton, T., et al., filed Aug. 8, 2014. cited by
applicant .
U.S. Appl. No. 14/168,274 of Odawa, A. et al., filed Jan. 30, 2014.
cited by applicant .
U.S. Appl. No. 14/455,220 of Templeton, T. et al., filed Aug. 8,
2014. cited by applicant .
U.S. Appl. No. 14/455,225 of Templeton, T. et al., filed Aug. 8,
2014. cited by applicant .
Non-Final Office Action dated Jan. 20, 2017, for U.S. Appl. No.
14/168,274, of Odawa, A.W., et al., filed Jan. 30, 2014. cited by
applicant .
Non-Final Office Action dated Apr. 27, 2017, for U.S. Appl. No.
14/455,220, of Templeton, T., et al., filed Aug. 8, 2014. cited by
applicant .
Final Office Action dated May 19, 2017, for U.S. Appl. No.
14/168,274, of Odawa, A.W., et al., filed Jan. 30, 2014. cited by
applicant .
"Bluetooth Accessory Design Guidelines for Apple Products," Apple
Inc., dated Sep. 18, 2013, Retrieved from the Internet URL:
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf-
, pp. 1-40. cited by applicant .
Chiraag, "A payment Card that Changes Magnetic Stripe via
Smartphone," published Nov. 12, 2013, Retrieved from the Internet
URL:
https://letstalkpayments.com/card-changes-magnetic-stripe-via-smartphone/-
, on Jan. 3, 2018, pp. 1-6. cited by applicant .
Non-Final Office Action dated Jan. 9, 2015, for U.S. Appl. No.
14/145,895 of Aaron, P., et al., filed Dec. 31, 2013. cited by
applicant .
Non-Final Office Action dated Feb. 6, 2015, for U.S. Appl. No.
14/478,522, of Lamba, K., filed Sep. 5, 2014. cited by applicant
.
Non-Final Office Action dated Feb. 18, 2015, for U.S. Appl. No.
14/244,632, of Quigley, O.S.C., et al., filed Apr. 3, 2014. cited
by applicant .
Non-Final Office Action dated May 12, 2015, for U.S. Appl. No.
14/189,869 of Lamba, K., et al., filed Feb. 25, 2014. cited by
applicant .
Non-Final Office Action dated May 26, 2015, for U.S. Appl. No.
14/225,338, of Aaron, P., et al., filed Mar. 25, 2014. cited by
applicant .
Non-Final Office Action dated May 27, 2015, for U.S. Appl. No.
14/197,704, of Lamba, K., et al., filed Mar. 5, 2014. cited by
applicant .
Notice of Allowance dated Jun. 3, 2015, for U.S. Appl. No.
14/478,522, of Lamba, K., filed Sep. 5, 2014. cited by applicant
.
Notice of Allowance dated Jul. 6, 2015, for U.S. Appl. No.
14/244,632, of Quigley, O.S.C., et al., filed Apr. 3, 2014. cited
by applicant .
Final Office Action dated Aug. 18, 2015, for U.S. Appl. No.
14/145,895, of Aaron, P., et al., filed Dec. 31, 2013. cited by
applicant .
Notice of Allowance dated Sep. 3, 2015, for U.S. Appl. No.
14/244,632, of Quigley, O.S.C., et al., filed Apr. 3, 2014. cited
by applicant .
Notice of Allowance dated Sep. 18, 2015, for U.S. Appl. No.
14/197,704, of Lamba, K., et al., filed Mar. 5, 2014. cited by
applicant .
Non-Final Office Action dated Sep. 23, 2015, for U.S. Appl. No.
14/478,601, of Steshenko, R.T.S. V., filed Sep. 5, 2014. cited by
applicant .
Final Office Action dated Oct. 2, 2015, for U.S. Appl. No.
14/225,338, of Aaron, P., et al., filed Mar. 25, 2014. cited by
applicant .
Advisory Action dated Dec. 31, 2015, for U.S. Appl. No. 14/225,338,
of Aaron, P., et al., filed Mar. 25, 2014. cited by applicant .
Non-Final Office Action dated Jan. 22, 2016, for U.S. Appl. No.
14/189,869, of Lamba, K., et al., filed Feb. 25, 2014. cited by
applicant .
Notice of Allowance dated Feb. 8, 2016, for U.S. Appl. No.
14/478,601, of Steshenko, R.T.S.V., filed Sep. 5, 2014. cited by
applicant .
Non-Final Office Action dated Mar. 24, 2016, for U.S. Appl. No.
14/145,895, of Aaron, P., et al., filed Dec. 31, 2013. cited by
applicant .
Non-Final Office Action dated May 9, 2016, for U.S. Appl. No.
14/225,338, of Aaron, P., et al., filed Mar. 25, 2014. cited by
applicant .
Final Office Action dated Jul. 18, 2016, for U.S. Appl. No.
14/189,869, of Lamba, K., et al., filed Feb. 25, 2014. cited by
applicant .
Non-Final Office Action dated Aug. 4, 2016, for U.S. Appl. No.
14/321,429, of Wade, J., filed Jul. 1, 2014. cited by applicant
.
Final Office Action dated Sep. 1, 2016, for U.S. Appl. No.
14/225,338, of Aaron, P., et al., filed Mar. 25, 2014. cited by
applicant .
Advisory Action dated Oct. 11, 2016, for U.S. Appl. No. 14/189,869,
of Lamba, K., et al., filed Feb. 25, 2014. cited by applicant .
Final Office Action dated Oct. 12, 2016, for U.S. Appl. No.
14/145,895, of Aaron, P., et al., filed Dec. 31, 2013. cited by
applicant .
Non-Final Office Action dated Nov. 3, 2016, for U.S. Appl. No.
14/225,342, of Lamba, K., et al., filed Mar. 25, 2014. cited by
applicant .
Notice of Allowance dated Nov. 8, 2016, for U.S. Appl. No.
14/225,338, of Aaron, P., et al., filed Mar. 25, 2014. cited by
applicant .
Advisory Action dated Dec. 22, 2016, for U.S. Appl. No. 14/145,895,
of Aaron, P., et al., filed Dec. 31, 2013. cited by applicant .
Notice of Allowance dated Feb. 7, 2017, for U.S. Appl. No.
14/321,429, of Wade, J., filed Jul. 1, 2014. cited by applicant
.
Final Office Action dated Mar. 10, 2017, for U.S. Appl. No.
14/225,342, of Lamba, K., et al., filed Mar. 25, 2014. cited by
applicant .
Non-Final Office Action dated Mar. 13, 2017, for U.S. Appl. No.
14/189,869, of Lamba, K., et al., filed Feb. 25, 2014. cited by
applicant .
Non-Final Office Action dated Apr. 12, 2017, for U.S. Appl. No.
14/145,895, of Aaron, P., et al., filed Dec. 31, 2013. cited by
applicant .
Advisory Action dated Jun. 9, 2017, for U.S. Appl. No. 14/225,342,
of Lamba, K., et al., filed Mar. 25, 2014. cited by applicant .
Non-Final Office Action dated Jun. 29, 2017, for U.S. Appl. No.
14/189,869, of Lamba, K., et al., filed Feb. 25, 2014. cited by
applicant .
Notice of Allowance dated Nov. 9, 2017, for U.S. Appl. No.
14/145,895, of Aaron, P., et al., filed Dec. 31, 2013. cited by
applicant .
Advisory Action dated Dec. 11, 2017, for U.S. Appl. No. 14/455,220,
of Templeton, T., et al., filed Aug. 8, 2014. cited by applicant
.
Final Office Action dated Jan. 8, 2018, for U.S. Appl. No.
14/189,869, of Lamba, K., et al.al., filed Feb. 25, 2014. cited by
applicant .
Office Action for European Patent Application No. 14855987.5, dated
Mar. 23, 2018. cited by applicant .
Advisory Action dated Apr. 12, 2018, for U.S. Appl. No. 14/189,869,
of Lamba, K., et al., filed Feb. 25, 2014. cited by applicant .
Final Office Action dated May 2, 2018, for U.S. Appl. No.
14/455,225, of Templeton, T., et al., filed Aug. 8, 2014. cited by
applicant .
International Search Report and Written Opinion for International
Application No. PCT/US2014/058447, dated Jan. 15, 2015. cited by
applicant .
International Search Report and Written Opinion for International
Application No. PCT/US2015/038165, dated Sep. 17, 2015. cited by
applicant .
Extended European Search Report for European Patent Application No.
14855987.5, dated May 10, 2017. cited by applicant .
Non-Final Office Action dated Oct. 5, 2018, for U.S. Appl. No.
14/189,869, of Lamba, K., et al., filed Feb. 25, 2014. cited by
applicant .
Advisory Action dated Jul. 25, 2018, for U.S. Appl. No. 14/455,225,
of Templeton, T., et al., filed Aug. 8, 2014. cited by applicant
.
Office Action for European Patent Application No. 14855987.5, dated
Sep. 14, 2018. cited by applicant .
Notice of Allowance dated Dec. 27, 2018, for U.S. Appl. No.
14/455,225, of Templeton T., et al., filed Aug. 8, 2014. cited by
applicant .
Notice of Allowance dated Jan. 7, 2019, for U.S. Appl. No.
14/455,220, of Templeton, T., et al., filed Aug. 8, 2014. cited by
applicant .
Final Office Action dated Feb. 25, 2019, for U.S. Appl. No.
14/189,869, of Lamba, K., et al., filed Feb. 25, 2014. cited by
applicant .
Advisory Action dated May 7, 2019, for U.S. Appl. No. 14/189,869,
of Lamba, K., et al., filed Feb. 25, 2014. cited by applicant .
Non-Final Action dated May 30, 2019, for U.S. Appl. No. 15/436,478,
of Kartik Lamba filed Feb. 17, 2017. cited by applicant.
|
Primary Examiner: Iwarere; Oluseye
Attorney, Agent or Firm: Schott, P.C.
Claims
The invention claimed is:
1. A method comprising: receiving, by an electronic system, a
request regarding an emulation rule of a plurality of emulation
rules for one of a plurality of payment cards to be emulated by a
card that is external to the electronic system; creating or
modifying, by the electronic system, the emulation rule in response
to the request; and transmitting, to the card, the created or
modified emulation rule when an update has been made to the
plurality of emulation rules, wherein the created or modified
emulation rule is applied to the card in response to a trigger
event, wherein application of different emulation rules,
corresponding to the plurality of payment cards, to the card
facilitates a user of the card with benefits from use of the
plurality of payment cards with a single card, and wherein the card
has an appearance of a payment card and contains a processing
element and memory.
2. The method of claim 1, further comprising: receiving a second
request regarding the plurality of emulation rules for one of the
plurality of payment cards; and combining the plurality of
emulation rules by Boolean operators in response to the second
request.
3. The method of claim 1, further comprising: receiving a second
request regarding the plurality of emulation rules for one of the
plurality of payment cards; and prioritizing the plurality of
emulation rules in response to the second request.
4. The method of claim 1, further comprising receiving a second
request regarding a selection rule for selecting one of the
plurality of payment cards for emulation.
5. The method of claim 4, wherein the selection rule involves a
time, a location, or a business.
6. The method of claim 4, further comprising creating, modifying,
or deleting the selection rule in response to the second
request.
7. The method of claim 4, further comprising: receiving a third
request regarding a plurality of selection rules for one of the
plurality of payment cards; and combining the plurality of
selection rules or prioritizing the plurality of selection rules in
response to the third request.
Description
BACKGROUND
A consumer today may use several types of payment cards, such as a
credit card, a gift card, and an ATM card. Different types of
payment cards may be well suited for different occasions. For
example, a consumer would want to use an ATM card when no credit is
accepted or use a gift card from a merchant in a business location
of the merchant. It can be inconvenient and unwieldy to manage a
number of payment cards. In addition, the use of each payment card
often needs to be specifically controlled. For example, a consumer
would want to deactivate a payment card when it is stolen, and a
parent may want to limit the use of a payment card given to a
child.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the present invention will be described and
explained through the use of the accompanying drawings in
which:
FIG. 1A illustrates an example environment in which a consumer sets
up a proxy card profile using an electronic device.
FIG. 1B illustrates an example proxy card profile.
FIG. 1C illustrates an example environment in which a consumer uses
a proxy card for payment at a point-of-sale (POS) system in a
store.
FIG. 2 is a flow diagram illustrating an example process performed
by an electronic device for setting up a proxy card profile.
FIG. 3 is a flow diagram illustrating an example process performed
by a proxy card for selecting and emulating one of a plurality of
payment cards.
FIG. 4 is a high-level block diagram showing an example of a
processing device that can implement techniques described
herein.
DETAILED DESCRIPTION
In this description, references 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 technique introduced here.
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.
Introduced here is a technique related to a proxy card which
emulates different payment cards according to different rules.
Using this technique, a consumer benefits from the use of multiple
payment cards with the single proxy card. Furthermore, the consumer
can manage the selection of a payment card for emulation and the
emulation of each selected payment card with various rules based on
time, location, business, or other factor(s). Specifically, the
consumer can create, edit or delete the various rules for each
payment card using an electronic device, such as a mobile phone,
which transmits the resulting rules to the proxy card at various
points in time.
In certain embodiments a "proxy card" is a card that can emulate
one or more other cards/accounts (e.g., payment cards/accounts).
The proxy card is essentially identical or similar in appearance to
a payment card, such as a credit card, a debit card, or a gift
card, being roughly of wallet size and having an identification
component, such as a magnetic stripe or integrated circuit (IC)
chip, which can hold information identifying one or more payment
cards. In addition, in some embodiments the proxy card includes a
processor and memory capable of computation, processing and storage
functionalities. The proxy card may also include input and output
elements, such as a button or switch for input and a liquid-crystal
display (LCD) or light emitting diode (LED) display for output.
Furthermore, the proxy card includes a communication interface to
carry out short-range (typically less than 100 meters) wireless
communication, which may be implemented by Bluetooth Low Energy
(BLE), for example. These features enable the proxy card to emulate
each of multiple payment cards according to specified rules.
In some embodiments, the proxy card stores in the memory one or
more rules governing the emulation of each payment card. It also
stores in the memory identification information for each payment
card. Upon accepting a selection of one of the multiple payment
cards, through the input element or the communication interface,
the processor configures the identification component to correspond
to the selected payment card in accordance with emulation rules
associated with the payment card. The proxy card also displays any
status update or error message through the output element.
FIG. 1A illustrates an example environment in which a consumer sets
up a proxy card profile by using an electronic device. In some
embodiments, before using a proxy card, the consumer needs to
register one or more payment cards to be emulated by the proxy card
and sets up a profile for the proxy card on a server system 108.
One way to register each of the payment cards is through an
electronic sensing device, such as a Radio-Frequency Identification
(RFID) scanner or a Near Field Communication (NFC) scanner,
attached to an electronic device, such as a mobile phone 104, which
is capable of communicating with the server system 108. The
communication between the electronic sensing device and the proxy
card can be through a short-range wireless link, such as standard
Bluetooth, BLE, Wi-Fi, RFID, and NFC, or direct access to the
identification component on the proxy card. The communication
between the electronic device and the server system 108 can be
through any network link, such as the Internet. During
registration, the electronic sensing device receives information
from each payment card, and the electronic device forwards the
received information to the server system 108, which then saves the
forwarded information in databases.
In some embodiments, the server system 108 provides a client device
with a graphical user interface (GUI) for the management of a proxy
card profile. The GUI can be displayed on any of various client
electronic devices, such as a mobile phone 104, a tablet, a laptop,
or a desktop. The consumer can create, edit, or delete a proxy card
profile on the server system 108. FIG. 1B illustrates an example
proxy card profile. The proxy card profile includes two sections, a
selection section 130 with rules for selecting one of the
registered payment cards to emulate, and an emulation section 132
with rules for emulating each of the registered payment cards. The
server system 108 can prepopulate the emulation section with
information regarding each of the registered payment cards. The
server system 108 can also add a "blank card" that corresponds to a
state of no emulation to be distinguished from a real payment card.
This blank card can be selected when no payment card is to be
emulated by the proxy card.
In the selection section 130, each line corresponds to a selection
rule. The selection rules specify how to select one or more payment
cards out of a group of payment cards. The selection rules can be
expressed in various forms, with regard to time, location,
business, or other factors. Some examples are as follows: 1)
selecting a particular payment card after normal business hours; 2)
selecting a gift card from a particular merchant when the proxy
card is located within a business establishment of the merchant; 3)
selecting a payment card with a low foreign exchange rate when the
proxy card 102 is located in a foreign country; 4) selecting a
particular payment card when the proxy card is located at a
business in a particular industry (e.g., entertainment, restaurant,
etc.); 5) selecting a credit card instead of a debit card under a
specified condition; 6) selecting a payment card in the consumer's
name before selecting a payment card not in the consumer's name; 7)
skipping a payment card that has been used more than a specified
number of times or for transactions totaling more than a specified
amount of money during a period of time.
In some embodiments, the selection rules can incorporate or be
combined with Boolean operators. They can also be prioritized so
that conflicts between them can be resolved. In some embodiments,
while the selection rules enable an automatic selection of a
payment card, they can be overridden by the consumer at the time of
using the proxy card, as discussed below.
In the emulation section 132, each row corresponds to a set of
emulation rules associated with a registered payment card, i.e., a
payment card associated with the proxy card. These emulation rules
control the emulation of a payment card, controlling how the
payment card is emulated, for security, efficiency, and other
purposes. The emulation rules can also be expressed in various
forms, with regard to time, location, business, or other
factors.
In some embodiments, regarding time, an emulation rule specifies
that the emulation is on or off at a designated time or relative to
the occurrence of an event, or the emulation lasts for a specified
period of time, etc. Such an event can be, for example, the push of
a button on the proxy card to signify the beginning of emulation,
the accessing of the identification component on the proxy card,
which normally signifies the end of emulation, the entering or
exiting of a business location, the opening or closing of a
business location, etc. Regarding location, an emulation rule
specifies that the emulation is on or off at a designated location,
near a particular object, etc. A designated location can be as
specific as an address or the name of a business establishment or
as broad as a category of businesses, such as a restaurant, or the
name of a geographic area, such as New York City. An object in a
scenario can be, for example, a mobile electronic device that also
belongs to the consumer and communicates with the server system
108, such as a smart phone. The presence of such an object near the
proxy card increases the possibility that the proxy card is in the
possession of its rightful owner. Regarding business, an emulation
rule specifies that the emulation is on or off depending on the
nature of the business operating at the current location. Various
aspects of the business can be taken into consideration, such as
the size, the credit history, the customer service, etc.
In some embodiments, for each of the registered payment cards,
multiple emulation rules can be combined. For example, a parent who
controls the use of the proxy card by a child may create a first
rule combination which indicates that a payment card is emulated
for one hour from the time the button on the proxy card 102 is
pushed when the business operating at the current location is a
video game store, and a second rule combination which indicates
that the payment card is emulated during the entire time the proxy
card is on the premises of the business operating at the current
location when the business is a bookstore. Furthermore, multiple
emulation rules or combinations of emulation rules can be
prioritized so that conflicts between them can be resolved.
In some embodiments, certain data regarding the registered payment
cards, including the identification information and the proxy card
profile, are transmitted from the server system 108 to the proxy
card at various times. For example, the data regarding the
registered payment cards can be transmitted to the proxy card 102
periodically or whenever a new payment card is registered and an
existing payment card is un-registered. The proxy card profile
similarly can be transmitted periodically or whenever a certain
amount of update has been made to the proxy card profile. The
transmission can result from a push from the server system 108 or a
pull from the proxy card. Communication between the server system
108 and the proxy card can be through an electronic device that
also belongs to the consumer and that communicates with the server
system 108, such as the mobile phone 104. Specifically, the
communication between the server system 108 and the mobile phone
104 can be through a cellular network and another network such as
the Internet, for example, and the communication between the mobile
phone 104 and the proxy card 102 can be through a short-range
wireless link, which can be implemented by BLE.
FIG. 1C illustrates an example environment in which a consumer uses
a proxy card for payment at a POS system in a store. In some
embodiments, when the selection rules do not determine a payment
card to emulate by default, the proxy card 102 displays a prompt
for the consumer to select a payment card to emulate. The proxy
card 102 allows the consumer to select a payment card using a
button, a navigation key or other input element on the proxy card.
A consumer can also make a selection using an electronic device,
such as a mobile phone 104, which then communicates the selection
to the proxy card 102. Once a payment card is selected for
emulation, the associated emulation rules are applied.
In some embodiments, in applying the selection or emulation rules,
the proxy card 102 determines whether a specific event has
occurred, such as the push of a button on the proxy card 102 or the
closing of a business location where the proxy card 102 is located.
The proxy card 102 can detect the occurrence of an event or receive
information from a nearby electronic device, such as the mobile
phone 104, regarding the occurrence of an event through a
short-range wireless link, such as BLE. As one example, the proxy
card 102 can contain special hardware, such as an accelerometer,
which detects the pressure exerted on or the speed of the proxy
card 102, thereby determining whether the proxy card 102 is being
swiped through a magnetic card reader. As another example, when the
proxy card 102 is swiped through a magnetic card reader attached to
the POS system 106, the information read from a magnetic stripe on
the proxy card 102 can be transmitted from the POS system 106
through the server system 108 and the mobile phone 104 and back to
the proxy card 102. The proxy card 102 also determines whether it
is in a particular location or near a particular object. As one
example, the proxy card 102 determines whether it is near a mobile
phone of the consumer by requesting the mobile phone 104 to
transmit its mobile phone number, where both the request and the
response can be via a short-range wireless link, such as BLE. Next,
the proxy card 102 determines whether the transmitted number
matches the number for the mobile phone 104 previously stored on
the proxy card 102. As another example, the proxy card 102
determines whether it is in a particular location by requesting the
mobile phone 104, which has Global Positioning System (GPS)
capabilities, to transmit information regarding its current
location, using a short-range wireless link such as mentioned
above. In addition, the proxy card 102 determines the nature of the
business operating at the current location. The proxy card 102 can
similarly rely on the mobile phone 104 to obtain such information
directly, from a web search, for example, or by contacting the
server system 108, which stores data regarding merchants and
businesses. The proxy card 102 can also request a POS system 106
near the current location to transmit information regarding the
business, such as a Merchant Category Code (MCC), using a
short-range wireless link.
In some embodiments, as a result of applying the emulation rules,
the proxy card 102 begins and ends the emulation of the selected
payment card accordingly. It is possible that when the proxy card
102 is actually used, where the identification component is
accessed by the POS system 106, for example, the emulation of the
selected payment card is off according to the associated emulation
rules. In that case, the proxy card 102 or the POS system 106 can
display an error message. In response, the consumer may manually
select another payment card, re-initiate an event, such as pushing
a button on the proxy card 102, or take other actions to remedy the
situation. The proxy card 102 can also automatically select the
next payment card based on the selection rules.
In some embodiments, when the proxy card 102 is not emulating any
payment card (e.g., because it is set to emulate the blank card,
because the emulation is off for the selected payment card, or for
some other reason), the proxy card 102 turns on a fraud protection
feature. For example, the proxy card 102 displays an error message
in an LCD on the proxy card 102 or sends an alert to the mobile
phone 104 when the number of attempts to use the proxy card exceeds
a predetermined threshold during a certain timeframe or
duration.
FIG. 2 is a flow diagram illustrating an example process performed
by an electronic system for managing emulation rules that are part
of a proxy card profile for a proxy card. The proxy card is used to
emulate a group of payment cards, each being, for example, a credit
card, a debit card, a gift card, an ATM card, a fleet card, etc. In
step 202, an electronic system receives a request from a user of
the electronic system, typically the owner of the proxy card,
regarding one or more emulation rules associated with one of the
group of payment cards. The electronic system can be or include,
for example, a server system that stores all the emulation rules.
It can also be or include a client electronic device, such as a
mobile phone, tablet computer, laptop computer, or desktop
computer, which supports a GUI for managing the emulation rules. In
step 204, the electronic system creates, modifies, or deletes one
or more emulation rules in response to the request. In working with
an emulation rule, the electronic system allows the user to specify
how emulation is performed with respect to time, location,
business, and other factors. In step 206, the electronic system
also combines or prioritizes multiple emulation rules in response
to the request. It allows the user to specify which Boolean
operators to use in combining emulation rules. It also allows the
user to assign weights to individual emulation rules. In another
example process, this step may be optional.
In step 208, the electronic system transmits existing emulation
rules associated with the payment card to the proxy card. When the
electronic system, such as the mobile phone that also belongs to
the user, is near the proxy card, the electronic system can
transmit the emulation rules directly using a short-range wireless
link, such as BLE, Bluetooth, Wi-Fi, NFC or RFID. When the
electronic system is not near the user, it can transmit the
emulation rules to an electronic device that is near the user using
a typical network interface and relies on that electronic device
for further transmission to the proxy card. The transmission can be
done based on a predetermined schedule, whenever emulation rules
are updated, and so on. The emulation rules associated with the
payment card may be transmitted by themselves or together with
additional emulation rules.
FIG. 3 is a flow diagram illustrating an example process performed
by a proxy card for selecting and emulating one of a plurality of
payment cards. The proxy card is used to emulate any of a group of
payment cards, each being, for example, a credit card, a debit
card, a gift card, an ATM card, a fleet card, etc. The proxy card
contains an identification element, such as a magnetic stripe, or
an IC chip (e.g., such as commonly used in a smartcard or in an
RFID tag), which may hold information corresponding to a payment
card. The proxy card also contains a communication element
supporting short-range wireless communication. In addition, it may
contain an input element, such as a button or a navigator key, and
an output element, such as a display, for various purposes.
In step 302, the proxy card selects one card of the group of
payment cards to emulate, based on an instruction from a user of
the proxy card. The proxy card can preselect a payment card
according to certain selection rules, but the user can manually
select a card using the input element on the proxy card. Once a
selection of a payment card is made, the proxy card needs to apply
the emulation rules associated with the selected payment card. An
emulation rule specifies how a payment card should be emulated with
respect to time, location, business or other factors. Therefore,
the proxy card identifies the current time, the current location,
and the business operating at the current location in order to
apply the emulation rules. In terms of time, in step 304, the proxy
card detects any use of the input element for signifying a start or
an end of emulation or any access of the identification component,
which can correspond to an end of emulation. In terms of location
and business, in step 306, the proxy card receives from a nearby
electronic device, such as a mobile phone or a POS system of a
store, data regarding the current location or the business
operating at the current location using a short-range wireless
link, such as BLE. Having identified the current time, the current
location, and the business operating at the current location, in
step 308, the proxy card applies the emulation rules associated
with the selected payment card to determine how to emulate the
selected payment card. Specifically, the proxy card configures the
identification element to correspond to the selected payment card
for a specific timeframe. Outside the timeframe, in step 310, the
proxy card performs no emulation by keeping the identification
element in a blank state that does not correspond to any payment
card. This measure provides a high level of security. An
alternative measure is for the proxy card to emulate a particular
card by default.
FIG. 4 is a high-level block diagram showing an example of a
processing device 400 that can represent any of the devices
described above, such as a proxy card, an electronic device, and a
server system. Any of these systems may include two or more
processing devices such as represented in FIG. 4, which may be
coupled to each other via a network or multiple networks.
In the illustrated embodiment, the processing system 400 includes
one or more processors 410, memory 411, a communication device 412,
and one or more input/output (I/O) devices 413, all coupled to each
other through an interconnect 414. In some embodiments, the
processing system 400 may not have any I/O devices 413. The
interconnect 414 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) 410 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) 410 control the
overall operation of the processing device 400. Memory 411 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), non-volatile memory such
as flash memory, miniature hard disk drive, or other suitable type
of storage device, or a combination of such devices. Memory 411 may
store data and instructions that configure the processor(s) 410 to
execute operations in accordance with the techniques described
above. The communication device 412 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. For an electronic sensing device of a merchant, or a proxy
card or mobile device of a consumer, the communication device 412
supports at least one technology for short-range wireless
communication. Depending on the specific nature and purpose of the
processing device 400, the I/O devices 413 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.
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.
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.
Software or firmware for use in implementing 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.
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.
* * * * *
References