US20130346313A1 - Methods and systems for user authentication - Google Patents
Methods and systems for user authentication Download PDFInfo
- Publication number
- US20130346313A1 US20130346313A1 US13/975,874 US201313975874A US2013346313A1 US 20130346313 A1 US20130346313 A1 US 20130346313A1 US 201313975874 A US201313975874 A US 201313975874A US 2013346313 A1 US2013346313 A1 US 2013346313A1
- Authority
- US
- United States
- Prior art keywords
- user
- authentication
- transaction
- transactions
- history database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2101—Auditing as a secondary aspect
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2151—Time stamp
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2153—Using hardware token as a secondary aspect
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
Definitions
- the present invention relates to user authentication.
- 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.
- FIG. 1 is a block diagram representation of a system that may be provided according to some embodiments.
- FIG. 2 is a block diagram of an authentication service device according to some embodiments.
- FIG. 3 is a flow chart that illustrates a method that may be performed according to some embodiments.
- FIG. 4 is a block diagram of an apparatus according to some embodiments.
- FIG. 5 is a portion of a tabular representation of a transaction database according to some embodiments.
- FIG. 6 is a portion of a tabular representation of a rules database according to some embodiments.
- FIG. 7 is an illustrative user interface that may be used according to some embodiments.
- FIG. 8 is a further illustrative user interface that may be used according to some embodiments.
- 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.
- 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.
- the term “user” might refer to, for example, a person (or entity) who executes transactions with merchants or service providers.
- the term “user account” might refer to, for example, any financial account associated with or controlled by the user to perform financial transactions.
- 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.
- historical transactions might refer to, for example, any transactions conducted by the user involving the user account.
- 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.
- 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.
- 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).
- 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.
- devices 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.
- 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.
- IP Internet Protocol
- communications include those enabled by wired or wireless technology.
- the service provider device 110 might also communicate with, for example, one or more user devices 120 .
- 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.
- PC Personal Computer
- IVRU Interactive Voice Response Unit
- 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.
- PDA Personal Digital Assistant
- 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.
- the service provider device 110 also communicates with an authentication service device 160 .
- 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).
- 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 .
- 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.
- 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® International Incorporated BankNet® payment network.
- 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 .
- 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.
- 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.
- the linking or registration of the account may require authentication, or proof, that John owns the account he is trying to link.
- John chooses to link his MasterCard® credit card to his new account at Money Transfer Co. This linking requires authentication that John actually owns or controls the MasterCard® 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.
- 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.
- 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 ).
- 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.
- 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.
- 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 .
- 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.
- 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 .
- 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).
- any single element might be performed by multiple parties.
- the authentication process 300 of FIG. 3 may begin at 302 , where a user has submitted a registration request.
- processing at 302 occurs once John Doe (interacting with the Money Transfer Co. Website) has requested that his MasterCard® credit card be linked to his new Money Transfer Co. account.
- Processing at 302 involves receiving an account number from the user.
- John Doe provides the primary account number (or “PAN”) from his MasterCard® 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.
- PAN primary account number
- the authentication service device 160 creates a query using the account number provided at 302 .
- the query is a date-based query defined based on business rules (or, in some embodiments, based on information provided by the user).
- the query created may be to retrieve all transactions involving the account number over the past 2 weeks.
- the query may be to retrieve all of the transactions conducted using John Doe's MasterCard® 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.
- 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® 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.).
- 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.).
- FIGS. 7 and 8 Examples of user authentication forms generated at 308 are shown in FIGS. 7 and 8 .
- 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.
- 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.
- the user is prompted to provide the missing data at 808 (the names of two merchants).
- 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® 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® credit card that he is attempting to register for use in the money transfer program.
- 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.
- a “success” message may be transmitted to the service provider device 110 .
- 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.
- 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® Pentium® 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 .
- 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.
- 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.
- 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.
- RAM Random Access Memory
- ROM Read Only Memory
- 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.
- the processor 410 performs instructions of the program 415 , and thereby operates in accordance with the present invention.
- 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.
- 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.
- 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 .
- 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 ).
- 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.
- 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.
- 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 .
- 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.
- the authentication service device 160 may look up the appropriate web form identifier when a request to authenticate a user is received.
- 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).
- service providers may specify a desired date range to be retrieved by specifying a query date range 608 .
- 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).
- a number of retry(s) 612 may also be specified in the event a user fails the first authentication process.
- 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.
- 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.
- 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.
- the bogus transactions are randomly selected from a list of top merchants or from a list of likely bogus transactions.
- the level of authentication may be increased, as the user is required to identify negative information as well as provide positive information.
- 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.
- 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.
- 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.
- entity such as a service provider
- 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.
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.
Description
- 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.
- 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.
- 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®). As another example, a user may wish to associate their checking account with a service (such as a rewards system, PayPal® 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.
- A number of techniques have been used for such authentication. For example, when a PayPal® 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).
- 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.
-
FIG. 1 is a block diagram representation of a system that may be provided according to some embodiments. -
FIG. 2 is a block diagram of an authentication service device according to some embodiments. -
FIG. 3 is a flow chart that illustrates a method that may be performed according to some embodiments. -
FIG. 4 is a block diagram of an apparatus according to some embodiments. -
FIG. 5 is a portion of a tabular representation of a transaction database according to some embodiments. -
FIG. 6 is a portion of a tabular representation of a rules database according to some embodiments. -
FIG. 7 is an illustrative user interface that may be used according to some embodiments. -
FIG. 8 is a further illustrative user interface that may be used according to some embodiments. - 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.
- 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.
- 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.
- Turning now in detail to the drawings,
FIG. 1 is a block diagram representation of asystem 100 that may be provided according to some embodiments. Thesystem 100 includes aservice provider device 110 in communication with other devices via acommunication network 130. Theservice 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, theservice 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. - 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 singleservice provider device 110 andcommunication network 130 are shown inFIG. 1 , any number of such devices and networks may be included in thesystem 100. Similarly, any number of the other devices described herein may be included in thesystem 100 according to embodiments of the present invention. - The
service provider device 110 might also communicate with, for example, one ormore user devices 120. For example, theservice 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. Theuser device 120 may be any device capable of performing various functions described herein. Theuser device 120 might be, for example, a Personal Digital Assistant (PDA) or a wired or wireless telephone. A consumer may use theuser device 120, for example, register to access or utilize services offered by theservice provider device 110, and may also use thedevice 120 to complete an authentication process pursuant to embodiments of the present invention. - According to some embodiments, the
service provider device 110 also communicates with anauthentication service device 160. For example, theservice provider device 110 may transmit or forward data about the user to theauthentication service device 160 so that theauthentication service device 160 may operate to authenticate the user (or the user's account). For example, theservice 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). Theauthentication 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 theservice provider device 110. - Although a separate
service provider device 110 andauthentication service device 160 are shown inFIG. 1 , some or all of these devices may be incorporated in a single device. In some embodiments, which will be described further below, theauthentication 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® International Incorporated BankNet® payment network. In some embodiments, theauthentication 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 ofFIG. 5 . - 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® credit card to his new account at Money Transfer Co. This linking requires authentication that John actually owns or controls the MasterCard® 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. -
FIG. 2 is a block diagram of anauthentication service device 200, such as thedevice 160 described with respect toFIG. 1 , according to some embodiments. In this case, theauthentication service device 200 includes acommunication port 210 to exchange data over a network to facilitate communication with, for example, other devices (such asservice provider devices 110 and user devices 120). Note thatnumerous 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, thecommunication port 210 may comprise an Ethernet connection to a local area network through which theauthentication service device 200 may receive and transmit information over the Internet and/or over private or proprietary networks. - In addition, the
authentication service device 200 includes aquery engine 220 and averification engine 240 that may be constituted by one or more conventional processors. Theengines authentication service device 200 to provide desired functionality. Theauthentication service device 200 further includes astorage device 230 to store transaction history information. Note that theengines storage device 230 may be co-located with, or remote from, theauthentication service device 200. - 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 inFIG. 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 inFIG. 3 may be performed, for example, by theservice provider device 110 ofFIG. 1 and/or theauthentication service device 200 ofFIG. 2 . Note that the elements ofFIG. 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. - 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® 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® credit card (e.g., the 16-digit number embossed or printed on the face of John's card). This information may be provided to theservice provider device 110 which may then forward or redirect the information to theauthentication service device 160 for processing. - 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® 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. - 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 theauthentication service device 200 by applying the query (generated at the query engine 220) to thetransaction history database 230. Continuing the illustrative example introduced above, processing at 306 may involve searching for transactions involving John Doe's MasterCard® 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.). - 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 theuser device 120 over a network (e.g., theauthentication service device 200 may be in direct communication with theuser device 120 or may be in communication with a browser of theuser device 120 via an iFrame or other HTML code hosted on a server associated with theservice provider device 110. Theauthentication service device 200 may generate a dynamic HTML form using the historical transaction data retrieved from thehistorical transaction database 230 and based on rules established by the service provider. For example, eachservice 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.). - Examples of user authentication forms generated at 308 are shown in
FIGS. 7 and 8 . Referring first toFIG. 7 , auser interface 700 is shown which includes aheader area 702, and aform area 704. Theform 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 thehistorical 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. - In the
user interface 800 ofFIG. 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 inFIG. 8 , the user is prompted to provide the missing data at 808 (the names of two merchants). - 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® credit card. John Doe must provide the missing data (such as the missing
transaction amount data 708 in the form ofFIG. 7 , or the missingmerchant name data 808 in the form ofFIG. 8 ) in order to successfully prove that he is the owner of the MasterCard® credit card that he is attempting to register for use in the money transfer program. - 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 theverification 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 theservice provider device 110. In some embodiments, session control may be returned to theservice provider device 110 so that the service provider device can complete the registration process with the user. -
FIG. 4 is a block diagram of anapparatus 400 that may be descriptive of the devices shown inFIGS. 1 and/or 2 according to an embodiment of the present invention. Theapparatus 400 comprises aprocessor 410, such as one or more INTEL® Pentium® processors, coupled to acommunication device 420 configured to communicate via a communication network (not shown inFIG. 4 ). Thecommunication device 420 may be used to communicate, for example, withservice provider device 110 and/oruser devices 120. - The
processor 410 may also be in communication with a local input device (not shown inFIG. 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. Theprocessor 410 may also be in communication with a local output device (not shown inFIG. 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. - The
processor 410 is also in communication with astorage device 430. Thestorage 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. - The
storage device 430 stores aprogram 415 for controlling theprocessor 410. Theprogram 415 may be stored in a compressed, uncompiled and/or encrypted format. Theprogram 415 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by theprocessor 410 to interface with peripheral devices. - The
processor 410 performs instructions of theprogram 415, and thereby operates in accordance with the present invention. For example, theprocessor 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. Theprocessor 410 may further arrange to transfer a success or fail message to the service provider so that theservice provider device 110 may proceed accordingly. - 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 theapparatus 400 from another software application, module, or any other source. - As shown in
FIG. 4 , thestorage device 430 also stores a transaction history database 500 (described with respect toFIG. 5 ) and a authentication rules database 600 (described with respect toFIG. 6 ). Examples of databases that may be used in connection with theapparatus 400 will now be described in detail with respect toFIGS. 5 and 6 . - Note that the illustrations and accompanying descriptions of the
databases - 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 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). -
FIG. 5 is a portion of a tabular representation of atransaction history database 500 that may be stored at theapparatus 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 definesfields account identifier 502; anaccount owner 504; atransaction identifier 506; atransaction date 508; amerchant 510; amerchant category 512 and atransaction amount 514. The information in thehistorical 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. - 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). Theaccount owner 504 may include information identifying the owner of the account identified in 502. Thetransaction identifier 506 may be an alphanumeric code uniquely identifying a particular transaction conducted using the payment account identified by theaccount identifier 502, and thetransaction date 508,merchant 510,merchant category 512 andtransaction amount 514 may be the details of the transaction identified by thetransaction 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. -
FIG. 6 is a portion of a tabular representation of anauthentication rules database 600 that may be stored at theapparatus 400 according to an embodiment of the present invention. The table includes entries identifying one or more rules to be applied by theauthentication service device 160 to authenticate users on behalf of one or more service providers. In this manner, anauthentication service device 160 may perform authentication services on behalf of more than one service provider, and eachservice provider 110 may specify different authentication rules. The table also definesfields service provider identifier 602; aweb form identifier 604; a required minimum number of transactions 606; aquery date range 608; anallowable variance 610; a number of retry(s) 612, and aredirect URL 614. The information in theauthentication rules database 600 may be created and updated, for example, based on information received fromservice provider devices 110. - 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. Theweb 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, theauthentication service device 160 may look up the appropriate web form identifier when a request to authenticate a user is received. - 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. Anallowable 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). - 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. - 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Claims (19)
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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/975,874 US20130346313A1 (en) | 2009-08-14 | 2013-08-26 | Methods and systems for user authentication |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/541,464 US8572704B2 (en) | 2009-08-14 | 2009-08-14 | Methods and systems for user authentication |
US13/975,874 US20130346313A1 (en) | 2009-08-14 | 2013-08-26 | Methods and systems for user authentication |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/541,464 Continuation US8572704B2 (en) | 2009-08-14 | 2009-08-14 | Methods and systems for user authentication |
Publications (1)
Publication Number | Publication Date |
---|---|
US20130346313A1 true US20130346313A1 (en) | 2013-12-26 |
Family
ID=43589377
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/541,464 Active 2031-10-04 US8572704B2 (en) | 2009-08-14 | 2009-08-14 | Methods and systems for user authentication |
US13/975,874 Abandoned US20130346313A1 (en) | 2009-08-14 | 2013-08-26 | Methods and systems for user authentication |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/541,464 Active 2031-10-04 US8572704B2 (en) | 2009-08-14 | 2009-08-14 | Methods and systems for user authentication |
Country Status (1)
Country | Link |
---|---|
US (2) | US8572704B2 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015108659A1 (en) * | 2014-01-19 | 2015-07-23 | Mastercard International Incorporated | Method and system for virtual account number-based travel expense controls and accounting |
WO2015160686A1 (en) * | 2014-04-14 | 2015-10-22 | Mastercard International Incorporated | Systems, apparatus and methods for improved authentication |
US20170024740A1 (en) * | 2015-07-24 | 2017-01-26 | Paypal, Inc. | Automatic authentication for a user with a service provider during a voice data connection to a merchant |
US11049101B2 (en) * | 2017-03-21 | 2021-06-29 | Visa International Service Association | Secure remote transaction framework |
US11321707B2 (en) | 2016-03-22 | 2022-05-03 | Visa International Service Association | Adaptable authentication processing |
US20220405753A1 (en) * | 2021-06-17 | 2022-12-22 | Ramp Business Corporation | Rule based transaction authorization server |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9665898B2 (en) * | 2011-10-21 | 2017-05-30 | Groupon, Inc. | Executing multiple transactions using trigger inputs |
US20140108247A1 (en) | 2012-10-17 | 2014-04-17 | Groupon, Inc. | Peer-To-Peer Payment Processing |
US10235692B2 (en) | 2012-10-17 | 2019-03-19 | Groupon, Inc. | Consumer presence based deal offers |
US20140229375A1 (en) | 2013-02-11 | 2014-08-14 | Groupon, Inc. | Consumer device payment token management |
US9576286B1 (en) | 2013-03-11 | 2017-02-21 | Groupon, Inc. | Consumer device based point-of-sale |
US9852409B2 (en) | 2013-03-11 | 2017-12-26 | Groupon, Inc. | Consumer device based point-of-sale |
GB2512070A (en) * | 2013-03-19 | 2014-09-24 | Barclays Bank Plc | Online payment transaction system |
US9444804B2 (en) * | 2013-11-25 | 2016-09-13 | Roy S. Melzer | Dynamic security question generation |
US11341470B1 (en) * | 2015-03-20 | 2022-05-24 | Wells Fargo Bank, N.A. | Systems and methods for smart card online purchase authentication |
US11682016B2 (en) * | 2017-11-30 | 2023-06-20 | Mastercard International Incorporated | System to perform identity verification |
US10812460B2 (en) * | 2018-01-02 | 2020-10-20 | Bank Of America Corporation | Validation system utilizing dynamic authentication |
EP3602457B1 (en) * | 2019-02-28 | 2021-04-07 | Advanced New Technologies Co., Ltd. | System and method for blockchain-based data management |
US11244320B1 (en) * | 2019-06-26 | 2022-02-08 | Intuit Inc. | System and method for error correcting coding of billing transactions for data management system user identity verification |
US11928723B2 (en) * | 2021-07-29 | 2024-03-12 | Walmart Apollo, Llc | Systems and methods for facilitating online search based on offline transactions |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030154406A1 (en) * | 2002-02-14 | 2003-08-14 | American Management Systems, Inc. | User authentication system and methods thereof |
US7058817B1 (en) * | 1999-07-02 | 2006-06-06 | The Chase Manhattan Bank | System and method for single sign on process for websites with multiple applications and services |
US20060180660A1 (en) * | 2004-04-12 | 2006-08-17 | Gray R O | Electronic identification system |
US20070288380A1 (en) * | 2006-04-28 | 2007-12-13 | Ed Starrs | Method and apparatus for online check processing |
US20080120507A1 (en) * | 2006-11-21 | 2008-05-22 | Shakkarwar Rajesh G | Methods and systems for authentication of a user |
US20080185429A1 (en) * | 2007-02-05 | 2008-08-07 | First Data Corporation | Authentication Of PIN-Less Transactions |
US20090106134A1 (en) * | 2007-10-18 | 2009-04-23 | First Data Corporation | Applicant authentication |
US20100199338A1 (en) * | 2009-02-04 | 2010-08-05 | Microsoft Corporation | Account hijacking counter-measures |
US8151343B1 (en) * | 2007-07-30 | 2012-04-03 | Intuit Inc. | Method and system for providing authentication credentials |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7979894B2 (en) * | 2008-01-08 | 2011-07-12 | First Data Corporation | Electronic verification service systems and methods |
-
2009
- 2009-08-14 US US12/541,464 patent/US8572704B2/en active Active
-
2013
- 2013-08-26 US US13/975,874 patent/US20130346313A1/en not_active Abandoned
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7058817B1 (en) * | 1999-07-02 | 2006-06-06 | The Chase Manhattan Bank | System and method for single sign on process for websites with multiple applications and services |
US20030154406A1 (en) * | 2002-02-14 | 2003-08-14 | American Management Systems, Inc. | User authentication system and methods thereof |
US20060180660A1 (en) * | 2004-04-12 | 2006-08-17 | Gray R O | Electronic identification system |
US20070288380A1 (en) * | 2006-04-28 | 2007-12-13 | Ed Starrs | Method and apparatus for online check processing |
US20080120507A1 (en) * | 2006-11-21 | 2008-05-22 | Shakkarwar Rajesh G | Methods and systems for authentication of a user |
US20080185429A1 (en) * | 2007-02-05 | 2008-08-07 | First Data Corporation | Authentication Of PIN-Less Transactions |
US8151343B1 (en) * | 2007-07-30 | 2012-04-03 | Intuit Inc. | Method and system for providing authentication credentials |
US20090106134A1 (en) * | 2007-10-18 | 2009-04-23 | First Data Corporation | Applicant authentication |
US20100199338A1 (en) * | 2009-02-04 | 2010-08-05 | Microsoft Corporation | Account hijacking counter-measures |
Non-Patent Citations (1)
Title |
---|
In re Harza, 124 USPQ 378, 380; 274 F.2d 669 (CCPA 1960); MPEP 2144.04. * |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015108659A1 (en) * | 2014-01-19 | 2015-07-23 | Mastercard International Incorporated | Method and system for virtual account number-based travel expense controls and accounting |
WO2015160686A1 (en) * | 2014-04-14 | 2015-10-22 | Mastercard International Incorporated | Systems, apparatus and methods for improved authentication |
CN106416189A (en) * | 2014-04-14 | 2017-02-15 | 万事达卡国际股份有限公司 | Systems, apparatus and methods for improved authentication |
US20170024740A1 (en) * | 2015-07-24 | 2017-01-26 | Paypal, Inc. | Automatic authentication for a user with a service provider during a voice data connection to a merchant |
US10692083B2 (en) * | 2015-07-24 | 2020-06-23 | Paypal, Inc. | Automatic authentication for a user with a service provider during a voice data connection to a merchant |
US11321707B2 (en) | 2016-03-22 | 2022-05-03 | Visa International Service Association | Adaptable authentication processing |
US11049101B2 (en) * | 2017-03-21 | 2021-06-29 | Visa International Service Association | Secure remote transaction framework |
US20220405753A1 (en) * | 2021-06-17 | 2022-12-22 | Ramp Business Corporation | Rule based transaction authorization server |
US11869011B2 (en) * | 2021-06-17 | 2024-01-09 | Ramp Business Corporation | Rule based transaction authorization server |
Also Published As
Publication number | Publication date |
---|---|
US8572704B2 (en) | 2013-10-29 |
US20110041170A1 (en) | 2011-02-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8572704B2 (en) | Methods and systems for user authentication | |
US10657588B2 (en) | Method and system for funding a financial account | |
US10896477B2 (en) | Systems and methods for identity validation and verification | |
AU2009279704B2 (en) | Account holder demand account update | |
US8768813B2 (en) | System for electronic re-allocation of a transaction amount to an investment | |
US8261977B2 (en) | Methods and systems for using an interface and protocol extensions to perform a financial transaction | |
US20070244778A1 (en) | System and method for cash distribution and management | |
US20060089909A1 (en) | Cardless transaction system | |
AU2011207602B2 (en) | Verification mechanism | |
US20030135457A1 (en) | Method and apparatus for providing online financial account services | |
US20090228365A1 (en) | Methods and systems for managing merchant identifiers | |
US11610243B2 (en) | Systems, devices and methods for computer automated assistance for disparate networks and internet interfaces | |
US20130185207A1 (en) | Method and system for online authentication using a credit/debit card processing system | |
US10755339B2 (en) | System and method of purchase request management using plain text messages | |
US9105019B1 (en) | Method and system for depositing funds at a point of sale terminal | |
US20120116940A1 (en) | Processing loan transactions | |
KR100869132B1 (en) | Methdo for Settling Accounts Between Financial Agency and Shopping Mall | |
US20120116949A1 (en) | Processing loan transactions | |
KR20180113871A (en) | Method and system for financial goods subscription | |
WO2001084517A2 (en) | System and method for secure network transactions | |
KR20190075037A (en) | Method and system for financial goods subscription | |
KR20040051999A (en) | System for network-based instantly credit loan service and method thereof | |
KR20080065962A (en) | System for settling accounts between financial agency and shopping mall | |
CA2508842A1 (en) | Cardless transaction system | |
KR20070116369A (en) | System and method for operating game and game operating server |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |