U.S. patent application number 13/975874 was filed with the patent office on 2013-12-26 for methods and systems for user authentication.
This patent application is currently assigned to MasterCard International Incorporated. The applicant listed for this patent is MasterCard International Incorporated. Invention is credited to John R. Wankmueller.
Application Number | 20130346313 13/975874 |
Document ID | / |
Family ID | 43589377 |
Filed Date | 2013-12-26 |
United States Patent
Application |
20130346313 |
Kind Code |
A1 |
Wankmueller; John R. |
December 26, 2013 |
METHODS AND SYSTEMS FOR USER AUTHENTICATION
Abstract
Methods and systems for authenticating a user are provided. In
an embodiment, an authentication service device receives a request
to authenticate a user, and transmits a transaction history
database query based on business rules concerning transactions
conducted by the user. The response to the query includes a
plurality of transactions, and the authentication service device
generates a user authentication form that includes a set of
transactions, and at least two of the transactions include a
redacted transaction detail field. The user authentication form is
transmitted to a user device, and user responses to the redacted
transaction detail fields are received. The user is authenticated
based on a monetary amount response that falls within a
predetermined variance threshold, at least one positive information
response, and on the user satisfying a permissible number of
retry(s) requirement.
Inventors: |
Wankmueller; John R.; (Great
Neck, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MasterCard International Incorporated |
Purchase |
NY |
US |
|
|
Assignee: |
MasterCard International
Incorporated
Purchase
NY
|
Family ID: |
43589377 |
Appl. No.: |
13/975874 |
Filed: |
August 26, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12541464 |
Aug 14, 2009 |
8572704 |
|
|
13975874 |
|
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
H04L 63/12 20130101;
G06Q 20/40 20130101; G06F 2221/2101 20130101; G06F 2221/2153
20130101; H04L 2463/102 20130101; H04L 2209/56 20130101; G07F 19/00
20130101; G06F 21/31 20130101; H04L 63/08 20130101; G06Q 20/4014
20130101; G06F 2221/2151 20130101; G06Q 20/10 20130101; G06Q 40/02
20130101; H04L 9/3271 20130101 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40 |
Claims
1. A method, comprising: receiving, by an authentication service
device from a service provider device, a request to authenticate a
user, the request comprising user identification data and financial
account data associated with the user; transmitting, by the
authentication service device based on the financial account data,
a transaction history database query to a transaction history
database, the query based on business rules concerning transactions
conducted by the user and stored in the transaction history
database, wherein each transaction comprises a plurality of
transaction detail fields; receiving a response comprising a
plurality of transactions that satisfy the query; generating, by
the authentication service device, a user authentication form
comprising a set of transactions of the plurality of transactions,
wherein at least two of the set of transactions include at least
one redacted transaction detail field, and wherein the user
authentication form is generated based on authentication rules
provided by the service provider device that specify a minimum
number of transactions requirement, at least one transaction amount
detail field redaction requirement, and a permissible number of
user retry(s) requirement; transmitting the user authentication
form including the redacted transaction detail fields to a user
device; receiving, by the authentication service device, user
responses to the redacted transaction detail fields; and
authenticating, by the authentication service device, the user
based on a monetary amount response within a predetermined variance
threshold, on at least one positive information response, and on
the user satisfying the permissible number of retry(s)
requirement.
2. The method of claim 1, further comprising transmitting, by the
authentication service device to the service provider device, the
authentication result.
3. The method of claim 1, further comprising: receiving from a
service provider device, updated authentication rules; and
replacing, by the authentication device, the authentication rules
with the updated authentication rules prior to generating a user
identification form.
4. The method of claim 1, wherein the business rules for creating
the transaction history database query includes requiring a set of
transactions to be within a predetermined date range.
5. The method of claim 4, wherein the predetermined date range is
specified by a user.
6. The method of claim 1, wherein the business rules for creating
the transaction history database query includes requiring at least
one transaction to have been conducted at particular type of
merchant.
7. The method of claim 1, wherein the user authentication form
further comprises at least one transaction that includes a redacted
bogus transaction detail field.
8. The method of claim 1, wherein the transaction history database
includes a plurality of transactions conducted by a plurality of
users.
9. The method of claim 1, wherein authenticating further comprises
determining that the amount of correct information responses of the
user satisfies a predetermined authentication threshold.
10. An authentication apparatus, comprising: a processor; and a
non-transitory storage device operably coupled to the processor and
storing instructions configured to cause the processor to: receive
a request to authenticate a user from a service provider device,
the request comprising user identification data and financial
account data associated with the user; transmit a transaction
history database query to a transaction history database, the query
based on business rules concerning transactions conducted by the
user and stored in the transaction history database, wherein each
transaction comprises a plurality of transaction detail fields;
receive a response comprising a plurality of transactions that
satisfy the query; generate a user authentication form comprising a
set of transactions of the plurality of transactions, wherein at
least two of the set of transactions include at least one redacted
transaction detail field, and wherein the user authentication form
is generated based on authentication rules provided by the service
provider device that specify a minimum number of transactions
requirement, at least one transaction amount detail field redaction
requirement, and a permissible number of user retry(s) requirement;
transmit the user authentication form including the redacted
transaction detail fields to a user device; receive user responses
to the redacted transaction detail fields; and authenticate the
user based on a monetary amount response within a predetermined
variance threshold, on at least one positive information response,
and on the user satisfying the permissible number of retry(s)
requirement.
11. The apparatus of claim 10, wherein the storage device further
stores at least one of a transaction history database and an
authentication rules database.
12. The apparatus of claim 10, further comprising a communication
device operatively coupled to the processor and adapted to
communicate with at least one of a point of sale device, a user
device, and a service provider device.
13. A non-transitory computer-readable medium storing instructions
configured to cause a processor to: receive a request to
authenticate a user from a service provider device, the request
comprising user identification data and financial account data
associated with the user; transmit a transaction history database
query to a transaction history database, the query based on
business rules concerning transactions conducted by the user and
stored in the transaction history database, wherein each
transaction comprises a plurality of transaction detail fields;
receive a response comprising a plurality of transactions that
satisfy the query; generate a user authentication form comprising a
set of transactions of the plurality of transactions, wherein at
least two of the set of transactions include at least one redacted
transaction detail field, and wherein the user authentication form
is generated based on authentication rules provided by the service
provider device that specify a minimum number of transactions
requirement, at least one transaction amount detail field redaction
requirement, and a permissible number of user retry(s) requirement;
transmit the user authentication form including the redacted
transaction detail fields to a user device; receive user responses
to the redacted transaction detail fields; and authenticate the
user based on a monetary amount response within a predetermined
variance threshold, on at least one positive information response,
and on the user satisfying the permissible number of retry(s)
requirement.
14. The non-transitory computer-readable medium of claim 13,
further comprising instructions configured to cause the processor
to transmit to the authentication result to a service provider
device.
15. The non-transitory computer-readable medium of claim 13,
further comprising instructions configured to cause the processor
to: receive updated authentication rules; and replace the
authentication rules with the updated authentication rules prior to
generating a user identification form.
16. The non-transitory computer-readable medium of claim 13,
wherein the business rules for creating the transaction history
database query comprise rules configured to cause the processor to
transmit a transaction history database query requiring the set of
transactions to be within a predetermined date range.
17. The non-transitory computer-readable medium of claim 13,
wherein the business rules for creating the transaction history
database query comprise rules configured to cause the processor to
transmit a transaction history database query requiring at least
one transaction to have been conducted at particular type of
merchant.
18. The non-transitory computer-readable medium of claim 13,
wherein the authentication rules for generating the user
authentication form comprise rules configured to cause the
processor to include at least one transaction that includes a
redacted bogus transaction detail field.
19. The non-transitory computer-readable medium of claim 13,
wherein the instructions for authenticating the user further
comprises instructions configured to cause the processor to
determine that the amount of correct information responses of the
user satisfies a predetermined authentication threshold.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit of U.S. patent
application Ser. No. 12/541,464 filed on Aug. 14, 2009, which is
incorporated herein by reference.
FIELD
[0002] The present invention relates to user authentication. In
particular, the present invention relates to systems and methods
for authenticating a user substantially in real-time using an
account identifier and historical transaction information
associated with the user.
BACKGROUND
[0003] As the Internet and other forms of remote communication
become more prevalent, more and more service providers are allowing
new customers or users to register for access to products or
services remotely. Frequently, users are asked to enroll one of
their existing financial accounts into a back end system. For
example, a user may want to link a credit card account to an
Internet service (such as PayPal.RTM.). As another example, a user
may wish to associate their checking account with a service (such
as a rewards system, PayPal.RTM. or the like). Prior to allowing
such association, service providers must accurately and carefully
authenticate the user and the user's right to access the account to
be associated.
[0004] A number of techniques have been used for such
authentication. For example, when a PayPal.RTM. customer wishes to
link a bank account to his or her PayPal account, PayPal requires
that the user authenticate their ownership of the bank account by
confirming two small deposit amounts that are made by PayPal into
the user's bank account. By confirming the amounts, the user
authenticates her ownership or access to the bank account.
Unfortunately, such authentication takes time (sometimes up to
several days after the user requested access to the new financial
service).
[0005] It would be desirable to provide systems and methods that
would allow user authentication to be performed substantially in
real-time during the course of a registration transaction.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 is a block diagram representation of a system that
may be provided according to some embodiments.
[0007] FIG. 2 is a block diagram of an authentication service
device according to some embodiments.
[0008] FIG. 3 is a flow chart that illustrates a method that may be
performed according to some embodiments.
[0009] FIG. 4 is a block diagram of an apparatus according to some
embodiments.
[0010] FIG. 5 is a portion of a tabular representation of a
transaction database according to some embodiments.
[0011] FIG. 6 is a portion of a tabular representation of a rules
database according to some embodiments.
[0012] FIG. 7 is an illustrative user interface that may be used
according to some embodiments.
[0013] FIG. 8 is a further illustrative user interface that may be
used according to some embodiments.
DETAILED DESCRIPTION
[0014] To alleviate problems inherent in the prior art, the present
invention introduces systems and methods wherein a user may be
authenticated substantially in real-time and in the course of a
registration transaction.
[0015] Some embodiments of the present invention are associated
with a "user" who is seeking to access a product or service in
which the user's identity (or information associated with the user)
requires authentication. As used herein, the term "user" might
refer to, for example, a person (or entity) who executes
transactions with merchants or service providers. As used herein,
the term "user account" might refer to, for example, any financial
account associated with or controlled by the user to perform
financial transactions. For example, a user account might be a bank
account, a credit card account, a debit card account, a prepaid
account, a loan account, or the like. As used herein, the term
"historical transactions" might refer to, for example, any
transactions conducted by the user involving the user account. For
example, a user having a credit card account may have a number of
historical transactions (or transactions which were conducted using
the credit card account) in any given time period. These, and
other, terms will be used to describe features of some embodiments
of the present invention by reference to the following detailed
description of the invention, the appended claims and the drawings
provided herewith.
[0016] For purposes of illustrating features of some embodiments of
the present invention, a simple example will now be introduced and
referenced throughout the disclosure. In the illustrative example,
a customer (named "John Doe") wishes to sign up for a money
transfer service so that he can easily send money to a relative in
the Philippines. John Doe has a bank account at his local bank, and
he has a MasterCard branded credit card that is issued by his bank
and that he uses frequently for purchases. The money transfer
service that John wishes to sign up for uses the authentication
techniques of the present invention. The money transfer service
provider is called "Money Transfer Co.", and Money Transfer Co. has
engaged the services of an authentication service called
"Authentication Co." which offers authentication services pursuant
to the present invention. Money Transfer Co. requires that all
users who wish to send funds using Money Transfer Co.'s services
register an active bank account or credit card account so that
funds can be debited from one of those accounts to fund any money
transfers initiated by the user. John Doe wants to send money to
his relative quickly, and chooses to register his credit card
account so that Money Transfer Co. can debit funds from John's
credit card account to make the transfer. In the following detailed
description, we will refer to this illustrative example to show how
John, Money Transfer Co., and Authentication Co. use features of
the present invention to authenticate John's account so that it can
be quickly linked and used to conduct transactions. Those skilled
in the art will recognize that this example is illustrative and not
limiting and is provided purely for explanatory purposes.
[0017] Turning now in detail to the drawings, FIG. 1 is a block
diagram representation of a system 100 that may be provided
according to some embodiments. The system 100 includes a service
provider device 110 in communication with other devices via a
communication network 130. The service provider device 110 may be
associated with, for example, a company or service that offers
services or products to consumers and which requires users to
authenticate themselves or their ownership of a financial account
in order to obtain access to goods or services offered by the
service provider (or a entity associated with the service
provider). For example, the service provider device 110 may be
associated with an entity that provides funds transfer services and
which requires a user to provide a funding account in order to send
funds using the services. Embodiments of the present invention
allow the service provider to quickly and accurately authenticate a
new user's account so that the new user may quickly gain access to
the service provider's services.
[0018] As used herein, devices (including the service provider
device 110) may communicate, for example, via a communication
network 130 such as a Local Area Network (LAN), a Metropolitan Area
Network (MAN), a Wide Area Network (WAN), a proprietary network, a
Public Switched Telephone Network (PSTN), a Wireless Application
Protocol (WAP) network, a Bluetooth network, a cable television
network, or an Internet Protocol (IP) network such as the Internet,
an intranet or an extranet. Moreover, as used herein,
communications include those enabled by wired or wireless
technology. Although a single service provider device 110 and
communication network 130 are shown in FIG. 1, any number of such
devices and networks may be included in the system 100. Similarly,
any number of the other devices described herein may be included in
the system 100 according to embodiments of the present
invention.
[0019] The service provider device 110 might also communicate with,
for example, one or more user devices 120. For example, the service
provider device 110 might communicate (via the network) with a
remote Personal Computer (PC), laptop computer, hand-held computer,
or other computing device associated with a consumer. Although some
embodiments are described with respect to information exchanged via
a Web site, according to other embodiments information is instead
exchanged, for example, via: a telephone, an Interactive Voice
Response Unit (IVRU), electronic mail, a cable network interface,
and/or a wireless communication system. The user device 120 may be
any device capable of performing various functions described
herein. The user device 120 might be, for example, a Personal
Digital Assistant (PDA) or a wired or wireless telephone. A
consumer may use the user device 120, for example, register to
access or utilize services offered by the service provider device
110, and may also use the device 120 to complete an authentication
process pursuant to embodiments of the present invention.
[0020] According to some embodiments, the service provider device
110 also communicates with an authentication service device 160.
For example, the service provider device 110 may transmit or
forward data about the user to the authentication service device
160 so that the authentication service device 160 may operate to
authenticate the user (or the user's account). For example, the
service provider device 110 may transmit information identifying
the user and one or more user accounts (e.g., via a redirect, via
an HTTP post, or the like). The authentication service device 160
may use this information to perform look ups and other processing
(to be described further below) and may then transmit an
authentication result to the service provider device 110.
[0021] Although a separate service provider device 110 and
authentication service device 160 are shown in FIG. 1, some or all
of these devices may be incorporated in a single device. In some
embodiments, which will be described further below, the
authentication service device 160 may store, or have access to, a
historical transaction database which includes transaction data for
a large number of financial transactions. For example, in some
embodiments, the historical transaction database includes
transaction data extracted from credit card, debit card, and other
financial transactions which have been processed over a payment
network, such as the MasterCard.RTM. International Incorporated
BankNet.RTM. payment network. In some embodiments, the
authentication service device 160 has access to payment data from
one or more payment networks, thereby increasing the number and
type of user accounts that can be authenticated. Further details of
a historical transaction database which may be used in some
embodiments will be provided below in conjunction with a discussion
of FIG. 5.
[0022] In the illustrative example introduced above, John Doe may
operate a user device 120 to interact with Money Transfer Co. (who
operates service provider device 110). Money Transfer Co. may
provide a registration Web site that John Doe interacts with over
the Internet to sign up and conduct the registration process.
During the registration process, John Doe may be asked to link or
associate a funding account to his new account with Money Transfer
Co. so that money transfers can be funded from the funding account.
Pursuant to some embodiments, the linking or registration of the
account may require authentication, or proof, that John owns the
account he is trying to link. In the illustrative example, John
chooses to link his MasterCard.RTM. credit card to his new account
at Money Transfer Co. This linking requires authentication that
John actually owns or controls the MasterCard.RTM. credit card he
is trying to link. Money Transfer Co., using the services provided
by Authentication Co., uses features of the present invention to
authenticate the ownership.
[0023] FIG. 2 is a block diagram of an authentication service
device 200, such as the device 160 described with respect to FIG.
1, according to some embodiments. In this case, the authentication
service device 200 includes a communication port 210 to exchange
data over a network to facilitate communication with, for example,
other devices (such as service provider devices 110 and user
devices 120). Note that numerous ports 210 may be provided (to
allow for simultaneous communication with a number of other
devices) and may be preferably configured with hardware suitable to
physically interface with desired external devices and/or network
connections. For example, the communication port 210 may comprise
an Ethernet connection to a local area network through which the
authentication service device 200 may receive and transmit
information over the Internet and/or over private or proprietary
networks.
[0024] In addition, the authentication service device 200 includes
a query engine 220 and a verification engine 240 that may be
constituted by one or more conventional processors. The engines
220, 240 operate to execute processor-executable process steps so
as to control the authentication service device 200 to provide
desired functionality. The authentication service device 200
further includes a storage device 230 to store transaction history
information. Note that the engines 220, 240 and storage device 230
may be co-located with, or remote from, the authentication service
device 200.
[0025] The authentication service device 200 may operate in
accordance with any of the embodiments described herein. By way of
example only, FIG. 3 is a flow chart that illustrates a method that
may be performed according to some embodiments. The flow charts in
FIG. 3 and the other figures described herein do not imply a fixed
order to the steps, and embodiments of the present invention can be
practiced in any order that is practicable. Moreover, the methods
may be performed by any of the devices described herein. The method
shown in FIG. 3 may be performed, for example, by the service
provider device 110 of FIG. 1 and/or the authentication service
device 200 of FIG. 2. Note that the elements of FIG. 3 and the
other FIGS. described herein may be performed by different parties.
For example, each element might be performed by a different party
(e.g., by a service provider, by an authentication service, by a
financial institution, by a payment association, or any other agent
or party). Moreover, any single element might be performed by
multiple parties.
[0026] The authentication process 300 of FIG. 3 may begin at 302,
where a user has submitted a registration request. Referring again
to the illustrative example introduced above, processing at 302
occurs once John Doe (interacting with the Money Transfer Co.
Website) has requested that his MasterCard.RTM. credit card be
linked to his new Money Transfer Co. account. Processing at 302
involves receiving an account number from the user. In the
illustrative example, John Doe provides the primary account number
(or "PAN") from his MasterCard.RTM. credit card (e.g., the 16-digit
number embossed or printed on the face of John's card). This
information may be provided to the service provider device 110
which may then forward or redirect the information to the
authentication service device 160 for processing.
[0027] At 304, the authentication service device 160 creates a
query using the account number provided at 302. In some
embodiments, the query is a date-based query defined based on
business rules (or, in some embodiments, based on information
provided by the user). For example, the query created may be to
retrieve all transactions involving the account number over the
past 2 weeks. Referring to the illustrative example, the query may
be to retrieve all of the transactions conducted using John Doe's
MasterCard.RTM. credit card over the last two weeks. A number of
other query types may also be used to retrieve transactions made
using the user's account (as will be described further below, it is
desirable to retrieve one or more transactions that may be
identified by the legitimate account owner so that the user can
authenticate that he owns the account), for example, transactions
conducted during a certain time period may be retrieved,
transactions conducted at particular types of merchants may be
retrieved, etc.
[0028] At 306, the transaction database is searched to identify
transaction(s) that match the query parameters. For example,
referring to the device of FIG. 2, processing at 306 may be
performed by the authentication service device 200 by applying the
query (generated at the query engine 220) to the transaction
history database 230. Continuing the illustrative example
introduced above, processing at 306 may involve searching for
transactions involving John Doe's MasterCard.RTM. credit card over
the last two weeks. In some embodiments, if the initial query
results in no (or too few) transaction records, a second, expanded
query may be attempted (e.g., over a larger span of time,
etc.).
[0029] Processing continues at 308 where the matching transactions
are extracted and are used to create a user authentication form or
user interface. In some embodiments, this is performed under
control of the authentication service device 200 which is in
communication with the user device 120 over a network (e.g., the
authentication service device 200 may be in direct communication
with the user device 120 or may be in communication with a browser
of the user device 120 via an iFrame or other HTML code hosted on a
server associated with the service provider device 110. The
authentication service device 200 may generate a dynamic HTML form
using the historical transaction data retrieved from the historical
transaction database 230 and based on rules established by the
service provider. For example, each service provider 110 may
require that their forms be presented and validated according to
different rules (e.g., with different headers, different
requirements for the number of transactions to be presented,
etc.).
[0030] Examples of user authentication forms generated at 308 are
shown in FIGS. 7 and 8. Referring first to FIG. 7, a user interface
700 is shown which includes a header area 702, and a form area 704.
The form area 704 includes a table of historical transactions
conducted by a user who is attempting to register for a service
with a service provider. Each of the transactions include data
retrieved from the historical transaction database 230 based on an
account number provided by the user. In the illustrated user
interface, information from five transactions are shown, with the
transaction amount information for three of the transactions left
blank. Pursuant to some embodiments, a user must enter the missing
data at 708 to be authenticated.
[0031] In the user interface 800 of FIG. 8, a slightly different
user authentication form is shown in which the same transaction
details are shown, but all of the transaction amount information is
filled out. In the form shown in FIG. 8, the user is prompted to
provide the missing data at 808 (the names of two merchants).
[0032] Referring again to the illustrative example introduced
above, processing at 308 involves John Doe being presented with a
user authentication form which includes transaction data from
transactions conducted using John Doe's MasterCard.RTM. credit
card. John Doe must provide the missing data (such as the missing
transaction amount data 708 in the form of FIG. 7, or the missing
merchant name data 808 in the form of FIG. 8) in order to
successfully prove that he is the owner of the MasterCard.RTM.
credit card that he is attempting to register for use in the money
transfer program.
[0033] Processing continues at 310 after the user clicks "submit"
or otherwise submits her response to the user authentication form.
Processing at 310 includes receiving the user entered data and
determining whether to authenticate the user. This determination
may be performed by the authentication service device 200 using the
verification engine 240 to apply one or more verification rules
which may be specified by individual service providers. For
example, pursuant to some embodiments, a service provider may set
variance thresholds to allow for some inaccuracy in data entered by
the user. For example, a service provider may specify that a user
must enter transaction amounts that are accurate to +/-5% (or
+/-10%). Those skilled in the art will appreciate that other
variances or rules may also be specified to account for a user's
vague memory about certain transactions. If the user submitted data
passes the verification rules, the user is consider to be
authenticated and a "success" message may be transmitted to the
service provider device 110. In some embodiments, session control
may be returned to the service provider device 110 so that the
service provider device can complete the registration process with
the user.
[0034] FIG. 4 is a block diagram of an apparatus 400 that may be
descriptive of the devices shown in FIGS. 1 and/or 2 according to
an embodiment of the present invention. The apparatus 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 service provider device 110 and/or user devices 120.
[0035] The processor 410 may also be in communication with a local
input device (not shown in FIG. 4). The local input device may
comprise, for example, a keyboard, a mouse or other pointing
device, a switch, an infrared port, a docking station, and/or a
touch screen. Such a local input device may be used, for example,
to provide rules and threshold values associated with
authentication rules (e.g., established or specified by service
providers using the authentication service), or to perform
maintenance or modification of queries or interfaces to obtain
transaction history data. The processor 410 may also be in
communication with a local output device (not shown in FIG. 4). The
local output device may comprise, for example, a display (e.g., a
computer monitor), a speaker, and/or a printer. The local output
device may be used, for example, to generate reports and/or export
information to be used to generate authentication rules or
procedures.
[0036] 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.
[0037] The storage device 430 stores a program 415 for controlling
the processor 410. The program 415 may be stored in a compressed,
uncompiled and/or encrypted format. The program 415 may furthermore
include other program elements, such as an operating system, a
database management system, and/or device drivers used by the
processor 410 to interface with peripheral devices.
[0038] The processor 410 performs instructions of the program 415,
and thereby operates in accordance with the present invention. For
example, the processor 410 may receive data associated with a user
to be authenticated, and then use that data to query a transaction
history database, and then present the data to the user in an
interactive form according to the rules from the authentication
rules database. The processor 410 may further arrange to transfer a
success or fail message to the service provider so that the service
provider device 110 may proceed accordingly.
[0039] As used herein, information may be "received" by or
"transmitted" to, for example: (i) the apparatus 400 from remote
device; or (ii) a software application or module within the
apparatus 400 from another software application, module, or any
other source.
[0040] As shown in FIG. 4, the storage device 430 also stores a
transaction history database 500 (described with respect to FIG. 5)
and a authentication rules database 600 (described with respect to
FIG. 6). Examples of databases that may be used in connection with
the apparatus 400 will now be described in detail with respect to
FIGS. 5 and 6.
[0041] Note that the illustrations and accompanying descriptions of
the databases 500 and 600 presented herein are exemplary, and any
number of other database arrangements could be employed besides
those suggested by the figures. For example, as will be understood
by those skilled in the art, the schematic illustrations shown
herein and the following descriptions of the exemplary entries are
merely examples of arrangements for stored representations of
information. Any number of other arrangements may be employed
besides that suggested by the tables shown. Similarly, the
illustrated entries of the databases represent exemplary
information only.
[0042] In a practical embodiment, the number of entries in the
various databases may be in the thousands, or even in the millions.
Moreover, for convenience of presentation, some databases are shown
as having only several fields. However, in practice additional
fields may be present, such as other fields for additional consumer
contact information, transaction information, etc. Moreover, the
various databases may generally be integrated with other databases
used for other purposes in addition to those described herein.
Also, note that the information stored in the database 500, 600 may
be stored by (or at) and/or accessed by any number of different
parties or locations (e.g., by an issuer, an account processor,
and/or any other agent or party). For example a transaction history
database 500 might be partially stored at a bankcard network and
partially stored on an authentication service provider's system
(and, when combined, form the complete transaction history database
500).
[0043] FIG. 5 is a portion of a tabular representation of a
transaction history database 500 that may be stored at the
apparatus 400 according to an embodiment of the present invention.
The table includes entries identifying a number of completed (or
historical) transactions conducted with various payment accounts.
The table also defines fields 502, 504, 506, 508, 510, 512 for each
of the entries. The fields specify: an account identifier 502; an
account owner 504; a transaction identifier 506; a transaction date
508; a merchant 510; a merchant category 512 and a transaction
amount 514. The information in the historical transaction database
500 may be created and updated, for example, based on information
received from one or more payment processing networks or systems
based on transactions conducted by consumers using those networks
or systems.
[0044] The account identifier 502 may be, for example, an
alphanumeric code associated with a particular payment account
(e.g., in the case of a credit card or other payment card, the
account identifier may be the PAN associated with the account). The
account owner 504 may include information identifying the owner of
the account identified in 502. The transaction identifier 506 may
be an alphanumeric code uniquely identifying a particular
transaction conducted using the payment account identified by the
account identifier 502, and the transaction date 508, merchant 510,
merchant category 512 and transaction amount 514 may be the details
of the transaction identified by the transaction identifier 506.
The transaction details may be the details received from a merchant
point of sale location during a purchase transaction involving the
account, for example, and may include additional or other
information depending on the nature of the transaction, or on the
payment network used to obtain the information.
[0045] FIG. 6 is a portion of a tabular representation of an
authentication rules database 600 that may be stored at the
apparatus 400 according to an embodiment of the present invention.
The table includes entries identifying one or more rules to be
applied by the authentication service device 160 to authenticate
users on behalf of one or more service providers. In this manner,
an authentication service device 160 may perform authentication
services on behalf of more than one service provider, and each
service provider 110 may specify different authentication rules.
The table also defines fields 602, 604, 606, 608, 610, 612 and 614
for each of the entries. The fields specify: a service provider
identifier 602; a web form identifier 604; a required minimum
number of transactions 606; a query date range 608; an allowable
variance 610; a number of retry(s) 612, and a redirect URL 614. The
information in the authentication rules database 600 may be created
and updated, for example, based on information received from
service provider devices 110.
[0046] The service provider identifier 602 may be, for example, an
alphanumeric code associated with a particular service provider
that seeks to use authentication services provided by the
authentication service. The web form identifier 604 may be a URL or
other address specifying which web form is to be used to present
the authentication questions to the user. Each service provider may
have one or more web forms (which, for example, may be customized
to include the service provider's logo and specific rules and
instructions) that are used to present authentication questions to
users who are being authenticated. In some embodiments, the
authentication service device 160 may look up the appropriate web
form identifier when a request to authenticate a user is
received.
[0047] The minimum number of transactions 606 specifies the number
of transactions that must be retrieved for each user and each
account to be authenticated (e.g., if a service provider wants at
least 5 historical transactions to be retrieved, the query created
by the authentication service device will be designed to retrieve
at least 5 queries associated with a user's account). Similarly,
service providers may specify a desired date range to be retrieved
by specifying a query date range 608. In some embodiments, a
service provider may specify that the user being authenticated may
specify a preferred date range. An allowable variance 610 may be
specified to indicate how precise the user must be in her
authentication response (e.g., a variance or threshold may be
acceptable).
[0048] A number of retry(s) 612 may also be specified in the event
a user fails the first authentication process. In the event of a
success or failure, one or more redirect URLs 614 may be specified,
so that control may be returned to the service provider after the
authentication process has completed.
[0049] In this manner, embodiments allow a user to be authenticated
substantially in real-time and during the course of a registration
transaction. Embodiments allow service providers (who have a need
to authenticate users) with an accurate and controlled means of
authenticating users with a high degree of precision.
[0050] Although embodiments have been described in which users are
presented with an accurate list of transactions (some of which may
have redacted fields to be entered by the user), other embodiments
may be provided in which one or more fields (or entire
transactions) are bogus or made up. For example, the user may be
asked to fill in the missing data for one or more actual
transactions, and also to identify (or leave blank) the fields
associated with bogus transactions. In some embodiments, the bogus
transactions are randomly selected from a list of top merchants or
from a list of likely bogus transactions. In such embodiments, the
level of authentication may be increased, as the user is required
to identify negative information as well as provide positive
information.
[0051] In some embodiments, a user may be queried for additional
information prior to identifying a set of transactions. For
example, a user may be asked if they save or have transaction
receipts (or have access to them). The user may be able to select a
preferred time period in which he or she will be most likely able
to accurately identify past transaction data. The system may then
present only transactions falling within that preferred time period
so that the user may have a greater chance to accurately identify
all missing information during that period.
[0052] In some embodiments, the authentication system may present
the user with a challenge list of historical transactions with both
correct and incorrect transaction amounts. Bogus transactions may
also be added to the challenge list and the user may then be asked
to identify which transactions were initiated by the user (e.g., by
clicking or selecting those transactions). Such embodiments may not
require the user to enter an actual transaction amount, but simply
select between invalid and valid transactions.
[0053] Embodiments allow the authentication of a user,
substantially in real time, during a registration process. Further,
embodiments allow such authentication to be performed for an entity
(such as a service provider) which has no prior or direct business
relationship with the user. The system authenticates that the user
has access and control over an account purported to be their
account with a minimal amount of information that needs to be
provided by the user during the registration process (e.g., in some
embodiments, all that is required is an account number). The system
avoids the need to wait for further authentication, allowing a user
to quickly access network services, and allowing a service provider
to safely authenticate a user prior to providing access.
[0054] 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.
* * * * *