User authentication is performed at the access control server using a mobile device.

Abstract

A method is disclosed. The method includes, after an access device receives a credential or token from a user's portable device, an access control server receiving an authentication request message including the credential or token from the access device. The method further includes, in response to receiving the authentication request message, the access control server transmitting an inquiry message to a user device associated with the user; and the access control server generating an authentication indicator. The method also includes, the access control server transmitting an authentication response message including the authentication indicator to the access device.

Description

[0001] Cross-reference to related applications

[0002] This application is a PCT application filed on March 5, 2020, with U.S. Provisional Patent Application No. 62 / 985,449, and claims priority thereto, the entire contents of which are incorporated herein by reference. Background Technology

[0003] Existing systems that allow users to access resources such as secure locations, goods or services, or secure data require these users to enter sensitive information into access devices such as access terminals. Typically, users may need to enter confidential information, such as known access codes (e.g., PIN codes), into access terminals like traffic gates, point-of-sale terminals, or kiosks. Conventional access devices are usually located at the resource provider's premises and are generally designed to securely handle any confidential information entered into them.

[0004] In recent years, many commercial off-the-shelf devices, such as mobile phones, have been used as access devices. This raises security concerns because conventional mobile devices, such as mobile phones and tablets, may not have been manufactured specifically to receive and process user confidential information. Therefore, commercial off-the-shelf devices are more vulnerable to hacking and compromise compared to conventional access devices manufactured for dedicated purposes.

[0005] Furthermore, allowing users to input secrets into the access device introduces security risks. For example, some access devices are insecure, and hackers and other unauthorized personnel could steal secrets from them. Additionally, in some cases, the heat generated by a user's fingers can remain on the keys after the user has entered secrets into the access device via the keyboard. Some people use infrared devices to identify pressed keys and thus determine the user's secrets. Similarly, inputting secrets into the access device can be problematic for other reasons as well.

[0006] The embodiments of the present invention address these and other problems respectively. Summary of the Invention

[0007] One embodiment includes a method comprising: receiving, by an access device, a credential or token from a portable device associated with a user in interaction; in response to receiving the credential or token from the portable device, transmitting, by the access device, an authentication request message including the credential or token to an access control server, the access control server transmitting an interrogation message to a user device associated with the user; receiving, by the access device, an authentication response message including an authentication indicator from the access control server; and transmitting, by the access device, an authorization request message including the authentication indicator and the credential or token to an authorization entity computer. The authorization entity computer may use the credential or token and the authentication indicator to determine whether to authorize the interaction. In some embodiments, the authentication indicator may be a password.

[0008] Another embodiment of the present invention includes an access device comprising: a processor; and a non-transitory computer-readable medium including instructions executable by the processor to cause the access device to: receive a credential or token from a portable device associated with a user in interaction; in response to receiving the credential or token from the portable device, transmit an authentication request message including the credential or token to an access control server, the access control server transmitting an interrogation message to a user device associated with the user; receive an authentication response message including an authentication indicator from the access control server; and transmit an authorization request message including the authentication indicator and the credential or token to an authorization entity computer. The authorization entity computer may use the credential or token and the authentication indicator to determine whether to authorize the interaction.

[0009] Another embodiment of the present invention includes a method comprising: after an access device receives a credential or token from a user's portable device, an access control server receiving an authentication request message including the credential or token from the access device; in response to receiving the authentication request message, the access control server transmitting an inquiry message to a user device associated with the user; the access control server obtaining an authentication indicator; and the access control server transmitting an authentication response message including the authentication indicator to the access device.

[0010] Another embodiment of the present invention includes an access control server comprising a processor and a computer-readable medium coupled to the processor. The computer-readable medium includes instructions that, when executed by the processor, cause the access control server to: receive an authentication request message including the credential or token from the access device after the access device receives a credential or token from a user's portable device; transmit an inquiry message to a user device associated with the user in response to receiving the authentication request message; obtain an authentication indicator; and transmit an authentication response message including the authentication indicator to the access device.

[0011] These and other embodiments of the invention are described in further detail below. Attached Figure Description

[0012] Figure 1 A block diagram of a system having a flowchart according to an embodiment is shown.

[0013] Figure 2 A block diagram of another system having another flowchart according to another embodiment is shown.

[0014] Figure 3 A block diagram of a user device according to an embodiment is shown.

[0015] Figure 4 A block diagram of an access device according to an embodiment is shown.

[0016] Figure 5 A block diagram of an access control server according to an embodiment is shown. Detailed Implementation

[0017] Before discussing the embodiments, some terms can be described in detail.

[0018] "User" may include an individual or computing device. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may be a cardholder, account holder, or consumer.

[0019] A “user device” can be any suitable device that a user can interact with (e.g., a payment card or a mobile phone). A user device can take any suitable form. Some examples of user devices include cards with magnetic stripes or contactless elements (e.g., payment cards such as debit cards, credit cards, and prepaid cards), cellular phones, PDAs, personal computers (PCs), tablet computers, etc. In some embodiments where the user device is a mobile device, the mobile device may include a display, memory, processor, computer-readable medium, and any other suitable components. In some embodiments, the user device may include a portable device. For example, a user device can be a mobile phone that can also perform the functions of a portable device, such as a payment device.

[0020] A “mobile device” (sometimes referred to as a mobile communication device) can include any electronic device that a user can transport or operate, and that may also provide the ability to communicate remotely with a network. A mobile communication device can communicate using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that provides access to networks such as the Internet or a private network. Examples of mobile devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, netbooks, laptops, wearable devices (e.g., watches), vehicles such as cars and motorcycles, personal music players, handheld dedicated readers, etc. A mobile device can include any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., two devices used together may be considered a single mobile device when the device remotely accesses a network by sharing the network with another device (i.e., using said other device as a modem)).

[0021] "Contactless" communication can be communication that exchanges data between two devices without the two devices being physically coupled. Without limiting the generality of the foregoing, "contactless" communication can include data transmission via near field communication (NFC) transceivers, laser, radio frequency, infrared communication, or other radio frequency or wireless communication protocols such as Bluetooth, Bluetooth Low Energy (BLE), Wi-Fi, iBeacon, etc.

[0022] An "application" can be a computer program used for a specific purpose. Examples of applications may include transportation applications, secure data access applications, banking applications, digital wallet applications, event ticketing applications, loyalty reward applications, and so on. In some embodiments, an application may be associated with a user account (e.g., a bank account, a public transportation prepaid account, a building access account, etc.) maintained by a resource or service provider.

[0023] An "access device" can be any suitable device for providing access to an external computer system. Access devices can take any suitable form. Some examples of access devices include point-of-sale (POS) devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, websites, and so on. Access devices can use any suitable contact or contactless operating mode to send or receive data to or associate with a mobile device. In some embodiments where the access device may include a POS terminal, any suitable POS terminal can be used, and it may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a mobile device.

[0024] "Access data" can include any suitable data that can be used to access resources or create data that allows access to resources. In some embodiments, access data can be account information for a payment account. Account information can include a PAN, payment token, expiration date, and verification value (e.g., CVV, CVV2, dCVV, dCVV2), etc. In other embodiments, access data can be data that can be used to activate account data. For example, in some cases, account information can be stored on a mobile device but may not be activated until the mobile device receives specific information. In other embodiments, access data can include data that can be used to access a location. Such access data can be event ticket information, data for accessing buildings, transportation ticket information, etc. In other embodiments, access data can include data for obtaining access to sensitive data. Examples of access data can include code or other data required by a server computer to grant access to sensitive data.

[0025] "Authentication data" can include any data suitable for authenticating a user or mobile device. Authentication data can be obtained from the user or the device operated by the user. Examples of authentication data obtained from a user can include confidential information such as a personal identification number (PIN), biometric data, passwords, etc. Examples of authentication data that can be obtained from a device can include device serial numbers, hardware secure element identifiers, device fingerprints, phone numbers, IMEI numbers, etc.

[0026] "Confidential" can be information that others do not know or cannot see. Confidentiality may be known only to the user. For example, a PIN, password, biometric sample, biometric template, or other data specific to the user and / or known only to the user can be confidential. Derivatives of confidentiality can be information derived from it. For example, encrypted confidentiality or confidentiality linked to other information can be derivatives of confidentiality.

[0027] A "key" or "cryptographic key" can include a piece of information used in a cryptographic algorithm to transform data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms the original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of cryptographic algorithms can include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

[0028] "Access device key" can be a cryptographic key used by the access device during interaction.

[0029] An "authorizing entity" can be an entity that typically uses an authorized computer to authorize a request. Authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. An "issuer" can typically include a commercial entity that maintains user accounts (e.g., a bank). Issuers may also issue payment credentials to users that are stored on user devices such as cellular phones, smart cards, tablets, or laptops.

[0030] "Interaction" can include reciprocal effects or influences. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, etc. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate the payment.

[0031] "Interaction data" can include data related to the interaction and / or data recorded during the interaction. In some embodiments, interaction data can be transaction data of network data. Transaction data can include multiple data elements with data values.

[0032] A “credential” can be any suitable information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters that can be presented or contained in any object or document that can serve as authentication.

[0033] A "value certificate" can be information associated with value. Examples of value certificates include payment vouchers, coupon identifiers, and information required to obtain promotional offers.

[0034] A "payment credential" may include any suitable information associated with an account (e.g., the payment account and / or payment device associated with the account). This information may be directly related to the account or derived from account-related information. Instances of account information may include PAN (primary account number or "account number"), username, expiry date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and so on. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values ​​are typically visible to the user (e.g., a consumer), while CVV and dCVV values ​​are typically embedded in memory or authorization request messages and are not easily known to the user (although they are known to the issuer and payment processor). A payment credential may be any information identifying a payment account or associated with a payment account. A payment credential can be provided to make payments from a payment account. A payment credential may also include a username, expiry date, gift card number or code, and any other suitable information.

[0035] A "token" can be an alternative value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Instances of tokens include access tokens, such as payment tokens, data that can be used to access a security system or location, etc.

[0036] A "payment token" may include an identifier for a payment account, which is an alternative to an account identifier such as a primary account number (PAN) and / or an expiry date. For example, a token may include a series of alphanumeric characters that can be used as an alternative to the original account identifier. For example, the token "4900 0000 00000001" may be used in place of the PAN "4147 0900 00001234". In some embodiments, the token may be "formatted" and may have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., the ISO 8583 Financial Transaction Message Format). In some embodiments, the token may replace the PAN used to initiate, authorize, process, or resolve payment transactions, or represent the original credentials in other systems where the original credentials would typically be provided. In some embodiments, a token value may be generated such that the original PAN or other account identifier may not be computably recoverable from the token value. Furthermore, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to recognize the entity issuing the token.

[0037] "Tokenization" is the process of replacing sensitive data with alternative data. For example, a real credential (e.g., a master account (PAN)) can be tokenized by replacing the real account identifier with an alternative number that can be associated with the real credential. Furthermore, tokenization can be applied to any other information, thereby replacing implicit information with a token. "Token exchange" or "detoxing" can be the process of recovering data that was replaced during tokenization. For example, token exchange can include replacing a payment token with the master account (PAN) associated with the payment token. Furthermore, detoxing or token exchange can be applied to any other information, thereby retrieving the replaced information from the token. In some embodiments, token exchange can be implemented via transaction messages (e.g., ISO messages), application programming interfaces (APIs), or other types of web interfaces (e.g., web requests).

[0038] A “token service computer” may include a system that provides token services. In some embodiments, the token service computer may facilitate requesting, determining (e.g., generating), and / or issuing tokens, and maintaining the established token-to-PAN mapping in a repository (e.g., a token vault). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token’s association with the PAN. The token service computer may include or communicate with a token vault storing generated tokens. The token service computer may support token processing for payment transactions submitted using tokens by de-tokenizing the tokens to obtain the actual PAN.

[0039] An "authorization request message" can be a message requesting authorization for an interaction. In some embodiments, an authorization request message may include an electronic message sent to a payment processing network and / or the issuer of a payment card to request authorization for a transaction. Authorization request messages according to some embodiments may conform to ISO 8583, a standard for systems exchanging information about electronic transactions associated with payments made by a user using a payment device or payment account. An authorization request message may include credentials, such as a master account number that may be associated with a payment device or payment account, or a token associated with a master account. An authorization request message may also include additional data elements corresponding to "identification information," including, for example only, a service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. An authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction volume, merchant identifier, merchant location, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0040] An "authorization response message" can be an electronic message reply to an authorization request message. In some embodiments, the authorization response message may be generated by the issuing financial institution or a payment processing network. For example only, the authorization response message may include one or more of the following status indicators: Approval - the transaction is approved; Rejection - the transaction is not approved; or Call Center - further information is pending, and the merchant must call the toll-free authorization number. The authorization response message may also include an authorization code, which may be a code returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the payment processing network), indicating that the transaction has been approved. This code can serve as evidence of authorization.

[0041] A "server computer" is typically a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers acting as a unit. In one example, a server computer could be a database server coupled to a web server.

[0042] "Processor" can include any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to achieve a desired function. A processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processors; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0043] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory may include non-transient computer-readable media whose storage contains instructions executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0044] A "resource provider" can be any suitable entity that provides resources (e.g., goods, services, access to secure data, access to location, etc.) during a transaction. For example, a resource provider could be a merchant, venue operator, building owner, government entity, etc. A "merchant" can typically be an entity that participates in the transaction and can sell goods or services or provide access to goods or services.

[0045] A "portable device" can be a device that can be carried by a user. Portable devices can have the ability to store, process, and transmit information. They can also store credentials such as payment vouchers. Portable devices can have ways to generate and / or store password information to increase security. Examples of portable devices include laptops, mobile phones, payment cards, and key cards.

[0046] An acquirer can be a financial institution associated with a resource provider. Acquiring parties typically provide bank accounts for resource providers and, in some cases, transaction acceptance infrastructure. Generally, after a transaction is authorized, funds are transferred from the issuer to the acquirer's resource provider account as part of the settlement process. Acquiring parties can also communicate the payment transaction status with resource providers. Acquiring parties can operate their own computers, which can also be broadly referred to as "transfer computers."

[0047] An "issuer" can be a financial institution, such as a bank, that creates and maintains financial accounts for account holders. An issuer or issuing bank can issue and maintain financial accounts for consumers. The issuer of a particular consumer account can determine whether to approve or reject a particular transaction. If the transaction is approved (e.g., the consumer's account has sufficient available balance and meets other authorization or authentication criteria), the issuer can authenticate the consumer and release funds to the acquiring party.

[0048] A "payment processing network" can be a data processing subsystem, network, and operation used to support and deliver authorization services, exception document services, and clearing and settlement services. An exemplary payment processing network may include VisaNet. TM For example, VisaNet TM Such payment processing networks are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Authorization, settlement, and clearing can occur simultaneously (essentially simultaneously, such as within minutes or hours) or as part of a batch settlement process (e.g., at the end of a day or week). Payment processing networks may include server computers. Payment processing networks can use any suitable wired or wireless network, including the Internet.

[0049] An "access control server" (ACS) can be a server computer that can provide authentication processing. In some embodiments, an access control server can provide the issuer with the ability to authenticate the presenter (e.g., a consumer, user) during a transaction such as a remote or face-to-face purchase transaction.

[0050] A directory server can be used to route messages between different endpoints. In some embodiments, a directory server can route registration and authentication information between a Merchant Plug-in (MPI) in an access device and an issuer's ACS.

[0051] In this embodiment, the "Merchant Plug-in" (MPI) can be a component operating within the acquiring domain. In an online environment, it performs various authentication functions on behalf of the merchant or resource provider. These functions include determining whether authentication is available for a card number and verifying the digital signature in the authentication message.

[0052] An "authentication indicator" may include some type of signal indicating that authentication has been performed. In some embodiments, the authentication indicator may be in the form of a password. In other embodiments, the authentication indicator may be a code or a binary value that indicates that an entity such as an access control server or even a user device has authenticated the user interacting with it.

[0053] One embodiment includes a method. The method includes an access device receiving credentials or tokens from a portable device associated with a user in interaction. In response to receiving credentials or tokens from the portable device, the access device transmits an authentication request message including the credentials or tokens to an access control server. The access control server then transmits a query message to a user device associated with the user. In some embodiments, the query message may include a temporary code, such as a one-time password. The user receives the temporary code and may enter it into the access device. In other embodiments, the query message may include a request for the user to provide a known secret to a local application on the user device. The local application may be attached to the access control server. In such embodiments, the access control server may receive a temporary code from the access device or a secret from a local application on the user device. The access control server may then verify that the temporary code is identical to the code transmitted to the user device. Alternatively, the access control server may verify the user's secret. In both cases, the access control server may verify that the user is a legitimate user and then transmit an authentication response message including a password or other type of authentication indicator to the access device.

[0054] After receiving the authentication response message, the access device then generates and transmits an authorization request message to the authorized entity computer, including an authentication indicator (e.g., a password) and credentials or tokens. The authorized entity computer then uses the credentials or tokens and the authentication indicator to determine whether to authorize the interaction.

[0055] Figure 1 An interactive processing system according to an embodiment is shown, wherein a flowchart illustrating the method is covered. Figure 1 The system may include a user 110 associated with a user device 105 (e.g., a smartphone, mobile phone) and a portable device 115 (e.g., an access card, credit card, debit card, etc.).

[0056] User 110 can interact with a resource provider operating access device 120 (e.g., a smartphone). In some embodiments, access device 120 may be a mobile phone, point-of-sale device, door access device, kiosk, etc. Access device 120 may include an application 122 providing transaction processing functionality and a reader 124 capable of reading information from a portable device 115 (e.g., a contactless interface, such as an NFC interface). In some embodiments, application 122 may be a Merchant Plug-in (MPI).

[0057] Access device 120 can also communicate with authorized entity computer 150 via transmission computer 130 and processing network computer 140. In some embodiments, transmission computer 130 may be an acquiring computer, processing network computer 140 may be a payment processing network computer, and authorized entity computer 150 may be operated by an authorized entity such as an issuer.

[0058] Access device 120 can also communicate with directory server 160 and access control server 170. Directory server 160 may contain a directory that links different parts of credentials or tokens to different access control servers 170. For example, credentials such as a master account may contain sixteen characters, and the first six characters may indicate a specific access control server 170. In this respect, directory server 160 can transmit messages between multiple different access devices and multiple different access control servers.

[0059] The access control server 170 will be described in more detail below. The access control server 170 may be attached to the authorized entity computer 150. For example, in some embodiments, the access control server 170 and the authorized entity computer 150 may be operated by the same issuer.

[0060] Figure 1 (as well as Figure 2 Components within the system can communicate operationally with each other via any suitable communication channel or network. Suitable communication networks can be any one and / or a combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), an Operational Mission as an Internet node (OMNI), a secure custom connection, a wide area network (WAN), or a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.). Messages between computers, networks, and devices can be sent using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); and Secure Hypertext Transfer Protocol (HTTPS).

[0061] In step S102, user 110 can initiate an interaction (e.g., a transaction) with access device 120 using their portable device 115. Information can be transferred from portable device 115 to access device 120 via reader 124. For example, user 110 can tap their portable device 115 against the NFC reader in access device 120. Portable device 115 can then transmit credentials (e.g., payment credentials, access identifiers, etc.) or tokens, verification codes (e.g., CVV, dCVV), and optional other information to access device 120 via a wireless connection between portable device 115 and access device 120. This information can then be received by application 122 on access device 120.

[0062] In step S104, access device 120 may generate an authentication request message and send it to directory server 160. The authentication request message may include credentials or tokens, timestamps, and potentially other information. In some embodiments, application 122 may be a merchant plugin that provides the connection between access device 120 and directory server 160.

[0063] Upon receiving an authentication request message, directory server 160 can identify the appropriate access control server 170. For example, access control server 170 can be identified by analyzing a portion of a credential or token. A portion of the credential or token can be used to identify a specific access control server 170. For example, in some embodiments, if the credential is a master account or PAN, directory server 160 can identify access control server 170 from the PAN's Bank Identification Number (BIN) (e.g., the first six digits).

[0064] In step S106, after receiving the authentication request message and determining the appropriate access control server 170, the directory server 160 may transmit the authentication request message to the access control server 170. Upon receiving the authentication request message, the access control server 170 may parse the authentication request message. The access control server 170 may then identify the user 110. In some embodiments, the access control server 170 may identify the user 110 from credentials (e.g., from a PAN or bank account) or tokens in the authentication request message. In this regard, the access control server 170 may have a database that maps user information (e.g., phone number, email address, etc.) to one or more corresponding credentials or tokens.

[0065] In step S108, after the access control server 170 determines the address of the user's device 105 (e.g., email address, phone number, IP address, etc.), the access control server 170 may send an inquiry message with a temporary code such as a one-time password (OTP) to the user device 105. In some embodiments, the OTP may be a 6-digit password. In other embodiments, the OTP may be an alphanumeric string or image of any length (e.g., a QR code or barcode). In some embodiments, the OTP may be sent to the user device 105, for example, by the access control server 170 as an SMS message. In other embodiments, the OTP may be sent via email, automated phone calls, or push notifications.

[0066] In step S110, user 110 may input the OTP received at user device 105 into access device 120. For example, user 110 may type the OTP into access device 120. In other embodiments, the OTP may be passed directly from user device 105 to access device 120. For example, access device 120 may scan a QR code in which the OTP is displayed on user device 105. Alternatively, access device 120 may receive the OTP from user device 105 via a contactless communication link (e.g., Bluetooth or NFC).

[0067] In step S112, after obtaining the OTP, the access device 120 can send an authentication request message including the OTP to the access control server 170 via the directory server 160.

[0068] In step S114, after receiving the authentication request message including the OTP, the access control server 170 can compare the OTP from the authentication request message with the OTP sent to the user device 105 in step S108. If the OTPs match, the access control server 170 can authenticate the user 110 and the user device 105. After determining that the user 110 is authentic, the access control server 170 can also obtain (e.g., generate) an authentication indicator, such as a password indicating that the user 110 has been authenticated. Alternatively, if the OTPs do not match, the access control server 170 can generate an error message.

[0069] A password can be generated by changing data in an encrypted manner. For example, data including credentials or tokens, as well as variable data elements such as counters or timestamps, and optional data about the access device (e.g., access device identifier) ​​can be encrypted with a cryptographic key to form a password. In some embodiments, the cryptographic key may be a symmetric key shared with the authorized entity computer 150.

[0070] In some embodiments, the authentication indicator may be a code or binary value that instructs the access control server 170 to authenticate user 110.

[0071] In step S116, the access control server 170 may send an authentication response message or error message, including a password (or other authentication indicator), to the access device 120 via the directory server 160. If the access device 120 receives an error message, the resource provider operating the access device 120 may terminate the interaction.

[0072] In step S118, after receiving the authentication response message with the password, the access device 120 may generate an authorization request message including an authentication indicator (e.g., password), credentials or tokens, verification value, interaction value (e.g., transaction amount), and possibly other information. In some embodiments, the authorization request message may include a bit indicating the performance of user authentication. This bit may be in a form factor indicator data field or other data fields. The access device 120 may then transmit the authorization request message to the transmission computer 130. In steps S120 and S122, the transmission computer 130 may then transmit the authorization request message to the authorization entity computer 150 via the processing network computer 140.

[0073] If the authorization request message includes credentials such as a PAN, the processing network computer 140 can identify the authorizing entity computer 150 from the credentials and can transmit them to the authorizing entity computer 150. If the authorization request message includes a token, the processing network computer 140 can contact a token service computer (not shown) to obtain the actual credentials associated with the token.

[0074] In step S122, the processing network computer 140 can send an authorization request message to the authorization entity computer 150, which can authorize (or reject) the transaction and generate an authorization response message.

[0075] In some embodiments, approval of an authorization response message may depend on the validity of the received credentials (e.g., a master account) and the verification of the password. For example, the authorizing entity computer 150 may use a password key shared with the access control server 170 to decrypt the password and may recover various data elements. Such data elements may include values ​​or counters shared with the access control server 170, credentials, or other data accessible by the authorizing entity computer 150. Approval of an authorization request message may also depend on the amount of credit or funds in the account associated with the received credentials. If the authentication indicator is a code or binary value, the authorizing entity computer 150 may use this code or binary value in its decision on the approval interaction.

[0076] In steps S124, S126, and S128, the authorization response message can then be sent from the authorizing entity computer 150 to the access device 120 via the processing network computer 140 and the transmission computer 130.

[0077] At a later point in time, the transmission computer 130, the processing network computer 140, and the authorized entity computer 150 can complete the clearing and settlement process of the transaction.

[0078] Figure 2 A system and flowchart of another embodiment are shown. Figure 2 The system components are similar to Figure 1 The components in the text do not need to be described repeatedly.

[0079] However, in this embodiment, the user device 105 (e.g., a smartphone) may include a native application 107, such as an online banking application. For example, the native application 107 may be a mobile application associated with the authorized entity computer 150 and / or the access control server 170 that provides mobile banking capabilities to the user 110. The native application 107 may additionally or alternatively act as a mobile wallet.

[0080] In step S202, user 110 can initiate an interaction (e.g., a transaction) with access device 120 using their portable device 115. Information can be transmitted from portable device 115 to access device 120 via reader 124. For example, user 110 can tap their portable device 115 against the NFC reader in access device 120. Portable device 115 can then transmit credentials (e.g., payment credentials, access identifiers, etc.) or tokens, verification codes (e.g., CVV, dCVV), and optional other information to access device 120 via a wireless connection between portable device 115 and access device 120. This information can then be received by application 122 on access device 120.

[0081] In step S204, access device 120 may generate an authentication request message and send it to directory server 160. The authentication request message may include credentials or tokens, timestamps, and potentially other information. In some embodiments, application 122 may be a merchant plugin that provides the connection between access device 120 and directory server 160.

[0082] Upon receiving an authentication request message, directory server 160 can identify the appropriate access control server 170. For example, access control server 170 can be identified by analyzing a portion of a credential or token. A portion of the credential or token can be used to identify a specific access control server 170. For example, in some embodiments, if the credential is the primary account number of a PAN, directory server 160 can identify access control server 170 from the PAN's Bank Identification Number (BIN) (e.g., the first six digits).

[0083] In step S206, after receiving the authentication request message and determining the appropriate access control server 170, the directory server 160 may transmit the authentication request message to the access control server 170. Upon receiving the authentication request message, the access control server 170 may parse the authentication request message. The access control server 170 may then identify the user 110. In some embodiments, the access control server 170 may identify the user 110 from credentials (e.g., from a PAN or bank account) or tokens in the authentication request message. In this regard, the access control server 170 may have a database that maps user information (e.g., phone number, email address, etc.) to one or more corresponding credentials or tokens.

[0084] In step S208, the access control server 170 may send an inquiry message including an out-of-band authentication request to the local application 107 of the user device 105. The inquiry message may prompt the local application 107 to prompt the user 110 to authenticate themselves. For example, the inquiry message may be an SMS message requesting the user to log in to the local application 107 using known login credentials including a username and password (i.e., a confidential instance).

[0085] In step S210, user 110 can authenticate themselves to local application 107. For example, user 110 can enter a password or PIN or biometrics (e.g., fingerprint, facial scan) into local application 107. Local application 107 can then authenticate user 110. In some embodiments, the authentication process can be the same process used by user 110 to log in to local application 107 under normal operation. In other embodiments, local application 107 may present a window from which a secret can be received from the user. To authenticate the user, the received secret can be compared with a secret stored in local application 107 on user device 105 or a secret stored on an application server (e.g., access control server 170 or authorization entity computer 150).

[0086] In step S212, after receiving the secret, the local application 107 may send an inquiry response message to the access control server 170. The inquiry response message may include an indication that the user 110 has been successfully authenticated or not authenticated by the user device 105. In other embodiments, the inquiry response message may include a secret entered by the user into the local application 107. The secret can then be verified by the access control server 170 by comparing the received secret with a stored secret.

[0087] In step S214, the access control server 170 can verify that user 110 is authenticated by the local application 107, or it can verify the secret entered by user 110 into the local application 107. If user 110 is authenticated, the access control server 170 can verify the secret entered by user 110 into the local application 107 as described above. Figure 1 The password (or other authentication indicator) may be obtained (e.g., generated) in the same or different manner as described in the embodiments. If user 110 is not successfully authenticated, access control server 170 may generate an error message.

[0088] In step S216, after obtaining (e.g., generating) the password, the access control server 170 may send an authentication response message or error message, including the password (or other authentication indicator), to the access device 120 via the directory server 160. If the access device 120 receives an error message, the resource provider operating the access device 120 may terminate the interaction.

[0089] In step S218, after receiving the authentication response message with the password, the access device 120 may generate an authorization request message including the password (or other authentication indicator), credentials or tokens, verification value, interaction value (e.g., transaction amount), and possibly other information. In some embodiments, the authentication indicator may be a bit that can be included in the authorization request message to indicate that authentication of the user has been performed. This bit may be in a form factor indicator data field or other data fields. The access device 120 may then transmit the authorization request message to the transmission computer 130. The transmission computer 130 may then transmit the authorization request message to the authorization entity computer 150 via the processing network computer 140.

[0090] If the authorization request message includes credentials such as a PAN, the processing network computer 140 can identify the authorizing entity computer 150 from the credentials and can transmit them to the authorizing entity computer 150. If the authorization request message includes a token, the processing network computer 140 can contact a token service computer (not shown) to obtain the actual credentials associated with the token.

[0091] In step S222, the processing network computer 140 can send an authorization request message to the authorization entity computer 150, which can authorize (or reject) the transaction and generate an authorization response message.

[0092] As explained above, approval of an authorization response message can depend on the validity of the received credentials (e.g., master account) and the verification of the password. For example, the authorizing entity computer 150 can use a password key shared with the access control server 170 to decrypt the password and recover various data elements. Such data elements may include values ​​or counters shared with the access control server 170, credentials, or other data accessible by the authorizing entity computer 150. Approval of an authorization request message can also depend on the amount of credit or funds in the account associated with the received credentials.

[0093] In steps S224, S226, and S228, the authorization response message can then be sent from the authorizing entity computer 150 to the access device 120 via the processing network computer 140 and the transmission computer 130.

[0094] At a later point in time, the transmission computer 130, the processing network computer 140, and the authorized entity computer 150 can complete the clearing and settlement process of the transaction.

[0095] In some embodiments, after authentication has been completed, the authentication result can be embedded in the chip data sent by the portable device 115 to the authorizing entity computer 150. This can be used by the authorizing entity computer 150 for authorization decisions. Alternatively, the authentication process can be recorded in logs stored in a directory server 160 and / or an access control server 170. The authorizing entity computer 150 can access these logs and retrieve information about the authentication for authorization or dispute resolution.

[0096] Figure 3 A block diagram of a user device 300 according to an embodiment is shown.

[0097] User device 300 may include a processor 300A for processing functions of user device 300. User device 300 may also include a display 300B and an input element 300C (e.g., touchscreen, keyboard, biometric sensor, etc.) coupled to processor 300A. User device 300 may also include volatile memory 300D (e.g., RAM, DRAM, EEPROM, etc.), non-transient computer-readable medium 310, and contactless element 300E coupled to processor 300A.

[0098] Processor 300A may include any suitable one or more data computing devices. Processor 300A is capable of interpreting code and executing instructions stored on computer-readable medium 310. Processor 300A may include a central processing unit (CPU) operating on a reduced instruction set, and may include a single-core or multi-core processor. Processor 300A may also include an arithmetic logic unit (ALU) and cache memory.

[0099] In some embodiments, the contactless element 300E may be implemented as a semiconductor chip (or other data storage element) having an associated wireless transmission (e.g., data transmission) element, such as an antenna. The contactless element 300E is capable of transmitting and receiving data using short-range wireless communication capabilities (e.g., NFC).

[0100] Computer-readable medium 310 may include code executable by a processor for implementing the methods of the embodiments. For example, computer-readable medium 310 may include code executable by processor 300A for implementing a method comprising: receiving temporary code, or receiving an inquiry message, receiving a secret from a user, verifying the secret, or transmitting an inquiry response message including the secret to an access control server.

[0101] The computer-readable medium 310 may contain one or more access applications 310A (e.g., a digital wallet application, a mobile banking application maintained by an authorized entity or payment processing network). The computer-readable medium 310 may also contain multiple functional modules, including an encryption module 310B, a communication module 310C, and an interaction processing module 310C.

[0102] The encryption module 310B may include code executable by the processor 300A for performing encryption services, including encrypting or decrypting data (e.g., generating an authorization response cipher), digitally signing data (e.g., committing to a transaction), performing key exchange, and encrypting messages sent to other systems or devices.

[0103] The communication module 310C may include code that can be executed by the processor 300A to allow the user device 300 to communicate with other external devices.

[0104] The interaction processing module 310D may include code executable by the processor 300A to perform interaction processing, such as transaction processing. It may include code for obtaining a credential or token and then providing the credential or token to a contactless element for transmission to an access device.

[0105] Figure 4 A block diagram of the access device 400 according to an embodiment is shown.

[0106] Access device 400 includes a processor 400A. The access device may also include a display 400B and an input element 400C (e.g., touchscreen, PIN pad, microphone, portable device reader, etc.) coupled to the processor 400A. Access device 400 may also include a network interface 400D, a memory 400E, a contactless element 400F, and a computer-readable medium 410 coupled to the processor. The contactless element 400F is configured to communicate (e.g., send and / or receive data) with the contactless element 300E of user device 300 using short-range wireless communication capabilities (e.g., NFC).

[0107] The network interface 400D may include an interface that allows the access device 400 to communicate with external devices (e.g., user devices, processing computers, acquiring computers).

[0108] Computer-readable medium 410 may contain multiple modules to perform methods of embodiments including interactive authorization module 410A, encryption module 410B, communication module 410C, and application program 410D.

[0109] The interactive authorization module 410A may include code executable by the processor 400A to perform transaction authorization functions. Such functions may include generating authorization request messages and receiving authorization response messages.

[0110] Encryption module 410B and communication module 410C can be similar to encryption module 310B and communication module 310C, and their description need not be repeated here.

[0111] Application 410D may be code executable by processor 400A for communicating with a directory server and an access control server. In some embodiments, if the access device is a point-of-sale terminal, application 410D may be an MPI or a merchant plugin.

[0112] Computer-readable medium 410 may include instructions executable by a processor to cause the access device to: receive a credential or token from a portable device associated with a user in the interaction; in response to receiving the credential or token from the portable device, transmit an authentication request message including the credential or token to an access control server, the access control server transmitting an inquiry message to a user device associated with the user; receive an authentication response message including an authentication indicator obtained by the access control server; and transmit an authorization request message including the authentication indicator and the credential or token to an authorization entity computer, wherein the authorization entity computer uses the credential or token and the authentication indicator to determine whether to authorize the interaction.

[0113] Figure 5 A block diagram of an access control server 500 according to an embodiment is shown.

[0114] Access control server 500 includes processor 500A for processing the functions of access control server 500. Access control server 500 may also include data storage 500B coupled to processor 500A. Access control server 500 may also include network interface 500C, which may include an interface allowing access control server 500 to communicate with external devices (e.g., access devices, directory server computers, etc.) and may be coupled to processor 500A. Access control server 500 may also include computer-readable medium 510 coupled to processor.

[0115] Data storage device 500B can store the mapping between credentials or tokens and user information. Data storage device 500B can also store temporary codes (e.g., one-time passwords) and the secrets of real users. Data storage device 500B can also store various cryptographic keys used to generate passwords.

[0116] The computer-readable medium 510 may contain multiple software modules. These modules may include a data retrieval module 510A, a password generation module 510B, a communication module 510C, an authentication module 510D, and a code generation module 510E.

[0117] The data retrieval module 510A may include code that can be executed by the processor 500A to locate user information in the data storage device 500B based on the received user credentials or token.

[0118] The password generation module 510B may include code, as described above, executable by the processor 500A, for generating one or more passwords.

[0119] The communication module 510C may include code that can be executed by the processor 500A to allow the access control server 500 to communicate with other external entities.

[0120] Verification module 510D may include code executable by processor 500A to perform any of the verification processes described above, including verification of secrets, digital certificates, user credentials, or tokens. For example, verification module 510D and processor 500A may compare a secret received from a user with a stored secret to determine if the user is authentic. In another instance, verification module 510D and processor 500A may compare a received temporary code with a previously generated temporary code.

[0121] The code generation module 510E may include code executable by the processor 500A to generate code that can be used in the processes described above. The code generation module 510E may also include code for a random number generator, which can be used to generate temporary codes, such as one-time passwords.

[0122] Computer-readable medium 510 may include code executable by processor 500A to cause access control server 500 to perform a method comprising: after an access device receives a credential or token from a user's portable device, receiving from the access device an authentication request message including the credential or token; in response to receiving the authentication request message, transmitting an inquiry message to a user device associated with the user; obtaining an authentication indicator; and transmitting an authentication response message including the authentication indicator to the access device.

[0123] Embodiments of the present invention offer several advantages. These embodiments can allow access devices that may be less sophisticated than point-of-sale terminals or other dedicated access devices (such as smartphones) to be securely used for transaction processing. In embodiments of the present invention, the user's confidentiality is never directly entered into a potentially insecure access device. In the described embodiments, a temporary code can be provided to the user and entered into the access device. This code can be a one-time password that cannot be reused by hackers or fraudsters. In other embodiments, the user does not need to enter anything into the access device but can simply authenticate themselves as a local application operated by an access control server on the user's own user device. In both cases, the user's confidentiality is protected, and the user can use the access device to access any desired resources.

[0124] Any software component or function described in this application may be implemented as processor-executable software code using, for example, conventional or object-oriented techniques and any suitable computer language (e.g., Java, C++, or Perl). The software code may be stored as a series of instructions or commands on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive, or optical media such as a CD-ROM. Any such computer-readable medium may reside on or within a single computing device, and may exist on different computing devices within a system or network, or on different computing devices.

[0125] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of this disclosure. Therefore, the scope of the invention may be determined not with reference to the above description, but rather with reference to the pending claims and their full scope or equivalents.

[0126] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0127] Unless specifically indicated to the contrary, the use of “a / an” or “the” is intended to mean “one or more”.

[0128] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. This does not constitute an admission that they are prior art.

Claims

1. A method for user authentication, the method comprising: The access device receives credentials or tokens from a portable device associated with the user in the interaction; In response to receiving the credential or the token from the portable device, the access device transmits a first authentication request message including the credential or the token to the access control server, and the access control server transmits a one-time password to the user device associated with the user. The access device receives the one-time password from the user device; The access device sends a second authentication request message containing the credential or the token and the one-time password to the access control server. After verifying the one-time password, the access control server generates an authentication response message containing an authentication indicator. The access device receives the authentication response message, including the authentication indicator, from the access control server, and The access device transmits an authorization request message, including the authentication indicator and the credential or token, to the authorized entity computer.

2. The method of claim 1, wherein transmitting the first authentication request message to the access control server includes transmitting the first authentication request message to the access control server via a directory server.

3. The method of claim 1, wherein receiving the credential or the token from a portable device associated with the user by the access device includes receiving the credential from the portable device by the access device.

4. The method of claim 1, wherein the portable device is in the form of a card, and the user device is in the form of a mobile phone.

5. The method of claim 1, wherein the portable device is located within the user device.

6. The method of claim 1, wherein the authentication indicator is a password generated using a first symmetric key stored at the access control server, and the password is verified at the authorized entity computer using a second symmetric key stored at the authorized entity computer.

7. The method of claim 1, wherein the access device is in the form of an access terminal, the access terminal allowing the user to access a secure location.

8. The method of claim 1, wherein the authentication indicator is code or binary data.

9. The method of claim 1, wherein the portable device includes a contactless element capable of wirelessly communicating with an RF reader in the access device.

10. A method for user authentication, the method comprising: The access device receives credentials or tokens from a portable device associated with the user in the interaction; In response to receiving the credential or token from the portable device, the access device transmits an authentication request message including the credential or token to an access control server, wherein the access control server transmits an inquiry message to a user device associated with the user, and wherein the inquiry message includes an out-of-band authentication request that requests the user to log in to a local application by entering a username and a secret or biometrics in a local application on the user device, the local application authenticates the user, and then generates and sends an inquiry response message to the access control server, the inquiry response message containing an indication that the user has successfully logged in to the local application; The access device receives an authentication response message, including an authentication indicator, from the access control server. The access device transmits an authorization request message, including the authentication indicator and the credential or token, to the authorized entity computer.

11. An access device, comprising: processor; as well as A non-transient computer-readable medium, the non-transient computer-readable medium including instructions executable by the processor to cause the access device to: Receive credentials or tokens from the portable device associated with the user during the interaction; In response to receiving the credential or the token from the portable device, a first authentication request message including the credential or the token is transmitted to the access control server, which transmits a one-time password to the user device associated with the user. Receive the one-time password from the user device; The access control server sends a second authentication request message containing the credential or the token and the one-time password. After verifying the one-time password, the access control server generates an authentication response message containing an authentication indicator. Receive the authentication response message including the authentication indicator from the access control server; as well as The authorization request message, including the authentication indicator and the credential or token, is transmitted to the authorized entity computer.

12. A method for user authentication, the method comprising: After the access device receives a credential or token from the user's portable device, the access control server receives an authentication request message from the access device, including the credential or token. In response to receiving the authentication request message, the access control server transmits an inquiry message to the user device associated with the user, wherein the inquiry message includes an out-of-band authentication request, which requests the user to log in to the local application by entering a username and a secret or biometric feature in the local application on the user device. The access control server receives an inquiry response message from the local application on the user device, the inquiry response message containing an indication that the user has successfully logged into the local application; The authentication indicator is obtained from the access control server; as well as The access control server transmits an authentication response message, including the authentication indicator, to the access device.

13. The method of claim 12, wherein the authentication indicator is a password, and wherein the method further comprises: The confidential information is received from the user by a local application on the user device. as well as The access control server verifies the secret before obtaining the password, wherein obtaining the authentication indicator includes generating the authentication indicator.

14. The method of claim 12, wherein the authentication indicator is a password.

Images