U.S. patent application number 12/475718 was filed with the patent office on 2010-05-20 for methods and systems for secure mobile device initiated payments.
Invention is credited to Paul Smith, John R. Wankmueller.
Application Number | 20100125516 12/475718 |
Document ID | / |
Family ID | 42172733 |
Filed Date | 2010-05-20 |
United States Patent
Application |
20100125516 |
Kind Code |
A1 |
Wankmueller; John R. ; et
al. |
May 20, 2010 |
METHODS AND SYSTEMS FOR SECURE MOBILE DEVICE INITIATED PAYMENTS
Abstract
Systems, methods, processes, computer program code and means for
conducting a transaction include receiving a request to authorize a
purchase transaction, the request including a static virtual
payment account number ("VPAN"), an expiry date, and a dynamic code
generated by a mobile device, the request further including a
transaction amount and a transaction date, identifying, based on
the static VPAN, a payment card account number, verifying that the
dynamic code matches an expected value of the dynamic code, and
transmitting an updated authorization request message to an issuer
associated with the payment card account number for authorization
analysis.
Inventors: |
Wankmueller; John R.; (Great
Neck, NY) ; Smith; Paul; (Edinburgh, GB) |
Correspondence
Address: |
BUCKLEY, MASCHOFF & TALWALKAR LLC
50 LOCUST AVENUE
NEW CANAAN
CT
06840
US
|
Family ID: |
42172733 |
Appl. No.: |
12/475718 |
Filed: |
June 1, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61114593 |
Nov 14, 2008 |
|
|
|
Current U.S.
Class: |
705/35 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 20/326 20200501; G06Q 20/204 20130101; G06Q 20/3274 20130101;
G06Q 20/32 20130101; G06Q 20/20 20130101 |
Class at
Publication: |
705/35 |
International
Class: |
G06Q 20/00 20060101
G06Q020/00 |
Claims
1. A method for conducting a transaction, comprising: receiving a
request to authorize a purchase transaction involving a purchase
from a merchant, said request including a static virtual payment
account number (VPAN), an expiry date, and a dynamic code generated
by a mobile device, said request further including a transaction
amount and a transaction date; identifying, based on said static
VPAN, a payment card account number; verifying that said dynamic
code matches an expected value of said dynamic code; and
transmitting an updated authorization request message to an issuer
for authorization processing based on said payment card account
number.
2. The method of claim 1, further comprising: receiving an
authorization response message from said issuer; and forwarding an
updated authorization response message to said merchant, said
updated authorization response message including said static
VPAN.
3. The method of claim 1, wherein verifying that said dynamic code
matches an expected value comprises: generating at least a first
expected value based on a transaction counter value and a shared
secret key.
4. The method of claim 1, wherein said dynamic code is selected
from among a pre-populated list of dynamic codes based on a value
of a transaction counter.
5. The method of claim 1, wherein verifying that said dynamic code
matches an expected value comprises: generating a series of
expected values based on a series of expected transaction counter
values and a shared secret key.
6. A payment provider apparatus, comprising: a processor; a
communication device coupled to said processor and adapted to
communicate with at least one of an issuer, and a merchant device
over a processing network; a storage device in communication with
said processor and storing instructions adapted to be executed by
said processor to: receive, from said merchant device, a request to
authorize a purchase transaction involving a purchase, said request
including a static virtual payment account number (VPAN), an expiry
date, and a dynamic code generated by a mobile device, said request
further including a transaction amount and a transaction date;
identify, based on said static VPAN, a payment card account number;
verify that said dynamic code matches an expected value of said
dynamic code; and transmit an updated authorization request message
to said issuer for authorization processing based on said payment
card account number.
7. The apparatus of claim 6, wherein said storage device further
storing instructions adapted to be executed by said processor to:
receive, from said issuer, an authorization response message; and
forward, to said merchant device, an updated authorization response
message, said updated authorization response message including said
static VPAN.
8. The apparatus of claim 6, wherein said instructions to verify
that said dynamic code matches an expected value further comprises
instructions adapted to be executed by said processor to: generate
at least a first expected value based on a transaction counter
value and a shared secret key.
9. The apparatus of claim 6, wherein the dynamic code generated by
said mobile device is generated by selecting a dynamic code from
among a list of available dynamic codes, said selection based on
the value of a transaction counter in said mobile device.
10. The apparatus of claim 6, wherein said instructions to verify
that said dynamic code matches an expected value further comprises
instructions adapted to be executed by said processor to: generate
a series of expected values based on a series of expected
transaction counter values and a shared secret key.
11. The apparatus of claim 6, wherein said storage device stores at
least a database containing said static VPAN.
12. The apparatus of claim 11, wherein said database further stores
at least one of (i) a physical PAN, (ii) a counter, (iii) and an
expiration date of said VPAN.
13. A computer-readable medium storing instructions adapted to be
executed by a processor to perform a method of processing payment
transactions, said method comprising: receiving a request to
authorize a purchase transaction involving a purchase from a
merchant, said request including a static virtual payment account
number (VPAN), an expiry date, and a dynamic code generated by a
mobile device, said request further including a transaction amount
and a transaction date; identifying, based on said static VPAN, a
payment card account number; verifying that said dynamic code
matches an expected value of said dynamic code; and transmitting an
updated authorization request message to an issuer for
authorization processing based on said payment card account
number.
14. The computer-readable medium of claim 13, wherein the method of
processing payment transactions further comprising: receiving, from
said issuer, an authorization response message; and forwarding, to
said merchant device, an updated authorization response message,
said updated authorization response message including said static
VPAN.
15. The computer-readable medium of claim 13, wherein said
verifying that said dynamic code matches an expected value further
comprises: generating at least a first expected value based on a
transaction counter value and a shared secret key.
16. The computer-readable medium of claim 13, wherein the dynamic
code generated by said mobile device is generated by selecting a
dynamic code from among a list of available dynamic codes, said
selection based on the value of a transaction counter in said
mobile device.
17. The computer-readable medium of claim 13, wherein said
verifying that said dynamic code matches an expected value further
comprises: generating a series of expected values based on a series
of expected transaction counter values and a shared secret key.
18. The computer-readable medium of claim 13, wherein said storage
device stores at least a database containing said static VPAN.
19. The computer-readable medium of claim 18, wherein said database
further stores at least one of (i) a physical PAN, (ii) a counter,
(iii) and an expiration date of said VPAN.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit of and priority to U.S.
Provisional Patent Application Ser. No. 61/114,593, filed Nov. 14,
2008, which is incorporated herein by reference for all
purposes.
[0002] Mobile telephones and other mobile communications devices
(such as personal digital assistants) are carried by millions of
consumers. There have been a number of attempts to integrate
payment applications with these mobile devices. Some of these
attempts require substantial changes to either existing payment
authorization systems and existing point of transaction devices (or
both), making it difficult to achieve widespread adoption of mobile
payments. It would be desirable to provide a mobile payment system
which uses existing point of transaction devices and existing
payment authorization systems. It would further be desirable to
provide mobile payment transactions which are secure and in which
the cardholder's presence may be confirmed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] FIG. 1 is a block diagram depicting a payment system
configured pursuant to some embodiments.
[0004] FIG. 2 is a flow diagram depicting a cardholder registration
process pursuant to some embodiments.
[0005] FIG. 3 is a flow diagram depicting a transaction process
pursuant to some embodiments.
[0006] FIG. 4 is a block diagram depicting a payment provider
device configured pursuant to some embodiments.
[0007] FIG. 5 is a tabular view of a portion of a VPAN database in
accordance with some embodiments of the present invention.
DESCRIPTION
[0008] Embodiments of the present invention relate to systems,
methods, processes, computer program code, and means for using
mobile devices to conduct payment transactions over a network. In
some embodiments, the mobile device can be used to conduct payment
transactions involving credit, debit, stored value or other payment
accounts. Pursuant to some embodiments, systems, methods,
processes, computer program code and means for conducting a
transaction include receiving a request to authorize a purchase
transaction, the request including a static virtual payment account
number ("VPAN"), an expiry date, and a dynamic code generated by a
mobile device, the request further including a transaction amount
and a transaction date, identifying, based on the static VPAN, a
payment card account number, verifying that the dynamic code
matches an expected value of the dynamic code, and transmitting an
updated authorization request message to an issuer associated with
the payment card account number for authorization analysis. In some
embodiments, an authorization response message is received from the
issuer, and an updated authorization response message is forwarded
to a merchant, the updated authorization response message including
the static VPAN.
[0009] For clarity and ease of exposition, a number of terms are
used herein. For example, the term "cardholder" is used to refer to
an individual who has been issued a payment account that may be
used to conduct payment transactions. For example, in some
embodiments, the payment account may be a debit or credit account
which is accessible by a debit card or a credit card (or other
device). As used herein, the term "issuer" is used to refer to a
financial institution that has issued a payment account to a
cardholders For example, an issuer may be a bank that issues a
credit card account to a cardholder, and provides the cardholder
with a credit card to access the account.
[0010] As used herein, the term "primary account number" (or "PAN")
is used to refer to a number of digits (or characters) which
identity a payment account issued by an issuer. For example, in
embodiments where a payment account is a credit card account which
is issued by a financial institution pursuant to the MasterCard
International Incorporated rules, the PAN may be a sixteen-digit
string that identifies both the issuer (based on the first 5 digits
of the string) and the payment account number at the issuer. The
PAN is used to route and process transactions that involve the
payment card and the payment account. Those skilled in the art will
appreciate that other primary account number schemes and formats
may be used in conjunction with embodiments of the present
invention.
[0011] As used herein, the term "payment network" is used to refer
to one or more networks that are used to process a payment
transaction. For example, a payment network may be the BankNet.RTM.
processing network operated by MasterCard International
Incorporated. Those skilled in the art will appreciate that other
networks may also be used to facilitate the authorization, clearing
and settlement of payment transactions conducted using the present
invention.
[0012] The term "mobile device" is used to refer to a handheld or
portable device carried or used by a cardholder. In the context of
embodiments of the present invention, a "mobile device" is a device
that has a payment application stored, loaded or otherwise
installed in or on the device such that the cardholder may conduct
payment transactions involving a payment account pursuant to
embodiments of the present invention. Other terms will be
introduced throughout the specification to illustrate features of
some embodiments.
[0013] Pursuant to some embodiments, mobile devices (such as mobile
telephones) are provided with (or updated to include) a payment
application which stores at least one static virtual payment
account number (or "VPAN"). The VPAN account has its own virtual
expiry date. An authorized user of the payment application may
access the VPAN and use it to make a purchase transaction (e.g., at
a physical merchant location or an electronic commerce location).
The authorized user provides the VPAN, along with its expiry date,
and a dynamic code (generated by the payment application) to the
merchant and the merchant routes the VPAN, expiry date, dynamic
code, and other transaction information to a payment provider
(e.g., using existing payment authorization systems).
[0014] The payment provider uses the VPAN to look-up an actual PAN
associated with a payment account of the customer, and confirms the
validity of the dynamic code. A second authorization request
message is then created with the actual PAN and the transaction
information. The second authorization request is routed to the
issuer of the customer's payment account for authorization. If the
transaction is authorized, the authorization response is returned
to the payment provider. The payment provider replaces the actual
PAN with the VPAN and returns the authorization response to the
merchant so that the transaction can be completed.
[0015] Features of some embodiments of the present invention will
be described by reference to FIG. 1, which is a block diagram of a
system 100 pursuant to some embodiments. As shown, a payment
account holder or customer (hereafter, the "customer") may have or
use a mobile device 102 (such as a mobile telephone or the like).
The mobile device 102 has a display screen 104 and a data entry
device 106 (such as a keypad or touch screen). Pursuant to
embodiments of the present invention, the customer may use the
mobile device 102 to conduct a purchase transaction with a merchant
108. The merchant 108 may be a physical storefront or electronic
commerce merchant.
[0016] In a typical example transaction, a customer may purchase
products or services from the merchant 108 by interacting with a
payment application (installed in or on the mobile device 102) to
cause the generation of a static VPAN on the mobile device 102. In
some embodiments, the payment application also generates an
expiration date associated with the static VPAN. In some
embodiments, the payment application also generates a dynamic
account validation code. In some embodiments, the dynamic account
validation code has the same format as existing dynamic card
validation codes found on physical payment cards. The VPAN, the
expiration date, and the dynamic account validation code are
provided to a clerk operating a point of sale terminal, who keys in
the information as if it were being copied from a normal payment
card.
[0017] In some embodiments, such as embodiments operable in
electronic commerce environments, the customer may cause the
payment application in the mobile device to display a VPAN,
expiration date and dynamic account validation code on a display
device of the mobile device 102. The customer may read the
information from the display device and then key in that data into
a Web page on a computer to complete the ecommerce transaction. In
some embodiments, such as embodiments involving telephone
transactions, the customer may read the information from the
display device of the mobile device 102 and orally convey the
information to a call center operator or key the information in
through a telephone keypad. In FIG. 1, the communication or
provision of this VPAN to the merchant (whether it be at a physical
point of sale, in an ecommerce transaction, or in a telephone
transaction) is shown as transaction message number "1".
[0018] In addition to generating (or providing) the VPAN, the
payment application on the mobile device 102, in one preferred
embodiment, prompts the user for a password to open up, launch, or
otherwise access the payment application on the mobile device. This
provides evidence that the account holder of the VPAN was present
during the transaction. If the user's password is verified, the
payment application on the mobile device operates to generate (or
otherwise provide) an expiry date and a multi digit dynamic number
(hereinafter a "dynamic code"). In some embodiments, the dynamic
code is a three or four digit code that may be used in place of a
"CVV" or "CVC" code (a code generally used in payment card systems
and used to verify that a cardholder was in possession of a payment
card during a transaction).
[0019] In some embodiments, the dynamic code is generated in the
payment application of the mobile device 102 based on a secret key
stored in the payment application (e.g., by an issuer of a payment
account held by the cardholder) when the payment application and
the VPAN are loaded into the mobile device 102. The dynamic code
is, in some embodiments, generated based on the secret key and the
value of a transaction counter. For example, each payment
application may have a transaction counter that increments each
time the payment application is used to conduct a transaction using
a VPAN. Once the payment application has retrieved or generated the
VPAN, the expiry date, and the dynamic code for the transaction,
the data elements are displayed on a display device 104 of the
mobile device 102 and the customer provides the data elements to
the merchant 108.
[0020] In some embodiments, the dynamic code is not generated in
the payment application of the mobile device 102 but is taken from
a pre-populated list of dynamic codes stored in the payment
application (e.g., by an issuer of a payment account held by the
cardholder) when the payment application and the VPAN are loaded
into the mobile device 102.
[0021] The merchant 108 enters the data elements (including the
VPAN, the expiry date and the dynamic code) into a point of
transaction terminal (e.g., such as a POS terminal) and causes the
creation of an authorization request message in the format required
by the payment networks used by the merchant systems. The
authorization request message is transmitted (at message "2" in
FIG. 1) from the merchant 108 to a payment provider 110. The
authorization request message may include, for example, the VPAN,
the expiry date, and the dynamic code generated by the mobile
device 102 as well as the transaction details associated with the
current purchase transaction.
[0022] The authorization request message is transmitted through a
network 120 (such as a payment association network, e.g., the
BankNet.RTM. network operated by MasterCard International
Incorporated). Pursuant to some embodiments, the authorization
request message is routed to a payment provider 110 such as a
server device or system operated to manage and administer
transactions involving embodiments of the present invention. In
some embodiments, the authorization request message is routed
through the network 120 based on data in the VPAN. For example,
each VPAN may have a four or five leading digits which serve to
identify the payment provider 110 as the "issuer" of the VPAN.
Those skilled in the art will appreciate that an authorization
request involving a payment card is typically transmitted to the
payment card issuer for authorization. In embodiments of the
present invention, authorization requests involving VPANs are
routed, instead, to a payment provider 110.
[0023] The payment provider 110, upon receiving the authorization
request, uses the VPAN in the authorization request to look-up a
data record (such as the data record illustrated as 150) which
includes details associated with the VPAN, including, for example,
information from an associated physical payment card with the
physical payment card's expiry date and physical card's static card
verification code and a value (or range of values) identifying an
expected counter value. The expected counter value may be used to
confirm the likely validity of the dynamic value generated by the
mobile device 102. An example of a database that could store a data
record 150 is shown and discussed below at FIG. 5.
[0024] Because the payment provider 110 may not know the exact
value of the counter in each mobile device 102, the payment
provider 110 may generate a series of expected dynamic values based
on the general range of counter values the payment provider expects
from a particular mobile device. For example, if a mobile device
102 has engaged in 10 prior transactions using VPANs, the payment
provider 110 may generate a range of expected dynamic values using
ten counter values from 10 and 20. The resulting ten expected
dynamic values are then compared to the received dynamic value. If
the dynamic value received from the mobile device 102 is equal to
one of the ten expected dynamic values, the transaction may
continue. If the dynamic value received from the mobile device 102
is not equal to one of the ten expected dynamic values, then the
transaction may be declined (e.g., by returning a denial response
in message "5").
[0025] If the dynamic value received from the mobile device 102 is
equal to one of the expected dynamic values, the payment provider
110 continues processing the transaction by creating an updated
authorization request in which the VPAN is replaced with the PAN of
the payment card registered for that VPAN by the customer plus the
expiry date of the real physical card. In some embodiments, a CVC
or other static values associated with the customer's physical
payment card is also included in the updated authorization request.
The updated authorization request is then routed, via the network
120, to the issuer of the customer's physical payment card. The
issuer 112, upon receipt of the updated authorization request,
performs normal authorization processing to determine if the
payment transaction can be authorized. An authorization response is
then returned to the payment provider (e.g., at message "4").
[0026] The payment provider then creates an updated authorization
response message by replacing the PAN of the customer's physical
payment card with the VPAN previously received. The updated
authorization response is then returned to the merchant 108 to
complete the transaction. In this manner, mobile devices (and their
processing power) may be used to generate and simply display, to
the merchant clerk (for face to face transactions) or to the
customer (for ecommerce transactions) the three primary pieces of
payment data (a PAN, an expiry date, and a card verification code
that is the same format as normal) that are used in existing
payment card networks and to initiate key entered payment
transactions involving payment cards. An important aspect of some
embodiments of the present invention is that the keyed in card
verification code is dynamic and is checked by payment provider
110, not by issuer 112 of the physical card. In this manner,
payment card issuers are not required to deploy or implement new
processes to validate or support the dynamic card codes, nor are
they required to implement new systems to track or generate VPANs.
Further, embodiments ensure that merchants are not made aware of
the actual payment card information, as they are only exposed to
the VPAN information.
[0027] Pursuant to some embodiments, prior to conducting a
transaction using a VPAN, a cardholder must first register a
payment card with the payment provider 110, and install (or
activate) a payment application on a mobile device. One process for
registration and activation is shown in FIG. 2, where a process 200
is shown. Process 200 may be performed by a cardholder to activate
a payment application on a mobile device (or to install and
activate a payment application onto a mobile device) and to
register a payment card with payment provider 110. Process 200
begins at 202 where the cardholder contacts the payment provider
110 (or an agent of the payment provider). The cardholder may
contact the payment provider 110 from a mobile device that has (or
will have) the payment application installed thereon, or the
cardholder may contact the payment provider 110 from a computer
over the Internet or the like.
[0028] Once the cardholder contacts the payment provider,
processing continues at 204 where the cardholder is walked through
a menu of options to create a mobile transaction account. For
example, the cardholder may be prompted for personal information to
verify the cardholder's identity, and may be prompted for
information needed to create the mobile transaction account.
[0029] Processing continues at 206 where the cardholder is prompted
to identify one or more payment card accounts to be associated with
the mobile transaction account. The payment card account(s) will be
used to complete transactions processing using the system.
[0030] Processing continues at 208 where the payment provider 110
creates a VPAN and a VPAN record (e.g., such as shown in item 150
of FIG. 1) and delivers the VPAN to the cardholder's mobile device.
In some embodiments, the mobile phone application with the VPAN and
other data is transmitted to the cardholder's mobile device using
over the air ("OTA") techniques. In some embodiments, the VPAN is
packaged in a payment application and delivered and installed on
the cardholder's mobile device. Processing at 208 may also include
the generation and delivery of a shared secret key for use by the
payment application in generating a dynamic code value as described
above. Once the VPAN and payment application have been installed on
the mobile device, the cardholder may use the mobile device to
complete transactions pursuant to the present invention.
[0031] Reference is now made to FIG. 3, where a process 300 for
conducting a mobile transaction pursuant to some embodiments is
described. Process 300 may be performed by a payment processor such
as the payment processor 110 of FIG. 1. For example, process 300
may be performed in response to authorization requests received by
the payment processor 110 involving transactions at merchants where
a VPAN was provided by a cardholder.
[0032] Processing begins at 302 where an authorization request
involving a VPAN is received. At 304, an initial determination may
be made whether the transaction date is prior to the expiry date of
the VPAN. If not, processing may continue at 316 where an
authorization denial may be created. If the transaction date is
prior to the expiry date, processing continues at 306 where a
mapping or look-up is performed (using the VPAN) to retrieve data
associated with the VPAN (e.g., such as the data shown as item 150
of FIG. 1). Processing continues at 308 where a series of expected
dynamic verification numbers are computed. At 310, a determination
is made whether the dynamic code received in the authorization
request is within the series of computed (or expected) codes. If
not, the transaction may be denied and processing may continue at
316 where an authorization response denying the transaction is
generated. If the determination at 310 indicates that the dynamic
code received in the authorization request is within the series of
computed (or expected) codes, processing continues at 312 where an
updated authorization request is created using the transaction data
(received at 302) and the payment card information retrieved at
306. The updated authorization request is transmitted to the issuer
and a response is received and returned to the merchant at 314.
[0033] FIG. 4 illustrates payment provider device 400 that might be
descriptive, for example, of the payment provider device 110
illustrated in FIG. 1 in accordance with an exemplary embodiment of
the invention. The payment provider device 400 comprises a
processor 410, such as one or more INTEL.RTM. Pentium.RTM.
processors, coupled to a communication device 420 configured to
communicate via a communication network (not shown in FIG. 4). The
communication device 420 may be used to communicate, for example,
with one or more merchants, acquirers, issuers, and
cardholders.
[0034] The processor 410 is also in communication with an input
device 440. The input device 440 may comprise, for example, a
keyboard, a mouse, or computer media reader. Such an input device
440 may be used, for example, to enter information about
cardholders participating in the system or to perform
administrative actions associated with the management and
administration of the payment provider device 400. The processor
410 is also in communication with an output device 450. The output
device 450 may comprise, for example, a display screen or printer.
Such an output device 450 may be used, for example, to provide
reports and/or display information associate with cardholder
registrations and the usage or administration of cardholder
data.
[0035] The processor 410 is also in communication with a storage
device 430. The storage device 430 may comprise any appropriate
information storage device, including combinations of magnetic
storage devices (e.g., magnetic tape and hard disk drives), optical
storage devices, and/or semiconductor memory devices such as Random
Access Memory (RAM) devices and Read Only Memory (ROM) devices.
[0036] The storage device 430 stores a program 415 for controlling
the processor 410. The processor 410 performs instructions of the
program 415, and thereby operates in accordance any embodiments of
the present invention described herein. For example, the processor
410 may receive, via the communication device 420, a request from a
cardholder to register a payment card and to activate a payment
application on a mobile device (e.g., such as a registration
request in accordance with the process of FIG. 2). As another
example, the processor 410 may receive, via the communication
device 420, a transaction authorization request from a merchant or
an acquirer (e.g., such as an authorization request process in
accordance with the process of FIG. 3). As another example, the
processor 410 may also transmit and receive (via the communication
device 420) an authorization request, and an authorization response
to and from an issuer (such as the issuer 112 of FIG. 1).
[0037] The processor 410 may also operate with the program to
retrieve data from a storage device (e.g., to retrieve data
associated with a static VPAN received from a merchant) and to
compute a series of expected dynamic verification numbers
associated with the static VPAN to determine whether a transaction
should be declined or whether an authorization request should be
created and transmitted to an issuer. Moreover, the processor 410
may match this information using one or more rules or formulas.
[0038] As used herein, information may be "received" by or
"transmitted" to, for example: (i) the payment provider device 400
from merchant devices, acquirers, mobile devices, issuer devices,
payment network devices; or (ii) a software application or module
within the payment provider device 400 from another software
application, module, or any other source.
[0039] As shown in FIG. 4, the storage device 430 also stores one
or more VPAN databases 500 (described with respect to FIG. 5).
Examples of a VPAN database that may be used in connection with the
payment provider device 400 will now be described in detail with
respect to FIG. 5. The illustrations and accompanying descriptions
of the databases presented herein are exemplary, and any number of
other database arrangements could be employed besides those
suggested by the figures.
[0040] FIG. 5 is a tabular view of VPAN database 500 in accordance
with some embodiments of the present invention. The table includes
entries identifying VPANs that have been issued or assigned by the
payment provider 110. The table also defines fields 502, 504, 506,
508, 510 for each of the VPAN entries. The fields specify: a VPAN
502, a PAN 504, a static card verification code 506, a counter 508,
and a VPAN expiry date 510. The information in the database 500 may
be created and updated based on information received from
cardholders, mobile devices operated by cardholders, merchants and
issuers.
[0041] The VPAN 502 may be, for example, an alphanumeric code
(typically, in current systems, a sixteen digit numeric code)
assigned by the payment provider to a cardholder for the
cardholder's use in making certain transactions pursuant to
embodiments of the present invention. In some embodiments, VPANs
issued or assigned by a payment provider are formatted in
accordance with a payment network's formatting rules. As a specific
example, for VPANs processed over the payment network operated by
MasterCard International Incorporated, VPANs are 16 digit numeric
codes in which the first 6 digits are used to identify the VPAN as
a VPAN to be routed to a payment provider 110 for processing. For
example, as illustrated in FIG. 5, the first six digits of each of
the VPANs have identical formats: "5555-55". Such a convention may
be used to ensure that transactions involving a VPAN are routed to
the payment provider 110 for processing. Those skilled in the art
will appreciate that other routing, numbering, and formatting
conventions may be used so long as a payment network may reliably
identify transactions involving a VPAN as such.
[0042] As shown in FIG. 5, each VPAN 502 is associated with a PAN
504. That is, each VPAN 502 is associated with an actual payment
account number that has been issued to a cardholders Each VPAN 502
is also associated with the static card verification code 506 from
the payment account. For example, in the case of a MasterCard
payment card, the static card verification code 506 may be the
MasterCard CVC number printed on the back face of a MasterCard
credit or debit card. Pursuant to some embodiments, the PAN 504 and
the static card verification code 506 are obtained from a
cardholder when the cardholder registers to use a payment card in a
system of the present invention (e.g., using a registration process
such as the process 200 of FIG. 2). Other static card verification
codes may also be used (e.g., such as the codes used by other
payment card brands).
[0043] Each VPAN 502 is also associated with one or more counters
508. The counter may, for example, increment each time a VPAN 502
is used in a transaction. As discussed above in conjunction with
FIG. 1, the counter 508 is used to confirm the likely validity of a
dynamic value generated by a payment application in a mobile device
when and transmitted from a mobile device to a merchant and then
from the merchant to the payment provider 110 in an authorization
request. In some embodiments (not shown in FIG. 5), a secret key
shared by the payment provider 110 and a mobile device 102 (and
stored, for example, in a payment application installed in the
mobile device 102) may also be stored in the database of FIG. 5.
The shared secret key may be used to encrypt a dynamic value
transmitted from the mobile device. The payment provider 110 may
use the shared secret key, in conjunction with the counter 508, to
decrypt the dynamic value from the mobile device 102 to ascertain
the authenticity of the transaction request. Each VPAN 502 is also
associated with a VPAN expiry date 510. The VPAN expiry date 510
may be set when the VPAN 502 is originally issued or assigned to a
cardholder, and limits the period in which the VPAN 502 may be used
in transactions. Payment provider 110 may consult the VPAN expiry
date 510 as described above in conjunction with FIG. 3 to determine
whether to deny an authorization request (or to allow further
authorization processing to proceed).
[0044] The above descriptions of processes herein should not be
considered to imply a fixed order for performing the process steps.
Rather, the process steps may be performed in any order that is
practicable, including simultaneous performance of at least some
steps.
[0045] Although the present invention has been described in
connection with specific exemplary embodiments, it should be
understood that various changes, substitutions, and alterations
apparent to those skilled in the art can be made to the disclosed
embodiments without departing from the spirit and scope of the
invention as set forth in the appended claims.
* * * * *