System and method for second factor authentication of customer support calls

Abstract

To provide a system and method that 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 contactless card uniquely associated with a client may provide a second factor of authentication via a backchannel 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 service providers, without incurring further delay. During call handling, service providers may initiate further client authentication processes, including contactless card authentication requests, over one or more different communication channels for authorizing access to sensitive information or to allay suspicion.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] Related Applications This application claims priority to U.S. Patent Application No. 16 / 357,266, entitled "Systems and Methods for Second Factor Authentication of Customer Support Calls," filed on Mar. 18, 2019. The content of the foregoing application is hereby incorporated by reference in its entirety.

Background Art

[0002] Call center services are typically provided by service providers to enable customers to access, modify, delete, or otherwise control their accounts. From a security perspective, call center transactions can be the most risky area for a company because they can expose sensitive customer information to malicious third parties. Up to 90% of the calls received on a given day at a customer call center are from unauthorized callers attempting 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 implementing compliance with the PCI standards to protect sensitive customer data. For example, the PCI standards may dictate authentication standards that should be followed before a client is permitted to access and / or modify customer account information. At a call center, client authentication may be required in the form of password exchanges, answers to personal questions, biometric data, etc. However, authentication technologies are often affected by problems such as "spoofing" or "phishing," where fraudsters mask or change the caller ID number, email address, IP address, etc. in an attempt to pose as a client to steal information or funds. External risks are also caused by hackers who monitor service provider communications, particularly call center communications, for the purpose of stealing customer information.

Summary of the Invention

[0004] According to one aspect, a device for authenticating an information access request includes a customer service interface configured to receive an authentication request from a customer service agent, the authentication request being associated with an 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 requested by the access request. The device further includes a storage device configured to store client data comprising pre-verified contact information of 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 unlocks access to the information requested 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 including steps associated with an 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 can access the information requested by the access request. The method includes obtaining client data including pre-verified contact information of the client from a data store, and pushing the authentication request to the device via a second communication channel using the pre-verified contact information. The authentication request can include a request for a 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 with the client data, and selectively authenticating the client according to the comparison steps including selectively unlocking access to the information requested by the access request.

[0006] According to a further aspect, a method for authenticating an information access request received by a customer service agent comprises receiving an authentication request from the customer service agent, the authentication request being associated with an 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 requested by the client access request. The method may include obtaining pre-verified client contact information of 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 ciphertext from the client's contactless card, and the method of authenticating the access request includes receiving the ciphertext from the client device via the second communication channel, decrypting the ciphertext using a copy of the key associated with the client, providing the 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 comparison 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 different communication channels to exchange authentication information before permitting access to customer data reduces the likelihood of disclosure of confidential customer information because malicious parties cannot disrupt all client communication interfaces.

Brief Description of the Drawings

[0008]

Fig. 1A

Fig. 1B

Fig. 2

Fig. 3

Fig. 4

Fig. 5

Fig. 6

Fig. 7

Fig. 8

Fig. 9

Fig. 10

Fig. 11

Fig. 12A

Fig. 12B

DETAILED DESCRIPTION OF THE INVENTION

[0009] The object of some embodiments of the present disclosure is the use of one or more keys incorporated in one or more contactless cards, as described in U.S. Patent Application No. 16 / 205,119, filed on November 29, 2018, by Ozborne et al. and titled "Systems and Methods for Encrypted Authentication of Contactless Cards," which is incorporated herein by reference (hereinafter referred to as the '119 application). Contactless cards can be used for authentication and many other functions where the user needs to carry another physical token in addition to the contactless card. By adopting a contactless interface, a contactless card can be provided with a way to interact and communicate between the 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 (registered trademark) operating system but has issues with the iOS (registered trademark) operating system, which is more restricted regarding the use of near-field communication (NFC) as it is only used in read-only mode and includes an authentication process. It is different from RFID, which can be used to read devices operating at a relatively long distance. The exemplary embodiments of the contactless card described in the '119 application may utilize NFC technology.

[0010] Accordingly, a system and method are disclosed for improving the security and efficiency of a customer call center by leveraging a service provider's multi-factor authentication capabilities and intelligent call routing. Pre-authentication of customer support requests reduces the likelihood of confidential customer data being exploited during a call. A contactless card uniquely associated with a client can provide a second factor of authentication, reducing the possibility of malicious impersonation by third parties. Pre-approved customer support calls are routed intelligently and efficiently in a way that reduces the opportunity for malicious call interference and information theft.

[0011] In other aspects, it has been 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 additional authentication can be performed for various reasons, including before allowing changes to highly sensitive data, such as passwords and contact information, or before granting access to specific services, such as loan services. Additional authentication may also be required when a customer is transferred between customer service agents or when a customer service agent doubts the reliability of a client seeking access to client information.

[0012] In one aspect, authentication can be performed using communication channels and protocols other than those used to request information access. In some embodiments, the communication channel is established using contact information of a client pre-verified by the service provider. In some embodiments, after access is granted, other communication methods, such as email or text messaging, can be used to notify the client of such access. Using different communication channels and protocols at various stages of authentication limits the possibility of malicious third-party interference because it becomes difficult for a malicious third party to interfere simultaneously with each communication medium used for authentication.

[0013] These and other features of the present invention will be described with reference to the figures, where like reference numerals are used throughout to refer to like elements.

[0014] As used in this application, the terms "system," "component," and "unit" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are described herein. For example, a component can be a process running on a processor, a processor, a hard disk drive, a plurality of storage drives (of optical and / or magnetic storage media), an object, an executable, a thread of execution, a program, and / or a computer, but is not limited to these. By way of illustration, both an application running on a server and the server can be components. One or more components can be located within a process and / or thread of execution, and a component can be localized on one computer and / or distributed between two or more computers.

[0015] Furthermore, components can be communicatively coupled to each other by various types of communication media for purposes of coordinating operations. The coordination can include one-way or two-way information exchange. For example, components can communicate information in the form of signals communicated through the communication media. This information can be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, in further embodiments, alternatively, data messages can be used. Such data messages can be transmitted through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0016] FIG. 1A shows a system 100 including one or more client devices 110 coupled to a service provider 120 via a network 115. According to one aspect, the client device 110 comprises a network-enabled computer and communicates with the service provider 120 via networks 115 and 125 to access the content and services of the service provider.

[0017] As referred to herein, a network-enabled computer can include, but is not limited to, for example, a computer device, or a 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 devices.

[0018] Accordingly, client device 110 may include a processor and memory, and the processing circuitry may include additional components including a processor, memory, error and parity / CRC checker, data encoder, collision avoidance algorithm, controller, command decoder, security primitive, and anti-tampering hardware, as necessary to perform the functions described herein. Client device 110 may further include a display and an input device. The display may be any type of device for presenting visual information, such as a computer monitor, flat panel display, and mobile device screen including a liquid crystal display, light emitting diode display, plasma panel, and cathode ray tube display. The input device may include any device for inputting information available and supported by the user's device into the user's device, such as a touch screen, keyboard, mouse, cursor control device, touch screen, 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] One or more client devices 110 may also be mobile devices such as, for example, Apple's iPhone (registered trademark), iPod (registered trademark), iPad (registered trademark), or other mobile devices running Apple's iOS (registered trademark) operating system, any device running Microsoft's Windows (registered trademark) mobile operating system, and / or other smartphones or similar wearable mobile devices.

[0020] The various client devices 110 of FIG. 1A include a mobile phone 142, a laptop 144, a tablet 148, and a terminal 146. The client devices 110 may include a sink client application that is particularly adapted for communication with a service provider 120. The sink client application is stored in the memory of the client device and is operable when executed by the client device, and may control the interface between the client device and the service provider application, enabling a user of the client device to access service provider content and services.

[0021] In some examples, the network 115 can be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and can be configured to connect the client devices 110 to the service provider 120. For example, the network 115 can include one or more of a fiber optic network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a 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 multiplexing-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] Furthermore, network 115 may include, but is not limited to, a telephone line, optical fiber, IEEE Ethernet 902.3, wide area network ("WAN"), wireless personal area network ("WPAN"), local area network ("LAN"), or a global network such as the Internet. Additionally, network 115 may support an Internet network, a wireless communication network, a cellular network, etc., or any combination thereof. Network 115 may further include one network, or any number of the exemplary types of networks described above, operating as a stand-alone network or cooperating with each other. Network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 may convert one or more protocols of network devices to other protocols.

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

[0024] In one embodiment, service provider 120 is a business that provides computer-based services to clients via network 115. Almost all modern service providers use the Internet to provide services to potential consumers. The provision of services is typically 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 a client is referred to herein as a "server". A server can communicate via a private network 125 of the service provider, often referred to as a corporate or enterprise network. The private network 125 can 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 as including an application server 150, an authentication server 160, and a customer relationship management (CRM) server 140. Each server is shown as an individual device, but it should be understood that the applications and servers can be distributed across the enterprise and, in the case of distributed resources such as "cloud" resources, across the entire network 115. The application server 150 can support one or more application services provided by service provider 120, such as, for example, account management services. The CRM server 140 can be used to provide customer support services to clients of service provider 120, including handling and forwarding incoming calls from clients to one or more call handling agents operating at workstations 132, 135.

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

[0027] According to one aspect, contactless card 105 may communicate wirelessly with one or more client devices 110, for example, via near-field communication (NFC). For example, contactless card 105 may include one or more chips, such as radio frequency identification chips, 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 application 119, contactless card 105 may be configured to communicate via NFC with one of card reader terminal 146, mobile phone 142, laptop 144, and / or tablet 148 when contactless card 105 is within the range of each client device. As will be described in more detail below, contactless card 105 may include a key and counter information that can be transformed using an encryption algorithm to generate a ciphertext that can be used by a service provider to authenticate a client device.

[0028] FIG. 1B is a timing diagram showing an exemplary 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 refer to components similar to those shown in FIG. 1A.

[0029] In step 102, application 122 communicates with contactless card 105 (for example, after being brought close to contactless card 105). The communication between application 122 and contactless card 105 may include a contactless card 105 that is close enough 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 client device 110 and contactless card 105, contactless card 105 generates a message authentication code (MAC) ciphertext. In some examples, this may occur when contactless card 105 is read by application 122. In particular, this may occur during reading, such as the NFC reading of a Near Field Communication Data Exchange (NDEF) tag that may be created according to the NFC data exchange format. For example, a reader such as application 122 may send a message such as an applet selection message using the applet ID of the NDEF generation applet. When the selection is confirmed, a sequence of selection file messages followed by read file messages may be sent. For example, the sequence may include "selection of function file", "reading of function file", and "selection of NDEF file". At this point, the counter value maintained by contactless card 105 may be updated or incremented, and then "reading of NDEF file" may follow. At this point, a message that may include a header and a shared secret may be generated. Next, a session key may be generated. The MAC ciphertext may be created from the message, which may include a header and a shared secret. Next, the MAC ciphertext may be concatenated with one or more blocks of random data, and the MAC ciphertext and random number (RND) may be encrypted with the session key. Thereafter, the ciphertext and the header may be concatenated, encoded as ASCII hexadecimal, and returned in the NDEF message format (in response to the "reading of NDEF file" message).

[0031] In some examples, the MAC ciphertext may be transmitted as an NDEF tag, and in other examples, the MAC ciphertext may be included with a uniform resource indicator (e.g., 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 for generating a MAC ciphertext.

[0033] In step 106, the contactless card 105 sends the MAC ciphertext to the application 122. In some examples, the MAC ciphertext is sent via NFC, but the present disclosure is not limited thereto. In other examples, this communication may be performed 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, the processor 124 verifies the MAC ciphertext according to instructions from the application 122. For example, as described below, the MAC ciphertext may be verified.

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

[0037] In some examples, the MAC ciphertext may function as a digital signature for verification purposes. To perform this verification, 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, may be used.

[0038] More specifically, according to one aspect, the contactless card 105 can be used in conjunction with first authentication credentials provided to an application service provider for pre-authenticating customer support requests before forwarding the support request to the CRM server 140. There are two advantages to pre-authenticating customer support requests in this way. Since the authentication information is not transferred to the CRM, the opportunity for abuse of such information by call center agents is avoided. Further, using the 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 removing the ability for malicious third parties to "impersonate" the client, i.e., spoof. 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] Exemplary embodiments of the systems and methods described herein can be configured to provide multi-factor security authentication that can be used to bypass authentication by the CRM server 40, thereby reducing the potential for theft of confidential customer information during call processing.

[0040] Security element authentication may comprise multiple processes. The first authentication process may comprise logging in and verifying the user via one or more applications running on the device. The second authentication process may operate after the login and verification are successful and cause the user to perform one or more actions associated with one or more contactless cards. In effect, the security element authentication process may comprise a multi-factor authentication process that includes both securely proving the identity of the user and causing the user to 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 tapping a contactless card against the device by the user. 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, the client may access the service provider's website by linking to the service provider's web page using an Internet browser application running on the client device. The browser is a software application such as Google® Chrome®, Internet Explorer®, Safari®, and includes programming code for converting the hypertext markup language (HTML) web page of the service provider application 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 approval information including password information, answers to pre-stored queries, biometric information, images, or other mechanisms for verifying that the user of the client device is authorized to access the content and services including the account managed by the service provider.

[0042] Certain high-risk services provided 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 within the client's browser to speed up the authentication process during the client's login. Browser cookies, along with related passwords and other data, are vulnerable to discovery and misuse. Therefore, it is important to verify that the user has access rights before allowing the user to access or modify highly confidential or personal information, as may occur during a call to customer support.

[0043] According to one aspect, the contactless card 105 can be used to provide a second authentication to the user of the client device. In one embodiment, as described in more detail below, the contactless card can include a key, a counter, and an encryption processing function that can be used to generate an encrypted text that can be used to verify the user of the client device. The counter advantageously reflects the previous actions of the card owner. For example, the counter can reflect the number of times the user has previously accessed a particular service of the service provider. This information is virtually impossible for a malicious third party to accurately collect.

[0044] According to one aspect, and as described in more detail below, ciphertext exchange occurs using backchannel communication. For the 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 can be authenticated using a backchannel call, text, or email issued directly to the pre-verified client contact. In other embodiments, the communication channel may utilize information (such as session information) from the application communication channel when establishing the backchannel communication link.

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

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

[0047] In the above description, the first authentication has been described as using personal, biometric, question, or other authentication information. However, in some examples, it is recognized that a client application running on a device can first activate or launch the device's application in response to a tap of a contactless card. In such examples, in both the first authentication process and the second authentication process, the key / counter contactless card authentication process described in detail below is used. In some embodiments, if the client-side application is not installed on the client device, a tap of a contactless card in proximity to the card reader can initiate a download of the application (such as navigation to the application download page). Following the installation, tapping the contactless card activates or launches the application, and then, for example, activation of the contactless card can be initiated via the application or other backend communication. In some examples, one or more applications can be configured to determine that they were launched via one or more tap gestures of a contactless card, such as having been launched at 3:51 PM, a transaction having been processed at 3:56 PM, or having occurred, in order to verify the identity of the user.

[0048] In some examples, data can be collected about the tap behavior as biometric / gesture authentication. For example, a unique identifier that is cryptographically secure and difficult to eavesdrop on can be sent to one or more backend services. The unique identifier can be configured to search for secondary information about the individual. The secondary information can comprise information that can identify the individual user, including but not limited to social security information, query responses, passwords, account information, etc. In some examples, the secondary information can be stored within the contactless card.

[0049] FIG. 2 shows one or more contactless cards 200, which may include 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 include, but is not limited to, an identification card that has no relation to a payment card. In some examples, the payment card may include a dual interface contactless payment card. The contactless card 200 may include a substrate 210 that 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 acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 300 may have physical characteristics that conform 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 the contactless card 200 according to the present disclosure may have different characteristics, and the present disclosure does not require that the contactless card be implemented as a payment card.

[0050] The contactless card 200 may also include identification information 215 displayed on the front and / or back of the card, and contact pads 220. The contact pads 220 may be configured to establish contact with other communication devices such as user devices, smartphones, laptops, desktops, or tablet computers. The contactless card 200 may also include a processing circuit, an antenna, and other components not shown in FIG. 2. These components may be located behind the contact pads 220 or at other locations on the substrate 210. The contactless card 200 may also include a magnetic strip or tape that may be disposed on the back of the card (not shown in FIG. 2).

[0051] As shown in FIG. 3, the contact pad 320 of FIG. 3A may include a processing circuit 325 for storing and processing information, including a microprocessor 330 and a memory 335. The processing circuit 325 may include additional components such as a processor, a memory, an error and parity / CRC checker, a data encoder, a collision prevention algorithm, a controller, a command decoder, a security primitive, and anti-tampering hardware as necessary to perform the functions described herein.

[0052] The memory 335 can be a read-only memory, a write-once read-multiple memory, or a read / write memory, such as RAM, ROM, and EEPROM, and the contactless card 300 can include one or more of these memories. The read-only memory can be programmable as read-only at factory shipment or programmable once. With the one-time programmability, it can be read multiple times after being written once. The write-once / read-multiple memory can be programmed at some point after the memory chip is shipped from the factory. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. The read / write memory can be programmed and reprogrammed multiple times after factory shipment and can be read multiple times.

[0053] 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 execute on one or more contactless cards such as Java Card applets. However, it is understood that the applet 340 is not limited to Java Card applets and may instead be any software application operable on a contactless card or other device having limited memory. The one or more counters 345 may comprise numeric counters sufficient to store integers. The customer identifier 350 may comprise a unique alphanumeric identifier assigned to a user of the contactless card 300, and the identifier may distinguish the user of the contactless card from users of other contactless cards. In some examples, the customer identifier 350 may identify both the customer and the account assigned to that 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 have been described with reference to the contact pads, the present disclosure is not so limited. These elements may be implemented outside the pads 320, may be completely separated 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 comprise one or more antennas 355. The one or more antennas 355 may be disposed within the contactless card 300 and around the processing circuitry 325 of the contact pads 320. For example, the one or more antennas 355 may be integral with the processing circuitry 325, and 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 pads 320 and the processing circuitry 325.

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

[0057] As described above, the contactless card 300 can be built on a software platform operable on other devices with limited memory, such as smart cards or Java cards, and one or more applications or applets can be securely executed. The applet can 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 can 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 with a cryptographically secure OTP encoded as an NDEF text tag.

[0058] Figure 4 shows an exemplary NDEF short record layout (SR = 1) 400 according to an exemplary embodiment. The NDEF message provides a standardized way for the client device 110 to communicate with the contactless card 105. In some examples, the NDEF message may comprise one or more records. The NDEF record 400 includes a header 402 that includes a plurality of 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. The MB 403a and ME flags 403b may be set to indicate the first and last records of the message, respectively. The CF 403c and IL flags 403e provide information about the record, including whether the data is "chunked" (data distributed across multiple records in the message) or whether the ID type length field 408 is relevant, respectively. The SR flag 403d may be set if the message contains only one record.

[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 identifiers (URI) [defined in RFC3986], external (user-defined), unknown, unchanged [for chunks], reserved.

[0060] Other fields of the NFC record include type length 404, payload length 406, ID length 408, type 410, ID 412, and payload 414. The length of the payload type is included in bytes. The type length field 404 specifies the exact type of data detected in the payload. The payload length 406 includes the length of the payload in bytes. The record can contain up to 4,294,967,295 bytes (or 2^32 - 1 bytes) of data. The ID length 408 includes the length of the ID field in bytes. The type 410 identifies the type of data contained in the payload. The ID 412 provides a means for an external application to identify the entire payload being transmitted within the NDEF record. The payload 414 comprises the message.

[0061] In some examples, by performing STOREDATA (E2) under a secure channel protocol, data can first be stored on the contactless card. This data can include, in addition to a unique personal user ID (pUID) for the card, one or more initial keys, encrypted processing data including session keys, data encryption keys, random numbers, and other values described in detail below. These values can be used to generate a message authentication code (MAC) that can be used to pre-authenticate the client before processing customer services.

[0062] Exemplary information that can be exchanged between the contactless card 105 and the authentication server 160 during initialization for 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 for uniquely identifying the card owner. These functions can be used according to one aspect for authenticating client access to high-risk services as described below.

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

[0066] The client device 520 also includes a card interface 525 for communicating with the contactless card, and one or more other network interfaces (not shown) that enable the client device 520 to communicate with the service provider using various communication protocols as described above. The client device may further include a user interface 526 that can include one or more of a keyboard or a touch screen display to enable communication between the service provider application and the user of the client device 520. The client device 520 further includes a memory 522 that stores information and program code for controlling the operation of the client device 520, such as, for example, a client-side application 523, which can be provided to the client by the service provider to facilitate access to and use of the service provider's applications. 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 provided by the service provider. The client-side application 523 can be controlled via input received at a service provider (SP) application interface 527 displayed on the user interface 526. For example, the user can 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, the client device 520 can be connected to various services provided by a service provider 505, including a customer relationship management (CRM) server 540 and an authentication server 550. In one embodiment, the CRM server 540 manages the routing of received support calls and the transfer of received calls to a call processing pipeline 542. The authentication server 550 includes a client information table 552 for storing information such as that shown in Table 1 for a client of the service provider. The authentication server 554 includes hardware and software for performing various authentication processes on a client using information from a client counter value table 556. In one embodiment, the authentication server further includes a client interface 557 for exchanging authentication messages with the client device and a customer service interface 553 for exchanging authentication messages with the CRM server 540. The authentication server may also include a client counter value table 556 that can be used as described below to perform authentication in combination with the contactless card 510.

[0068] FIG. 6 shows various steps that can be performed by an authentication service of a contactless card 601, a client device 611, and a service provider 621 configured to use a key diversification technique as part of a multi-factor authentication protocol for pre-authenticating a client. For example, the card owner of the contactless card 601 accessible to the client device 611 may request authentication from the service provider 621 to enable access to a service, including requesting multi-factor authentication for access to a high-risk service such as call center support.

[0069] In step 610, the client device 611 first accesses the client account maintained by the service provider 621 by exchanging login credential information with the service provider. The login credential information may include, but is not limited to, passwords, keys, biometric data, image data, queries. In one embodiment, the client may initiate this access by launching a client-side application via the SP application interface 527. The launch of the application may include the display of a web page of the service provider configured to receive first credential information from the user.

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

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

[0072] In step 614, the client device requests access to a high-risk application, such as a customer service application. The client may request access, for example, by selecting one of a plurality of hyperlinks provided on the service provider's website to direct the client to the selected service. The hyperlink may include, for example, the web address of the landing page of the service. Alternatively, the hyperlink may include the phone number of the 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 an embodiment that provides second factor authentication using a contactless card, the service provider may prompt the client device to use the contactless card to obtain a ciphertext for verification purposes. The prompt may be any means of indicating to the client that it is necessary to use the contactless card, including text prompts, visual prompts, audible prompts, and other available display mechanisms.

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

[0075] In step 602, the contactless card receives an authentication request. In step 604, the processing component within the contactless card increments the Application Service Transaction (AST) counter, encrypts the counter using the master key stored in the contactless card with a symmetric encryption algorithm, and generates a diversified key. The encryption algorithm can 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 can include any symmetric encryption algorithm used as needed to generate a diversified symmetric key of a desired length. Non-limiting examples of symmetric algorithms 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 is understood that if the output of the selected symmetric algorithm does not generate a key of sufficient length, multiple outputs of sufficient length can be generated as needed by techniques such as processing multiple iterations of the symmetric algorithm with the same master key and different input data and combining them.

[0076] The processing component of the contactless card can use the selected encryption algorithm and the master symmetric key to process the counter value. For example, the contactless card 601 can select a symmetric encryption algorithm and use a counter that increments for each authentication transaction processed by the contactless card. Next, the contactless card 601 can 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, diversified symmetric keys can be used to process a counter before transmitting it for authentication purposes. For example, the contactless card 601 can encrypt the counter value using a symmetric encryption algorithm and diversified symmetric keys, and the output comprises an encrypted MAC ciphertext. Next, the contactless card 601 can send 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 can be sent between the transmitting device 205 and the receiving device 210 in block 230 without encryption.

[0078] In one embodiment, a template of an authentication message comprising a ciphertext may comprise a first record with a well-known index for providing 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, when additional tags are added, the first byte is changed to indicate the start of the message but does not indicate the end, and subsequent records can be added. Since the ID length is zero, the ID length field and the ID are omitted from the record. The example message shown in Table 3 below may include the UDKAUT key; a derived AUT session key (using 0x1234); version 1.0; pATC = 0x1234; RND = 76a6627b67a8cfbb; MAC = <calculated 8 bytes>. The first column may comprise an address / index to the NDEF message data.

[0081] [Table 3]

[0082] In step 618, the client device 611 receives the ciphertext and transfers it to the service provider 621. In step 626, after the service provider requests second-factor authentication in step 624, in one embodiment, the authentication server of the service provider 621 uses the client device to obtain client information associated with the card owner of the contactless card associated with the client's account. The client information may include the client's master key and the counter of the application service transaction of the contactless card. The service provider 621 uses an encryption algorithm that matches the encryption algorithm used by the contactless card with the master key to encrypt the obtained counter value to generate a service provider copy of the diversified key.

[0083] In step 628, the service provider decrypts the ciphertext using the diversified key and publishes the counter value transferred by the contactless card. In step 629, the service provider compares the published counter with the counter obtained by the service provider, which provides the user's second authentication. If there is no match, the client is not permitted 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 starts a call process with the CRM server in 630. In one aspect, as described with respect to FIGS. 7 and 8, service provision may generate one or more messages for controlling one of the CRM or the client device in order to utilize pre-authentication already performed by the service provider.

[0084] Next, when the contactless card is used for authentication, different counter values can be selected to generate different diversified symmetric keys, making it difficult for malicious parties monitoring the communication to decrypt the communication. Both the service provider and the contactless card increment the counter according to a pre-determined increment pattern agreed upon between the parties. For example, the counter can be incremented by 1 each time, or in a pattern, e.g., by 1 for the first transaction, by 2 for the second, by 3 for the third, or by 5 for each transaction. Since 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 keys are changed for each transaction, but both the sending device and the receiving device have the same key.

[0085] As described above, in some examples, the key diversification value can be achieved using the 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 the counter values transmitted from the sending and receiving devices; a portion of the counter values transmitted from the sending and receiving devices; a counter maintained independently by the sending and receiving devices but not transmitted between the two; a one-time passcode exchanged between the sending and receiving devices; and the encrypted hash of the counter. In some examples described in the '119 application, one or more portions of the key diversification value can be used by the parties to create multiple diversified keys. For example, the counter can be used as the key diversification value.

[0086] In other examples, some of the counters can be used as key diversification values. When multiple master key values are shared among parties, multiple diversified key values can be obtained by the systems and processes described herein. New diversification values, and thus new diversified symmetric keys, can be created as many times as needed. In the most secure case, a new diversification value can be created each time confidential data is exchanged between a sending device and a receiving device. In practice, this can create a one-time use key such as a single session key.

[0087] Various other symmetric encryption / decryption techniques that may be used instead of those described with respect to FIG. 6 are described in the 119 application, which is incorporated herein by reference.

[0088] FIGS. 7 and 8 each show an example of a transaction flow that may be performed following the pre-authentication of a client seeking access to a call center service. In one embodiment, customer information stored on a contactless card may include call center information unique 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, a telephone number, or other contact address or random number. FIG. 7 shows exemplary messaging that may occur between components of a call routing process 700 that defines a communication link between a client device 702 and a customer service agent 705 using call center information from a contactless card 701.

[0089] Following the multi-factor pre-authentication process shown in FIG. 6, the authentication server 703 of the service provider inputs customer service web content 710 into the client interface. The web content may include contact information, a URL for communicating with the CRM server, a phone number, or other contact addresses. When a link is selected, a communication link is generated between the client device and the CRM server. According to one embodiment, the customer service web content includes a prompt 711 that requests a connection with the contactless card 701.

[0090] Upon receiving the prompt, the contactless card 701 transfers 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. When the communication link is generated, at least a portion of the pre-authentication number may be added to the contact information. For example, the web content 710 may include a link to the customer service phone number 1-800-123-4567. The contactless card may provide a pre-authentication number of 7777 for the client device to add to the phone number. The client device initiates a call 715 to -800-123-4567,,,,7777 via the cellular network. The application server alerts the CRM of an incoming call with the number from the contactless card 714 added. The CRM monitors incoming calls with the pre-authentication number and bypasses authentication when initiating a call in the customer service agent pipeline 716.

[0091] The process of FIG. 7 includes a pre - authentication number stored on the contactless card. However, in some embodiments, the client device may be configured to generate a pre - authentication number for addition to the call. The pre - authentication number can be generated, for example, in response to communication with the contactless card following a ciphertext exchange with the contactless card, as described in FIG. 6. In some embodiments, the pre - authentication number can be changed for each customer support request. Such a measure protects customer support calls from redirection by malicious parties because fake client devices do not have the pre - authentication number and authentication is not bypassed at the CRM server.

[0092] In other embodiments, as shown in FIG. 8, to further protect call processing from malicious interference, the 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 prompt re - authentication of the client device. The contactless card 812 generates a ciphertext as described above, which is transferred via the client device 702 to the authentication server 703 for verification. When the authentication server verifies the ciphertext, at step 814, the authentication server instructs the CRM server to bypass call approval. At step 815, the call bypasses approval and is placed in the call agent queue, and at step 816, the CRM initiates a back - channel call. Here, the back - channel call is a call initiated via a communication link directly established between a server (e.g., the CRM server) and the phone number, IP address, etc. of the client device.

[0093] In some embodiments, the re - authentication step can occur following the initiation of a call at step 816 by customer service agent 705, ensuring that the call is not redirected between the previous authentication and call processing. The ways in which a customer service agent can be used to re - authenticate or further authorize client access will be described in detail below. Such embodiments can 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] FIG. 9 shows some exemplary components of one embodiment of a CRM service 900. The CRM service 900 is shown to include authentication logic 906 and agent assignment unit 910. An incoming call 901 is transferred to a pre - authentication filter 902. The pre - authentication filter 902 can store the pre - authentication number received from the authentication server as described above. Incoming calls that are not pre - authenticated are transferred to an authentication queue 904. The authentication logic retrieves the incoming call from the authentication queue 904 and, in cooperation with an authentication server (not shown), verifies the client using any combination of the authentication methods described above. Once authenticated, the call is transferred to queue 908.

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

[0096] Thus, queue 908 stores authenticated calls that are assigned to agents 920, 922, 924 by the agent assignment unit 910 for processing according to the resource load. With such a configuration, pre - authenticated calls can be intelligently routed to the customer call center and processing delays can be minimized.

[0097] Accordingly, systems and methods have been described that utilize a service provider's multi-factor authentication capabilities and intelligent call routing to improve security and efficiency in a customer call center. According to other aspects, it will be appreciated that the advantages of the authentication process described above may be further utilized by a customer service agent during a call. For example, a customer service agent may request an increased level of authentication in order to more finely control access to client information or to verify the ongoing reliability of a client. The multi-factor authentication process of FIG. 6 is described as being useful for authenticating a client before granting access to high-risk services, but it should be understood that within high-risk services there are data and actions that are likely to endanger a client account and thus access should be restricted.

[0098] For example, the risk of disclosing a personal account password is higher than the risk of disclosing the balance of the personal account. Further, since these communication means are typically used during a normal password change, there is a significant risk in allowing an individual to change their phone number or email, and if a malicious user changes this data, access to the account by the appropriate client may be lost.

[0099] Briefly referring to FIG. 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 a plurality of customer service agents (CSAs) 1032, 1034 that access client data 1040 using a data server 1036. Client data 1040 is conceptually distributed in a hierarchical data structure that includes highly confidential data 1042, moderately confidential data 1044, and lowly confidential data 1046. Thus, each layer is associated with a different level of data confidentiality and a different degree of associated access control. In some embodiments, certain confidential data may be made unavailable to unauthorized parties, as indicated by shaded data items such as data item 1045.

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

[0101] The generated additional factor authentication request may take many forms that desirably verify both that the device that initiated the access request is associated with the client and that the client (or someone approved by the client) physically owns it. For example, a "push" message may be issued by the authentication server to the client device, and the push message may include a prompt that requests authentication data that is personal to the approved device or personal to the approved client.

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

[0103] The in - app challenge in the SwiftID application authenticates the client by capturing an image of the client's phone at the time of registration. When the client receives a push notification from the authentication server, the client swipes the phone screen to confirm the activity. SwiftID checks the reliability by comparing the captured image of the phone with the image registered in the file and verifies the client based on the correlation of the images. The SMS code exchange includes a unique code pushed to the client's pre - verified contact information and the client who proves device ownership by entering the code into the service provider app.

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

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

[0106] In step 1122, the customer service agent 1120 establishes a communication link with the client, for example, preferably using the processes described with respect to FIGS. 1 - 9 where the client is pre - authenticated prior to the call handling.

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

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

[0109] In step 1124, the customer service agent determines whether the client is authorized for the requested access by comparing the authorization level of the client requesting the access level of the access request. If the client is authorized, the process proceeds to step 1128, where the access is permitted. For example, in some embodiments, authorization for such access may visualize confidential information to one or both of the customer service agent and the client. In other embodiments, authorization may unlock data fields and allow changes.

[0110] In step 1129, the notification is transferred to the client. In one embodiment, the notification is transferred to a pre-verified contact address of the client, e.g., an email sent to a pre-verified email address or a text message sent to a pre-verified phone number. Preferably, the communication channel used to transfer the notification is different from the communication channel used by the client to request access to the information. For example, if the client uses a web application to request access, the notification can be sent to an email address supported by a separate email application. Using a different communication channel to provide the notification to the client helps reduce the chance of a malicious third party impersonating the client to gain access. Although the notification step 1129 is shown to occur following the access in step 1128, in various embodiments, such a notification can occur before access is granted and involves a delay to enable recovery in case the client did not issue such a request.

[0111] In step 1124, if it is determined that the initial pre-approval 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 wait for the authentication result.

[0112] In step 1131, when the authentication server receives an authentication request, in step 1132, the authentication server pushes the authentication request to the client. According to one aspect, the backchannel communication link can 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 device identifier (IMEI), an Internet Protocol (IP) address, etc. The "push" request can be sent to the client using the pre-verified contact information. The "push" request includes a request for a specific form of authentication information (i.e., SwiftID, SMS code, ciphertext, etc.). By pushing the authentication request to the client using a channel different from the channel the client is seeking access to, the opportunity for fraudsters to be granted access to confidential information is reduced.

[0113] In addition to pushing to pre-verified contacts, or in some embodiments, the push message and related authentication responses can be exchanged between the client and the authentication server using a session identifier associated with the client / customer service agent communication session. The session ID is a unique number assigned by the server of a website to the client during the client's visit (session). Since this is a time-limited unique value, it is often difficult for hackers to successfully decrypt the session communication and intrude. The session ID can be stored as a cookie, a form field, or a URL (Uniform Resource Locator) on both the customer service agent and the client device. Since many servers use algorithms including more complex ways to generate session identifiers, using the session identifier to transfer communication adds an additional layer of security to the client / customer service agent communication.

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

[0115] In step 1126, if the customer service agent receives a rejection signal, the client is not authenticated and the process proceeds to step 1127 where the access request is rejected. In such a case, the customer service agent may search for other authentication means, end the call, or transfer the call for improper handling. In step 1126, if the customer service agent receives an authentication signal, the requested access is permitted in step 1128 and a mail is transferred in step 1129 to notify the client of the access request.

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

[0117] Figures 12A and 12B show exemplary graphic user interface (GUI) displays of a customer service agent (CSA) 1232 and a client 1234 that can communicate using the above process with respect to FIG. 11. When the customer service agent receives a call for processing, the 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. The 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 described above, certain information may not be displayed to one or both of the CSA 1232 and / or the client depending on the approval level of each entity. Thus, in FIG. 12A, the CSA 1232 is not approved to display the client's password 1224 or social security number 1226. However, the client 1234 is approved to display these fields. However, the lock icon 1258 indicates that the client is not approved to change the fields without further authentication. The process of further authenticating the client using steps such as those in FIG. 11 may be initiated in various ways, such as by the customer service agent selecting an authentication button 1260 on the display, or by one or both of the CSA 1232 or the client 1234 selecting one of the lock icons, such as the lock icon 1258. Further, as described above, if the CSA 1232 suspects the reliability of the client, at any point during the call processing, the CSA may select the authentication button 1260 to initiate the authentication process.

[0118] Accordingly, systems and methods have been shown and described that reduce the opportunity for malicious access to client information during customer service transactions by verifying the reliability of a client using a plurality of different communication channels. Such authentication can be performed after, or instead of, pre-authentication.

[0119] Some embodiments may be described using the expressions "one embodiment" or "an embodiment" along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification are not necessarily all referring to the same embodiment. Further, unless otherwise noted, 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] Referring generally to the notation and nomenclature used herein, the detailed description herein may be presented with respect to functional blocks or units that can be implemented as program steps executed on a computer or a network of computers. The description and representation of these steps are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art.

[0121] The steps are here, and generally are considered to be a self-consistent series 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 that can be stored, transferred, combined, compared, and otherwise manipulated. For primarily reasons of common usage, it may be convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. However, it should be noted that all of these and similar terms are merely convenient labels associated with the appropriate physical quantities and are nothing more than convenient labels applied to these quantities.

[0122] Furthermore, the operations performed are often referred to in terms such as addition or comparison, which are generally associated with intellectual operations performed by a human operator. In any of the operations described herein that form part of one or more embodiments, such capabilities of a human operator are not necessary or, in most cases, desirable. Rather, 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 expressions "coupled" and "connected" along with their derivatives. These terms are not necessarily intended to be synonyms of 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 still cooperate or interact with each other.

[0124] The various embodiments also relate to an apparatus or system for performing these operations. This apparatus may be specially constructed for the required purpose or 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 a particular computer or other apparatus. It will be appreciated that various general-purpose machines may be used with a program written in accordance with the teachings herein, or it may be convenient to construct a more specialized apparatus for performing the required method steps. The required structure for these various machines will become apparent from the given description.

[0125] It is emphasized that a summary of the disclosure is provided so that a reader can quickly ascertain the nature of the technical disclosure. It is presented with the understanding that it is not used to interpret or limit the scope or meaning of the claims. Further, in the foregoing detailed description, various features are grouped together in a single embodiment in order to streamline the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as reflected by the following claims, the subject matter of the present invention lies in less than all of the features of a single disclosed embodiment. Accordingly, the following claims are incorporated into the detailed description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "comprising" and "therein" are used as the plain English equivalents of the respective terms "including" and "wherein." Further, the terms "first," "second," "third," etc. are used merely as labels and are not intended to impose numerical requirements on their objects.

[0126] The foregoing includes examples of the disclosed architecture. Of course, it is not possible to describe all possible combinations of components and / or methodologies, but one of ordinary skill in the art may 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. A memory for storing instructions, A processor for executing the instructions, wherein when the instructions are executed, the processor is caused to execute, a device comprising a processor, The instructions are, Processing login information for logging in to a website via a web browser or an application, wherein the website or the application is related to a service provider system, Executing a pre-authentication routine with an authentication server, the pre-authentication routine causing the processor to execute a predetermined process, The process is, Receiving encrypted data from a contactless card via short-range wireless communication, Transmitting the encrypted data to the authentication server for authentication, Receiving customer service web content including a link from the authentication server, the link establishing a communication link with a server of the service provider system when selected, Processing the selection of the link to establish the communication link and determining a pre-authentication number, Initiating a call with the service provider system and transmitting the pre-authentication number to the service provider system, the service provider system suspending additional authentication based on the pre-authentication number and putting the call into a call agent queue, A device including.

2. The processor is further configured to process the instructions to generate the pre-authentication number, The device according to claim 1.

3. The pre-authentication number is generated in response to receiving the encrypted data from the contactless card, The device according to claim 2.

4. The processor is further configured to add the pre-authentication number to the link, The device according to claim 1.

5. The pre-authentication number is updated for each customer support request, The device according to claim 1.

6. The link is a uniform resource locator (URL) link to the service provider system, The device according to claim 1.

7. The service provider system bypasses an authentication queue and puts the call into the call agent queue to suspend additional authentication based on a pre-authentication filter, The device according to claim 1.

8. A computer-implemented method, The method is, The client device performs a pre - authentication routine with an authentication server based on successful login to a website or application, The pre - authentication routine includes: the client device receiving encrypted data from a contactless card via short - range wireless communication; the client device sending the encrypted data to the authentication server for authentication; the client device receiving customer service web content including a link from the authentication server, where the link, when selected, establishes a communication link with a server of a service provider system; the client device establishing the communication link and processing the selection of the link to determine a pre - authentication number; the client device initiating a call with the service provider system and sending the pre - authentication number to the service provider system, where the service provider system queues the call in a call agent queue to defer additional authentication based on the pre - authentication number. A method.

9. The method according to claim 8, wherein the client device generates the pre - authentication number. The method according to claim 8.

10. The method according to claim 9, wherein the pre - authentication number is generated in response to receiving the encrypted data from the contactless card. The method according to claim 9.

11. The method according to claim 8, wherein the client device adds the pre - authentication number to the link. The method according to claim 8.

12. The method according to claim 8, wherein the pre - authentication number is updated for each customer support request. The method according to claim 8.

13. The method according to claim 8, wherein the link is a Uniform Resource Locator (URL) link to the service provider system. The method according to claim 8.

14. The service provider system bypasses an authentication queue and queues the call in the call agent queue to defer additional authentication based on a pre - authentication filter. The method according to claim 8.

15. A non - transitory computer - readable storage medium, wherein the computer - readable storage medium stores predetermined instructions that, when executed by a device, cause the device to perform: the instructions include: performing a pre - authentication routine with an authentication server based on successful login to a website or application. The pre-authentication routine receives encrypted data from a contactless card via short-range wireless communication; sends the encrypted data to an authentication server for authentication; receives customer service web content including a link and selects the link to establish a communication link with a server of the service provider system; processes the selection of the link to establish a communication link and determines a pre-authentication number; initiates a call with the service provider system and sends the pre-authentication number to the service provider system, wherein the service provider system queues the call in a call agent queue to defer additional authentication based on the pre-authentication number; a non-transitory computer-readable storage medium

Images