Web-based authentication for call centers using contactless cards

Abstract

A system, method, product, and computer-readable medium may include: a server receiving a call and generating a uniform resource locator (URL) that includes a session identifier for an account; a server transmitting the URL to a client device; a server receiving a request from a web browser that includes the URL; a server determining that the session identifier in the URL of the request matches the session identifier for the account and transmitting the web page for the URL to the web browser; a server receiving from the web browser, via a card reader on the client device, a ciphertext read by the web page and decrypting the ciphertext; a server authenticating the identity of the caller based on the decryption of the ciphertext and the session identifier in the URL matching the session identifier for the account.

Description

Technical Field

[0001] Related Applications This application claims priority to U.S. Patent Application No. 17 / 085,768, entitled "Web-Based Authentication for Call Centers Using Contactless Cards," filed on October 30, 2020. The entire content of the foregoing application is hereby incorporated by reference in its entirety.

[0002] The embodiments disclosed herein generally relate to call center platforms, and more specifically, to secure web-based authentication for call center calls using contactless cards.

Background Art

[0003] People often call call centers provided by various entities such as government agencies, companies, educational institutions, etc. For security reasons, authenticating the identity of the caller is a prerequisite for providing customer service via the call center. In some conventional solutions, dedicated applications can be utilized to facilitate authentication. However, some users may not have installed such dedicated applications on their computing devices when making a call.

[0004] Embodiments disclosed herein provide systems, methods, products, and computer-readable media for secure web-based authentication for call center calls using contactless cards. In one example, a server may receive a call from a client device. The server may generate a uniform resource locator (URL) that includes a session identifier as a parameter and associate the session identifier with an account. The server may send the URL to the client device. The server may receive a request containing the URL from the web browser of the client device. The server may determine that the session identifier in the URL of the request matches a session identifier associated with an account and send the web page associated with the URL to the web browser. The server may receive ciphertext from the web page in the web browser, read by the web page via the card reader of the client device, and decrypt the ciphertext. Based on the decryption of the ciphertext and the session identifier in the URL that matches the session identifier associated with the account, the server may authenticate the account for the call. Based on the authentication of the account, the server may provide one or more attributes of the account to a graphical user interface displayed on a call center agent system assigned to the call. [Brief explanation of the drawing]

[0005] [Figure 1A] This shows an embodiment of the system. [Figure 1B] This shows an embodiment of the system. [Figure 1C] This shows an embodiment of the system. [Figure 1D] This shows an embodiment of the system. [Figure 2A] This shows an embodiment of the system. [Figure 2B] This shows an embodiment of the system. [Figure 2C] This shows an embodiment of the system. [Figure 2D] This shows an embodiment of the system. [Figure 2E]This shows an embodiment of the system. [Figure 3A] This shows an embodiment of the system. [Figure 3B] This shows an embodiment of the system. [Figure 4A] This shows an embodiment of the system. [Figure 4B] This shows an embodiment of the system. [Figure 4C] This shows an embodiment of the system. [Figure 4D] This shows an embodiment of the system. [Figure 5] This shows an example of a user interface. [Figure 6A] An example of a contactless card is shown. [Figure 6B] An example of a contactless card is shown. [Figure 7] This shows a data structure according to one embodiment. [Figure 8A] This shows the first logical flow. [Figure 8B] This shows the first logical flow. [Figure 9] This shows the second logical flow. [Figure 10] This shows a computer architecture according to one embodiment. [Modes for carrying out the invention]

[0006] Embodiments disclosed herein provide a technology for securely authenticating identity using a computing device that does not have a contactless card and a dedicated application installed. For example, a bank or other financial institution may provide a call center system. Often, a bank may provide a dedicated application that can be used to access associated account functions. However, a user cannot install such an application on any computing device. Fortunately, however, embodiments disclosed herein can leverage a web browser to securely read data from a contactless card via near-field communication (NFC). As described in more detail herein, data read via NFC can be used to verify (or authenticate) the identity of a caller to a call center platform.

[0007] In one embodiment, a user may make a phone call to a call center. The call center system may generate a session identifier (ID) for the call. The call center system may associate the session ID with an account that indicates the caller is the subject of the call (for example, by storing the session ID in the account database record of the account). The call center system may then generate a uniform resource locator (URL) that includes the session ID as a parameter. The URL may generally point to one or more web pages associated with the call center. The call center system may then send the URL to a known device associated with the account, for example, via a short message service (SMS) message, text message, email, system notification, etc.

[0008] Upon receiving the request, the user may select a URL on their device. This causes the device to open a web browser requesting a resource at the specified URL. The web server associated with the call center system may receive the request from the web browser and identify the session ID. The web server may determine that the session ID specified in the URL matches a stored session ID generated for the account. If the session IDs match, the web server may send the web page associated with the URL to the device's web browser. When rendered in the web browser, the web page may include functionality for communicating with a contactless card via NFC, for example. The web page may instruct the user to tap the contactless card on the device. Accordingly, the user may tap the contactless card on the device, and the web page and / or web browser may instruct the contactless card to generate a ciphertext, which may be included as part of an NFC Forum Data Exchange Format (NDEF) file. The web page and / or web browser may read the ciphertext and send it to the server for decryption. The server may attempt to decrypt the ciphertext. If the server can decrypt the ciphertext and the session ID matches, the caller's authentication may be completed. In such an example, one or more attributes of the account may be output to the graphical user interface (GUI) of the call center terminal (for example, the system used by the call center agent speaking with the caller).

[0009] In other embodiments, a user may access a web page using a web browser on a computing device. The web page rendered in the web browser may instruct the user to tap a contactless card on the computing device. The web page and / or web browser may communicate with the contactless card to cause the contactless card to generate ciphertext. The web page and / or web browser may read the ciphertext and send it to a server for decryption. If the server can decrypt the ciphertext, the web server may determine whether one or more associated cookies are stored by the computing device's web browser. For example, a cookie may store a hash value associated with a user account. If a cookie exists and stores a hash value that matches a hash value stored in the user account's account database, the user's identity may be authenticated. If the hash values ​​match, the web server and / or call center server may generate a session ID for the call. The session ID may be appended to a pre-authenticated telephone number, followed by one or more special characters, such as the hash "#" character. The web server may send the telephone number, including the session ID, to the computing device's web browser. If selected, the computing device may initiate a call to the received number. When the call is answered by the call center system, the computing device may automatically enter a session ID and thereby provide the session ID to the call center system. If the session ID entered by the computing device matches the session ID, the call may be authenticated and connected directly to the agent without requiring further authentication. The call center terminal used by the agent may automatically display the relevant account details in a GUI.

[0010] Conveniently, the embodiments disclosed herein provide techniques for securely authenticating the identity of callers of call center calls. By leveraging ciphertext generated by a contactless card, the disclosed embodiments can securely verify the identity of the caller while minimizing the risk of fraud. Further, by using a web browser, no dedicated client application is required to authenticate the caller and / or perform data communication with the contactless card. Using a web browser allows the functions described herein to be advantageously scaled to various entities and any number of users without the need for a dedicated application. Further, by providing a simplified authentication process, more user calls can be processed by the call center system, thereby improving system performance.

[0011] Referring generally to the notation and nomenclature used herein, one or more portions of the following detailed description may be presented with respect to program procedures executed on a computer or a network of computers. The description and representation of these procedures are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A procedure is herein, and generally is considered to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. For reasons of common usage, it is convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0012] Furthermore, these operations are often referred to in terms such as addition and comparison, which are generally associated with intellectual operations performed by a human operator. However, for any of the operations described herein that form part of one or more embodiments, such capabilities of a human operator are not necessary or, in most cases, desirable. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include digital computers selectively activated or configured by computer programs stored therein, written in accordance with the teachings herein, and / or include devices or digital computers specially constructed for the required purpose. The various embodiments also relate to devices or systems for performing these operations. These devices can be specially constructed for the required purpose. The structures required for these various machines will become apparent from the given description.

[0013] Here, reference is made to the drawings. Like reference numerals are used throughout to refer to like elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. However, it may be apparent that novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate their description. The intention is to cover all modifications, equivalents, and alternatives within the scope of the claims.

[0014] FIG. 1A shows an exemplary system 100 consistent with the disclosed embodiments. The system 100 shown in FIGS. 1A - 1D has a limited number of elements in a particular topology, but it can be understood that the system 100 can include more or fewer elements in alternative topologies as desired for a given implementation.

[0015] As shown, System 100 comprises one or more contactless cards 101, one or more computing devices 110, one or more call center agent systems 140, and one or more servers 120. The contactless card 101 represents any type of payment card, such as a credit card, debit card, ATM card, or gift card. The contactless card 101 may have one or more communication interfaces 109, such as a radio frequency identification (RFID) chip, configured to communicate with the communication interface 118 of the computing device 110 via NFC, the EMV standard, or other short-range protocols in wireless communication. While NFC is used as an exemplary communication protocol, this disclosure is equally applicable to other types of wireless communication, such as the EMV standard, Bluetooth®, and / or Wi-Fi.

[0016] The computing device 110 and the call center agent system 140 represent any number and type of computing devices, including smartphones, tablet computers, wearable devices, laptops, portable game devices, virtualization computing systems, vendor terminals, point-of-sale systems, servers, and desktop computers. The server 120 represents any type of computing device, including servers, workstations, compute clusters, cloud computing platforms, and virtualization computing systems. Although not shown for clarity, the computing device 110, contactless card 101, server 120, and agent system 140 each include one or more processor circuits for executing programs, code, and / or instructions.

[0017] As shown, the memory 102 of the contactless card 101 includes an applet 103, a counter 104, a master key 105, a diversified key 106, and a unique customer identifier (ID) 107. The applet 103 is executable code configured to perform the operations described herein. The counter 104, master key 105, diversified key 106, and customer ID 107 are used to provide security in the system 100, as will be described in more detail below.

[0018] As shown, the memory 111 of the computing device 110 includes an operating system (OS) 112, a telephone application 113, and a web browser 115. Exemplary operating systems 112 include Android® OS, iOS®, macOS®, Linux®, and Windows® operating systems. The telephone application 113 (also called the “dialer” application) is an application that enables the device 110 to make and receive phone calls. For example, in embodiments where the computing device 110 is a smartphone, the telephone application 113 enables the user to make and / or receive phone calls over a cellular network (not shown) and / or a network 130 (e.g., the Internet). The web browser 115 is an application that enables the device 110 to access information over the network 130 (e.g., over the Internet).

[0019] As shown, the memory 122 of server 120 includes the authentication application 123, the call center application 126, and the web server 127. Although shown as separate components of server 120, in some embodiments the authentication application 123, the call center application 126, and / or the web server 127 may be integrated into a single component, for example, a single application containing all the relevant functions described herein. Similarly, although shown as part of server 120, in some embodiments the authentication application 123, the call center application 126, and / or the web server 127 may be implemented on a separate server. Furthermore, the authentication application 123, the call center application 126, and / or the web server 127 may be implemented in hardware, software, and / or a combination of hardware and software. In addition, instances of the call center application 126 of server 120 and / or agent system 140 are generally configured to perform all disclosed operations related to the call center application 126.

[0020] As will be described in more detail herein, the authentication application 123 is configured to facilitate the authentication of calls to the call center application 126 based on encrypted data generated by the contactless card 101. The web server 127 is generally configured to handle client requests for web pages 134 from the web browser 115. In at least one embodiment, the web server 127 and the browser 115 communicate via the Hypertext Transfer Protocol (HTTP).

[0021] The call center application 126 generally provides functionality to a call center system, thereby enabling it to answer, route, transfer, and / or process multiple calls. For example, a caller may dial one of several telephone numbers associated with the call center application 126. The call center application 126 on server 120 may answer the call, optionally receive input from the user, and / or route the call to one of several call center agent systems 140 for processing by an agent. In some embodiments, the call center application 126 provides a virtual call center where the agent systems 140 are geographically diverse, for example, not located in a centralized location. Each call center agent system 140 includes an instance of the call center application 126 that interfaces with the call center application 126 on server 120 to accept and / or manage calls received from customers routed to the agent system 140 by server 120. More generally, the call center application 126 may include one or more GUIs that display attributes of a call, caller, account, and / or other relevant information as described herein.

[0022] Continuing from the previous example, the call center application 126 on server 120 may route a caller's call to a first agent system 140. To assist the customer, the agent may need to access the details of one or more customer accounts in account data 124. However, to maintain the security of account data 124, system 100 must authenticate the identity of the caller and / or the call. In the embodiment shown in Figure 1A, the call center application 126 on server 120 may generate a session ID for the call and associate the session ID with an account in a record in account data 124. The session ID can be any unique alphanumeric identifier of any appropriate length, such as a hash value of 32 characters. The call center application 126 on server 120 may further assign a time limit or period to the session ID, such as 45 seconds, 2 minutes, or 10 minutes. The call center application 126 of server 120 may further associate the session ID with identifiers of the agent assigned to the call, such as a unique agent identifier, an identifier of the device 140 used by the agent assigned to the call, and / or an identifier of the instance of the call center application 126 used by the agent assigned to the call. The call center application 126 of server 120 may then generate a URL 108 that includes the session ID as a parameter. The URL 108 (and any other URLs disclosed herein) may be directed to any component of server 120 and / or any resource associated with server 120. For example, if the session ID is "ABC123", the URL having session ID 108 may be "http: / / www.example.com / webauth.html?ABC123". In such an example, the "http: / / www.example.com / webauth.html" portion of the URL may generally point to server 120, one or more web pages 134 managed by web server 127, any component of server 120, and / or any resource associated with server 120.

[0023] Generally, web page 134 may include a Hypertext Markup Language (HTML) page, a JavaScript® page, and / or any other type of page that can be rendered by a web browser 115. In some embodiments, web page 134 and / or URL 108 may be directed to a call center application 126 and / or an authentication application 123. In some embodiments, web page 134 may provide access to functionality provided by the call center application 126 and / or the authentication application 123. Furthermore, in some embodiments, web page 134 may be directed to a web-based front-end exposed by the call center application 126 and / or the authentication application 123.

[0024] In one embodiment, the call center application 126 on server 120 generates a session ID and URL 108 in response to input received from an agent via the call center application 126 on agent system 140. The input may include instructions for the account number on which the customer requested access. In some embodiments, the call center application 126 may programmatically generate the URL 108 and / or session ID based on the determination that the telephone number on which the call was received is stored in account data 124 as being associated with an account.

[0025] If an incoming call originates from a number associated with an account in account data 124, the call center application 126 on server 120 may send a URL with session ID 108 to the device associated with the target account in account data 124. For example, the call center application 126 on server 120 may identify a mobile phone number associated with an account in account data 124 and send an SMS message to the specified mobile phone number. In another example, the call center application 126 on server 120 may include a URL with session ID 108 in an email sent to a known email address of the customer. In general, a URL with session ID 108 may be transmitted via any suitable technology. In some embodiments, the call may be received from a first number associated with an account, and the URL with session ID 108 may be sent to a second phone number associated with the account. Embodiments are not limited to this context.

[0026] Figure 1B shows an embodiment in which device 110 receives a URL having session ID 108 from server 120. A user may select URL 108, which causes web browser 115 to generate an HTTP request 133 specifying URL 108. Web server 127 may receive and process request 133. In at least one embodiment, web server 127 may extract the session ID from URL 108 and compare the session ID with the session ID stored in account data 124. If no match is found, authentication may fail, and web server 127 may return an instruction for failed authentication to devices 110, 140. Similarly, web server 127 may determine whether the session ID time limit has expired. For example, if the time limit is 10 minutes and request 133 is received 15 minutes after the session ID was created, the time limit has been exceeded and authentication fails. Otherwise, if a match exists and the time limit has not been exceeded, web server 127 may send a response containing web page 134-1. Furthermore, if a match exists and the time limit has not been exceeded, the web server 127 and / or the call center application 126 may provide corresponding instructions to the call center application 126 on the agent device 140.

[0027] Figure 1C shows an embodiment in which a web browser 115 loads a web page 134-1. Advantageously, the web page 134-1 includes the functionality to wirelessly read data generated by a contactless card 101 and / or wirelessly write data to the memory 102 of the contactless card 101. More generally, a given web page 134 and / or web browser 115 may include the functionality to control a communication interface 118 and communicate with the card 101 without requiring a dedicated operating system application (e.g., an application store application) to perform these functions. In at least one embodiment, the functionality is provided via one or more application programming interfaces (APIs). APIs may be defined by the Web NFC Draft Community Group Report. Thus, a web page 134-1 (and any other web page 134) can control the NFC functionality of the communication interface 118 without requiring a dedicated application.

[0028] In some embodiments, a web page 134-1 of the web browser 115 may output instructions requesting or instructing the user to tap a contactless card 101 on the device 110 to authenticate the call account. Generally, when the contactless card 101 is brought within range of the communication interface 118 of the device 110, the applet 103 of the contactless card 101 may generate a ciphertext 148. The ciphertext 148 may be based on the customer ID 107 of the contactless card 101. The ciphertext 148 may be generated based on any suitable cryptographic technique. In at least one embodiment, the ciphertext 148 is contained in an NDEF file. The NDEF file may indicate that the ciphertext 148 was read from the contactless card 101 via the card reader 118 of the device 110.

[0029] As stated herein, system 100 is configured to implement key diversification to protect data, which may be referred to as key diversification technology. Generally, the server 120 (or other computing device) and the contactless card 101 may be provisioned with the same master key 105 (also called a master symmetric key). More specifically, each contactless card 101 is programmed with a separate master key 105 having a corresponding pair within the server 120. For example, when a contactless card 101 is manufactured, a unique master key 105 may be programmed into the memory 102 of the contactless card 101. Similarly, the unique master key 105 may be stored in the customer record associated with the contactless card 101 within the account data 124 of the server 120 (and / or in other secure locations such as a hardware security module (HSM) 125). The master key 105 may be kept secret from all parties other than the contactless card 101 and the server 120, thereby enhancing the security of system 100. In some embodiments, the applet 103 of the contactless card 101 may use the master key 105 and the data as input to an encryption algorithm to encrypt and / or decrypt the data (e.g., customer ID 107). For example, encrypting customer ID 107 with the master key 105 yields the encrypted customer ID contained in the ciphertext 148. Similarly, the server 120 may use the corresponding master key 105 to encrypt and / or decrypt the data associated with the contactless card 101.

[0030] In other embodiments, the master key 105 of the contactless card 101 and the server 120 may be used in conjunction with a counter 104 to enhance security using key diversification. The counter 104 contains a value that is synchronized between the contactless card 101 and the server 120. The counter value 104 may contain a number that changes each time data is exchanged between the contactless card 101 and the server 120 (and / or between the contactless card 101 and device 110). When preparing to send data (for example, to the server 120 and / or device 110), the contactless card 101 may increment the counter value 104. The contactless card 101 may then provide the master key 105 and the counter value 104 as input to an encryption algorithm, which generates a diversified key 106 as output. The encryption algorithm may include an encryption algorithm, a hash-based message authentication code (HMAC) algorithm, a cryptographic-based message authentication code (CMAC) algorithm, and the like. Non-limiting examples of encryption algorithms may include symmetric encryption algorithms such as 3DES or AES107, symmetric HMAC algorithms such as HMAC-SHA-256, and symmetric CMAC algorithms such as AES-CMAC. Examples of key diversification techniques are described in detail in U.S. Patent Application No. 16 / 205,119, filed November 29, 2018. The aforementioned patent application is incorporated herein by reference in its entirety.

[0031] Continuing with the example of key diversification, the contactless card 101 may use the diversified key 106 and data as input to an encryption algorithm to encrypt data (e.g., customer ID 107 and / or any other data). For example, encrypting customer ID 107 with the diversified key 106 yields the encrypted customer ID contained in the ciphertext 148. A web browser 115 and / or web page 134 can then read the ciphertext 148 via the communication interface 118.

[0032] Regardless of the encryption technology used, the web page 134 and / or web browser 115 may send the ciphertext 148 to the server 120 via the network 130. The web page and / or web browser 115 may further indicate to the server 120 that the ciphertext 148 was read from the contactless card 101 via the card reader 118 of device 110. Upon receipt, the authentication application 123 may attempt to authenticate the ciphertext 148. For example, the authentication application 123 may attempt to decrypt the ciphertext 148 using a copy of the master key 105 stored by the server 120. In another example, the authentication application 123 may provide the master key 105 and a counter value 104 as input to an encryption algorithm, which generates a diversified key 106 as output. The resulting diversified key 106 may correspond to the diversified key 106 of the contactless card 101 and can be used to decrypt the ciphertext 148.

[0033] Regardless of the decryption technique used, the authentication application 123 may successfully decrypt the ciphertext 148 and thereby verify or authenticate it (for example, by comparing the resulting customer ID 107 with the customer ID stored in the account data 124 and / or based on the indication that decryption was successful using keys 105 and / or 106). Although it is shown that keys 105 and 106 are stored in memory 122, keys 105 and 106 may be stored elsewhere, such as in the secure element and / or HSM 125. In such embodiments, the secure element and / or HSM 125 may decrypt the ciphertext 148 using keys 105 and / or 106 and an encryption function. Similarly, the secure element and / or HSM 125 may generate a diversified key 106 based on the master key 105 and counter value 104 as described above. If decryption is successful and the session ID of URL 108 matches the session ID stored in the account data 124, the call may be authenticated.

[0034] However, if the authentication application 123 cannot decrypt the ciphertext 148 and produce the expected result (e.g., the customer ID 107 of the account associated with the contactless card 101), the authentication application 123 will not validate the ciphertext 148. In such an example, the authentication application 123 will send instructions for the failed authentication to the web browser 115, the call center application 126 on the server 120, and / or the call center application 126 on the agent system 140. The call center application 126 and / or the call center application 126 may then restrict access from the account data 124 to the client data to maintain the security of the account.

[0035] Figure 1D shows an embodiment in which the authentication application 123 successfully decrypts the ciphertext 148, thereby verifying (or authenticating) the identity of the user making the call by means of the ciphertext and its association. As shown, the authentication application 123 sends a confirmation 139 to the device 110, which indicates that the authentication application 123 has successfully decrypted the ciphertext 148 and that the session ID of URL 108 matches the session ID stored in account data 124. Web page 134-1 may be updated to reflect the confirmation 139. In another embodiment, the confirmation 139 is web page 134, and the web browser 115 may display web page 134 of the confirmation 139.

[0036] Although not shown, the authentication application 123 may provide confirmation 139 to the call center application 126 of the web server 127, the server 120, and / or the call center application 126 of the call center agent system 140 assigned to the call. Furthermore, as shown, the call center application 126 may transmit one or more elements of the account data 124-1 to the call center application 126 of the agent system 140 used by the agent assigned to the call, based on, for example, one or more agent identifiers associated with the session ID. In doing so, various account attributes are displayed in one or more GUIs provided by the call center application 126, such as name, address, or other user information. In other embodiments, the account data 124-1 is already stored by the call center application 126 but is obfuscated or not exposed until the account is authenticated for the call via the GUI of the call center application 126. In such an example, the GUI of the call center application 126 may expose the stored elements of the account data 124 when it receives confirmation 139 from the server 120 that the session ID matches the session ID in which the session ID is stored, that the session ID has not expired, and that the ciphertext 148 has been successfully decrypted.

[0037] Advantageously, callers are authenticated and account data 124-1 is exposed via the call center application 126 on the agent system 140 (for example, an application provided by a financial institution associated with a contactless card 101), without requiring the device 110 to run a dedicated client application provided by the entity associated with the call center application 126.

[0038] Figure 2A shows a schematic diagram of an exemplary system 200 consistent with the disclosed embodiment. While the system 200 shown in Figures 2A to 2E has a limited number of elements in a particular topology, it can be understood that the system 200 may include more or fewer elements in alternative topologies as desired for a given implementation.

[0039] Generally, Figures 2A to 2E illustrate an embodiment in which a pre-authenticated call is initiated between device 110 and a call center application 126 on server 120 using a contactless card 101. As shown, the web browser 115 of device 110 loads webpage 134-2. Webpage 134-2 is received from web server 127 in response to a request to access webpage 134-2. Webpage 134-2 may include similar functionality to webpage 134-1, for example, the ability to communicate with contactless card 101 by reading data generated by contactless card 101 and / or writing data to the memory of contactless card 101. Thus, webpage 134-2 and / or web browser 115 may generally communicate with contactless card 101 via NFC by controlling the NFC functionality of communication interface 118.

[0040] In the embodiment shown in Figure 2A, the web page 134-2 may instruct the user to tap a contactless card 101 to initiate a pre-authenticated call to the call center application 126 of the server 120. The user may then tap the card 101 on the device 110.

[0041] By doing so, the applet 103 of the contactless card 101 generates ciphertext 201 (e.g., encrypted customer ID 107) based on the customer ID 107 and the diversified key 106, as described above. The web browser 115 and / or web page 134-2 can then read the ciphertext 201, for example, via NFC. In some embodiments, the applet 103 includes the unencrypted customer ID 107 and / or some other user identifier within the data package containing the ciphertext 201, so that the server 120 can perform the relevant decryption operation. Once read, the web browser 115 and / or web page 134-2 may send the ciphertext 201 to the authentication application 123 for processing. The web page 134-2 and / or web browser 115 may further indicate to the authentication application 123 that the ciphertext was read from the contactless card 101 via the card reader 118 of device 110.

[0042] The authentication application 123 may attempt to verify the ciphertext upon receipt. In at least one embodiment, the unencrypted customer ID 107 provided by the applet 103 may be used to identify the associated account, counter value 104, and / or master key 105 within the account data 124. The authentication application 123 may attempt to decrypt the ciphertext by providing the master key 105 and the incremented counter value 104 as input to an encryption algorithm, which generates a diversified key 106 as output. The resulting diversified key 106 may be used to construct and decrypt the ciphertext 201, corresponding to an instance of the diversified key 106 generated by the contactless card 101. Generally, the authentication application 123 may send a decryption result indicating whether decryption was successful or unsuccessful to the web browser 115 and / or web page 134-2.

[0043] Figure 2B shows an embodiment in which server 120 sends confirmation 202 to device 110. Confirmation 202 generally includes a decryption result indicating that the ciphertext 201 has been authenticated, verified, or otherwise successfully decrypted. A web browser 115 and / or web page 134-2 may receive confirmation 202 which may further include instructions for providing one or more cookies 203 of the web browser 115 to the web server 127. Generally, a cookie 203 may include a hash value or other identifier used to indicate that the web browser was used to successfully authenticate an account associated with customer ID 107. Accordingly, web browser 115 and / or web page 134-2 may send the relevant cookies 203 to the web server 127.

[0044] Upon receipt, the web server 127 may determine, based on the cookie's date, whether cookie 203 has expired, whether the hash value in the cookie is a valid hash value assigned to the account in the account data 124, and any other type of processing of cookie 203. For example, if cookie 203 is not validated based on an invalid hash value and / or an expired cookie, one or more alternative forms of authentication may be required. For example, the web server 127 and / or the call center application 126 may send a one-time password (OTP) to the device associated with the account in the account data 124. If the user provides the correct code (e.g., via web page 134-2), the OTP may be validated instead of cookie 203. In other embodiments, the web server 127 and / or the call center application 126 of server 120 may perform stability checks on one or more telephone numbers reflected in the account data 124 of the account. For example, if a telephone number has been stored in the account data 124 for a period longer than a threshold time (e.g., one week, one month, etc.), the telephone number may be validated instead of cookie 203. If cookie verification, OTP verification, and / or phone number stability checks fail, a failure notification is sent to the web browser 115 and / or web page 134-2.

[0045] Figure 2C reflects an embodiment in which the web server 127 validates the cookie 203 received from the web browser 115. However, Figure 2C may further reflect an embodiment in which the OTP is validated and / or a phone number stability check reveals that the phone number has been registered to the account for longer than a threshold.

[0046] Based on the validation of cookie 203, the call center application 126 on server 120 may generate a session ID for the pre-authenticated call. The session ID may be a hash value or other unique identifier associated with the account, and a telephone number associated with the account in account data 124. The session ID may also be associated with a time limit, such as 30 seconds, 10 minutes, or 30 minutes. The call center application 126 on server 120 may then select a pre-authenticated telephone number from among several pre-authenticated telephone numbers and append the session ID as a parameter to the telephone number to generate the telephone number with session ID 204. For example, if the pre-authenticated telephone number is 1-555-555-1212 and the session ID is "56789", the telephone number with session ID 204 may be "1-555-555-1212#56789". The call center application 126 on server 120 may then provide the telephone number along with session ID 204 to the web server 127. Next, the web server 127 may send a telephone number with session ID 204 to the web browser 115. Additionally and / or alternatively, the call center application 126 of server 120 may send a telephone number with session ID 204 to device 110 via other means such as SMS message, email, etc. Upon receipt, the user may select the telephone number with session ID 204 and initiate a call to the call center application 126 of server 120 with the pre-authenticated number. In some embodiments, the web server 127 may update cookie 203 (for example, to include a new expiration date and / or a new hash value) based on the verification of cookie 203 and / or the decryption of ciphertext 201. Furthermore, if cookie 203 does not exist, the web server 127 may store (or write) cookie 203 to the web browser 115, at least in part based on the decryption of ciphertext 201. The web server 127 may also update account data 124 to reflect the new and / or updated cookie 203.

[0047] In some embodiments, the cookie 203 may be processed before and / or simultaneously with the generation and / or processing of the ciphertext 201. In such examples, the cookie 203 may specify hash values ​​corresponding to one or more accounts in the account data 124. In this way, the server 120 can identify the master key 105 and counter value 104 of the corresponding accounts, generate a diversified key 106, and decrypt the ciphertext 201 without the contactless card 101 and / or the web browser 115 having to provide the customer ID 107 to the server 120. Similarly, if the cookie is not validated (e.g., the cookie does not exist and / or has an expired or invalid hash value), the server 120 may refrain from decrypting the ciphertext 201 to conserve resources.

[0048] Figure 2D shows an embodiment in which a call 205 is initiated by a telephone application 113 on a client device 110. The call 205 may be directed to a telephone number with session ID 204. When answered by a call center application 126 on a server 120, the telephone application 113 may provide the session ID as input, for example by programmatically entering the digits "56789" after a certain initial delay.

[0049] Next, the call center application 126 on server 120 may determine whether the call 205 is directed to one of several pre-authenticated numbers. Then, the call center application 126 on server 120 may receive a session ID from the telephone application 113 and determine whether the session ID is valid. For example, the call center application 126 on server 120 may compare the session ID with a session ID stored in the account data 124. If a match exists, the call center application 126 on server 120 may determine whether the session ID has expired (for example, whether the call was received within a threshold time since the session ID was generated). Furthermore, the call center application 126 on server 120 may determine whether the call was received from a telephone number associated with an account in the account data 124. If the call is directed to one of several pre-authenticated numbers, the session ID is valid and has not expired, and the call was received from a telephone number associated with an account in the account data 124, the center application 126 on server 120 may authenticate the pre-authenticated call. Otherwise, the call center application 126 on server 120 may reject the pre-authenticated call or perform other actions on the call (for example, prompting the user to authenticate using another method when speaking with a customer service agent).

[0050] Figure 2E shows an embodiment in which the call center application 126 authenticates a pre-authenticated call 205. Generally, once a pre-authenticated call is authenticated as described above, the call 205 can be directly connected to the agent without the user having to wait while the agent is processing calls from other callers. For example, if there is a queue of 10 callers waiting for their calls to be processed, the pre-authenticated call 205 will be placed at the front of the queue and may be answered and processed before the other 10 calls in the queue. Similarly, the user does not need to provide any information when connecting to the agent. Furthermore, as shown in Figure 2E, the call center application 126 on the server 120 may provide account data 124-1 to the call center application 126 on the agent system 140. In this way, the agent can view the details of the account associated with the call when it is connected, without requiring any additional input from the caller. In some embodiments, the web server 127 may update the cookie 203 based on the authentication of the pre-authenticated call (e.g., to include a new expiration date and / or a new hash value). Furthermore, if cookie 203 does not exist, the web server 127 may store cookie 203 in the web browser 115 based at least partially on the decryption of the ciphertext 201. The web server 127 may also update the account data 124 to reflect the new and / or updated cookie 203.

[0051] Figure 3A is a schematic diagram 300 showing an exemplary mobile computing device 110. As shown, the mobile device 110 receives a URL 301. The URL 301 may include a session ID parameter, for example, the "123456" portion of the URL 301. The session ID parameter may be generated in response to a call made by a user of device 110 to the call center application 126. The call center application 126 on server 120 may route the call to an agent. The agent may use the agent system 140 to instruct the call center application 126 on server 120 to generate a session ID and URL 301 for the customer. The session ID parameter may be associated with an account, a call, and / or an agent assigned to the call in account data 124. The session ID may be limited to a limited validity period, for example, 10 minutes. The call center application 126 on server 120 may then send the URL 301 to device 110. URL 301 can generally be directed to any other resource associated with web page 134 and / or server 120. In some embodiments, URL 301 is directed to one or more web pages 134 associated with call center application 126 and / or web server 127. URL 301 can be specified in a text message or other type of message sent to device 110. If selected, a web browser 115 can be opened to access the resource at URL 301.

[0052] Figure 3B is a schematic diagram 310 showing an embodiment in which the web page at URL 301 is accessed. Since URL 301 includes a session ID parameter, the web server 127, the call center application 126, or any other component of server 120 may extract the session ID parameter and compare the extracted session ID parameter with the session ID parameter stored in account data 124. If the comparison results in a match, the web server 127, the call center application 126, or any other component of server 120 may determine whether the web page at the URL was accessed (or requested) within a session ID time threshold, for example, within 10 minutes following the previous example. If the web page was accessed within a time threshold, the web server 127, the call center application 126, or any other component of server 120 may verify the session ID.

[0053] In response, the web server 127, the call center application 126, or any other component of server 120 refreshes (and / or loads a new web page into) the web browser 115 and instructs the user to tap the contactless card 101 on the mobile device 110. The user may tap the contactless card 101 on the device 110. By doing so, the web browser 115 and / or the web page within the browser 115 instruct the applet 103 of the contactless card 101 to generate ciphertext, for example, ciphertext 148 or 201. More generally, the applet 103 may generate ciphertext by incrementing a counter 104, encrypting the counter 104 and the master key 105 to generate an instance of a diversified key 106, and using the diversified key 106 to encrypt the customer ID 107. The applet 103 may then send the ciphertext to the mobile device 110, for example, via NFC, or provide it in other ways. Upon receipt, the web browser 115 may send the ciphertext to the server 120, for example, via the HTTP protocol. The web page and / or web browser 115 may further indicate to the server 120 that the ciphertext was read from the contactless card 101 via the card reader 118 of the device 110. The web server 127 or any other component of the server 120 may then instruct the authentication application 123 to decrypt the ciphertext.

[0054] As shown in Figure 3B, the authentication application 123, the web server 127, or any other component of the server 120 may return a decryption result to the mobile device 110 indicating whether the ciphertext was decrypted or not. Based on the decryption result, the mobile device 110 may determine that the ciphertext was decrypted. As shown, the decryption result indicates that the authentication application 123 decrypted the ciphertext, and the authentication of the call is completed. In this way, the call center agent can proceed with assisting the caller. In some embodiments, the call center application 126 on the server 120 exposes account attributes from account data 124 on the GUI of the call center application 126 for the session ID and / or the agent system 140 associated with the call. However, if decryption is unsuccessful and / or the session ID is not validated, the authentication of the call fails, and access to account data 124 may be restricted to maintain security.

[0055] Figure 4A is a schematic diagram 400 showing an embodiment in which a contactless card 101 is used to initiate a pre-authenticated call to a call center application 126 on server 120. As shown, a mobile device 110 running a web browser 115 accesses a web page at URL 401. URL 401 may generally be directed to a web page 134 and / or any other resources associated with server 120. In some embodiments, URL 401 is directed to one or more web pages associated with the call center application 126 and / or web server 127.

[0056] As shown, the webpage at URL 401 instructs the user to tap the contactless card 101 on the mobile device 110. In some embodiments, the instruction to tap the contactless card 101 is based on the webpage and / or web server 127 reading one or more cookies in the web browser 115. For example, if the cookies store a known valid hash value, the web server 127 may allow the pre-authenticated call flow to proceed. The user can tap the contactless card 101 on the device 110. By doing so, the web browser 115 and / or the webpage within the browser 115 instruct the applet 103 of the contactless card 101 to generate ciphertext, for example, ciphertext 148 or 201. More generally, the applet 103 may generate ciphertext by incrementing a counter 104, encrypting the counter 104 and the master key 105 to generate an instance of a diversified key 106, and using the diversified key 106 to encrypt the customer ID 107. The applet 103 may then send the ciphertext to the mobile device 110, for example, via NFC reading, or provide it in other ways. Upon receipt, the web browser 115 may send the ciphertext to the server 120, for example, via the HTTP protocol. The web page and / or web browser 115 may further indicate to the server 120 that the ciphertext was read from the contactless card 101 via the card reader 118 of the device 110. The web server 127 or any other component of the server 120 may then instruct the authentication application 123 to decrypt the ciphertext.

[0057] In some embodiments, for example, a customer ID 107 is sent along with the ciphertext so that the server 120 can identify the appropriate master key 105 and counter 104. In this way, the authentication application 123 can increment the server 120 counter 104 associated with the account, generate an instance of the diversified key 106 using the account-associated counter 104 and master key 105, and decrypt the ciphertext using the diversified key. Similarly, in some embodiments, a cookie is sent along with the ciphertext so that, for example, the web server 127 can determine whether the cookie contains the valid hash value described above. If the cookie does not contain a hash value, the server 120 refrains from decrypting the ciphertext and typically refrains from the user using the pre-authenticated calling function.

[0058] Figure 4B is a schematic diagram 410 showing an embodiment in which the authentication application 123 decrypts the ciphertext. As shown, the web page in the web browser 115 reflects that the ciphertext has been successfully decrypted, for example, based on the decryption result received from the server 120. Furthermore, the web page in the web browser 115 instructs the user to select the next notification to initiate a pre-authenticated call.

[0059] Figure 4C is a schematic diagram 420 showing an embodiment in which a mobile device 110 receives a notification 403 containing a pre-authenticated telephone number. The telephone number includes a session ID parameter generated by the call center application 126 of the server 120, e.g., "123456". The notification 403 may be received as an SMS message, email, or any other type of notification. In some embodiments, a web page of the web browser 115 shown in Figure 4B may output the notification 403 and / or related information from the notification 403. The pre-authenticated telephone number may be directed to the call center application 126 of the server 120 and associated with a session ID and associated account (e.g., based on customer ID 107) in account data 124. As stated, the session ID may be limited to a predetermined validity period.

[0060] Figure 4D is a schematic diagram 430 showing an embodiment in which the user selects notification 403. Doing so opens the telephone application 113, which dials the number specified in notification 403. When answered by the call center application 126 of server 120, the telephone application 113 may provide a session ID parameter as input by providing, for example, "123456" as input after a predetermined time delay.

[0061] Next, the call center application 126 on server 120 can process the incoming call and associated inputs. Generally, the call center application 126 determines whether the call is directed to a pre-authenticated phone number. If the call is directed to a pre-authenticated phone number, the call center application 126 determines whether the correct session ID was received as input. For example, the call center application 126 on server 120 may compare the received session ID with the session ID of the pre-authenticated call stored in account data 124. If the comparison results in a match, the call center application 126 on server 120 determines whether the call was received while the session ID was still valid, for example, whether the call was received within the time limit assigned to the session ID. For example, if the time limit for the session ID is 5 minutes and the call was received within 4 minutes, the call center application 126 on server 120 determines that the session ID is valid. The call center application 126 on server 120 can then connect the pre-authenticated call directly to an agent. This may include allowing pre-authenticated calls to skip other calls waiting in line. Furthermore, doing so may allow one or more attributes of an account from account data 124 to be populated in the GUI of the call center application 126.

[0062] Figure 5 is a schematic diagram 500 showing an exemplary agent device 140 running an instance of the call center application 126. Generally, once a call is authenticated using one or more of the techniques described herein, the GUI of the call center application 126 may output one or more elements of data from the account data 124 of the authenticated account. For example, as shown, the GUI may depict a name, address, and information about one or more accounts of the user. The GUI further includes a link 501, if selected, that causes the call center application 126 on the server 120 to generate a session ID for the call, associate the session ID with an account ending in 123 and the call, and send a URL having the session ID 108 to the device 110 as described above. When the URL is accessed in a web browser 115, the user may tap a contactless card 101 to generate a ciphertext, which is sent to the server 120 for decryption. If the ciphertext is successfully decrypted and a comparison of the session ID in the URL 108 with the stored session ID matches, the call can be authenticated for that account. In such embodiments, additional details of this account may be disclosed. For example, while the balance of an account ending in 789 is displayed (e.g., based on successful authentication of a call using a card ending in 789 using one or more of the techniques described herein), the balance of an account ending in 123 is not displayed. Thus, if a call is authenticated using a contactless card 101 ending in 123, the account balance (and / or other details) of the account ending in 123 may be displayed. Advantageously, security can be enhanced by requiring different contactless cards 101 to authenticate access to the associated account during the same call with a call center agent.

[0063] Figure 6A is a schematic diagram 600 showing an exemplary configuration of a contactless card 101, which may include a payment card such as a credit card, debit card, or gift card issued by a service provider, as indicated by a service provider mark 602 on the front or back of the contactless card 101. In some examples, the contactless card 101 may include, but is not limited to, an identification card that is not related to a payment card. In some examples, the contactless card may include a dual-interface contactless payment card, a rewards card, etc. The contactless card 101 may include a substrate 610 which may include a single layer or one or more laminated layers made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, titanium anodized oxide, palladium, gold, carbon, paper, and biodegradable materials. In some cases, the contactless card 101 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard, or otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, the contactless card 101 relating to this disclosure may have different characteristics, and it should be understood that this disclosure does not require the contactless card to be implemented as a payment card.

[0064] The contactless card 101 may also include identification information 615 displayed on the front and / or back of the card, and contact pads 620. The contact pads 620 may include one or more pads and be configured to establish contact with other client devices such as ATMs, user devices, smartphones, laptops, desktops, or tablet computers via the contactless card. The contact pads may be designed in accordance with one or more standards, such as the ISO / IEC 7816 standard, and may enable communication in accordance with the EMV protocol. The contactless card 101 may also include processing circuits, antennas, and other components, as further described in Figure 6B. These components may be located behind the contact pads 620 or elsewhere on the substrate 610, for example, in different layers of the substrate 610, and may be electrically and physically coupled with the contact pads 620. The contactless card 101 may also include magnetic strips or magnetic tapes, which may be located on the back of the card (not shown in Figure 6A). The contactless card 101 may also include a Near Field Communication (NFC) device coupled with an antenna that can communicate via the NFC protocol. The embodiments are not limited to these.

[0065] As shown in the illustration, the contact pads 620 of the contactless card 101 may include a processing circuit 625 for storing, processing, and communicating information, which includes a processor 630, memory 102, and one or more communication interfaces 109. It is understood that the processing circuit 625 may include additional components, as necessary to perform the functions described herein, including a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitives, and tamper-proof hardware.

[0066] Memory 102 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 101 may include one or more of these memories. Read-only memory may be programmable at the factory as read-only or one-time programmable. One-time programming allows it to be written once and read multiple times. Write-once / read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once programmed, the memory may not be rewritable but can be read multiple times. Read / write memory may be programmed and reprogrammed multiple times after leaving the factory. Read / write memory may be read multiple times after leaving the factory. In some cases, memory 102 may be encrypted memory that utilizes an encryption algorithm performed by the processor 630 to encrypt the data.

[0067] Memory 102 may be configured to store one or more applets 103, one or more counters 104, a master key 105, a diversified key 106, and a customer ID 107. One or more applets 103 may comprise one or more software applications configured to run on one or more contactless cards, such as a Java® card applet. However, it is understood that applet 103 is not limited to a Java® card applet, but could instead be any software application capable of running on a contactless card or other device with limited memory. One or more counters 104 may comprise numeric counters sufficient to store integers. The customer ID 107 may comprise a unique alphanumeric identifier assigned to a user of a contactless card 101, the identifier being able to distinguish a user of a contactless card from a user of another contactless card. In some examples, the customer ID 107 may identify both the customer and the account assigned to that customer, and further identify the contactless card 101 associated with the customer's account.

[0068] The processor 630 and memory elements of the exemplary embodiments described above are described with reference to the contact pad 620, but the disclosure is not limited thereto. It is understood that these elements may be implemented outside the contact pad 620, or completely separated from it, or may be implemented as additional elements in addition to the processor 630 and memory 102 elements located within the contact pad 620.

[0069] In some examples, the contactless card 101 may include one or more antennas 655. These antennas 655 may be positioned within the contactless card 101, around the processing circuit 625 of the contact pads 620. For example, one or more antennas 655 may be integrated with the processing circuit 625, or they may be used in conjunction with an external booster coil. In other examples, one or more antennas 655 may be located outside the contact pads 620 and the processing circuit 625.

[0070] In one embodiment, the coil of the contactless card 101 may function as the secondary side of an air-core transformer. A terminal may communicate with the contactless card 101 by disconnecting power or amplitude modulation. The contactless card 101 may infer data transmitted from the terminal using a gap in the power connection of the contactless card 101, which may be functionally maintained by one or more capacitors. The contactless card 101 may switch the load on the coil or return communication by load modulation. Load modulation may be detected in the terminal's coil by interference. More generally, using an antenna 655, a processor 630, and / or memory 102, the contactless card 101 provides a communication interface for communication via NFC, Bluetooth®, and / or Wi-Fi communication.

[0071] As described above, the contactless card 101 may be built on a software platform capable of running on other devices with limited memory, such as a smart card or JavaCard, and one or more applications or applets may be securely executed. An applet 103 may be added to the contactless card to provide a one-time password (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 103 may be configured to respond to one or more requests, such as a near-field wireless data exchange request from a reader (e.g., on a mobile device or point-of-sale terminal), and generate an NDEF message with a cryptographically secure OTP encoded as an NDEF text tag.

[0072] An example of NDEFOTP is the NDEF short record layout (SR=1). In such an example, one or more applets 103 may be configured to encode the OTP as a well-known type of text tag of NDEF type 6. In some examples, an NDEF message may consist of one or more records, such as ciphertext 148, 201, etc. Applet 103 may be configured to add one or more static tag records in addition to the OTP records.

[0073] In some examples, one or more applets 103 may be configured to emulate an RFID tag. The RFID tag may include one or more polymorphic tags. In some examples, each time the tag is read, different encrypted data may be presented that can indicate the authenticity of the contactless card 101. Based on one or more applets 103, the NFC reading of the tag is processed, the data is sent to a server such as a banking system server, and the data may be verified by the server.

[0074] In some examples, the contactless card 101 and the server 120 may contain specific data so that the card can be properly identified. The contactless card 101 may contain one or more unique identifiers (not shown). Each time a read operation is performed, the counter 104 may be configured to increment. In some examples, each time data is read from the contactless card 101 (for example, by a computing device 110), the counter 104 is sent to the server for verification, and it is determined whether the counter 104 is equal to a counter on the server (as part of the verification).

[0075] One or more counters 104 may be configured to prevent replay attacks. For example, if a ciphertext is retrieved and replayed, and a counter 104 is read, used, or otherwise passed, the ciphertext is immediately rejected. If a counter 104 has not been used, it can be replayed. In some examples, counters incremented on the card are different from counters incremented in transactions. Because there is no communication between applets 103 on the contactless card 101, the contactless card 101 cannot determine the application transaction counter 104. In some examples, the contactless card 101 may comprise a first applet 103-1 which may be a transaction applet and a second applet 103-2 which may be an authentication applet for authenticating the calls disclosed herein. Each applet 103-1 and 103-2 may comprise its respective counter 104.

[0076] In some examples, counter 104 may become out of sync. In some examples, counter 104 may increment to account for accidental reads that initiate a transaction, such as diagonal reads, but the application does not process counter 104. In some examples, when device 110 is woken up, NFC may be enabled and device 110 may be configured to read available tags, but no action is taken in response to the read.

[0077] To maintain the synchronization of counter 104, an application, such as a background application, may be run, which would be configured to detect when device 110 wakes up and to synchronize with a banking system server indicating that the reads resulting from the detection subsequently advance counter 104. In another example, a hashed one-time password may be used to allow for a window of synchronization misses. For example, if it is within a threshold of 10, counter 104 may be configured to advance. However, if it is within a different threshold number, for example, 10 or 1000, a request for resynchronization may be handled, which may be requested through one or more applications for the user to indicate one or more taps, gestures, or other methods via the user's device. If counter 104 is incrementing in the appropriate order, the user may be able to know that it has done so.

[0078] The key diversification techniques described herein with reference to counter 104, the master key, and the diversified key are examples of encryption and / or decryption of key diversification techniques. Since this disclosure is equally applicable to other types of key diversification techniques, this exemplary key diversification technique should not be considered limiting to the disclosure.

[0079] During the creation process of the contactless card 101, two encryption keys may be uniquely assigned to each card. The encryption keys may be symmetric keys that can be used for both encrypting and decrypting data. The Triple DES (3DES) algorithm may be used by EMV and implemented by the hardware of the contactless card 101. By using a key diversification process, one or more keys may be derived from the master key based on uniquely identifiable information of each entity that requires a key.

[0080] In some examples, to overcome vulnerabilities in the 3DES algorithm, session keys may be derived (e.g., a unique key per session) but without using a master key, instead using unique card-derived keys and counters as diversification data. For example, each time contactless card 101 is used in operation, a different key may be used to generate a message authentication code (MAC) and perform encryption. This results in three layers of encryption. Session keys may be generated by one or more applets and derived using application transaction counters with one or more algorithms (as defined in EMV6.3Book2A1.3.1 Common Session Key Derivation).

[0081] Furthermore, the increment for each card is unique and is assigned either by personalization or algorithmically by some identifying information. For example, odd-numbered cards may increment by 2, and even-numbered cards may increment by 5. In some examples, the increment may also vary with sequential reading, such as a single card incrementing sequentially as 1, 3, 5, 2, 2, ... A specific sequence or algorithmic sequence may be defined during personalization or from one or more processes derived from a unique identifier. This can make it difficult for a replay attacker to generalize from a small number of card instances.

[0082] The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In another example, the NDEF record may be encoded in hexadecimal format.

[0083] Figure 7 shows an NDEF short record layout (SR=1) data structure 700 according to an exemplary embodiment. One or more applets may be configured to encode OTPs as text tags of a known type of NDEF type 4. In some examples, an NDEF message may comprise one or more records. The applet may be configured to add one or more static tag records in addition to the OTP record. Exemplary tags include, but are not limited to, tag type: well-known type, text, encoding English (en); applet ID: D2760000850104; function: read-only access; encoding: authentication messages may be encoded as ASCII hexadecimal; type-long-value (TLV) data may be provided as personalization parameters that can be used to generate an NDEF message; and in one embodiment, an authentication template may comprise a first record having a well-known index for providing actual dynamic authentication data. In various embodiments, the payload of the data structure 700 may store ciphertexts (e.g., encrypted customer ID 107, ciphertext 148, and / or ciphertext 201) and any other relevant data.

[0084] The operation of the disclosed embodiments can be further described with reference to the following figures. Some figures may include logical flows. While such figures presented herein may include specific logical flows, it should be understood that the logical flows only provide examples of how the general functions described herein can be implemented. Furthermore, a given logical flow does not necessarily have to be performed in the order presented unless otherwise indicated. Moreover, in some implementations, not all actions shown in the logical flow are required. Furthermore, a given logical flow may be implemented by hardware elements, software elements executed by a processor, or any combination thereof. Embodiments are not limited to this context.

[0085] Figure 8 shows one embodiment of the logical flow 800. The logical flow 800 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 800 may include some or all of the operations for providing secure authentication to calls in a call center system using a contactless card 101. Embodiments are not limited to this context.

[0086] As shown, in block 810, the call center application 126 on server 120 receives a call from a client device. In block 815, the call center application 126 on server 120 determines that the phone number is associated with one or more accounts in the account database 124. In block 820, the call center application 126 on server 120 connects the call to an agent. The agent may be associated with an agent system 140 running an instance of the call center application 126. The agent may specify that the call center application 126 be used to generate a URL with a session ID in block 820. In block 825, the call center application 126 on server 120 and / or agent system 140 generates a session ID, e.g., a hash value, and includes the session ID as a parameter in the URL, e.g., URL 108. In block 830, the call center application 126 associates the session ID with the time limit, account, call, and / or agent in the account data 124.

[0087] In block 830, the call center application 126 of server 120 sends a URL with session ID 108 to a known contact record associated with the account. For example, the call center application 126 of server 120 may identify a mobile phone number in the account data 124 of the account and send the URL 108 to that phone number via an SMS message. As another example, the call center application 126 of server 120 may identify an email address associated with the account in the account data 124 and send the URL 108 in an email directed to that email address. In block 835, the web server 127 receives an HTTP request from the web browser 115 of device 110 specifying the URL generated in block 825.

[0088] In block 840, the call center application 126 of the web server 127 and / or server 120 determines that the session ID in the URL received in block 835 matches the session ID stored in the account data in block 830. The call center application 126 of server 120 and / or web server 127 may further determine that the amount of time elapsed since the generation of the session ID in block 825 and the receipt of the request in block 835 does not exceed the time threshold associated with the session ID. In block 845, the web server 127 sends the web page 134 associated with the URL 108 to the requesting device 110. In block 850, the web server 127 may send a request to authenticate the call via the web page 134 in the web browser 115. Doing so may generally instruct the user to tap a contactless card 101 on the device 110. However, in some embodiments, the request is contained in or included with the web page sent in block 845.

[0089] In block 855, web page 134 and / or web browser 115 read the ciphertext generated by contactless card 101. In block 860, web server 127 receives the ciphertext from web page 134 and / or web browser 115. The ciphertext may include instructions indicating that the ciphertext was read from contactless card 101 by web page 134 and / or web browser 115. In block 865, web server 127 and / or call center application 126 of server 120 determine that the amount of time elapsed since the generation of the session ID in block 825 and the receipt of the ciphertext in block 860 does not exceed the time threshold associated with the session ID.

[0090] In block 870, the authentication application 123 decrypts the ciphertext based on the master key 105 and counter value 104 of card 101, and the diversified key 106 generated based on these. In block 880, the web server 127, the call center application 126 of server 120, and / or the authentication application 123 may authenticate the account for the call received in block 805 based on the decryption of the ciphertext, the matching of the session ID stored in the URL 108 with the session ID, and the fact that the session ID has not expired. In block 885, the GUI of the call center application 126 of agent system 140 receives one or more attributes of the authenticated account and may display the attributes in the GUI based on the authentication in block 880.

[0091] Figure 9 shows one embodiment of the logical flow 900. The logical flow 900 may represent some or all of the operations performed by one or more embodiments described herein. For example, the logical flow 900 may include some or all of the operations for pre-authenticating a call using a contactless card 101. Embodiments are not limited to this context.

[0092] In block 905, the web browser 115 of device 110 accesses a web page 134 hosted by a web server 127. The web browser 115 may include one or more browser cookies 203 in the HTTP request to access the web page 134. Generally, the web page 134 accessed by the web browser 115 instructs the user to tap a contactless card 101 to initiate a pre-authenticated call. In block 910, the user taps the contactless card 101 on device 110. The web page 134 and / or the web browser 115 may then instruct the contactless card 101 to generate a ciphertext. The contactless card 101 may then generate a data package containing the ciphertext and an unencrypted customer identifier. In block 915, the web page 134 and / or the web browser 115 read the data package generated by the contactless card 101, for example, via NFC. The web page 134 and / or web browser 115 may then send the data package to the server 120 along with instructions indicating that the data package was read from the contactless card 101. As stated, the unencrypted customer identifier may consist of the customer ID 107 of the account, or any other unique identifier that enables the server 120 to identify the associated account, counter value 104, and / or master key 105 in the account data 124.

[0093] In block 920, the web server 127 verifies the cookie 203 received from the web browser 115. For example, the web server 127 may determine whether a valid hash value is stored in the cookie 203. In block 925, the web server 127 and / or the authentication application 123 decrypt the ciphertext based on the verification of the cookie 203. Generally, the web server 127 and / or the authentication application 123 may use the unencrypted customer ID 107 contained in the data package with the ciphertext to identify the master key 105 and the current counter value 104 in the account data 124. The web server 127 and / or the authentication application 123 may then increment the counter value and encrypt the master key 105 and the incremented counter value 104 to generate a diversified key 106. The generated diversified key 106 may be used to attempt to decrypt the ciphertext. If decryption is successful, the call center application 126, web server 127, and / or authentication application 123 of server 120 generate a session ID. In block 930, the session ID generated in block 925 is associated with an account in account data 124 and a time threshold is assigned. In block 935, the web server 127 sends a pre-authenticated phone number containing the session ID to the web browser 115. In doing so, the phone number is displayed in the web browser 115. When the user selects a phone number, the phone application 113 opens and initiates a call to the selected number.

[0094] In block 940, the call center application 126 on server 120 receives a call from client device 110 specifying a pre-authenticated telephone number. After a predetermined delay, client device 110 may further provide a session ID as input. The call center application 126 on server 120 can generally verify that the call was received on a pre-authenticated telephone number. In block 945, the call center application 126 on server 120 determines that the session ID provided as input during the call matches the session ID stored in account data 124. In block 950, the call center application 126 on server 120 determines that the call was received within the time threshold assigned to the session ID. In block 955, the call center application 126 on server 120 authenticates the call based on the decryption of the ciphertext, the determination that the telephone number was received on a pre-authenticated number, the fact that the session ID received as input matches the stored session ID, and that the time threshold assigned to the session ID has not expired. In block 960, the call center application 126 on server 120 connects the call directly to an agent. In block 965, the GUI of the call center application 126 on agent system 140 receives one or more attributes of the authenticated account and may display the attributes in the GUI based on the authentication in block 955.

[0095] Figure 10 shows one embodiment of an exemplary computer architecture 1000, including a computing system 1002 suitable for carrying out the various embodiments described above. In one embodiment, the computer architecture 1000 may include or be carried out as part of a computing system 100 or 200. In some embodiments, the computing system 1002 may represent, for example, a contactless card 101, a computing device 110, a server 120, and an agent device 140 of systems 100-200. Embodiments are not limited to this context. More generally, the computing architecture 1000 is configured to carry out all the logic, applications, systems, methods, apparatus, and functions described herein with reference to Figures 1A-9.

[0096] As used in this application, the terms “system” and “component” are intended to refer to any computer-related entity, whether hardware, a combination of hardware and software, software, or software in operation, examples of which are provided by the exemplary computing computer architecture 1000. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, an execution thread, a program, and / or a computer. For example, both an application running on a server and the server itself may be components. One or more components may reside within a process and / or an execution thread, and components may be localized to one computer and / or distributed across two or more computers. Furthermore, components may be coupled together in a communicative manner by various types of communication media and their operation may be coordinated. Coordination may include the one-way or two-way exchange of information. For example, components may communicate information in the form of signals communicated over a communication medium. Information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may use data messages as an alternative. Such data messages can be transmitted over various connections. Examples of connections include parallel interfaces, serial interfaces, and bus interfaces.

[0097] Computing architecture 1000 includes a variety of common computing elements such as one or more processors, multicore processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, and power supplies. However, embodiments are not limited to those of computing architecture 1000.

[0098] As shown in Figure 10, the computing architecture 1000 includes a processor 1012, system memory 1004, and system bus 1006. The processor 1012 may be any of various commercially available processors.

[0099] System bus 1006 provides an interface for system components, including but not limited to system memory 1004, to the processor 1012. System bus 1006 can be one of several types of bus structures that can further interconnect to the memory bus (with or without a memory controller), peripheral bus, and local bus using any of various commercially available bus architectures. Interface adapters can connect to system bus 1008 via slot architectures. Examples of slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, Industry Standard Architecture ((E)ISA), Microchannel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extensible) (PCI(X)), PCI Express, and the International Personal Computer Memory Card Association (PCMCIA).

[0100] The computing architecture 1000 may include or implement a variety of products. These products may include computer-readable storage media for storing logic. Examples of computer-readable storage media may include any tangible media capable of storing electronic data, such as volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, and writable or rewritable memory. Examples of logic may include executable computer program instructions implemented using any appropriate type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, and visual code. Embodiments may also be implemented, at least in part, as instructions contained in or on non-temporary computer-readable media, which may be read and executed by one or more processors to enable the execution of the operations described herein.

[0101] System memory 1004 may include various types of computer-readable storage media in the form of one or more high-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, ferroelectric polymer memory, ovonic memory, polymer memory such as phase-change or ferroelectric memory, silicon oxide nitride (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drives (SSDs)), and other types of storage media suitable for storing information. In the illustrated embodiment shown in Figure 10, system memory 1004 may include non-volatile memory 1010 and / or volatile memory 1012. The non-volatile memory 1010 may store the basic input / output system (BIOS).

[0102] The computer 1002 may include various types of computer-readable storage media in the form of one or more low-speed memory units, including an internal (or external) hard disk drive 1030, a magnetic disk drive 1016 for reading from or writing to a removable magnetic disk 1020, and an optical disk drive 1028 for reading from or writing to a removable optical disk 1032 (e.g., a CD-ROM or DVD). The hard disk drive 1030, the magnetic disk drive 1016, and the optical disk drive 1028 may be connected to the system bus 1006 by an HDD interface 1014, an FDD interface 1018, and an optical disk drive interface 1034, respectively. The HDD interface 1014 for external drive implementation may include at least one or both of the Universal Serial Bus (USB) and IEEE 1394 interface technologies.

[0103] The drive and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer executable instructions, etc. For example, several program modules, including an operating system 1022, one or more applications 1042, other program modules 1024, and program data 1026, may be stored in the drive and non-volatile memory 1010 and volatile memory 1012. In one embodiment, one or more applications 1042, other program modules 1024, and program data 1026 may include various applications and / or components of system 100-200, such as an applet 103, a counter 104, a master key 105, a diversified key 106, a customer ID 107, a telephone application 113, a web browser 115, a URL 108, ciphertext 148, ciphertext 201, a cookie 203, an authentication application 123, account data 124, a call center application 126, a web server 127, and a web page 134.

[0104] The user may input commands and information to the computer 1002 via one or more wired / wireless input devices, such as a pointing device like a keyboard 1050 and a mouse 1052. Other input devices may include a microphone, infrared (IR) remote control, radio frequency (RF) remote control, gamepad, stylus pen, card reader, dongle, fingerprint reader, grab, graphics tablet, joystick, keyboard, retina reader, touchscreen (e.g., capacitive, resistive, etc.), trackball, trackpad, sensor, stylus, etc. These and other input devices are often connected to the processor 1012 via an input device interface 1036 coupled to the system bus 1006, but may also be connected via other interfaces such as a parallel port, IEEE 1394 serial port, game port, USB port, or IR interface.

[0105] Monitor 1044 or other types of display devices are also connected to the system bus 1006 via an interface such as a video adapter 1046. Monitor 1044 may be located inside or outside the computer 1002. In addition to Monitor 1044, the computer typically includes other peripheral output devices such as speakers and printers.

[0106] Computer 1002 may operate in a network environment using logical connections via wired and / or wireless communication to one or more remote computers, such as remote computer 1048. Remote computer 1048 could be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node, typically containing many or all of the elements described in relation to computer 1002, but for brevity, only memory and / or storage device 1058 is shown. The logical connections shown include wired / wireless connections to a local area network 1056 and / or a larger network, such as a wide area network 1054. Such LAN and WAN network environments are common in offices and businesses and facilitate enterprise-scale computer networks such as intranets. All of these may connect to global communication networks, such as the Internet.

[0107] When used in a local area network 1056 networking environment, the computer 1002 connects to the local area network 1056 via a wired and / or wireless network interface or network adapter 1038. The network adapter 1038 may facilitate wired and / or wireless communication to the local area network 1056, which may include wireless access points placed on it to communicate with the wireless capabilities of the network adapter 1038.

[0108] When used in a wide area network 1054 networking environment, computer 1002 may include a modem 1040, or be connected to a communication server on the wide area network 1054, or have other means for establishing communication on the wide area network 1054, such as via the Internet. The modem 1040 may be internal or external, wired and / or wireless, and connect to the system bus 1006 via an input device interface 1036. In a network environment, the program modules, or parts thereof, shown with respect to computer 1002 may be stored in remote memory and / or storage device 1058. The shown network connections are illustrative, and it will be understood that other means can be used to establish communication links between computers.

[0109] Computer 1002 is capable of communicating with wired and wireless devices or entities using the IEEE 802 standard family, such as wireless devices configured to operate wirelessly (e.g., IEEE 802.11 wireless modulation technology). This includes at least Wi-Fi (or Wireless Fidelity), WiMAX, and Bluetooth® wireless technologies. Thus, communication can be a predefined structure, similar to conventional networks, or simply ad-hoc communication between at least two devices. Wi-Fi networks provide secure, reliable, and high-speed wireless connectivity using wireless technologies called IEEE 802.11 (a, b, g, n, etc.). Wi-Fi networks can be used to connect computers to each other, to connect to the Internet, or to wired networks (using IEEE 802.3 related media and functions).

[0110] Referring to Figures 1A to 10, the various elements of the device described above may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application programming interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, the decision of whether an embodiment is implemented using hardware and / or software elements may vary, depending on the requirements of a particular implementation, according to any number of factors such as desired computing speed, power level, heat resistance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

[0111] One or more aspects of at least one embodiment can be implemented by representative instructions stored in a machine-readable medium representing various logics within a processor, which, when read by a machine, produce logic that performs the techniques described herein. Such representations, known as "IP cores," are stored in tangible machine-readable medium and provided to various customers or manufacturing facilities for loading into manufacturing machines that create logic or processors. Some embodiments can be implemented using, for example, a machine-readable medium or article that can store instructions or a set of instructions that, when executed by a machine, can cause a machine to perform methods and / or operations according to the embodiment. Such machines can include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and can be implemented using any suitable combination of hardware and / or software. Machine-readable media or articles may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disks, floppy disks, compact disk read-only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewritable (CD-RW), optical disks, magnetic media, magneto-optical media, removable memory cards or disks, various digital versatile disks (DVDs), tapes, cassettes, etc. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, cryptographic code, etc., and may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0112] The foregoing description of exemplary embodiments is provided for illustrative and explanatory purposes only. It is not intended to be exhaustive or to limit this disclosure to the exact form disclosed. Many modifications and changes are possible in light of this disclosure. The scope of this disclosure is intended to be limited by the appended claims rather than by this detailed description. Future applications claiming priority to this application may assert the disclosed subject matter in different ways and may generally include any set of one or more limitations, as variously disclosed or demonstrated herein.

Claims

1. The server receives a call from the client device, The server generates a uniform resource locator (URL) that includes the session identifier as a parameter, The server associates the session identifier with the account, The server transmits the URL to the client device, The server receives a request including the URL from the web browser of the client device, The server determines that the session identifier of the URL in the request matches the session identifier associated with the account, The server sends the web page associated with the URL to the web browser, The server receives the encrypted text read by the web page from the web browser via the card reader of the client device, The server decrypts the ciphertext, The server authenticates the account for the call based on the decryption of the ciphertext and the session identifier of the URL that matches the session identifier associated with the account. The server provides one or more attributes of the account to the graphical user interface displayed on the agent system assigned to the call, based on the authentication of the account. A method that includes this.

2. The method described above, before receiving the ciphertext, The server sends a request to the web page of the web browser to authenticate the account for the call. The method according to claim 1, further comprising:

3. The method described above, before authenticating the account for the call, The server receives an instruction from the web page of the web browser indicating that the ciphertext has been read from the contactless card via the card reader of the client device. The method according to claim 1, further comprising:

4. The URL is sent to the phone number associated with the account in the account database, and the method is The server decides to receive a call from the telephone number associated with the account in the account database. The method according to claim 1, further comprising:

5. The aforementioned method, The server assigns a time threshold to the session identifier, The server determines that the elapsed time between the generation of the session identifier and the receipt of the request including the URL does not exceed the time threshold, The method according to claim 1, further comprising:

6. The method according to claim 1, wherein the ciphertext includes Near Field Communication (NFC) Forum Data Exchange Format (NDEF) tags.

7. The aforementioned method, The server increments the counter value associated with the account, The server generates diversified keys based on the counter value and the master key associated with the account, Decrypting the ciphertext using the diversified key, The method according to claim 1, further comprising:

8. Processor and A server comprising a memory for storing instructions, wherein when an instruction is executed by the processor, the processor receives Receiving calls from client devices, This involves generating a uniform resource locator (URL) that includes the session identifier as a parameter, Associating the aforementioned session identifier with the account, Sending the aforementioned URL to the client device, The client device receives a request including the URL from its web browser, Determining that the session identifier of the URL in the request matches the session identifier associated with the account, Sending the web page associated with the URL to the web browser, The web browser receives the encrypted text read by the web page via the card reader of the client device, Decrypting the aforementioned ciphertext, Authenticating the account for the call based on the decryption of the ciphertext and the session identifier of the URL that matches the session identifier associated with the account, Based on the authentication of the account, one or more attributes of the account are provided to the graphical user interface displayed on the agent system assigned to the call. A server that executes commands.

9. The memory stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. Sending a request to authenticate the account for the aforementioned call to the web page of the web browser, The server according to claim 8, which causes the server to execute.

10. The memory stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. The web browser receives an instruction from the web page that indicates that the ciphertext has been read from the contactless card via the card reader of the client device. The server according to claim 8, which causes the server to execute.

11. The memory stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. Determining that a call has been received from the telephone number associated with the account in the account database, wherein the URL is sent to the telephone number associated with the account in the account database. The server according to claim 8, which causes the server to execute.

12. The memory stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. Assigning a time threshold to the aforementioned session identifier, Determine that the elapsed time between the generation of the session identifier and the receipt of the request including the URL does not exceed the time threshold, The server according to claim 8, which causes the server to execute.

13. The server according to claim 8, wherein the ciphertext includes Near Field Communication (NFC) Forum Data Exchange Format (NDEF) tags.

14. The memory stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. Increment the counter value associated with the aforementioned account, Based on the counter value and the master key associated with the account, a diversified key is generated. Decrypting the ciphertext using the diversified key, The server according to claim 8, which causes the server to execute.

15. A non-temporary computer-readable storage medium for storing instructions, wherein when an instruction is executed by a processor provided by a server, the processor receives the instructions. Receiving calls from client devices, This involves generating a uniform resource locator (URL) that includes the session identifier as a parameter, Associating the aforementioned session identifier with the account, Sending the aforementioned URL to the client device, The client device receives a request including the URL from its web browser, Determining that the session identifier of the URL in the request matches the session identifier associated with the account, Sending the web page associated with the URL to the web browser, The web browser receives the encrypted text read by the web page via the card reader of the client device, Decrypting the aforementioned ciphertext, Authenticating the account for the call based on the decryption of the ciphertext and the session identifier of the URL that matches the session identifier associated with the account, Based on the authentication of the account, one or more attributes of the account are provided to the graphical user interface displayed on the agent system assigned to the call. A computer-readable storage medium that enables execution of [something].

16. The computer-readable storage medium stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. Sending a request to authenticate the account for the aforementioned call to the web page of the web browser, A computer-readable storage medium according to claim 15, which enables the execution of the above.

17. The computer-readable storage medium stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. The web browser receives an instruction from the web page that indicates that the ciphertext has been read from the contactless card via the card reader of the client device. A computer-readable storage medium according to claim 15, which enables the execution of the above.

18. The computer-readable storage medium stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. Determining that a call has been received from the telephone number associated with the account in the account database, wherein the URL is sent to the telephone number associated with the account in the account database. A computer-readable storage medium according to claim 15, which enables the execution of the above.

19. The computer-readable storage medium stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. Assigning a time threshold to the aforementioned session identifier, Determine that the elapsed time between the generation of the session identifier and the receipt of the request including the URL does not exceed the time threshold, A computer-readable storage medium according to claim 15, which enables the execution of the above.

20. The computer-readable storage medium stores instructions, and when an instruction is executed by the processor, the processor receives the instructions. Increment the counter value associated with the aforementioned account, Based on the counter value and the master key associated with the account, a diversified key is generated. Decrypting the ciphertext using the diversified key, wherein the ciphertext includes Near Field Communication (NFC) Forum Data Exchange Format (NDEF) tags, A computer-readable storage medium according to claim 15, which enables the execution of the above.

Images