阅读说明：本技术 用于客户支持呼叫的预认证的系统和方法 (System and method for pre-authentication of customer support calls ) 是由 杰弗里·鲁尔 拉伊科·埃琳西克 于 2020-03-13 设计创作，主要内容包括：公开了一种利用服务提供商的多因素认证特征和智能呼叫路由来提高客户呼叫中心的安全性和效率的系统和方法。客户支持请求的预认证降低了在呼叫处理期间盗用敏感客户数据的可能性。与客户端唯一关联的非接触式卡可以提供第二认证因素,以减少第三方恶意冒充客户端的可能性。在降低恶意呼叫干扰和信息盗用的机会同时,智能而有效地对预授权的客户支持呼叫进行路由。(A system and method for improving the security and efficiency of a customer call center using a service provider's multi-factor authentication features and intelligent call routing is disclosed. Pre-authentication of customer support requests reduces the likelihood of theft of sensitive customer data during call processing. A contactless card uniquely associated with the client may provide a second authentication factor to reduce the likelihood of a third party maliciously impersonating the client. While reducing the chance of malicious call interference and information theft, pre-authorized customer support calls are intelligently and efficiently routed.)

1. A method of pre-authenticating a support request received by a service provider from one or more coupled devices, comprising the steps of:

receiving a support request from a client operating a client device that has been authorized to access a service provider application in response to first authentication information provided by the client;

requesting second authentication information from the client in response to the support request, the second authentication information including a password obtained by engaging a contactless card with a client device;

receiving the second authentication information including the password from the client device, wherein the password is forwarded from the contactless card to the client device;

selectively authenticating the client by decrypting at least a portion of the second authentication information using a copy of a key associated with the client and maintained by the service provider; and

in response to the authentication of the client:

initiating a call through the client device; and

the call center support service is instructed to bypass the authorization step of the call center support procedure to expedite processing of the initiated call.

2. The method of claim 1, wherein the first authentication information comprises one of a credential, biometric information, a key, or a password.

3. The method of claim 1, wherein the step of requesting second authentication information from the client comprises the step of prompting the client to engage a contactless card providing the password with the client device.

4. The method of claim 1, wherein the key comprises a diversified key generated in response to client information maintained by the service provider, the client information comprising a counter value and a master key.

5. The method of claim 4, wherein the step of selectively verifying comprises the step of decrypting the second authentication information using the diversified key and one or more decryption algorithms to produce decrypted authentication information.

6. The method of claim 5, wherein the decrypted authentication information comprises a decrypted counter value associated with the client, and wherein the method comprises the step of comparing the decrypted counter value to the client information counter value.

7. The method of claim 5, wherein the one or more decryption algorithms are selected from the group consisting of a symmetric encryption algorithm, an HMAC algorithm, and a CMAC algorithm.

8. The method of claim 2, further comprising the step of authenticating the client using the password to access a service provider application prior to receiving the support request.

9. The method of claim 1, wherein the step of initiating a call by the client comprises the step of forwarding a communication link to the client device, the communication link including a mechanism for accessing the call center, the communication link when selected operatively connecting the client device to the call center.

10. The method of claim 9, wherein the communication link comprises a field that, when received by the call center from the client device, instructs the call center to bypass an authorization step of the call center process.

11. The method of claim 1, wherein the step of initiating a call by the client device comprises the step of forwarding a communication link to the call center support service, the communication link comprising a mechanism that enables the call center support service to communicate with the client device.

12. A system for pre-authenticating customer service support requests received at a service provider from one or more coupled client devices, each of said client devices executing a client application customized for communication and cooperation with said service provider, said system comprising:

a client interface adapted to exchange information with one or more coupled client devices;

a storage device;

a diversified key table stored in the storage device and comprising entries for at least one client of the service provider, the entries comprising first and second authentication information for the client;

an authentication unit, coupled to the client interface and the diversified key table, to retrieve one of the first or second authentication information when a client request is received by the client interface and to authorize the client request in response to the retrieved first or second authentication information; and

a customer call center interface coupled to the authentication unit to selectively forward a support request received from the client device to a call center service, the forwarding of the support request occurring after the authentication unit authorizes the support request, the customer call center interface to augment the support request to direct the call center service to bypass authentication of the support request by the call center service process.

13. The system of claim 12, wherein the authentication unit further comprises cryptographic logic to initiate exchange and verification of a password between the client's card and the service provider to authorize the client request.

14. The system of claim 13, wherein the at least one entry of the diversified key table comprises a master key and a counter value of an associated client, and the cryptographic logic comprises:

derivative key generation logic to generate a derivative key for the client in response to the counter value of the client and the master key;

an encryption unit for encrypting at least a portion of the service provider communications using the derivative key; and

a decryption unit for decrypting at least a portion of the client communication using the derived key.

15. The system of claim 12, wherein the client interface is operative to forward a support request reply to the client device, the support request reply including a link to the call center support service.

16. The system of claim 15, wherein the link is adapted to cause the client device to automatically participate in the call center support service.

17. The system of claim 15, wherein the link is visually presented to the client and operates to participate in the call center support service when selected by the client.

18. The system of claim 15, wherein the enhanced support request forwarded to the call center support service includes a telephone number of the client device so that a call center agent can call back the client device.

19. The system of claim 12, wherein the first and second authentication information comprises one of a credential, biometric information, a key, or a password.

20. A method of pre-authenticating a support request received by a service provider from one or more coupled client devices, comprising the steps of:

receiving a support request from a client device that has been authorized to access a service provider application in response to first authentication information provided by the client;

in response to receiving the support request, prompting a client to engage a card with the client device to retrieve second authentication information from the card, the second authentication information including a password;

receiving the second authentication information;

selectively verifying the support request by decrypting at least a portion of the second authentication information using a derivative key associated with the client and maintained by the service provider; and in response to verification of the supported request:

establishing a communication link between the call center support service and the client device by forwarding communication link information to at least one of the client device and the call center support service to cause one of the client device or the call center support service to contact the other; and

an authorization step indicating that the call center support service bypasses the call center support process for each incoming call that has been previously authenticated by the service provider.

Background

Call center services are typically provided by service providers that enable clients to access, modify, delete, or otherwise control their accounts. From a security perspective, call centers may be the most risky area in an enterprise, as call center transactions may expose sensitive client information to malicious third parties.

Call centers face both internal and external risks. Internal risks include employees stealing sensitive customer information. In a typical authentication process, call center personnel have direct access to sensitive customer data. The call center may be outsourced with high call center employee traffic rates. Thus, companies are often at risk that an out-of-work or remote employee may improperly retain customer information.

External risks include the risks posed by "spoofing" and "phishing" in which an impostor disguises or modifies an incoming number, email address, IP address, etc., impersonating a customer in an attempt to steal information or funds. Hackers monitoring service provider communications, particularly call center communications, to steal customer information also pose external risks.

To address these security issues, the payment card industry security standard committee (PCI SSC) is responsible for managing the ongoing development of Payment Card Industry (PCI) security standards. The service provider is responsible for enforcing compliance with the PCI standard to protect sensitive customer data. For example, the PCI standard may specify an authentication standard to be followed before a client is allowed to access and/or modify customer account information. The call center may need to perform client authentication in the form of exchanging passwords, answering personal questions, biometric data, etc. The customer may be prompted to provide authentication information in various forms multiple times during the processing of the call. Not only can such authentication and re-authentication processes be annoying to customers and reduce the reputation of service providers, each authentication instance can expose sensitive customer information to potentially malicious parties.

Disclosure of Invention

According to one aspect of the invention, a method of pre-authenticating a support request received by a service provider from one or more coupled devices, comprises the steps of: a support request is received from a client operating a client device that has been authorized to access the service provider application in response to first authentication information provided by the client. In response to the support request, the method includes requesting second authentication information from the client, the second authentication information including a password and receiving the second authentication information including the password from the client device. The method includes selectively authenticating the client by decrypting at least a portion of the second authentication information using a copy of a key associated with the client and maintained by the service provider. The method comprises the following steps; responsive to the authentication of the client, expedite processing of the initiated call by initiating a call by the client device and an authorization step that instructs a call center support service to bypass a call center support procedure. With such an arrangement, the service provider's multi-factor authentication mechanism can be used with customer support services, thereby increasing the efficiency of client problem resolution and increasing customer information security.

According to another aspect of the present invention, a system for pre-authenticating customer service support requests received at a service provider from one or more coupled client devices includes a client interface adapted to exchange information with the one or more coupled client devices. The system also includes a storage device and a diversified key table stored in the storage device and including an entry for at least one client of the service provider, the entry including first and second authentication information for the client. The system further includes an authentication unit, coupled to the client interface and the diversified key table, for retrieving one of the first or second authentication information when a client request is received by the client interface and authorizing the client request in response to the retrieved first or second authentication information. A customer call center interface is coupled to the authentication unit for selectively forwarding a support request received from the client device to a call center service, the forwarding of the support request occurring after the authentication unit authorizes the support request, the customer call center interface enhancing the support request to direct the call center service to bypass authentication of the support request by the call center service process.

According to a further aspect of the invention, a method of pre-authenticating a support request received by a service provider from one or more coupled client devices, comprises the steps of: a support request is received from a client device that has been authorized to access the service provider application in response to first authentication information provided by the client. In response to receiving the support request, the method includes prompting a client to engage a card with the client device to retrieve second authentication information from the card, the second authentication information including a password and receiving the second authentication information. The method includes selectively verifying the support request by decrypting at least a portion of the second authentication information using a derivative key associated with the client and maintained by the service provider. In response to verification of the supported request, the method includes the authorization step of establishing a communication link between the call center support service and the client device by forwarding communication link information to at least one of the client device and the call center support service to cause one of the client device or the call center support service to contact the other and to instruct the call center support service to bypass call center support procedures for each incoming call that has been previously verified by the service provider.

Drawings

FIG. 1A is a block diagram illustrating a data transmission system configured to pre-authenticate a client request in accordance with an illustrative embodiment;

FIG. 1B is a diagram illustrating a sequence for providing authenticated access, according to an example embodiment;

FIG. 2 is an example of a contactless card for storing authentication information that may be used in the system of FIG. 1A;

FIG. 3 is a detailed block diagram illustrating exemplary components of the contactless card of FIG. 2;

FIG. 4 is a diagram illustrating exemplary message fields exchanged between the contactless card and the client device of FIG. 1A;

FIG. 5 is a detailed block diagram of components of the system of FIG. 1A that may be used to support aspects of the present invention;

FIG. 6 is a data flow diagram depicting exemplary steps that may be performed in one embodiment by the components of FIG. 4 during call authentication in accordance with aspects of the invention;

FIG. 7 is a data flow diagram depicting exemplary steps that may be performed during one embodiment of a call routing process using the contactless card of FIG. 2;

FIG. 8 is a data flow diagram depicting exemplary steps that may be performed during another embodiment of a call routing process using the contactless card of FIG. 2;

fig. 9 is a block diagram illustrating an exemplary call processing pipeline in a call service center that accepts pre-authenticated service requests.

Detailed Description

Some embodiments of the present invention are directed to using one or more keys that have been incorporated into one or more contactless cards, as described in U.S. patent application 16/205119, issued 2018 on 11/29 by Osborn et al, entitled "contactless card cryptographic authentication system and method," which is incorporated herein by reference (hereinafter the' 119 application). The contactless card may be used to perform authentication andmany other functions that may require the user to carry a separate physical token in addition to the contactless card. Contactless cards may be used to perform authentication and many other functions that may require a user to carry a separate physical token in addition to the contactless card. By employing a contactless interface, contactless cards may have a way to interact and communicate between a user's device (e.g., a mobile phone) and the card itself. For example, the EMV protocol underlying many credit card transactions includes an authentication process forOperating systems are sufficient, but forIt is a challenge becauseThe use of Near Field Communication (NFC) is more limited because it can only be used in a read-only manner. Unlike RFID, RFID can be used to read devices in long-range motion. Exemplary embodiments of the contactless card described in the' 119 application may utilize NFC technology.

A system and method for improving the security and efficiency of a customer call center using a service provider's multi-factor authentication features and intelligent call routing is disclosed. Pre-authentication of customer support requests reduces the likelihood of theft of sensitive customer data during call processing. A contactless card uniquely associated with the client may provide a second authentication factor to reduce the likelihood of a malicious third party impersonating the client. Pre-authenticated customers support call routing in an intelligent and efficient manner, thereby reducing the chance of malicious call interference and information theft.

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

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, or software in execution, examples of which are described herein. For example, a component may be, but is not limited to being, a process running on a processor, a computer processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can 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.

In addition, the components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve one-way or two-way exchange of information. For example, the components may communicate information in the form of signals communicated over the communications media. This information may be implemented as signals assigned to various signal lines. In this allocation, each message is a signal. However, further embodiments may alternatively employ data information. Such data information may be sent over various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

Fig. 1A shows a system 100, the 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 service provider content and services.

As described herein, network-enabled computers may include, but are not limited to: for example, a computer device, or a communication device, including, for example, a server, a network device, a Personal Computer (PC), a workstation, a mobile device, a telephone, a handheld PC, a Personal Digital Assistant (PDA), a thin client device, a thick client device, an internet browser, or other device.

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

One or more client devices 110 may also be, for example, mobile devices, e.g., fromiPhone, iPod, iPad or any other mobile device running Apple's iOS operating system, running MicrosoftAny device of the mobile operating system and/or any other smartphone or similar wearable mobile device.

The various client devices 110 of FIG. 1A include a cellular telephone 142, a laptop computer 144, a tablet 148, and a terminal 146. The client device 110 may include a thin client application specifically adapted to communicate with the service provider 120. The thin client application may be stored in a memory of the client device and operable when executed by the client device to control an interface between the client device and the service provider application to allow a user at the client device to access service provider content and services.

In some examples, the 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 the client device 110 to the service provider 120. For example, the network 115 may include one or more of the following: fiber optic networks, passive optical networks, cable networks, internet networks, satellite networks, wireless Local Area Networks (LANs), global system for mobile communications, personal communication services, personal area networks, wireless application protocols, multimedia message services, enhanced message services, short message services, time division multiplexing based systems, code division multiple access based systems, 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, and the like.

Further, the network 115 may include, but is not limited to, telephone lines, fiber optics, IEEE ethernet 902.3, wide area networks ("WANs"), wireless personal area networks ("WPANs"), local area networks ("LANs"), or global networks, such as the internet. Further, the network 115 may support an internet network, a wireless communication network, a cellular network, and the like, or any combination thereof. The network 115 may also include one network or any number of the above exemplary types of networks, operating as independent networks or cooperating with each other. The network 115 may utilize one or more protocols of one or more network elements communicatively coupled thereto. The network 115 may translate to or from other protocols to one or more protocols of the network device.

It should be appreciated that the network 115 may be part of a plurality of interconnected networks, such as the internet, a service provider's private network 125, a cable network, a corporate network (e.g., a credit card association network), and a home network, according to one or more examples. In addition, private network 125 may be implemented as a virtual private network layered on network 115.

In one embodiment, the service provider 120 is an enterprise that provides computer-based services to clients over the network 115. Almost all modern service providers use the internet to provide services to potential consumers. Service products are typically provided in the form of software applications that operate using dedicated resources of the service provider. The combination of software and hardware that provides a particular service to a client is referred to herein as a "server". The servers may communicate through a service provider's private network 125, commonly referred to as a corporate or enterprise network. The private network 125 may include a wireless network, a wired network, or any combination of wireless and wired networks, as described above with respect to the network 115.

In the system of fig. 1A, the service provider 120 is shown as including an application server 150, an authentication server 160, and a Customer Relationship Management (CRM) server 140. Although each server is shown as a discrete device, it will be understood that the applications and servers may be distributed throughout the enterprise, or throughout the network 115 in the case of distributed resources such as "cloud" resources. The application server 150 may support one or more application services, such as account management services, provided by the service provider 120. The CRM server 140 may be used to provide customer support services to clients of the service provider 120, including the processing and forwarding of incoming calls from the clients to one or more call processing agents operating at the workstations 132, 135.

Database 130 includes data storage resources that may be used, for example, to store customer accounts, credentials, and other authentication information for use by application server 150 and authentication server 160. Database 130 may be comprised of coupled data resources including any combination of local storage, distributed data center storage, or cloud-based storage.

According to one aspect, contactless card 105 may communicate wirelessly, such as 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, the contactless card 105 may communicate with the client device 110 through other means including, but not limited to, bluetooth, satellite, and/or WiFi. As described in the 119 application, the contactless card 105 may be configured to communicate with one of the card reader terminal 146, the cellular telephone 142, the laptop computer 144, and/or the tablet 148 via NFC when the contactless card 105 is within range of a corresponding client device. As will be described in more detail below, the contactless card 105 may include key and counter information that may be converted using a cryptographic algorithm to generate a password that may be used by a service provider to authenticate a client device.

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

At step 102, the application 122 communicates with the contactless card 105 (e.g., after coming into proximity with the contactless card 105). Communication between the application 122 and the contactless card 105 may involve the contactless card 105 being in sufficient proximity to a reader (not shown) of the client device 110 to enable NFC data transfer between the application 122 and the contactless card 105.

At 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) password. In some embodiments, this may occur when application 122 reads contactless card 105. In particular, this may occur when reading (e.g., NFC reading) a near field data exchange (NDEF) tag that may be created according to an NFC data exchange format. For example, a reader such as the application 122 may send a message, such as an applet selection message, with the NDEF generating the applet ID for the applet. Upon confirmation of the selection, a sequence of selected file messages followed by read file messages may be sent. For example, the sequence may include "select function file", "read function file", and "select NDEF file". At this point, the counter value maintained by the contactless card 105 may be updated or incremented, which may be followed by "reading the 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. The MAC password may be created from a message, which may include a header and a shared secret. The MAC cipher may then be concatenated with one or more random data blocks, and the MAC cipher and Random Number (RND) may be encrypted with a session key. Thereafter, the ciphertext and header may be concatenated and encoded as ASCII hexadecimal and returned in NDEF message format (in response to the "read NDEF file" message).

In some embodiments, the MAC password may be transmitted as an NDEF tag, and in other examples, the MAC password may be included with a uniform resource indicator (e.g., as a formatting string).

In some examples, application 122 may be configured to send a request to contactless card 105 that includes an instruction to generate a MAC password.

At step 106, the contactless card 105 sends the MAC password to the application 122. In some examples, the transmission of the MAC password occurs via NFC, however, the invention is not limited thereto. In other examples, the communication may occur via Bluetooth, Wi-Fi, or other wireless data communication means.

At step 108, application 122 passes the MAC password to processor 124.

At step 112, the processor 124 verifies the MAC password according to instructions from the application 122. For example, the MAC password may be verified, as described below.

In some examples, verifying the MAC password 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 password for transmission to the service provider 120, and the service provider 120 may verify the MAC password.

In some examples, the MAC password may be used as a digital signature for verification. Other digital signature algorithms, such as public key asymmetric algorithms, such as digital signature algorithms and RSA algorithms, or zero knowledge protocols, may be used to perform this verification.

More specifically, according to one aspect, the contactless card 105 may be used with first authentication credentials provided to the application service provider to pre-authenticate the customer support request before forwarding the support request to the CRM server 140. Pre-authenticating customer support requests in this manner provides a dual advantage; since the authentication information is not forwarded to the CRM, opportunities for call center agents to misuse such information are avoided. Furthermore, the use of a contactless card as a second authentication factor enables a particular device/phone number to be associated with a particular individual (i.e., the owner of the card), thereby eliminating the ability of a malicious third party to "spoof" (i.e., impersonate) a client. According to another aspect, the pre-authentication communication protocol described below identifies or uses a particular communication channel for call processing, thereby reducing the chance of client impersonation.

Exemplary embodiments of the systems and methods described herein may be configured to provide multi-factor security authentication that may be used to bypass authentication of the CRM server 40, thereby reducing the likelihood that sensitive client information is stolen during call processing.

Security factor authentication may include a number of processes. The first authentication process may include logging in and authenticating the user via one or more applications executing on the device. The second authentication process may operate after successful login and verification to cause the user to engage in one or more behaviors associated with the one or more contactless cards. In practice, the security factor authentication process comprises a multi-factor authentication process that may include securely proving the identity of the user and encouraging the user to engage in one or more behaviors associated with the contactless card, including, but not limited to, one or more tap gestures. In some examples, the one or more tap gestures may include the user tapping the device with a contactless card. In some examples, the device may include a mobile device, a kiosk, a terminal, a tablet, or any other device configured to process the received tap gesture.

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 webpage using an internet browser application executing on the client device. Browsers being software applications, e.g.InternetEtc., and includes programming code for translating a hypertext markup language (HTML) web page of the service provider application into a format suitable for operating a client of the client device. As part of accessing the service provider website, the service provider may request first authorization information, including password information, answers to pre-stored queries, biometric information, images, or other mechanisms to verify whether the user of the client device has access to content and services (including accounts), managed by the service provider.

Certain high-risk services provided by service providers, such as call center support, may benefit from multi-factor authentication. For example, the service provider may store the first level authentication information as a cookie in the client's browser to speed up the authentication process during client login. Browser cookies and associated passwords or other data are easily discovered and abused. Therefore, before allowing a user to access or modify highly sensitive or personal information (as may occur during a customer-supported call), it is important to verify that the user has access rights.

According to one aspect, the contactless card 105 may be used to provide a second authentication for the user of the client device. In one embodiment, and as described in more detail below, the contactless card includes a key, a counter, and a cryptographic processing function that can be used to generate a password that can be used to authenticate a user of a client device. The counter advantageously reflects the previous behavior of the cardholder. For example, the counter may reflect the number of times the user previously accessed a particular service of the service provider, which information is nearly impossible for a malicious third party to accurately obtain.

When the client seeks to access a high-risk service, in some embodiments, the service provisioning 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.

After the second authentication, and as will be described in more detail below, the service provider returns data to the client device. The data may include data that allows the client to initiate a communication link with the CRM server 140. Such data may include contact information, such as a link to a CRM service provider application, or a telephone number of a call center. In some embodiments, the contact information may be augmented with control information for the CRM or call center. For example, the control information may instruct the CRM or call center to bypass any authentication or Interactive Voice Response (IVR) processes typically performed at the call center to account for the fact that the client has been pre-authenticated through the service provider application/contactless card multi-factor authentication process.

It should be noted that although in the above description the first authentication is described as using personal information, biometric information, questions or other authentication information, in some examples it should be appreciated that a client application executing on the device may respond to a tap of the contactless card to initially activate or launch an application of the device. In such an example, both the first and second authentication processes use a key/counter contactless card authentication process described in more detail below. In some embodiments, if the client application is not installed on the client device, a tap of the contactless card near the card reader may initiate a download of the application (e.g., navigate to a download page of the application). After installation, the tapping of the contactless card may activate or start an application and then initiate activation of the contactless card, for example, through an application or other backend communication. In some embodiments, one or more applications may be configured to determine that it was initiated by one or more tap gestures of contactless card 101 such that initiation occurs at 3:51 PM and the transaction is processed or occurred at 3:56 PM to verify the identity of the user.

In some examples, data may be collected at the time of the tap behavior as biometric/gesture authentication. For example, a unique identifier that is cryptographically secure and not easily intercepted may be transmitted to one or more back-end services. The unique identifier may be configured to look up secondary information about the individual. The secondary information may include personally identifiable information about the user. In some embodiments, the secondary information may be stored in a contactless card.

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 service provider 205 displayed on the front or back of the card 200. In some embodiments, contactless card 200 is independent of a payment card, and may include, but is not limited to, an identification card. In some embodiments, the payment card may comprise a dual interface contactless payment card. Contactless card 200 may include a substrate 210 that may include a single layer, or one or more laminate layers composed of plastic, metal, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some embodiments, contactless card 200 may have physical characteristics that conform to the ID-1 format of the ISO/IEC 7810 standard, and the contactless card may additionally 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 implementation of the contactless card in a payment card.

Contactless card 200 may also include identification information 212 and contact pads 220 displayed on the front and/or back of the card. The contact pad 220 may be configured to establish contact with another communication device, such as a user device, a smart phone, a laptop, a desktop computer, or a 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 the contact pads 220 or elsewhere on the substrate 210. Contactless card 200 may also include a magnetic strip or tape, which may be located on the back of the card (not shown in fig. 2).

As shown in fig. 3, the contact pads 220 may include processing circuitry for storing and processing information, including a microprocessor 330 and a memory 335. It should be understood that the processing circuitry may contain additional components, including a processor, memory, error and parity/CRC checker, data encoder, anti-collision algorithm, controller, command decoder, security primitives, and tamper-resistant hardware, to perform the functions described herein.

The memory 335 may be a read-only memory, a write-once read-many memory, or a read/write memory, such as RAM, ROM, and EEPROM, and the contactless card 300 may include one or more of these memories. The read only memory may be factory programmable to be read only or one time programmable. One-time programmability provides the opportunity to write once and then read multiple times. The write-once/read-many memory can be programmed at a certain point in time after the memory chip is shipped from a factory. Once the memory is programmed, it may not be rewritten, but it may be read multiple times. The read/write memory may be programmed and reprogrammed multiple times after shipment. It can also be read multiple times.

The memory 335 may be configured to store one or more applets 340, one or more counters 345, and customer information 350. The one or more applets 340 can include one or more software applications configured to execute on one or more contactless cards, such as a Java Card applet. However, it should be understood that applet 340 is not limited toCard applet, but can be any software application operable on a contactless Card or other device with limited memory. The one or more counters 345 may comprise a digital counter sufficient to store an integer. Customer information 350 may include a unique alphanumeric identifier assigned to the user of contactless card 200 and one or more cryptographic keys together may distinguish the user of the contactless card from other contactless card users. In some embodiments, customer information 350 may include information identifying the customer and an account assigned to the customer, and may further identify a contactless card associated with the customer's account.

The processor and memory elements of the foregoing exemplary embodiments are described with reference to contact pads, but the invention is not limited thereto. It should be understood that these elements may be implemented external to, or entirely separate from, the contact pads 220, or as additional elements in addition to the microprocessor 330 and memory 335 elements located within the contact pads 220.

In some embodiments, contactless card 200 may include one or more antennas (not shown). One or more antennas may be placed within contactless card 200 and around the processing circuitry of contact pads 220. For example, one or more antennas may be integrated with the processing circuitry, and one or more antennas may be used with the external boost coil. As another example, one or more antennas may be external to the contact pads 220 and processing circuitry.

As described above, contactless card 200 may be built on a software platform, such as a JavaCard, that is operable on a smart card or other device that includes program code, processing functionality, and memory. Applets may be added to contactless cards to generate one-time passwords (OTP) 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 near field data exchange (NDEF) requests, from a card reader, such as a mobile Near Field Communication (NFC) card reader, and generate a NDEF message that includes an encrypted secure OTP encoded as a NDEF text tag. The contactless card is thus functionally adapted to provide a unique one-time password as part of the above-mentioned near field data exchange communication.

Fig. 4 illustrates an exemplary NDEF short record layout (SR ═ 1)400, according to an example embodiment. The NDEF message provides a standardized method for the client device 110 to communicate with the contactless card 105. In some embodiments, the NDEF message may include one or more records. NDEF record 400 includes a header 402, the header 402 including a plurality of flags defining how to interpret the rest of the record, including a message start (MB) flag 403a, a Message End (ME) flag 403b, a block flag (CF)403c, a Short Record (SR) flag 403d, an ID Length (IL) flag 403e, and a Type Name Format (TNF) field 403 f. The MB 403a and ME flag 403b may be set to indicate the respective first record and last record of the message. The CF 403c and IL flag 403e provide information about the records, including whether the data is "chunked" (data is distributed among multiple records within a message) or whether the ID type length field 408 is relevant, respectively. When the message includes only one record, the SR flag 403d may be set.

The TNF field 403f identifies the type of content contained by the NFC protocol defined field. These types include empty, well-known (data defined by the Record Type Definition (RTD) of the NFC forum), Multipurpose Internet Mail Extensions (MIME) [ defined by RFC 2046 ], absolute Uniform Resource Identifiers (URIs) [ defined by RFC 3986 ], external (user-defined), unknown, unmodified [ for blocks ], and reserved.

Other fields of the NFC record include type length 404, payload length 406, ID length 408, type 410, ID 412, and payload 414. Contains the length of the payload type in bytes. The 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 4294967295 bytes (or 2^32-1 bytes) of data. The ID length 408 contains the length of the ID field in bytes. Type 410 determines the type of data contained in the payload. The ID field 412 provides a way for external applications to identify the entire payload carried in the NDEF record. Payload 414 comprises a message.

In some examples, the data may be initially stored in the contactless card by implementing the storing of the data under a secure channel protocol (E2). This data may include a card-specific individual user id (plid), as well as one or more of an initial key, cryptographic process data including a session key, a data encryption key, a random number, and other values as will be described in more detail below. These values may be used to generate a Message Authentication Code (MAC) that may be used to pre-authenticate the client prior to customer service processing.

Exemplary information that may be exchanged with the contactless card 105 and the authentication server 160 during initialization to populate the contactless card to support secure authentication according to some aspects of the present invention is shown in table I below.

Table 1:

after initialization, both the contactless card and the authentication server store information that uniquely identifies the cardholder. These features may be used according to one aspect to authenticate a client's access to high-risk services, as described below.

Fig. 5 illustrates a communication system in which a contactless card 510 may store information, such as that included in table 1, that may be used to authenticate a user prior to connecting the user with a high-risk service of a service provider. In one aspect, a "high-risk service" is a service that may benefit from a multifactor authentication process because the service has an opportunity to expose sensitive customers or other information. As described with respect to fig. 3, each contactless card may include a memory 516 for storing customer information 518 including one or more unique identification attributes (e.g., an identifier, a key, a random number, etc.). In one aspect, the memory also includes an authentication applet 517 operable when executed by the microprocessor 512 to control the authentication process described herein. In addition, each card 510 may include one or more Application Transaction Counters (ATCs) 514 and an interface 515. As described above, in one embodiment, the interface operates an NFC or other communication protocol.

Client device 520 also includes a card interface 525 for communicating with contactless cards, as well as one or more other network interfaces (not shown) that allow device 520 to communicate with a service provider using various communication protocols as described above. The client device may also include a user interface 526, which may include one or more of a keyboard or touch screen display, allowing communication between the service provider application and the user of the client device 520. The client device 520 also includes memory 522 that stores information and program code that controls the operation of the client device 520, including for example a client application 523, which may be provided to the client by a service provider to facilitate access and use of the service provider application. In one embodiment, client application 523 comprises program code configured to communicate authentication information from contactless card 510 to one or more services provided by a service provider. The client application 523 may be controlled by 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 a client application to access SP application services.

As described with respect to fig. 1A, the client device 520 may connect to various services provided by the service provider 505, including a Customer Relationship Manager (CRM) server 540 and an authentication server 550. In one embodiment, the CRM server 540 manages the routing of received support calls and forwards received calls to the call processing pipeline 542. The authentication server 550 includes a client information table 552, and the client information table 552 is used to store information such as that shown in table 1 for clients of a service provider. The authentication unit 554 includes hardware and software for performing various authentication processes for the client using information from the table 556. In one embodiment, the authentication server may also include a client counter value table 556, which may be used to perform authentication in conjunction with contactless card 510 as described below.

Fig. 6 illustrates various steps that may be performed by the authentication service of contactless card 601, client device 611, and service provider 621, which are configured to use key diversification techniques as part of a multi-factor authentication protocol for pre-authenticating clients. For example, a cardholder who is able to access contactless card 601 of client device 611 may seek authentication from service provider 621 in order to be able to access services, including seeking multi-factor authentication to access high-risk services, such as call center support.

At step 610, the client 611 first accesses a client account maintained by the service provider 621 by exchanging login credentials with the service provider, where in one embodiment, the login credentials may include, but are not limited to, passwords, keys, biometric data, image data, query/response exchanges, and the like. In one embodiment, the client may initiate this access by launching a client application via the SP application interface 527. Launching the application may include displaying a web page of the service provider, the web page configured to accept the first credential information from the user.

In some embodiments, the first level of authentication may be performed using a cryptographic exchange process for the second level of authentication described below. The service provider application may initiate a password exchange by tapping contactless card 601 to client device 611.

The service provider receives the credentials at step 620 and compares the credentials to the credentials of the client maintained by the authorization server. If the login credentials do not match at step 622, the service provider proceeds to step 631 to use other methods for authentication of the client device. If a match is determined to exist at step 622, the client is authenticated and the service provider coordinates with a client application maintained by the client device 611 to display a service provider web page to the client to allow access to one or more services.

At 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 a service provider website to direct the client to access the selected service. For example, the hyperlink may include a web address of a landing page of the service. Alternatively, the hyperlink may include a telephone number of the customer support system.

Upon receiving the customer service request at 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 where the second factor authentication is provided using a contactless card, the service provider may prompt the client device to use the contactless card to retrieve a password for verification purposes. The prompt may be any manner of indicating to the customer that they should use the contactless card, including text prompts, visual prompts, audible prompts, and other available indication mechanisms.

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

At step 602, the contactless card receives an authentication request. At step 604, a processing component within the contactless card increments an Application Service Transaction (AST) counter and encodes the counter using a symmetric cryptographic algorithm using a master key stored in the contactless card to generate a diversified key. The cryptographic algorithm may be selected from the group consisting of 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 diversified values may include any symmetric cryptographic algorithm that is used to generate diversified symmetric keys of a desired length as needed. Non-limiting examples of symmetric algorithms may include symmetric encryption algorithms, such as 3DES (triple data encryption algorithm) or Advanced Encryption Standard (AES) 128; a symmetric hash-based message authentication (HMAC) algorithm, such as HMAC-SHA-256; and a symmetric cipher based message authentication code (CMAC) algorithm, 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 using different input data and the same master key may produce multiple outputs that may be combined as needed to generate a sufficiently long key.

The processing component of the contactless card may employ the selected encryption algorithm and process the counter value using the master symmetric key. For example, the contactless card 601 may select a symmetric encryption algorithm and use a counter that is incremented with each authenticated transaction processed by the contactless card. The contactless card 601 may then encrypt the counter value using the master symmetric key using the selected symmetric encryption algorithm to generate a diversified symmetric key.

In one aspect, diversified symmetric keys can be used to process counters prior to transmission for authorization purposes. For example, contactless card 601 may encrypt the counter value using a symmetric encryption algorithm and a diversified symmetric key, the output including an encrypted MAC password. Contactless card 601 may then send the password to service provider 621 for authentication.

In one embodiment, the template for the authentication message including the password may include a first record having a well-known index for providing the actual dynamic authentication data. Table II below is one example of authentication messages that may be exchanged between client device 611 and contactless card 601.

Table II:

in one example, if additional flags are to be added, the first byte may change to indicate that the message begins, rather than ends, and subsequent records may be added. Since the ID length is zero, the ID length field and the ID are omitted from the record. The example messages shown in table III below may include: a UDK AUT key; derived AUT session key (using 0x 1234); version 1.0; pATC ═ 0x 1234; RND 76a6627b67a8 cfbb; MAC ═ 8 bytes of computation >. The first column may include the address/index of the incoming NDEF message data.

Table III:

at step 618, the client device 611 receives the password and forwards it to the service provider 621. At step 626, after the service provider requests the second factor authentication at step 624, in one embodiment, the authentication server of the service provider 621 retrieves client information associated with the cardholder of the contactless card associated with the account of the client using the client device. The client information may include a master key of the client and a counter of application service transactions of the contactless card. The service provider 621 encodes the retrieved counter value using the master key and a cryptographic algorithm that matches the cryptographic algorithm used by the contactless card to produce a service provider copy of the diversified key.

At step 628, the service provider decrypts the password using the diversified key to expose the counter value forwarded by the contactless card. At step 629, the service provider compares the exposed counter with the service provider retrieved counter, which provides a second authentication of the user. If there is no match, the client is not granted access to the service and, at step 631, the service provider 621 may seek to authenticate the user using other methods. If there is a match at step 629, the service provider initiates call processing with the CRM server at 630. In one aspect, as will be described with reference to fig. 7 and 8, the service provider may generate one or more messages for controlling one of the CRM or client device to take advantage of the pre-authentication that the service provider has performed.

When the non-contact card is used for authentication next time, different counter values can be selected to generate different diversified symmetric keys, so that a malicious party monitoring communication is difficult to decrypt the communication. Both the service provider and the contactless card increment a counter according to a predetermined incrementing pattern agreed upon by both parties. For example, the counter may be incremented by 1, or in some pattern, such as 1 for a first transaction, 2 for a second transaction, 3 for a third transaction, or 5 for each transaction. Since contactless cards and service providers use a common counter, a common incremental mode, a common master key and a common cryptographic algorithm, both the sending device and the receiving device will have the same key even though the diversified key will change in each transaction.

As described above, in some examples, the diversified value of the key may be implemented using a counter value. Other non-limiting examples of key diversification values include: a random nonce generated each time a new diversified key is required; a full value of the counter values transmitted from the transmitting device and the receiving device; a part of the counter values transmitted from the transmitting device and the receiving device; a counter maintained independently by the transmitting device and the receiving device but not transmitted therebetween; a one-time password exchanged between the transmitting device and the receiving device; and cryptographic hashes of counters. In some examples described in the' 119 application, parties may use one or more portions of the key diversification value to create multiple diversified keys. For example, a counter may be used as the key diversification value.

In another example, a portion of the counter may be used as a key diversification value. If multiple master key values are shared between parties, multiple diversified key values may be obtained by the systems and processes described herein. New diversified values can be created as often as necessary to create new diversified symmetric keys. In the most secure case, a new diversification value can be created for each exchange of sensitive data between the sending device and the receiving device. In practice, this may create a one-time-use key, such as a single session key.

Various other symmetric encryption/decryption techniques are described in the' 119 application in lieu of those described in connection with fig. 6 and are incorporated herein by reference.

Fig. 7 and 8 each illustrate an exemplary transaction flow that may be performed after multi-factor authentication of a client seeking access to a call center service. In one embodiment, the client information stored on the contactless card may include client-specific call center information. For example, the call center information may include a number. The number may include any portion or combination of an IP address, telephone number or other contact address, random number or IP address, telephone number or other contact address, or random number. Fig. 7 illustrates exemplary 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.

After the multi-factor pre-authentication process shown in fig. 6, the service provider's application server 703 populates the client interface with customer service web content 710. The web content may include contact information including a URL, phone number, or other contact address for communicating with the CRM server. 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 network content includes a prompt 711 requesting a connection with the contactless card 701.

The contactless card 701, upon receiving the prompt, forwards the stored pre-authentication number 712 to the client device, which makes it available to the application 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 when the communication link is generated. For example, the network content 710 may include links to customer service telephone numbers 1-800-. The contactless card may provide a pre-authentication number 7777 that the client device appends to the telephone number. The client device initiates a call 715 over the cellular network to-800-. At 714, the application server alerts the CRM of the incoming call with the additional number of the contactless card. The CRM monitors for incoming calls with pre-authenticated numbers and bypasses authentication when dialing 716 in the customer service agent pipeline.

Although 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 for attaching to the call. The pre-authentication number may be generated in response to communication with the contactless card, for example after a password exchange with the contactless card as described in fig. 6. In some embodiments, the pre-authentication number may change for each customer support request. Such an arrangement ensures that customer support calls are not redirected by malicious parties, as the imposter client device will not have a pre-authentication number, and thus authentication will not be bypassed on the CRM server.

In other embodiments, as shown in FIG. 8, to further protect call processing from malicious interference, call processing is initiated by a customer service agent. After pre-authentication using the process of fig. 6, the client device is provided with customer support web content 810. In one embodiment, the content includes a prompt 811 to encourage re-authorization of the client device. The contactless card 812 generates a password as described above, which is forwarded to the authorization server 703 via the client device 702 for authentication. Once the authorization server verifies the password, the authorization server instructs the CRM server to bypass authorization of the call at step 815 and instructs the CRM server to begin calling the client device phone number, IP address, etc. via the back-end server at step 814. At 816, the CRM initiates the call.

In some embodiments, the re-authentication step may occur after the customer service agent 705 initiates the call to ensure that the call is not redirected between the previous authentication and call processing. Such an embodiment may be beneficial when there is a delay between the previous authentication and call processing (e.g., a long wait in a customer service queue or a scheduled call back).

FIG. 9 illustrates several exemplary components of one embodiment of a CRM service 900. The CRM service 900 is shown as including authentication logic 906 and a proxy assignment unit 910. The incoming call 901 is forwarded to a pre-authentication filter 902. Pre-authentication filter 902 may store the pre-authentication number received from the authorization server as described above. Incoming calls that are not pre-authenticated are forwarded to authentication queue 904. The authentication logic retrieves the incoming call from the queue 904 and cooperates with an authentication server (not shown) to authenticate the client using any combination of the authentication methods described above. Once authenticated, the call is forwarded to queue 908.

Incoming calls determined to be pre-authenticated are forwarded directly from pre-authentication filter 902 to queue 908. Advantageously, to minimize the possibility of malicious interference, the pre-authentication number is deleted from the pre-authentication filter 902 once a call with the stored pre-authentication number is bypassed in this manner.

Thus, queue 908 stores authenticated calls that are assigned to agents 920, 922, 924 for processing by agent assignment unit 910 according to resource load. With such an arrangement, pre-authenticated calls can be intelligently routed at the customer call center to minimize processing delays.

Accordingly, a system and method are described for improving the security and efficiency of a customer call center utilizing the multi-factor authentication features and intelligent call routing of a service provider. Some embodiments may be described using the expression "one embodiment" or "an embodiment" along with their derivatives. The terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearances of the phrase "in one embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the above features are contemplated to be used together in any combination, unless otherwise specified. Thus, any features discussed individually may be used in combination with each other, unless it is noted that the features are not compatible with each other.

With general reference to the symbols and nomenclature used herein, the detailed description 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 process 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.

A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations 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 has proven convenient at times, 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.

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

Some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. 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. The term "coupled," however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

Various embodiments are also directed to an apparatus or system 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 processes described herein are not inherently related to a 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 a variety of these machines will appear from the description given.

It is emphasized that the abstract of the disclosure is provided to enable 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. Furthermore, in the foregoing detailed description, various features are grouped together in a single embodiment for the purpose of streamlining 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 less than all features of a single disclosed embodiment. Thus 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 "including" and "in which" are used as the plain-english equivalents of the respective terms "comprising" and "wherein", respectively. Moreover, the terms "first," "second," "third," and the like are used merely as labels, and are not intended to impose numerical requirements on their objects.

What has been described above includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and/or methodologies, but one of ordinary skill in the art may recognize that many further 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.