U.S. patent application number 14/509247 was filed with the patent office on 2015-06-11 for systems, apparatus and methods for improved authentication.
The applicant listed for this patent is MasterCard International Incorporated. Invention is credited to Craig Gilbert, Brian John Piel, Gregory D. Williamson.
Application Number | 20150161608 14/509247 |
Document ID | / |
Family ID | 53271586 |
Filed Date | 2015-06-11 |
United States Patent
Application |
20150161608 |
Kind Code |
A1 |
Gilbert; Craig ; et
al. |
June 11, 2015 |
SYSTEMS, APPARATUS AND METHODS FOR IMPROVED AUTHENTICATION
Abstract
A cardholder authentication method includes receiving, at an
authentication network, an authentication request involving an
account. The method further includes determining, based at least in
part on a portion of an account identifier associated with said
account, an authentication service. In addition, the method
includes determining, based at least on said authentication service
and a portion of said account identifier, an authentication
response. The method also includes transmitting, to a merchant
associated with a transaction involving said account, said
authentication response.
Inventors: |
Gilbert; Craig;
(Chesterfield, MO) ; Piel; Brian John; (Ballwin,
MO) ; Williamson; Gregory D.; (Stamford, CT) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MasterCard International Incorporated |
Purchase |
NY |
US |
|
|
Family ID: |
53271586 |
Appl. No.: |
14/509247 |
Filed: |
October 8, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61913670 |
Dec 9, 2013 |
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/4014 20130101;
G06Q 20/401 20130101; G06Q 20/405 20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40 |
Claims
1. A cardholder authentication method, comprising: receiving, at an
authentication network computer, an authentication request
involving an account; determining, based at least on a portion of
an account identifier associated with said account, an
authentication service; determining, based at least on said
authentication service and a portion of said account identifier, an
authentication response; and transmitting, to a merchant associated
with a transaction involving said account, said authentication
response.
2. The cardholder authentication method of claim 1, wherein said
determining said authentication service includes determining that
an enhanced authentication is required.
3. The cardholder authentication method of claim 2, wherein said
enhanced authentication includes at least a first service provided
by an on-behalf-of service provider.
4. The cardholder authentication method of claim 1, wherein the
authentication network computer is a directory server.
5. The cardholder authentication method of claim 1, wherein the
authentication network computer is an on-behalf-of services
computer.
6. The cardholder authentication method of claim 1, further
comprising: receiving at the authentication network computer, prior
to receiving said authentication request, a configuration message
from an issuer of said account, the configuration message defining
at least one criterion for determining said authorization
response.
7. The cardholder authentication method of claim 1, further
comprising: receiving at the authentication network computer, prior
to receiving said authentication request, a configuration message
from a user of said account, the configuration message defining at
least one criterion for determining said authorization
response.
8. An apparatus comprising: a processor; and a memory in
communication with the processor, the memory storing program
instructions, the processor operative with the program instructions
to perform functions as follows: receiving an authentication
request involving an account; determining, based at least on a
portion of an account identifier associated with said account, an
authentication service; determining, based at least on said
authentication service and a portion of said account identifier, an
authentication response; and transmitting, to a merchant associated
with a transaction involving said account, said authentication
response.
9. The apparatus of claim 8, wherein said determining said
authentication service includes determining that an enhanced
authentication is required.
10. The apparatus of claim 9, wherein said enhanced authentication
includes at least a first service provided by an on-behalf-of
service provider.
11. The apparatus of claim 8, wherein the processor is a component
of an authentication network computer.
12. The apparatus of claim 11, wherein the authentication network
computer is a directory server.
13. The apparatus of claim 11, wherein the authentication network
computer is an on-behalf-of services computer.
14. The apparatus of claim 8, wherein the processor is further
operative with the program instructions to receive, prior to
receiving said authentication request, a configuration message from
an issuer of said account, the configuration message defining at
least one criterion for determining said authorization
response.
15. The apparatus of claim 8, wherein the processor is further
operative with the program instructions to receive, prior to
receiving said authentication request, a configuration message from
a user of said account, the configuration message defining at least
one criterion for determining said authorization response.
16. A cardholder authentication method, comprising: receiving, at
an authentication network computer, an authentication request
involving an account; determining, based at least on a portion of
an account identifier associated with said payment account, an
authentication service; determining, based at least on said
authentication service and a portion of said account identifier, an
authentication response; and transmitting, to a token requester
associated with said authentication request, said authentication
response.
17. The cardholder authentication method of claim 16, wherein said
determining said authentication service includes determining that
an enhanced authentication is required.
18. The cardholder authentication method of claim 17, wherein said
enhanced authentication includes at least a first service provided
by an issuer access control server.
19. The cardholder authentication method of claim 16, wherein the
authentication network computer is a directory server.
20. The cardholder authentication method of claim 16, further
comprising: receiving at the authentication network computer, prior
to receiving said authentication request, a configuration message
from an issuer of said account, the configuration message defining
at least one criterion for determining said authorization response.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit of U.S. Provisional
Patent Application No. 61/913,670 filed on Dec. 9, 2013, the
contents of which are hereby incorporated by reference for all
purposes.
BACKGROUND
[0002] Embodiments of the present invention described herein relate
to transactions for payment of goods/services and, more
particularly, to the provision of authenticated transactions across
multiple channels of commerce.
[0003] Card issuers and other financial institutions now offer or
use standardized Internet transaction protocols to improve on-line
transaction performance and to accelerate the growth of electronic
commerce. Under some standardized protocols card issuers or issuing
banks may authenticate transactions thereby reducing the likelihood
of fraud and associated chargebacks attributed to cardholder
not-authorized transactions. One example of such a standardized
protocol is the 3-D Secure Protocol. The presence of an
authenticated transaction may result in an issuer assuming
liability for fraud should it occur despite efforts to authenticate
the cardholder during an online purchase. Merchants are assured by
card issuers or issuing banks that they will be paid for
issuer-authenticated transactions. The 3-D Secure (3DS) protocol is
consistent with and underlies the authentication programs offered
by card issuers (e.g., Verified by Visa or MasterCard SecureCode)
to authenticate customers for merchants during remote transactions
such as those associated with the Internet.
[0004] The 3-D Secure Protocol leverages existing Secure Sockets
layer (SSL) encryption functionality and provides enhanced security
through issuer "authentication" of the cardholder during the online
shopping session. A piece of software called the Merchant Plug In
(MPI) is used by participating merchants to exchange messages, pass
information and query participants in order to establish an
authentication session between the cardholder and their card issuer
during an online purchase. The 3-D Secure Protocol services are
generally based on a three-domain model--the issuer domain,
acquirer and interoperability domain. The issuer is responsible for
managing the enrollment of cardholders in the service, and for
authenticating cardholders during on-line transactions. The
acquirer is responsible for defining procedures so that merchants
participating in Internet transactions operate under an agreement
with the acquirer, and for providing back end processing for
authenticated transactions. The interoperability domain facilitates
the transaction exchange between the other two domains with a
common protocol and shared services.
[0005] Cardholders and their banks may come under the "Issuer
Domain", merchants and their banks may come under the "Acquirer
Domain". Communication between issuing and acquiring banks or
financial institutions and card issuer infrastructure may come
under "Interoperability Domain". While transacting with 3-D Secure
compliant banks and merchants, a consumer may have the same
Internet shopping experience as previously, except that there is a
separate authentication window or i-frame element from the
cardholder's bank to determine if the transacting party is indeed
the cardholder of record. The transaction flow for an on-line
Internet purchase transaction under the protocol may be as
follows:
[0006] (1) Customers fill in payment data at merchant web sites in
the usual fashion, via an encrypted Secure Sockets Layer (SSL)
connection.
[0007] (2) The merchant then sends a message through an MPI to a
directory server or system which in turn queries the card issuer to
find out whether the customer is enrolled in the 3-D Secure
program.
[0008] (3) The card issuer responds to the directory with a message
indicating whether the cardholder is enrolled and, if so, provides
a Web address for the financial institution that issued the card.
This message is then processed and a response forwarded to the
merchant.
[0009] (4) The merchant then sends a message to the issuing
financial institution, through the cardholder device, to initiate
an authentication session between the cardholder and the card
issuer in which transaction details such as merchant name and
transaction amount may also be presented to the cardholder for
confirmation.
[0010] (5) The issuing financial institution will then populate an
authentication window to the cardholder detailing information
related to the transaction such as merchant name and amount, a
personal security message, and a response area where authentication
details can be entered by the cardholder.
[0011] (6) The customer approves the transaction in one of a
variety of ways, depending on how the issuing financial institution
chooses to implement the system. Options may range from entering a
static password or PIN to utilizing a smart card and a Personal
Card Reader (PCR) to generate an authentication token, and may also
include utilizing authentication methods on a consumer device such
as a smart phone application or consumer biometric reader.
[0012] (7) If the authentication is valid, the issuer sends a
message to the merchant indicating the transaction was successful.
The issuer also notifies the merchant if the authentication failed
or was unable to be completed.
[0013] It would be desirable to provide improved authentication
systems which are based, at least in part, on the 3-D Secure
Protocol described above or on any other authentication
protocol.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] Features and advantages of some embodiments, and the manner
in which the same are accomplished, will become more readily
apparent with reference to the following detailed description taken
in conjunction with the accompanying drawings, which illustrate
exemplary embodiments, wherein:
[0015] FIG. 1 is a block diagram of a transaction system according
to an embodiment of the invention.
[0016] FIGS. 2-4 are block diagrams of a portion of a transaction
system pursuant to some embodiments.
[0017] FIGS. 5A-6C are flow diagrams illustrating processes
according to some embodiments.
[0018] FIG. 7 is a block diagram of a computer system/computer
architecture that may constitute one or more components of the
transaction system of FIG. 1.
[0019] FIGS. 8-9 are flow diagrams illustrating processes according
to some embodiments.
DETAILED DESCRIPTION
[0020] In general, and for the purpose of introducing concepts of
novel embodiments described herein, provided are systems, apparatus
and methods for providing an improved authentication system for
financial transactions.
[0021] In some embodiments, improved authentication techniques and
methods are provided which allow an improved user experience for
merchants and consumers, especially when used in conjunction with
transactions involving mobile devices. In some embodiments,
authentication techniques and methods are provided which allow use
with financial transactions involving tokenization (such as
transactions following the tokenization standards recently
announced by MasterCard International Incorporated and Visa
International).
[0022] Further, in some embodiments, authentication techniques may
include additional authentication levels that may be determined by
a card issuer or on a transaction by transaction basis, allowing
the authentication required for a given transaction to be enhanced
in some situations. Embodiments provide improved adoption of such
authentication techniques, as well as the reduction of declined
transactions which are legitimate card not present
transactions.
[0023] Features of some embodiments will now be described by
reference to FIG. 1, where a transaction system 100 pursuant to
some embodiments is shown. A system pursuant to some embodiments
involves a number of devices and entities interacting to conduct a
transaction. For example, payment cardholders may interact with one
or more consumer devices 102 to initiate financial transactions.
Consumer devices 102 may include, for example, mobile phones,
computers, set top boxes, or other devices (such as game consoles,
or the like). The transactions are card not present transactions
(e.g., where no physical card is presented to the merchant during
the transaction). Embodiments allow such card not present
transactions to be performed with a higher level of authentication
than in the past. As used herein, the consumer devices 102 are
referred to as being part of the "consumer interaction domain" of
the present invention.
[0024] Each of the consumer devices 102 may be in communication
with one or more devices in an "interoperability domain". The
interoperability domain may be at least partly constituted by an
authentication network 103. The authentication network 103 may
include any device or computer that engages in or facilitates
decision-making in regard to what kind or kinds of authentication
processing are to be employed for a given transaction. The
authentication network 103 may include, for example: (A) one or
more servers or devices providing a consumer interface application
programming interface ("API") 104, (B) one or more servers or
devices providing a directory server 106, and (C) one or more
servers or devices providing on-behalf-of (OBO) services 108.
[0025] The devices and systems in the "interoperability domain" are
in communication with one or more devices or systems in an "issuer
domain" such as, for example, one or more access control servers
110, and one or more issuers 112.
[0026] Making reference again to the consumer device 102 and the
"consumer interaction domain", it should be noted that both of
these may interact with the "acquirer domain" in the three domain
model. The acquirer domain is at least partly represented in FIG. 1
by block 114, which represents one or more servers or other devices
that perform services by or for the merchant that is involved in
the current transaction. The merchant services component 114 may,
for example, be an e-commerce server operated by the merchant or by
a service provider retained by the merchant. It will be noted that
the merchant services component 114 may interact with both the
consumer device 102 and with one or more components of the
authentication network 103.
[0027] Pursuant to some embodiments, the present invention allows
an improved customer experience in authentication interactions
across different types of consumer devices than previous
authentication systems. For example, in some embodiments, the need
for a merchant plug in may be reduced or eliminated in some
situations. Further embodiments allow merchants to maintain their
desired look and feel during transactions. In some embodiments,
context specific message sets may be provided--for example,
tokenization transactions may be provided with authentication
support. Pursuant to some embodiments, the interaction between a
consumer device 102 and a device in the interoperability domain may
depend on an authentication choice made by a merchant. For example,
a merchant may use a standard MPI for authentication of
transactions involving different consumer devices 102, and in such
embodiments, the interaction between the consumer device 102 and a
device in the interoperability domain may include interaction with
the authentication network 103. A merchant may also (or instead)
choose to use an API for interaction during authentication
transactions, and in such embodiments, the interaction between the
consumer device 102 and a device in the interoperability domain may
include interaction with a consumer interface API 104. In either
event, the interoperability domain may also be invoked to perform
one or more on-behalf-of services by applying rules associated with
on-behalf-of services device 108. Pursuant to some embodiments, the
application of any on-behalf-of services 108 may be based on
information associated with the payment card used by the consumer
at the consumer device 102. For example, in some embodiments,
whether any on-behalf-of (OBO) service should be applied in a given
transaction may be based on BIN- or account-level rules established
by a payment card issuer. In addition to or instead of permitting
configuration of decisioning on OBO service by the payment card
issuer, the transaction system 100 may also incorporate
configuration of such decisioning by the cardholder/user of the
payment card. In some embodiments, where both issuer-configured and
user-configured rules are in effect, a suitable rules hierarchy may
be established to determine which rule or rules to apply in a given
case. In some embodiments, the rules hierarchy may be established
by or in response to the issuer so as to accommodate one or more
user-configured rules. In some embodiments, the rules hierarchy may
operate so as to override a user-configured rule in favor of a
contrary rule established pursuant to issuer configuration
input.
[0028] A number of different types of on-behalf-of services may be
used and applied to transactions pursuant the present invention.
For example, on-behalf-of services may be provided which provide
additional or enhanced authentication to transactions. For example,
a financial account issuer may determine that transactions
involving certain accounts should utilize biometric authentication
techniques. The on-behalf-of services 108 may be applied to
transactions involving such accounts pursuant to the present
invention, and the additional biometric authentication requirements
may be imposed during such transactions. Other types of
on-behalf-of services applied during transactions involving the
system of the present invention could include, for example, risk
based decisioning services, dynamic verification code services, or
the like.
[0029] Pursuant to some embodiments, communication between the
interoperability domain and the issuer domain may involve one or
more interactions (unlike prior authentication solutions). For
example, an authentication interaction may involve communication
between a consumer device 102, a consumer interface API 104 and an
issuer 112. In this manner, issuers, merchants and consumers may
participate in the authentication system of the present invention
without need to interact with an ACS or without need to use an MPI.
Such interactions may also invoke the application of one or more on
behalf services 108. Pursuant to some embodiments the use of the
consumer interface API 104 allows the provision of authentication
web services across a wide variety of devices. Further,
on-behalf-of services may be made available to all issuers,
allowing for an enhanced transaction experience. For example, an
issuer may select to utilize risk based decisioning (or "RBD") and
an RBD service may be applied to transactions associated with that
issuer (or a predetermined subset of accounts associated with the
issuer). Pursuant to some embodiments, the authentication network
103 may be configurable for each issuer 112, allowing unique
routing per message type and per BIN (or account number) range. For
example, some elite cards may be configured to use an on behalf
service providing RBD, and all other card types from that issuer
may be sent to an ACS for authentication processing. In some
embodiments, the use of the consumer interface API 104 allows the
ACS 110 and/or the issuer 112 to interact with a consumer device
102 via a secure channel.
[0030] Illustrative examples of various combinations of
authentication flows are shown in FIGS. 2-4 (in each, the consumer
device 102 is depicted as being a mobile device for illustration
purposes only--a wide variety of consumer devices may be used in
each of the flows).
[0031] In the authentication flow of FIG. 2, tokenization may be
implemented (i.e., with a payment token in use in at least part of
the transaction flow instead of a PAN (primary account number)).
For that reason, the consumer device 102 may interact with a token
requestor server 202 as well as the merchant services provider 114.
In the example shown in FIG. 2, interaction between the consumer
device 102 and the token requestor 202, and between the consumer
device 102 and the merchant services provider 114 may be via an
API. Similarly, any necessary interaction between the ACS 110 and
the issuer 112 (on one hand) and the consumer device 102 (on the
other hand) may also be via API. Communication among the
authentication network 103, the merchant services provider 114 and
the token requestor 202 may be web-based, via XML (extensible
markup language), JSON (JavaScript Object Notation), or other
communication format.
[0032] In FIG. 3, an embodiment is depicted where the consumer
device 102 may be used in either an ecommerce transaction--block
302 (via an API communication with the authentication network 103)
as well as in an identification and verification ("ID&V")
transaction--block 304 (via an API communication with the
authentication network 103). In some transactions, the
authentication network 103 is in communication with an ACS 110, and
in others, the authentication network 103 is in communication with
the issuer 112.
[0033] In FIG. 4, an embodiment is depicted with various messaging
steps identified and showing the use of the API of the present
invention in conjunction with a tokenization transaction. At S402,
the cardholder/user initiates the ID&V process by operating the
consumer device 102. At S404, the token requestor 202 sends the PAN
and all applicable device information via API to the authentication
network 103.
[0034] At S406, the authentication network 103 receives the request
and determines that the applicable process flow is for ID&V. As
part of this step, the authentication network 103 looks up the
appropriate issuer interface and sends an ID&V request over the
interface to the issuer 112. (If no appropriate issuer interface is
available, the authentication server responds accordingly to the
token requestor 202 and the process terminates at that point.)
[0035] At S408, the issuer 112 responds to the authentication
network 103 to acknowledge the ID&V process flow.
[0036] At S410, the authentication network 103 forwards the issuer
response and the issuer API reference back to the token requestor
202.
[0037] At S412, the token requestor 202 sends an ID&V
confirmation request to the web service of the issuer 112 via the
consumer device 102.
[0038] At S414, the issuer 112 receives the ID&V confirmation
request.
[0039] At S416, the issuer 112 validates the request and then the
ACS (FIG. 1, not shown in FIG. 4) creates an ID&V response
message.
[0040] At S418, the issuer 112 returns the ID&V response to the
token requestor 202 via the consumer device 102. (In addition, the
issuer 112 may send selected ID&V transaction records to a
history server, which is not shown.)
[0041] At S420, the token requestor 202 receives the ID&V
response.
[0042] At S422, the token requestor 202 validates the ID&V
response.
[0043] At S424, in the case of a positive response, the token
requestor 202 completes the tokenization of the consumer device
102; in the case of a negative response, the same is communicated
at this point from the token requestor 202 to the consumer device
102.
[0044] Illustrative examples of transaction flows which involve the
on-behalf-of services features of the present invention are shown
in FIGS. 5A-6C. In FIGS. 5A-6C, the use of a merchant plugin
("MPI") is shown--however, embodiments may include flows without an
MPI (e.g., where communication between the consumer device 102 and
an interoperability layer is via an API or other connection). In
the illustrative embodiment of FIGS. 5A/5B, a first scenario is
shown where one or more on-behalf-of services are applied to a
transaction during processing. In the processing of FIG. 5A, a
cardholder/user interacts (block 502, FIG. 5A) with a consumer
device 102 to conduct a transaction with a merchant; this may
include the user entering payment card account data into the
merchant e-commerce checkout page. The merchant causes payment
account data associated with the cardholder to be transmitted
(block 504) to an interoperability domain (e.g., to the above
mentioned MPI; this may occur via an API call or a software call,
for example).
[0045] At block 506, the MPI may generate and transmit a
corresponding message to the authentication network 103 (FIG. 1).
Referring again to FIG. 5A, at decision block 508, the
authentication network 103 (e.g., via directory server 106) makes a
routing determination based on the payment account data (e.g., such
as based on the BIN of the payment account). Based on the routing
determination, a determination may be made (at decision block 510)
that some on-behalf-of services are to be applied (e.g., based on
information provided by the issuer of the payment account). Again
this determination may be made by the authentication network 103
(possibly via the directory server 106).
[0046] At block 512, the authentication network 103/directory
server 106 then causes a message (such as, for example, an XML
message or the like) to be transmitted to the on-behalf-of services
108 for processing. At decision block 514, the OBO service 108 may
determine that a corresponding app that it hosts has received the
message referred to above in connection with block 512. In the
illustrative example, shown in FIG. 5A, the on-behalf-of services
processing 108 determines (decision block 516) that the cardholder
is a low risk cardholder (e.g., using a risk based decisioning
service) and a response is transmitted (block 518) from the OBO
service 108 to the authentication network 103 with the
authentication response. Where the authentication is deemed
successful, as assumed here, then the response may include a
transaction cryptogram or other token such as an "AAV" (account
authentication value). The data provided by the OBO service 108 is
forwarded (block 520, FIG. 5B) from the authentication network 103
to the MPI. Then, as indicated at 522 in FIG. 5B, the MPI may
complete the 3DS transaction and transmit required data elements to
the merchant 114 (FIG. 1) to allow the merchant to proceed (block
524) with what may be an essentially conventional authorization
request to the acquirer (not shown). The transaction may then be
completed in accordance with conventional practices for e-commerce
transactions.
[0047] In some embodiments, the processing by the interoperability
domain may include a determination that some "step up" or increased
authentication may be required for a transaction. Such an example
is shown in the flow diagram formed by FIGS. 6A/6B/6C, where the
on-behalf-of service 108 determines that the cardholder or
transaction requires additional authentication method(s) and causes
some additional processing to be performed by the consumer and/or
the merchant to complete the transaction. In this manner,
embodiments allow improved authentication processing to be
performed. Issuers are able to provide "step up" or additional
services that can easily be applied to transactions.
[0048] The above discussion related to blocks 502-514 of FIG. 5A is
also applicable to blocks 602-614 of FIG. 6A. In the illustrative
example shown in FIG. 6A, the OBO service processing 108 determines
(decision block 616) that the cardholder is not sufficiently low
risk to by-pass the step up process. In other words, based on risk
based decisioning (RBD), the OBO service processing 108 determines
that step-up is required. Consequently, as indicated at block 618
in FIG. 6B, the OBO service processing 108 may initiate a call to
the cardholder/user via the consumer device 102 and/or according to
whatever method or methods the card account issuer has prescribed
for contacting the cardholder for the step-up process. As indicated
at block 620, the cardholder receives an authorization request,
which may include one or more of a single use token, an e-mail
link, a push notification, a request to provide a biometric
authentication, etc.
[0049] In conjunction with the process steps shown at 618 and 620,
the OBO service processing 108 transmits (block 622) a response to
the authentication network 103, where the response may be a message
with the step-up flag set to indicate that the step-up process is
to be performed. The authentication network 103, in turn, may
formulate and transmit (block 624) a response to the MPI, where the
response has the step-up flag set. The MPI then initiates (block
626) a step-up call to a presentation interface channel via post
through the consumer device 102. The cardholder/user is then
involved (block 628) by operating the consumer device 102 to open
the step-up interface in a window on the consumer device 102 by
using the presentation interface.
[0050] At block 630, the authentication network 103, via the
presentation interface, loads web content (i.e., HTML, Javascript
and the like) to a web browser via i-frame, page redirection, etc.,
or interacts with Software Development Kit (SDK), on the consumer
device 102, and calls the ACS 110 via XML with a step-up response
based on the cardholder's input/response to the step-up process
requirement(s).
[0051] At decision block 632, the OBO service processing 108 may
receive the resulting message and determine whether the cardholder
response is valid. Then, at block 634 (FIG. 6C), the OBO service
processing 108 may formulate and send to the authentication network
103/presentation interface the authentication response. Where the
authentication is deemed successful, as assumed here, then the
response may include a transaction cryptogram or other token such
as an "AAV" (account authentication value).
[0052] At block 636, the authentication network 103/presentation
interface may complete the session with the cardholder via the
consumer device 102 and post a response with the MPI. Then, as
indicated at 638 in FIG. 6C, the MPI may complete the 3DS
transaction and transmit required data elements to the merchant 114
(FIG. 1) to allow the merchant to proceed (block 640) with what may
be an essentially conventional authorization request to the
acquirer (not shown). The transaction may then be completed in
accordance with conventional practices for e-commerce
transactions.
[0053] FIG. 7 is a block diagram of a computer system/computer
architecture that may constitute one or more components of the
transaction system 100 of FIG. 1. For example, the computer system
702 depicted in FIG. 7 may implement one or more of the directory
server 106 and/or the OBO service computer 108 and/or another
component of the authentication network 103. As discussed further
below, the computer system 702 may be programmed in accordance with
aspects of the present invention to provide one or more of the
functions described herein.
[0054] Referring now to FIG. 7, the computer system 702 may be
conventional in its hardware aspects but may be controlled by
software to cause it to function as described herein. For example,
the computer system 702 may be constituted by conventional server
computer hardware.
[0055] The computer system 702 may include a computer processor 700
operatively coupled to a communication device 701, a storage device
704, an input device 706 and an output device 708.
[0056] The computer processor 700 may be constituted by one or more
conventional processors. Processor 700 operates to execute
processor-executable steps, contained in program instructions
described herein, so as to control the computer system 702 to
provide desired functionality.
[0057] Communication device 701 may be used to facilitate
communication with, for example, other devices (such as other
components of the transaction system 100). For example, the
communication device 701 may include numerous communication ports
and interfaces to facilitate communications over-the-air via one or
more mobile communication networks (not shown) and/or the
communication device 701 may facilitate numerous calls for service
via the Internet and/or over one or more private or dedicated data
communication networks.
[0058] Input device 706 may comprise one or more of any type of
peripheral device typically used to input data into a computer. For
example, the input device 706 may include a keyboard and a mouse.
Output device 708 may comprise, for example, a display and/or a
printer.
[0059] Storage device 704 may comprise any appropriate information
storage device, including combinations of magnetic storage devices
(e.g., hard disk drives), optical storage devices such as CDs
and/or DVDs, and/or semiconductor memory devices such as Random
Access Memory (RAM) devices and Read Only Memory (ROM) devices, as
well as so-called flash memory. Any one or more of such information
storage devices may be considered to be a computer-readable storage
medium or a computer usable medium or a memory.
[0060] Storage device 704 stores one or more programs for
controlling processor 700. The programs comprise program
instructions (which may be referred to as computer readable program
code means) that contain processor-executable process steps of the
computer system 702, executed by the processor 700 to cause the
computer system 702 to fulfill the functions of one or more system
components described herein.
[0061] The programs may include one or more conventional operating
systems (not shown) that control the processor 700 so as to manage
and coordinate activities and sharing of resources in the computer
system 702, and to serve as a host for application programs
(described below) that run on the computer system 702.
[0062] The programs stored by the storage device 704 may include,
for example, a transaction handling application program 710. The
transaction handling application program 710 may control the
processor 700 to enable the computer system 702 to perform one or
more of the transaction-related functions described in this
disclosure. For example, this may include, at least in part,
determining what type or types of authentication service(s) are to
be performed for a given transaction based on account-related
information such as the account number associated with the account
involved in the current transaction. The transactions handled by
the computer system 702 may include payment transactions and
ID&V (tokenization) transactions.
[0063] The storage device 704 may also store one or more decision
rules 712 that indicate how the computer system 702 decides from
transaction to transaction what authentication service(s) is (are)
to be applied. As noted above, the decision rules may be subject to
being configured according to input from either or both of the card
account issuer and/or the card account user.
[0064] In addition, the storage device 704 may store a data
communications program 714 such as may be required to allow the
computer system 702 to engage in data communications with other
components of the transaction system 100.
[0065] The storage device 704 may also store, and the computer
system 702 may also execute, other programs, which are not shown.
For example, such programs may include a reporting application,
which may respond to requests from system administrators for
reports on the activities performed by the computer system 702. The
other programs may also include, e.g., website hosting programs, a
database management program, device drivers, etc.
[0066] The storage device 704 may also store one or more databases
716 required for operation of the computer system 702.
[0067] In accordance with teachings of the present invention,
configurability of authentication services, by card account issuers
and/or card account users, may allow for authentication processes
that meet the issuers' and/or account users' goals for transaction
security and convenience. For example, in some embodiments, a
particular issuer may specify that for its top tier account
holders, step-up will be performed only for quite large purchases,
and when step-up does occur a particular biometric process that is
convenient for the account holder will be utilized. In some
embodiments, the rules specified by the issuer for the top-tier
customer may allow RBD to be by-passed for some or most
transactions. The authentication network 103 may determine that a
particular issuer-configured rule is applicable to a particular
transaction based on the payment account number (or portion
thereof, such as the BIN) submitted for the transaction. In some
embodiments, for other account holders, a conventional RBD process
with possible step-up may be applicable.
[0068] In accordance with other teachings of this disclosure, the
account user may be permitted to configure rules so as to implement
the user's preferences with respect to authentication processing.
For example, the user may be permitted to indicate a preference for
biometric authentication or authentication by PIN entry. In some
embodiments, the transaction system 100/authentication network 103
may operate to harmonize the issuer's preferences with the user's
preferences. In some embodiments, if there is an insoluble conflict
between the issuer's authentication preferences and the user's
authentication preferences, the transaction system
100/authentication network 103 may operate such that the issuer's
preferences are allowed to prevail.
[0069] In some embodiments, authentication rules may also be
subject to configuration by merchants in at least some cases. For
example, where the merchant has the customer's account information
(and/or payment token) on file and the merchant is well acquainted
with the customer (and/or has performed its own risk assessment for
the customer with a satisfactory result), the merchant may prefer
that RBD/possible step-up by the authentication network 103 be
bypassed. Thus for a given account number/payment token and a given
merchant, a transaction may be processed by the transaction system
100/authentication network 103 such that authentication processing
may be determined in accordance with configuration data input from
the merchant. According to another example embodiment, the merchant
may configure the authentication decisioning such that the
transaction will not go through unless the account issuer supports
authentication in accordance with the 3DS model. The authentication
network 103 may make a determination on this point based on the BIN
for the submitted account number.
[0070] Configuration data input from the issuer, user or merchant,
as the case may be, may be provided from the party in question by a
message sent to and received by the authentication network 103
during administrative or set-up activity prior to execution of a
transaction that is based on the configuration data input.
[0071] FIGS. 8-9 are flow diagrams illustrating processes according
to some embodiments.
[0072] FIGS. 8 and 9 illustrate example processes for performing
ID&V (identification and verification) in accordance with
aspects of the present invention. As is understood by those who are
skilled in the art, ID&V may be performed in connection with
tokenization operations.
[0073] In the scenario of FIG. 8, ID&V is performed without
step-up. At block 802 in FIG. 8, the token requestor 202 (FIG. 2)
sends an ID&V request to the authentication network 103.
Continuing to refer to FIG. 8, at decision block 804, the
authentication network 103 (e.g., via directory server 106, FIG.
1), makes a routing determination based on the payment account data
(e.g., such as based on the BIN of the payment account). At block
806, the authentication network 103 formulates and sends a message
which includes a request for authentication. This message may be
sent to an issuer ACS 110 (FIG. 1), with the particular ACS
determined and/or the content of the message/request determined at
block 804.
[0074] At decision block 808, the issuer ACS 110 selects the
desired type of authentication process. At decision block 810, the
issuer ACS 110 determines the cardholder's identity and/or
determines to what extent there is risk involved in the current
authentication request. In the illustrative example shown in FIG.
8, the issuer ACS 110 determines that the request is low risk, and
transmits (block 812) a response back to the authentication network
103 with the authentication status. Where the authentication is
deemed successful, as assumed here, then the response may include a
cryptogram or other token such as an "AAV" (account authentication
value).
[0075] At block 814, the authentication network 103 may formulate
and send a response to the token requestor 202, to indicate the
authentication status. Then, at block 816, the token requestor 202
may continue the tokenization process.
[0076] In some embodiments, the processing in the authentication
network 103 or another component of the transaction system 100 may
include a determination that some "step up" or increased
authentication may be required for the ID&V request. Such an
example is shown in the flow diagram presented in FIG. 9.
[0077] The above discussion of blocks 802-806 in connection with
FIG. 8 is also applicable to blocks 902-906 shown in FIG. 9. At
decision block 908 in FIG. 9, the issuer ACS 110 selects the
desired type of authentication process. In this illustrative
example, it is assumed that the issuer ACS 110 determines (e.g.,
pursuant to RBD) that step-up should be required. This may involve
a user authentication process (block 910), which may entail the
cardholder/user interacting with the consumer device 102 to perform
a function such as a bank customer login procedure, token
validation, etc.
[0078] At decision block 912, the issuer ACS 110 may consider the
outcome/user response provided at block 910 and on that basis may
determine the cardholder's identity and/or determine to what extent
there is risk involved in the current authentication request. In
the illustrative example shown in FIG. 9, the issuer ACS 110
determines that the request is low risk, and transmits (block 914)
a response back to the authentication network 103 with the
authentication status. Where the authentication is deemed
successful, as assumed here, then the response may include a
cryptogram or other token such as an "AAV" (account authentication
value).
[0079] At block 916, the authentication network 103 may formulate
and send a response to the token requestor 202, to indicate the
authentication status. Then, at block 918, the token requestor 202
may continue the tokenization process.
[0080] In some embodiments, the improved authentication processing
is based in part on existing 3-D Secure transaction methods which
include modified messaging (including, for example, additional
buyer information fields, risk based decisioning data, and other
optional data). Additional message types are provided to support
new processes such as, for example, tokenization processes. A Web
services interface is provided to improve interaction between
devices, and routing is provided which allow issuers to specify
on-behalf-of and other services.
[0081] As used herein and in the appended claims, the term "payment
account identifier" includes PANs (primary account numbers) as well
as payment tokens used in place of PANs pursuant to a tokenization
system.
[0082] While teachings of the present disclosure have been
described within the context of payment account system processes,
those teachings are also applicable to other types of accounts as
well, such as customer loyalty accounts, access accounts (e.g., to
rooms, buildings, or computing resources and/or webpage accounts),
and other types of financial accounts. As used herein and in the
appended claims, the term "account" includes a payment account and
other types of accounts, including but not limited to those
mentioned above, and the term "account identifier" includes a
payment account identifier and identifiers of other types of
accounts.
[0083] The above descriptions and illustrations 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.
[0084] 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.
* * * * *