Omni Channel Authentication

This application is a continuation of U.S. application Ser. No. 18/235,321, filed Aug. 17, 2023, which claims priority to U.S. Provisional Application No. 63/399,132, filed Aug. 18, 2022, each of which is incorporated by reference in its entirety.

This application generally relates to systems and methods for managing security protocols and authentication operations in enterprise systems in which end-users access services or agents of the enterprise system through multiple communications channels or various type of communications devices.

Oftentimes, a user requires some assistance from a customer support specialist when operating or accessing a web application or mobile application of an enterprise's service (e.g., online banking application). This activity frequently involves two or more communication channels between the user and the enterprise, such as a data-related channel between the user's device and the enterprise server (for the application data) and a telephony channel for the conversation between the user and the support personnel. A problem arises in servicing the user when switching from one channel to another. Typically, when the user reaches a customer support agent, the support agent asks the user for identification information, verifies the user identity, performs certain processes to authenticate the user, and captures the reason for user's call. But when the communication channel changes from an online channel to a telephone channel (or vice-versa), the relevant enterprise systems might lose some or all of the identity, authentication, and context information collected for one or more channels associated with the user. This is an unpleasant, wasteful, and poor experience for the user.

Prior authentication management solutions implemented omni-channel solutions that perform certain identity management operations to maintain the authentication across channels. However, these prior approaches require an integrated suite of software solutions to properly interact with one another. These conventional approaches presume and require a common ecosystem of products, but that has limitations and are becoming increasingly impracticable in view of growing amounts of disparate technologies in the enterprise systems and employed at the client-side. These approaches operate within the confines of the common software ecosystem or suite of products to figure out how to do a handoff between a proprietary chatbot and proprietary voice-based webpage application. For example, the enterprise system would have to adopt and employ the same vendor's solutions for authentication and identity management across the communication channels (e.g., website or portal login solutions; chatbot solution; voice-based communication solution).

Demanding this level of integration raises several identifiable, expected, and unforeseen issues for the enterprise system. Migration to or adoption of new vendor solutions would be inhibited due to, for example, technical incompatibility, adaptation-development costs and time.

Disclosed herein are systems and methods capable of addressing the above-described shortcomings and may also provide any number of additional or alternative benefits and advantages. Embodiments include a computing device that executes software routines and/or one or more machine-learning architectures providing improved omni-channel authentication solutions. Embodiments include one or more computing devices that provide an authentication interface by which various communication channels may deposit contact or session data received via a first-channel communication session into a non-transitory storage medium of an authentication database for another channel to obtain and employ (e.g., verify users). This allows the customer to access an online data channel and enter the contact center through a telephony communication channel, but further allows the enterprise contact center system to passively maintain access to various types of contextual information (e.g., identity, authentication, context) about the user's identity and other information about or captured from each contact channel, allowing the call center to request or capture authenticating information (e.g., voice biometrics) from both channels to employ authentication processes for one or both channels, such as voice biometrics authentication processes or other types of authentication functions.

In an embodiment, a computer-implemented method comprises receiving, by a computer, an auth-trigger notification from a data server of an enterprise service provider network, the auth-trigger notification including an intermediate identifier associated with an end-user and an enrolled phone number expected for a telephony device associated with the end-user; generating, by the computer, a session record including the intermediate identifier and the enrolled phone number; receiving, by the computer from a telephony server of the enterprise service provider network, inbound call data for an inbound call and an authentication request for an inbound call; generating, by the computer, an inbound voiceprint for the inbound call by applying a machine-learning architecture on the inbound call data; and generating, by the computer, a confidence score for the inbound call based upon a distance between a stored enrolled voiceprint associated with the intermediate identifier and the inbound voiceprint.

In another embodiment, a computer-implemented method comprises receiving, by a data server associated with an enterprise service provider network, authenticating information for an end-user from a client device via a data channel; transmitting, by the data server, to an authentication server associated with an authentication database, an auth-trigger notification including an intermediate identifier for the end-user associated with the data channel; receiving, by a telephony server associated with the enterprise service provider network, inbound call data from a caller device via a telephony channel; transmitting, by a telephony server associated with the enterprise service provider network, to the authentication server an authentication request including inbound call data received via the telephony channel; receiving, by the telephony server from the authentication server, an authentication response containing authentication results including a confidence score indicating a distance between an enrolled voiceprint associated with the intermediate identifier for the end-user associated with the data channel and an inbound voiceprint generated for the inbound call data received via the telephony channel.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.

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.

1 1 FIGS.A-C 1 1 FIGS.A-C 100 103 103 103 103 100 101 110 114 114 114 114 100 105 a d a d show various arrangements of components of a systemfor receiving and analyzing voice biometrics and other types of information received via various types of communication channels-(collectively referred to as “channels” or a “channel”). The systemcomprises an analytics system, one or more provider systems, and any number of end-user devices-(collectively referred to as “end-user devices” or an “end-user device”). The systemfurther includes hardware and software components for an identity management service, shown as an identity serverin.

101 114 110 101 102 106 102 110 110 111 111 111 111 111 111 114 111 114 114 111 111 111 116 a b b a a b a b a The analytics systemincludes hardware and software components for performing various analytics operations for recognizing and authenticating end-users or end-user deviceson behalf of the provider system. The analytics systemincludes, for example, an analytics serverthat performs the analytics operations and an analytics databasethat stores various types of data (e.g., call data, enrolled user data, device data) referenced by the analytics serverwhen performing the analytics operations. The provider systemincludes hardware and software components for hosting or providing the end-users various service offerings or customer support. The provider systemincludes, for example, an enterprise telephony serveror enterprise data server(collectively referred to as “provider servers” or a “provider server”), among other types of provider serversor devices. For instance, the enterprise data serverincludes hardware (e.g., processor) and software (e.g., webserver) for hosting or executing online data services, which an end-user accesses using a particular end-user devicehaving a web browser or other mobile or software application. The enterprise telephony server, for example, includes call center management software for receiving inbound telephony calls placed by the end-user using a telephony device or telephony software (e.g., landline phone, mobile device). The enterprise telephony serverextracts various types of call data, generates user interface prompts, receives and processes responses to the prompts, and routes the calls to the appropriate call center agent or instructs another device (e.g., enterprise data server) to perform a certain operation. The enterprise telephony servercould route the call and the call data to an agent device, which displays the call data to the agent.

1 FIG.A 100 121 101 110 121 110 101 121 110 110 103 121 105 101 110 121 107 114 114 111 In, the systemcomprises an identity service systemis a distinct enterprise infrastructure from both the enterprise infrastructures of the analytics systemand the provider systemand is often operated or managed by an identity and access management (“IAM” or “IdAM”) service (e.g., Forge Rock®, Okta®). The identity service systemincludes hardware and software components for performing various IAM operations on behalf of the provider system. As described herein, the analytics systemand identity service systemoperate in concert to identify and authenticate the end-users for the provider system, particularly when the end-users access the provider systemvia multiple channels. The identity service systemincludes an identity serverthat hosts and executes the various IAM operations using data inputs received from the analytics systemand provider system. In some cases, the identity service systemincludes an authentication database, which stores various types of data about the end-users, the end-user devices, or channel sessions established between the end-user devicesand the provider servers.

101 110 121 101 105 107 102 105 101 105 102 106 107 100 110 105 107 111 105 110 105 111 112 107 1 FIG.B 1 FIG.C In some embodiments, the analytics systemor the provider systemincorporate and perform various features and functions of the identity service system. In, for example, the analytics systemincludes the identity serverand the authentication database. In some implementations, the analytics serverincorporates and performs the features and functions of the identity server, such that the analytics systemneed not include the identity serverdistinct from the analytics server. Similarly, in some implementations, the analytics databaseincorporates and performs the features and functions of the authentication database. As another example,depicts another arrangement of the systemembodiment in which the provider systemincludes the identity serverand the authentication database. As before, in some implementations, one or more provider serversincorporates and performs the features and functions of the identity server, such that the provider systemneed not include the identity serverdistinct from the provider servers. Similarly, in some implementations, the provider databaseincorporates and performs the features and functions of the authentication database.

1 FIG.A 1 FIG.A 1 FIG.A 100 110 101 102 102 106 106 102 Turning back to, embodiments may comprise additional or alternative components or omit certain components from those of, yet still fall within the scope of this disclosure. It may be common, for example, for the systemto include multiple provider systems, or for the analytics systemto have multiple analytics servers. Embodiments may include or otherwise implement any number of devices capable of performing the various features and tasks described herein. As an example,shows the analytics serveras a distinct computing device from the analytics database, though in some configurations, the analytics databasemay be integrated into the analytics server, such that these features are integrated within a single device.

103 110 114 110 103 110 111 103 110 114 103 The channelsfacilitate communications between the provider systemand the end-user device, whenever the user accesses and interacts with the services or devices of the provider systemand exchanges various types of data or executable instructions. The channelsallow the end-user to access the services, service-related data, and/or user account data hosted by components of the provider system, such as the provider servers. Each channelincludes hardware and/or software components for hosting and conducting the communication exchanges between the provider systemand the end-user devicecorresponding to the channel.

114 114 110 103 114 114 114 114 114 100 114 114 114 114 114 110 103 103 103 103 114 a b c d a b a e a a The end-user deviceincludes any type of electronic communications device capable of performing the various tasks or processes described herein. Using the end-user devices, the user accesses and interacts with the services and data hosted by the provider systemvia the corresponding channels. Non-limiting examples of the end-user devicesinclude a landline phone, a mobile device, a computing device, and an Internet-of-Things (IoT) device. Other embodiments of the systemor the end-user devicemay include other types of end-user devices. In some cases, the end-user deviceincludes a telephony-centric device (e.g., landline phone, mobile device) that the user operates to access the services of the provider systemthrough a telephony-centric channel(e.g., landline channel, mobile telephony channel) which includes hardware and software of telephony networks and communications (e.g., telecommunication network, POTS, cellular telephone network). The telephony channel (e.g., landline channelassociated with the landline phone) may include telephony and telecommunications protocols, hardware, and software capable of hosting, transporting, and exchanging audio data associated with telephone calls. Non-limiting examples of hardware components for telephony-centric networks include switches and trunks, among other additional or alternative hardware used for hosting, routing, or managing telephone calls, circuits, and signaling. Non-limiting examples of software and protocols of telephony-centric networks include Skype®, Zoom®, VOIP, SS7, SIGTRAN, SCTP, ISDN, and DNIS among other additional or alternative software and protocols used for hosting, routing, or managing telephone calls, circuits, and signaling. Components for telecommunications may be organized into or managed by various different entities, such as, for example, carriers, exchanges, and networks, among others.

114 114 114 114 110 103 103 103 103 b c d b c d In some cases, the end-user deviceincludes a data-centric computing device (e.g., computing device, mobile device, IoT device) that the user operates to access the services of the provider systemthrough a data-centric channel(e.g., mobile data channel, mobile channel, IoT channel), which includes hardware and software of computing data networks and communication (e.g., Internet, TCP/IP networks).

114 114 114 110 111 114 103 114 103 114 103 114 b c d b b b c c d d In some cases, the user operates the mobile device, computing device, or IoT deviceto access the services of the provider system, such as a provider website, an online web-application (“web app”), or Voice-over-IP (VOIP) telephony software, as hosted on the enterprise data server, where the end-user devicesaccess these services via corresponding types of data communication channels. Non-limiting examples of the data channels include the mobile data channelassociated with the mobile device, the computing channelassociated with the computing device, and the IoT channelassociated with the IoT device. The online data channel may include hardware and software components of one or more public or private computing networks. Non-limiting examples of such networks include: Local Area Network (LAN), Wireless Local Area Network (WLAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), and the Internet. The communication over the network may be performed in accordance with various communication protocols and software, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), IEEE communication protocols, Skype®, Zoom®, and VoIP, among others.

114 114 110 111 114 114 110 103 114 103 114 114 111 103 111 114 111 103 a b a a b a a e b b b b b b a e. In some cases, the user operates a telephony communications device, such as a landline phoneor mobile device, to interact with services of the provider systemby placing a telephone call to a call center agent or interactive voice response (IVR) system hosted by the enterprise telephony server. The user operates the telephony device (e.g., landline phone, mobile device) to access the services of the provider systemvia corresponding types of telephony communications channels, such as the landline channel(for the landline phone) or the mobile telephony channel(for the mobile device). For example, the mobile deviceexecutes an app that accesses the data services hosted by the enterprise data servervia the mobile data channel. The enterprise data serverreturns an out-of-channel notification that prompts the mobile deviceto place a telephone call to the enterprise telephony servervia the mobile telephony channel

114 114 103 103 111 111 c d c d a b. In some instances, the user operates the computing deviceor IoT deviceas a telephony device that executes software-based telephony protocols (e.g., VOIP) to place a software-based telephony call through the corresponding channel (e.g., computing channel, IoT channel) to the enterprise telephony serveror enterprise data server

103 100 114 111 103 114 111 103 c b c c a c Notably, certain channelsof the systemrepresent data channels in some circumstances, but represent telephony channels in other cases. For example, the end-user executes software on the computing devicethat accesses a web-portal or web-application hosted on the enterprise data server, such that the computing channelrepresents a data-centric channel carrying the data packets for the data service-related services. As another example, the end-user executes a telephony software (sometimes referred to as a “softphone”) of the computing deviceto place a telephone call to the enterprise telephony server, such that the computing channelrepresents a telephony channel carrying the data for the telephony-related services.

100 110 101 110 121 110 As mentioned, the systemcomprises several enterprise network infrastructures associated with various service entities (e.g., analytics service entity, IAM service entity, service provider entity). The provider systemincludes the enterprise computing network infrastructure managed by, operated by, owned by, or otherwise associated with the enterprise organization (e.g., retailers, banks, government entity) that functions as the provider of the various services to the end-users. The analytics systemincludes an enterprise computing network infrastructure managed by, operated by, owned by, or otherwise associated with the analytics service that performs the various analytics operations on behalf of the provider systems, such as biometrics or device authentication operations or risk assessment operations. The identity service systemincludes an enterprise computing network infrastructure managed by, operated by, owned by, or otherwise associated with the IAM service that performs the IAM operations on behalf of the provider systems.

110 111 112 116 The provider systemcomprises the provider server, provider database, and the agent device, each of which may include or be hosted on any number of computing devices comprising a processor, non-transitory machine-readable storage media, and software and capable of performing various processes described herein.

111 111 114 111 103 114 111 The provider servershost or provide the various services or support provided by the service provider to the end-users. The provider serverstransmit, receive, exchange, or otherwise communicate various types of data to, from, or with the end-user devices. The provider serverscomprise hardware and software components, configurations, and capabilities relative to the particular types of channelsor end-user devicesthat the provider serverswill support.

111 111 110 111 111 111 114 114 111 116 a a a a a a The enterprise telephony servercomprises a processor, software, and non-transitory storage for receiving and capturing telephone call data via the telephony channel, among other operations. The enterprise telephony serverreceives the call data for an inbound call from hardware that monitors or manages the telecommunications network data. For instance, a telecom monitoring device (not shown) situated at a trunk, exchange, or switch, may capture the call data of inbound telephone calls directed to the provider systemand forwards the call data to the enterprise telephony server. The enterprise telephony serverexecutes the call management software, such as call center queue software or IVR software. During execution of the call management software, the enterprise telephony serverreceives and captures the various inputs from the end-user device(e.g., spoken inputs, keypad inputs) and performs certain downstream operation. The IVR software, for example, executes a series of preconfigured IVR interfaces based on the inputs from the end-user device, and may eventually route the inbound call to the agent. The enterprise telephony serverfurther transmits the inbound call data to the agent device, which presents some or all of the inbound call data to the agent.

111 114 111 114 103 111 111 114 114 114 114 111 111 114 114 114 111 111 114 114 b b b b b c b b b b b b b. The enterprise data servercomprises a processor, software, and non-transitory storage for receiving and capturing user data received from the end-user devicesvia a data-communication channel, among other operations. The enterprise data serverhosts online data services accessible to the software (e.g., browser, software application) executed by the end-user devicevia data-centric channels. For instance, the enterprise data serverexecutes software (e.g., webserver) for hosting web-based services executed by the enterprise data serveraccording to instructions from the end-user deviceor hosting cloud-based services accessible to a software or app executed by the end-user device. As an example, the mobile deviceor computing deviceexecutes a browser to request and access a website having a chatbot service hosted on the enterprise data server. When executing the software programming for the chatbot, the enterprise data serverreceives inputs from the end-user device, determines the corresponding responsive output, and transmits the responsive output the end-user devicefor display at a graphical user interface of the browser. In another example, the mobile deviceexecutes a mobile app that accesses a portal or other service hosted by the enterprise data server. The enterprise data serverreceives user inputs from the mobile device, determines a particular responsive output, and transmits the responsive output for display at the mobile app of the mobile device

114 103 111 114 111 111 111 114 114 111 111 114 111 114 103 b c b b b b b b In operation, the end-user devicetransmits a request for the data-centric services over the data-communication channelto the enterprise data server. For instance, the computing deviceissues a request for services by visiting a website or accessing a feature hosted by the enterprise data server. For example, when the user attempts to access a bank account via banking portal for conducting a desired online transaction, the enterprise data serverprompts the user to enter authenticating data to log into the user's account. The enterprise data serverdisplays a portal GUI on end-user device, presenting a login prompt requiring the user to input the user authenticating data (e.g., account information, user identifier information) on the GUI. The user inputs the authenticating data and instructs the end-user deviceto transmit the authenticating data to the enterprise data server. When the enterprise data serversuccessfully authenticates the end-user device, the enterprise data serverestablishes a data-related session or authenticated session for the end-user devicevia the particular channel.

111 114 111 114 114 111 111 111 103 114 b b b b b b In some implementations, the enterprise data serverprompts the end-user deviceto perform a multi-factor authentication operation. For instance, the enterprise data serversuccessfully authenticates the end-user and the end-user device, permitting the end-user deviceto access the website services (e.g., banking web portal). When the enterprise data serverreceives a request or instruction for a particular feature or operation (e.g., wire funds to another account), the enterprise data serverautomatically executes the multi-factor authentication operation in which the enterprise data servertransmits a particular challenge prompt or code through another communication channel(e.g., email to pre-stored email address, text message to pre-stored phone number, push notification to mobile device).

111 114 111 103 111 114 111 114 103 b b b b The enterprise data serverincludes software programming that determines or detects instances of a triggering request based on inputs or instructions received from the end-user deviceor other preconfigured condition (e.g., temporal condition). In response to detecting the triggering request, the enterprise data serverdetermines that an ongoing session or exchange over the data-communication channelbetween the enterprise data serverand end-user devicereached an endpoint or otherwise expired. The enterprise data serverthen generates and transmits an out-of-band handling notification to the end-user device, indicating that the end-user should continue to interact with the service provider's services over a new communication channel.

111 114 103 111 111 111 103 111 103 103 110 103 114 103 b b b b b b b b b b b e. Continuing with the prior banking services example, the enterprise data serverreceives a request to initiate a stock purchase or close an account from the mobile devicevia the mobile data channel. The enterprise data serverdetermines that the requested operation is a type of request or instruction requiring the end-user to speak with a call center agent, according to preconfigured software code of the enterprise data server. In this example, the enterprise data serverdetects the requested operation as the triggering request that ends the operation process flow or data-channel session currently ongoing over the mobile data channel. The enterprise data servertransmits the out-of-band handling notification to the mobile data channel, prompting or otherwise instructing the end-user or the mobile data channelto call the call center of the provider system(e.g., place a telephone call via telephony channel). If the end-user wants to proceed, then the end-user operates the mobile deviceto place a telephone call via the mobile telephony channel

114 110 103 114 114 114 114 103 114 114 110 In some implementations, the out-of-band notification includes machine-executable instructions that automatically instruct the software of the end-user deviceto initiate software routines for contacting the provider systemvia the new channel. In some implementations, the out-of-band notification includes machine-executable instructions for the end-user deviceto generate a prompt or push notification for the graphical user interface of the end-user device, confirming whether the end-user would like the end-user deviceto invoke the software routines of the end-user deviceand place a telephone call via the telephony channel. In some implementations, the out-of-band notification includes machine-executable instructions for the end-user deviceto generate a prompt or push notification for the graphical user interface of the end-user deviceto inform the end-user to call the call center of the provider system.

111 100 111 110 111 111 The provider serverobtains certain types of authenticating data of the end-user, including a federated identifier (federated ID) uniquely identifying the end-user within the IAM processes and the ecosystem (e.g., other users, devices) of the system. The provider serverthen preparers and transmits an auth-trigger notification, which may be any executable method or HTTP verb for sending or otherwise providing data updates or uploads to a webserver (e.g., POST, PUT, PATCH). containing various types of session-related information, including the end-user's federated ID. The auth-trigger notification may further include, for example, an authentication level indicator (e.g., whether multi-factor authentication was successfully performed), a session ID, an expected phone number associated with the end-user user, and an enterprise phone number associated with the provider system. The provider servertransmits or otherwise communicates the auth-trigger notification according to any number of communication protocols. For example, in some cases, the auth-trigger notification is transmitted as a POST or PUT verb command according to the HTTP protocol. As another example, in some cases, the auth-trigger notification is generated by the provider server(or administrator-operated client device) using a gRPC interface or similar RPC-style client interface and transmitted according to the corresponding gRPC protocol or the similar RPC protocol.

111 114 114 114 107 112 The provider serverobtains the certain types of data about the end-user or the end-user devicefrom, for example, user inputs received from the end-user device, metadata received in the data packets or signaling data from the end-user device, or data records for the end-user stored in one or more databases (e.g., authentication database, provider database) containing pre-stored end-user data, previously captured and stored during a registration or enrollment process for the end-user.

111 102 105 106 107 102 107 107 The provider servertransmits the auth-trigger notification to the analytics serveror the identity server, which then stores the data into the analytics databaseor authentication database. For instance, the analytics servergenerates a channel session record using the data received in the auth-trigger notification. The channel session record includes, for example, a database insert file (e.g., JSON object) that contains some or all of the data in the auth-trigger notification and instructions for the authentication databaseto insert and store the channel session record into the non-transitory storage of the authentication databasefor later reference.

111 111 114 111 102 102 114 114 102 106 102 102 105 102 106 a When the provider server(e.g., enterprise telephony server) receives voice-related call data from the end-user device, the provider servertransmits an analytics request or authentication request to the analytics server, instructing the analytics serverto invoke various analytics operations on the call data received from the end-user devicefor a given communication channel session (e.g., inbound call received via telephony channel). The analytics request may include information about one or more communication sessions (e.g., session IDs), the end-user (e.g., call data, voice recording), or the end-user device. In some implementations, the analytics serverinvokes the voice biometrics operations immediately, such as extracting an inbound voiceprint vector using inbound audio data of the inbound call data, querying the analytics databasefor an enrollee voiceprint vector, or generating confidence scores for the inbound call data based upon the relative distances between the inbound voiceprint and the enrollee voiceprints. As discussed further below, in some implementations the analytics serverperforms only certain analytics operations or altogether delays the analytics operations until the analytics serverreceives the federated ID information from the identity server. In this way, the analytics servermust compare only a subset of targeted enrolled voiceprints, rather than comparing the inbound voiceprint against any number of enrolled voiceprints stored in the analytics database.

100 102 105 111 102 102 102 100 102 105 111 105 100 The federated ID may be any arbitrary value generated by a computing device of the system(e.g., analytics server, identity server, provider server). As a non-limiting example, when enrolling a new enrolled user, the analytics servermay assign a unique ID to the enrolled user data based on a random number generator. The analytics servermay then generate the federated ID for the enrolled user based upon a hash of the unique ID and a current timestamp of the analytics server. Additionally or alternatively, the federated ID may be provisioned and assigned by a computing device of the system(e.g., analytics server, identity server, provider server) in accordance with various pre-configured parameters. In some implementations, the federated ID may be an intermediary arbitrary identifier that is mutually agreed upon by the analytics service, identity service, and provider system, but independent of the respective provisioning parameters or rule sets governing unique identifiers implemented by each of the analytics service, identity service, and provider system. The identity serveror other device of the systemmay store and reference mappings or relationships between such federated ID and the unique IDs implemented by the respective computing architectures or sub-systems.

105 111 102 105 102 111 105 105 102 111 In some embodiments, the federated ID could be a unique ID that the identity service provisions and uses to identify an enrolled user. The identity servermay issue and provision the federated ID for the new enrolled user when that enrolled registers an account with the provider serveror enrolls with the analytics server. The identity servermay receive an instruction to generate the federated ID from the analytics serveror the provider server. Optionally, this instruction includes various types of information about the enrolled user. The identity servergenerates the new federated ID according to any number of preconfigured parameters and stores the federated ID in one or more databases. In some cases, the identity servermay return the new federated ID to the analytics serveror the provider server.

102 111 111 102 105 102 111 105 In some embodiments, the federated ID could be a unique ID that the provider service or the analytics service provisions and uses to identify an enrolled user. The analytics serveror the provider servermay issue and provision a new unique ID for the new enrolled user when that enrolled registers an account with the provider serveror enrolls with the analytics server. The identity servermay receive an instruction to generate the federated ID from the analytics serveror the provider server, where the instruction indicates the unique ID assigned to the enrolled user and may include various additional types of information about the enrolled user. The identity servergenerates the new federated ID according to any number of preconfigured parameters and stores the federated ID in one or more databases.

111 102 114 110 114 102 107 The provider serverreceives an authentication results notification from the analytics server, indicating the results of the various operations for evaluating the trustworthiness or riskiness of the end-user deviceattempting to communicate with the provider system. The authentication results include, for example, a confidence score (or threat score) indicating the distance (or similarity) between the enrolled voiceprint (or other types of enrolled vectors, such as deviceprints or behaviorprints) of the end-user indicated by the federated ID when compared against the inbound voiceprint (or other types of inbound vectors) generated for the inbound call data (or other types of inbound data). The authentication results may further indicate other information about the end-user or end-user device, such as the federated ID referenced by the analytics serverand authentication database.

111 114 103 103 111 114 111 103 111 111 116 116 116 116 116 111 Using the authentication results, the provider serverdetermines whether to permit or deny communication with the end-user devicethrough the later communication channel(e.g., telephony channel). In some implementations, the provider serverprogrammatically determines whether to permit or deny communication with the end-user devicein accordance with certain pre-configured thresholds or functions. For example, the provider serverdetermines that the caller's voice received through the telephony channeldoes not sufficiently match to the enrolled end-user's voice because the confidence score fails to satisfy a threshold score. In this example, the provider serverrejects (or terminates) the telephone call, or executes one or more mitigation operations (e.g., request additional authentication operations). Additionally or alternatively, the provider serverforwards the confidence score or other information from the authentication results to the agent device, allowing the agent deviceto determine whether the voice-match is sufficient in view of various factors in the call data, available to the agent through the agent device. The agent devicemay reject (or terminate) the telephone call or initiate the mitigation operations; or the agent devicemay transmit instructions to the provider serverto reject (or terminate) the telephone call or initiate the mitigation operations.

101 102 106 101 102 114 103 110 114 103 111 102 The analytics systemcomprises the analytics serverand the analytics database, each of which may be hosted on any number of computing devices comprising a processor, non-transitory machine-readable storage media, and software and capable of performing various processes described herein. The components of the analytics system, such as the analytics server, execute various processes using information extracted from the communication sessions with the user devicesvia the various channels. The end-user user accesses the services of the provider system(e.g., logs into the user's account) using one or more user devicesvia the corresponding channels, and the provider serversforward various types of communication data (e.g., call data) to the analytics serverfor the analytics operations.

110 114 114 103 103 103 111 116 112 114 114 102 106 114 110 103 111 102 107 a b a e a As an example, the user places a telephone call to the provider system(e.g., banking system) to withdraw money from a savings account, using a telephony device (e.g., landline phone, mobile device) through a telephony channel(e.g., landline channel, mobile telephony channel). The enterprise telephony server(e.g., IVR software) or the agent deviceenters into a provider databaseor auth-trigger notification the contact data or session data about the end-user, end-user device, or operation services accessed by the end-user; examples of such data includes, for example, the account accessed by the end-user device, the time and date of the transaction, service requested (e.g., withdrawal) and related information (e.g., requested withdrawal amount), call data (e.g., recording of the call, device metadata, user's phone number), and federated ID indicated by the phone number, among others. The analytics serverstores this session data for the communication sessions into an analytics databaseand performs various analytics operations, such as training or applying voice biometrics machine-learning architecture(s) on the data. When the end-user devicecontacts the provider systemvia one or more channels, the provider serverscapture and transmit the various types of contact data to the analytics server, among other devices (e.g., authentication database).

102 111 114 111 103 102 107 102 In some implementations, the analytics serverreceives the auth-trigger notification from the provider serverrelated to the communication between a particular end-user deviceand provider serverthrough a particular channel. The analytics serverthen uses the data in the auth-trigger notification to generate and store a new session data record into the authentication database. In some cases, the analytics serverincludes additional or alternative types of session data from the data in the auth-trigger notification.

111 114 111 114 114 103 103 103 111 114 103 114 103 111 102 102 103 103 b b b c b c b a e b As an example, the enterprise data servercaptures certain types of data about the end-user and end-user device, while the enterprise data servercommunicates with a mobile deviceor computing devicevia the corresponding data communication channel(e.g., mobile data channel, computing channel). When the enterprise data serverprompts the end-user deviceor the end-user to swap to a telephony channel(e.g., landline phone, mobile telephony channel), the enterprise data serversends the auth-trigger notification containing the various types of contact data or session data to the analytics server. Examples of data in the auth-trigger notification include the federated ID of the end-user, an authentication level, a session ID, and one or more phone numbers (e.g., expected phone number for the end-user, enterprise-generated phone number associated with the end-user). In this example, the analytics serveruses the information in the auth-trigger notification to generate the session record for the data-communication channel, and further includes other types of session data, such as an indication of an expiration or time-to-live (TTL) for the session record, indication of the type of authentication operations to perform on the expected new communication channel, among others.

111 103 111 102 102 114 111 103 114 103 When the provider serverreceives the later communication via the new communication channel, the provider servertransmits an authentication request to the analytics server, instructing the analytics serverto perform the various analytics operations on the contact data (e.g., audio session ID, call data, end-user data, end-user devicedata) captured by the provider serverfrom the communication received via the new communication channel. In some cases, the contact data includes the federated ID for the end-user deviceor end-user associated with the new communication channel. In some cases, the contact data includes the inbound phone number (or other identifier) associated with a caller's federated ID.

102 107 103 102 105 102 107 102 105 105 107 102 102 103 Using this inbound phone number, the analytics serverobtains the session record stored in the authentication databasefor the earlier communication channel. In some cases, the analytics serverqueries the identity serverfor the federated ID(s) associated with the inbound phone number. The analytics serveruses these federated ID(s) to query the authentication databasefor the session data record(s) associated with the federated ID(s). In some cases, the analytics serversends the inbound phone number to the identity server. The identity serveridentifies the federated ID(s) associated with the inbound phone number, queries the authentication databasefor the session data record(s) associated with the identified federated ID(s), and returns the identified session records associated with the federated ID(s) to the analytics server. In this way, the analytics serveraccesses the federated IDs for the inbound caller and for the end-user involved with the session record generated for the initial communication channel.

102 107 106 102 102 106 100 103 102 114 103 103 103 103 100 b e The analytics operations executed by the analytics serverinclude training and applying one or more machine-learning architectures on the contact data to determine the similarities or distances between inbound contact data, stored session data in the authentication database, and/or stored enrolled data in the analytics database. For instance, the analytics serverapplies a speaker recognition machine-learning architecture on the call data of the inbound call to extract an inbound voiceprint for the inbound caller. Using the federated ID in the earlier session record, the analytics serverqueries the analytics databasefor an enrolled voiceprint for an enrolled end-user. The machine-learning architecture returns a confidence score (or risk score) indicating the similarity (or distance) between the inbound voiceprint and the enrolled voiceprint. In this way, the systemprovides multiple layers of failure for fraudsters attempting to coopt the contact at the switch to the new communication channel. For example, if the inbound contact data does not include sufficient data for obtaining the federated IDs, then the analytics serverwould be unable to retrieve the session data record and/or the enrolled voiceprint. As another example, if the fraudster spoofs the data associated with the federated IDs or manages to access the end-user devices, the fraudster would still need to satisfy the voice biometrics operations. As a matter of user experience, the user's switch from a first channel(e.g., mobile data channel) to a second channel(e.g., mobile telephony channel) is frictionless, due to the systemreferencing data storage locations based on passing the federated ID without necessarily requiring further inputs from the end-user, though further or different inputs may be desirable in certain circumstances.

106 112 110 102 106 112 102 105 The analytics databaseand provider databaseinclude various types of enrolled data associated with the enrolled users of the provider system. This includes data records containing various types of enrolled data used for authenticating the registered users or tracking operations, features, and behaviors of the registered users. The enrolled data includes various enrolled feature vectors, as generated by the layers of the machine-learning architecture executed by the analytics server. Non-limiting examples of the enrolled feature vectors include voiceprints, deviceprints (sometimes called “phoneprints”), behaviorprints, deepfake detection (sometimes referred to as “liveness detection”), and the like. The analytics databaseor provider databasestores the enrolled data for the enrolled users with the corresponding federated IDs of the enrolled users, such that the analytics serveror identity serveruses the user's federated ID to query and retrieve particular user's voiceprint or other enrolled data for the authentication operations.

121 105 106 101 102 114 103 110 114 103 111 102 The identity service systemcomprises the identity serverand the analytics database, each of which may be hosted on any number of computing devices comprising a processor, non-transitory machine-readable storage media, and software and capable of performing various processes described herein. The components of the analytics system, such as the analytics server, execute various processes using information extracted from the communication sessions with the user devicesvia the various channels. The end-user user accesses the services of the provider system(e.g., logs into the user's account) using one or more user devicesvia the corresponding channels, and the provider serversforward various types of communication data (e.g., call data) to the analytics serverfor the analytics operations.

110 114 114 103 103 103 111 116 112 114 114 114 110 103 111 102 107 111 102 103 103 105 107 111 103 a b a e a b As an example, the user places a telephone call to the provider system(e.g., banking system) to withdraw money from a savings account, using a telephony device (e.g., landline phone, mobile device) through a telephony channel(e.g., landline channel, mobile telephony channel). The enterprise telephony server(e.g., IVR software) or the agent deviceenters into a provider databaseor auth-trigger notification, contact data or session data about the end-user, end-user device, or the operation services accessed by the end-user; examples of such data includes, for example, the account accessed by the end-user device, the time and date of the transaction, service requested (e.g., withdrawal) and related information (e.g., requested withdrawal amount), call data (e.g., recording of the call, device metadata, user's phone number), and federated ID indicated by the phone number, among others. When the end-user devicecontacts the provider systemvia one or more channels, the provider serverscapture and transmit the various types of contact data to the analytics server, among other devices (e.g., authentication database). In some cases, the provider serveror the analytics serverobtain the federated ID (or other types of information) for the end-user associated with the initial communication channelsession (e.g., mobile data channel) by querying the identity serveror authentication databaseusing the contact data (e.g., expected or enrolled phone number, user credentials, end-user device IDs) captured by the provider serverin the initial channel.

111 111 105 105 111 114 111 103 105 107 In some implementations, when the provider serverdetects the triggering request, the provider servergenerates and transmits the auth-trigger notification to the identity server. In such implementations, the identity serverreceives the auth-trigger notification from the provider serverrelated to the communication between the particular end-user deviceand the provider serverthrough the particular channel. The identity serverthen uses the contact data in the auth-trigger notification (e.g., federated ID, authentication level, session ID, phone numbers) to generate and store a new session data record in the authentication database.

105 111 114 111 114 114 103 103 103 111 114 103 114 103 111 105 105 103 103 103 b b b c b c b a e b b In some cases, the identity serverincludes additional or alternative types of session data from the data in the auth-trigger notification. As an example, the enterprise data servercaptures certain types of data about the end-user and end-user device, when the enterprise data servercommunicates with the mobile deviceor computing devicevia the corresponding data communication channel(e.g., mobile data channel, computing channel). When the enterprise data serverprompts the end-user deviceor the end-user to swap to a telephony channel(e.g., landline phone, mobile telephony channel), the enterprise data serversends the auth-trigger notification containing the various types of contact data or session data to the identity server. Examples of data in the auth-trigger notification include the federated ID of the end-user, an authentication level, a session ID, and one or more phone numbers (e.g., expected phone number for the end-user, enterprise-generated phone number associated with the end-user). In this example, the identity serveruses the information in the auth-trigger notification to generate the session record for the data-communication channel, and further includes other types of session data, such as an indication of an expiration or time-to-live (TTL) for the session record, indication of the type of authentication operations to perform on the expected new communication channel(e.g., mobile data channel), among others.

111 103 111 102 102 114 111 103 114 103 When the provider serverreceives the later communication via the new communication channel, the provider servertransmits the authentication request to the analytics server, instructing the analytics serverto perform the various analytics operations on the contact data (e.g., audio session ID, call data, end-user data, end-user devicedata) captured by the provider serverfrom the communication received via the new communication channel. In some cases, the contact data includes the federated ID for the end-user deviceor end-user associated with the new communication channel. In some cases, the contact data includes the inbound phone number (or other identifier) associated with a caller's federated ID.

102 107 103 102 105 102 107 102 105 105 107 102 102 103 Using this inbound phone number, the analytics serverobtains the session record stored in the authentication databasefor the earlier communication channel. In some cases, the analytics serverqueries the identity serverfor the federated ID(s) associated with the inbound phone number. The analytics serveruses these federated ID(s) to query the authentication databasefor the session data record(s) associated with the federated ID(s). In some cases, the analytics serversends the inbound phone number to the identity server. The identity serveridentifies the federated ID(s) associated with the inbound phone number, queries the authentication databasefor the session data record(s) associated with the identified federated ID(s), and returns the identified session records associated with the federated ID(s) to the analytics server. In this way, the analytics serveraccesses the federated IDs for the inbound caller and for the end-user involved with the session record generated for the initial communication channel.

1 FIG.B 1 FIG.A 1 FIG.B 1 FIGS.B 1 FIG.C 1 FIG.B 100 121 101 121 105 107 105 102 101 100 100 110 101 102 102 106 106 102 102 105 102 105 In, the systemomits the distinct infrastructure for the identity service systemand the analytics systemincorporates the components and operations of the identity service system, including the operations of the identity serverand authentication database. The identity serverexecutes the IAM operations in concert with the analytics server, where the hardware and/or software performing the IAM operations are developed by the IAM service entity or homegrown by the analytics system. The systemand related components are similar to those described with respect toand need not be described again with respect to. Embodiments may comprise additional or alternative components or omit certain components from those of, yet still fall within the scope of this disclosure. It may be common, for example, for the systemto include multiple provider systems, or for the analytics systemto have multiple analytics servers. Embodiments may include or otherwise implement any number of devices capable of performing the various features and tasks described herein. As an example,shows the analytics serveras a distinct computing device from the analytics database, though in some configurations, the analytics databasemay be integrated into the analytics server, such that these features are integrated within a single device.shows the analytics serveras a distinct computing device from the identity server, though the analytics serverand the identity servermay be integrated into the same computing devices.

1 FIG.C 1 1 FIGS.A-B 1 FIG.C 1 FIGS.C 1 FIG.C 1 FIG.C 100 121 110 121 105 107 105 102 110 100 100 110 101 102 102 106 106 102 111 105 111 105 In, the systemomits the distinct infrastructure for the identity service systemand the provider systemincorporates the components and operations of the identity service system, including the operations of the identity serverand authentication database. The identity serverexecutes the IAM operations in concert with the analytics server, where the hardware and/or software performing the IAM operations are developed by the IAM service entity or homegrown by the provider system. The systemand related components are similar to those described with respect toand need not be described again with respect to. Embodiments may comprise additional or alternative components or omit certain components from those of, yet still fall within the scope of this disclosure. It may be common, for example, for the systemto include multiple provider systems, or for the analytics systemto have multiple analytics servers. Embodiments may include or otherwise implement any number of devices capable of performing the various features and tasks described herein. As an example,shows the analytics serveras a distinct computing device from the analytics database, though in some configurations, the analytics databasemay be integrated into the analytics server, such that these features are integrated within a single device. As another example,shows the provider serverand identity serveras distinct computing devices, though in some configurations, the provider serverand identity servermay be integrated into the same computing devices.

2 2 FIGS.A-B 200 200 include flowcharts showing operations of a processof identity management for an end-user accessing a provider system via multiple communication channels and using corresponding communication devices. As mentioned, a federated ID may include any form of intermediate ID referenced by the various devices of the process. For ease of understanding, certain features and functions involve a federated ID, though embodiments may include any form of intermediate arbitrary ID that each device of the system is preconfigured to ingest and map to another known unique ID.

2 FIG.A 200 111 111 b a shows certain operations of the processas performed by a provider data server (e.g., enterprise data server) and provider telephony server (e.g., enterprise telephony server) of a server provider system.

200 114 114 103 103 114 114 103 103 200 b c b c a b a e In the example process, the provider data server communicates with end-user client devices (e.g., mobile device, computing device) through corresponding data communication channels (e.g., mobile data channel, computing channel). The provider telephony server communicates with an end-user telephony device (e.g., landline phone, mobile device) through corresponding data communication channels (e.g., landline channel, mobile telephony channel). The example processdescribes operations for moving from a data channel (as a first channel) to a telephony channel (as a second channel), though embodiments are not so limited.

201 In operation, the provider data server receives various types of data and metadata from the client device via the data channel and establishes data-channel session with client device. The data server receives a data communication from the device of the end-user over the data channel, when the client device requests access to a service of the provider system. The provider server receives the service request through a particular communication channel that logically and/or physical connects the service and the computing device.

For example, the end-user instructs the client device to invoke and execute a mobile app associated with the provider service. The mobile app or data server receives and evaluates authenticating data (e.g., credentials, biometrics) inputted by the user. In a single-factor authentication configuration, the user successfully logs into the mobile app when the credentials supplied match to expected login credentials. In this way, the mobile app and the provider server confirmed the identity of the user, at least to a certain degree of authentication level, allowing the provider system and authentication server to store identity-related information in an authentication database for later authenticating the end-user through another channel (e.g., telephony channel, different data channel).

203 201 In operation, the data server receives data inputs from the client device via the data channel and detects a triggering request according to preconfigured triggering instructions in the software programming (e.g., triggering inputs, threshold values, temporal thresholds or expiration timing). Due to detecting the triggering request, the data server determines that an ongoing operational flow or service request (e.g., ongoing chatbot conversation, request to withdraw or transfer funds, generate or update user data) reaches an endpoint requiring the end-user to switch to another communication channel. The user's journey (operational flow of the session) of accessing and interacting with the provider's services begins when the mobile app or browser of the client device accesses and invokes the services or features executed by the data server (as in operation). The client device and the data server generate and communicate messages over the data channel, according to user inputs, software programming of the client device, and software programming of the data server. At some point in the journey, the data server receives instructions or inputs from the client device that the data server detects as the triggering request for a particular function or operation, representing an endpoint in the end-user and client device's journey through the particular data channel for the desired operation or service.

As an example, the data server includes webserver software that hosts a provider webpage and executes a chatbot program, accessed by the client device. The client device sends the various user inputs as entered into a chatbot user interface, and the chatbot determines how to respond or executes programming for a particular operation in accordance with the user inputs. Eventually, the data server detects the triggering request, occurring when the data server determines that the user input requested a response or operation that requires the user to contact the call center and speak with a call center agent.

As another example, the service provider is a bank and the data server invokes or performs operations (e.g., funds transfer, check account balance) according to the user inputs received from the client device (e.g., mobile app, web browser). The data server may present the account balance in response to an input request a balance check. The programming of the data server determines that the user has not accessed the user account for a login-threshold period of time and cannot request certain features (e.g., stock purchase, funds transfer) through the data server. The data server detects the triggering request from the client device, occurring when the data server determines that the login-threshold period elapsed and the end-user requested one or more of the certain features.

205 102 105 In operation, the data server generates an auth-trigger notification containing a federated ID and expected phone number associated with the end-user. The data server transmits the auth-trigger notification to one or more authentication servers (e.g., analytics server, identity server) that store the data into an authentication database as a session record associated with the data channel communication session (between the client device and the data server). Contemporaneously, the data server returns an out-of-band channel notification to the client device in response to the detecting the triggering request.

112 106 201 The data server or authentication server determines the federated ID according to the successful authentication of the end-user through the data channel or by retrieving relevant data records for the authenticated user from one or more databases (e.g., provider database, analytics database). In some cases, using the authenticating data obtained with the user's successful login (in operation), among other possible types of metadata or inputs, the data server or authentication server executes the IAM operations or services executed by the authentication server or queries the databases, to identify and retrieve the federated ID of the end-user for the communication session for the given channel.

For example, in response to detecting the triggering request, the data server transmits an auth-trigger notification indicating a registered ANI or phone number associated with the user. For instance, the auth-trigger notification indicates that the call center should expect a call from “(310) 555-1212” and “ID_100” identifying the end-user. Using the auth-trigger notification information, the authentication server then generates a database object file (e.g., JSON file) for a new channel session record, and stores the session record into the authentication database. In later operations, the authentication server references the federated ID (“ID_100”) of the end-user to identify and authenticate a caller as the end-user via the telephony channel, when that caller purports to be or otherwise should be associated with the same federated ID (“ID_100”), and thus should have the same biometrics (e.g., enrolled voiceprint) stored in a database referenced by the analytics operations.

In some implementations, if the client device and data server perform multi-factor authentication operations. For example, the data server may determine that the requested service or feature requires stepped-up authentication or the user's profile indicates that the user enabled a multi-factor authentication preference in the user's account data. In this example, when the customer reaches the endpoint in the journey and successfully satisfies the multi-factor authentication requirement, then the data server includes an authentication level (“MFA: ‘True’”) in the auth-trigger notification information.

205 Continuing with operation, as mentioned, the data server returns an out-of-band handling notification to the client device, indicating that end-user has reached the endpoint of the journey via the data channel and the end-user needs to contact the provider through another communication channel, such as a place a telephone call through the telephony channel. In some instances, the out-of-band notification includes instructions for the client device to present in present a graphical user interface prompt for the end-user to place the telephone call to the contact call center through the telephony channel. In some instances, the out-of-band notification includes instructions for the client device to invoke a telephony application or function of the client device.

207 In operation, the provider telephony server receives inbound call data for an inbound call, originated from a caller's telephony device via the telephony channel. The inbound call data includes various types of data for identifying the end-user, the end-user's telephony device, and for presenting to the call center agent to service the end-user's service requests. Non-limiting examples of the inbound call data includes the inbound phone number (or ANI) of the inbound caller's telephony device; an audio recording or acoustic data containing samples of the caller's voice; user inputs to IVR software executed by the telephony server; and metadata associated with or indicating the caller's telephony device, among other potential types of data.

In some cases, the telephony server receives the inbound call data from a monitoring device that monitors traffic over the telephony communication channels and forwards the inbound call data to the telephony server of the provider system. In such cases, the telephony channels include hardware and software components of telecommunications networks according to telephony-related protocols (e.g., trunks, exchanges, switches, SIP, SS7, POTS, DNIS, ISDN, PSTN, VOIP), where the telephony device includes a landline or mobile telephone. In some cases, the telephony server receives telephony channels include hardware and software components for computer-telephone integration (CTI) or digital telephony protocols (e.g., routers, switches, TCP/IP, VOIP), where the telephony device includes a computer or mobile device executing telephony software, softphone software, teleconferencing software, or integrated telephony software routines of the mobile application.

209 In operation, the telephony server sends an authentication request (with inbound call data) to the authentication server, which performs the IAM operations and analytics operations using the inbound call data. The authentication server queries the authentication database and retrieves the session record (for the user's session through the data channel), and receives the various types of inbound call data from the telephony channel. The IAM operations of the authentication server determine the user federated ID indicated by the client device and/or the user federated ID indicated by the telephony device. The analytics operations of the authentication server applying machine-learning architecture operations against the inbound call data for comparison against enrolled data associated with the federated ID expected from the session record.

205 The IAM operations include, for example, identifying the federated ID for the inbound user indicated by the inbound data. The IAM operation receives the authentication request containing the phone number, and queries the authentication database (or other databases) for the federated IDs associated with the phone numbers or ANIs in the authentication request. For example, the session record stored into the authentication includes the federated ID (“ID_100”) and expected phone number (“(310) 555-1212”). In this example, the telephony server includes the inbound phone number (“(310) 555-1212”) in the authentication request submitted to the authentication server. Using the inbound phone number (“(310) 555-1212”), the authentication database returns each of the database records and federated IDs (e.g., “ID_100”) associated with the inbound phone number, which in this example, is the same federated ID (“ID_100”) in the session record generated for the data channel (in operation).

The IAM operations return the selected federated ID (“ID_100”), among other potential types of data, to the analytics operations. The analytics operations, in turn, query the databases (e.g., analytics database) using the selected federated ID to retrieve various types of enrolled data for authenticating the caller over the telephony channel. The analytics operations retrieve the enrolled vectors and/or enrolled data associated with the selected federated ID against corresponding inbound vectors and/or inbound data generated for the inbound call data or received in the authentication request.

The analytics operations include, for example, executing one or more machine-learning architecture layers for extracting certain types of embedding feature vectors for registered enrolled users and inbound contact data from users. The analytics operations apply the layers of the machine-learning architecture on the contact data to extract certain types of features and corresponding types of feature vectors, such as voiceprints, browserprints (sometimes referred to as “browser fingerprints”), or deviceprints (sometimes referred to as “phoneprints”). As an example, the contact data comprises call data that includes voice samples, where the layers of the machine-learning architecture extract low-level acoustic features (e.g., MFCCs) from the voice sample data. In this example, the machine-learning architecture extracts a voiceprint based on the features extracted from the voice sample data. As another example, the contact data comprises metadata associated with the web browser of the client device of the end-user. In this example, the layers of the machine-learning architecture extract various types of features from the browser-related metadata and then extract the browserprint for the browser. As another example, the contact data comprises metadata associated with the client device of the end-user. In this example, the layers of the machine-learning architecture extract various types of features from the metadata, and then extract the deviceprint for the user's telephony device or client device. The types of metadata correspond to the types of end-user devices. For the telephony device, the analytics operations extract the metadata associated with the telephony device (e.g., ANI, telephone number) or telephony channel (e.g., SIP signaling data). Similarly, for the client device, the analytics operations extract the metadata associated with the client device (e.g., MAC address, IP address) or data channel (e.g., router data, switch data, IP packet header data).

200 When the user registers with the provider system, the analytics operations apply the layers of the machine-learning architecture on enrollment contact data received from an enrollee-user to extract the certain types of enrollment features and corresponding types of enrollment feature vectors (e.g., enrollment voiceprints, enrollment browserprints, enrollment deviceprints). The authentication server stores the enrollment vectors into an authentication database or other database (e.g., analytics database), which are stored in database records associated with the federated ID associated with the particular enrollee-user. During real-time authentication operations, as in the example process, the analytics operations apply the layers of the machine-learning architecture on the inbound contact data (e.g., inbound call data) received from an inbound user to extract the certain types of inbound features and corresponding types of inbound feature vectors (e.g., inbound voiceprint, inbound browserprint, inbound deviceprint). To authenticate an inbound user (e.g., inbound caller), the layers of the machine-learning architecture compare the enrollment vectors against the inbound vectors to generate a confidence score or risk score indicating a distance or similarity between the enrollment vectors and the corresponding inbound vectors.

In some embodiments, the server performs a multi-factor authentication operation. The data server or other device (e.g., authentication server) may authenticate the user according to the multi-factor authentication operation and the session record includes data indicating the authentication level (e.g., “MFA_False,” “MFA_True”). The telephony server generates the authentication request including the authentication level. In some circumstances, the authentication server determines that the multi-factor authentication operation should be performed for the particular requested operation, but that the multi-factor authentication was not successfully performed (“MFA_False”). In such circumstances, the authentication server transmits instructions to the telephony device or client device for the caller or end-user to perform the multi-factor authentication. In some circumstances, the authentication server determines that the multi-factor authentication operation should be performed for the particular requested operation, and that the multi-factor authentication was successfully performed (“MFA_True”). In such circumstances, the authentication server determines that certain authentication operations are unnecessary.

211 In operation, the telephony server receives authentication response from the authentication server. The authentication response indicates the authentication results (e.g., confidence score, risk score) generated by the authentication server, among other types of information.

213 In operation, the telephony server determines whether to accept or reject the inbound call based upon the authentication response. The authentication results may further include machine-readable instructions for the telephony server, call center agent device, or caller telephony device to perform based upon whether the telephony server accepted or rejected the inbound call. In accepting the inbound call, the telephony server may, for example, permit the inbound call to continue, route the call to the destination for handling the user's requested services (e.g., route to agent, IVR service), or execute the user's requested services. In rejecting the inbound call, the telephony server may, for example, terminate the inbound call, route the inbound call to a secondary queue for further consideration, or execute one or more mitigating operations. Such mitigating operations performed by the telephony server (or other server) include, for example, requesting additional information from the user, or instructing the authentication server and end-user to successfully perform the multi-factor authentication operation.

In some implementations, the telephony server performs the executable instructions indicating whether to permit or reject the inbound call as determined by the authentication server.

In some implementations, the telephony server executes preconfigured software routines that use the data within the authentication response to programmatically permit or reject the inbound call according to the data values within the authentication response. For instance, the telephony server compares the confidence score (or other values) in the authentication score against corresponding thresholds, such as a threshold confidence (or similarity) score or threshold distances, among other factors for determining whether to authenticate, permit, or reject the inbound call.

Additionally or alternatively, the telephony server permits or rejects, or mitigates the call, according to inputs received from the call center's agent device. The authentication response may include instructions for presenting the authentication results (e.g., confidence score) at the graphical user interface of the call center agent. The call center agent may then operate the graphical user interface and input a confirmation input instructing the telephony server whether to permit or reject the inbound call.

2 FIG.B 200 102 105 200 200 shows certain operations of the processas performed by one or more authentication servers (e.g., analytics server, identity server). For ease of description, the processoperations are described as being performed by one authentication server device, though embodiments may include any number of computing devices that perform the functions of one or more authentications. Moreover, the processoperations are described as being performed by the authentication server, though the processes and operations may be performed by, for example, an analytics server and an identity server.

221 In operation, the authentication server receives an auth-trigger notification from the provider's enterprise data server, where the auth-trigger notification includes various information about the communication session between the client device and the data server, including a federated ID and expected or enrolled phone number for the end-user.

For example, the data server transmits the auth-trigger notification indicating a registered enrolled ANI or phone number associated with the end-user for the data communication channel, between the data server and the client device. The auth-trigger notification indicates, for example, that the telephony should expect a call from the phone number: “(310) 555-1212,” and that the session involved the end-user associated with the federated ID: “ID 100.”

223 In operation, authentication server generates a session data record based on the auth-trigger notification for the client device's data channel session between with the data server over the data channel. The authentication server then stores the new session record into the authentication database.

Using the auth-trigger notification information, the authentication server then generates a database object file (e.g., JSON file) for the new channel session record, and stores the session record into the authentication database. Continuing with the earlier example, the session record would indicating the federated ID: “ID_100” and the associated ANI or phone number “(310) 555-1212.”

In some implementations, if the client device and data server perform multi-factor authentication operations. For example, the data server may determine that the requested service or feature requires stepped-up authentication or the user's profile indicates that the user enabled a multi-factor authentication preference in the user's account data. In this example, when the customer reaches the endpoint in the journey and successfully satisfies the multi-factor authentication requirement, then the data server includes an authentication level (“MFA: ‘True’”) in the auth-trigger notification information.

229 In some implementations, the authentication server includes a timestamp and a TTL expiration period (e.g., 30 minutes, 60 minutes) in the session record, after which the session record expires. As an example, when the authentication server later references the session record (described in later operation), the authentication server confirms whether the session record remains valid or expired.

225 In operation, the authentication server receives an inbound call notification or inbound call data from the provider's telephony server. When the call center receives an inbound call, the inbound call data is captured and forwarded to the telephony server, but one or more devices of the provider system may also send a notification to the authentication server, prompting the authentication server to establish a session ID for the telephony channel and perform one or more analytics operations on the call data. The inbound call data includes, for example, an audio session ID for the inbound phone call over the telephony channel, an audio recording, and telephony metadata for the end-user's telephony device, and the like.

The inbound call data includes various types of data for identifying the end-user, the end-user's telephony device, and for presenting to the call center agent to service the end-user's service requests. Non-limiting examples of the inbound call data includes the inbound phone call (or ANI) of the inbound caller's telephony device; an audio recording or acoustic data containing samples of the caller's voice; user inputs to IVR software executed by the telephony server; and metadata associated with or indicating the caller's telephony device, among other potential types of data.

In some cases, the telephony server receives the inbound call data from a monitoring device that monitors traffic over the telephony communication channels and forwards the inbound call data to the telephony server of the provider system. In such cases, the telephony channels include hardware and software components of telecommunications networks according to telephony-related protocols (e.g., trunks, exchanges, switches, SIP, SS7, POTS, DNIS, ISDN, PSTN, VOIP), where the telephony device includes a landline or mobile telephone. In some cases, the telephony server receives telephony channels and includes hardware and software components for computer-telephone integration (CTI) or digital telephony protocols (e.g., routers, switches, TCP/IP, VOIP), where the telephony device includes a computer or mobile device executing telephony software, softphone software, teleconferencing software, or integrated telephony software routines of the mobile application.

227 In operation, the authentication server receives an authentication request from the telephony server, instructing the authentication server to execute various IAM operations and analytics operations to identify and authenticate the caller. The IAM operations of the authentication server determine the user federated ID indicated by the client device and/or the user federated ID indicated by the telephony device. The analytics operations of the authentication server applying machine-learning architecture operations against the inbound call data for comparison against enrolled data associated with the federated ID expected from the session record. The authentication request includes inbound call data about the inbound call referenced by the IAM operations (e.g., inbound phone number or ANI of the inbound call data) and the analytics operations (e.g., inbound voice sample recording data, inbound metadata).

The IAM operations of the authentication server determine the user federated ID indicated by the client device and/or the user federated ID indicated by the telephony device. The analytics operations of the authentication server applying machine-learning architecture operations against the inbound call data for comparison against enrolled data associated with the federated ID expected from the session record.

229 223 In operation, using the inbound call data, the authentication server obtains the session data record stored in the authentication database (in operation). As mentioned, the IAM operations include software routines for determining the particular federated IDs associated with the end-user device identifiers (e.g., phone number, ANI, MAC address, IP address). The various authentication operations (e.g., analytics biometrics operations, multi-factor authentication operations) employed by the service provider systems benefit from the federated ID. The IAM operations generally output the federated ID for a given phone number (or other identifier), and forward the federated ID and the associated phone number to the downstream operations. In some cases, the IAM operations query and retrieve the federated ID from a previously stored database record (e.g., session data record). And in some cases, the IAM operations receive a purported federated ID or other identity claims, and the IAM operations confirm whether the purported federated ID successfully authenticates the end-user purporting to be associated with the purported federated ID.

As an example, the IAM operations successfully authenticated the user in the earlier data channel, and stored the federated ID (e.g., ID_100) into the session record of the authentication database. The session record may also include an expected enrolled phone number (“(310) 555-1212”) associated with the end-user. The IAM operations may receive an authentication request containing the inbound phone number (e.g., “(310) 555-1212”). The IAM operations query the authentication database for the federated ID(s) listed in the session record(s) associated with the inbound phone number. The IAM operations retrieve the federated ID(s) associated with the inbound phone accordingly.

The IAM operations return the selected federated ID (“ID_100”), among other potential types of data, to the analytics operations. The analytics operations, in turn, query the databases (e.g., analytics database) using the selected federated ID to retrieve various types of enrolled data for authenticating the caller over the telephony channel. The analytics operations retrieve the enrolled vectors and/or enrolled data associated with the selected federated ID against corresponding inbound vectors and/or inbound data generated for the inbound call data or received in the authentication request.

In some cases, multiple federated IDs are associated with multiple expected phone numbers and/or inbound phone number according to the records of the various system databases. The operations of the authentication server (e.g., IAM operations, analytics operations) may establish, exchange, and store a unique session ID for each session occurring through the various communication channels. This session ID may be stored into the session record for a prior session, but may be used to link to the ongoing the IAM operations and analytics operations for a current session. When retrieving the federated IDs associated with the inbound call data, the analytics operations or IAM operations select only those federated IDs associated with the current session ID through the later communication channel (e.g., telephony channel). In this way, the IAM operations may reduce the volume of information and amount data records fed into the analytics operations.

231 In operation, the authentication server generates a confidence score by comparing an enrollee's voiceprint associated with the federated ID against an inbound voiceprint from the inbound call data. The analytics operations generate the confidence score by applying layers of a machine-learning architecture on the inbound call data for the session, where the machine-learning architecture extracts inbound feature vectors for the inbound call data and compares the inbound feature vectors against enrolled feature vectors for the federated ID, as stored in the one or more databases.

The analytics operations include, for example, executing one or more machine-learning architecture layers for extracting certain types of embedding feature vectors for registered enrolled users and inbound contact data from users. The analytics operations apply the layers of the machine-learning architecture on the contact data to extract certain types of features and corresponding types of feature vectors, such as voiceprints, browserprints (sometimes referred to as “browser fingerprints”), or deviceprints (sometimes referred to as “phoneprints”). As an example, the contact data comprises call data that includes voice samples, where the layers of the machine-learning architecture extract low-level acoustic features (e.g., MFCCs) from the voice sample data. In this example, the machine-learning architecture extracts a voiceprint based on the features extracted from the voice sample data. As another example, the contact data comprises metadata associated with the web browser of the client device of the end-user. In this example, the layers of the machine-learning architecture extract various types of features from the browser-related metadata and then extract the browserprint for the browser. As another example, the contact data comprises metadata associated with the client device of the end-user. In this example, the layers of the machine-learning architecture extract various types of features from the metadata, and then extract the deviceprint for the user's telephony device or client device. The types of metadata correspond to the types of end-user devices. For the telephony device, the analytics operations extract the metadata associated with the telephony device (e.g., ANI, telephone number) or telephony channel (e.g., SIP signaling data). Similarly, for the client device, the analytics operations extract the metadata associated with the client device (e.g., MAC address, IP address) or data channel (e.g., router data, switch data, IP packet header data).

200 When the user registers with the provider system, the analytics operations apply the layers of the machine-learning architecture on enrollment contact data received from an enrollee-user to extract the certain types of enrollment features and corresponding types of enrollment feature vectors (e.g., enrollment voiceprints, enrollment browserprints, enrollment deviceprints). The authentication server stores the enrollment vectors into an authentication database or other database (e.g., analytics database), which are stored in database records associated with the federated ID associated with the particular enrollee-user. During real-time authentication operations, as in the example process, the analytics operations apply the layers of the machine-learning architecture on the inbound contact data (e.g., inbound call data) received from an inbound user to extract the certain types of inbound features and corresponding types of inbound feature vectors (e.g., inbound voiceprint, inbound browserprint, inbound deviceprint). To authenticate an inbound user (e.g., inbound caller), the layers of the machine-learning architecture compare the enrollment vectors against the inbound vectors to generate a confidence score or risk score indicating a distance or similarity between the enrollment vectors and the corresponding inbound vectors.

In some embodiments, the server performs a multi-factor authentication operation. The data server or other device (e.g., authentication server) may authenticate the user according to the multi-factor authentication operation and the session record includes data indicating the authentication level (e.g., “MFA_False,” “MFA_True”). The telephony server generates the authentication request including the authentication level. In some circumstances, the authentication server determines that the multi-factor authentication operation should be performed for the particular requested operation, but that the multi-factor authentication was not successfully performed (“MFA_False”). In such circumstances, the authentication server transmits instructions to the telephony device or client device for the caller or end-user to perform the multi-factor authentication. In some circumstances, the authentication server determines that the multi-factor authentication operation should be performed for the particular requested operation, and that the multi-factor authentication was successfully performed (“MFA_True”). In such circumstances, the authentication server determines that certain authentication operations are unnecessary.

The authentication server generates an authentication response for the telephony server. The authentication response indicates the authentication results (e.g., confidence score, risk score) generated by the authentication, among other types of information.

233 In operation, the authentication server transmits the authentication response containing the authentication results to the telephony server. The authentication results include, for example, the confidence score generated for the inbound call data associated with the inbound call received over the telephony channel. The authentication response further indicates one or more federated IDs associated the confidence score and/or an indication of the authentication level (e.g., was multi-factor authentication successful).

3 FIG. 3 FIG. 300 shows operations of a methodfor receiving and analyzing voice biometrics (and other types of information) received via various types of communication channels, according to an embodiment. Moreover,depicts dataflow amongst components of a telecommunications system or technical ecosystem during a customer-user's communication journey. For ease of understanding, certain features and functions involve a Federated ID, though embodiments may include any form of intermediate arbitrary ID that each device of the system is preconfigured to ingest and map to another known unique ID. As an example, as shown in TABLE 1 (below), a “tenant_id” field may be an arbitrary identifier value assigned by a call center system or analytics service that may also be used as the value of a “federated_id” field referenced by an identity service. In this non-limiting example, the arbitrary ID of one of call center system or analytics system (“tentant_ID” of “tenant-100”) may be repurposed as the Federated ID (“federated_id” of “100”). The intermediate ID may be generated, assigned, or derived for a given contact according to any number of preconfigured operations or correspondence mappings.

300 111 111 107 111 111 b a a b In particular, the methodincludes an omni-channel dataflow in which a user contacts and interacts with a provider service (e.g., bank, hotel, airline) through various communications channels, such as a data channel for mobile application communications, a data channel for browser-to-webserver communications, and a telephony channel for cellular phone communications, among others. The components of the system include various devices for initiating, conducting, and hosting communications with the user, and authenticating the user to establish a user's authenticated session. The system also includes various devices that authenticate the user contacting the provider service and host the user's authenticated session through the various communication channels through which the user may interact with the enterprise. The various devices include, for example, a provider's data server (e.g., provider data server) hosting enterprise online or web-based services of a provider service; a provider's server (e.g., telephony server) situated at a call center and configured to capture information via a telephony channel; an analytics server of an analytics service; an identity server that executes functions of an external or internal identity service; and an authentication store (e.g., authentication database) associated with the identity server, where the authentication store contains various types of data about users, user devices, or omni-channel sessions established between user devices and provider servers (e.g., telephony servers, provider data servers).

300 As shown in the method, the customer-user's journey begins with using a mobile application executed by a client device to access and interact with a provider's online services, as hosted by the data server. In this example, the user submits a request to confirm the amount of money available in the user's checking account. The client device then transmits one or more types of data for authenticating the user via a data channel for mobile application communications. An authenticated session is established for the user, assuming the user was successfully authenticated by an analytics server. Continuing with this example, the user's journey continues when the user submits a subsequent request to the provider server to initiate a transaction or operation having heightened security requirements (e.g., a funds transfer). In such circumstances, the transaction requested in the first request (e.g., how much money is in the checking account) may be authenticated and authorized using authenticating data gathered entirely through the data channel as an initial form of authentication. For the transaction requested in second request (e.g., transfer funds to another account), the provider data server prompts the user to place a call to the provider's call center to authenticate and confirm the transaction via a telephony channel. Thus, for the second request, the transaction is authenticated and authorized using the authentication that was initially supplied via the data channel and also further authenticating data gathered by the telephony server through the telephony channel. Notably, the authentication that was initially supplied via the data channel can be passively communicated between the various channels, amongst the devices of the system.

301 In operation, the client device accesses, via a data channel, enterprise online services hosted by the provider data server of a provider system. The client device then transmits a first transaction request to the provider data server. The provider data server receives various types of data and metadata from the client device via the data channel and establishes a data-channel session with client device. In some cases, the data server receives data communication from the client device, when the client device requests access to the online services of the provider data server.

303 In operation, the provider server determines that the first transaction request requires out-of-band handling and returns an out-of-band notification to the client device. The out-of-band notification instructs the client device to, for example, contact a call center via a telephony channel. Additionally or alternatively, the out-of-band notification instructs the client device to generate and display a prompt to the customer-caller, via a user interface of the client device, instructing the customer to place a telephone call to the call center via the telephony channel.

The data server receives data inputs from the client device via the data channel and detects a triggering request according to preconfigured triggering instructions in the software programming (e.g., triggering inputs, threshold values, temporal thresholds or expiration timing). Due to detecting the triggering request, the data server determines that an ongoing operational flow or service request (e.g., ongoing chatbot conversation, request to withdraw or transfer funds, generate or update user data) reaches an endpoint requiring the user to switch to another communication channel.

305 The mobile application or the provider data server may capture, parse, and store certain types of information about the user or client device, such as the caller ANI or other signaling metadata. In some implementations, the mobile application or the data server generates certain types of information about the user or the user device, which may include generating a unique ANI (or phone number) or auto-appending random digits to a dialed number as a session identifier (e.g., 800-555-1212∥1234). This information may be included into an auth-trigger notification (as in operation, below) or otherwise stored into one or more data records for the user, client device, or communication session.

305 300 102 105 305 303 3 FIG. In operation, the data server generates an auth-trigger notification, such as a POST notification in the example methodof, containing a federated ID and expected phone number associated with the end-user. The data server transmits the auth-trigger notification to one or more authentication servers, including a computing device configured to perform the various call data analytics and authentication operations described herein (e.g., analytics server), and a computing device configured to perform the various IAM operations described herein (e.g., identity server). For ease of description, the one or more authentication servers are sometimes described as a single authentication server having integrated functions of both analytics and identity servers, though embodiments may include any number of authentication servers having integrated analytics and identity servers. Embodiments may also include multiple authentication servers that include any number of analytics servers and any number of identity servers. Continuing with operation, the authentication server stores the data of the auth-trigger notification into the authentication store as a channel session record associated with the data channel communication session (between the client device and the data server). In some cases, the data server contemporaneously returns the out-of-band channel notification to the client device in response to the detecting the triggering request (as in operation).

In some implementations, the auth-trigger notification is provided to the authentication server with the customer's federated ID and an authentication level (e.g., single-factor authentication, multi-factor authentication). Optionally, the auth-trigger notification includes a session ID and/or an enterprise phone number that route, for example, to the provider call center.

102 In some cases, in the event the journey is from a non-telephony device, such as a desktop web browser or desktop-based softphone telephony software (e.g., Skype®), then the provider data server or authentication server (e.g., analytics server) may extract and generate a browser fingerprint or deviceprint for the caller's web browser associated with the caller ANI or softphone application associated with the caller ANI. The authentication server may create a match of browser fingerprints or device prints to ANIs, such that the authentication server may index a given ANI against any known or previously observed browser fingerprint(s) or deviceprint(s). In this way, the authentication server may notionally or logically treat the browser fingerprint or the deviceprint as a form of “digital ANI.”

307 “auth_id_type”:“voice”, “expires_at”:1652461250, “federated_id”:“100”, “mfa”:false, “phone”:“+13105551212”, “request_id”:“7fde4083-749d-40a0-b9df-c0bfa86a54a8”, “tenant_uid”:“tenant-100”, “timestamp”: “2022 May 13 T 16:59:50.616861” { } In operation, the authentication server generates a channel session record using the data received in the auth-trigger notification and add the session record into the authentication store. The channel session record generated based upon, for example, a database INSERT script query or file (e.g., JSON object) that contains some or all of the data of the auth-trigger notification and instructions for the authentication store to insert and store the channel session record into the non-transitory storage of the authentication store for later reference. The authentication server may assign a Time-to-Live (TTL) interval to the session record for any pre-configured amount of time (e.g., between 0 and N seconds) indicating an amount of time the session record remains valid. An example of the JSON object of the channel session record is shown in TABLE 1 (below).

309 In operation, the user operates and instructs the (same or another) client device to initiate an outbound telephone call to the provider's call center via the telephony channel. The provider's telephony server receives the corresponding inbound call data from the client device via the telephony channel. The inbound call data includes various types of data for identifying the user-caller, the client device, and for presenting to the call center agent to service the user's service requests. Non-limiting examples of the inbound call data includes the inbound phone number (or ANI) of the inbound caller's telephony device (e.g., 310-555-1212); the DNIS associated with the inbound phone call (e.g., 800-555-1212); an audio recording or acoustic data containing samples of the user-caller's voice; user inputs to IVR software executed by the telephony server; and metadata associated with or indicating the user's client device, among other potential types of data.

In some cases, the telephony server receives the inbound call data from a monitoring device of the provider's call center that monitors and captures various types of communication traffic (inbound call data packets) over the telephony channels and forwards the inbound call data to the telephony server. The telephony channels include hardware and software components of telecommunications networks according to telephony-related protocols (e.g., trunks, exchanges, switches, SIP, SS7, POTS, DNIS, ISDN, PSTN, VOIP), where the client device includes, for example, a landline or mobile telephone. In some cases, the telephony server receives telephony channels include hardware and software components for computer-telephone integration (CTI) or digital telephony protocols (e.g., routers, switches, TCP/IP, VOIP), where the client device includes a computer or mobile device executing telephony software, softphone software, teleconferencing software, or integrated telephony software routines of the mobile application.

311 102 106 In operation, the telephony server sends an inbound call notification or the inbound call data to the authentication server to perform the various call analytics and authentication functions described herein (e.g., analytics server). The authentication server receives an inbound call notification or inbound call data from the provider's telephony server. When the call center receives the inbound call, the inbound call data is captured and forwarded to the telephony server, but one or more devices of the provider system may also send a notification to the authentication server. This notification prompts the authentication server to establish a unique audio session ID (shown as “12345-ABCDE”) for the telephony channel communication session and perform one or more analytics operations on the inbound call data. The authentication server may store the audio session ID and other information into one or more databases, such as the authentication store or another database coupled to or hosted by the authentication server(s) (e.g., session database, analytics database). Moreover, the inbound call data includes various types of data for identifying the user and/or the client device, and for presenting information about the user or client device to the call center agent in order to service the user's service requests. Non-limiting examples of the inbound call data includes the one or more session IDs; the audio session ID for the inbound phone call over the telephony channel; telephony metadata for the client device, the inbound phone call (or ANI) of the client device; an audio recording or acoustic data containing samples of the user's voice; user inputs to the IVR software executed by the telephony server; and metadata associated with or indicating the user's client device, among other potential types of data.

311 Continue with the operation, the call analytics functions of the authentication server may return the unique audio session ID, among other types of data associated with the ANI of the client device. This data may be used for performing various authentication operations described further below.

313 In operation, the telephony server transmits an authenticate request, or GET request, to the authentication server. The GET request indicates the user's ANI (e.g., the ANI of the user's client device) and prompts the authentication server(s) to perform the various the IAM operations and analytics operations using the inbound call data.

315 317 307 “auth_id_type”:“voice”, “federated_id”:“100”, “mfa”:false, “phone”:“+13105551212”, “tenant_uid”:“tenant-100”, “timestamp”:“2022 May 13 T 16:59:50.616861”} { In operation, the IAM operations of the authentication server queries the authentication store using the GET request and selects the one or more session records associated with the user's ANI (for the user's session through the data channel). In operation, in response to the query, the authentication server returns various types of inbound contact data received via the data channel in the previously inserted authenticated session ID record (as inserted into the authentication store during operation). The IAM operations of the authentication server determine the user federated ID indicated by the client device(s) and/or the user federated ID indicated by the session ID record. TABLE 2 (below) shows an example of the previously inserted record that the authentication store returns to the IAM operations.

307 The IAM operations include, for example, identifying the federated ID for the inbound user indicated by the inbound data. The IAM operation receives the authentication request containing the phone number, and queries the authentication store for the federated IDs associated with the phone numbers or ANIs in the authentication request. For example, the session record stored into the authentication includes the federated ID (“100”) and expected phone number (“(310) 555-1212”). In this example, the telephony server includes the inbound phone number (“(310) 555-1212”) in the authentication request submitted to the authentication server. Using the inbound phone number (“(310) 555-1212”), the authentication store returns each of the database records and federated IDs (e.g., “100”) associated with the inbound phone number, which in this example, is the same federated ID (“100”) in the session record generated for the data channel (in operation).

319 311 106 In operation, the IAM operations of authentication server(s) sends a request for the analytics operations of the authentication server(s) to compared a federated ID (“100”) enrolled voiceprint against the acoustic features of the current call audio stream for the unique audio session ID (as determined in operation). The IAM operations return the selected federated ID (“100”), among other potential types of data, to the analytics operations of the authentication server. The analytics operations, in turn, query the databases (e.g., analytics database) using the selected federated ID to retrieve various types of enrolled data for authenticating the caller over the telephony channel, and the current call data (and/or current audio stream) associated with the audio session ID (“12345-ABCDE”). The analytics operations retrieve the enrolled vectors and/or enrolled data associated with the selected federated ID against corresponding inbound vectors and/or inbound data generated for the inbound call data or received in the GET request. The analytics operations of the authentication server apply a machine-learning architecture trained for call data analytics and authentication against the inbound call data, which compares the inbound vectors and/or inbound data against enrolled vectors or enrolled data associated with the federated ID expected from the session record.

209 227 229 2 FIG.A 2 FIG.B The analytics operations include, for example, executing one or more machine-learning architecture layers for extracting certain types of embedding feature vectors for registered enrolled users and inbound contact data from users. The analytics operations apply the layers of the machine-learning architecture on the inbound data to extract certain types of features and corresponding types of feature vectors, such as voiceprints, browserprints (sometimes referred to as “browser fingerprints”), or deviceprints (sometimes referred to as “phoneprints”). The features and functions for analytics operations and authentication operations by an analytics server of an analytics service were described previously (e.g., operationof; operations-of) and need not be repeated here.

321 “confidence”:0.8675309, “identity”:100} { In operation, the analytics operations of the authentication server generate and returns an confidence score for the federated ID (“100”) for the current inbound call data (and/or current audio stream) associated with the current audio session ID (“12345-ABCDE”). The authentication server generates a confidence score by comparing an enrollee's voiceprint associated with the federated ID against an inbound voiceprint from the inbound call data. TABLE 3 (below) shows an example of the confidence score data generated by the analytics operations.

229 231 2 FIG.B The analytics operations generate the confidence score by applying layers of a machine-learning architecture on the inbound call data for the session, where the machine-learning architecture extracts inbound feature vectors for the inbound call data and compares the inbound feature vectors against enrolled feature vectors for the federated ID, as stored in the one or more databases. The features and functions of analytics operations for generating the confidence score were described previously (e.g., operations-of) and need not be repeated here.

323 313 “auth ts”:“2022 May 13 T 16:59:50.616861”, “confidence”:0.8675309, “identity”:100, “mfa”:false} { } In operation, the authentication server returns to the telephony server an authentication response corresponding to the GET authentication request (as in operation). The authentication response indicates the authentication results (e.g., confidence score, risk score) generated by the authentication server, among other types of information. The authentication results include, for example, an authentication timestamp, the confidence score generated for the inbound call data associated with the inbound call received over the telephony channel. The authentication response further indicates one or more federated IDs associated the confidence score and/or an indication of the authentication level (e.g., was multi-factor authentication successful). TABLE 4 (below) shows an example of the response data of the authentication results.

325 213 233 2 FIG.A 2 FIG.B In operation, the telephony server determines whether to accept or reject the inbound call based upon the authentication response. The authentication results may further include machine-readable instructions for the telephony server, call center agent device, or caller telephony device to perform based upon whether the telephony server accepted or rejected the inbound call. In accepting the inbound call, the telephony server may, for example, permit the inbound call to continue, route the call to the destination for handling the user's requested services (e.g., route to agent, IVR service), or execute the user's requested services. In rejecting the inbound call, the telephony server may, for example, terminate the inbound call, route the inbound call to a secondary queue for further consideration, or execute one or more mitigating operations. Such mitigating operations performed by the telephony server (or other server) include, for example, requesting additional information from the user, or instructing the authentication server and end-user to successfully perform the multi-factor authentication operation. The features and functions of the telephony server handling the inbound call based upon the authentication response were described previously (e.g., operationsof; operationof) and need not be repeated here. Based on the confidence score, the telephony server routes the inbound call associated with the inbound call data to one or more agent devices, or other type of destination device for the inbound call and the inbound call data. In some implementations, when the telephony server (or other computing device of the provider computing network) routes the inbound call to an agent device, the telephony server transmits machine-readable instructions and various types of data for presenting an authentication results user interface at the agent device or other type of user destination computing device. The authentication results user interface is configured to display the authentication results at the agent device for review by review an administrator or user of the provider's enterprise call center. The authentication results interface displays, for example, the confidence score or risk score, the inbound call data, and the enrolled user data, among other types of information for review by the user of the provider call center.

2 FIG.B In some embodiments, an authentication server (e.g., analytics server, identity server) performs various authentication operations using a federated identifier, which may include an intermediate identifier. A non-limiting example of such embodiment may be found in.

For instance, in some embodiments, a computer-implemented method comprises receiving, by a computer, an auth-trigger notification from a data server of an enterprise service provider network, the auth-trigger notification including an intermediate identifier associated with an end-user and an enrolled phone number expected for a telephony device associated with the end-user; generating, by the computer, a session record including the intermediate identifier and the enrolled phone number; receiving, by the computer from a telephony server of the enterprise service provider network, inbound call data for an inbound call and an authentication request for an inbound call; generating, by the computer, an inbound voiceprint for the inbound call by applying a machine-learning architecture on the inbound call data; and generating, by the computer, a confidence score for the inbound call based upon a distance between a stored enrolled voiceprint associated with the intermediate identifier and the inbound voiceprint.

In some implementations, the auth-trigger notification including the intermediate identifier is associated with an authenticated session for the end-user via a data channel.

In some implementations, the method includes transmitting, by the computer, the confidence score to an agent device of the enterprise service provider network.

In some implementations, the authentication request includes the inbound call data containing an inbound phone number and inbound voice sample data for generating the inbound voiceprint.

In some implementations, the method includes, in response to receiving the authentication request, obtaining, by the computer, the session record having the enrolled phone number matching an inbound phone number by querying the authentication database using the intermediate identifier of the session record.

In some implementations, the method includes, in response to receiving the authentication request, obtaining, by the computer, the stored enrolled voiceprint from a second database by querying the second database for the enrolled voiceprint associated with the intermediate identifier.

In some implementations, generating the session record includes storing, by the computer, the session record into an authentication database.

In some implementations, the method includes receiving, by the computer, from the telephony server, an inbound call notification for the inbound call containing the inbound call data; and generating, by the computer, an audio session identifier associated with the inbound call data and the intermediary identifier.

In some implementations, the method includes applying, by the computer, the machine-learning architecture on the inbound call data to generate at least one of an inbound deviceprint or an inbound browser fingerprint for the telephony device associated with the end-user. The computer generates the confidence score for the inbound call further based upon the distance between the at least one of the inbound deviceprint or the inbound browser fingerprint and at least one of a stored enrolled deviceprint or a stored enrolled browser fingerprint associated with the intermediate identifier.

In some implementations, the computer comprises an authentication server including at least one of an analytics server or an identity server.

In some embodiments, a system comprises an authentication server comprising a processor and configured to: receive an auth-trigger notification from a data server of an enterprise service provider network, the auth-trigger notification including an intermediate identifier associated with an end-user and an enrolled phone number expected for a telephony device associated with the end-user; generate a session record including the intermediate identifier and the enrolled phone number; receive, from a telephony server of the enterprise service provider network, inbound call data for an inbound call and an authentication request for an inbound call; generate an inbound voiceprint for the inbound call by applying a machine-learning architecture on the inbound call data; and generate a confidence score for the inbound call based upon a distance between a stored enrolled voiceprint associated with the intermediate identifier and the inbound voiceprint.

In some implementations, the auth-trigger notification including the intermediate identifier is associated with an authenticated session for the end-user via a data channel.

In some implementations, the authentication server is further configured to transmit the confidence score to an agent device of the enterprise service provider network.

In some implementations, the authentication request includes the inbound call data containing an inbound phone number and inbound voice sample data for generating the inbound voiceprint.

In some implementations, the authentication server is further configured to, in response to receiving the authentication request, obtain the session record having the enrolled phone number matching an inbound phone number by querying the authentication database using the intermediate identifier of the session record.

In some implementations, the authentication server is further configured to, in response to receiving the authentication request, obtain the stored enrolled voiceprint from a second database by querying the second database for the enrolled voiceprint associated with the intermediate identifier.

In some implementations, when generating the session record the authentication server is further configured to store the session record into an authentication database.

In some implementations, authentication server is further configured to receive from the telephony server, an inbound call notification for the inbound call containing the inbound call data; and generating, by the computer, an audio session identifier associated with the inbound call data and the intermediary identifier.

In some implementations, authentication server is further configured to apply the machine-learning architecture on the inbound call data to generate at least one of an inbound deviceprint or an inbound browser fingerprint for the telephony device associated with the end-user. The authentication server generates the confidence score for the inbound call further based upon the distance between the at least one of the inbound deviceprint or the inbound browser fingerprint and at least one of a stored enrolled deviceprint or a stored enrolled browser fingerprint associated with the intermediate identifier.

In some implementations, the authentication server includes an identity server.

2 FIG.A In some embodiments, one or more provider servers (e.g., provider data server, telephony server) requests authentication for inbound contacts, where the authentication processes implement a federated identifier, which may include an intermediate identifier. A non-limiting example of such embodiment may be found in.

For instance, in some embodiments, a computer-implemented method comprises receiving, by a data server associated with an enterprise service provider network, authenticating information for an end-user from a client device via a data channel; transmitting, by the data server, to an authentication server associated with an authentication database, an auth-trigger notification including an intermediate identifier for the end-user associated with the data channel; receiving, by a telephony server associated with the enterprise service provider network, inbound call data from a caller device via a telephony channel; transmitting, by a telephony server associated with the enterprise service provider network, to the authentication server an authentication request including inbound call data received via the telephony channel; and receiving, by the telephony server from the authentication server, an authentication response containing authentication results including a confidence score indicating a distance between an enrolled voiceprint associated with the intermediate identifier for the end-user associated with the data channel and an inbound voiceprint generated for the inbound call data received via the telephony channel.

In some implementations, the auth-trigger notification includes the intermediate identifier associated with the end-user and an enrolled phone number expected for the end-user via a telephony channel.

In some implementations, the inbound call data includes an inbound phone number associated with the caller device and inbound voice sample data for generating the inbound voiceprint.

In some implementations, the method includes detecting, by the data server, a triggering transaction request for the data channel indicating an endpoint for a communication session between the client device and the data server for the data channel.

In some implementations, the method includes receiving, by the data server, a transaction request from the client device via the data channel; determining, by the data server, that the transaction request satisfies a triggering condition for a second channel of authentication; and transmitting, by the data server to the client device via the data channel, authentication instructions for the second channel of authentication.

In some implementations, the authentication instructions include a prompt for display at a user interface of the client device.

In some implementations, the authentication instructions include executable instructions for generating the inbound call data at the caller device.

In some implementations, the method includes routing, by the telephony server, an inbound call associated with the inbound call data based upon the confidence score received from the authentication server.

In some implementations, the telephony server routes the inbound call to an agent device and transmits a results interface for displaying the authentication results at the agent device.

In some implementations, the confidence score further indicates the distance between at least one of an inbound deviceprint or an inbound browser fingerprint and at least one of a stored enrolled deviceprint or a stored enrolled browser fingerprint associated with the intermediate identifier.

In some embodiments, a system comprises a data server and a telephony server associated with an enterprise service provider network, each comprising a respective processor. The data server is configured to receive authenticating information for an end-user from a client device via a data channel; and transmit to an authentication server associated with an authentication database, an auth-trigger notification including an intermediate identifier for the end-user associated with the data channel. The telephony server is configured to receive inbound call data from a caller device via a telephony channel; transmit to the authentication server an authentication request including inbound call data received via the telephony channel; and receive, from the authentication server, an authentication response containing authentication results including a confidence score indicating a distance between an enrolled voiceprint associated with the intermediate identifier for the end-user associated with the data channel and an inbound voiceprint generated for the inbound call data received via the telephony channel.

In some implementations, the auth-trigger notification includes the intermediate identifier associated with the end-user and an enrolled phone number expected for the end-user via the telephony channel.

In some implementations, the inbound call data includes an inbound phone number associated with the caller device and inbound voice sample data for generating the inbound voiceprint.

In some implementations, the data server is configured to detect a triggering transaction request for the data channel indicating an endpoint for a communication session between the client device and the data server for the data channel.

In some implementations, the data server is configured to receive a transaction request from the client device via the data channel; determine that the transaction request satisfies a triggering condition for a second channel of authentication; and transmit, to the client device via the data channel, authentication instructions for the second channel of authentication.

In some implementations, the authentication instructions include a prompt for display at a user interface of the client device.

In some implementations, the authentication instructions include executable instructions for generating the inbound call data at the caller device.

In some implementations, the data server is configured to route an inbound call associated with the inbound call data based upon the confidence score received from the authentication server.

In some implementations, the telephony server is configured to route the inbound call to an agent device and transmit a results interface for displaying the authentication results at the agent device.

In some implementations, the confidence score further indicates the distance between at least one of an inbound deviceprint or an inbound browser fingerprint and at least one of a stored enrolled deviceprint or a stored enrolled browser fingerprint associated with the intermediate identifier.

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, attributes, or memory contents. Information, arguments, attributes, 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.