Chain connection of tokens

Abstract

Embodiments may provide a linked authentication token. The authentication tokens may be linked in such a manner that a current authentication token may be determined by using a previous authentication token. Such embodiments may enable a server computer to authenticate a user even if an authentication token received by a client computer is not latest.

Description

[0001] Cross-reference to related applications

[0002] none. Background Art

[0003] A client computer used by a user can receive an authentication token from an authentication server computer after the user registers with the server computer. When the user of the client computer subsequently needs to access resources using the server computer, the client computer can use the authentication token to authenticate itself to the server computer. In some cases, after the server computer authenticates the client computer using the authentication token, the server computer creates a new authentication token and sends it to the client computer for use in the next transaction conducted by the client computer.

[0004] However, if the connection between the client computer and the server computer is interrupted, the server computer may send a new authentication token to the client computer, but the client computer may not receive the new authentication token. When the client computer attempts a subsequent transaction with the server computer and attempts to authenticate itself to the server computer, the client computer will send the previous authentication token to the server computer. However, the server computer expects to receive the newly created token. Because the server computer did not receive the newly created token, the server computer will not be able to authenticate the client computer in the subsequent transaction and will not allow the subsequent transaction to proceed.

[0005] Additionally, authentication systems can sometimes utilize different server computers that perform similar functions. This can provide redundancy, reduce latency, and more. The different server computers periodically synchronize data so that client computers interacting with the system can have the same experience, regardless of the specific server computer they are currently interacting with. If a client computer attempts to authenticate with different server computers in consecutive transactions within a short period of time, those server computers may not have sufficient time to synchronize data. Consequently, authentication attempts in such situations may fail.

[0006] Embodiments of the present disclosure address this and other problems, individually and collectively. Summary of the Invention

[0007] One embodiment of the present invention includes a method. The method includes: receiving, by a server computer, a first request message from a client computer; in response to receiving the first request message, inputting a plurality of static data elements and a first pseudo-random value into a token generator function to generate a first authentication token; sending, by the server computer, a first response message including the first authentication token to the client computer; receiving, by the server computer, a second request message from the client computer including the first authentication token; in response to receiving the second request message, inputting the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value; inputting the second pseudo-random value and the plurality of static data elements into the token generator function to obtain a second authentication token; and sending, by the server computer, a second response message including the second authentication token to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer.

[0008] Another embodiment of the present invention includes a server computer comprising: a processor; and a non-transitory computer-readable medium, the non-transitory computer-readable medium comprising code executable by the processor for performing operations, the operations comprising: receiving a first request message from a client computer; in response to receiving the first request message, inputting a plurality of static data elements and a first pseudo-random value into a token generator function to generate a first authentication token; sending a first response message comprising the first authentication token to the client computer; receiving a second request message comprising the first authentication token from the client computer; in response to receiving the second request message, inputting the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value; inputting the second pseudo-random value and the plurality of static data elements into the token generator function to obtain a second authentication token; and sending a second response message comprising the second authentication token to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer.

[0009] Another embodiment of the present invention includes: a client device sending a first request message to a server computer, wherein the server computer inputs multiple static data elements and a first pseudo-random value into a token generator function to generate a first authentication token, and sends a first response message including the first authentication token to the client computer; the client device receives the first authentication token; and the client device sends a second request message including the first authentication token to the server computer, wherein the server computer inputs the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value, inputs the second pseudo-random value and the multiple static data elements into the token generator function to obtain a second authentication token, and sends a second response message including the second authentication token to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer.

[0010] Another embodiment of the present invention includes a client device comprising: a processor; and a non-transitory computer-readable medium, the non-transitory computer-readable medium comprising code executable by the processor to perform a method, the method comprising: sending a first request message by the client device to a server computer, wherein the server computer inputs multiple static data elements and a first pseudo-random value into a token generator function to generate a first authentication token, and sending a first response message including the first authentication token to the client computer; receiving the first authentication token by the client device; and sending a second request message including the first authentication token by the client device to the server computer, wherein the server computer inputs the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value, inputs the second pseudo-random value and the multiple static data elements into the token generator function to obtain a second authentication token, and sending a second response message including the second authentication token to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer.

[0011] A better understanding of the nature and advantages of embodiments of the present invention may be obtained by reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 An authentication flow chart is shown.

[0013] Figure 2 A flow chart for generating an authentication token is shown.

[0014] Figure 3 An authentication flow diagram is shown, illustrating a failure of authentication.

[0015] Figure 4A data flow diagram for generating tokens according to an embodiment is shown.

[0016] Figure 5 An authentication flow chart showing successful authentication using a token generated according to an embodiment is shown.

[0017] Figure 6 A block diagram of a server computer is shown in accordance with some embodiments. DETAILED DESCRIPTION

[0018] Before discussing the embodiments of the present disclosure, some terms may be described in further detail.

[0019] A "user" may include an individual. In some embodiments, a user may be a cardholder, an account holder, or a consumer.

[0020] A "client device" may be a device that sends and receives communications from a server computer. In some embodiments, a client device may be a user device operated by a user. Examples of user devices may include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptop computers, desktop computers, server computers, vehicles (e.g., cars), thin client devices, tablet PCs, and the like. Furthermore, a user device may be any type of wearable technology device, such as a watch, headphones, glasses, and the like. A user device may include one or more processors capable of processing user input. A user device may also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, and the like. User input obtained by an input sensor may come from a variety of data input types, including but not limited to audio data, visual data, or biometric data. A user device may include any electronic device that can be operated by a user and that may also provide remote communication capabilities with a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that provides access to a network (such as the Internet or a private network).

[0021] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation agencies, government entities, venue and residential operators, etc. A "merchant" can generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services.

[0022] An "authentication token" (or auth token) is a piece of information that verifies a user's identity to a website, server, or anyone requesting verification of the user's identity. Authentication tokens can add an extra layer of security and have the added benefit of being easily scalable and providing better access control. Regarding scalability, authentication tokens contain the data needed to verify a user's identity and are stored locally on the user's device. Because each token can store user-specific data, authentication tokens can tell a server how much access to grant a user, thereby providing access control to the server that issued the authentication tokens.

[0023] A "processor" may include a device that processes something. In some embodiments, a processor may include any suitable data computing device or devices. A processor may include one or more microprocessors that work together to achieve the desired functionality. A processor may include a CPU that includes at least one high-speed data processor that is sufficient to execute program components for executing user and / or system generated requests. A CPU may be a microprocessor such as an Athlon, Duron, and / or Opteron from AMD; a PowerPC from IBM and / or Motorola; a Cell processor from IBM and Sony; a Celeron, Itanium, Pentium, Xeon, and / or XScale from Intel; and / or similar processors.

[0024] "Memory" can be any suitable device or devices capable of storing electronic data. Suitable memory can include non-transitory computer-readable media storing instructions executable by a processor to implement the desired method. Examples of memory can include one or more memory chips, disk drives, and the like. Such memory can operate using any suitable electrical, optical, and / or magnetic operating modes.

[0025] A "server computer" may include a powerful computer or computer cluster. For example, a server computer may be a mainframe, a cluster of minicomputers, or a group of servers operating as a unit. In one example, a server computer may be a database server coupled to a web server. A server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and assemblies to service requests from one or more client computers.

[0026] Embodiments may include the use of computationally linked authentication tokens. The authentication tokens in embodiments may be linked in such a manner that a current authentication token may be determined by using a previous authentication token. Such embodiments may enable a server computer to authenticate a client device even if an authentication token received from the client device is not the current authentication token. For example, if a server computer receives a first authentication token from a client computer when a second authentication token is expected, the server computer may still authenticate the client computer by determining the second authentication token using the first authentication token. The server computer may then check whether the second authentication token determined by using the first authentication token matches a second authentication token stored in its memory.

[0027] Embodiments of the present invention improve system reliability because a client computer can be authenticated even if there is a problem providing the client computer with a current authentication token.

[0028] Figure 1 106. In some cases, the client computer 102 may authenticate itself to the server computer 106 to access resources available via the server computer 106. For example, after the server computer 106 authenticates the client computer 102, the server computer 106 may provide access to resources such as goods or services, secure data, or a secure location.

[0029] Figure 1 The authentication flow chart in FIG. 4 may include a registration phase and an authentication phase. The registration phase may include steps S102 to S106, and the authentication phase may include steps S108 to S114.

[0030] Figure 1 The devices and computers in the system 100 and many subsequent figures can communicate with each other using a communication network (not shown), such as a cellular communication network or the Internet. However, it should be understood that such a communication network can take any suitable form and can include any one and / or combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), an operating mission as a node in the Internet (OMNI), a secure custom connection, a wide area network (WAN), a wireless network (e.g., using protocols such as, but not limited to, the Wireless Application Protocol (WAP), I-mode, etc.), etc. Messages between computers and devices in the system 100 can be sent using communication protocols such as, but not limited to, the File Transfer Protocol (FTP); the Hypertext Transfer Protocol (HTTP); the Secure Hypertext Transfer Protocol (HTTPS), the Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), etc.

[0031] In step S102, a user using client computer 102 may cause client computer 102 to send a first request message that includes unique information related to the user and client computer 102. Such information may include device information about client computer 102 (e.g., phone number, IMEI number, manufacturer's serial number, etc.) and information about the user of client computer 102 (e.g., name, account number, user identifier, such as a customer identifier). In some embodiments, client computer 102 may wish to authenticate itself to server computer 106 in order to access resources available via server computer 106. In some embodiments, the first request message may be characterized as a registration message.

[0032] In step S104, upon receiving the first request message from the client computer, the server computer 106 may verify the unique information sent by the client computer 102. For example, in a payment transaction, the server computer may verify that the user's account number and / or other personal information is authentic. The server computer 106 may also use an out-of-band authentication process, such as a one-time password (OTP) authentication process, to authenticate the client computer 102 or the user of the client computer 102. Upon successful authentication, the server computer 106 may generate a first authentication token based on the static data and the dynamic data. The server computer 106 may store the first authentication token in a database and send the first authentication token to the client computer 102.

[0033] In step S106, server computer 106 may generate a first response message including the first authentication token and send it to client computer 102. Server computer 106 may additionally allow the client computer to access resources available via server computer 106. The resources may be secure data, a secure location, or goods or services provided by the operator of server computer 106. In the event that the resource to be obtained is a good or service, server computer 106 may allow the transaction to proceed (e.g., submission of a credit or debit card authorization request) if the user of client computer 102 and client computer 102 have been authenticated.

[0034] In step S108, the user of client computer 102 may want to obtain a resource from server computer 106. Client computer 102 may use the first authentication token to authenticate itself with server computer 106. The client computer may do this by sending a second request message to server computer 106 including the authentication token.

[0035] In step S110 , upon receiving the second request message, server computer 106 may check whether the first authentication token received by client computer 102 matches a first authentication token in the database.

[0036] In step S112, after verifying that the two tokens match, server computer 106 can provide the requested resource to the user of client computer 102. Server computer 106 can also generate a second authentication token. Server computer 106 can use static data and dynamic data to generate the second authentication token. Server computer 106 can then store the second authentication token in its database.

[0037] In step S114, server computer 106 may send a second response message including the second authentication token to client computer 102. Server computer 106 may further allow the client computer to access resources available via the server computer. For subsequent authentication, client computer 102 may use the second authentication token to authenticate itself to server computer 106 in subsequent transactions.

[0038] Figure 2 A flow chart illustrating a server computer generating an authentication token using an existing method is shown. Authentication Token Multiple data elements 202 may be input into a token generator function 204 to determine an authentication token 206 .

[0039] The plurality of data elements may include unique data elements of the user, data provided by the client computer, and other information. For example, when a user operating a client computer is authenticating to a server computer for a payment transaction, the plurality of data elements 202 may include static data, such as the user's primary account number (or a hash thereof), a unique identifier for the client computer, a user identifier, a merchant identifier, and the like, as well as dynamic data elements, such as the current time. The static and dynamic data elements may be used to create a unique authentication token for each transaction. Because the time of day used to generate the first authentication token and the time of day used to generate the second authentication token may be very different, the first authentication token and the second authentication token may not be linked to each other or computationally unrelated to each other.

[0040] The token generator function 204 may include any suitable function for altering data. For example, the token generator function 204 may include a cryptographic hash function, such as SHA-1, or may include a cryptographic function that uses a cryptographic key.

[0041] Figure 3 An authentication flow chart is shown, which shows the failure of authentication. The authentication flow chart can be used according to Figure 2 The client computer 102 can authenticate itself to the server computer 106. The client computer 102 can authenticate itself to access resources available via the server computer 106, such as payment transactions, account authentication, etc.

[0042] The authentication flow chart may include a registration phase and an authentication phase. The registration phase may include steps S302 to S306. The first authentication phase may include steps S308 to S314. The second authentication phase may include steps S316 to S320.

[0043] Steps S302 to S312 may be similar to Figure 1 Steps S102 to S112 in which the Figure 2 In step S314, when server computer 106 stores the second authentication token and sends a second response message including the second authentication token to client computer 102, there may be a network interruption that prevents client computer 102 from receiving the second response message from client computer 102.

[0044] In step S316, client computer 102 can authenticate itself to server computer 106 in subsequent transactions to obtain resources from server computer 106. Client computer 102 does not receive the second authentication token from server computer 106 due to the network interruption, so it sends the first authentication token instead of the second authentication token to server computer 106 to authenticate itself.

[0045] In step S318, server computer 106 may check whether the first authentication token received from client computer 102 matches a second authentication token stored in a database of server computer 106. Since the first authentication token does not match the second authentication token, server computer 106 does not authenticate client computer 102.

[0046] In step S320, the server computer 106 may deny access to the requested resource to the user of the client computer 102. In this regard, the server computer 106 may send a third response message informing the client computer 102 that it has not been authenticated.

[0047] Figure 4 A flow chart of a server computer generating an authentication token according to an embodiment is shown. The authentication tokens generated in embodiments of the present invention can be computationally linked (e.g., mathematically linked) such that the current authentication token can be determined by using the previous authentication token. Figure 4 , first authentication token 412 may be used as input for generating second authentication token 416 .

[0048] Static data elements 402 may include unique data elements used to generate an authentication token. Static data may be unique to the user, the client computer, and optionally the resource provider with which the user is interacting. Examples of static data elements include a user identifier, an account number such as a primary account, a resource provider identifier, a client computer identifier, or derivatives thereof, such as hashes thereof. These static data elements may represent transactions in progress or to be conducted.

[0049] In step S402, initialization vector 404 may be seed data and / or random data that may be input into pseudo-random number generator 406. Initialization vector 404 may be a random string or number generated by a server computer. For example, initialization vector 404 may be a 32-byte random string that may be generated by a random number generator. In step S404, pseudo-random number generator 406 may then output a first pseudo-random value 408.

[0050] In step S406, the static data element 402 and the first pseudo-random value 408 may be input into a token generator function 410. In some embodiments, the token generator function 410 may be a cryptographic hash function that hashes a concatenated value including the static data element 402 and the first pseudo-random value 408. In step S408, the token generator function 410 may output a first authentication token 412.

[0051] A second authentication token 416 may be generated using the first authentication token 412 and the static data elements 402. In step S410, the first authentication token 412 may be input into the pseudo-random number generator 406. In step S412, the pseudo-random number generator 406 may determine a second pseudo-random value 414. In step S414, the plurality of static data elements 402 and the second pseudo-random value 414 may be input into the token generator function 410. In step S416, the token generator function 410 may output the second authentication token 416.

[0052] Subsequent authentication tokens (e.g., third authentication token, fourth authentication token, etc.) can be authenticated by using Figure 4 All authentication tokens may be derived from the same static data element 402.

[0053] Figure 5 Shows the use of the Figure 4 An authentication flow chart describes a method for generating an authentication token to successfully authenticate a client computer. Figure 5 The flow shown in shows a successful authentication even though the authentication token was sent by the server computer 106 but never received by the client computer 102 .

[0054] As with the previously described methods, the client computer 102 can authenticate itself to the server computer 106. The client computer 102 can authenticate itself to access resources available via the server computer 106, such as payment transactions, account authentication, and the like.

[0055] The client computer 102 may include a processor and a non-transitory computer-readable medium coupled to the processor. The non-transitory computer-readable medium may include code executable by the processor for implementing a method, the method comprising: sending, by the client computer, a first request message to a server computer, wherein the server computer inputs a plurality of static data elements and a first pseudo-random value into a token generator function to generate a first authentication token, and sending a first response message including the first authentication token to the client computer; receiving, by the client computer, the first authentication token; and sending, by the client computer, a second request message including the first authentication token to the server computer, wherein the server computer inputs the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value, inputs the second pseudo-random value and the plurality of static data elements into a token generator function to obtain a second authentication token, and sending a second response message including the second authentication token to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer. In some embodiments, the first authentication token and the second authentication token may be stored in an SDK (software development kit) on a computer-readable medium. The SDK may be an application that forms part of a resource provider application (e.g., a merchant application) so that the resource provider application and the client computer 102 storing the SDK can authenticate with the server computer 106.

[0056] In step S502, a user using client computer 102 may cause client computer 102 to send a first request message that includes unique information about the user and client computer 102. Such information may include device information about client computer 102 (e.g., phone number, IMEI number, manufacturer's serial number, etc.) and information about the user of client computer 102 (e.g., name, account number, user identifier, such as a customer identifier). In some embodiments, client computer 102 may wish to authenticate itself to server computer 106 in order to access resources available via server computer 106.

[0057] In step S504, upon receiving the first request message from the client computer, the server computer 106 may verify the unique information sent by the client computer 102. For example, in a payment transaction, the server computer may verify that the user's account number and / or other personal information is authentic. The server computer 106 may also use an out-of-band authentication process such as a one-time password (OTP) authentication process to authenticate the client computer 102 or the user of the client computer 102. After successful authentication, the server computer 106 may generate a first authentication token based on the static data and the dynamic data. The server computer 106 may store the first authentication token in a database along with the static data elements and send the first authentication token to the client computer 102. The first authentication token may be similar to Figure 4 The first authentication token 412 in.

[0058] In step S506, server computer 106 may generate a first response message including the first authentication token and send it to client computer 102. Server computer 106 may additionally allow the client computer to access resources available via server computer 106. The resources may be secure data, a secure location, or goods or services provided by the operator of server computer 106. In the event that the resource to be obtained is a good or service, server computer 106 may allow the transaction to proceed (e.g., submission of a credit or debit card authorization request) if the user of client computer 102 and client computer 102 have been authenticated.

[0059] In step S508, client computer 102 can use the first authentication token to authenticate to server computer 106 in a subsequent transaction. Client computer 102 can authenticate itself again to access resources available via server computer 106. For example, client computer 102 can use the first authentication token to authenticate itself to server computer 106 to conduct another payment transaction to obtain goods or services from a resource provider, such as an online merchant. Client computer 102 can send a second request message including the first authentication token to server computer 106.

[0060] In step S510 , upon receiving the second request message, server computer 106 may check whether the first authentication token received by client computer 102 matches the first authentication token stored in the database.

[0061] In step S512, after verifying that the two authentication tokens match, the server computer 106 authenticates the client computer 102 and allows the user of the client computer 102 to obtain the requested resource. The server computer 106 may then authenticate the client computer 102 by replacing the second pseudo-random value (e.g., Figure 4 414 in) and static data (e.g. Figure 4 402) element in the input to the pseudo-random number generator (for example, Figure 4 406 in ) to generate a second authentication token (e.g., second authentication token 416). The second pseudo-random value can be generated by replacing the first authentication token (e.g., Figure 4 412) is input to a pseudo-random number generator (e.g., Figure 4 The server computer 106 may then store the second authentication token in a database along with the static data elements.

[0062] In step S514, server computer 106 may send a second response message including the second authentication token to client computer 102. The second authentication token may be used by client computer 102 for subsequent authentication with server computer 106 in subsequent transactions.

[0063] In some cases, server computer 106 may attempt to send the second authentication token to client computer 102 , but there may be a network outage that prevents client computer 102 from receiving the second authentication token from server computer 106 .

[0064] In step S516, client computer 102 may attempt to authenticate itself to server computer 106 in another transaction to access secure data, a secure location, or goods or services. Because client computer 102 did not receive the second authentication token from server computer 106 due to the network outage, client computer 102 may send a third message including the first authentication token to server computer 106. Since server computer 108 attempted to send the second authentication token to client computer 102 in step S514 and stored the second authentication token in a database, the server computer expects to receive the second authentication token in the third message.

[0065] In step S518, the server computer may check whether the first authentication token received by the client computer 102 matches the second authentication token stored in the database of the server computer. Since the first authentication token does not match the second authentication token, the server computer 106 may now determine whether the received first authentication token is linked to the second authentication token, thereby indicating that the client computer 102 is authentic. The server computer 106 may input the received first authentication token into a pseudo-random number generator (e.g., Figure 4 406) to determine a second pseudo-random value (eg, Figure 4 Then, the second pseudo-random value (e.g., Figure 4 414) and static data elements 402 are input to the token generator function (e.g., Figure 4410) to determine the second authentication token (eg, Figure 4 416 in). Server computer 106 can then match the second authentication token determined from the first authentication token with the second authentication token stored in the database. If the two tokens match, the server computer can determine that the received first authentication token is linked to the second authentication token and can authenticate client computer 102.

[0066] In step S520 , if the two second authentication tokens match, the server computer may use the second authentication tokens to generate a third authentication token. Figure 4 The method shown in can be used to generate a third authentication token (ie, “first authentication token 412” can be replaced with the second authentication token, and “second authentication token 416” can be replaced with the third authentication token).

[0067] In step S522, server computer 106 may send a third response message including the third authentication token to client computer 102. Client computer 102 may use the third authentication token to authenticate client computer 102 in subsequent transactions.

[0068] In some embodiments, the server computer may set a limit on the number of authentication tokens that can be directly linked to the current authentication token. For example, if the server computer generates a fourth authentication token and attempts to send it to the client computer, the server computer may only allow the previous third and second authentication tokens to authenticate the client device. When the current authentication token is the fourth authentication token, the server computer may not allow the first authentication token generated before the second authentication to be used for authentication. This is because authentication tokens created many transactions prior to the current transaction may be unreliable and cannot be used to authenticate the client computer.

[0069] Figure 6 A block diagram of a server computer 600 is shown, according to an embodiment. The server computer 600 may include a processor 602, which may be coupled to a computer-readable medium 604, a database 606, and a network interface 608.

[0070] The network interface 608 may include an interface that allows the central server computer 200 to communicate with external computers. The network interface 608 may enable the server computer 600 to transfer data to and from another device (e.g., a card, an item provider computer, etc.). Some examples of the network interface 608 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. The wireless protocols enabled by the network interface 608 may include Wi-Fi TMThe data transmitted via the network interface 608 may be in the form of a signal, which may be an electrical signal, an electromagnetic signal, an optical signal, or any other signal capable of being received by an external communication interface (collectively referred to as an "electronic signal" or "electronic message"). These electronic messages, which may include data or instructions, may be provided between the network interface 608 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wire or cable, optical fiber, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.

[0071] The computer-readable medium 604 may include a plurality of software modules including a token verification module 604A, a token generation module 604B, and a random number generation module 604C.

[0072] The token verification module 604A may include code that causes the processor 602 to verify whether a token received from the client computer matches a token stored in the token storage 606A. The token generation module 604B may include code that causes the processor 602 to generate an authentication token using the static data elements 606B and a previous authentication token stored in the token storage 606A. The random number generation module 604C (e.g., a pseudo-random number generator) may include code that causes the processor 602 to generate a random number (e.g., a pseudo-random number) that can be used with the static data elements 606B to determine the authentication token.

[0073] The computer-readable medium 604 may also include code that can be executed by the processor 602 to perform operations, the operations including: receiving a first request message from a client computer; in response to receiving the first request message, inputting multiple static data elements and a first pseudo-random value into a token generator function to generate a first authentication token; sending a first response message including the first authentication token to the client computer; receiving a second request message including the first authentication token from the client computer; in response to receiving the second request message, inputting the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value; inputting the second pseudo-random value and multiple static data elements into the token generator function to obtain a second authentication token; and sending a second response message including the second authentication token to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer.

[0074] Database 606 may include token storage 606A, static data elements 606B, and authentication data 606C.

[0075] Token storage 606A may include different authentication tokens that have been generated by server computer 600. Static data elements 606B are described above and may be used to generate authentication tokens. Authentication data 606C may be used to authenticate users and / or client computers communicating with server computer 600.

[0076] Embodiments may have several advantages. One advantage is that a server computer can authenticate an authentication token even when there may be a network outage. When a server computer with a second authentication token receives a first authentication token from a client computer, the server computer can still authenticate the client computer by checking whether the received first authentication token is linked to the second authentication token. If the first authentication token can be used to generate the second authentication token, the server computer can verify and authenticate the client computer.

[0077] Another advantage is that the server computer can authenticate even when there may be data synchronization delays. When the server computer, which has the second authentication token, receives the third authentication token from the client computer, the server computer can still authenticate the client computer by checking whether the second authentication token in its database is linked to the received third authentication token. If the second authentication token can be used to generate the third authentication token, the server computer can verify the client computer and authenticate it.

[0078] In some embodiments, Figure 5 The server computer 106 in the example can be one server computer in a system including many server computers. The server computers in the system can synchronize data with each other. For example, one server computer can generate a first authentication token and share the first authentication token with other server computers in the system. This data synchronization may occur when the system needs to provide redundancy or improve latency for users in different geographic areas.

[0079] It will be apparent that the ability to "chain" authentication tokens as described above can allow different server computers performing similar functions in the same system to authenticate client computers using authentication tokens, even if those server computers are unable to synchronize their data in a timely manner. Thus, embodiments of the present invention allow systems with such server computers to operate without interruption.

[0080] Any software component or function described in this application can be implemented as a software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, and suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disc (CD) or a digital versatile disc (DVD), flash memory, etc. The computer-readable medium can be any combination of such storage devices or transmission devices.

[0081] Such program can also be encoded and sent using a carrier signal suitable for transmitting via a wired network, an optical network and / or a wireless network that conforms to multiple protocols, including the Internet. Therefore, a computer-readable medium according to an embodiment of the present invention can be created using a data signal encoded with such a program. The computer-readable medium encoded with program code can be packaged together with a compatible device, or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard drive, a CD or an entire computer system), and can be present on or within different computer products within a system or network. A computer system can include a monitor, a printer, or other suitable displays for providing any result mentioned herein to a user.

[0082] The above description is illustrative and not restrictive. After reading this disclosure, many variations of the present invention will become apparent to those skilled in the art. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims together with their full scope or equivalents.

[0083] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0084] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A method comprising: receiving, by the server computer, a first request message from the client computer; In response to receiving the first request message, inputting a plurality of static data elements and a first pseudo-random value into a token generator function to generate a first authentication token; The server computer sends a first response message including the first authentication token to the client computer; receiving, by the server computer from the client computer, a second request message including the first authentication token; In response to receiving the second request message, inputting the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value; inputting the second pseudo-random value and the plurality of static data elements into the token generator function to obtain a second authentication token; as well as A second response message including the second authentication token is sent by the server computer to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer.

2. The method of claim 1 , wherein the second response message is not received by the client computer, and the method further comprises: storing, by the server computer, the second authentication token in a database; receiving, by the server computer, a third message including the first authentication token when the server computer expects to receive the second authentication token; determining, by the server computer, that the received first authentication token is linked to the second authentication token; as well as In response to determining that the received first authentication token is linked to the second authentication token, the client computer is allowed to access resources available via the server computer.

3. The method of claim 2, wherein determining that the received first authentication token is linked to the stored second authentication token comprises: inputting the received first authentication token into the pseudo-random number generator to obtain the second pseudo-random value; as well as inputting the second pseudo-random value and the plurality of static data elements into the token generator function to obtain the second authentication token; as well as The obtained second authentication token is determined to be equal to the stored second authentication token, thereby determining that the received first authentication token is linked to the stored second authentication token. The method of claim 1 , wherein the static data element comprises a device identifier of the client computer. 5 . The method of claim 4 , wherein the static data element further comprises a user identifier of a user of the client computer.

6. The method of claim 5, wherein the static data element further comprises a resource provider identifier associated with a resource provider computer with which the client computer is interacting.

7. The method of claim 1, wherein the first request message and the second request message are received by the server computer via a resource provider computer.

8. The method according to claim 1, further comprising: The first pseudo-random value is generated by the server computer by inputting an initialization vector into the pseudo-random number generator.

9. The method of claim 8, wherein the initialization vector is 32 bytes of random data.

10. The method of claim 1, wherein the server computer is a first server computer, and wherein the method further comprises: The first server computer synchronizes the first authentication token and the second authentication token with a second server computer, wherein the first server computer and the second server computer perform the same function.

11. The method of claim 1, wherein the first request message is a registration request message that includes registration data of a user associated with the client computer.

12. The method of claim 1, wherein the client computer is a mobile phone.

13. The method of claim 12, wherein the first authentication token and the second authentication token are stored on the client computer by an SDK. The method of claim 13 , wherein the SDK is part of a resource provider application on the client computer.

15. A server computer comprising: processor; as well as A non-transitory computer-readable medium comprising code executable by the processor for performing operations comprising: receiving a first request message from a client computer; In response to receiving the first request message, inputting a plurality of static data elements and a first pseudo-random value into a token generator function to generate a first authentication token; sending a first response message including the first authentication token to the client computer; receiving, from the client computer, a second request message including the first authentication token; In response to receiving the second request message, inputting the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value; inputting the second pseudo-random value and the plurality of static data elements into the token generator function to obtain a second authentication token; and A second response message including the second authentication token is sent to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer.

16. The server computer of claim 15, further comprising a random number generation module comprising the pseudo-random number generator and a token generation module for generating the first authentication token and the second authentication token on the non-transitory computer-readable medium.

17. The server computer according to claim 15, further comprising: A database is used to store the first authentication token, the second authentication token and the static data element.

18. A method comprising: sending, by a client computer, a first request message to a server computer, wherein the server computer inputs a plurality of static data elements and a first pseudo-random value into a token generator function to generate a first authentication token, and sending a first response message including the first authentication token to the client computer; receiving, by the client computer, the first authentication token; as well as The client computer sends a second request message including the first authentication token to the server computer, wherein the server computer inputs the first authentication token into a pseudo-random number generator to obtain a second pseudo-random value, inputs the second pseudo-random value and the plurality of static data elements into the token generator function to obtain a second authentication token, and sends a second response message including the second authentication token to the client computer, wherein the second authentication token is used for subsequent authentication with the server computer.

19. The method of claim 18, wherein the second response message is not received by the client computer and the server computer stores the second authentication token in a database, and the method further comprises: When the server computer expects to receive the second authentication token, a third message including the first authentication token is sent by the client computer to the server computer, and the server computer then determines that the received first authentication token is linked to the second authentication token and allows the client computer to access resources available via the server computer.

20. The method of claim 18, wherein the first request message and the second request message are received by the server computer from the client computer via a resource provider computer, wherein the client computer seeks to access a resource provided by the resource provider computer.

Images