U.S. patent application number 14/469560 was filed with the patent office on 2015-04-30 for securing payment transactions with rotating application transaction counters.
The applicant listed for this patent is GOOGLE INC.. Invention is credited to Ignacio Carlos Blanco, Jonathan Kingsley Blatter, Justin Lee Brickell, Harry Lee Butler, IV, Denis Lila, Bobby Wieler.
Application Number | 20150120556 14/469560 |
Document ID | / |
Family ID | 52117391 |
Filed Date | 2015-04-30 |
United States Patent
Application |
20150120556 |
Kind Code |
A1 |
Brickell; Justin Lee ; et
al. |
April 30, 2015 |
SECURING PAYMENT TRANSACTIONS WITH ROTATING APPLICATION TRANSACTION
COUNTERS
Abstract
An account management system creates a bundle of private
application transaction counters (ATCs) and a bundle of
corresponding public ATCs, and transmits them to a user device. The
device receives a request for payment information from a merchant
and processes the request without accessing a secure element
processor on the device. The device calculates a security code
using one of the bundle of private ATCs and a transaction number
received from the merchant. The device transmits proxy account
information, the calculated security code, and the corresponding
public ATCs to the merchant. The merchant transmits a payment
request to the account management system as the issuer of the proxy
account information. The account management system retrieves the
private ATC using the public ATC, and determines the validity of
the security code by recomputing it. The account management system
retrieves the financial account information and requests
authorization from the issuer.
Inventors: |
Brickell; Justin Lee; (San
Francisco, CA) ; Blatter; Jonathan Kingsley; (New
York, NY) ; Wieler; Bobby; (New York, NY) ;
Butler, IV; Harry Lee; (New York, NY) ; Blanco;
Ignacio Carlos; (San Francisco, CA) ; Lila;
Denis; (Oakland, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
GOOGLE INC. |
Mountain View |
CA |
US |
|
|
Family ID: |
52117391 |
Appl. No.: |
14/469560 |
Filed: |
August 26, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14133591 |
Dec 18, 2013 |
8930274 |
|
|
14469560 |
|
|
|
|
61897520 |
Oct 30, 2013 |
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06F 21/45 20130101;
G06Q 20/385 20130101; G06Q 20/3227 20130101; G06Q 20/326 20200501;
H04L 63/123 20130101; G06Q 20/40 20130101; G06Q 20/3278
20130101 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40; G06Q 20/38 20060101 G06Q020/38 |
Claims
1. A computer-implemented method to process financial transactions,
comprising: receiving, by a computing device associated with a
user, a request for payment information from a merchant computing
system to process a payment transaction, the request for payment
information comprising a request for payment account information
and a merchant computing m transaction code; processing, by the
computing device associated with the user, the request for payment
information without accessing a secure element of the computing
device associated with the user; generating, by the computing
device associated with the user without accessing the secure
element, a security code using the merchant computing system
transaction code and a private application transaction counter;
transmitting, by the computing device associated with the user and
to the merchant computing system, a response to the request for
payment information, wherein information in the response comprises
payment account information, a public application transaction
counter corresponding to the private application transaction
counter, and the generated security code, and wherein the
information is transmitted by the merchant computing system to an
account management system for payment approval in a payment
processing request; and receiving, by the computing device
associated with the user, a notification of an approved payment
transaction, the notification of the approved payment transaction
indicating that the account management system confirmed the
validity of the generated security code received in the payment
processing request from the merchant computing system.
2. The computer-implemented method of claim 1, wherein the public
application transaction counter expires after a pre-defined period
of time.
3. The computer-implemented method of claim 1, wherein the public
application transaction counter is valid for a single payment
transaction.
4. The computer-implemented method of claim 1, further comprising
receiving, by the computing device associated with the user, a
bundle of public application transaction counters and a bundle of
corresponding private application transaction counters from the
account management system.
5. The computer-implemented method of claim 4, wherein the bundle
of public application transaction counters comprises a set of
randomly generated values that are limited in time and number.
6. The computer-implemented method of claim 1, further comprising
receiving, by the computing device associated with the user, proxy
account information, wherein the payment account information
comprises the proxy account information.
7. The computer-implemented method of claim 1, wherein the security
code comprises a dynamic card verification number.
8. The computer-implemented method of claim 1, further comprising
determining, by the computing device associated with the user, that
the public application transaction counter and the corresponding
private application transaction counter are available and not
expired.
9. The computer-implemented method of claim 1, further comprising
confirming, by the account management system, the validity of the
public application transaction counter by determining that the
public application transaction counter is not expired and not
previously used.
10. The computer-implemented method of claim 1, wherein the account
management system uses the public application transaction counter
received in the payment processing request to retrieve the
corresponding private application transaction counter, and wherein
the retrieved private application transaction counter is used to
recompute the generated security code.
11. The computer-implemented method of claim 10, wherein the
account management system confirms the validity of the generated
security code by confirming the recomputed security code matches
the generated security code received in the payment processing
request.
12. A computer program product, comprising: a non-transitory
computer-readable medium having computer-readable program
instructions embodied thereon that when executed by a computer
cause the computer to process financial transactions, the
computer-readable program instructions comprising:
computer-readable program instructions for receiving a request for
payment information from a merchant computing system to process a
payment transaction, the request for payment information comprising
a request for payment account information and a merchant computing
m transaction code; computer-readable program instructions for
processing the request for payment information without accessing a
secure element of the computer; computer-readable program
instructions for generating a security code using the merchant
computing system transaction code and a private application
transaction counter; computer-readable program instructions for
transmitting to the merchant computing m a response to the request
for payment information, wherein information in the response
comprises payment account information, a public application
transaction counter corresponding to the private application
transaction counter, and the generated security code, wherein the
information is transmitted by the merchant computing system to an
account management system for payment approval in a payment
processing request; and computer-readable program instructions for
receiving a notification of an approved payment transaction, the
notification of the approved payment transaction indicating that
the account management system confirmed the validity of the
generated security code received in the payment processing request
from the merchant computing.
13. The computer program product of claim 12, further comprising
computer-readable program instructions for receiving a bundle of
public application transaction counters from the account management
system, wherein the bundle of public application transaction
counters comprises a set of randomly generated values that are
limited in time and number.
14. The computer program product of claim 12, wherein the account
management system uses the public application transaction counter
received in the payment processing request to retrieve the
corresponding private application transaction counter, and wherein
the retrieved corresponding private application transaction counter
is used to recompute the generated security code.
15. The computer program product of claim 14, wherein the account
management system confirms the validity of the generated security
code by confirming the recomputed security code matches the
generated security code received in the payment processing
request.
16. A system for processing financial transactions, comprising: a
user computing device, wherein the user computing device comprises
a storage device and a processor communicatively coupled to the
storage device, and wherein the processor executes application code
instructions that are stored in the storage device without
accessing a secure element to cause the system to: receive, from a
merchant computing m a request for payment information from a
merchant computing system to process a payment transaction, the
request for payment information comprising a request for payment
account information and a merchant computing m transaction code;
process the request for payment information without accessing the
secure element; generate a security code using the merchant
computing m transaction code and a private application transaction
counter; and transmit, to the merchant computing m a response to
the request for payment information, wherein information in the
response comprises the payment account information, the generated
security code, and a public application transaction counter
corresponding to the private application transaction counter; and
an account management computing system, wherein the account
management computing system comprises one or more processors
communicatively coupled to one or more storage devices, and wherein
the one or more processors execute application code instructions
that are stored in the one or more storage devices to cause the
system to: receive a payment processing request from the merchant
computing system, the payment processing request comprising the
payment account information, the public application transaction
counter, and the generated security code; confirm the validity of
the public application transaction counter; confirm the validity of
the generated security code; and transmit notification of an
approved payment transaction to the merchant computing system.
17. The system of claim 16, wherein the processor executes
application code instructions that are stored in the storage device
without accessing a secure element to cause the system receive a
bundle of public application transaction counters from the account
management system, wherein the bundle of public application
transaction counters comprises a set of randomly generated values
that are limited in time and number.
18. The system of claim 16, wherein account management computing
system uses the public application transaction counter received in
the payment processing request to retrieve the corresponding
private application transaction counter, and wherein the retrieved
corresponding private application transaction counter is used to
recompute the generated security code.
19. The system of claim 18, wherein the account management
computing system confirms the validity of the generated security
code by confirming the recomputed security code matches the
generated security code received in the payment processing
request.
20. The system of claim 16, wherein confirming that the validity of
the public application transaction counter comprises determining
that the public application transaction counter is not expired and
not previously used.
Description
RELATED APPLICATION
[0001] This patent application claims priority under 35 U.S.C.
.sctn.119 to U.S. Patent Application No. 61/897,520, filed Oct. 30,
2013 and entitled "Securing Payment Transactions With Rotating
Application Transaction Counters." The entire contents of the
above-identified application are hereby fully incorporated herein
by reference.
TECHNICAL FIELD
[0002] The present disclosure relates generally to a payment
system, and more particularly to methods and systems that allow the
secure processing of payment transactions without accessing a
secure element of a user device.
BACKGROUND
[0003] Current near field communication (NFC) systems rely on a
hardware component commonly referred to as a "secure element" or a
"secure memory" installed on communication devices to provide a
secure operating environment for financial transactions, transit
ticketing, identification and authentication, physical security
access, and other functions. A secure element generally includes
its own operating environment with a tamper-proof microprocessor,
memory, and operating system. An NFC controller receives a payment
request message from a merchant's point of sale (POS) system and
transmits the message to the secure element for processing. A
trusted service manager (TSM), or other form of secure service
provider, can, among other things, install, provision, and
personalize applications and data in the secure element. The secure
element has one or more access keys that are typically installed at
time of manufacture. A corresponding key is shared by the TSM so
that the TSM can establish a cryptographically secure channel to
the secure element for installation, provisioning, and
personalization of the secure element while the device having the
secure element is in the possession of an end user. In this way,
the secure element can remain secure even if the host CPU in the
device has been compromised.
[0004] One deficiency with current NFC systems is that a tight
coupling exists between the secure element and the TSM. For current
deployments, only one TSM has access to the keys of a particular
secure element. Therefore, the end user can choose to provision
secure element features that are supplied by the one TSM only. The
manufacturer of the device typically chooses this TSM. For example,
a smart phone manufacturer may select the TSM for smart phones
under guidance from a mobile network operator (MNO), such as Phone
Company A, that purchases the smart phone rather than the end user.
Thus, the TSM features available to the end user may not be in the
end user's interest. As an example, the MNO may have a business
relationship with only one payment provider, such as Bank X. That
TSM may allow the secure element to be provisioned with payment
instructions from the one payment provider only. Thus, the end user
would not be able to access services from other payment providers,
such as Bank Z.
SUMMARY
[0005] In certain example aspects described herein, a method for
processing payment transactions comprises limited use financial
account information and application transaction counters. An
account management system creates limited use financial account
information, a bundle of public application transaction counters,
and a corresponding bundle of private application transaction
counters, and transmits the information to a user device for use in
a payment transaction. The user device receives a request for
payment information from a merchant system and processes the
request without accessing a secure element processor on the user
device. The user device calculates a security code using the
private application counter and a transaction number received from
the merchant system. The user device transmits the limited use
financial account information, the calculated security code, and
one or the bundle of public application transaction counters to the
merchant system. The merchant system transmits a payment request to
the account management system as the issuer of the limited use
financial account information. The account management system
determines the validity of the public application transaction
counter and looks up the corresponding private application
transaction counter using the public application transaction
counter. The account management system determines the validity of
the security code by recomputing it using the private application
transaction counter and the transaction number received from the
merchant system. The account management system retrieves the user's
financial account information and requests authorization from the
issuer of the financial account for the payment transaction.
[0006] In certain other aspects described herein, a system and a
computer program product for processing payment transactions are
provided.
[0007] These and other aspects, objects, features, and advantages
of the example embodiments will become apparent to those having
ordinary skill in the art upon consideration of the following
detailed description of illustrated example embodiments.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1 is a block diagram depicting a payment processing
system, in accordance with certain example embodiments.
[0009] FIG. 2 is a block flow diagram depicting a method for
processing payment transactions using limited use financial account
information and application transaction counters, in accordance
with certain example embodiments.
[0010] FIG. 3 is a block flow diagram depicting a method for saving
limited use financial account information and application
transaction counters on a user device, in accordance with certain
example embodiments.
[0011] FIG. 4 is a block flow diagram depicting a method for
transmitting limited use financial account information, a
calculated dynamic card verification code, and a public application
transaction counter to a terminal reader, in accordance with
certain example embodiments.
[0012] FIG. 5 is a block flow diagram depicting a method for
providing new limited use application transaction counters to a
user device, in accordance with certain example embodiments.
[0013] FIG. 6 is a block flow diagram depicting a method for
approving payment transactions using limited use financial account
information, a public application transaction counter, and a
calculated dynamic card verification code, in accordance with
certain example embodiments.
[0014] FIG. 7 is a block diagram depicting a computer machine and
module, in accordance with certain example embodiments.
DETAILED DESCRIPTION OF THE EXAMPLE EMBODIMENTS
Overview
[0015] The example embodiments described herein provide methods and
systems that enable processing of a payment transaction without
accessing a secure element of a user device. In an example
embodiment, a user is conducting a wireless payment transaction
with a merchant system by transmitting payment information from the
user device to a terminal reader. The secure element resident on
the user device may be tightly coupled to a TSM at the time of
manufacturer, thereby preventing the user from providing payment
instructions for a payment account not provisioned on the secure
element. In an example embodiment, the user device comprises an
application and application transaction counters (ATCs) that permit
the secure processing of the payment transaction without accessing
the secure element.
[0016] A user registers with an application management system and
provides financial account information that will be maintained in a
user account with the account management system. The account
management system creates limited use proxy or virtual financial
account information that corresponds to the user's financial
account information provided to the system. The account management
system also creates a set of public and corresponding private ATCs.
In an example embodiment, the ATCs are limited in time and in
number of uses. For example, each public private ATC may be used
once, so once the bundle of ATCs transmitted to the user device are
used, the user device must request a new bundle before a new
transaction can be processed. The account management system
transmits the limited use financial account information and the
limited use ATCs to the user device.
[0017] When the user requests processing of a financial transaction
using the limited use financial account information, the merchant
system transmits a payment request and an unpredictable number or
code to the user device. The user device uses the unpredictable
number and one of the bundle of private ATCs, which is known only
to the user device and the account management system, to calculate
a security code. The security code, the limited use financial
account information, and the corresponding public ATC are
transmitted to the merchant system. The merchant system prepares
and transmits a request to the account management system for
processing the payment transaction using the limited use financial
account information. In an example embodiment, the request
comprises the limited use financial account information, the public
ATC, the calculated security code, and the unpredictable
number.
[0018] The account management system receives the payment request
and determines that the public ATC is from the available bundle of
private ATCs transmitted to the user device and that the public ATC
is not expired. The account management system then uses the public
ATC to look up and retrieve the private ATC. The account management
system uses the retrieved private ATC and the unpredictable number
to recomputed the security code. The account management system
compares the calculated security code received in the payment
request to the recomputed security code to determine the validity
of the code received in the payment request. After performing these
security checks, the account management system retrieves the user's
financial account information and requests payment processing from
the issuer of the account. The merchant system is notified of the
payment request approval or denial and the payment transaction is
completed.
[0019] The inventive functionality of the invention will be
explained in more detail in the following description, read in
conjunction with the figures illustrating the program flow.
Example System Architectures
[0020] Turning now to the drawings, in which like numerals indicate
like (but not necessarily identical) elements throughout the
figures, example embodiments are described in detail.
[0021] FIG. 1 is a block diagram depicting a payment processing
system, in accordance with certain example embodiments. As depicted
in FIG. 1, the exemplary operating environment 100 comprises a
merchant computing system 110, a user computing device 120, an
account management computing system 130, an acquirer computing
system 150, and an issuer computing system 160 that are configured
to communicate with one another via one or more networks 140. In
another example embodiment, two or more of these systems (including
systems 110, 120, 130, 150, and 160) are integrated into the same
system. In some embodiments, a user associated with a device must
install an application and/or make a feature selection to obtain
the benefits of the techniques described herein.
[0022] Each network 140 includes a wired or wireless
telecommunication means by which network systems (including systems
110, 120, 130, 150, and 160) can communicate and exchange data. For
example, each network 140 can be implemented as, or may be a part
of, a storage area network (SAN), personal area network (PAN), a
metropolitan area network (MAN), a local area network (LAN), a wide
area network (WAN), a wireless local area network (WLAN), a virtual
private network (VPN), an intranet, an Internet, a mobile telephone
network, a card network, Bluetooth, near field communication
network (NFC), any form of standardized radio frequency, or any
combination thereof, or any other appropriate architecture or
system that facilitates the communication of signals, data, and/or
messages (generally referred to as data). Throughout this
specification, it should be understood that the terms "data" and
"information" are used interchangeably herein to refer to text,
images, audio, video, or any other form of information that can
exist in a computer-based environment.
[0023] In an example embodiment, each network computing system
(including systems 110, 120, 130, 150, and 160) includes a device
having a communication module capable of transmitting and receiving
data over the network 140. For example, each network system
(including systems 110, 120, 130, 150, and 160) may comprise a
server, personal computer, mobile device (for example, notebook
computer, tablet computer, netbook computer, personal digital
assistant (PDA), video game device, GPS locator device, cellular
telephone, Smartphone, or other mobile device), a television with
one or more processors embedded therein and/or coupled thereto, or
other appropriate technology that includes or is coupled to a web
browser or other application for communicating via the network 140.
In the example embodiment depicted in FIG. 1, the network systems
(including systems 110, 120, 130, 150, and 160) are operated by
merchants, users, an account management system operator, an
acquirer, and an issuer, respectively.
[0024] The merchant system 110 comprises at least one point of sale
(POS) terminal 113 that is capable of processing a purchase
transaction initiated by a user, for example, a cash register. In
an example embodiment, the merchant operates a commercial store and
the user indicates a desire to make a purchase by presenting a form
of payment at the POS terminal 113. In another example embodiment,
the merchant operates an online store and the user indicates a
desire to make a purchase by clicking a link or "checkout" button
on a website. In another example embodiment, the user device 120 is
configured to perform the functions of the POS terminal 113. In
this example, the user scans and/or pays for the transaction via
the user device 120 without interacting with the POS terminal
113.
[0025] An example merchant system 110 comprises at least a terminal
reader 115 that is capable of communicating with the user device
system 120 and a merchant PUS terminal 113 via an application 117.
The application 117 may be an integrated part of the POS terminal
113, an integrated part of the terminal reader 115, or a standalone
hardware device (not shown), in accordance with some example
embodiments.
[0026] In an example embodiment, the terminal reader 115 is capable
of communicating with the user device 120 using an NFC
communication method. In another example embodiment, the terminal
reader 115 is capable of communicating with the user device 120
using a Bluetooth communication method. In yet another embodiment,
the terminal reader 115 is capable of communicating with the user
device 120 using a Wi-Fi communication method.
[0027] In an example embodiment, the merchant system 110 is capable
of communicating with the user device 120 via the terminal reader
115 and/or the application 117. In an example embodiment, the user
device 120 may be a personal computer, mobile device (for example,
notebook, computer, tablet computer, netbook computer, personal
digital assistant (PDA), video game device, GPS locator device,
cellular telephone, Smartphone or other mobile device), or other
appropriate technology that includes or is coupled to a web server,
or other suitable application. The user can use the user device 120
to process payment transactions via a user interface 121 and an
application 123. The application 123 is a program, function,
routine, applet or similar entity that exists on and performs its
operations on the user device 120. For example, the application 123
may be one or more of a shopping application, merchant system 110
application, an Internet browser, a digital wallet application, a
loyalty card application, another value-added application, a user
interface 121 application, or other suitable application operating
on the user device 120. In some embodiments, the user must install
an application 123 and/or make a feature selection on the user
device 120 to obtain the benefits of the techniques described
herein.
[0028] The user device 120 also comprises a controller 125. In an
example embodiment, the controller 125 is an NFC controller. In
some example embodiments, the controller 125 is a Bluetooth link
controller. The Bluetooth link controller may be capable of sending
and receiving data, performing authentication and ciphering
functions, and directing how the user device 120 will listen for
transmissions from the terminal reader 115 or configure the user
device 120 into various power-save modes according to the
Bluetooth-specified procedures. In another example embodiment, the
controller 125 is a Wi-Fi controller or an NFC controller capable
of performing similar functions.
[0029] The user device 120 communicates with the terminal reader
115 via an antenna 127. In an example embodiment, once a user
device application 123 has been activated and prioritized, the
controller 125 is notified of the state of readiness of the user
device 120 for a transaction. The controller 125 outputs through
the antenna 127 a radio signal, or listens for radio signals from
the terminal reader 115. On establishing a secure communication
channel between the user device 120 and the terminal reader 115,
the terminal reader 115 requests a payment processing response from
the user device 120. An example controller 125 receives a radio
wave communication signal from the terminal reader 115 transmitted
through the antenna 127. The controller 125 converts the signal to
readable bytes. In an example embodiment, the bytes comprise
digital information, such as a request for a payment processing
response or a request for payment card information. The controller
125 transmits the request to the application 123 for
processing.
[0030] An example user device 120 may comprise a secure element or
secure memory (not shown), which can exist within a removable smart
chip or a secure digital (SD) card or which can be embedded within
a fixed chip on the device 120. In certain example embodiments,
Subscriber Identity Module (SIM) cards may be capable of hosting a
secure element, for example, an NFC SIM Card. The secure element
(not shown) allows a software application resident on the user
device 120 and accessible by the device user to interact securely
with certain functions within the secure element, while protecting
information stored within the secure element (not shown). In an
example embodiment, the secure element (not shown) comprises
components typical of a smart card, such as crypto processors and
random generators. In an example embodiment, the secure element
(not shown) comprises a Smart MX type NFC controller in a highly
secure system on a chip controlled by a smart card operating
system, such as a JavaCard Open Platform (JCOP) operating system.
In another example embodiment, the secure element (not shown) is
configured to include a non-EMV type contactless smart card, as an
optional implementation. The secure element (not shown)
communicates with the application in the user device 120. In an
example embodiment, the secure element (not shown) is capable of
storing encrypted user information and only allowing trusted
applications to access the stored information. In an example
embodiment, a controller 125 interacts with a secure key encrypted
application for decryption and installation in the secure
element.
[0031] In an example user device 120, a payment request is
processed by the application 123, instead of by a secure element
(not shown). In an example embodiment, the user device 120
communicates payment account information to the merchant system 110
in the form of a proxy or virtual account identifier, without
transmitting the user's actual financial account information. The
user's actual account information is maintained by the account
management system 130 instead of within a secure element (not
shown) resident on the user device 120.
[0032] An example data storage unit 129 enables storage of user
payment account information and/or virtual account identifier for
the user's account management system 130 account. In an example
embodiment, the data storage unit 129 can include any local or
remote data storage structure accessible to the user device 120
suitable for storing information. In an example embodiment, the
data storage unit 129 stores encrypted information, such as HTML5
local storage.
[0033] An example user device 120 communicates an account
identifier to the merchant system 110 that identifies an account
maintained by the account management system 130. An example account
management system 130 comprises an account management module 131,
an application transaction module 135 and a data storage unit
137.
[0034] The account management system 130 enables the storage of one
or more financial or payment accounts for the user. In an example
embodiment, the user registers one or more payment accounts, for
example, credit card accounts, debit accounts, bank accounts, gift
card accounts, coupons, stored value accounts, loyalty accounts,
rewards accounts, and other forms of payment accounts capable of
making a purchase with the account management system 130. For
example, the user may create a digital wallet account with the
account management system 130. The payment accounts may be
associated with the user's digital wallet account maintained by the
account management system 130. The user may access the digital
wallet account at any time to add, change or remove payment
accounts. In an example embodiment, the user's digital wallet
information is transmitted to the user's user device 120, enabling
use of the user's payment account without accessing the account
management system 130. In some example embodiments, the account
management system 130 transmits limited-use proxy account
information to the user device 120 enabling use of the payment
accounts during a payment transaction routed to the account
management system 130 during the payment processing. For example,
the proxy account number may route the payment authorization
request to the account management system 130, acting as the issuer
system 160 for the proxy account. In another example embodiment,
the user device 120 may generate limited use proxy account numbers
that are enable the payment transaction to be routed to the account
management system 130. In some example embodiments, the application
123 performs this function.
[0035] An example account management system 130 comprises a data
storage unit 137 accessible by the account management system 130.
The example data storage unit 137 can include one or more tangible
computer-readable storage devices capable of storing a user's
payment account information. The user may request a purchase from
the merchant system 110. In an example embodiment, the purchase is
initiated by a wireless "tap" of the user device 120 with the
terminal reader 115. The merchant system 110 interacts with the
acquirer system 150 (for example Acquirer Payment System Q or other
third party payment processing companies) and the issuer system 160
(for example Bank X or other financial institutions to authorize
payment) to process the payment. In some example embodiments, the
payment card information transmitted by the user device 120 to the
terminal reader 115 is a proxy account or a token account that
links the payment transaction to a user account maintained by the
account management system 130. The payment transaction is routed to
the account management system 130 as the issuer system 160 for the
proxy account for identification of the user's correct payment card
information. In an example embodiment, the application transaction
module 135 receives the payment request from the merchant system
110 and interacts with the account management module 131 to
identify the user's account management system 130 account and
process a payment request to the issuer system 160 of the user's
financial account.
[0036] The components of the example operating environment 100 are
described hereinafter with reference to the example methods
illustrated in FIGS. 2-6. The example methods of FIG. 2-6 may also
be performed with other systems and in other environments.
Example System Processes
[0037] FIG. 2 is a block flow diagram depicting a method for
processing payment transactions using limited use financial account
information and application transaction counters, in accordance
with certain example embodiments. The method 200 is described with
reference to the components illustrated in FIG. 1.
[0038] In block 210, limited use financial account information and
application transaction counters (ATCs) are saved on a user device
120. The method for saving limited use financial account
information and application transaction counters on a user device
is described in more detail hereinafter with reference to the
methods described in FIG. 3.
[0039] FIG. 3 is a block flow diagram depicting a method 210 for
saving limited use financial account information and application
transaction counters on a user device, in accordance with certain
example embodiments, as referenced in block 210. The method 210 is
described with reference to the components illustrated in FIG.
1.
[0040] In block 310, a user installs, downloads, or otherwise
enables a payment processing, digital wallet, or other financial
transaction application 123 on the user device 120. In an example
embodiment, once the user enables the application 123 on the user
device 120, the user device becomes an "authorized" user device
120. In this embodiment, an authorized user device 120 is capable
of processing a payment transaction, communicating with an account
management system 130, and performing the features described
herein. In this embodiment, the user device 120 receives limited
use financial account information and ATCs to perform the methods
described herein. In an example embodiment, the user can enable the
application 123 on more than one user device 120. In this
embodiment, each user device 120 may possess the same or different
limited use financial account information and/or ATCs for use in
processing payment transaction.
[0041] In another example embodiment, the user can disable or
uninstall the application 123 at any time and on any number of
previously authorized user devices 120. In this embodiment, the
limited use financial account information and/or ATCs are removed
from the device or otherwise rendered disabled for processing
payment transactions.
[0042] In block 315, the account management system 130 receives
notification that the user has enabled the application on the user
device 120 and determines whether the user has an account
management system 130 account. In an example embodiment, the user
is prompted to provide account management system 130 account
identification information or log into the user's account
management system 130 account when the application 123 is enabled.
In another example embodiment, the user previously logged into the
account management system 130 account and is otherwise
automatically logged into the account. In yet another example
embodiment, the user's login credentials are shared across other
accounts (for example, social networking websites and user device
120 accounts) and the user is automatically logged into the account
management system 130 account using the shared login
credentials.
[0043] If the user does not have an account management system 130
account, the method 210 proceeds to block 230 and the user is
prompted to create an account management system 130 account. In an
example, the user is prompted to register with the account
management system 130 when the user enables the application 123. In
another example embodiment, the user is not required to log in or
register for the account management system 130 account. In this
embodiment, the methods described herein are performed for a
"guest" user.
[0044] In situations in which the technology discussed here
collects personal information about the user, or may make use of
personal information, the user may be provided with a opportunity
to control whether programs or features collect user information
(for example, information about the user's purchases, social
network, social actions or activities, profession, a user's
preferences, or a user's current location), or to control whether
and/or how to receive content from the user device 120 and/or
account management system 130 that may be more relevant to the
user. In addition, certain data may be treated in one or more ways
before it is stored or used, so that personally identifiable
information is removed. For example, a user's identity may be
treated so that no personally identifiable information can be
determined for the user, or a user's geographic location may be
generalized where location information is obtained (for example, to
a city, ZIP code, or state level), so that a particular location of
the user cannot be determined. Thus, the user may have control over
how information is collected about the user and used by the account
management system 130.
[0045] In an example embodiment, the user may create the account
management system 130 account at any time prior to or while
enabling the application 123. In an example embodiment, the user
accesses the account management system 130 via a website and the
network 140. In an example embodiment, the user submits
registration information to the account management system 130,
including, but not limited to, name, address, phone number, e-mail
address, and information for one or more registered financial card
accounts, including bank account debit cards, credit cards, a
loyalty rewards account card, or other type of account that can be
used to make a purchase (for example, card type, card number,
expiration date, security code, and billing address). In an example
embodiment, the user's account management system 130 account
information is saved in the data storage unit 137 and is accessible
to the account management module 131 and application transaction
module 135. In another example embodiment, the user is not required
to log into and/or maintain an account management system 130
account.
[0046] In an example embodiment, the account management system 130
account is a digital wallet account maintained by the account
management system 130 or a third party system. In another example
embodiment, the user may use a smart phone application 123 to
register with the account management system 130. In yet another
example embodiment, the user accesses the account management system
130 via a smart phone application 123.
[0047] From block 320, the method 210 proceeds to block 325 in FIG.
3.
[0048] Returning to block 315 in FIG. 3, if the user has an account
management system 130 account, the user logs into the account in
block 325. In an example embodiment, the user's account management
system 130 account information is saved in the user device 120 and
the user is automatically signed into the user's account management
system 130 account. In another example embodiment, the user is
automatically logged into the account management system 130 account
using shared login credentials. In yet another example embodiment,
the user was previously logged into the account management system
130 account and is not required to login.
[0049] The user enters financial account information (for example,
credit account, debit account, bank account, stored value account,
loyalty account, gift account, or other account capable of paying
for a purchase) on the user device 120. In an example embodiment,
the user accesses an application 123 on the user device 120 and
enters the financial account information. In an example embodiment,
the user enters the financial account number, expiration date, card
verification number, name of the account, name of the user, and any
additional information required to process a financial
transaction.
[0050] In block 330, the financial account information entered by
the user is saved in the user's account management system 130
account. In an example embodiment, the financial account
information saved in the user's account management system 130
account can be accessed, changed, updated, and/or deleted at any
time. In an example embodiment, the financial account information
is saved in the data storage unit 137.
[0051] In block 340, the account management system 130 creates
limited use financial account information that corresponds to the
saved financial account information. In an example embodiment, the
limited use financial account information is a proxy account
identifier or account management system identifier. In this
embodiment, the account management system 130 functions as the
issuer system 160 of the financial account information and receives
a payment request from a merchant system 110 when the limited use
financial account information is used in a payment transaction.
[0052] In an example embodiment, the account management system 130
creates a single set of limited use financial account information
that is linked to each of the one or more financial accounts saved
in the user's account. In another example embodiment, the account
management system 130 creates two or more sets of limited use
financial account information and the application 123 on the user
device 120 determines which set of limited financial account
information to provide to the merchant system 110 during the
payment transaction. In an example embodiment, the user selects a
default financial account to be used for processing payment
transactions. In an alternative example embodiment, the user
defines rules understandable by the account management system 130
and/or the application 123 for determining which financial account
is used to process financial transaction at various merchants.
[0053] In an example embodiment, the limited use financial account
information is valid for a limited duration. In this embodiment,
new limited use financial account information is created at
pre-defined intervals (for example, after 24 hours expires) or upon
a triggering event (for example, after 10 transactions are
processed).
[0054] In block 350, the account management system 130 creates and
logs a bundle of limited use private ATCs. In an example
embodiment, the account management system 130 creates a bundle or
set of private ATCs that are limited in duration (for example, they
expire after 24 hours) and/or number (for example, 10 ATCs are
created for 10 transactions). In an example embodiment, the private
ATCs are known only to the account management system 130 and the
user device 120. In this embodiment, the user device 120 uses the
private ATCs to calculate a security code or dynamic card
verification number (for example, a CVC3 checksum).
[0055] In an example embodiment, the private ATCs are randomly
chosen numbers or values that do not repeat until each possible
value in the set of possible numbers has been used. For example,
each private ATC may be a value between 0000 and 9999. In an
example embodiment, a set amount of private ATCs are valid during
any given interval. For example, 10 private ATCs may be value in
each 24-hour period, and each private ATC is valid for only 1
transaction. In an example embodiment, the private ATC values are
not incremental, but randomly chosen values. In another example
embodiment, a single private ATC value is created for each limited
use financial account number.
[0056] In block 360, the account management system creates and logs
a corresponding bundle of public ATCs. In an example embodiment,
each private ATC has a corresponding public ATC. In an example
embodiment, the account management system 130 creates a bundle or
set of public ATCs that are limited in duration (for example, they
expire after 24 hours) and/or number (for example, 10 ATCs are
created for 10 transactions). In an example embodiment, the public
ATCs are known to the account management system 130, the user
device 120, and the merchant system 110 during a payment
transaction. In this embodiment, the user device 120 transmits a
public ATC to the merchant system 110 with the limited use
financial account information.
[0057] In an example embodiment, the public ATCs are randomly
chosen numbers or values that do not repeat until each possible
value in the set of possible numbers has been used. For example,
each public ATC may be a value between 0000 and 9999. In an example
embodiment, a set amount of public ATCs are valid during any given
interval. For example, 10 public ATCs may be value in each 24-hour
period, and each public ATC is valid for only 1 transaction. In an
example embodiment, the public ATC values are not incremental, but
randomly chosen values.
[0058] In block 370, the account management system 130 transmits
the limited use financial account information, the bundle of public
ATCs, and the corresponding bundle of private ATCs to the user
device 120. In an example embodiment, the information is replicated
on each authorized user device 120. In another example embodiment,
a new set of information is created and transmitted to each
authorized user device 120. In an example embodiment, new
information is created at pre-defined intervals (for example, every
24 hours) and is created upon request by the user device 120. In
another example embodiment, new information is created after the
previous information has expired or is no longer available (for
example, after the maximum number of transaction has been reached
or each of ATCs has been used).
[0059] In block 380, the user device 120 receives the limited use
financial account information, the bundle of public ATCs, and the
corresponding bundle of private ATCs.
[0060] In block 390, the user device 120 saves the limited use
financial account information, the bundle of public ATCs, and the
corresponding bundle of private ATCs. In an example embodiment, the
information is saved in the data storage unit 129 and is accessible
by the application 123 for processing a payment transaction with
the merchant system 110.
[0061] The method 210 then proceeds to block 220 in FIG. 2.
[0062] Returning to FIG. 2, in block 220, the user indicates a
desire to complete a payment transaction with the merchant system
110 using the financial account information saved in the user's
account management system 130 account. In an example embodiment,
the user indicates the desire by using the limited use financial
account information for processing.
[0063] In an example embodiment, the user accesses the application
123 on the user device 120. In an example embodiment, the
application 123 is a merchant shopping application 123 or other
application/website that enables the user to perform an electronic
financial transaction. In another example embodiment, the user
accesses a payment processing application 123 that enables the user
to wirelessly transmit financial account information to the
terminal reader 115. In this embodiment, the financial account
information is transmitted via a secure communication channel (for
example, near field communications, Bluetooth, Wi-Fi, or other form
of wireless communication channel).
[0064] In an example embodiment, the user taps the user device 120
in the proximity of the terminal reader 115. In an example
embodiment, the terminal reader 115 generates a radio frequency
(RF) or other field polling for the presence of a user device 120,
and the user "taps" the user device 120 by placing the device 120
within the field of the terminal reader 115. In some example
embodiments, the merchant activates the RF field or other field to
poll for the presence of a user device 120 using an application 117
on the terminal reader 115.
[0065] In block 225, the user device 120 and the terminal reader
115 establish a secure communication channel. In an example
embodiment, the communication channel is an NFC communication
channel. In some example embodiments, the communication channel is
a Bluetooth communication channel. In yet another example
embodiment, the communication channel is a Wi-Fi communication
channel. Accordingly, the payment transaction can be conducted via
wireless or "contactless" communication between the user device 120
and the terminal reader 115.
[0066] In an example embodiment, the terminal reader 115 requests
protocols and characteristics from the user device 120 to establish
the communication channel. For example, the terminal reader 115 may
request the identification of communication protocols (for instance
ISO/IEC 14443, MIFARE, and/or ISO/IEC 18092), a list of
applications available, and security protocols from the user device
120.
[0067] In an example embodiment, the terminal reader 115 transmits
a signal requesting a payment processing response to the user
device 120. In an example embodiment, the response is a request to
proceed with a financial payment transaction. In an example
embodiment, the response indicates to the terminal reader 115 that
the user device 120 is capable of performing a financial
transaction. In an example embodiment, the response comprises the
same language and/or information as a payment processing response
generated by a conventional secure element or secure memory.
[0068] In block 230, the terminal reader 115 transmits a payment
request to the user device 120. In an example embodiment, the
payment request comprises an unpredictable number. In an example
embodiment, the unpredictable number is a randomly generated number
that will be used by the user device 120 to calculate a security
code or CVC3 number. In another example embodiment, the
unpredictable number comprises a transaction number or other number
known by the merchant system 110 and/or transmitted to the account
management system 130 in a request for payment authorization.
[0069] In an example embodiment, the application 117 resident on
the merchant system 110 generates the payment request. In an
example embodiment, the request is converted to a signal capable of
being transmitted to the user device 120 via the communication
channel and converted into bytes understandable by the application
123.
[0070] In block 240, the antenna 127 of the user device 120
receives the payment request. In an example embodiment, the payment
request is transmitted via the communication channel and during the
"tap" of the user device 120 with the terminal reader 115.
[0071] In an example embodiment, the antenna 127 transmits the
payment request to the controller 125. In an example embodiment,
the tap is an NFC tap and the controller 125 is an NFC
controller.
[0072] In block 250, the controller 125 receives the payment
request and transmits it to the application 123. In an example
embodiment, the controller 125 converts the signal received by the
antenna 127 into a readable payment request. In an example
embodiment, the signal is converted into bytes comprising the
readable request.
[0073] In an example embodiment, the controller 125 transmits the
payment request to the application 123. In an example embodiment,
the application 123 functions in a manner similar to a secure
element or a secure memory during the payment transaction by
retrieving stored payment information and providing it to the
terminal reader 115 for processing a payment transaction.
[0074] In block 260, the application 123 receives the payment
request. In an example embodiment, the request is transmitted
through a series of connections before being received by the
application 123. In some example embodiments, the request is
transmitted directly from the controller 125 to the application
123.
[0075] In block 270, the application 123 transmits the limited use
financial account information, a calculated CVC3, and a public ATC
to the terminal reader. The method for transmitting limited use
financial account information, a calculated CVC3, and a public
application transaction counter to a terminal reader is described
in more detail hereinafter with reference to the methods described
in FIG. 4.
[0076] FIG. 4 is a block flow diagram depicting a method 270 for
transmitting limited use financial account information, a
calculated dynamic card verification code, and a public application
transaction counter to a terminal reader, in accordance with
certain example embodiments, as referenced in block 270. The method
270 is described with reference to the components illustrated in
FIG. 1.
[0077] In block 410, the user device 120 determines if ATCs are
available for the payment transaction. In an example embodiment,
the user device 120 determines if the ATCs are expired (for
example, the ATCs are limited in duration and the duration has
expired). In another example embodiment, the user device 120
determines if an un-used ATC is available for the payment
transaction (for example, the ATCs are limited to 1 per
transaction, and the user has exceeded the number of transactions).
In an example embodiment, the user device 120 performs this check
for the public ATCs, the private ATCs, or both. In an example
embodiment, the application 123 makes the determination.
[0078] If the ATCs are unavailable (for example, they have all been
used), expired, or are otherwise unavailable, the method 270
proceeds to block 420.
[0079] In block 420, new limited use ATCs are provided to the user
device 120. The method for providing new limited use application
transaction counters to a user device 120 is described in more
detail hereinafter with reference to the methods described in FIG.
5.
[0080] FIG. 5 is a block flow diagram depicting a method 420 for
providing new limited use application transaction counters to a
user device, in accordance with certain example embodiments, as
referenced in block 420. The method 420 is described with reference
to the components illustrated in FIG. 1.
[0081] In block 510, the application 123 transmits a request to the
account management system 130 for new limited use ATCs. In an
example embodiment, the request comprises an account identifier,
such as the limited use financial account information or other
account identifier that enables the account management system 130
to identify the user's account. In an example embodiment, the user
is prompted to provide a password, personal identification number,
or other form of verification when requesting new limited use ATCs.
In another example embodiment, the account management system 130 is
notified automatically by the user device 120 when the ATCs expire,
are all used, or are otherwise not available and new ATCs are
provided to the user device 120 without user involvement.
[0082] In block 520, the account management system 130 receives the
request for new ATCs.
[0083] In block 530, the account management system 130 identifies
the user's account management system 130 account. In an example
embodiment, the account management system 130 uses the information
in the request for new ATCs to identify the user's account. In
another example embodiment, the account management system uses
information in the user's response to the request for verification
to identify the user's account.
[0084] In block 540, the account management system 130 creates and
logs a new bundle of limited use private ATCs. In an example
embodiment, the account management system 130 creates a new bundle
of private ATCs in a manner consistent with the methods described
previously in connection with block 350.
[0085] In block 550, the account management system 130 creates and
logs a new bundle of corresponding limited use public ATCs. In an
example embodiment, the account management system 130 creates a new
bundle of corresponding public ATCs in a manner consistent with the
methods described previously in connection with block 360.
[0086] In block 560, the account management system 130 transmits
the bundle of public ATCs, and the corresponding bundle of private
ATCs to the user device 120.
[0087] In block 570, the user device 120 receives the bundle of
public ATCs, and the corresponding bundle of private ATCs.
[0088] In block 580, the user device 120 saves the bundle of public
ATCs, and the corresponding bundle of private ATCs. In an example
embodiment, the bundle of public ATCs, and the corresponding bundle
of private ATCs are saved in the data storage unit 129.
[0089] The method 420 then proceeds to block 430 in FIG. 3.
[0090] Returning to block 410 in FIG. 4, if ATCs are available and
not expired, the method 270 proceeds to block 430 in FIG. 4.
[0091] In block 430, the application 123 retrieves one of the
bundle of private ATCs. In an example embodiment, each private ATC
has a corresponding public ATC. In another example embodiment, the
application 123 retrieves the private ATC that corresponds to the
next available public ATC.
[0092] In block 440, the application 123 calculates the dynamic
card verification checksum (CVC3) or other security code using the
private ATC. In an example embodiment, the application 123 uses the
unpredictable number or other code received from the merchant
system 110 in the payment request and the private ATC to calculate
the CVC3. In an example embodiment, the application 123 executes an
algorithm or other equation known to the account management system
130 to calculate the CVC3 using the private ATC and the
unpredictable number received from the merchant system 110.
[0093] In block 450, the application 123 retrieves the limited use
financial account information or other account identifier that
corresponds to the user's account management system 130
account.
[0094] In some example embodiments, the account management system
130 transmits one or more sets of limited use financial account
information to the user device 120. The application 123 generates
the payment account information by accessing the transmitted
limited use financial account information and selecting a
particular set of account information to use for the transaction.
In an example embodiment, the account management system 130 may
periodically generate limited use financial account information and
update the user's user device 120 with the current set of
information. In some example embodiments, the user's user device
120 can communicate a request for limited use financial account
information to the account management system 130, and the account
management system 130 can, in response, communicate the limited use
financial account information to the user's user device 120 for use
in the payment transaction. In yet another example embodiment, the
application 123 generates the limited use financial account
information locally. The application 123 can communicate the
generated limited use financial account information to the account
management system 130 for verification by the account management
system 130 when the account management system 130 receives the
payment request from the merchant system 110. In some example
embodiments, the application can generate the limited use financial
account information using a scheme that can be replicated by the
account management system 130 to allow the account management
system 130 to verify the generated limited use financial account
information when the account management system 130 receives the
payment request from the merchant system 110.
[0095] The limited use financial account information may have time
or geographic limitations. For example, the limited use financial
account information may only be valid for a limited amount of time
or it may only be valid in a specific geographic location. The
limited use financial account information can be stamped with, have
encoded therein, or otherwise contain a time reference, a time
duration, a geographic position of the user device 120, and/or a
geographic region based on a geographic position of the user device
120. These features can allow the limited use financial account
information to expire after a specified period of time or when used
outside of a specified geographic location. The limited use
financial account information may also have limitations on the
number of times they may be used. For example, each proxy account
number may only be valid for a single use.
[0096] In block 460, the application 123 retrieves the
corresponding public ATC from the bundle of public ATCs received
from the account management system 130. In an example embodiment,
the application 123 is capable of determining the corresponding
public ATCs. In an example embodiment, used and/or expired ATCs are
removed from the user device 120.
[0097] In block 470, the user device 120 transmits the limited use
financial account information, the calculated CVC3, and the public
ATC to the terminal reader 115. In an example embodiment, the
information is transmitted in response to the payment request. In
an example embodiment, the information is transmitted from the
application 123 to the controller 125, where it is converted into a
signal understandable by the terminal reader 115 and/or application
117. In an example embodiment, the information is transmitted
through the secure communication channel and during the "tap" of
the user device 120 with the terminal reader 115.
[0098] The method 270 then proceeds to block 280 in FIG. 2.
[0099] In block 280, the terminal reader 115 receives the limited
use financial account information, the calculated CVC3, and the
public ATC from the user device 120.
[0100] In block 290, the merchant system 110 processes the payment
transaction. The method for approving payment transactions using
limited use financial account information, a public application
transaction counter, and a calculated dynamic card verification
code, is described in more detail hereinafter with reference to the
methods described in FIG. 6.
[0101] FIG. 6 is a block flow diagram depicting a method 290 for
approving payment transactions using limited use financial account
information, a public application transaction counter, and a
calculated dynamic card verification code, as referenced in block
290. The method 290 is described with reference to the components
illustrated in FIG. 1.
[0102] In block 610, the terminal reader 115 transmits the limited
use financial account information, the CVC3, and the public ATC to
the POS terminal 113.
[0103] In block 615, the POS terminal 113 receives the limited use
financial account information, the CVC3, and the public ATC. In an
example embodiment, the application 117 converts the signal into a
language understandable by the merchant system 110. In an example
embodiment, the user may be prompted to enter a personal
identification number ("PIN") into the merchant system 110.
[0104] In block 620, the merchant system 110 generates a payment
request message to request payment using the payment account
information provided by the user device 120 and submits the payment
request to the acquirer system 150. In an example embodiment, the
merchant's POS terminal 113 submits the request to the acquirer
system 150 via a network 130. In an example embodiment, the payment
request message comprises the limited use financial account
information, the CVC3, the public ATC, and the unpredictable
number.
[0105] In block 625, the acquirer system 150 receives the payment
request.
[0106] In block 630, the acquire system 150 transmits the payment
request to the account management system 130. In an example
embodiment, the acquire system 150 and/or card network 140
automatically makes a determination that routes the limited use
financial account information to the account management system 130.
In an example embodiment, the determination is made using a series
of numbers or routing information in the limited use financial
account information. In some example embodiments, the acquire
system 150 and/or card network 140 reviews a list of saved account
identification information provided to the by the account
management system 140.
[0107] In block 635, the account management system 130 receives the
payment request comprising the limited use financial account
information, the CVC3, the public ATC, and the unpredictable
number.
[0108] In block 640, the account management system 130 identifies
the user account associated with the payment request. In an example
embodiment, account management system 130 comprises a list of the
limited use financial account information and the public ATC
generated for each user and can map this information to the user's
account. In some example embodiments, a one-way algorithm, such as
a hash function, can be used to identify or associate the user's
account with the limited use financial account information and/or
the public ATC. In yet another example embodiment, a hardware
security module (HSM) can be used to store secured data, such as a
list of the limited use financial account information and the
public ATCs generated for each user. The HSM can be contacted by
the account management system 130 over a secure network to map the
limited use financial account information and the public ATCs
generated for each user to the user's account.
[0109] In block 650, the account management system 130 determines
whether the public ATC is correct and not expired. In an example
embodiment, the account management system 130 determines whether
the public ATC is from the current bundle of unexpired ATCs. In
another example embodiment, the account management system 130
determines whether the public ATC is the next available public ATC
from the bundle of public ATCs transmitted to the user device 120.
In this embodiment, the pubic ATCs are used in a predefined
sequence known only to the account management system 130 and the
user device 120.
[0110] If the public ATC is not correct or is expired, the method
290 proceeds to block 655 and the transaction is declined.
[0111] Returning to block 650, if the public ATC is correct and not
expired, the method 290 proceeds to block 660. In block 660, the
account management system 130 determines whether the CVC3 or other
calculated security code is correct. In an example embodiment, the
payment request comprises the unpredictable number or other code
used by the user device 120 to calculate the CVC3. In this
embodiment, the account management system 130 uses the public ATC
to look up and retrieve the corresponding private ATC. Using the
retrieved private ATC and the unpredictable number, the account
management system 130 recalculates the CVC3. The account management
system 130 compares the CVC3 received in the payment request to the
CVC3 recomputed by the account management system 130 to determine
if the CVC3 number in the payment request is correct.
[0112] In another example embodiment, the account management system
130 uses the private ATC and the CVC3 number to reverse-compute the
unpredictable number. The account management system 130 compares
the calculated unpredictable number to the unpredictable number
from the payment request to determine if the CVC3 number is
correct.
[0113] If the CVC3 number is not correct, the method 290 proceeds
to block 655 and the transaction is declined.
[0114] Returning to block 660, if the CVC3 number is correct, the
method 290 proceeds to block 670. In block 670, the account
management system retrieves the saved financial account information
that corresponds to the limited use financial account information
received in the payment request. In an example embodiment, the
account management system 130 identifies the user's saved payment
account information. In an example embodiment, the user's account
contains the rules defined by the user (or the default rules if the
user has not modified the default rules). If the user has defined
payment rules, the account management system 130 applies the
user-defined rules first to determine the order to apply the
payment accounts to the transaction. In an example embodiment, the
account management system 130 applies the user-defined rules
first.
[0115] In block 680, the account management system 130 generates
and transmits a new payment request to the issuer system 160 of the
selected payment account via the card network 140. In some example
embodiments, the account management system 130 is the issuer system
160 of the payment account. In this embodiment, the account
management system 130 will determine whether sufficient funds are
available for the transaction and approve/deny the transaction
accordingly.
[0116] In an example embodiment, the issuer system 160 receives the
new payment request from the account management system 130 and
approves or declines the transaction.
[0117] In block 690, the account management system 130 deter mines
whether the new payment request was approved or declined. In an
example embodiment, the account management system 130 receives
notice of an approved or declined transaction from the issuer
system 150.
[0118] If the transaction is declined, the method proceeds to block
655 and the account management system 130 notifies the merchant
system 110 of the declined transaction.
[0119] Returning to block 690, if the transaction is approved, the
method proceeds to block 695. In an example embodiment, the issuer
system 160 transmits an authorization message to the account
management system 130, and the account management system 130
transmits an approval of the original payment request to the
merchant system 110 through the acquirer system 150. In an example
embodiment, the issuer system 160 debits the user's financial
account for the amount of the payment transaction and the account
management system 130 receives a credit or payment in the amount of
the payment transaction. The account management system 130 then
credits the merchant system 110 the amount of the payment
transaction.
Other Example Embodiments
[0120] FIG. 7 depicts a computing machine 2000 and a module 2050 in
accordance with certain example embodiments. The computing machine
2000 may correspond to any of the various computers, servers,
mobile devices, embedded systems, or computing systems presented
herein. The module 2050 may comprise one or more hardware or
software elements configured to facilitate the computing machine
2000 in performing the various methods and processing functions
presented herein. The computing machine 2000 may include various
internal or attached components such as a processor 2010, system
bus 2020, system memory 2030, storage media 2040, input/output
interface 2060, and a network interface 2070 for communicating with
a network 2080.
[0121] The computing machine 2000 may be implemented as a
conventional computer system, an embedded controller, a laptop, a
server, a mobile device, a smartphone, a set-top box, a kiosk, a
vehicular information system, one more processors associated with a
television, a customized machine, any other hardware platform, or
any combination or multiplicity thereof. The computing machine 2000
may be a distributed system configured to function using multiple
computing machines interconnected via a data network or bus
system.
[0122] The processor 2010 may be configured to execute code or
instructions to perform the operations and functionality described
herein, manage request flow and address mappings, and to perform
calculations and generate commands. The processor 2010 may be
configured to monitor and control the operation of the components
in the computing machine 2000. The processor 2010 may be a general
purpose processor, a processor core, a multiprocessor, a
reconfigurable processor, a microcontroller, a digital signal
processor (DSP), an application specific integrated circuit (ASIC),
a graphics processing unit (GPU), a field programmable gate array
(FPGA), a programmable logic device (PLD), a controller, a state
machine, gated logic, discrete hardware components, any other
processing unit, or any combination or multiplicity thereof. The
processor 2010 may be a single processing unit, multiple processing
units, a single processing core, multiple processing cores, special
purpose processing cores, co-processors, or any combination
thereof. According to certain embodiments, the processor 2010 along
with other components of the computing machine 2000 may be a
virtualized computing machine executing within one or more other
computing machines.
[0123] The system memory 2030 may include non-volatile memories
such as read-only memory (ROM), programmable read-only memory
(PROM), erasable programmable read-only memory (EPROM), flash
memory, or any other device capable of storing program instructions
or data with or without applied power. The system memory 2030 may
also include volatile memories such as random access memory (RAM),
static random access memory (SRAM), dynamic random access memory
(DRAM), and synchronous dynamic random access memory (SDRAM). Other
types of RAM also may be used to implement the system memory 2030.
The system memory 2030 may be implemented using a single memory
module or multiple memory modules. While the system memory 2030 is
depicted as being part of the computing machine 2000, one skilled
in the art will recognize that the system memory 2030 may be
separate from the computing machine 2000 without departing from the
scope of the subject technology. It should also be appreciated that
the system memory 2030 may include, or operate in conjunction with,
a non-volatile storage device such as the storage media 2040.
[0124] The storage media 2040 may include a hard disk, a floppy
disk, a compact disc read only memory (CD-ROM), a digital versatile
disc (DVD), a Blu-ray disc, a magnetic tape, a flash memory, other
non-volatile memory device, a solid state drive (SSD), any magnetic
storage device, any optical storage device, any electrical storage
device, any semiconductor storage device, any physical-based
storage device, any other data storage device, or any combination
or multiplicity thereof. The storage media 2040 may store one or
more operating systems, application programs and program modules
such as module 2050, data, or any other information. The storage
media 2040 may be part of, or connected to, the computing machine
2000. The storage media 2040 may also be part of one or more other
computing machines that are in communication with the computing
machine 2000 such as servers, database servers, cloud storage,
network attached storage, and so forth.
[0125] The module 2050 may comprise one or more hardware or
software elements configured to facilitate the computing machine
2000 with performing the various methods and processing functions
presented herein. The module 2050 may include one or more sequences
of instructions stored as software or firmware in association with
the system memory 2030, the storage media 2040, or both. The
storage media 2040 may therefore represent examples of machine or
computer readable media on which instructions or code may be stored
for execution by the processor 2010. Machine or computer readable
media may generally refer to any medium or media used to provide
instructions to the processor 2010. Such machine or computer
readable media associated with the module 2050 may comprise a
computer software product. It should be appreciated that a computer
software product comprising the module 2050 may also be associated
with one or more processes or methods for delivering the module
2050 to the computing machine 2000 via the network 2080, any
signal-bearing medium, or any other communication or delivery
technology. The module 2050 may also comprise hardware circuits or
information for configuring hardware circuits such as microcode or
configuration information for an FPGA or other PLD.
[0126] The input/output (I/O) interface 2060 may be configured to
couple to one or more external devices, to receive data from the
one or more external devices, and to send data to the one or more
external devices. Such external devices along with the various
internal devices may also be known as peripheral devices. The I/O
interface 2060 may include both electrical and physical connections
for operably coupling the various peripheral devices to the
computing machine 2000 or the processor 2010. The I/O interface
2060 may be configured to communicate data, addresses, and control
signals between the peripheral devices, the computing machine 2000,
or the processor 2010. The I/O interface 2060 may be configured to
implement any standard interface, such as small computer system
interface (SCSI), serial-attached SCSI (SAS), fiber channel,
peripheral component interconnect (PCI), PCI express (PCIe), serial
bus, parallel bus, advanced technology attached (ATA), serial ATA
(SATA), universal serial bus (USB), Thunderbolt, FireWire, various
video buses, and the like. The I/O interface 2060 may be configured
to implement only one interface or bus technology. Alternatively,
the I/O interface 2060 may be configured to implement multiple
interfaces or bus technologies. The I/O interface 2060 may be
configured as part of, all of, or to operate in conjunction with,
the system bus 2020. The I/O interface 2060 may include one or more
buffers for buffering transmissions between one or more external
devices, internal devices, the computing machine 2000, or the
processor 2010.
[0127] The I/O interface 2060 may couple the computing machine 2000
to various input devices including mice, touch-screens, scanners,
electronic digitizers, sensors, receivers, touchpads, trackballs,
cameras, microphones, keyboards, any other pointing devices, or any
combinations thereof. The I/O interface 2060 may couple the
computing machine 2000 to various output devices including video
displays, speakers, printers, projectors, tactile feedback devices,
automation control, robotic components, actuators, motors, fans,
solenoids, valves, pumps, transmitters, signal emitters, lights,
and so forth.
[0128] The computing machine 2000 may operate in a networked
environment using logical connections through the network interface
2070 to one or more other systems or computing machines across the
network 2080. The network 2080 may include wide area networks
(WAN), local area networks (LAN), intranets, the Internet, wireless
access networks, wired networks, mobile networks, telephone
networks, optical networks, or combinations thereof. The network
2080 may be packet switched, circuit switched, of any topology, and
may use any communication protocol. Communication links within the
network 2080 may involve various digital or an analog communication
media such as fiber optic cables, free-space optics, waveguides,
electrical conductors, wireless links, antennas, radio-frequency
communications, and so forth.
[0129] The processor 2010 may be connected to the other elements of
the computing machine 2000 or the various peripherals discussed
herein through the system bus 2020. It should be appreciated that
the system bus 2020 may be within the processor 2010, outside the
processor 2010, or both. According to some embodiments, any of the
processor 2010, the other elements of the computing machine 2000,
or the various peripherals discussed herein may be integrated into
a single device such as a system on chip (SOC), system on package
(SOP), or ASIC device.
[0130] In situations in which the systems discussed here collect
personal information about users, or may make use of personal
information, the users may be provided with an opportunity or
option to control whether programs or features collect user
information (e.g., information about a user's social network,
social actions or activities, profession, a user's preferences, or
a user's current location), or to control whether and/or how to
receive content from the content server that may be more relevant
to the user. In addition, certain data may be treated in one or
more ways before it is stored or used, so that personally
identifiable information is removed. For example, a user's identity
may be treated so that no personally identifiable information can
be determined for the user, or a user's geographic location may be
generalized where location information is obtained (such as to a
city, ZIP code, or state level), so that a particular location of a
user cannot be determined. Thus, the user may have control over how
information is collected about the user and used by a content
server.
[0131] Embodiments may comprise a computer program that embodies
the functions described and illustrated herein, wherein the
computer program is implemented in a computer system that comprises
instructions stored in a machine-readable medium and a processor
that executes the instructions. However, it should be apparent that
there could be many different ways of implementing embodiments in
computer programming, and the embodiments should not be construed
as limited to any one set of computer program instructions.
Further, a skilled programmer would be able to write such a
computer program to implement an embodiment of the disclosed
embodiments based on the appended flow charts and associated
description in the application text. Therefore, disclosure of a
particular set of program code instructions is not considered
necessary for an adequate understanding of how to make and use
embodiments. Further, those skilled in the art will appreciate that
one or more aspects of embodiments described herein may be
performed by hardware, software, or a combination thereof, as may
be embodied in one or more computing systems. Moreover, any
reference to an act being performed by a computer should not be
construed as being performed by a single computer as more than one
computer may perform the act.
[0132] The example embodiments described herein can be used with
computer hardware and software that perform the methods and
processing functions described herein. The systems, methods, and
procedures described herein can be embodied in a programmable
computer, computer-executable software, or digital circuitry. The
software can be stored on computer-readable media. For example,
computer-readable media can include a floppy disk, RAM, ROM, hard
disk, removable media, flash memory, memory stick, optical media,
magneto-optical media, CD-ROM, etc. Digital circuitry can include
integrated circuits, gate arrays, building block logic, field
programmable gate arrays (FPGA), etc.
[0133] The example systems, methods, and acts described in the
embodiments presented previously are illustrative, and, in
alternative embodiments, certain acts can be performed in a
different order, in parallel with one another, omitted entirely,
and/or combined between different example embodiments, and/or
certain additional acts can be performed, without departing from
the scope and spirit of various embodiments. Accordingly, such
alternative embodiments are included in the invention claimed
herein.
[0134] Although specific embodiments have been described above in
detail, the description is merely for purposes of illustration. It
should be appreciated, therefore, that many aspects described above
are not intended as required or essential elements unless
explicitly stated otherwise. Modifications of, and equivalent
components or acts corresponding to, the disclosed aspects of the
example embodiments, in addition to those described above, can be
made by a person of ordinary skill in the art, having the benefit
of the present disclosure, without departing from the spirit and
scope of embodiments defined in the following claims, the scope of
which is to be accorded the broadest interpretation so as to
encompass such modifications and equivalent structures.
* * * * *