System and method for second factor authentication of customer support call

Abstract

To leverage multi-factor authentication features of a service provider and intelligent call routing to increase security and efficiency at a customer call center.SOLUTION: A data transmission system uses pre-authentication of customer support requests that reduces the potential for misappropriation of sensitive customer data during call handling. A contactless card uniquely associated with a client may provide a second factor of authentication via a back-channel to reduce the potential for malicious third-party impersonation of the client prior to transfer of the call to the customer call center. Pre-authorized customer support calls may be intelligently and efficiently routed directly to call center agents, without incurring further delay. During call handling, call center agents may initiate further client authentication processes, including contactless card authentication requests, over different communication channels for authorizing access to sensitive information or to allay suspicion.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] Related Applications This application claims priority to U.S. Patent Application No. 16 / 357,266, entitled "System and Method for Second Factor Authentication of Customer Support Calls," filed March 18, 2019. The contents of the aforementioned application are incorporated herein by reference in their entirety. [Background technology]

[0002] Call center services are typically offered by service providers to allow clients to access, modify, delete, or otherwise control their accounts. From a security perspective, call centers can be a company's highest risk area because call center transactions can expose sensitive customer information to malicious third parties. Up to 90% of the calls received by a customer call center on a given day are from fraudulent callers attempting to gain inappropriate access to customer accounts.

[0003] To address these security concerns, the Payment Card Industry Security Standards Council (PCI SSC) manages the ongoing evolution of the Payment Card Industry (PCI) Security Standards. Service providers are responsible for enforcing compliance with PCI standards to protect sensitive customer data. For example, PCI standards may dictate authentication standards that must be followed before allowing clients to access and / or modify customer account information. Call centers may require client authentication in the form of password exchanges, answers to personal questions, biometric data, and so on. However, authentication technologies are often susceptible to issues such as "spoofing" and "phishing," in which fraudsters mask or change dialed numbers, email addresses, IP addresses, and so on to impersonate clients in an attempt to steal information or funds. External risks also arise from hackers monitoring service provider communications, particularly call center communications, with the intent of stealing customer information. Summary of the Invention

[0004] According to one aspect, a device for authenticating information access requests includes a customer service interface configured to receive an authentication request from a customer service agent, the authentication request associated with the access request received by the customer service agent from a client device via a first communication channel. The authentication request can be used to determine whether the device is authorized to access the information sought by the access request. The device further includes a storage device configured to store client data comprising pre-verified contact information for the client, and a client interface configured to push a second factor authentication request to the client via a second communication channel established using the pre-verified contact information. The client interface can be configured to receive an authentication response from the client. The second communication channel can be different from the first communication channel. The device includes an authentication server coupled to the customer service interface and the client interface for generating the second factor authentication request and selectively unlocking access to the information sought by the access request in response to a match between the authentication response and the stored client data.

[0005] According to another aspect, a method for authenticating an access request received by a customer service agent includes receiving an authentication request from the customer service agent, the authentication request associated with the access request received by the customer service agent from a client device via a first communication channel. The authentication request can be used to determine whether the device has access to information sought by the access request. The method includes retrieving client data including pre-verified contact information for the client from a data store and pushing an authentication request to the device via a second communication channel using the pre-verified contact information. The authentication request can comprise a request for second factor authentication from the client. The method includes receiving a second factor authentication response from the device via the second communication channel, comparing the second factor authentication response to the client data, and selectively authenticating the client in response to the comparing step, including selectively unlocking access to the information sought by the access request.

[0006] According to a further aspect, a method for authenticating an information access request received by a customer service agent includes receiving an authentication request from the customer service agent, the authentication request associated with the access request received by the customer service agent via a first communication channel from a client device. The first communication channel may include a session identifier, and the authentication request may be used to determine whether the device is authorized to access the information sought by the client access request. The method may include retrieving pre-verified client contact information for the client from a data store and pushing the authentication request to the device using a second communication channel established using the pre-verified client contact information. The second communication channel may be different from the first communication channel. The authentication request may include a request for a cryptogram from the client's contactless card, and the method wherein authenticating the access request includes receiving the cryptogram from the client device via a second communication channel, decrypting the cryptogram using a copy of a key associated with the client to provide decrypted counter information, comparing the decrypted counter information with a copy of the counter maintained for the client, and selectively authenticating the client device in response to the comparing step, including selectively unlocking access to the information. The method further includes notifying the client of the access request using a third communication channel generated in response to the pre-verified client contact information, the third communication channel being different from both the first and second communication channels.

[0007] Using a different communication channel to exchange authentication information before granting access to customer data reduces the likelihood of disclosing sensitive customer information, as a malicious party cannot disrupt all client communication interfaces. [Brief explanation of the drawings]

[0008] [Figure 1A] FIG. 1 is a block diagram of a data transmission system configured to pre-authenticate a customer request according to an exemplary embodiment. [Figure 1B] FIG. 1 illustrates a sequence for providing authenticated access according to an exemplary embodiment. [Figure 2] 1B is an example of a contactless card for storing authentication information that may be used in the system of FIG. 1A. [Figure 3] FIG. 3 is a detailed block diagram illustrating exemplary components of the contactless card of FIG. 2. [Figure 4] 1B is a diagram of exemplary fields of messages exchanged between the contactless card of FIG. 1A and a client device. [Figure 5] FIG. 1B is a detailed block diagram of components of the system of FIG. 1A that may be utilized to support aspects of the present invention. [Figure 6] 5 is a data flow diagram provided to illustrate exemplary steps that may be performed in one embodiment by the components of FIG. 4 during call authentication in accordance with aspects of the present invention. [Figure 7] 3 is a data flow diagram provided to illustrate exemplary steps that may be performed during one embodiment of a call routing process using the contactless card of FIG. 2. [Figure 8] 3 is a data flow diagram provided to illustrate exemplary steps that may be performed during another embodiment of the call routing process using the contactless card of FIG. 2. [Figure 9] 1 is a block diagram illustrating an exemplary call processing pipeline in a call service center accepting pre-authenticated service requests. [Figure 10] FIG. 1 is a block diagram provided to illustrate layered security controls that may be provided to client data. [Figure 11] FIG. 10 is a flow diagram provided to illustrate exemplary steps that may be performed by a customer service agent and an authorization service in one embodiment. [Figure 12A]1 illustrates exemplary graphic user interface (GUI) content that may be displayed to customer service agents and clients in various embodiments. [Figure 12B] 1 illustrates exemplary graphic user interface (GUI) content that may be displayed to customer service agents and clients in various embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0009] Some embodiments of the present disclosure focus on the use of one or more keys embedded in one or more contactless cards, as described in U.S. Patent Application No. 16 / 205,119 (hereinafter the '119 Application), filed November 29, 2018, by Osborn et al., entitled "System and Method for Cryptographic Authentication of Contactless Cards," and incorporated herein by reference. Contactless cards can be used for authentication and many other functions that require a user to carry a separate physical token in addition to the contactless card. By employing a contactless interface, contactless cards can be provided with a method for interacting and communicating between a user's device (such as a mobile phone) and the card itself. For example, the EMV protocol underlying many credit card transactions is sufficient for the Android® operating system, but is only used for read-only authentication, presenting challenges for iOS®, which is more limited in its use of near-field communication (NFC). This differs from RFID, which can be used to read moving devices at significant distances. Exemplary embodiments of the contactless cards described in the '119 Application may utilize NFC technology.

[0010] Thus, a system and method are disclosed that leverages a service provider's multi-factor authentication capabilities and intelligent call routing to improve the security and efficiency of customer call centers. Pre-authentication of customer support requests reduces the likelihood of sensitive customer data being misused during call processing. A contactless card uniquely associated with a client may provide a second factor of authentication, reducing the likelihood of a malicious third party impersonating the client. Pre-approved customer support calls are intelligently and efficiently routed in a manner that reduces the opportunity for malicious call interference and information theft.

[0011] According to other aspects, it is recognized that it may be beneficial for a customer service representative to further authenticate a client during the processing of a customer service request. Such further authentication may be performed for a variety of reasons, including before allowing changes to highly sensitive data, including passwords and contact information, or before allowing access to certain services, such as loan services. Further authentication may also be required when a customer is transferred between customer service agents or if a customer service agent has doubts about the trustworthiness of a client seeking access to client information.

[0012] According to one aspect, authentication may be performed using communication channels and protocols other than those used to request information access. In some embodiments, the communication channel is established using the client's contact information that has been pre-verified by the service provider. In some embodiments, after access is granted, the client may be notified of such access using other communication methods, such as email or text messaging. Using different communication channels and protocols at various stages of authentication limits the potential for malicious third parties to interfere, as it makes it difficult for a malicious third party to simultaneously interfere with each communication medium used for authentication.

[0013] These and other features of the present invention are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout.

[0014] As used in this application, the terms "system," "component," and "unit" are intended to refer to a computer-related entity that is either hardware, a combination of hardware and software, software, or software in execution, examples of which are described herein. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer. Illustratively, both an application running on a server and the server may be a component. One or more components may reside 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.

[0015] Additionally, components may be communicatively coupled to one another by various types of communication media to coordinate operations. Coordination may include one-way or two-way information exchange. For example, components may communicate information in the form of signals communicated over the communication media. This information may be embodied as signals assigned to various signal lines. In such an assignment, each message is a signal. However, further embodiments may alternatively use data messages. Such data messages may be transmitted over various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0016] 1A illustrates a system 100 that includes one or more client devices 110 coupled to a service provider 120 via a network 115. According to one aspect, the client devices 110 comprise network-enabled computers and communicate with the service provider 120 via networks 115 and 125 to access the service provider's content and services.

[0017] As referred to herein, a network-enabled computer may include, for example, but is not limited to, a computing device or communication device including, for example, a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a telephone, a handheld PC, a personal digital assistant (PDA), a thin client device, a fat client device, an internet browser, or other device.

[0018] Accordingly, it is understood that client device 110 may include a processor and memory, and that processing circuitry may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proof hardware, as necessary to perform the functions described herein. Client device 110 may further include a display and input devices. The display may be any type of device for presenting visual information, such as a computer monitor, a flat-panel display, and a mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input devices may include any device for inputting information into a user's device that is available and supported by the user's device, such as a touchscreen, keyboard, mouse, cursor control device, touchscreen, microphone, digital camera, video recorder, or camcorder. These devices may be used to input information and interact with the software and other devices described herein.

[0019] The one or more client devices 110 may also be mobile devices such as, for example, an Apple® iPhone®, iPod®, iPad®, or other mobile device running Apple's iOS® operating system, any device running Microsoft's Windows® mobile operating system, and / or other smartphones or similar wearable mobile devices.

[0020] 1A includes a mobile phone 142, a laptop 144, a tablet 148, and a terminal 146. The client device 110 may include a thin client application specifically adapted for communication with the service provider 120. The thin client application may be stored in the memory of the client device, be operative when executed by the client device, control the interface between the client device and service provider applications, and enable a user of the client device to access service provider content and services.

[0021] In some examples, network 115 may be one or more of a wireless network, a wired network, or any combination of wireless and wired networks, and may be configured to connect client device 110 to service provider 120. For example, network 115 may include one or more of an optical fiber network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, 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 multiplex-based system, a code division multiple access-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, etc.

[0022] Additionally, network 115 may include, but is not limited to, a telephone line, optical fiber, IEEE Ethernet 902.3, a wide area network ("WAN"), a wireless personal area network ("WPAN"), a local area network ("LAN"), or a global network such as the Internet. Furthermore, network 115 may support an Internet network, a wireless communication network, a cellular network, or the like, or any combination thereof. Network 115 may further include one or any number of the exemplary types of networks listed above, operating as a standalone network or in cooperation with one another. Network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 may translate one or more protocols of network devices to and from other protocols.

[0023] According to one or more examples, it should be appreciated that network 115 may be part of multiple interconnected networks, such as, for example, the Internet, a service provider's private network 125, a cable television network, an enterprise network such as a credit card association network, a home network, etc. Additionally, private network 125 may be implemented as a virtual private network layered on network 115.

[0024] Service provider 120, in one embodiment, is a business that provides computer-based services to clients over network 115. Almost all modern service providers use the Internet to deliver their services to potential consumers. The service offerings are typically provided in the form of software applications that operate using the service provider's dedicated resources. The combination of software and hardware that provides a particular service to clients is referred to herein as a "server." The server may communicate over the service provider's private network 125, often referred to as an enterprise or business network. Private network 125 may comprise a wireless network, a wired network, or any combination of wireless and wired networks, as described above with respect to network 115.

[0025] In the system of FIG. 1A , service provider 120 is shown to include application server 150, authentication server 160, and customer relationship management (CRM) server 140. While each server is shown as a separate device, it should be understood that applications and servers may be distributed throughout an enterprise, or in the case of distributed resources such as “cloud” resources, throughout network 115. Application server 150 may support one or more application services offered by service provider 120, such as account management services. CRM server 140 may be used to provide customer support services to clients of service provider 120, including processing and forwarding incoming calls from the clients to one or more call processing agents running on workstations 132, 135.

[0026] Database 130 comprises a data storage resource that may be used, for example, to store customer accounts, credentials, and other authentication information used by application server 150 and authentication server 160. Database 130 may be comprised of combined data resources comprising any combination of local storage, distributed data center storage, or cloud-based storage.

[0027] According to one aspect, contactless card 105 may communicate wirelessly, e.g., via near field communication (NFC), with one or more client devices 110. For example, contactless card 105 may include one or more chips, such as a radio frequency identification chip, configured to communicate via NFC or other short-range protocols. In other embodiments, contactless card 105 may communicate with client device 110 via other means, including, but not limited to, Bluetooth, satellite, and / or WiFi. As described in the '119 application, contactless card 105 may be configured to communicate with one of card reader terminal 146, mobile phone 142, laptop 144, and / or tablet 148 via NFC when contactless card 105 is within range of the respective client device. As described in more detail below, contactless card 105 may contain key and counter information that can be converted using an encryption algorithm to generate cryptograms that can be used by a service provider to authenticate the client device.

[0028] 1B is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. System 100 may include contactless card 105 and client device 110, which may include application 122 and processor 124. FIG. 1B may reference similar components as shown in FIG. 1A.

[0029] In step 102, application 122 communicates with contactless card 105 (e.g., after being brought into proximity with contactless card 105). Communication between application 122 and contactless card 105 may involve contactless card 105 being sufficiently close to a card reader (not shown) of client device 110 to enable NFC data transfer between application 122 and contactless card 105.

[0030] In step 104, after communication is established between the client device 110 and the contactless card 105, the contactless card 105 generates a message authentication code (MAC) cryptogram. In some examples, this may occur when the contactless card 105 is read by the application 122. In particular, this may occur upon a read, such as an NFC read of a Near Field Communication Data Exchange (NDEF) tag, which may be created according to the NFC data exchange format. For example, a reader, such as the application 122, may send a message, such as an applet selection message, using the applet ID of the NDEF generation applet. Once the selection is confirmed, a sequence of select file messages followed by a read file message may be sent. For example, the sequence may include "select feature file," "read feature file," and "select NDEF file." At this point, a counter value maintained by the contactless card 105 may be updated or incremented, followed by "read NDEF file." At this point, a message may be generated, which may include a header and a shared secret. A session key may then be generated. A MAC ciphertext may be created from the message, which may include a header and a shared secret. The MAC ciphertext may then be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) may be encrypted with a session key. The ciphertext and header may then be concatenated, encoded as ASCII hexadecimal, and returned in NDEF message format (in response to a "read NDEF file" message).

[0031] In some examples, the MAC cryptogram may be transmitted as an NDEF tag, and in other examples, the MAC cryptogram may be included with the uniform resource indicator (eg, as a formatted string).

[0032] In some examples, the application 122 may be configured to send a request to the contactless card 105, the request comprising instructions to generate a MAC cryptogram.

[0033] In step 106, contactless card 105 transmits the MAC cryptogram to application 122. In some examples, transmission of the MAC cryptogram occurs via NFC, although this disclosure is not limited thereto. In other examples, this communication may occur via Bluetooth, Wi-Fi, or other wireless data communication means.

[0034] In step 108, the application 122 communicates the MAC ciphertext to the processor 124.

[0035] In step 112, processor 124 verifies the MAC ciphertext according to instructions from application 122. For example, the MAC ciphertext may be verified as described below.

[0036] In some examples, verification of the MAC ciphertext may be performed by a device other than client device 110, such as a service provider 120 in data communication with client device 110 (as shown in FIG. 1A). For example, processor 124 may output the MAC ciphertext for transmission to service provider 120, which may verify the MAC ciphertext.

[0037] In some examples, the MAC ciphertext may act as a digital signature for purposes of verification, which may be performed using a public key asymmetric algorithm, such as the Digital Signature Algorithm and the RSA algorithm, or other digital signature algorithms such as zero-knowledge protocols.

[0038] More specifically, according to one aspect, the contactless card 105 may be used in conjunction with first authentication credentials provided to the application service provider to pre-authenticate a customer support request before forwarding the support request to the CRM server 140. Pre-authentication of a customer support request in this manner has two advantages: The authentication information is not forwarded to the CRM, thereby avoiding the opportunity for misuse of such information by a call center agent. Furthermore, the use of a contactless card as a second factor of authentication allows a specific device / phone number to be associated with a specific individual (i.e., the card owner), thereby eliminating the ability of a malicious third party to "spoof," i.e., impersonate, the client. According to other aspects, the pre-authentication communication protocol described below identifies or uses a specific communication channel for call processing, thereby reducing the opportunity for client spoofing.

[0039] Example embodiments of the systems and methods described herein may be configured to provide multi-factor security authentication that may be used to bypass authentication by CRM server 40, thereby reducing the likelihood of theft of sensitive customer information during call processing.

[0040] Security factor authentication may comprise multiple processes. A first authentication process may comprise logging in and verifying a user via one or more applications running on the device. A second authentication process may operate after successful login and verification to have the user perform one or more actions associated with one or more contactless cards. Effectively, the security factor authentication process comprises a multi-factor authentication process that may include both securely proving the user's identity and having the user perform one or more types of actions, including, but not limited to, one or more tap gestures associated with the contactless card. In some examples, the one or more tap gestures may comprise a user tapping a contactless card against the device. In some examples, the device may comprise a mobile device, a kiosk, a terminal, a tablet, or any other device configured to process received tap gestures.

[0041] For example, to provide a first layer of authentication, a client may access a service provider's website by linking to the service provider's web page using an internet browser application running on the client device. A browser is a software application, such as Google® Chrome®, Internet Explorer®, or Safari®, that includes programming code for converting the service provider application's HyperText Markup Language (HTML) web pages into a format suitable for the client operating the client device. As part of accessing the service provider's website, the service provider may request first authorization information, including password information, answers to pre-stored queries, biometric information, a picture, or other mechanism that verifies that the user of the client device is authorized to access content and services, including accounts managed by the service provider.

[0042] Certain high-risk services offered by service providers, such as call center support, can benefit from multi-factor authentication. For example, a service provider may store first-level authentication information as a cookie in a client's browser to speed up the authentication process during client login. Browser cookies, and associated passwords and other data, are vulnerable to discovery and misuse. Therefore, before allowing a user to access or modify sensitive or personal information, as may occur during a customer support call, it is important to verify that the user is authorized to do so.

[0043] According to one aspect, the contactless card 105 may be used to provide a second authentication for a user of a client device. In one embodiment, as described in more detail below, the contactless card includes a key, a counter, and cryptographic processing functions that may be used to generate a cryptogram that may be used to verify the user of the client device. The counter advantageously reflects the card owner's previous behavior. For example, the counter may reflect the number of times the user has previously accessed a particular service of a service provider. This information is virtually impossible for a malicious third party to accurately gather.

[0044] According to one aspect, and as described in more detail below, the cryptographic text exchange occurs using backchannel communication; for purposes of this specification, a "backchannel" is a communication channel established between a client and an authentication server for the exchange of authentication tokens. In some embodiments, the communication channel used for backchannel authentication is different from the application communication channel established between a service provider application server and a client. For example, communication between a client and a service provider via the service provider's web interface may be authenticated using a backchannel call, text, or email issued directly to a pre-verified contact of the client. In other embodiments, the communication channel may leverage information (such as session information) from the application communication channel when establishing the backchannel communication link.

[0045] When a client seeks access to a high-risk service, in some embodiments, the service provision application may prompt the user to provide a second level of authentication using the contactless card 105, for example, by tapping or otherwise communicatively coupling the card 105 to one of the client devices 110, as described above.

[0046] Following the second authentication, as described in more detail below, the service provider returns data to the client device. The data may include data that enables the client to initiate a communications link with the CRM server 140. Such data may include contact information, such as a link to a CRM service provider application or a call center phone number. In some embodiments, the contact information may be augmented with CRM or call center control information. For example, the control information may instruct the CRM or call center to bypass any authentication or interactive voice response (IVR) process typically performed at the call center, considering the client has already been pre-authenticated by the service provider application / contactless card multi-factor authentication process.

[0047] While the above description describes the first authentication as using personal, biometric, question, or other authentication information, it is recognized that in some examples, a client application running on the device may initially activate or launch an application on the device in response to a tap of the contactless card. In such examples, both the first and second authentication processes use a key / counter contactless card authentication process, described in more detail below. In some embodiments, if a client-side application is not installed on the client device, tapping the contactless card in proximity to a card reader may initiate download of the application (e.g., navigation to the application's download page). Following installation, tapping the contactless card may activate or launch the application, and subsequently, activation of the contactless card may be initiated, for example, via application or other back-end communication. In some examples, one or more applications may be configured to determine that they were launched via one or more tap gestures of the contactless card, such as that they were launched at 3:51 PM and that a transaction was processed or made at 3:56 PM, to verify the user's identity.

[0048] In some examples, data may be collected about tapping behavior as biometric / gesture authentication. For example, a cryptographically secure and resistant to interception unique identifier may be transmitted to one or more backend services. The unique identifier may be configured to retrieve secondary information about the individual. The secondary information may comprise personally identifiable information about the user, including, but not limited to, social security information, query responses, passwords, account information, etc. In some examples, the secondary information may be stored within a contactless card.

[0049] FIG. 2 illustrates one or more contactless cards 200, which may comprise a payment card, such as a credit card, debit card, or gift card, issued by a designated service provider 205 displayed on the front or back of the card 200. In some examples, the contactless card 200 may comprise, but is not limited to, an identification card unrelated to a payment card. In some examples, the payment card may comprise a dual-interface contactless payment card. The contactless card 200 may comprise a substrate 210, which may include a single layer or one or more laminated layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium oxide, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 300 may have physical characteristics conforming to the ID-1 format of the ISO / IEC 7810 standard; otherwise, the contactless card may conform to the ISO / IEC 14443 standard. However, it is understood that contactless cards 200 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be embodied in a payment card.

[0050] Contactless card 200 may also include identification information 215 displayed on the front and / or back of the card, and contact pad 220. Contact pad 220 may be configured to establish contact with a user device or other communication device, such as a smartphone, laptop, desktop, or tablet computer. Contactless card 200 may also include processing circuitry, an antenna, and other components not shown in FIG. 2. These components may be located behind contact pad 220 or elsewhere on substrate 210. Contactless card 200 may also include a magnetic strip or tape (not shown in FIG. 2) that may be located on the back of the card.

[0051] 3A may include processing circuitry 325 for storing and processing information, including a microprocessor 330 and memory 335. It is understood that processing circuitry 325 may include additional components, including processors, memory, error and parity / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tamper hardware, as needed to perform the functions described herein.

[0052] The memory 335 may be read-only memory, write-once read-multiple memory, or read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 300 may include one or more of these memories. Read-only memory may be programmable as read-only at the factory or one-time programmable. One-time programmability allows it to be written once and then read many times. Write-once read-multiple memory may be programmed at some point after the memory chip leaves the factory. Once the memory is programmed, it cannot be rewritten, but it can be read many times. Read / write memory may be programmed and reprogrammed many times after leaving the factory and may be read many times.

[0053] The memory 335 may be configured to store one or more applets 340, one or more counters 345, and a customer identifier 350. The one or more applets 340 may comprise one or more software applications configured to run on one or more contactless cards, such as a Java Card applet. However, it is understood that the applet 340 is not limited to a Java Card applet and may instead be any software application capable of operating on a contactless card or other device with limited memory. The one or more counters 345 may comprise a numeric counter sufficient to store an integer. The customer identifier 350 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 300, which may distinguish the contactless card user from other contactless card users. In some examples, the customer identifier 350 may identify both the customer and the account assigned to the customer, and may further identify the contactless card associated with the customer's account.

[0054] Although the processor and memory elements of the foregoing exemplary embodiments are described with reference to contact pads, the present disclosure is not limited thereto. These elements may be implemented outside of the pads 320, may be completely separate from the pads 220, or may be implemented as additional elements in addition to the processor 330 and memory 335 elements disposed within the contact pads 320.

[0055] In some examples, the contactless card 300 may include one or more antennas 355. The one or more antennas 355 may be disposed within the contactless card 300 and around the processing circuit 325 of the contact pad 320. For example, the one or more antennas 355 may be integral with the processing circuit 325, or the one or more antennas 355 may be used with an external booster coil. As another example, the one or more antennas 355 may be external to the contact pad 320 and the processing circuit 325.

[0056] In one embodiment, the coil of the contactless card 300 may function as the secondary of an air-core transformer. The terminal may communicate with the contactless card 300 by interrupting power or amplitude modulation. The contactless card 300 may infer data transmitted from the terminal using a gap in the contactless card's power connection, which may be maintained functionally via one or more capacitors. The contactless card 300 may return communication by switching or load modulating the load on the contactless card's coil. Load modulation may be detected by interference in the terminal's coil.

[0057] As described above, contactless card 300 may be built on a software platform capable of operating on a smart card or other device with limited memory, such as a Java card, and one or more applications or applets may be securely executed. An applet may be added to the contactless card to provide one-time passwords (OTPs) for multi-factor authentication (MFA) in various mobile application-based use cases. The applet may be configured to respond to one or more requests, such as a Near Field Wireless Data Exchange (NDEF) request, from a reader, such as a mobile NFC reader, and generate an NDEF message comprising the cryptographically secure OTP encoded as an NDEF text tag.

[0058] FIG. 4 illustrates an exemplary NDEF short record layout (SR=1) 400 according to an exemplary embodiment. NDEF messages provide a standardized method for client device 110 to communicate with contactless card 105. In some examples, an NDEF message may comprise one or more records. NDEF record 400 includes a header 402 containing several flags that define how to interpret the rest of the record, including a Message Start (MB) flag 403a, a Message End (ME) flag 403b, a Chunk flag (CF) 403c, a Short Record (SR) flag 403d, an ID Length (IL) flag 403e, and a Type Name Format (TNF) field 403f. MB 403a and ME flag 403b may be set to indicate the first and last records, respectively, of the message. CF 403c and IL flag 403e provide information about the record, including whether the data is "chunked" (data spread across multiple records within a message) or whether an ID Type Length field 408 is relevant, respectively. If the message contains only one record, the SR flag 403d may be set.

[0059] The TNF field 403f identifies the type of content the field contains, as defined by the NFC protocol. These types include empty, well-known (data defined in the NFC Forum's Record Type Definition (RTD)), Multipurpose Internet Mail Extensions (MIME) [defined in RFC2046], absolute Uniform Resource Identifier (URI) [defined in RFC3986], foreign (user-defined), unknown, unchanged [for chunks], and reserved.

[0060] Other fields in an NFC record include type length 404, payload length 406, ID length 408, type 410, ID 412, and payload 414. It contains the length of the payload type in bytes. Type length field 404 specifies the exact type of data found in the payload. Payload length 406 contains the length of the payload in bytes. A record may contain up to 4,294,967,295 bytes (or 2^32-1 bytes) of data. ID length 408 contains the length of the ID field in bytes. Type 410 identifies the type of data contained in the payload. ID 412 provides a means for external applications to identify the entire payload carried within the NDEF record. Payload 414 comprises the message.

[0061] In some examples, data may be initially stored on the contactless card by implementing STOREDATA (E2) under a secure channel protocol. This data may include a personal user ID (pUID) unique to the card, as well as one or more initial keys, cryptographic processing data including session keys, data encryption keys, random numbers, and other values ​​described in more detail below. These values ​​may be used to generate a message authentication code (MAC), which may be used to pre-authenticate a client before processing customer service.

[0062] Exemplary information that may be exchanged with contactless card 105 and authentication server 160 during initialization to input into the contactless card to support secure authentication according to various aspects is shown in Table 1 below.

[0063] [Table 1]

[0064] After initialization, both the contactless card and the authentication server store information to uniquely identify the cardholder. These features may be used according to one embodiment to authenticate client access to high-risk services, as described below.

[0065] FIG. 5 illustrates a communications system in which a contactless card 510 may store information such as that contained in Table 1 and may be used to authenticate a user before connecting the user to a service provider's high-risk service. In one aspect, a "high-risk service" is a service that may benefit from a multi-factor authentication process because the service has the opportunity to expose sensitive customer or other information. As described with respect to FIG. 3, each contactless card may include memory 516 for storing customer information 518, including one or more uniquely identifying attributes such as an identifier, a key, a random number, etc. In one aspect, the memory further includes an authentication applet 517 operable when executed by the microprocessor 512 to control the authentication process described herein. Additionally, each contactless card 510 may include one or more application transaction counters (ATCs) 514 and an interface 515. As noted above, in one embodiment, the interface operates NFC or other communications protocols.

[0066] The client device 520 also includes a card interface 525 for communicating with a contactless card and one or more other network interfaces (not shown) that enable the client device 520 to communicate with a service provider using various communication protocols, as described above. The client device may further include a user interface 526, which may include one or more of a keyboard or a touchscreen display, that enables communication between a service provider application and a user of the client device 520. The client device 520 further includes memory 522 that stores information and program code that controls the operation of the client device 520, including, for example, a client-side application 523, which may be provided to the client by the service provider to facilitate access to and use of the service provider's application. In one embodiment, the client-side application 523 includes program code configured to communicate authentication information from the contactless card 510 to one or more services offered by the service provider. The client-side application 523 may be controlled via input received at a service provider (SP) application interface 527 displayed on the user interface 526. For example, a user may select an icon, link, or other mechanism provided as part of the SP application interface 527 to launch the client-side application and access the SP application services.

[0067] As described with respect to FIG. 1A , client device 520 may be connected to various services provided by service provider 505, including customer relationship management (CRM) server 540 and authentication server 550. In one embodiment, CRM server 540 manages the routing of received support calls and the forwarding of received calls to call processing pipeline 542. Authentication server 550 includes client information table 552 for storing information such as Table 1 for clients of the service provider. Authentication server 554 includes hardware and software for performing various authentication processes for clients using information from client counter value table 556. In one embodiment, authentication server 554 is further shown to include client interface 557 for exchanging authentication messages with client devices and customer service interface 553 for exchanging authentication messages with CRM server 540. Authentication server 520 may also include client counter value table 556, which may be used as described below to perform authentication in combination with contactless card 510.

[0068] 6 illustrates various steps that may be performed by a contactless card 601, a client device 611, and an authentication service of a service provider 621 configured to use key diversification techniques as part of a multi-factor authentication protocol to pre-authenticate a client. For example, a cardholder of contactless card 601 with access to client device 611 may seek authentication from service provider 621 to enable access to services, including requiring multi-factor authentication for access to high-risk services such as call center support.

[0069] At step 610, the client device 611 first accesses a client account maintained by the service provider 621 by exchanging login credentials with the service provider, which may include, but are not limited to, a password, a key, biometric data, image data, and a query. In one embodiment, the client may initiate this access by launching a client-side application via the SP application interface 527. Launching the app may include displaying a web page of the service provider configured to accept first credentials from the user.

[0070] In some embodiments, the first level of authentication may be performed using the cryptogram exchange process described below for the second level of authentication. The service provider app may be launched by tapping the contactless card 601 to the client device 611, initiating the cryptogram exchange as a precursor to granting access to the service provider app.

[0071] The service provider receives the credentials in step 620 and compares them with the client's credentials maintained by the authentication server. If the login credentials do not match in step 622, the service provider proceeds to step 631 and pursues authentication of the client device using other methods. If a match is determined in step 622, the client is authenticated and the service provider coordinates with a client-side application maintained by the client device 611 to display the service provider's web page to the client, enabling access to one or more services.

[0072] In step 614, the client device requests access to a high-risk application, e.g., a customer service application. The client may request access by, for example, selecting one of multiple hyperlinks provided on the service provider's website, directing the client to the selected service. The hyperlink may include, for example, a web address of the service's landing page. Alternatively, the hyperlink may include a telephone number for a customer support system.

[0073] Upon receiving the customer service request in step 624, the service provider determines that the selected service is a high-risk service that would benefit from a second level of authentication. For example, in embodiments that offer second factor authentication using a contactless card, the service provider may prompt the client device to use the contactless card to obtain a cryptogram for verification purposes. The prompt may be any method of indicating to the client that a contactless card should be used, including a text prompt, a visual prompt, an audible prompt, and other available display mechanisms.

[0074] The client device 611 receives this request and uses the contactless card in step 616. In one aspect, the client device uses the NFC communication channel described above to exchange messages with the contactless card, which cooperates to provide second factor authentication through a combination of a symmetric key, a symmetric encryption process, and a counter.

[0075] In step 602, the contactless card receives an authentication request. In step 604, a processing component within the contactless card increments an application service transaction (AST) counter and encodes the counter using a symmetric encryption algorithm with a master key stored on the contactless card to generate a diversified key. The encryption algorithm may be selected from a group including at least one of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm. In some examples, the symmetric algorithm used to process the diversification value may comprise any symmetric encryption algorithm used as needed to generate a diversified symmetric key of a desired length. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms such as 3DES (Triple Data Encryption Algorithm) or Advanced Encryption Standard (AES) 128, symmetric hash-based message authentication (HMAC) algorithms such as HMAC-SHA-256, and symmetric cipher-based message authentication code (CMAC) algorithms such as AES-CMAC. It will be appreciated that if the output of the selected symmetric algorithm does not generate a sufficiently long key, techniques such as processing multiple iterations of the symmetric algorithm with different input data and the same master key may generate multiple outputs that can be combined as needed to generate a key of sufficient length.

[0076] The contactless card's processing component may use a selected encryption algorithm and process the counter value using a master symmetric key. For example, the contactless card 601 may select a symmetric encryption algorithm and use a counter that increments for each authentication transaction processed by the contactless card. The contactless card 601 may then encrypt the counter value with the selected symmetric encryption algorithm using the master symmetric key to generate a diversified symmetric key.

[0077] In one aspect, a diversified symmetric key may be used to process the counter before transmission for authentication purposes. For example, the contactless card 601 may encrypt the counter value using a symmetric encryption algorithm and a diversified symmetric key, and the output comprises an encrypted MAC ciphertext. The contactless card 601 may then transmit the ciphertext to the service provider 621 for authentication. In some examples, the counter value may not be encrypted. In these examples, the counter value may be transmitted between the transmitting device 205 and the receiving device 210 in block 230 without encryption.

[0078] In one embodiment, the authentication message template comprising the cryptogram may comprise a first record with a known index to provide the actual dynamic authentication data. Table 2 below is an example of an authentication message that may be exchanged between the client device 611 and the contactless card 601.

[0079] [Table 2]

[0080] In one example, if an additional tag is added, the first byte is changed to indicate the start of the message but not the end, and subsequent records can be added. Because the ID length is zero, the ID length field and ID are omitted from the record. The example message shown in Table 3 below may include: UDKAUT key; derived AUT session key (using 0x1234); version 1.0; pATC=0x1234; RND=76a6627b67a8cfbb; MAC=<calculated 8 bytes>. The first column may comprise the address / index to the NDEF message data.

[0081] [Table 3]

[0082] In step 618, client device 611 receives the ciphertext and forwards it to service provider 621. In step 626, after the service provider requested second factor authentication in step 624, in one embodiment, the authentication server of service provider 621 retrieves client information associated with the cardholder of the contactless card associated with the client's account using the client device. The client information may include the client's master key and a counter of the contactless card's application service transactions. Service provider 621 encodes the retrieved counter value using the master key and an encryption algorithm that matches the encryption algorithm used by the contactless card to generate the service provider's copy of the diversified key.

[0083] In step 628, the service provider decrypts the ciphertext using the diversified key and publishes the counter value transmitted by the contactless card. In step 629, the service provider compares the published counter with the counter obtained by the service provider, which provides a second authentication of the user. If there is no match, the client is not allowed access to the service, and in step 631, the service provider 621 may attempt to authenticate the user using other methods. If there is a match in step 629, the service provider initiates call processing with the CRM server in 630. In one aspect, as described with respect to FIGS. 7 and 8, the service offering may generate one or more messages to control the CRM or one of the client devices to leverage pre-authentication already performed by the service provider.

[0084] When the contactless card is then used for authentication, a different counter value can be selected to generate a different diversified symmetric key, making it difficult for a malicious party monitoring the communications to decrypt the communications. Both the service provider and the contactless card increment the counter according to a predetermined increment pattern agreed upon between the parties. For example, the counter may increment by 1 or in a pattern, such as by 1 for the first transaction, by 2 for the second, by 3 for the third, or by 5 for each transaction. Because the contactless card and the service provider use a common counter, a common increment pattern, a common master key, and a common encryption algorithm, the diversified key changes for each transaction, but both the sending and receiving devices have the same key.

[0085] As noted above, in some examples, the key diversification value may be achieved using a counter value. Other non-limiting examples of key diversification values ​​include: a random nonce generated each time a new diversified key is needed; the complete value of a counter value transmitted from the sending device and the receiving device; a portion of a counter value transmitted from the sending device and the receiving device; a counter maintained independently by the sending device and the receiving device but not transmitted between the two; a one-time passcode exchanged between the sending device and the receiving device; or a cryptographic hash of a counter. In some examples described in the '119 application, one or more portions of the key diversification value may be used by the parties to create multiple diversified keys. For example, a counter may be used as a key diversification value.

[0086] In other examples, a portion of the counter may be used as a key diversification value. When multiple master key values ​​are shared between parties, multiple diversified key values ​​may be obtained by the systems and processes described herein. New diversification values, and therefore new diversified symmetric keys, may be created as often as needed. In the most secure case, a new diversification value may be created each time sensitive data is exchanged between a sending device and a receiving device. In effect, this may create a one-time-use key, such as a single session key.

[0087] Various other symmetric encryption / decryption techniques alternative to those described with respect to FIG. 6 are described in the '119 application, which is incorporated herein by reference.

[0088] 7 and 8 each illustrate an example transaction flow that may occur following pre-authentication of a client seeking access to call center services. In one embodiment, customer information stored on a contactless card may include call center information specific to the client. The call center information may include, for example, a number. The number may comprise an IP address, a telephone number, or other contact address, a random number, or any portion or combination of an IP address, telephone number, or other contact address, or a random number. FIG. 7 illustrates example messaging that may occur between components of a call routing process 700 that uses call center information from a contactless card 701 to define a communication link between a client device 702 and a customer service agent 705.

[0089] Following the multi-factor pre-authentication process shown in FIG. 6 , the service provider's authentication server 703 populates the client interface with customer service web content 710. The web content may include contact information, contact information with a URL for communicating with the CRM server, a phone number, or other contact address. Selecting a link creates a communication link between the client device and the CRM server. According to one embodiment, the customer service web content includes a prompt 711 requesting connection with the contactless card 701.

[0090] Upon receiving the prompt, the contactless card 701 forwards the stored pre-authentication number 712 to the client device, thereby providing it to the authentication server 703. In one embodiment, the stored pre-authentication number 712 includes a unique number associated with the pre-authentication of the client device. At least a portion of the pre-authentication number may be appended to the contact information upon creation of the communication link. For example, the web content 710 may include a link to a customer service phone number 1-800-123-4567. The contactless card may provide a pre-authentication number of 7777, to which the client device appends the phone number. The client device initiates a call 715 to -800-123-4567, , , 7777 over the cellular network. The application server alerts the CRM of the incoming call with the appended number from the contactless card at 714. The CRM monitors incoming calls with the pre-authentication number and bypasses authentication when placing the call at 716 in the customer service agent pipeline.

[0091] While the process of FIG. 7 includes a pre-authentication number stored on the contactless card, in some embodiments, the client device may be configured to generate a pre-authentication number to add to the call. The pre-authentication number may be generated in response to communication with the contactless card, for example, following a cryptogram exchange with the contactless card, as described in FIG. 6. In some embodiments, the pre-authentication number may be changed for each customer support request. Such an arrangement protects customer support calls from being redirected by malicious parties, because a fake client device would not have the pre-authentication number and would not bypass authentication at the CRM server.

[0092] In another embodiment, as shown in FIG. 8, to further protect call processing from malicious interference, call processing is initiated by a customer service agent. Following pre-authentication using the process of FIG. 6, customer support web content 810 is provided to the client device. In one embodiment, the content includes a prompt 811 to re-authenticate the client device. The contactless card 812 generates a cryptogram as described above, which is forwarded via the client device 702 to the authentication server 703 for verification. If the authentication server verifies the cryptogram, then in step 814 the authentication server instructs the CRM server to bypass authorization for the call. In step 815, the call is placed in a call agent queue, bypassing authorization, and in step 816 the CRM initiates a backchannel call. Here, a backchannel call is a call initiated via a communications link established directly between a server (e.g., the CRM server) and the client device's telephone number, IP address, etc.

[0093] In some embodiments, a re-authentication step may occur following initiation of the call in step 816 by the customer service agent 705, ensuring that the call is not redirected between the previous authentication and call processing. Methods that a customer service agent may use to re-authenticate or further approve client access are described in more detail below. Such embodiments may be beneficial when there is a delay between the previous authentication and call processing, for example, a long wait in a customer service queue or a scheduled callback.

[0094] 9 illustrates some exemplary components of one embodiment of a CRM service 900. The CRM service 900 is shown to include authentication logic 906 and an agent allocation unit 910. An incoming call 901 is forwarded to a pre-authentication filter 902, which may store a pre-authentication number received from an authentication server, as described above. Incoming calls that are not pre-authenticated are forwarded to an authentication queue 904. The authentication logic retrieves the incoming call from the authentication queue 904 and works with an authentication server (not shown) to verify the client using any combination of the authentication methods described above. Once authenticated, the call is forwarded to queue 908.

[0095] Incoming calls that are determined to be pre-authenticated are forwarded directly from pre-authentication filter 902 to queue 908. Advantageously, to minimize the possibility of malicious interference, when a call that has a stored pre-authentication number is bypassed in this manner, the pre-authentication number is removed from pre-authentication filter 902.

[0096] Thus, queue 908 stores authorized calls that are assigned to agents 920, 922, 924 for processing by agent allocation unit 910 according to resource loading. With such an arrangement, pre-authorized calls can be intelligently routed to customer call centers, minimizing processing delays.

[0097] Thus, a system and method have been described that leverages a service provider's multi-factor authentication capabilities and intelligent call routing to improve security and efficiency in customer call centers. According to other aspects, it is understood that the benefits of the above authentication process can be further leveraged by customer service agents during call handling. For example, a customer service agent may request an increased level of authentication to provide greater control over access to client information or to verify the ongoing authenticity of the client. While the multi-factor authentication process of FIG. 6 has been described as useful for authenticating clients before granting access to high-risk services, it should be understood that even within high-risk services, there is data and actions that are likely to compromise a client account and therefore should have limited access.

[0098] For example, there is a higher risk of disclosing the password of an individual's account than the balance of the individual's account. Furthermore, there is a great risk in allowing individuals to change their phone number or email, as these means of communication are usually used during password changes, and if a malicious user changes this data, access to the account by the appropriate client may be lost.

[0099] 10 , a block diagram of an exemplary subset of components of a system 1000 operating in accordance with aspects of the present invention may include multiple customer service agents (CSAs) 1032, 1034 using a data server 1036 to access client data 1040. The client data 1040 is conceptually distributed into a tiered data structure including high sensitivity data 1042, medium sensitivity data 1044, and low sensitivity data 1046. Each tier is therefore associated with a different level of data sensitivity and an accompanying different degree of access control. In some embodiments, certain sensitive data may be made unavailable to unauthorized parties, as indicated by shaded data items, such as data item 1045.

[0100] Thus, account takeover fraud is prevented, and in one embodiment, a customer service agent (or software running on the customer service agent workstation) may proactively request additional factor authentication during a call. For example, the customer service agent may affirmatively select a button on a graphic user interface (GUI) dashboard to generate a request to an authentication server to perform an authentication process. Alternatively, the customer service agent may select a data element on a screen that is indicated as having restricted access, and that selection may proactively result in the generation of additional factor authentication.

[0101] The generated additional factor authentication request may take many forms that desirably verify that the device initiating the access request is both associated with the client and in the client's (or someone authorized by the client's) physical possession. For example, a "push" message may be issued by the authentication server to the client device, the push message including a prompt requesting authentication data that is personal to the authorized device or personal to the authorized client.

[0102] For example, such authentication methods may include, but are not limited to, in-application notifications (such as CaptialOne® SwiftID in-app challenges), short message service (SMS) code exchange, and the contactless card authentication process described with respect to FIG. 6.

[0103] The SwiftID in-app challenge authenticates the client by capturing an image of the client's phone during enrollment. The client swipes the phone screen upon receiving a push notification from the authentication server to confirm activity. SwiftID confirms authenticity by comparing the captured image of the phone with an image on file and validates the client based on image correlation. The SMS code exchange involves a unique code pushed to the client's pre-verified contact information and the client proving possession of the device by entering the code into the service provider app.

[0104] As described in Figure 6, the contactless card authentication method uses the above-mentioned NFC communication channel to exchange messages with the contactless card and cooperates with the contactless card to provide second factor authentication through a combination of a symmetric key, a symmetric encryption process, and a counter.

[0105] 11, exemplary steps that may be performed in one embodiment of a customer service authentication process 1100 employing aspects of the present invention will now be described. The customer service authentication process may be implemented as a software program running on a customer service agent's workstation that operates in response to input from the customer service agent to perform the steps of the process of FIG. 11. For purposes of the following description, operations described as being performed by a customer service agent are meant to include operations performed by both an operator of the software and the software itself.

[0106] In step 1122, customer service agent 1120 establishes a communications link with the client, for example, using the process described with respect to FIGS. 1-9, in which the client is preferably pre-authenticated prior to call processing.

[0107] At step 1123, customer service agent 1120 receives the access request from the client. At step 1124, the customer service agent determines whether the client is authorized for access. As previously discussed, it should be understood that there may be multiple levels of authorization associated with client data, such that low-risk data, services, or features may be more freely accessible than high-risk data, services, or features. Thus, while pre-authentication already performed may be sufficient for customer service call processing in some cases, additional authentication may be required in other cases. However, in some situations, such as a change of email address or phone number, such pre-authentication may be insufficient. According to one aspect, each attempted access is associated with an authorization level that must be met before access is granted.

[0108] In some embodiments, the authentication server may store, for each client, the client's approval level. In one embodiment, the approval level may be represented as a numerical scale, and the value may be stored for each client as part of the client data stored in database 130.

[0109] In step 1124, the customer service agent determines whether the client is approved for the requested access by comparing the authorization level of the access request with the authorization level of the requesting client. If the client is authorized, the process proceeds to step 1128, where access is granted. For example, in some embodiments, authorization for such access may make sensitive information visible to one or both of the customer service agent and the client. In other embodiments, authorization may unlock data fields, allowing them to be modified.

[0110] In step 1129, a notification is forwarded to the client. In one embodiment, the notification is forwarded to a pre-validated contact address of the client, such as an email sent to a pre-validated email address or a text message sent to a pre-validated phone number. Preferably, the communication channel used to forward the notification is different from the communication channel used by the client to request access to the information. For example, the client may request access using a web application, and the notification may be sent to an email address supported by a separate email application. Providing notification to the client using another communication channel helps reduce the opportunity for a malicious third party to impersonate the client and gain access. While notification step 1129 is shown to occur following access in step 1128, in various embodiments, such notification may occur before granting access, with a delay to allow for remediation if the client did not issue such a request.

[0111] If in step 1124 it is determined that the initial pre-authorization is insufficient for the requested access, in step 1125 the customer service agent requests additional authentication from the server and is processed in step 1126 to await the authentication result.

[0112] Once the authentication server receives the authentication request in step 1131, the authentication server pushes the authentication request to the client in step 1132. According to one aspect, a backchannel communication link may be established between the authentication server and the client device using a pre-verified communication channel. For example, the authentication server may store one or more pre-verified contact information for each client, including, but not limited to, a phone number, an Internet Mobile Equipment Identifier (IMEI), an Internet Protocol (IP) address, etc. A "push" request may be sent to the client using the pre-verified contact information. The "push" request includes a request for a particular form of authentication information (i.e., a SwiftID, an SMS code, a cryptogram, etc.). Pushing the authentication request to the client using a channel different from the channel through which the client seeks access reduces the opportunity for a fraudster to be granted access to sensitive information.

[0113] Alternatively, in some embodiments, in addition to pushing to pre-verified contacts, push messages and associated authentication responses may be exchanged between the client and authentication server using a session identifier associated with the client / customer service agent communication session. A session ID is a unique number that a website's server assigns to a client during the client's visit (session). Because it is a time-limited, unique value, it is often difficult for a hacker to successfully decrypt and infiltrate session communications. The session ID may be stored as a cookie, form field, or URL (uniform resource locator) on both the customer service agent and the client device. Because many servers use algorithms that involve more complex methods of generating session identifiers, using the session identifier to route communications adds an additional layer of security to client / customer service agent communications.

[0114] In step 1134, authentication server 1130 receives an authentication token (i.e., phone image, SMS code, cryptogram) used to authenticate the client device. Authentication server 1130 compares the token to an expected value retrieved from a data store and forwards one of the authentication or denial signals to a customer service agent.

[0115] If the customer service agent receives a denial signal in step 1126, the client is not authenticated and the process proceeds to step 1127, where the access request is denied. In such a case, the customer service agent may seek other means of authentication, terminate the call, or transfer the call for fraudulent handling. If the customer service agent receives an authentication signal in step 1126, the requested access is granted in step 1128, and email is forwarded in step 1129 to notify the client of the access request.

[0116] In some embodiments, implementation of the requested change may be delayed while awaiting a response to the email from the client. For example, the email message may include a request for affirmative indication from the client indicating that the access request has been approved. In some embodiments, the email request may require further authentication, such as a SwiftID, an SMS code, or a cryptogram exchange.

[0117] 12A and 12B illustrate exemplary graphic user interface (GUI) displays of a customer service agent (CSA) 1232 and a client 1234 that may communicate using the process described above with respect to FIG. 11. When the customer service agent receives a call for processing, a customer service screen 1220 may include various fields that display information about the client, such as a username 1222, a password 1224, and a social security number 1226. A client display 1250 may similarly include a subset of one or more information fields displayed to the customer service agent, including a username 1252, a password 1254, and a social security number 1256. According to one aspect, as noted above, certain information may not be displayed to one or both of the CSA 1232 and / or the client, depending on the entities' respective authorization levels. Thus, in FIG. 12A, the CSA 1232 is not authorized to display the client's password 1224 or social security number 1226. However, the client 1234 is authorized to view these fields. However, lock icon 1258 indicates that the client is not authorized to change the field without further authentication. The process of further authenticating the client using steps such as those in Figure 11 may be initiated in a variety of ways, such as by a customer service agent selecting an authenticate button 1260 on a display, or by one or both of CSA 1232 or client 1234 selecting one of the lock icons, such as lock icon 1258. Additionally, as noted above, if CSA 1232 is suspicious of the client's authenticity, at any point during call processing, the CSA may select authenticate button 1260 to begin the authentication process.

[0118] Thus, a system and method have been shown and described that reduces the opportunity for malicious access to client information during a customer service transaction by verifying the authenticity of the client using multiple different communication channels. Such authentication may be performed after or in lieu of pre-authentication.

[0119] Some embodiments may be described using the phrase "in one embodiment" or "embodiment," along with derivatives thereof. These terms mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification do not necessarily all refer to the same embodiment. Furthermore, unless otherwise specified, it is recognized that the above features can be used together in any combination. Thus, any features discussed separately can be used in combination with each other unless it is noted that the features are not compatible with each other.

[0120]

[0013] Generally, reference is made to the notation and nomenclature used herein, and the detailed descriptions herein may be presented in terms of functional blocks or units that can be implemented as program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

[0121] A procedure is herein, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is sometimes convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

[0122] Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein that form part of one or more embodiments. Rather, the operations are machine operations. Useful machines for performing the operations of the various embodiments include general purpose digital computers or similar devices.

[0123] Some embodiments may be described using the terms "coupled" and "connected," along with derivatives thereof. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and / or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but yet still cooperate or interact with each other.

[0124] Various embodiments also relate to apparatus or systems for performing these operations. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. The procedures presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for these various machines will be apparent from the description given.

[0125] It is emphasized that this Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the foregoing Detailed Description, various features are grouped together in a single embodiment to streamline the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in fewer than all features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "comprising" and "wherein" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Furthermore, the terms "first," "second," "third," etc. are used merely as labels and are not intended to impose numerical requirements on their subject matter.

[0126] What has been described above includes examples of the disclosed architecture. Of course, it is not possible to describe every conceivable combination of components and / or methodologies, but one of ordinary skill in the art will recognize that many more combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. 1. A device for authenticating information access requests, comprising: a customer service interface configured to receive an authentication request from a customer service agent, the authentication request associated with an access request received by the customer service agent from a client device via a first communication channel, the authentication request determining whether the device is authorized to access information sought by the access request; and a storage device configured to store client data comprising pre-verified contact information for said clients; a client interface configured to push a second factor authentication request to the client and receive an authentication response from the client via a second communication channel established using the pre-verified contact information, the second communication channel being different from the first communication channel; and an authentication server coupled to the customer service interface and the client interface for generating the second factor authentication request of a cryptogram from the client, the cryptogram being provided by the client's contactless card, and selectively unlocking access to information sought by the access request responsive to a match between the authentication response and the stored client data; Devices that include:

2. 10. The device of claim 1, wherein the authentication server is further configured to notify the client of the access request using a third communication channel generated in response to the pre-verified contact information of the client.

3. The device of claim 1 , wherein the second factor authentication request comprises one of a contactless card cryptogram request, a short message service (SMS) code request, and an in-application notification.

4. 4. The device of claim 3, wherein the authentication server further comprises a diversified key table stored in a storage device and having at least one of stored keys and stored counters for the clients.

5. 5. The device of claim 4, wherein the authentication server further comprises decryption logic for decrypting ciphertext received in response to the second factor authentication request using the stored key to obtain a decrypted counter, wherein the match is between the decrypted counter and the stored counter.

6. The device of claim 1 , wherein the pre-validated contact information includes at least one of an Internet Mobile Equipment Identifier (IMEI), a pre-validated device phone number, and an email address of the client.

7. The device of claim 6 , wherein the first communication channel comprises a session identifier.

8. The device of claim 7 , wherein the second communication channel is further established using the session identifier.

9. 10. The device of claim 8, wherein the client data comprises an authorization level of the client, and the authentication server selectively validates the client by comparing the authorization level of the client with an access level of the information.

10. 10. The device of claim 9, wherein the information is selected from a group including account information, passwords, addresses, and phone numbers, and the access request is selected from a group of requests including a read request and a change request.

11. 1. A method for authenticating an access request received by a customer service agent, comprising: receiving an authentication request from a customer service agent, the authentication request associated with an access request received by the customer service agent from a client device via a first communication channel, the authentication request determining whether the device is authorized to access information sought by the access request; retrieving client data from a data store, the client data including pre-verified contact information; pushing an authentication request to the device over a second communication channel using the pre-verified contact information, the authentication request comprising a request for second factor authentication from the client; and receiving a second factor authentication response from the device via the second communication channel, the second factor authentication response comprising a cryptogram received from the client's contactless card; comparing the second factor authentication response to the client data; selectively authenticating the client in response to the comparing step, including selectively unlocking access to the information sought by the access request; A method comprising the steps of:

12. 12. The method of claim 11, further comprising notifying the client of the access request using a third communication channel established in response to the pre-verified contact information.

13. The method of claim 12 , wherein the first communication channel comprises a session identifier.

14. 14. The method of claim 13, wherein the pre-validated contact information comprises at least one of an Internet Mobile Equipment Identifier (IMEI), a pre-validated client device phone number, and an email address of the client.

15. 15. The method of claim 14, wherein pushing an authentication request uses the session identifier in conjunction with the pre-verified contact information to form the second communication channel.

16. The method of claim 11 , wherein the authentication request comprises one of a contactless card cryptogram request, a short message service (SMS) code request, and an in-application notification.

17. The method comprises: storing a diversified key table in a data store, the diversified key table having at least one of a stored key and a stored counter for the client; in response to receiving a ciphertext as the second factor authentication response, decrypting the ciphertext using the stored key to generate a decrypted counter, and comparing the stored counter with the decrypted counter to selectively unlock access to the information sought by the access request; 17. The method of claim 16, further comprising:

18. The method of claim 11 , wherein selectively authenticating includes determining an access level for the information.

19. 20. The method of claim 18, wherein selectively authenticating comprises determining an authorization level of the client and comparing the authorization level of the client to an access level of the information.

20. 1. A method for authenticating an information access request received by a customer service agent, comprising: receiving an authentication request from a customer service agent, the authentication request associated with an access request received by the customer service agent via a first communication channel from a client device, the first communication channel including a session identifier, the authentication request determining whether the device is authorized to access information sought by the access request; Retrieving pre-validated client contact information for the client from a data store; Pushing an authentication request to the device using a second communication channel established using the pre-verified client contact information, the second communication channel being different from the first communication channel, and the authentication request including a request for a cryptogram from the client's contactless card; authenticating the access request receiving the cryptogram from the client device via the second communication channel, the cryptogram being received from a contactless card using the client device; and decrypting the ciphertext using a copy of a key associated with the client and providing decrypted counter information; comparing the decrypted counter information with a copy of a counter maintained for the client; selectively authenticating the client device in response to the comparing step, including selectively unlocking access to the information; notifying the client of the access request using a third communication channel generated in response to the pre-verified client contact information, the third communication channel being different from both the first and second communication channels; The method includes the steps of:

Images