Technology for performing dynamic call center authentication using a contactless card

Abstract

Techniques and systems for performing authentication using mini-applications

Description

Background Art

[0001] Service providers typically provide call center services to allow customers to access their accounts, change, delete, or manage them in other ways. From a security perspective, the call center can be the riskiest area for a company. This is because call center transactions can expose customers' confidential information to malicious third parties.

[0002] Call centers face both internal and external risks. Internal risks include the theft of confidential customer information by employees. During typical authentication processes, call center employees have direct access to highly confidential customer data. Call centers may be outsourced, and the turnover rate of call center employees is high. As a result, companies are constantly at risk of departing or remote employees inappropriately retaining customer information.

[0003] External risks include risks posed by "spoofing" and "phishing". Fraudsters attempt to disguise themselves as customers by masking or changing incoming numbers, email addresses, IP addresses, etc., and steal information or funds. Hackers also monitor the communications of service providers, especially call center communications, posing an external risk of stealing customer information.

[0004] The Payment Card Industry Security Standards Council (PCI SSC) manages the continuous evolution of the Payment Card Industry (PCI) security standards to address these security concerns. Service providers are responsible for enforcing compliance with the PCI standards to protect highly confidential customer data. For example, the PCI standards define authentication criteria that should be followed before a client permits access to and / or modification of customer account information. A call center may request authentication of the client in the form of password exchange, answers to personal questions, biometric data, etc. Customers may be prompted multiple times to provide authentication information in various forms during the course of a call. Such authentication and re - authentication processes not only irritate customers and reduce the credibility of the service provider, but each authentication instance potentially exposes the customer's confidential information to malicious parties.

Summary of the Invention

[0005] In one aspect, an embodiment includes a computer - implemented method, which includes steps of establishing, by a call center system, a call connection with a mobile device; determining, by the call center system, a call session identifier for the call connection and a telephone number associated with the mobile device; transmitting, by the call center system, a text message including the call session identifier and a mini - application link configured to obtain a code snippet from a server by the mobile device, based on the telephone number, to the mobile device; receiving, by the call center system, authentication information generated by a contactless card and the call session identifier from the mobile device; determining, by the call center system, that the authentication information is genuine; and enabling, by the call center system, the call connection to continue for communication.

[0006] In one aspect, the call center system includes a processing circuit. The call center system further includes a memory for storing instructions. When executed by the processing circuit, the instructions cause the processing circuit to determine a call connection with a mobile device, determine a phone number associated with the mobile device, send a text message including a mini-application link configured to obtain a code snippet by the mobile device to the mobile device based on the phone number, receive authentication information generated by a contactless card from the mobile device, determine that the authentication information is authentic, and based on the authentication information being authentic, enable the call connection to be continued for communication.

[0007] In one aspect, embodiments of a system and device for implementing a computer-implemented method and a technology including the computer-implemented method include steps of establishing, by a mobile device, a call connection with a call center system; receiving, by the mobile device, a text message including a call session identifier and a mini-application link configured to obtain a code snippet from a server; receiving, by the mobile device, the code snippet from the server; executing, by the mobile device, a code snippet that causes a prompt to be displayed on a display of the mobile device and prompts to tap a contactless card on or near the mobile device; receiving, by the mobile device, authentication information from the contactless card based on a tap of the contactless card on or near the mobile device; sending, by the mobile device, the authentication information and the call session identifier; and maintaining, by the mobile device, a call connection with the call center system based on a display indicating that the authentication information has been authenticated.

Brief Description of the Drawings

[0008] To easily identify the discussion regarding a particular element or operation, the most significant digit or number of the reference number refers to the figure number in which the element was first introduced.

[0009]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Best Mode for Carrying Out the Invention

[0010] Embodiments generally relate to systems and techniques for performing secure authentication operations using a mini - application that operates on a customer's device, such as a mobile device or a cellular phone. Thus, these techniques enable performing secure authentication operations via the device without downloading a large - scale full - application, and improve upon conventional technical solutions by minimizing the download time and storage space required for the application.

[0011] For example, customer authentication may be required during a help call or a customer service call. The techniques discussed herein include sending a text message that includes a link to the mini - application to a device associated with the customer. The mini - application is downloaded and executed on the customer's device to perform the authentication. As explained, the mini - application may include minimal executable instructions for performing the authentication. In one example, the authentication is performed with the customer's contactless card. The customer may be asked to bring the card within the communication range of the device and, for example, tap the card on the device. This initiates data exchange between the device and the contactless card. As part of the exchange, the card transmits authentication information and / or the device acquires authentication information. The device may then send the authentication information to the system to perform the customer's authentication. Based on the result of the authentication, the call may be permitted to continue or cancelled. These and other details will become more apparent in the following description.

[0012] FIG. 1 shows an example of a system 100 according to an embodiment discussed herein. The illustrated system 100 is a simplified illustration for discussion purposes, and in an implementation, the system 100 includes additional components not shown, such as networking components, additional servers, and processing devices.

[0013] The illustrated system 100 includes components and devices for performing and processing call center communications and for simply and quickly verifying callers who call the call center, as compared to conventional authentication techniques. As described above, the embodiments discussed herein provide advantages over conventional systems by enabling customers to call a call center and authenticate themselves using a contactless card without installing a complete mobile application on a mobile device or another client device.

[0014] The call center system 106 is configured to provide call center services to callers regarding products or services. In one example, the call center system 106 is implemented as part of a banking system and is configured to provide call center services to bank customers. Thus, in some examples, the call center system may handle confidential information that requires the caller to be authenticated before discussion. The call center system 106 may include any number of components so that multiple operators or call agents can handle calls and provide call center support. In FIG. 1, the call center system 106 includes a call server 108 and an authentication server 110. The call server 108 may be configured to provide call center services. Call center services may include handling calls and establishing call connections with other devices, providing a user interface for support staff and operators, accessing information and data for supporting calls, determining that customer authentication is required, initiating an authentication operation, and the like. It should be noted that the call server 108 may be a number of servers and other computing devices and equipment.

[0015] The authentication server 110 may perform the authentication operation of the call center system 106. In an embodiment, the authentication server 110 may include a number of servers, other computing devices, and components. The authentication server 110 may be configured to perform the authentication operation by registering a pending authentication operation and comparing the authentication information provided by the calling party with the authenticated information held, for example, in a data store, by the authentication server 110. The authentication server 110 may return the result of the authentication operation to the call server 108 for use in determining whether to continue the call.

[0016] In an embodiment, the call center system 106 is configured to handle phone calls from any type of telephone device, such as the mobile device 102, the telephone 118, or any other device used to make a phone call. Further, the call center system 106 may be configured to handle calls according to various protocols, such as the plain old telephone system (POTs 120) and the protocols required to handle calls on a voice over internet protocol (VoIP) system via the network 104, which may include cellular communication protocols and fixed telephone protocols.

[0017] In a specific example, the call center system 106 including the call server 108 receives or initiates a call with a device and establishes a call connection with the device. Once established, the call server 108 may determine that an authentication routine or operation is required to support the call. For example, the call may involve handling secure information such as a bank account. The call server 108 may register the pending authentication with the authentication server 110 and initiate an authentication routine to authenticate the calling party or user.

[0018] The authentication server 110 may perform an authentication operation including collecting information from the caller. As described in this specification, the call center system 106 including the authentication server 110 may execute an authentication routine using a mini-application or code snippet such as Apple's (registered trademark) App Clip (registered trademark) or Google's (registered trademark) Instant App (registered trademark), and collect authentication information from the caller. Using a mini-application or code snippet improves the prior art. This is because the call center system 106 can collect data from the caller safely and electronically without the caller installing a difficult-to-handle application that requires a long time. The mini-application or code snippet is specially adjusted to perform operations for collecting authentication information and provide the information to the authentication server 110 for further processing.

[0019] To provide a mini-application or code snippet to the customer, the call center system 106 including the call server 108 may register an authentication operation with the authentication server 110, notify the authentication server 110 of the pending authentication, and generate a call session identifier associated with the authentication operation. Specifically, the call server may make an application programming interface (API) call to the authentication server and associate a unique identifier of the caller, for example, a portable unique identifier (pUID), with the pending authentication executed by the authentication server. The authentication server may generate a session token or call session identifier for the pending authentication and return the call session identifier to the call server in response to the API call. The call session identifier may be provided in a text message for transmission to the mobile device. The call session identifier may be any unique combination of alphanumeric characters used to uniquely identify the pending authentication operation by the authentication server 110. The call session identifier may be an identifier that can be used only once, and each of the pending authentication operations may be associated with a different identifier.

[0020] The call server 108 may generate a text message that includes a link for downloading and / or starting a mini-application on a device associated with the caller. The text message may be communicated according to any messaging protocol, such as, for example, Short Message Service (SMS), Multimedia Messaging Service (MMS), Rich Communication Service (RCS), and the like. The link may be a Uniform Resource Locator (URL) link to a location where the mini-application is downloaded, such as the address of a server. In some embodiments, the link may point to the server 114 of the application store system 112, and the device may download the mini-application or code snippet from the application store system 112. In other embodiments, the call center system 106 may hold the mini-application, and the user's device may download it from the call center system 106.

[0021] The call server 108 can send a text message to a device associated with the caller. In some examples, the call server 108 may send it to a device such as the mobile device 102 while the caller is on the call. However, in other examples, the calling device, such as the phone 118, may not have a text messaging function, and the call server 108 may determine another device associated with the caller, such as another mobile device or another computing device, and send the text message. To determine the device to send the message, the call server 108 may utilize the phone number associated with the call connection. For example, the call server 108 may determine the call number associated with the call connection to the mobile device 102 and send a text message to the mobile device 102. In other examples, the call center system 106 may execute a lookup to determine another device to send the text message using the call number associated with the call connection to the phone 118. In embodiments, other information may be used to determine the device to send the message. For example, the caller may provide information such as a name, address, account number, etc.

[0022] In embodiments, a device such as the mobile device 102 may receive a text message from the call server 108 for performing authentication. The text message includes a link selectable by the user. For example, the caller can select the link using a touch screen interface or other input device. The messaging program may be configured to process the link. For example, it may be configured to launch an application to download a mini-application, automatically download the mini-application, or launch the mini-application.

[0023] In some examples, the text message may include a call session identifier. The call session identifier may be appended to a part of the text message. In some examples, it may be embedded in a link, and in other examples, it may be separated from the link. In some embodiments, the device may receive the call session identifier in another text message. The call session identifier may be a unique identifier associated with an authentication operation and may be returned together with authentication information for the authentication server 110 to perform authentication.

[0024] In an embodiment, the selectable link may include an address to a server such as server 114 of the application store system 112 for downloading a mini-application or code snippet configured to perform authentication. When selected, the mobile device 102 may automatically download and execute the mini-application. In some examples, the mobile device 102 may already have downloaded the mini-application, for example, from a previous authentication attempt, and the mini-application is executed when the link is selected.

[0025] The mini-application or code snippet is configured to be executed on the mobile device 102 and may include instructions to perform a single or limited number of operations. Generally, the mini-application is much smaller in size than a full-size application, requires less memory to execute, and can be downloaded more quickly, making it more beneficial than conventional solutions.

[0026] According to an embodiment, the mini - applications or code snippets discussed herein may include instructions to cause a mobile device to display a prompt on the display of the mobile device for a user to provide a contactless card on or near the mobile device, and to perform a wireless communication exchange with the contactless card 116, e.g., near - field communication (NFC), on the mobile device to receive authentication information. The instructions may be configured to cause the mobile device 102 to communicate the authentication information and optionally a call session identifier to the authentication server 110. The code snippet may be configured to securely communicate the authentication information to the authentication server 110, e.g., in an API call, using an application programming interface (API) provided by the authentication server 110. In some examples, the mobile device 102 may send a call session identifier to the authentication server 110 along with the authentication information. The authentication server 110 can associate the authentication information with specific hold / registration and authentication routines. The mini - application or code snippet may include additional instructions to enable the execution of these operations, e.g., files or runtime libraries necessary for the execution of the operations.

[0027] The authentication server 110 may process the authentication information to determine whether the authentication information is genuine. In an embodiment, the authentication server 110 receives the authentication information and the call session identifier from the mobile device 102, determines the authenticated information associated with the contactless card / caller, compares the authentication information with the authenticated information, and determines whether they match. In an embodiment, the authentication server 110 may use the call session identifier to determine the authenticated information associated with the contactless card or the caller. For example, the authentication server 110 can perform a lookup based on the call session identifier and determine and retrieve the authenticated information from the data store. The data store may be any type of data store, such as a database configured to store the authenticated information related to the customer and the customer's contactless card. In some examples, the call session identifier may be used to determine additional information related to the caller, such as the account number, name, address, etc., and perform a lookup. This information may be associated with the call session identifier when the authentication operation is registered.

[0028] In an embodiment, the authentication server 110 compares the authenticated information with the authentication information received from the mobile device 102. If they match, the authentication server 110 authenticates the contactless card and notifies the call server 108 and the operator. If they do not match, the authentication server 110 does not authenticate the contactless card and notifies the call server 108 and the operator. In some examples, the authentication information is encrypted, and the authentication server 110 may first decrypt the authentication information using a session key derived from the master key, as described herein, for example, in FIGS. 12 to 14. When the authentication information is authenticated, 106 enables the continuation of the call and maintains the call connection. If the authentication information is not authenticated, the call connection is cancelled or disconnected. In FIGS. 6 to 14, further details regarding performing authentication using the data of the contactless card 116 and the authentication server are described.

[0029] In some embodiments, the caller performs an authentication operation to authenticate the operator of the call center system 106. In one example, the caller may send a code, such as a text message containing an alphanumeric sequence, to the call center system 106. The code may be displayed to the operator, and the operator may read back the code. In an embodiment, the caller may send a text message to a known phone number associated with the call center system 106 that is known to be secure and / or legitimate. If the operator is not authenticated, the caller may decide to end the call connection. Alternatively, if the operator is authenticated, the caller may decide to maintain the call connection.

[0030] Figures 2A and 2B show examples of sequence flows 200a and 200b that are executed according to embodiments to authenticate a caller by a call center. In addition to authenticating the caller, Figure 2B extends the sequence and includes authentication of the operator by the caller.

[0031] In an embodiment, at line 202, the call is initiated between the mobile device 102 and the call server 108. The call may be initiated by the mobile device 102 or the call server 108, but the embodiments are not limited to this method. Initiating the call may include establishing a call connection between the mobile device 102 and the call server 108. Thus, the call may be made by a POTs system, a VoIP system, or a combination thereof. Further, the embodiments are not limited to calls with mobile devices, and the call may be made with an old-fashioned telephone and / or a non-mobile device.

[0032] At line 204, the sequence includes the call server 108 sending a text message including a mini-application link to the call server 108. Although not illustrated in this aspect, the call server 108 may, in parallel, register an authentication on hold for the call with the authentication server 110 at line 206. In some examples, the call server 108 may first register the authentication and receive a call session identifier to include in the text message. In other examples, the call server 108 may send a second message including the call session identifier to the mobile device 102.

[0033] Registering the authentication operation may include generating a call session identifier and determining the authenticated information associated with the call. For example, the authentication server 110 may determine the information to be authenticated based on information associated with the call, such as a phone number, caller name, account number, address.

[0034] At line 208, the sequence includes the mobile device 102 downloading a code snippet from a server 114, such as an app store server. In an embodiment, the code snippet may be downloaded based on the user of the mobile device 102 selecting the mini-app link within the text message sent by the call server 108. The code snippet may be configured to execute on the mobile device 102 to perform an authentication operation. For example, the code snippet may cause the mobile device 102 to display a message for tapping a contactless card. At line 210, the caller taps a contactless card on the mobile device 102, and the mobile device 102 may receive authentication information from the card as previously described. Further, at line 210, the mobile device sends the authentication information to the authentication server 110. The mobile device 102 may send the call session identifier to the authentication server 110 along with the authentication information.

[0035] The authentication server 110 can perform an authentication operation on the authentication information. For example, the authentication server 110 compares the authentication information with the authenticated information. If the two match, the authentication server 110 may authenticate the authentication information, but if they do not match, the authentication server 110 may not need to authenticate the authentication information. At line 212, the authentication server 110 returns the authentication result to the call server 108.

[0036] At line 214, based on the authenticated authentication information, the call connection between the mobile device 102 and the call server 108 is maintained. If the authentication information is not authenticated, the call connection between the mobile device 102 and the call server 108 ends.

[0037] Sequence diagram 200b shows a flow similar to sequence diagram 200a, but the caller may perform an authentication step to authenticate the operator. For example, at line 216, the caller and the mobile device 102 can communicate a secret code to the call server 108. The call server 108 may present the secret code to the operator of the call server 108. The operator reads the code back via the voice connection, and the caller can confirm the authentication of the operator. For example, at line 218, the mobile device 102 may send an indication of the result of the operator authentication server 114. Embodiments are not limited to the specific sequences shown in FIGS. 2a / 2b. In some examples, one or more operations may be performed before other operations.

[0038] Figure 3 shows an example of routine 300 that the systems discussed in this specification may execute. For example, a call center system including one or more servers may execute one or more of the following options. In some examples, one or more operations may be performed by different servers and / or systems. For example, a call server may process one or more operations for call connection, and an authentication server may execute one or more operations to authenticate the calling party. In other examples, the operations may be performed on a single server or computing device, or on multiple servers or computing devices.

[0039] In block 302, routine 300 includes establishing a call connection with a mobile device. For example, the call center system establishes a call connection with the mobile device based on the mobile device calling a help line or contact number. In other examples, the call center system generates a call connection with the mobile device. The call connection is made via any type of voice communication protocol or connection, such as Plain Old Telephone Service (POTS), cellular protocol, WiFi protocol, Voice over Internet Protocol (VoIP), etc.

[0040] In an embodiment, the call center system may first determine to perform one or more authentication operations to authenticate the caller using a mobile device. In block 304, routine 300 includes determining a call session identifier for a call connection and a phone number associated with the mobile device. To determine the call session identifier, a call server of the call center system may communicate with an authentication server of the authentication system to register the call connection. Specifically, the call server may make an application programming interface (API) call to the authentication server and associate a unique identifier of the caller, such as a portable unique identifier (pUID), with the pending authentication performed by the authentication server. The authentication server may generate a session token or a call session identifier for the pending authentication and return the call session identifier to the call server in response to the API call. The call session identifier may be used by the authentication server to identify which pending authentication to perform and where to return the authentication result.

[0041] The call center system may determine a phone number associated with the call connection. For example, the call center system may determine the phone number based on information of the call itself. In another example, the call center system may perform an account lookup based on information provided by the caller. In a third example, the caller may provide the phone number, for example, via voice input or touchpad input. The phone number is used to return communication to the mobile device.

[0042] For example, in block 306, routine 300 includes sending a text message to a mobile device based on a phone number. The text message may include a call session identifier and a mini - application link. The mini - application link is configured to cause the mobile device to obtain a code snippet from a server. In an embodiment, the mini - application link may be a Uniform Resource Locator (URL) to an address of a server for downloading a mini - application. The server may be part of an application store such as Google's Play store or Apple's App Store. In other examples, the server may be part of a call center system, and embodiments are not limited in this regard.

[0043] In an embodiment, the mini - application may be a code snippet configured to be executed on a mobile device, such as a part of executable code. In some examples, the mini - application may be Apple's App Clip or Android's Instant App. However, embodiments are not limited to these examples.

[0044] As described in more detail in FIG. 4, the mobile device may download or obtain the code snippet and execute the code snippet. The code snippet can perform one or more operations on the mobile device. These operations include determining authentication information and sending the authentication information to a call center system, such as an authentication server, to authenticate the authentication information. In some examples, the mobile device may send the call session identifier along with the authentication information to the call center system so that the authentication information can be associated with a pending authentication operation or request.

[0045] In block 308, routine 300 includes receiving authentication information and a call session identifier from a mobile device. In some examples, the authentication information and the call session identifier are received by an authentication server. In block 310, routine 300 determines that the authentication information is authentic. For example, the authentication server compares the authentication information with the stored authentication information. As described above, the call session identifier may be associated with the calling party (pUID) and a particular authentication operation during the registration process. The authentication server may utilize the call session identifier to determine the authentic information associated with the calling party by performing a lookup in a data store.

[0046] In an embodiment, the result of the comparison is returned to a call center server or another device, and based on the result, the call connection may be maintained or blocked. In this example, the authentication information is successfully authenticated. In block 312, routine 300 includes enabling the continuation of the call connection for communication.

[0047] FIG. 4 shows an example of a routine 400 executed in accordance with the embodiments discussed herein. In some examples, routine 400 may be executed by a computing device such as a mobile phone or a mobile device. Embodiments are not limited to these examples.

[0048] In block 402, routine 400 includes establishing a call connection with a call center system. The call connection may be established based on the calling party using a mobile device to call the call center system. In other examples, the call connection may be established by the call center system calling the mobile device, for example, by a callback support call.

[0049] In block 404, routine 400 includes receiving a text message that includes a call session identifier and a mini-application link. In an embodiment, the text message may be generated and transmitted by a call center system. As described above, the mini-application link may be a URL or other type of selectable link to an address for downloading a mini-application such as a code snippet. In some examples, the calling party may select the mini-application link, and the mobile device may download or obtain the code snippet from the location specified by the link. In some examples, the code snippet may be automatically downloaded when the text message is received. In block 406, routine 400 receives the code snippet from the server by the mobile device.

[0050] In block 408, routine 400 includes executing the code snippet. In some embodiments, the code snippet may be an executable portion of the code. The code snippet may be configured to perform an authentication operation on the mobile device. In the embodiments described herein, the authentication may be performed using a contactless card. For example, the code snippet may be executed to present a display on the display of the mobile device. The display may instruct the calling party to tap a contactless card on the surface of the mobile device or bring the card close to the mobile device. When the card is brought close to a specified range, such as an NFC communication range, data is exchanged between the mobile device and the contactless card as described in FIGS. 5-14 herein. The contactless card may provide authentication information such as encrypted data.

[0051] In block 410, routine 400 includes receiving authentication information from a contactless card based on a tap of the contactless card on or near the mobile device. For example, the contactless card may transmit authentication information to the mobile device in an NFC exchange. Embodiments are not limited to this method, and the authentication information may be communicated according to other short-range communication protocols such as Bluetooth®, WiFi, RF, etc.

[0052] In block 412, routine 400 includes transmitting the authentication information and the call session identifier to the call center system. For example, the mobile device may transmit the authentication information and the call session identifier to an authentication server of the call center system, perform an authentication operation on the information, and for example, determine that there is a match between the authentication information and the authenticated information stored in the authentication system. The authentication system can perform the authentication operation and determine the result provided to the call center server and / or the mobile device. Based on this result, the call center system and / or the mobile device can determine whether to continue the call connection or abort the call connection, i.e., hang up the phone. In this routine, the call connection is maintained between the call center system and the mobile device. In block 414, routine 400 includes maintaining a call connection with the call center system based on an indication that the authentication information has been authenticated.

[0053] FIG. 5 shows an example of a processing flow 500 showing that the call center system performs an authentication operation to determine whether to continue a call. These operations may be performed by one or more servers of the call center system, and embodiments are not limited to this method. In block 502, processing flow 500 includes establishing a call with a telephone device such as a mobile device or another telephone. The call connection may be made via a VoIP connection, a POT connection, or other types of connections. Further, the connection may be initiated by the call center system or another device.

[0054] The call center system may determine to perform authentication to authenticate the caller / user of other devices. In an embodiment, the authentication may be performed by causing the caller to provide additional information, i.e., authentication information. As an example, the call center system can utilize a mini-application such as App Clip (registered trademark) or Instant App (registered trademark) to request that the caller provide authentication information generated by a contactless card. The mini-application may be downloaded to a telephone that has a call connection with another device associated with the caller, e.g., another mobile device.

[0055] In block 504, process flow 500 includes sending a text message to another device to perform authentication of the caller. In an embodiment, the text message may be sent by the call center system and may include a mini-application link such as a URL used to download a mini-application to the device. When the user selects the link, the mini-application may be downloaded from a server hosting the application. It should be noted that in some examples, the mini-application may already be installed and / or downloaded to the device, and selection of the link may cause the mini-application to be executed without the need for a download. The link may be the address of the call center system's server or an application store hosting the mini-application.

[0056] In block 506, process flow 500 includes receiving authentication information. In one example, a mobile device may send the authentication information and a call center system including an authentication server may receive the authentication information. The authentication information may be collected by the mobile device. For example, the authentication information may be generated by a contactless card and the mobile device reads the information from the card. Embodiments support other collected authentication information. For example, additional authentication information may include a password or PIN entered by the user, biometrics collected by the mobile device, or other information known to the calling party and the authentication system. Embodiments are not limited to this aspect.

[0057] In block 508, process flow 500 includes performing an authentication operation on the authentication information. Specifically, the authentication server may compare the authentication information with valid and genuine information maintained by the call center system. In some embodiments, the authentication server may determine valid and genuine data within the call center system by performing a lookup in a data store using an identifier, such as a call session identifier.

[0058] In decision block 510, process flow 500 includes determining whether the authentication information is valid or invalid based on the result of the comparison. If the information is not authenticated, process flow 500 may proceed to block 514 and the call connection may be disconnected. If the information is authenticated, process flow 500 may proceed to block 512 and the connection is maintained. In some embodiments, the calling party may also perform authentication, for example, by providing a portion of the information read back to the calling party as described above.

[0059] FIG. 6 shows a data transmission system 600 according to an exemplary embodiment. The system 600 may be an example configuration for performing an authentication operation using a contactless card, which includes generating authentication information and transmitting the authentication information to the authentication server 110. As further discussed below, the system 600 may include a contactless card 116, a mobile device 102, a network 602, and an authentication server 110. Although FIG. 6 shows a single instance of the components, the number of components included in the system 600 may be any number.

[0060] The system 600 may include one or more contactless cards 116, which will be further described below. In some embodiments, the contactless card 116 may wirelessly communicate with the mobile device 102, for example, using near field communication (NFC).

[0061] In some embodiments, system 600 may include mobile device 102 or a client device. In some embodiments, the client device may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to, a computer device or communication device such as, for example, a server, network appliance, personal computer, workstation, telephone, handheld PC, personal digital assistant, thin client, fat client, Internet browser, or other device. Mobile device 102 may be any type of mobile device, for example, the mobile device may include an Apple® iPhone®, iPod®, iPad®, or any other mobile device running Apple® iOS® operating system, any device running Microsoft® Windows® Mobile operating system, any device running Google® Android® operating system, and / or any other smartphone, tablet, or similar wearable mobile device.

[0062] The mobile device 102 can include a processor and memory. The processing circuitry may include additional components including a processor, memory, error and parity / CRC checker, data encoder, anti-collision algorithm, controller, command decoder, security primitive, and anti-tampering hardware necessary to perform the functions described herein. The mobile device 102 may further include a display and an input device. The display may be any type of device for presenting visual information such as a computer monitor, flat panel display, and mobile device screen, including a liquid crystal display, light emitting diode display, plasma panel, and cathode ray tube display. The input device may include any device available and supported on the user's device for inputting information to the user's device, such as a touch screen, keyboard, mouse, cursor control device, touch screen, microphone, digital camera, video recorder, camcorder, etc. These devices can be used to input information and interact with the software and other devices described herein.

[0063] In some examples, the mobile device 102 of the system 600 may execute one or more applications, such as software applications, that enable network communication with one or more components of the system 600 and transmit and / or receive data.

[0064] Mobile device 102 communicates with one or more servers 110 via one or more networks 602 and may operate, for example, as a respective front-end to back-end pair with the authentication server 110. Mobile device 102 may send one or more requests to authentication server 110, for example, from a mobile device mini-application executed on mobile device 102. The one or more requests may be related to obtaining or sending data from / to authentication server 110. Authentication server 110 may receive one or more requests from mobile device 102. Based on the one or more requests from mobile device 102, authentication server 110 may be configured to perform one or more operations for authenticating authentication information.

[0065] System 600 may include one or more networks 602. In some examples, network 602 is one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and is configured to connect mobile device 102 to authentication server 110. For example, network 602 may include one or more of a fiber optic network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a mobile communication global system, a personal communication service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing based system, a code division multiple access based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 1202.11 family of networking, Bluetooth®, NFC, Radio Frequency Identification (RFID), Wi-Fi, etc.

[0066] Furthermore, network 602 may include, but is not limited to, a telephone line, optical fiber, IEEE Ethernet 802.3, wide area network, wireless personal area network, LAN, or a global network such as the Internet. Additionally, network 602 may support an Internet network, wireless communication network, cellular network, etc., or any combination thereof. Network 602 may further include one network or any number of the aforementioned exemplary types of networks that operate as a stand-alone network or in cooperation with each other. Network 602 may utilize one or more protocols of one or more network elements communicatively coupled. Network 602 may convert from one or more protocols of other protocols to one or more protocols of network devices, or from one or more protocols of other protocols to one or more protocols of network devices. Although network 602 is depicted as a single network, according to one or more examples, network 602 may include, for example, multiple interconnected networks such as the Internet, a service provider's network, a cable television network, a corporate network such as a credit card association's network, and a home network.

[0067] System 600 may include one or more authentication servers 110. In some examples, authentication server 110 may include one or more processors coupled to a memory. Authentication server 110 may be configured as a central system, server, or platform for controlling and invoking various data at different times to execute multiple workflow operations. Authentication server 110 may be configured to connect to other devices and systems including one or more databases configured to store authenticated information. Authentication server 110 may be connected to at least one mobile device 102.

[0068] FIG. 7 shows a configuration example of the contactless card 116. This may include a payment card such as a credit card, a debit card, or a gift card issued by a service provider so as to be displayed as a service provider indicator 702 on the front or back surface of the contactless card 116. In some examples, the contactless card 116 may include, without limitation, an identity certificate, regardless of the payment card. In some examples, the transaction card may include a dual interface contactless payment card, a reward card, and the like. The contactless card 116 may include a substrate 708 including a single layer or one or more laminated layers made of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 116 has physical characteristics compliant with the ID-1 format of the ISO / IEC 7816 standard, and the transaction card may comply with the ISO / IEC 14443 standard. However, it is understood that the contactless card 116 according to the present disclosure may have different characteristics, and the present disclosure does not require that the transaction card be implemented in the payment card.

[0069] The contactless card 116 may include identification information 706 displayed on the front and / or back of the card and contact pads 704. The contact pads 704 may include one or more pads and may be configured to establish contact with other client devices such as ATMs, user devices, smartphones, laptops, desktops, or tablet computers via a transaction card. The contact pads may be designed according to one or more standards such as the ISO / IEC 7816 standard and may enable communication according to the EMV protocol. The contactless card 116 may include a processing circuit, an antenna, and other components as further described in FIG. 8. These components may be arranged behind the contact pads 704 or in other locations of the substrate 708, such as in a different layer of the substrate 708, and may be electrically and physically coupled to the contact pads 704. The contactless card 116 may include a magnetic strip or tape disposed on the back of the card (not shown in FIG. 7). The contactless card 116 may include a near field communication (NFC) device coupled to an antenna capable of communicating via the NFC protocol. Embodiments are not limited to this aspect.

[0070] As shown in FIG. 7, the contact pads 704 of the contactless card 116 may include a processing circuit 816 for storing, processing, and communicating information, which includes a processor 802, a memory 804, and one or more interfaces 806. It should be understood that the processing circuit 816 may include additional components necessary to perform the functions described herein, including a processor, a memory, an error and parity / CRC checker, a data encoder, a collision prevention algorithm, a controller, a command decoder, a security primitive, and anti-tampering hardware.

[0071] Memory 804 may be a read-only memory, a write-once read-multiple memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 116 may include one or more of these memories. The read-only memory may be programmable at the factory as read-only or may be programmable only once. The one-time programmability provides the opportunity to write only once and read multiple times. The write-once / read-multiple memory may be programmed after the memory chip is shipped from the factory. Once programmed, the memory cannot be rewritten but can be read any number of times. The read / write memory may be programmed and reprogrammed any number of times after factory shipment. The read / write memory may be read any number of times after factory shipment. In some examples, the memory 804 may be an encrypted memory that utilizes an encryption algorithm executed by the processor 802 to encrypt data.

[0072] Memory 804 may be configured to store one or more applets 808, one or more counters 810, a customer identifier 814, and an account number 812 that may be a virtual account number. The one or more applets 808 may include one or more software applications configured to execute on one or more contactless cards, such as Java (registered trademark) card applets. However, it is understood that the applets 808 are not limited to Java card applets and may be any software application operable on a contactless card or other device having limited memory. The one or more counters 810 may include numeric counters sufficient to store integers. The customer identifier 814 may be composed of a unique alphanumeric identifier assigned to a user of the contactless card 116, and the identifier may distinguish the user of the contactless card from users of other contactless cards. In some examples, the customer identifier 814 may identify both the customer and the account assigned to that customer, and may further identify the contactless card 116 associated with the customer's account. As described above, the account number 812 may include thousands of once-only-use virtual account numbers associated with the contactless card 116. The applets 808 of the contactless card 116 may be configured to manage the account number 812 (e.g., select the account number 812, mark the selected account number 812 as used, and transmit the account number 812 to a mobile device for automatic filling by an automatic filling service). In some embodiments, the applets 808 are configured to generate authentication information, as described in more detail herein.

[0073] Although the processor 802 and memory elements of the exemplary embodiments described above have been described with reference to the contact pad 704, the present disclosure is not limited thereto. It is understood that these elements may be implemented external to the contact pad 704, may be completely separated from the contact pad 704, or may be implemented as additional elements in addition to the processor 802 and memory 804 elements disposed within the contact pad 704.

[0074] In some examples, the contactless card 116 may include one or more antennas 818. The one or more antennas 818 may be disposed within the contactless card 116 around the processing circuit 816 of the contact pad 704. For example, the one or more antennas 818 may be integral with the processing circuit 816, and the one or more antennas 818 may be used with an external booster coil. As another example, the one or more antennas 818 may be external to the contact pad 704 and the processing circuit 816.

[0075] In an embodiment, the coil of the contactless card 116 may function as the secondary side of an air-core transformer. The terminal may communicate with the contactless card 116 by disconnecting power or amplitude modulation. The contactless card 116 may infer data transmitted from the terminal using the gap in the power connection of the contactless card. The gap may be functionally maintained via one or more capacitors. The contactless card 116 may send back communication by switching the load or load modulation of the coil of the contactless card. The load modulation may be detected at the coil of the terminal via interference. More generally, using the antenna 818, the processor 802, and / or the memory 804, the contactless card 101 provides a communication interface for communicating via NFC, Bluetooth®, and / or Wi-Fi communication.

[0076] As described above, the contactless card 116 may be built on a software platform operable on a smart card such as a JavaCard having limited memory or other devices, and one or more applications or applets may be securely executed. The applet 808 may be added to the contactless card to provide one-time passwords (OTP) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet 808 may be configured to respond to one or more requests, such as a short-range data exchange request from a reader such as a mobile NFC reader (e.g., of a mobile device or a POS terminal), and generate an NDEF message containing an encrypted and secure OTP encoded as an NDEF text tag.

[0077] An example of an NDEF OTP is an NDEF short record layout (SR = 1). In such an example, one or more applets 808 may be configured to encode the OTP as a well-known type of text tag of NDEF type 4. In some examples, the NDEF message may be composed of one or more records. The applet 808 may be configured to add one or more static tag records in addition to the OTP record.

[0078] In some examples, one or more applets 808 may be configured to emulate an RFID tag. The RFID tag can include one or more polymorphic tags. In some examples, each time the tag is read, various cryptographic data indicating the authenticity of the contactless card is presented. Based on one or more applets 808, the NFC reading of the tag is processed, and the data is transmitted to a server such as a server of a banking system, and the data may be verified at the server.

[0079] In some examples, the contactless card 116 and the server may include specific data, such as authentication information, so that the card is properly identified. The contactless card 116 may include one or more unique identifiers (not shown). Each time a read operation is performed, the counter 810 may be configured to increment. In some examples, each time data from the contactless card 116 is read (e.g., by a mobile device), the counter 810 is sent to the server for verification, and it is determined whether the counter 810 is equal to the server's counter (as part of the verification).

[0080] One or more counters 810 may be configured to prevent replay attacks. For example, if an encrypted signal is captured and replayed, when the counter 810 is read, used, or otherwise passed, the encrypted signal is immediately rejected. If the counter 810 is not used, there is a possibility of replay. In some examples, the counter incremented on the card is different from the counter incremented for a transaction. Since there is no communication between the applets 808 on the contactless card 116, the contactless card 101 cannot determine the application transaction counter 810.

[0081] [[ID=⑧]]In some examples, one or more counters 810 may not be synchronized. In some examples, the counter 810 may be incremented to account for accidental reads that start a transaction, such as a diagonal read, but the application does not process the counter 810. In some examples, when the mobile device 10 is powered on, NFC is enabled and the mobile device 102 is configured to read available tags, but no action is taken on the read.

[0082] To continue synchronizing the counter 810, an application such as a background application may be executed that is configured to detect that the mobile device 110 has been activated and synchronize with a server of a banking system that instructs the readout generated by the detection to advance the counter. In other examples, a hashed one-time password may be utilized such that a window of failed synchronization is accepted. For example, if within a threshold of 10, the counter 810 is configured to advance. However, within a different number of thresholds, for example within 10 or 1000, a request to perform resynchronization may be processed. This request requires the user to indicate, via one or more applications, one or more taps, gestures, or other means via the user's device. If the counter 810 increases in an appropriate sequence, the user can know that the user has done so.

[0083] The key diversification techniques described herein with reference to the counter 810, the master key, and the diversification key are an example of encryption and / or decryption by key diversification techniques. This exemplary key diversification technique should not be considered as limiting the present disclosure since the present disclosure is equally applicable to other types of key diversification techniques.

[0084] In the process of creating the contactless card 116, two cryptographic keys may be uniquely assigned to each card. The cryptographic keys may include symmetric keys that can be used for both encryption and decryption of data. The Triple DES (3DES) algorithm is used by EMV and implemented by the hardware within the contactless card 116. By using a key diversification process, one or more keys are derived from the master key based on uniquely identifiable information for each entity that requires a key.

[0085] In some examples, to overcome the drawbacks of the 3DES algorithm that is vulnerable, a session key (such as a key unique per session) may be derived, but instead of using a master key, a unique card-derived key and a counter may be used as diversification data. For example, each time the contactless card 101 is in operation, different keys may be used for generating a message authentication code (MAC) and performing encryption. As a result, triple encryption is realized. The session key may be generated by one or more applets and derived by using an application transaction counter with one or more algorithms (defined in EMV 4.3 Book 2 A1.3.1 Common Session Key Derivation).

[0086] Furthermore, the increment for each card may be unique, assigned by personalization, or algorithmically assigned by some identification information. For example, odd-numbered cards are incremented by 2, and even-numbered cards are incremented by 5. In some examples, the increment may change sequentially in a readout order such that one card is incremented sequentially as 1, 3, 5, 2, 2,.... A specific sequence or algorithm sequence may be defined during personalization or defined 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.

[0087] The authentication information included in the authentication message may be transmitted as the content of a text NDEF record in hexadecimal ASCII format. In other examples, the NDEF record may be encoded in hexadecimal format.

[0088] Figure 9 is a timing diagram showing an example sequence for providing authentication information according to one or more embodiments of the present disclosure. Sequence flow 900 includes contactless card 116 and mobile device 102. Mobile device 102 includes application 902, such as a mini-application or code snippet as discussed herein, and processor 904.

[0089] At line 908, application 902 communicates with contactless card 116 (e.g., after being brought near contactless card 116). Communication between application 902 and contactless card 116 includes contactless card 116 being sufficiently close to a card reader (not shown) of mobile device 102 to enable NFC data transfer between application 902 and contactless card 116.

[0090] After communication is established between the mobile device 102 and the contactless card 116, at line 906, the contactless card 116 generates a Message Authentication Code (MAC) cipher. In some examples, this occurs when the contactless card 116 is read by the application 902. In particular, this may occur based on a read such as an NFC read of a Near Field Data Exchange (NDEF) tag generated according to the NFC Data Exchange Format. For example, a read application such as the application 902 transmits a message such as an applet selection message with the applet ID of the applet that generates the NDEF. In response to confirmation of the selection, a sequence of a selection file message followed by a read file message may be transmitted. For example, the sequence may include a "selection capability file", a "read capability file", and a "select NDEF file". At this point, the counter value held by the contactless card 116 may be updated or incremented, followed by the transmission of a "read NDEF file". At this point, a message including a header and a shared secret is generated. Thereafter, a session key is generated. A MAC cipher may be generated from the message including the header and the shared secret. The MAC cipher may be concatenated with one or more blocks of random data, and the MAC cipher and a random number (RND) may be encrypted with the session key. Thereafter, the cipher and the header are concatenated, encoded as ASCII hexadecimal, and returned in the NDEF message format (in response to the "read NDEF file" message).

[0091] In some examples, the MAC cipher is transmitted as an NDEF tag, and in other examples, the MAC cipher may be included with a Uniform Resource Indicator (e.g., as a formatted string). In some examples, the application 902 may be configured to transmit a request including an instruction to generate the MAC cipher to the contactless card 116.

[0092] At line 910, the contactless card 116 transmits the MAC cipher to the application 902. In some examples, the transmission of the MAC cipher is performed via NFC, but the present disclosure is not limited thereto. In other examples, this communication may be performed via Bluetooth®, Wi-Fi, or other means of wireless data communication. At line 912, the application 902 transmits the MAC cipher to the processor 904.

[0093] At line 914, the processor 904 verifies the MAC cipher according to the instructions from the application 122. For example, the MAC cipher may be verified as described below. In some examples, the verification of the MAC cipher may be performed by a device other than the mobile device 102, such as a server of a banking system that communicates with the mobile device 102. For example, the processor 904 may output the MAC cipher for transmission to the server of the banking system, and the server may verify the MAC cipher. In some examples, the MAC cipher functions as a digital signature for verification. Other digital signature algorithms, such as public key asymmetric algorithms, digital signature algorithms, and RSA algorithms, or zero-knowledge protocols may be used to perform this verification.

[0094] FIG. 10 shows a data structure 1000 of an NDEF short record layout (SR = 1) according to an exemplary embodiment. One or more applets may be configured to encode OTP as a well-known type of text tag of NDEF type 4. In some examples, the NDEF message is composed of 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, encoded in English (en); applet ID: D2760000850101; function: read-only access; encoding: the authentication message may be encoded as hexadecimal of ASCII; type-length-value (TLV) data may be provided as personalization parameters that can be used to generate the NDEF message. In one embodiment, the authentication template may include a first record along with a well-known index for providing actual dynamic authentication information.

[0095] FIG. 11 shows a diagram of a system 1100 configured to implement one or more embodiments of the present disclosure. As described below, in the process of generating a contactless card, two cryptographic keys may be uniquely assigned to each card. The cryptographic keys may include symmetric keys used for both encryption and decryption of data. The triple DES (3DES) algorithm is used by EMV and implemented in the hardware within the contactless card. By using a key diversification process, one or more keys are derived from a master key based on uniquely identifiable information for each entity that requires a key.

[0096] Regarding the management of master keys, two issuer master keys 1102, 1126 may be required for each part of the portfolio issued by one or more applets. For example, the first master key 1102 includes an issuer cryptographic generation / authentication key (Iss-Key-Auth), and the second master key 1126 includes an issuer data encryption key (Iss-Key-DEK). As further described herein, the two issuer master keys 1102, 1126 are diversified within card master keys 1108, 1120 that are unique for each card. In some examples, as back-office data, the network profile record ID (pNPR) 522 and the derived key index (pDKI) 1124 may be used to identify which issuer master keys 1102, 1126 to use in the cryptographic process for authentication. A system that performs authentication may be configured to obtain the values of the pNPR 1122 and pDKI 1124 for a contactless card at the time of authentication.

[0097] In some examples, to enhance the security of the solution, a session key (such as a key unique to each session) may be derived, but instead of using a master key, as described above, a unique card-derived key and a counter may be used as diversification data. For example, each time a card is used in an operation, different keys may be used for generating a message authentication code (MAC) and for performing encryption. Regarding the generation of a session key, the key used to generate an encryption in one or more applets and encrypt data may include a session key based on the unique keys of the card (Card-Key-Auth1108 and Card-Key-Dek1120). The session keys (Aut-Session-Key1132 and DEK-Session-Key1110) may be generated by one or more applets and derived using the application transaction counter (pATC)1104 with one or more algorithms. Only the two lower bytes of the 4-byte pATC1104 are used to conform the data to one or more algorithms. In some examples, the 4-byte session key derivation method may include F1:=PATC(lower 2 bytes)||‘F0’||‘00’||PATC(4 bytes) F1:=PATC(lower 2 bytes)||‘0F’||‘00’||PATC(4 bytes) SK:={(ALG(MK)[F1])||ALG(MK)[F2]}. Here, ALG includes 3DES ECB, and MK may include the unique derived master key of the card.

[0098] As described herein, one or more MAC session keys may be derived using the lower two bytes of the pATC1104 counter. Upon each tap of the contactless card, the pATC1104 is configured to be updated, and the card master keys Card-Key-AUTH508 and Card-Key-DEK1120 are further diversified into the session keys Aut-Session-Key1132 and DEK-Session-KEY1110. The pATC counter 1104 may be initialized during personalization or applet initialization. In some examples, the pATC counter 1104 may be initialized during or before personalization and may be configured to increment by one upon each reading of each NDEF.

[0099] Furthermore, the update of each card may be unique and may be assigned by personalization or algorithmically assigned by the pUID or other identification information. For example, odd-numbered cards may increment or decrement by two, and even-numbered cards may increment or decrement by five. In some examples, the update may change sequentially upon successive readings such that one card sequentially increments as 1, 3, 5, 2, 2,.... A specific sequence or algorithmic sequence may be defined during personalization or may be defined from one or more processes derived from a unique identifier. This can make it difficult for replay attackers to generalize from a small number of card instances.

[0100] The authentication message may be delivered as the content of a text NDEF record in hexadecimal ASCII format. In some examples, only the authentication data, the MAC of the authentication data followed by an 8-byte random number is included. In some examples, the random number is before cipher A and is of 1 block length. In other examples, there may be no limit on the length of the random number. In yet another example, all data (i.e., random number + cipher) may be a multiple of the block size. In such an example, an 8-byte block may be added to match the block generated by the MAC algorithm. As another example, if the algorithm employed uses 16-byte blocks, a multiple of that block size may be used, or the output may be automatically or manually padded to a multiple of that block size.

[0101] The MAC is executed by the function key (AUT-Session-Key) 1132. The data specified by the cipher is processed using the javacard.signature method: ALG_DES_MAC8_ISO9797_1_M2_ALG3 and is associated with the EMV ARQC verification method. The key used for this calculation may include the session key AUT-Session-Key1132 as described above. As described above, the lower 2 bytes of the counter may be used for the diversification of one or more MAC session keys. As described below, AUT-Session-Key1132 may be used for MAC data 1106, and the resulting data or cipher An1114 and random number RND may be encrypted using DEK-Session-Key1110 to generate cipher B or output 1118 transmitted in the message.

[0102] In some examples, one or more HSM commands may be processed for decryption and may include 3DES symmetric encryption using CBC mode where the last 16 (binary, 32 hexadecimal) bytes are followed by MAC authentication data following a zero IV of random numbers. The key for this encryption may include a session key DEK-Session-Key1110 derived from Card-Key-DEK1120. In this case, the ATC value for session key derivation is the least significant byte of counter pATC1104.

[0103] The following format represents an exemplary embodiment in binary form. Further, in some examples, the first byte may be set to ASCII 'A'. TIFF2025524500000002.tif91165 TIFF2025524500000003.tif161166

[0104] Other exemplary formats are shown below. In this example, the tags are encoded in hexadecimal format. TIFF2025524500000004.tif95165 TIFF2025524500000005.tif133165

[0105] From the master keys Iss-Key-AUTH502 and Iss-Key-DEK1126, the UID field of the received message may be extracted to derive the card master keys (Card-Key-Auth1108 and Card-Key-DEK1120) of a specific card. To derive the session keys (Aut-Session-Key1132 and DEK-Session-Key1110) of a specific card using the card master keys (Card-Key-Auth508 and Card-Key-DEK1120), the counter (pATC) field of the received message may be used. Cipher B 1118 is decrypted using the DEK-Session-KEY, cipher An1114 and RND are generated, and RND is discarded. The UID field may be used to search for the shared secret of the contactless card, which, together with the Ver, UID, and pATC fields of the message, is processed via the cipher MAC using the regenerated Aut-Session-Key, and a MAC output such as MAC’ may be generated. If MAC’ is the same as cipher An1114, it indicates that all decryption of the message and MAC check have been completed. Then, pATC is read and it is determined whether it is valid.

[0106] During the authentication session, one or more applications may generate one or more cryptographs. For example, one or more cryptographs are generated as 3DES MAC using the ISO9797-1 algorithm 3 with padding of method 2 via one or more session keys such as Aut-Session-Key1132. The input data 1106 may be in the following format: version (2), pUID (8), pATC (4), shared secret (4). In some examples, the numbers in parentheses may include the byte length. In some examples, the shared secret may be generated by one or more random number generators. The random number generator is configured to confirm by one or more secure processes that the random numbers are unpredictable. In some examples, the shared secret includes a random 4-byte binary number that is injected into the card during personalization and is known to the authentication service. During the authentication session, the shared secret may not be provided from one or more applets to the mobile application. The padding of method 2 may include adding an essential 0x‘80’ byte at the end of the input data and adding optional 0x‘00’ bytes at the end of the data up to the 8-byte boundary. The resulting cryptograph is 8 bytes long.

[0107] In some examples, one of the advantages of encrypting an unshared random number as the first block of the MAC cryptograph is that it functions as an initialization vector when using the CBC (block chaining) mode of a common encryption algorithm. This enables "scrambling" from block to block without having to pre-establish a fixed IV or dynamic IV.

[0108] By including an Application Transaction Counter (pATC) as part of the data included in the MAC cipher, the authentication service may be configured to determine whether the value transmitted in the clear data has been tampered with. Further, by including a version within one or more ciphers, it becomes difficult for an attacker to deliberately fake the version of the application in an attempt to reduce the strength of the cipher solution. In some examples, the pATC starts at 0 and is incremented by 1 each time one or more applications generate authentication data. The authentication service may be configured to track the pATC used during an authentication session. In some examples, if the authentication data uses a pATC that is equal to or lower than a previous value received by the authentication service, this is interpreted as an attempt to replay an old message and authentication may be denied. In some examples, if the pATC is greater than a previously received value, this is evaluated to determine whether it is within an acceptable range or threshold, and if it exceeds the range or threshold or is outside the range or threshold, the verification has failed or is determined to be untrustworthy. In the MAC operation 1112, the data 1106 is processed with the MAC using the Aut-Session-Key 1132 and an encrypted MAC output (Cipher A) 1114 is generated.

[0109] To provide additional protection against brute force attacks that leak keys on a card, it is desirable that the MAC cipher 1114 be encrypted. In some examples, the data included in the ciphertext or the cipher 1114 includes a random number (8), a cipher (8). In some examples, the numbers in parentheses may include the byte length. In some examples, the random number may be generated by one or more random number generators. The random number generator is configured to confirm by one or more secure processes that the random number is unpredictable. The key used to encrypt this data may include a session key. For example, the session key may include DEK-Session-Key1110. In the encryption process 1116, the DEK-Session-Key510 is used to process the data or the cipher An1114 and RND, and the encrypted data, cipher B 1118 is generated. The data is encrypted using 3DES in cipher block chaining mode, and the attacker may be required to perform an attack on all ciphers. As a non-limiting example, other algorithms such as the Advanced Encryption Standard (AES) may be used. In some examples, an initialization vector of 0x‘000000000000’ may be used. Since the correctly decrypted data cannot be distinguished from the incorrectly decrypted data due to its random appearance, an attacker who tries to decrypt the key used to encrypt this data by brute force cannot determine when the correct key was used.

[0110] For the authentication service to verify one or more ciphers provided by one or more applets, the following data needs to be transmitted in plaintext from one or more applets to the mobile device during the authentication session. A version number for determining the encryption approach used and the message format for verifying the ciphertext, The pUID for searching for the cryptographic asset and deriving the card key, and, The pATC for deriving the session key used for the cipher.

[0111] Figure 12 shows a method 1200 for generating an encryption. For example, in block 1202, a network profile record ID (pNPR) and a derived key index (pDKI) are used to identify the issuer master key used in the encryption process for authentication. In some examples, the method includes performing authentication to obtain the values of pNPR and pDKI of the contactless card at the time of authentication.

[0112] In block 1204, the issuer master key may be diversified by combining it with the unique ID number of the card (pUID) and the PAN sequence number (PSN) of one or more applets, such as a payment applet.

[0113] In block 1206, Card-Key-Auth and Card-Key-DEK (unique card key) may be generated by diversifying the issuer master key to generate a session key.

[0114] In block 1208, the key used to generate the encryption and encrypt the data within one or more applets may include the session key of block 1030 based on the unique keys of the card (Card-Key-Auth and Card-Key-DEK). In some examples, these session keys are generated by one or more applets, derived by using pATC, resulting in the session keys Aut-Session-Key and DEK-Session-Key.

[0115] Figure 13 shows an exemplary process 1300 illustrating key diversification according to an example. First, two different master keys are prepared for the sender and the receiver. For example, the first master key is a data encryption master key, and the second master key is a data integrity master key. The sender has a counter value updated in block 1302 and other data such as the data to be protected that can be securely shared with the receiver.

[0116] In block 1304, the counter value may be encrypted by the sender using the data encryption master key to generate a data encryption derived session key, and the counter value may further be encrypted by the sender using the data integrity master key to generate a data integrity derived session key. In some examples, the entire counter value or a portion of the counter value may be used during both encryptions.

[0117] In some examples, the counter value may not be encrypted. In such examples, the counter may be transmitted in plaintext, i.e., unencrypted, between the sender and the receiver.

[0118] In block 1306, the data to be protected is processed by the sender using a cryptographic MAC operation using the data integrity session key and a cryptographic MAC algorithm. The protected data, which includes the plaintext and the shared secret, is used to generate a MAC using one of the session keys (AUT-Session-Key).

[0119] In block 1308, the data to be protected may be encrypted by the sender using the data encryption derived session key combined with a symmetric encryption algorithm. In some examples, the MAC is combined with, for example, an equal amount of random data each 8 bytes in length and then encrypted using a second session key (DEK-Session-Key).

[0120] In block 1310, the encrypted MAC is transmitted from the sender to the receiver along with sufficient information to identify further secret information (such as a shared secret, master key, etc.) for verification of the cipher.

[0121] In block 1312, the receiver independently derives two derived session keys from the two master keys using the received counter value as described above.

[0122] In block 1314, the data encryption-derived session key is used together with a symmetric decryption operation to decrypt the protected data. Thereafter, additional processing is performed on the exchanged data. In some examples, after the MAC is extracted, it may be desirable to reproduce and match the MAC. For example, when verifying the cipher, decryption can be performed using a properly generated session key. For verification, the protected data may be reconstructed. The MAC operation is executed using a properly generated session key to determine whether it matches the decrypted MAC. Since the MAC operation is an irreversible process, the only way to verify is to attempt regeneration from the source data.

[0123] In block 1316, the session key derived from data integrity is used in combination with an encrypted MAC operation to verify that the protected data has not been modified.

[0124] Some examples of the methods described herein can advantageously confirm the case where authentication is determined to be successful when the following conditions are met. First, the ability to verify the MAC indicates that the derived session key was appropriate. The MAC is correct only when decryption is successful and an appropriate MAC value is obtained. The success of decryption indicates that the correctly derived encryption key was used to decrypt the encrypted MAC. Since the derived session key is generated using a master key known only to the sender (e.g., the transmitting device) and the receiver (e.g., the receiving device), the contactless card that first generated the MAC and encrypted the MAC can be trusted to be genuine. Further, it is shown that the counter values used to derive the first and second session keys are valid and are used to perform the authentication operation.

[0125] Thereafter, the two derived session keys may be discarded, and the next iteration of the data exchange updates the counter value (returns to block 1302), and a new set of session keys may be generated (in block 1310). In some examples, the combined random data may be discarded.

[0126] Figure 14 shows a method 800 for card activation according to an exemplary embodiment. For example, card activation is performed by a system including a card, a device, and one or more servers. The contactless card, device, and one or more servers may be the same or similar components as those described above, such as the contactless card 116, the mobile device 102, and the server.

[0127] In block 1402, the card may be configured to dynamically generate data. In some examples, this data includes information such as an account number, a card identifier, a card verification value, or a phone number, and is transmitted from the card to the device. In some examples, one or more portions of the data may be encrypted by the systems and methods disclosed herein.

[0128] In block 1404, one or more portions of the dynamically generated data are communicated to an application on the device via NFC or other wireless communication. For example, when the card is brought close to and tapped on the device, the application on the device reads one or more portions of the data associated with the contactless card. In some examples, if the device does not have an application to assist with card activation, the tap of the card prompts the customer to a software application store to either instruct the device or download the relevant application to activate the card. In some examples, the user is prompted to gesture, position, or orient the card sufficiently towards the surface of the device, for example, place the card diagonally or flat on, near, or in proximity to the surface of the device. In response to sufficient gesture, position, and / or orientation of the card, the device can proceed to transmit one or more encrypted portions of the data received from the card to one or more servers.

[0129] In block 1406, one or more portions of the data may be communicated to one or more servers, such as a card-issuing server. For example, one or more encrypted portions of the data may be transmitted from the device to the card-issuing server in order to activate the card.

[0130] In block 1408, one or more servers can decrypt one or more encrypted portions of the data by the systems and methods disclosed herein. For example, one or more servers may receive encrypted data from the device and decrypt the received data to compare it with recorded data accessible to the one or more servers. If the result of the comparison of one or more decrypted portions of the data by the one or more servers matches successfully, the card is activated. If the result of the comparison of one or more decrypted portions of the data by the one or more servers does not match, one or more processes are performed. For example, in response to the determination of a mismatch, the user is prompted to tap, swipe, or wave the card again. In this case, there is a predetermined threshold including the number of attempts permitted for the user to activate the card. Alternatively, the user may receive a notification, such as a message on the device, indicating that the card authentication attempt has failed and prompting the user to contact the relevant service for activating the card by phone, email, or text, or another notification such as a phone call indicating that the card authentication attempt has failed and prompting the user to contact the relevant service for activating the card by phone, email, or text, or another notification such as an email indicating that the card authentication attempt has failed and prompting the user to contact the relevant service for activating the card by phone, email, or text.

[0131] In block 1410, one or more servers may send a reply message based on the successful activation of the card. For example, the device may be configured to receive from one or more servers an output indicating the successful activation of the card by the one or more servers. The device may be configured to display a message indicating that the card has been successfully activated. When the card is activated, the card may be configured to stop the dynamic generation of data in order to avoid unauthorized use. In this way, the card is not activated thereafter, and the one or more servers are notified that the card has already been activated.

[0132] FIG. 15 shows an embodiment of an exemplary computer architecture 1500 suitable for implementing various embodiments as already described. In one embodiment, the computer architecture 1500 includes, or is implemented as part of, one or more systems or devices discussed herein.

[0133] As used herein, the terms "system" and "component" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the illustrative computing architecture 1500. For example, a component may be a process running on a processor, a processor, a hard disk drive, a plurality of storage drives (of optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer, but are not limited thereto. By way of illustration, both an application running on a server and the server may be components. One or more components may exist within a process and / or thread of execution, and a component may be localized on one computer and / or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communication media for purposes of coordinating operations. This coordination may include the exchange of information in a unidirectional or bidirectional manner. For example, a component may transmit information in the form of signals communicated through the communication media. The information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may alternatively employ data messages. Such data messages may be transmitted across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0134] Computing architecture 100 includes various common computing elements such as one or more processors, multi-core processors, coprocessors, memory units, chip sets, controllers, peripheral devices, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components, power supplies, etc. However, embodiments are not limited to implementation by computing architecture 100.

[0135] As shown in FIG. 8, computing architecture 100 includes a processor 1512, a system memory 1504, and a system bus 1506. The processor 1512 may be any of a variety of commercially available processors.

[0136] The system bus 1506 provides an interface for system components, including but not limited to the system memory 1504, to the processor 1512. The system bus 1506 may be any of several types of bus structures that further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus, using any of a variety of commercially available bus architectures. Interface adapters may be connected to the system bus 608 via a slot architecture. Exemplary slot architectures include, but are not limited to, Accelerated Graphics Port (AGP), CardBus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0137] Computing architecture 100 may include or implement various products. The product may include a computer-readable storage medium for storing logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Embodiments may also be implemented, at least in part, as instructions included in or on a non-transitory computer-readable medium that can be read and executed by one or more processors to enable performance of the operations described herein.

[0138] System memory 1504 can 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, polymer memories such as ferroelectric polymer memories, ovonic memories, phase change memories or ferroelectric memories, silicon-oxide-nitride-oxide-silicon (SONOS) memories, magnetic cards or optical cards, arrays of devices such as Redundant Array of Independent Disks (RAID) drives, solid-state memory devices (e.g., USB memories), solid-state drives (SSD), and any other type of storage medium suitable for storing information. In the embodiment shown in FIG. 15, system memory 1504 may include non-volatile memory 1508 and / or volatile memory 1510. The basic input / output system (BIOS) may be stored in non-volatile memory 1508.

[0139] Computer 1502 can include various types of computer-readable storage media in the form of one or more low-speed memory units, such as an internal (or external) hard disk drive 1530, a magnetic disk drive 1530 for reading from or writing to a removable magnetic disk 1520, and an optical disk drive 1528 for reading from or writing to a removable optical disk 1532 (e.g., CD-ROM or DVD). The hard disk drive 1530, the magnetic disk drive 1530, and the optical disk drive 1528 can be connected to the system bus 1506 by an HDD interface 1514, an FDD interface 1518, and an optical disk drive interface 1534, respectively. The HDD interface 1514 for external drive implementation may include at least one or both of universal serial bus (USB) and IEEE 1394 interface technologies.

[0140] The drive and the associated computer-readable media provide volatile and / or non-volatile storage such as data, data structures, computer-executable instructions, etc. For example, a number of program modules including operating systems 1522, one or more applications 1542, other program modules 1524, and program data 1526 can be stored in the drive and non-volatile memory 1508, and volatile memory 1510. In one embodiment, one or more applications 1542, other program modules 1524, and program data 1526 can include, for example, various applications and / or components of the system discussed herein.

[0141] A user can input commands and information into the computer 1502 by one or more wired / wireless input devices, such as a pointing device like a keyboard 1550 and a mouse 1552. Other input devices can include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game pad, a stylus pen, a card reader, a dongle, a fingerprint reader, a glove, a graphics tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a trackball, a track pad, a sensor, a stylus, etc. These and other input devices are often connected to the processor 1512 via an input device interface 1536 coupled to the system bus 1506, but may also be connected by other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

[0142] A monitor 1544 or other type of display device is also connected to the system bus 1506 via an interface such as a video adapter 1546. The monitor 1544 can be inside or outside the computer 1502. In addition to the monitor 1544, the computer typically includes other peripheral output devices such as speakers, printers, etc.

[0143] Computer 1502 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 1548. Remote computer 1548 may be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node, and typically includes many or all of the elements described in relation to computer 1502, but for the sake of brevity, only memory and / or storage device 1558 is illustrated. The illustrated logical connections include wired / wireless connections to local area network 1556 and / or a larger network, such as wide area network 1554. Such LAN and WAN networking environments are common in offices and enterprises, facilitating enterprise-scale computer networks such as intranets, all of which may be connected to a global communication network such as the Internet.

[0144] When used in the networking environment of local area network 1556, computer 1502 is connected to local area network 1556 via a wired and / or wireless communication network interface or network adapter 1538. Network adapter 1538 can facilitate wired and / or wireless communication to local area network 1556 and may also include a wireless access point disposed thereon for communicating with the wireless function of network adapter 1538.

[0145] When used in the networking environment of the wide area network 1554, the computer 1502 can include a modem 1540, or be connected to a communication server on the wide area network 1554, or have other means for establishing communication on the wide area network 1554, such as via the Internet. The modem 1540, which can be an internal or external, as well as wired and / or wireless device, is connected to the system bus 1506 via the input device interface 1536. In a network environment, program modules represented in relation to the computer 1502, or portions thereof, can be stored in the remote memory and / or storage device 1558. It is understood that the network connections shown are exemplary, and other means for establishing communication links between computers may be used.

[0146] The computer 1502 can communicate with wired and wireless devices or entities that use standards of the IEEE 802 family, such as a wireless device operably disposed within wireless communication (e.g., IEEE 802.11 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth® wireless technologies. Thus, the communication may be in a predefined structure like a conventional network, or simply an ad hoc communication between at least two devices. A Wi-Fi network uses wireless technologies called IEEE 802.11 (a, b, g, n, etc.) to provide a secure, reliable, and high-speed wireless connection. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using media and functions related to IEEE 802.3).

[0147] The various elements of the device as described above may include various hardware elements, software elements, or a combination of both. Examples of hardware elements are devices, logical 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, chip sets, etc. Examples of software elements are 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 program interfaces (APIs), instruction sets, operation codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether an embodiment is implemented using hardware elements and / or software elements may vary according to any number of factors such as the desired computational speed, power level, thermal tolerance, processing cycle budget, input data speed, output data speed, memory resources, data bus speed, and other design or performance constraints for a given implementation.

[0148] The components and functions of the aforementioned device may be implemented using any combination of discrete circuits, application specific integrated circuits (ASICs), logic gates, and / or single chip architectures. Further, the functions of the device may be implemented using a microcontroller, programmable logic array and / or microprocessor, or preferably any combination of the foregoing. It should be noted that hardware, firmware, and / or software elements may be referred to herein, collectively or individually, as "logic" or "circuit".

[0149] FIG. 16 is a block diagram showing an exemplary communication architecture 1600 suitable for implementing various embodiments as described above. The communication architecture 1600 includes various common communication elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, and the like. However, the embodiments are not limited to implementation by the communication architecture 1600 and may be consistent with the systems and devices discussed herein.

[0150] As shown in FIG. 16, the communication architecture 1600 includes one or more clients 1602 and a server 1604. The server 1604 may implement one or more of the functions and embodiments discussed herein. The clients 1602 and the server 1604 are operatively connected to respective client data stores 1606 and server data stores 1608 that can be employed to store information local to the respective clients 1602 and the server 1604, such as cookies and / or related context information.

[0151] The clients 1602 and the server 1604 can communicate information with each other using a communication framework 1610. The communication framework 1610 may implement any well-known communication technology and protocol. The communication framework 1610 may be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as a corporate intranet), a circuit-switched network (e.g., the public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with appropriate gateways and translators).

[0152] The communication framework 1610 may implement various network interfaces arranged to permit, communicate with, and connect to a communication network. The network interface may be regarded as a dedicated form of the input / output (I / O) interface. The network interface may employ connection protocols including, but not limited to, direct connect, Ethernet (e.g., thick, thin, twisted pair 10 / 100 / 1000 base T, etc.), token ring, wireless network interface, cellular network interface, IEEE802.7a - x network interface, IEEE802.16 network interface, IEEE802.20 network interface, etc. Further, multiple network interfaces may be used to be compatible with various communication network types. For example, multiple network interfaces may be employed to enable communication on broadcast, multicast, and unicast networks. A distributed network controller architecture may likewise be employed to increase the communication bandwidth required by the client 1602 and the server 1604 by pooling, load balancing, and other methods when the processing requirements need greater speed and capacity. The communication network may be either one and a combination of a wired network and / or a wireless network, including but not limited to, direct interconnection, security - protected custom connection, private network (e.g., enterprise intranet), public network (e.g., Internet), personal area network (PAN), local area network (LAN), metropolitan area network (MAN), operating mission as a node on the Internet (OMNI), wide area network (WAN), wireless network, cellular network, and other communication networks.

Claims

1. establishing a call connection with a mobile device by a call center system; determining, by the call center system, a call session identifier for the call connection and a telephone number associated with the mobile device; transmitting, by the call center system, a text message including the call session identifier and a mini-application link configured to obtain a code snippet from a server by the mobile device, to the mobile device based on the telephone number; receiving, by the call center system, authentication information generated by a contactless card and the call session identifier from the mobile device; determining, by the call center system, that the authentication information is authentic; enabling, by the call center system, the call connection for communication; A computer-implemented method comprising the above steps.

2. The computer-implemented method according to claim 1, wherein the code snippet is obtained from the server based on user interaction with the mini-application link, and the mini-application link is a uniform resource locator to the server including the code snippet.

3. The computer-implemented method according to claim 1, wherein the server is maintained by an application store and the code snippet is downloaded to the mobile device upon selection.

4. The computer-implemented method according to claim 1, wherein the code snippet is executed on the mobile device and is configured to present a display on the display of the mobile device instructing to tap the contactless card on the surface of the mobile device.

5. registering, by the call center system, a request for performing authentication of the call connection; generating, by the call center system, the call session identifier based on the registration of the request; The computer-implemented method according to claim 1, comprising the above steps.

6. determining, by the call center system, the telephone number for the call connection; determining, by the call center system, an account associated with the telephone number of the mobile device; Automatically transmitting the text message to the mobile device based on a determination of the account associated with the telephone number by the call center system; The computer-implemented method according to claim 1, comprising:

7. Receiving, by the call center system, a second text message from the mobile device, The text message includes a code for authenticating a call agent of the call center system. The computer-implemented method according to claim 1.

8. The call center system receives the authentication information from the code snippet executed on the mobile device, The code snippet is configured to perform a reading operation by the contactless card to receive the authentication information and transmit it to the call center system. The computer-implemented method according to claim 1.

9. A call center system comprising a processing circuit and a memory for storing instructions, When the instructions are executed by the processing circuit, the processing circuit is caused to: Determine a call connection with a mobile device; Determine a telephone number associated with the mobile device; Transmit a text message including a mini-application link configured to obtain a code snippet by the mobile device to the mobile device based on the telephone number; Receive, from the mobile device, authentication information generated by a contactless card; Determine that the authentication information is genuine; Based on the authentication information being genuine, enable the call connection to continue for communication. A call center system.

10. The code snippet is received from a server based on a user interaction with the mini-application link, and the mini-application link is a uniform resource locator to the server including the code snippet, according to the call center system of claim 9.

11. The server is maintained by an application store, and the code snippet is downloadable to the mobile device upon selection, according to the call center system of claim 10.

12. ​ ​ ​ The call center system according to claim 9, wherein the code snippet is configured to be executed on the mobile device and present a display on the display of the mobile device instructing to tap the contactless card on the surface of the mobile device.

13. including further instructions, wherein the further instructions cause the processing circuit to register a request for authenticating the call connection, generate a call session identifier based on the registration of the request, and the call session identifier is transmitted to the mobile device and used by the call center system to associate the authentication of the authentication information with the call connection. The call center system according to claim 9.

14. including further instructions, wherein the further instructions cause the processing circuit to determine the phone number for the call connection, determine an account associated with the phone number of the mobile device, automatically send the text message to the mobile device based on the determination of the account associated with the phone number, and The call center system according to claim 9.

15. including further instructions for causing the processing circuit to receive a second text message from the mobile device, wherein the text message includes a code for authenticating a call agent of the call center system. The call center system according to claim 9.

16. The call center system receives the authentication information from the code snippet executed on the mobile device, wherein the code snippet is configured to perform a reading operation by the contactless card to receive the authentication information and transmit it to the call center system. The call center system according to claim 9.

17. establishing a call connection with a call center system by a mobile device; receiving, by the mobile device, a text message including a call session identifier and a mini-application link configured to obtain a code snippet from a server; receiving, by the mobile device, the code snippet from the server causing the mobile device to display a prompt on the display of the mobile device and execute the code snippet that prompts to tap a contactless card on or near the mobile device; receiving authentication information from the contactless card by the mobile device based on a tap of the contactless card on or near the mobile device; transmitting, by the mobile device, the authentication information and the call session identifier; maintaining, by the mobile device, the call connection with the call center system based on a display indicating that the authentication information has been authenticated; A computer-implemented method comprising:

18. The computer-implemented method according to claim 17, further comprising transmitting, by the mobile device, a second text message including code for authenticating a call agent of the call center system.

19. The computer-implemented method according to claim 17, wherein the mini-application link is a uniform resource locator to the server including the code snippet.

20. The computer-implemented method according to claim 17, wherein the server is maintained by an application store and the code snippet is downloaded to the mobile device selectively.

Images