Patent ID: 12212709

DETAILED DESCRIPTION

Reference will now be made to the illustrative embodiments illustrated in the drawings, and specific language will be used here to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Alterations and further modifications of the inventive features illustrated here, and additional applications of the principles of the inventions as illustrated here, which would occur to a person skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the invention.

With the ever-changing topology of the telephony channel (sometimes referred to as a “call channel”), techniques and tools for spoofing telephone calls to call centers or other enterprises grow more numerous and easier to deploy. As a result, the telephony channel is inherently untrustworthy. In addition, it is becoming harder to authenticate callers while maintaining the usability of the system by callers and call center agents.

The system disclosed herein builds on the trust of a data channel for the telephony channel. Certain types of authentication information can be received through the telephony channel, as well. But the mobile application associated with the call center system may provide additional or alternative forms of data through the data channel. The system may send requests to a mobile application of a device to provide information that can reliably be assumed to be coming from that particular device, such as a state of the device and/or a user's response to push notifications. In some cases, the authentication processes may be based on quantity and quality of matches between certain metadata or attributes expected to be received from a given device as compared to the metadata or attributes received.

In addition, system requests for authentication information may be transmitted to a mobile application associated with the call center system and installed on a registered device. Devices that are not executing the mobile application are inhibited or prohibited from adequately communicated with the components of the system. For instance, certain requests for authentication information are sent to the mobile application on a registered device. If an imposter calls from an imposter device purporting to be a registered user, then the authenticating request is still sent to the mobile application of the registered user. The requests sent to the mobile application may include a push notification or text message, which prompts the registered user for a response via a graphical user interface (GUI) to indicate whether that registered user is attempting to access the call center system. An element of the GUI could allow the user to immediately report fraud, which provides convenient and secure protection from spoofing or other forms of social engineering attacks directed to call centers. In some cases, the affirmative or negative response may be all that is needed to authenticate the call, while other cases may require additional types of information. In some cases, the system may generate one or more probabilistic scores, in addition or as an alternative, a sequence of comparative matches between observed information and expected information.

Several aspects of the technology described herein mention that a call center system sends requests for authentication information to a “registered device,” where relying upon registration may be preferable in some circumstances. But in some circumstances, it may not be possible or available. The system may execute various forms of fraud analysis processes to generate one or more predictive probabilistic fraud scores. In this way, patterns of previously and recently received information can be used to predict the likelihood that a device that has originated a current call to the call center is the expected or appropriate device. Devices may be enrolled into, registered with, or otherwise identified by the call center system. In some implementations, the user does not even have to explicitly verify or enroll their identity to call center system. This may be accomplished manually, when a user downloads a mobile application. Enrollment, however, may also be accomplished passively or automatically when the system determines that an unenrolled or otherwise unknown device has provided device identification information with sufficient consistency between data entries and over time.

Illustrative System

FIG.1shows components of a system100configured for call authentication, according to an illustrative embodiment. The illustrative system100comprises a call center system101, caller devices109,110, and an application datastore118. The components of the system100may communicate through one or more communication channels112,114, such as a telephony channel112or data channel114, which may include one or more public and private networks. In operation, callers use the caller devices109,110to place telephone calls to the call center101. When an indication of an inbound telephone call is received at the call center system101, software-based authentication processes are executed to determine whether the caller device109,110is a registered device109with (or otherwise trusted by) the call center101, or whether the caller device109,110is an imposter device110(or otherwise untrusted by the call center101).

It should be appreciated that although one instance of each device is shown inFIG.1, embodiments are not so limited and may include any number of the various devices. In addition, embodiments may implement the various processes and tasks described herein through additional or fewer devices than what are described herein. For instance, other embodiments may incorporate an authentication server104into an enterprise server102and still fall within the scope of this disclosure.

The system100includes any number of communication channels112,114, such as the telephony channel112and the data channel114, which host various types of communication exchanges between caller devices109,110and the call center system101.

The telephony channel112may host device communications that are based on telephony protocols and comprises any number of devices capable of conducting and hosting telephonic communications. Non-limiting examples of components of the telephony channel112may include public exchanges (PBX), telephony switches, trunks, integrated services digital network (ISDN), public switch telephone network (PSTN), and the like.

In operation, the call center system101may receive inbound calls from caller devices109,110via the telephony channel112. Inbound calls may be received at or routed to an enterprise server102, an IVR server108, an agent device116, or other device of the call center system101capable of managing inbound calls. In some cases, devices of the call center system101may capture certain overhead metadata about the caller device109,110or the inbound call, where such metadata is received via the telephony channel112. In addition, the caller may provide information about the caller or the caller device109,110, which is used to, for example, route the inbound call or authenticate the call.

The data channel114may host device communications that are based on non-telephony, inter-device commutation protocols, such as TCP/IP, and comprises any number of devices capable of conducting and hosting networked communications. Non-limiting examples of components of the data channel114may include routers, network switches, proxy servers, firewalls, and the like.

In operation, the call center system101may receive information about the caller device109,110or user inputs via the telephony channel112. As shown inFIG.1, a registered device109may communicate with the call center system101, while imposter device110is unable to because the imposter device110is not properly configured. In some cases, this incapability is due to the imposter device110not having proper configurations, certain locally installed software, or not having certain credentials. In some embodiments, registered devices109execute a software application associated with the call center system101that enables the registered device109to communicate with the call center system101via the data channel112.

The call center system101may prompt callers or caller devices109,110for certain information. In some cases, the requests for the information are verbally provided to a caller during a discussion with the call center agent. The call center agent may then enter the responses into the agent device116, which forwards the responses to the authentication server104. In some cases, requests may also be sent to the caller device109,110via the telephony channel112. For instance, the IVR server108may request the caller to enter or speak certain information. And in some cases, requests may be transmitted to a registered device109via a data channel114. The authentication server104(or other device of the call center system101) uses certain information received in the responses in order to perform various processes, such as authentication or registration.

The call center system101may request various types of information from the registered device109via the data channel114. Non-limiting examples may include a request for a state of the registered device109, a request for one or more attributes of the registered device109or other predetermined types of data, and a request that includes a message notification for the registered user. In some implementations, the message notification may include a push notification that is associated with a mobile application associated with the call center system101. The registered device109may install and execute a mobile application that enables the registered device109to receive and respond to these requests via the data channel114. Because imposter device110will not have the mobile application, the imposter device110may be inhibited from receiving the requests for information or adequately responding to the requests.

As mentioned, some information requests include message notifications sent to the registered device109. The message notifications are configured to elicit a user input via a graphical user interface (GUI) presented on the registered device109. Like several other types of information requests, the message notifications may be sent to the registered device109via the telephony channel112or the data channel114, while responses are received at the call center system101via the data channel114. Message notifications may be in the form of push notifications that are associated with a mobile application executing on the registered device109and generated according to the operating system and protocols of the registered device109. These push notifications are transmitted to the registered device109via the data channel114. The message notification includes a GUI comprising interface elements that prompt the user to select a response. The selected response is then transmitted to the call center system101via the data channel114. Additionally or alternatively, message notifications may be in the form of text messages that are generated according to, for example, short message service (SMS) message protocol, multimedia message service (MMS) message protocol, rich communication service (RCS) message protocol, or the like. These text messages may be transmitted to the registered device109via the telephony channel112according to one or more carrier and device protocols. Text messages may include an interactive link that, when actuated by a user, instructs the operating system of the registered device109to invoke the mobile application. The mobile application is then executed, which presents the GUI having the selectable interface elements. As before, the selected response is then transmitted to the call center system101via the data channel114.

The call center system101is a physical and logical network infrastructure that includes various devices for telephony and data communications with caller devices109,110via the communication channels112,114. The component devices of the call center101may, for example, receive inbound calls, route the inbound calls to appropriate call center agent devices116, and perform various authentication or analytics processes. The devices of the call center system101may communicate with one another through one or more public or private networks of the network infrastructure. In the illustrative system100ofFIG.1, the call center system101comprises the enterprise server102, an authentication server104, a call center database106, the IVR server108, and the agent computing device116.

It should be appreciated that components of the call center system101are described as separate components for ease and clarity. Embodiments may aggregate or parse the operations of the components described into fewer or more components. For example, the enterprise server102may be described as a distinct component from the authentication server104inFIG.1, but other embodiments may partially or entirely incorporate the features of the enterprise server102into the authentication server104.

The enterprise server102may receive call data and manage data flow for inbound calls received at the call center system101and for data communication with mobile applications installed on registered caller devices109. The enterprise server102may be any number of computing devices comprising a processor, device hardware, and machine-readable software and capable of performing the various processes and tasks described herein. Non-limiting examples of the enterprise server102may include a server computer, a desktop computer, a laptop computer, a tablet computer, and the like.

The enterprise server102may be situated as a logical central hub for components of the call center system101. For example, an inbound call received via a telephony channel112may be received by the enterprise server102and routed to the IVR server108or an agent device116. As another example, the enterprise server102could execute various software applications that monitor one or more “legs” of the call lifecycle. In this example, the enterprise server102could trigger or otherwise invoke the authentication server104to authenticate the legitimacy of the inbound call and/or authenticate the caller based on information from the caller device109,110. As another example, software on a monitoring device of the call center system101(e.g., firewall, router, switch, computing device, server) could be configured to detect an inbound call before or after the inbound call is routed to the IVR server108or agent device116. In this example, the monitoring device then initiates a request to the enterprise server102to authenticate the inbound call, caller, or calling device109,110. The enterprise server102may receive and forward the authentication request to the authentication server104. As noted, it should be appreciated that in other embodiments the enterprise server102and the authentication server104could be combined into a single server.

The enterprise server102may receive and manage communications with mobile applications of registered caller devices109via the data channel114. For example, information exchanges between the mobile application of the registered device109and the authentication server104may traverse the various communications networks according to instructions from the enterprise server102. The enterprise server102may detect or trigger processes, such as an authentication or registration process executed by the authentication server104. In some implementations, the enterprise server102may also manage registration operations for new mobile application installations for new registered devices109of the system. In such implementations, the enterprise server102may receive certain types of data associated with a registered device109, and store this data for later use when authenticating calls purportedly originating from the registered device109.

The authentication server104may receive various types of call data of an inbound telephone call for authenticating telephone calls and execution instructions from other devices of the call center system101(e.g., enterprise server102, IVR server108, agent device116). The authentication server104executes various processes for registering and authenticating inbound phone calls received from caller devices109,110. It should be appreciated that the authentication server104may be any number of computing devices comprising a processor, device hardware, and machine-readable software and capable of performing the various processes and tasks described herein. Non-limiting examples of the authentication server104may include a server computer, a desktop computer, a laptop computer, a tablet computer, and the like.

The authentication server104executes machine-readable software instructions for executing authentication routines and registration routines. In operation, the authentication server104receives information about caller devices109,110from various data sources of the system100, such as the enterprise server102, call center database106, IVR server108, agent device116, and caller devices109,110. The authentication server104receives caller identifier information, determines a device identifier associated with the caller identifier, and requests information from the registered device109identified by the device identifier. The authentication server104then determines whether the data of the responses received via the data channel114match expected data values, which may be pre-stored values or dynamically determined by the authentication server104during the call.

Caller identification information includes various types of data values that identify a caller or can be used as part of the identity of the caller. In some cases, caller identification data expressly identify the caller (e.g., name, username, caller identifier) or an aspect of the caller identity (e.g., email address, location); or the caller identification information may include data that can be used to derive or determine the identity of the caller (e.g., passphrase, pin). Non-limiting examples of types of caller identification data may include a name, authentication credentials (e.g., username, password, passphrase, pin), biometric data, account number, account identifier, email address, cryptographic tokens (e.g., encryption keys, encryption certificate, hashed key), social security number, physical address, date of birth, and phone number, among other types of information that can be used to identify a user/caller who is registered with the call center system101and who has purportedly originated an inbound telephone call.

Device identification information includes various types of data values that identify registered device109or can be used as part of the identity of the registered device109. In some cases, device identification data expressly identify the registered device109(e.g., device identifier, computer name, MAC address) or an aspect of the registered device109(e.g., IP address, Automatic Number Identification (ANI)); or the device identification information may include data that can be used to derive or determine the identity of the registered device109. Non-limiting examples of types of device identification data may include a device identifier, a MAC address, an IP address, a system-generated universally unique device identifier (UUID), an identifier for advertising (IDFA), and a Google advertising identifier (AAID), among other types of information that can be used to identify the registered device109that has purportedly originated an inbound telephone call.

Continuing with the authentication server104, in some implementations the authentication server104sends query to the caller device109,110to confirm whether the caller device109,110has a certain mobile application associated with the call center system101. The authentication server104may, for example, transmit a request message to the caller device109,110that the mobile application detects and transmits a brief response accordingly. If the caller device109,110does not have the mobile application, then the authentication server104takes a certain remedial action, such as halting or rejecting the inbound call, routing the inbound call to a call center agent, invoking an alternative authentication process, or executing a registration routine. Additionally or alternatively, the enterprise server102may query a listing or data records of registered devices109having the mobile application associated with the call center system101to determine whether the caller device109,110has the mobile application of the call center system101.

The call center database106may store various data records associated with registered devices109. The call center database106may be updated by the authentication server104or other devices to enroll new registered devices109or queried by the authentication server or other device when executing various authentication processes. The call center database106may be hosted on any number of computing devices comprising a processor, device hardware, and machine-readable software and capable of performing the various processes and tasks described herein.

The database records in the call center database106include various types of data about registered callers and registered devices, such as caller identification information and device identification information. The data records for a registered caller may indicate other information employed by the system100for authentication processes, such as preferred mechanisms for communication (e.g., email, text message) and ways to contact registered device110when transmitting requests for certain information.

The IVR server108is a computing device that manages the data flow for inbound calls that navigate an IVR application, which in the illustrative system100is executed by the IVR server108. It should be appreciated that the IVR server108may be any number of computing devices comprising a processor, device hardware, and machine-readable software and capable of performing the various processes and tasks described herein. Non-limiting examples of the IVR server108may include a server computer, a desktop computer, a laptop computer, a tablet computer, and the like.

In operation, when the caller initiates a call to the call center system101, the inbound call traverses over the telephony channel112and is routed to the IVR server108. The IVR server108can determine how to route the inbound call, such as determining which call center agent should handle the content of the call. In some cases, the IVR server108can capture and forward certain information that can be employed for authentication purposes. For example, the IVR server108may prompt the caller to input certain caller identification information, which may indicate who the caller purports to be.

It should be noted that in some embodiments, the system100does not include an IVR server108. Rather, inbound calls may be routed directly to an agent device116. Similarly, even for embodiments comprising an IVR server108, in some circumstances the nature or content of the inbound call may forgo the IVR server108and the inbound call may be routed directly to an agent device116.

The agent device116is a computing device operated by an agent of the call center system101to handle inbound calls. The agent device116may include a GUI configured to display information gathered by the IVR server108(or any other devices) that routed the inbound call from the telephony channel112to the agent device116. This information may include data fetched from the database106, data entered by the caller during an IVR application, or data extracted from the overhead metadata of the telephony channel112. Additionally or alternatively, the GUI may display information fetched by the agent device116from the database106or entered by the agent. In some cases, the agent device116may be used to manually initiate an authentication request, which the agent device116transmits, along with various types of information, to an authentication server104or enterprise server102.

An agent device116may be any computing device comprising a processor, device hardware, and machine-readable software and capable of performing the various processes and tasks described herein. Non-limiting examples of the agent device116may include a server computer, a desktop computer, a laptop computer, a tablet computer, and the like.

The application datastore118may be a data service from which caller devices109,110may download and install a mobile application associated with the call center system101. In some cases, the datastore118may be hosted by public data service, such as Apple App Store® or Google Play®. And in some embodiments, the datastore118is a private data service hosted on a privately available application server. In operation, caller devices109,110may navigate to, for example, a web-based address for the datastore118from which caller devices109,110may download the mobile application.

Caller devices109,110can be any electronic device comprising a processor and software, and capable of performing the various tasks and processes described herein, which includes the capability of communicating with a call center system101via a telephony channel112and via a data channel114. A caller device109,110could be, for example, a cellular phone (sometimes called a “smartphone” or “mobile phone”), a tablet device, a laptop computer, or any other computing device. It should also be appreciated that in some instances, the telephony channel includes voice-over-IP (VoIP) communications as initiated and executed by the caller device109,110. It should be appreciated that embodiments are not necessarily limited to mobile applications or mobile electronic devices, but may rather include fixed devices (e.g., laptop computer, desktop computers), telephones (e.g., unified communications phones, application and VoIP-enabled telephones), or telephony software (e.g., softphone) executed on a fixed device.

Authentication

FIG.2shows execution steps of an illustrative method200for authenticating a phone call using multiple communication channels, according to an embodiment. In the illustrative method200, a caller places a telephone call to a call center system that executes various processes to authenticate the telephone call. The call center system includes one or more databases containing database records with information about users or devices registered with the call center system. The caller of an inbound call provides information that indicates the caller purports to be a registered user.

It should be appreciated that additional or alternative devices may be implemented to execute the various steps of the illustrative method200. In addition, the illustrative method200is described as using two communication channels, though other embodiments may implement more. It should be further appreciated that other embodiments may include additional or alternative steps, or omit certain steps, from those shown inFIG.2and still fall within the scope of this disclosure. Although the steps of the method200are described as being executed by the authentication server, is should be appreciated that additional or alternative computing devices may be involved in executing the various steps.

In step202, an authentication server of a call center receives an indicator of an inbound phone call received at the call center through a first communication channel, such as a telephony channel. The indicator may be an event or data that triggers the server to execute various authentication processes, which are based upon responses received from caller devices through a second communication channel. The indicator can include information (e.g., name, address, account number, caller identifier) about the caller or the caller device that the authentication server references for later steps of the method200.

In some embodiments, the call indicator may be a user input, entered by the caller, call center agent call center, or another end-user. The caller, purporting to be a registered user of the call center system, could enter or provide information about the caller, caller device, or registered user. The caller can provide such identifying information to an IVR server or call center agent, via the telephony channel, through spoken interactions or keypresses at the caller device. The IVR server or call center agent may invoke the authentication server to execute various authentication processes using the information provided by the caller.

The call center system receives a caller identifier with the call indicator. The authentication server may use the caller identifier to later determine a device identifier, as in step204. In some cases, the caller identifier may be received at the IVR server based on caller inputs responding to IVR prompts. For instance, the caller identifier may be a user name, account number, or other identifying data that the caller enters in response to IVR prompts. The IVR server may then forward that information to the authentication server. In some cases, the caller identifier may be received as a function of the telecommunications systems, carriers, and protocols. For example, a caller identifier may be the Caller ID metadata, the ANI, or any other type of telecommunications overhead metadata. And in some cases, the caller identifier may be entered by a call center agent. As mentioned, the call center agent may receive the inbound call directly or through an IVR system and enter the caller identifier data into a GUI according to the verbal information conveyed by the caller. At some point in the conversation, the call center agent may manually submit the ongoing call to the authentication server and instructions to execute the authentication processes.

The caller identifier may be explicit in the call indicator (or other data received by the call center system) or the authentication server must determine the caller identifier using the information received by the call center system. For example, the information received from the caller through the telephony channel may be an encrypted, hashed, or other type of encoded version of the caller identifier. The authentication server may apply the appropriate algorithms to derive the caller identifier from the information provided. As another example, the information received may include a database value that maps to database of record of the registered user containing the caller identifier. For instance, the information received via the telephony channel may include a password, passphrase or passphrases, pin, or hash of predetermined information, which the authentication server uses to query the database for the caller identifier.

In some embodiments, such as the illustrative method300ofFIG.3, the call center system employs multi authentication processes. For instance, the call center system may implement an optional precursor authentication process prior to the method200ofFIG.2. With respect to step202, a successful authentication of the inbound call during a preceding authentication process may effectively serve as a call indicator that triggers the following steps of the method200ofFIG.2.

In step204, based on the caller identifier, the authentication server identifies a device identifier for a registered device associated with the registered user. A database record, such as a database record for the registered user, can include a device identifier that identifies a device registered to, or otherwise previously associated with, the registered user. When the authentication server identifies the caller identifier for the registered user, as in step202, the authentication server then identifies or otherwise determines the device identifier associated with that registered user.

In step206, the authentication server transmits one or more authentication requests to the registered device according to the device identifier. The authentication requests, transmitted by the authentication server, may be requests for certain types of information about the registered device. Non-limiting examples may include requests for the state of the device, requests for certain attributes about the device, or a message notification configured for human interaction through a GUI of the registered device. For instance, during an enrollment process, the authentication server may receive or generate certain types of data associated with the registered device (e.g., MAC address, UUID) or the registered user (e.g., user credentials), which are then stored as attributes of the device into the database.

The authentication requests may be transmitted through a telephony channel or through a data channel. As mentioned, a message notification may include an app-based push notification configured to be displayed by a mobile application installed on the registered device. Such push notifications are transmitted through a data channel. When the registered user clicks the push notification or otherwise executes the mobile application, the mobile application presents a GUI comprising one or more GUI elements prompting the registered user to input whether the registered user is involved with the current inbound call. Additionally or alternatively, the message notification may be an SMS or MMS (collectively, “text message”) that the authentication server or other device of the call center system transmits via a telephony channel. The text message may include a clickable link instructing the mobile device to invoke the locally-executed mobile app. When the registered user clicks the link, the mobile application is executed and a GUI is presented with a GUI element, which could be a confirmation element, allowing the registered user to input and confirm whether the registered user is involved with the current inbound call.

The authentication requests may further include requests for certain information about the registered device, such as the device state or other predetermined types of data that were captured or generated during an enrollment process for the registered device. During authentication, the mobile application may gather the corresponding information by, for example, querying the local storage or software program logically situated on top of the operating system of the registered device (e.g., middleware capable of retrieving information from the operating system on behalf of the mobile application). For example, the local storage may contain a UUID assigned to the mobile application during registration and the operating system or other firmware component of the registered device may indicate (for the mobile application) the state of the caller device during the call.

In step208, the authentication server receives, from the registered device, responses to each of the authentication requests via the second communication channel (e.g., a data channel). As mentioned, the registered device executes a mobile application associated with the call center system. The mobile application may, for example, gather certain information according to the requests from the local storage or operating system of the registered device and receive a user input via a GUI, and then transmit the responses to the authentication server via the second channel.

In step210, the authentication server executes a software-based authentication routine that uses the responses received from the registered device in order to authenticate the inbound call. The responses may include responses to the message notification, responses to the state requests, and responses to the attribute requests. The authentication server may compare the response information against the expected information to determine whether the information matches. If the information fails to match, then the authentication fails.

The authentication server may determine there is a match according to one or more algorithmic operations. In some embodiments, a match is identified based upon straightforward comparisons of the data in the responses against the expected data values. In such embodiments, the amount of matching data may vary. For example, the authentication server may implement a strict threshold requiring that each of the compared data values match or that certain critical data values match. As another example, the authentication server may implement a less-stringent threshold that requires some threshold number of matches, thereby allowing for some number of mismatches or variations.

In some embodiments, a match is based upon heuristic or threshold scoring rules. In such embodiments, a score may be assigned to certain identified matches based upon the criticality of the data field and/or based upon the precision of the match. The scores maybe may combined according to one or more mathematical operations into a matching score. If the matching score satisfies a threshold, then the authentication server has determined the values in the response match the expected values.

In some embodiments, the authentication server may apply one or more machine-learning algorithms for determining whether the data in the responses matches expected data. In such embodiments, the data values received from the registered device may be employed for training a machine-learning model or for various operation related to developing the model. Models may be generated and trained for each particular registered caller and/or for categories of callers, using supervised or unsupervised machine-learning algorithms. As an example, feature vectors for each of the registered users can be generated from the data records of registered users, which, in some cases, could include a label indicating that the feature vector is associated with the registered user. The models can be trained against one or more feature vectors of one or more registered users according to the particular types of data being modeled. For instance, certain personalized user identifying information (e.g., social security number, UUID) can be used to generate and/or train models for a particular registered user; and certain categorical user identifying information (e.g., carrier, country location) can be used to generate and/or train models for a collection of registered users. A feature vector can likewise be extracted from the data values received from the inbound call associated with the caller. The one or more trained models can be applied to the feature vector extracted for the caller to generate a score. If the score satisfies a threshold, then the caller is determined to be the registered user. Additionally or alternatively, the authentication server may apply clustering techniques to certain data values of the registered user to identify the types of data critical to the authentication when generating/updating the feature vector for the registered user to train the model for the registered user. Clustering may also be implemented, additionally or alternatively, to determine an authentication score by determining whether the distance from clustered data values or feature vector extracted for the registered user satisfies a threshold from the data values or feature vector extracted for the caller.

It should be appreciated that these examples of authentication based upon the data of the registered user and the caller are merely illustrative and non-limiting. Variations or well-known algorithmic approaches for authentication using such data may be within the scope of this disclosure.

The response to the message notification is a user input that indicates whether the registered user is actually the caller who initiated the inbound call. If the user input indicates that the registered user did not initiate the call, then the authentication fails.

In optional step212, the authentication server authenticates the inbound phone call when responses match expected values and include an affirmative response to message notification. The authentication server may route the call according to the context in which the method200was invoked. For example, the authentication routine may be invoked prior to routing the call to an IVR server or agent. In this example, upon successful authentication, the call is routed by the authentication server or other device of the system to the IVR server or agent. In another example, the authentication routine may be invoked by an instruction inputted at an agent device. In this example, the upon successful authentication, a successful authentication notification may be provided to the GUI of the agent device or the inbound call may be reinitiated and routed back to the agent device.

In optional step214, the authentication server may take remedial action when the responses either fail to match expected values or a negative response to message notification is received. The remedial action may include dropping the call, rejecting the call from further routing, routing the call to an agent or fraud analyst, re-attempting the authentication routine using the same or different attributes, or attempting a different technique for authenticating the call.

FIG.3shows execution steps of an illustrative method300for authenticating a phone call using multiple communication channels, according to an embodiment. In the illustrative method300, a caller places a telephone call to a call center system that performs multiple authentication processes in order to authenticate the telephone call. The inbound call is then authenticated using multiple iterations of call authentication processes. In the second authentication process, responses are received via the data channel and include a response to a message notification displayed at the client-side GUI.

It should be appreciated that additional or alternative devices may be implemented to execute the various steps of the illustrative method300. In addition, the illustrative method300is described as using two communication channels, though other embodiments may implement more. It should be further appreciated that other embodiments may include additional or alternative steps, or omit certain steps, from those shown inFIG.3and still fall within the scope of this disclosure.

In step302, the call center system receives an inbound phone call via a telephony communication channel. The call may be routed from the telephony channel to an IVR system or agent device. At a predetermined triggering event, such as when the inbound call is received, the caller may be prompted, through the telephony channel, to provide certain authentication information for a first authentication process. Additionally or alternatively, a state of the device may be queried by an authentication server.

In step304, an authentication server receives the response information for the first authentication process. These responses may be received via the telephony channel or via a data channel. These responses may include user credentials or simplified caller identification information. In some case, these responses further include the current device state.

In step306, the authentication server executes a first authentication routine using the state of the device and the caller identification information received in the first set of responses. The authentication server may compare the information received in the first set of responses against pre-stored or expected information, then the authentication server authenticates the phone call for a first level. If the call fails the first authentication process, the authentication server may invoke one or more remedial processes and prevents the call from proceeding.

In step308, the authentication server (or other device of the call center system) identifies an event triggering a second authentication process. A triggering event may include, for example, a caller's attempt to access sensitive data, a caller's attempt to perform a sensitive process, or at a predetermined timing interval after the first authentication process.

In step310, the authentication server transmits requests for authentication information to the registered device. These requests may be transmitted through the telephony channel or the data channel, and may include requests for the same or different authentication information. In addition, the second round authentication process includes a request comprising a message notification configured to be displayed at a GUI of the registered device and to receive a user input indicating the response.

In some implementations, the information received for the first authentication process may be employed for preparing the requests of the second authentication process. For example, credentials used to authenticate call for the first authentication process may include caller identification information, which the authentication server uses to fetch the device identification information or other data related the registered caller.

In step312, the authentication server receives the second set of responses to the second round of requests via the data channel. As mentioned, the registered device executes a mobile application associated with the call center system. The mobile application may, for example, gather certain information according to the requests from the local storage or operating system of the registered device and receive a user input via a GUI, and then transmit the responses to the authentication server via the second channel.

In step314, the authentication server executes the second authentication routine using the responses received via a data channel. The responses may include responses to the message notification, responses to a second state request, and responses to requests requiring the same or different attributes. The authentication server may compare the second set of response information against expected information to determine whether the second round of information matches. If the information fails to match, then the second authentication routine fails.

A response to the message notification is a user input that indicates whether the registered user is actually the caller who initiated the inbound call. If the user input indicates that the registered user did not initiate the call, then the authentication fails.

If the authentication server authenticates the inbound phone call in the second authentication process, when responses match expected values and include an affirmative response to message notification, then the authentication server may route the call according to the context in which the method300was invoked.

If the authentication server determines that the authentication fails, when the information in the second set of responses either fail to match expected values or a negative response to message notification is received, then authentication server may take remedial action. The remedial action may include, for example, dropping the call, rejecting the call from further routing, routing the call to an agent or fraud analyst, re-attempting the authentication routine using the same or different attributes, or attempting a different technique for authenticating the call.

FIG.4shows execution steps of an illustrative method400in the context of device components, according to an embodiment.FIG.4shows that certain execution steps are executed by an authentication server401of a call center system, while other executed steps are executed by a mobile device403(sometimes referred to as a “caller device”).

In the illustrative method400, a user initiates a call from a mobile device403. The call reaches the carrier of the mobile device403and then transferred to the carrier of a call center enterprise. In some circumstances, the carriers may be the same; and in some circumstances, there may be one or more carriers involved with the call. The call may be received at an enterprise server, which may be configured to initiate an authentication request for an authentication server401to authenticate the call before the call is answered at an IVR server. Although the illustrative method400mentions that authentication is initiated before the call is answered at the IVR server, it should be appreciated that this is not limiting on other embodiments. The authentication, among other operations, may be initiated or otherwise occur before or when the call is being handled at the IVR server. For instance, in some circumstances the programmatic hooks for the IVR server to execute various processes are not present before the call arrives at the IVR server. In such circumstances, the authentication might not be initiated before the call is answered at the IVR server, but rather when the IVR server has received and is handling the call. These cases nevertheless fall within the scope of this disclosure.

In step402, an inbound telephone call arrives at the authentication server401from an enterprise server. The enterprise server may extract certain information about the call, which is sent to the authentication server401with the authentication request. For example, the ANI and other metadata may be extracted from the incoming call and is sent to the authentication server401. Additionally or alternatively, the authentication server401receives an account identifier (account ID) along with the authentication request for the call. In some cases, the authentication server401uses the ANI as the account ID.

In step404, the authentication server determines whether the account ID is associated with a particular device identifier (device ID) in a database. The authentication server401may use the ANI (or another type of data) as an account ID to check if there are any device identifier(s) in the database.

In some implementations, the authentication server401retrieves one or more device ID associated with that account ID and may use the device ID to sends queries to a mobile application of the mobile device403to check the call states of the mobile device403. Additionally or alternatively, the authentication server may extract other stored metadata, such as a device timestamp, timezone, device ID, location, WIFI, Bluetooth, International Mobile Equipment Identity (IMEI), network or carrier information, and security information (lock/unlock feature bits indicating whether the device is locked or unlocked), among other types of data. This information may be transmitted to a fraud analysis program, which is described with respect to steps418-420.

Referring back to step404, the authentication server may determine one or more type of authentication functions to be employed. In some implementations, the database record for the account ID or the enterprise server may establish a default policy for a certain authentication function, which the authentication server401can consider when determining the type of authentication function to implement. As shown inFIG.4, there are three potential authentication functions to be executed, which may be selected based on various factors, such as the capabilities of the mobile device403, recent communications or authentication attempts between the authentication server401and mobile device403, or a predetermined policy for the registered user. A first authentication (type 1) function and second authentication (type 2) function transmits a message notification to the mobile device403, prompting user interaction via a GUI of the mobile device403. A third authentication (type 3) function determines whether the mobile application of the mobile device403has recently transmitted authenticating data to the authentication server401.

In optional step406, the authentication server401initiates a type 1 authentication function, in which the authentication server401transmits a message notification prompting a user interaction via a GUI display of the mobile device403. In step412, the mobile application determines whether the user clicked “approve” to the request prompt. It should be appreciated that embodiments are not limited to those indicating “approve” on the GUI but may further include any GUI element capable allowing the user to select and enter an affirmative response to the prompt displayed via the GUI. In step414, the mobile application gathers call state or device state data, and other attribute data about the mobile device403. As shown in step416, the mobile application comprises an executable service that monitors outgoing calls. The call monitoring server continuously or periodically captures the call state or device state data, as well as other attribute data. This captured data may be stored for later transmission to the authentication server401in step414.

In optional step408, the authentication server401initiates a type 2 authentication function, in which the authentication server401transmits a message notification prompting a user interaction via a GUI display of the mobile device403. In a type 2 authentication function, there is no affirmative response available for the user to select; only an option to report fraud to the authentication server401or other device of the call center system. As such, the authentication server401is not awaiting a response from the mobile device403before proceeding with the authentication processes.

In optional step410, the authentication server401initiates a type 3 authentication function, in which the authentication server401determines whether there is recently received authentication information that is stored in a memory or cache of the authentication server401or other device of the call center system. Authentication information may be stored in a database or other memory and each data entry comprise or be assigned a timestamp. If recent authentication information was received within a time threshold, then the authentication server401may use such data for authentication purposes in later steps of the method400.

In step418, the authentication server401uses the various types of authentication information received as responses or otherwise available to the authentication server401to execute a programmatic fraud analysis process. The fraud analysis process references the current authentication information to execute one or more algorithms that generate a predictive authentication score for the call. In some implementations, fraud analysis process further retrieves and uses historical data, which may include type 3 data or other data received from the mobile device403. Is should be appreciated that, in various embodiments, the risk score may also be computed using historical data and/or previously determined reputation information received from a reputational database, which stores data records containing reputation data indicating the riskiness of the caller according to the identifying information of the caller. Additionally or alternatively, a risk analysis engine may generate a risk score the call based upon the historical data, metadata, and/or reputation data generated, received, or extracted from the various data sources. The authentication server401may generate an authentication score based upon the data obtained from prior step404(e.g., device states, device metadata); and may further generate a risk score using the data obtained from the mobile application of the mobile device403and the historical data. In step420, the authentication server401uses the risk score and the authentication score to generate a final score.

In optional step422, the authentication server may execute an enrollment procedure after executing the authentication processes. When a caller has been authenticated, the authentication server or enterprise server may enroll the user passively, so that for future calls the user can be authenticated passively without user interaction. After the user has been authenticated, the authentication server references the call states of the call or the mobile device403previously or make another request to the mobile device403to retrieve the call state. The authentication server401may compare the received call state against the expected call state, as determined by the authentication server401or received from the enterprise server or other device of the call center system. In some implementations, the authentication server401may check for state transition with the enterprise server. For example, the enterprise server may put the user on hold (e.g., “hold” call state) and instruct the authentication server to query the state of the mobile device403to determine whether the mobile device403was on hold (e.g., “hold” device state). The enterprise server may later remove the user from hold (e.g., “active” call state) and instruct the authentication server401to query whether the state of the device changed accordingly. If there is a strong correlation, then the user and the device may be enrolled. Non-limiting examples of call authentication using call states can be found in U.S. patent application Ser. No. 16/287,879, entitled “Silent Caller ID Verification Using Callback Request,” filed Feb. 27, 2019, which claims priority to U.S. Provisional Application No. 62/640,826, filed Mar. 9, 2018, each of which is incorporated by reference in its entirety.

In step424, the authentication score or a result derived from the authentication score is transmitted to the enterprise server or other device of the system. The enterprise server or the authentication server may then approve or deny authentication for the current inbound call based on whether the final score and/or the information obtained from the authentication server401satisfies a threshold score value, amount of information, or another threshold metric.

With reference to step404, in some embodiments, the authentication server or enterprise server is configured to disallow authentication where no device ID is found in the database. If the authentication server cannot retrieve the device ID against the queried account ID sent by the enterprise server, then the authentication server401concludes the caller device is not enrolled and registered. The authentication server can generate and respond to the enterprise server with a risk score that will fail an authentication threshold.

FIG.5Ashows an illustrative message notification500adisplayed at a GUI of a mobile device. The message notification500aincludes a GUI having two user interface elements. A first GUI button to indicate an affirmative authentication response from user, thereby indicating the authentication request should proceed, and a second GUI button to, for example, report fraud or otherwise indicate a negative authentication response. Each of these buttons transmits a response to authentication server, which the authentication server uses when determining whether to authenticate a call made to a call center system.

FIG.5Bshows an illustrative message notification500bdisplayed at a GUI of a mobile device. The message notification500aincludes a GUI having one user interface element: a GUI button to allow the user to indicate report fraud or otherwise indicate a negative authentication response. If the user actuates the report fraud button, the mobile devices transmits a response to authentication server, which the authentication server uses when determining whether to authenticate a call made to a call center system. The report fraud button may automatically or by weighted value for scoring deny authentication of the call and trigger the authentication server or enterprise server to execute various remedial process. If the user does not enter a response, because the user does not object to the content of the message notification500b, then the server may automatically determine an approval was received from the user after a threshold amount of time.

Enrollment

FIGS.6A-6Brelate to an illustrative embodiment for enrollment.FIG.6Ashows execution steps of an enrollment method600aandFIG.6Bshows information flow among components of a system600baccording to the illustrative embodiment. It should be appreciated that embodiments may include additional or alternative steps, or may omit steps, from those shown inFIG.6A, but still fall within the scope of this disclosure. It may likewise be appreciated that components of the system600bmay be incorporated or distributed into more or fewer devices from those components shown inFIG.6B.

In step602, a mobile device615downloads and installs an application617associated with a call center. The downloaded application617may be a new installation of the application617, a re-installation of the application617, or an update to a previously installed instance of the application617. The mobile device615may download the application617from an application source613. In some implementations, the application source613may be a datastore hosted at an application server or other enterprise server619of an enterprise infrastructure; and in some implementations, the application source613may be a datastore hosted on a server of a third-party application service (e.g., Apple App Store®, Google Play®).

In step604, the user operating the mobile device615enters login credentials into the application617to access a user account or other service requiring authentication. Non-limiting examples of the credentials may include a password, PIN, biometric data, and private/public keys, among others.

In step606, the mobile device615transmits the login credentials to an enterprise server619. In step608, the enterprise server619sends one or more ANIs of the mobile device615, a device ID of the mobile device615, and other types of metadata to an authentication server621. In some implementations, these credentials are transferred from the enterprise server619to the authentication server621along with a device ID (e.g., MAC address, UUID, IDFA, Google AAID), an account ID, and any registered ANIs that may be on file for the account in a database.

An account ID may be any type of data that can be used by a server of the system to query a database, for example, in order to retrieve an authentication score of a call involving the user. Non-limiting examples of the account ID may be a phone number, account number, email address, or some form of a hashed key.

In step610, the authentication server621registers and stores the authenticating data into a data record for the user account. The data record is stored within a user database, which may be hosted on the authenticating server621or other computing device of the enterprise infrastructure.

FIGS.7A-7Brelate to an illustrative embodiment for enrollment.FIG.7Ashows execution steps of a method700aenrollment andFIG.7Bshows information flow among components of a system700baccording to the illustrative embodiment. It should be appreciated that embodiments may include additional or alternative steps, or may omit steps, from those shown inFIG.7A, but still fall within the scope of this disclosure. It may likewise be appreciated that components of the system700bmay be incorporated or distributed into more or fewer devices from those components shown inFIG.7B.

In step702, a mobile device715downloads and installs an application717associated with a call center. In step704the user operating the mobile device715enters login credentials into the application717to access a user account or other service requiring authentication. In step706, the mobile device715transmits the login credentials to an enterprise server719. In step708, the enterprise server719sends ANI and device ID to an authentication server721. In step710, the mobile device715sends other metadata to the authentication server712. In step712, the authentication server721registers and stores data in record of user account.

FIGS.8A-8Brelated to an illustrative embodiment for enrollment.FIG.8Ashows execution steps of a method800aenrollment andFIG.8Bshows information flow among components of a system800baccording to the illustrative embodiment. It should be appreciated that embodiments may include additional or alternative steps, or may omit steps, from those shown inFIG.8A, but still fall within the scope of this disclosure. It may likewise be appreciated that components of the system800bmay be incorporated or distributed into more or fewer devices from those components shown inFIG.8B.

In step802, a mobile device815downloads and installs an application817associated with a call center. In step804the user operating the mobile device815enters login credentials into the application817to access a user account or other service requiring authentication. In step806, the mobile device815transmits the login credentials to an enterprise server819. In step808, the enterprise server819sends an ANI and device ID back to the mobile device815. In step810, the mobile device815sends the ANI, the device ID, and other metadata to an authentication server821. In step812, the authentication server821registers and stores the user authenticating data in a user record for the user account.

The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

Embodiments implemented in computer software may be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

The actual software code or specialized control hardware used to implement these systems and methods is not limiting of the invention. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description herein.

When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module which may reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.

The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.