CN117769831A - Determining and displaying estimated hold duration for call - Google Patents

Abstract

An estimated hold duration of the call is determined and displayed. An identifier of the target entity is obtained, which may be used by the first calling device to initiate a call between the first calling device and the target entity. The determination of hold duration is an estimated amount of time before the call matches the human agent when the call is initiated at a particular time that is expected for the current time. The hold duration is determined based on previous calls between the one or more calling devices and the target entity. The hold duration is provided for display by the first calling device prior to initiating a call between the first calling device and the target entity.

Description

Determining and displaying estimated hold duration for call

Cross Reference to Related Applications

The present application claims priority from U.S. patent application Ser. No.17/540,849, entitled "Determination and Display of Estimated Hold Duations for Calls (determining and displaying estimated hold duration for calibration calls)" filed on month 2 of 2021, which claims priority from U.S. provisional patent application Ser. No.63/236,648, entitled "Determination and Display of Estimated Hold Duations for Calls", filed on month 8 of 2021, which is incorporated herein by reference in its entirety.

Background

People make many telephone calls to businesses or other entities to obtain information, arrange services, etc. The entity's human agent will typically talk to the caller to obtain an automatic response to a particular request or service that is not readily handled. Many entities are unable to handle the volume of calls received from callers for such information and services and therefore require some callers to wait in a hold queue until human agents are available for their calls. Some entities provide human agents with an estimate of latency. Such an estimate is determined by the entity based on factors such as the number of callers currently in the hold queue and the availability of human agents.

The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

Disclosure of Invention

Embodiments of the present application relate to determining and displaying an estimated hold duration for a call. In some implementations, a computer-implemented method includes obtaining an identifier of a target entity that is usable by a first calling device to initiate a call between the first calling device and the target entity. The determination of hold duration is an estimated amount of time before the call matches the human agent when the call is initiated at a particular time that is expected for the current time. The hold duration is determined based on a plurality of previous calls between the one or more calling devices and the target entity. The hold duration is provided for display by the first calling device prior to initiating a call between the first calling device and the target entity.

Various embodiments and examples of the method are described. For example, in some implementations, obtaining the identifier, determining the hold duration, and providing the hold duration to be displayed are performed by a server device in communication with the first calling device, the obtaining the identifier includes receiving, at the server device, the identifier from the first calling device that has received the identifier based on user input to the first calling device, and the providing the hold duration to be displayed includes transmitting the hold duration from the server device to the first calling device for display by the first calling device. In some implementations, obtaining the identifier, determining the hold duration, and providing the hold duration to display are performed by the first calling device, and determining the hold duration includes accessing a data structure of the hold duration or the machine learning model stored in a local store of the first calling device, the data structure outputting the hold duration in response to an input including the target entity and the specific time. In some implementations, obtaining the identifier, determining the hold duration, and providing the hold duration to be displayed are performed by the first calling device, and determining the hold duration includes: requesting a hold duration from a server device over a communication network; transmitting the identifier from the first calling device to a server device, the server device determining the hold duration based on the identifier; and receiving a hold duration from the server device at the first calling device prior to initiating the call between the first calling device and the target entity, and requesting the hold duration to be performed prior to obtaining the full version of the identifier of the target entity.

In some implementations, determining the hold duration is based on use of a machine learning model or data structure; the machine learning model receives an input comprising an identifier and a time of a call and outputs a result indicative of an estimated duration of hold of the call, and trains based on training data comprising the identifier, an initiation time of a previous call, a duration of the call of the previous call, and the duration of hold of the previous call; and the data structure stores an estimated hold duration of the entity, the hold duration based on a plurality of previous calls. In some implementations, the one or more calling devices are a plurality of calling devices associated with a plurality of users.

In some implementations, the hold duration is determined based on call duration data indicating a plurality of call durations of a plurality of previous calls between the one or more calling devices and the target entity, and the hold duration data indicating a plurality of hold durations of the previous calls. In some examples, the plurality of previous calls have a call duration greater than a threshold duration and calls having a call duration less than the threshold duration are excluded, and one or more of the hold durations are based on a corresponding call duration of the call duration greater than the threshold duration. In a further example, one or more hold durations are determined based on a function of estimating one or more hold durations of one or more previous calls, and a threshold duration and function are customized for a target entity associated with the identifier.

In some implementations, the method further includes causing the first calling device to display a particular time in association with the display of the hold duration, the particular time being at least one day prior to the current time.

In some embodiments, the method further comprises determining a plurality of hold durations for a plurality of intended calls, the plurality of hold durations comprising the hold duration, wherein each hold duration of the plurality of hold durations indicates a respective estimated amount of time before an associated intended call is matched to the human agent when the respective call time before the current time is initiated, and wherein the respective call times are different from each other; and causing the plurality of hold durations to be displayed in association with respective call times of the plurality of hold durations. In some embodiments, the method further comprises: receiving user input selecting an intended call having a particular hold duration of a plurality of hold durations and a particular call time associated with the particular hold duration; and scheduling the selected intended call at a particular call time in a calendar associated with the first calling device. In some examples, a notification is output by the first calling device indicating that a particular call time is approaching or has arrived. In some examples, the call between the first calling device and the target entity is automatically initiated by the first calling device at a particular call time.

In some embodiments, the hold duration to be displayed is caused to be performed during a first call between the first calling device and the target entity, the call between the first calling device and the target entity being a second call, and the first call being initiated prior to initiation of the second call resulting in between the first calling device and the target entity. In some embodiments, the method further comprises: causing a prompt for user feedback to be displayed after termination of the call between the first call device and the target entity; receiving user feedback indicating a degree of accuracy of the hold duration; and updating a data structure or model for determining the hold duration based on the user feedback.

In some implementations, a system for providing hold duration estimation of a call includes a memory storing instructions and at least one processor coupled to the memory, the at least one processor configured to access the instructions from the memory to perform operations. The operations include: obtaining an identifier of a target entity, the identifier being usable by a first calling device to initiate a call between the first calling device and the target entity; determining a hold duration, the hold duration being an estimated amount of time before the call matches a human agent when the call is initiated at a particular time that is expected for a current time, the hold duration being determined based on a plurality of previous calls between one or more calling devices and the target entity; and providing the hold duration to be displayed by the first calling device prior to initiating the call between the first calling device and the target entity.

In various embodiments of the system, the operation of determining the hold duration is based on call duration data indicating a plurality of call durations of previous calls between the one or more calling devices and the target entity, and hold duration data indicating a plurality of hold durations of previous calls. In some implementations, the further operations include determining a plurality of hold durations including a hold duration, each of the hold durations indicating a respective estimated amount of time before the call matches the human agent when the call is initiated at a respective time of the call that is expected to be different from the current time and the respective times of the call are different from each other; and causing the hold durations to be displayed in association with their respective call times. In various implementations, the operations may include one or more features of the methods described above.

In some implementations, a non-transitory computer-readable medium having instructions stored thereon, which when executed by a processor, cause the processor to perform operations. The operations include: obtaining an identifier of a target entity, the identifier being usable by a first calling device to initiate a call between the first calling device and the target entity; determining a hold duration, the hold duration being an estimated amount of time before the call matches a human agent when the call is initiated at a particular time that is expected for a current time, the hold duration being determined based on a plurality of previous calls between a plurality of calling devices and the target entity, and the plurality of calling devices being associated with a plurality of users; and providing the hold duration to be displayed by the first calling device prior to initiating a call between the first calling device and the target entity. In various implementations, the operations may include one or more features of the methods or systems described above.

Drawings

FIG. 1 is a block diagram of an example system that may be used with one or more embodiments described herein;

FIG. 2 is a flow chart illustrating an example method for determining and displaying an estimated hold duration for an intended call, according to some embodiments;

FIG. 3 is a flow chart illustrating an example method of constructing a data structure and/or model for estimating a hold duration of an intended call based on previous calls, in accordance with some embodiments;

FIG. 4 is a flow chart illustrating an example method for determining a hold duration of an intended call to a target entity, according to some embodiments;

5-8 are schematic diagrams of a user interface displayed by a calling device, wherein a hold duration of an intended call is displayed prior to initiating the call, according to some embodiments;

fig. 9 and 10 are schematic diagrams of user interfaces displayed by a calling device, in which a hold duration of an intended call is displayed during a call, according to some embodiments; and

FIG. 11 is a block diagram of an example device that may be used in one or more embodiments described herein.

Detailed Description

One or more embodiments described herein relate to determining and displaying an estimated hold duration for a call. In various embodiments, a method includes obtaining an identifier of a target entity. The identifier may be used by the calling device to initiate a call between the calling device and the target entity; for example, a telephone number or other identifier may be dialed to connect to the enterprise and establish a call. One or more hold durations are determined for the estimated amount of time before the call matches the human agent. The call for which the hold duration is determined is initiated at a call time subsequent to the current time and is not an intended call for the currently ongoing call. The hold duration is determined based on previous calls made to the target entity, for example, by multiple users of the calling device. The determined hold duration may be displayed by the calling device prior to initiating the intended call between the calling device and the target entity.

Various additional features are described. For example, in some embodiments, determining the hold duration may be performed by a server in communication with the calling device, wherein the server may send the hold duration to the calling device for display. In some implementations, obtaining the identifier and determining and displaying the hold duration may be performed by the calling device. In various embodiments, determining the retention time duration may include accessing a data structure storing the retention time duration. In some implementations, a machine learning model is used that outputs a hold duration in response to an input call characteristic of an intended call, such as a target entity and a time of call of the intended call. In various embodiments, the data structures and/or models may be stored on a server or in a local store of the calling device. In some implementations, the client device may request a hold duration from a server or other remote device before obtaining a full version of the identifier of the target entity.

In some implementations, the hold duration is determined based on call duration data indicating a call duration of a previous call between the calling device and the target entity, and the hold duration data indicating the hold duration of the previous call. For example, a previous call for determining the hold duration has a call duration greater than a threshold duration and a call having a call duration less than the threshold duration is excluded. One or more of the previous call-on-hold durations may be based on the corresponding call duration being greater than a threshold. In some implementations, the previous call hold duration is based on a function, where the threshold duration and function may be customized for the target entity associated with the identifier.

In some implementations, a plurality of hold durations for the intended call are determined at a plurality of respective call times that are different from one another, and the plurality of hold durations may be displayed in association with their respective call times. In some implementations, the user input may select an intended call having a particular hold duration and intended call time, and automatically schedule the selected intended call at its call time in a calendar associated with the user. For example, a notification may be output by the calling device indicating that a particular call time is approaching or has arrived, and/or a selected call may be automatically initiated between the calling device and the target entity at the particular call time.

The described techniques and features have several advantages. The described embodiments provide the user with an estimate of the hold duration of an expected call that has not yet been initiated. This is in contrast to previous systems that provided an estimated hold time for a call currently in progress, but do not provide the hold duration information of the call to the user prior to initiating the call. With the estimate of hold duration for the intended call, the user can plan and schedule the call more efficiently and with less potential frustration than would be the case for the calling entity without such information. The described techniques may provide users with an estimated hold duration for calls that are now initiated and/or initiated one or more hours or days in the future, allowing users to plan calls on the time and day that have the most convenience and time efficiency for their schedules and their devices. In addition, notifications may be provided to the user regarding planned calls and the duration of hold for those calls.

Furthermore, the various embodiments described herein use the call characteristics of previous calls made by the user to determine an estimated hold duration without the need for data received from a target entity (or an associated entity like a call center). For example, such data may indicate current or expected availability of agents, e.g., based on internal monitoring of agents and calls performed by the target entity or associated entities, and/or may indicate the number of callers currently in a hold queue awaiting speech to the target entity's human agent. The techniques described herein do not require the use of such agent availability and currently maintaining queue data. For example, the described techniques may estimate hold durations based on data related to previous calls by users and user devices without using current agent availability data, current hold queue data, or other data received from a target entity or associated entity. This previous call data may include a hold duration of the previous call that is automatically determined by the device, determined based on user feedback, and/or determined based on other call characteristics, such as the call duration of the previous call, thus providing a robust estimate of the hold duration for calls on different upcoming days and times. Thus, the described techniques may be used to estimate the hold duration of any call for which previous call data is available, e.g., calls made at times and/or to entities for which no current agent availability data or hold queue data is available or known.

A technical effect of one or more of the described embodiments is that the device expends less computing resources to obtain results. For example, a technical effect of the described techniques is a reduction in consumption of system processing resources and power resources as compared to existing systems that do not provide one or more of the described techniques or features. For example, such existing systems may require a user to make a number of different calls to attempt to connect with human agents at a target entity, each call requiring the user to hold an amount of time that the user does not know in advance. The user will typically terminate the call before connecting with the agent and attempt to call the target entity again at a different time in hopes that the hold duration will be smaller at that time. Such multiple attempts at calling wastefully consume system resources. The features described herein may reduce such drawbacks by, for example, displaying the hold duration of an intended call that has not yet been initiated, allowing the user to make the call more efficiently and taking into account the known hold duration at different call times, generally resulting in fewer calls being initiated and reducing overall processing and power requirements of the calling device, the target entity, and other devices communicating with the calling device to enable the call.

Further, in some implementations, the data structures and/or models may be used to determine the hold duration and may be constructed and stored prior to the call made by the user and prior to the determination of the hold duration. The pre-built data structures and/or models may be efficiently accessed by the calling device via local storage or efficient communication with the remote device such that consumption of processing and networking resources during and prior to the call is reduced. In contrast, some existing systems may require data indicating current availability of agents at the target entity and/or the current number of callers in the hold queue to determine a current hold time estimate, which may require additional system processing and networking resources.

Further to the description herein, a control may be provided to the user that allows the user to make a selection as to whether and when the system, program, or feature described herein may enable collection of user information (e.g., information about the user's social network, social actions or activities, profession, user preferences, user's current location, user's message, outgoing call placed by the user or user's device) and whether the user is sent content or communication from a server. In addition, certain data may be processed in one or more ways before being stored or used such that personally identifiable information is removed. For example, the identity of the user may be processed such that personally identifiable information cannot be determined for the user, or the geographic location of the user may be summarized where the location information is obtained (such as to a city, zip code, or state level) such that a particular location of the user cannot be determined. Thus, the user may have control over what information the user gathers, how to use the information, and what information is provided to the user.

FIG. 1 illustrates a block diagram of an example network environment 100 that may be used in some embodiments described herein. In some implementations, the network environment 100 includes one or more server devices, such as the server system 102 in the example of fig. 1. For example, server system 102 may communicate over network 130. The server system 102 may include a server device 104 and a database 106 or other storage device. Network environment 100 also includes one or more client devices, such as client device 120, client device 122, client device 124, and client device 126, which may communicate with server 102, each other, and/or other devices via network connection 130. The network 130 may be any type of communication network including one or more of the internet, a Local Area Network (LAN), a wireless network, a switch or hub connection, and the like. In some implementations, network 130 may include peer-to-peer communication between devices 120-126, e.g., using a peer-to-peer wireless protocol (e.g.,Wi-Fi direct, etc.) or a server with one client device acting as another client device, etc. Two client devices One example of peer-to-peer communication between 120 and 122 is shown by arrow 132.

For ease of illustration, FIG. 1 shows one block of server system 102, server device 104, and database 106, and four blocks of client devices 120, 122, 124, and 126. Server blocks 102, 104, and 106 may represent a plurality of systems, server devices, and network databases, and the blocks may be provided in a different configuration than that shown. For example, server system 102 may represent a plurality of server systems that may communicate with other server systems, e.g., via network 130. In some implementations, the server system 102 can include, for example, a cloud-hosted server or a server that provides call services (e.g., voice over internet protocol, VOIP). In some examples, database 106 and/or other storage devices may be provided in a server system block separate from server device 104 and may communicate with server device 104 and other server systems via network 130. Moreover, any number of client devices may be present. In some examples, server system 102 communicates wirelessly with a client device over network connection 130, which provides various features that may be enabled or supplemented by signals from a server mobile device.

Server system 102 and client devices 120-126 may be any type of device used in a variety of applications, such as desktop computers, laptop computers, portable or mobile devices, cellular telephones, smart phones, tablet computers, televisions, television set-top boxes or entertainment devices, wearable devices (e.g., display glasses or goggles, head Mounted Displays (HMDs), headphones, earplugs, body bands, wrist watches, headsets, armbands, jewelry, etc.), virtual Reality (VR) and/or Augmented Reality (AR) enabled devices, personal Digital Assistants (PDAs), media players, gaming devices, etc. Some client devices may also have a local database similar to database 106 or other storage. In other embodiments, network environment 100 may not have all of the components shown and/or may have other elements including other types of elements in place of or in addition to those described herein.

In various implementations, the client devices 120-126 may interact with the server system 102 via applications running on the respective client devices and/or the server system 102. For example, the respective client devices 120, 122, 124, and 126 may communicate data to and from the server system 102. In some implementations, the server system 102 can send various data, such as content data (e.g., audio, images, video, messages, emails, etc.), notifications, commands, etc., to all or a particular one of the client devices. Each client device may send appropriate data, such as replies, requests for data, notifications, user commands, call requests, etc., to server system 102. In some examples, the server and client devices may transmit various forms of data, including text data, audio data, video data, image data, or other types of data.

In various implementations, end users U1, U2, U3, and U4 may communicate with server system 102 and/or each other using respective client devices 120, 122, 124, and 126. In some examples, users U1, U2, U3, and U4 may interact with each other via applications running on respective client devices and/or server systems 102 and/or via web services implemented on server systems 102, such as social networking services or other types of web services. In some implementations, the server system 102 can provide appropriate data to the client devices such that each client device can receive communication content or shared content uploaded to the server system 102 and/or web service. In some embodiments, a "user" may include one or more programs or virtual entities, as well as people interfacing with a system or network.

User interfaces on client devices 120, 122, 124, and/or 126 may enable display of user content and other content, including images, video, data, and other content, as well as communications (e.g., for telephone or internet calls, video conferences, synchronous or asynchronous chat, etc.), privacy settings, notifications, and other data. Such a user interface may be displayed using software on a client device, software on a server device, and/or a combination of client software and server software executing on server device 104, such as application software or client software in communication with server system 102. The user interface may be displayed by a display device of the client device or the server device, such as a touch screen or other display screen, projector, or the like. In some implementations, an application running on a server system may communicate with a client device to receive user input at the client device and output data such as visual data, audio data, and the like at the client device.

Various applications and/or operating systems executing on the server and client devices may implement various functions, including communication applications (e.g., connecting and providing audio calls, video conferences, chat or other communications), email applications, display of content data, privacy settings, notifications, browsers, etc. The user interface may be displayed on the client device using an application or other software executing on the client device, software on the server device, and/or a combination of client software and server software executing on the server 102, such as application software or client software in communication with the server 102. The user interface may be displayed by a display device of a client device or a server device, such as a display screen, projector, or the like. In some implementations, an application running on a server can communicate with a client device to receive user input at the client device and output data such as visual data, audio data, and the like at the client device. In some implementations, one or more devices of the network environment 100, such as one or more servers of the server system 102, may maintain electronic encyclopedias, knowledge maps, one or more databases, corpora of words, phrases, symbols, and other information, social networking applications (e.g., social graphs, social networks of friends, social networks of businesses, etc.), websites for places or locations (e.g., restaurants, auto dealers, etc.), mapping applications (e.g., websites looking up map locations), call characteristics and data, and so forth. In some implementations, the server system 102 can include a classifier for a particular type of content item (e.g., text or image) and can determine whether any particular class is detected in the received content item.

Some implementations may provide one or more features described herein on a client or server device that is disconnected from or intermittently connected to a computer network. In some implementations, the client device can provide features and results for asynchronous communications as described herein, e.g., via chat or other messages.

The machine learning model may be used by the server system 102 and/or one or more client devices 120-126 as described herein. In some implementations, the machine learning model may be a neural network having one or more nodes arranged according to a network architecture, e.g., in one or more layers, where the various nodes are connected via the network architecture and have associated weights. For example, in a training phase of the model, the model may be trained using training data, and then in an inference phase, the trained model may determine an output based on the input data. In some implementations, the model may be trained offline, for example, on a test device in a test laboratory or other setting, and the trained model may be provided to a server executing the model. In some implementations, the trained model may be retrained or updated locally on the device, or the untrained model may be trained on the device. In some implementations, with user permissions, one or more trained models may be updated with federal learning, for example, where individual server devices may each perform local model training, and updates to the models may be aggregated to update one or more central versions of the models.

Fig. 2 is a flowchart illustrating an example method 200 for determining and displaying an estimated hold duration for an intended call, in accordance with some embodiments. In some implementations, the method 200 may be implemented on a server, such as the server system 102 shown in fig. 1. In some implementations, some or all of the blocks of method 200 may be implemented on one or more client devices (e.g., client devices 120, 122, 124, and/or 126 as shown in fig. 1), one or more server devices, and/or both server devices and client devices. In the depicted example, the system implementing the blocks of method 200 includes one or more processor hardware or processing circuitry ("processors") and may access one or more storage devices, such as database 106 or other accessible storage. In some implementations, different components of one or more server systems may perform different blocks or portions of the blocks.

Some embodiments may initiate the method 200 or portions thereof based on user input. For example, the user may have selected the initiation of method 200 or a particular box of method 200 from the displayed user interface. In some implementations, the method 200, or portions thereof, may be performed via user input with guidance by a user. In some implementations, the method 200 or portions of the method may be initiated automatically by the device. For example, the method (or portions thereof) may be initiated periodically or based on the occurrence of one or more particular events or conditions. For example, such events or conditions may include obtaining data indicative of one or more previous calls that have been performed by the device or other devices, a predetermined period of time that has expired since the last execution of method 200, and/or one or more other events or conditions that may be specified in the settings of the device implementing method 200. In some examples, a device (server or client) may perform the method 200 with access to call characteristic data (if user consent is received).

In block 202, it is checked whether user consent (e.g., user permissions) has been obtained to use the user data in an embodiment of the method 200. For example, the user data may include user preferences, user call characteristic data, responses of user selections, other content in a user interface of the device, or other items of content data in a collection of content (e.g., calls associated with the user), messages sent or received by the user, information about the user's social network and/or contacts, content ratings, the user's geographic location, historical user data, and so forth. In some implementations, one or more blocks of the methods described herein can use user data.

If user consent has been obtained from the relevant user that may use the user data in method 200, then in block 204, the blocks of determining the method herein may be implemented with possible use of the user data described by those blocks, and the method continues to block 208. If user consent has not been obtained, then it is determined in block 206 that the block will be implemented without using the user data, and the method continues to block 208. In some implementations, if user consent has not been obtained, the remainder of method 200 is not performed and/or particular blocks using user data are not performed. In some implementations, if user consent has not been obtained, the blocks of method 200 will be implemented without using user data and with commonly or publicly accessible and publicly available data.

In block 208, a data structure and/or model of hold duration is constructed based on data related to previous calls (e.g., telephone calls, voice calls, or other calls placed via an Over The Top (OTT) service) of one or more users. Using a data structure or model, hold durations are estimated for various entities that have made previous calls. As mentioned herein, various entities are called via identifiers associated with the entities, such as telephone numbers or other address information (e.g., user names, email addresses, user identifiers, etc., tokens mapped to telephone numbers or other address information, hashes of telephone numbers, or other address information, etc.), allowing voice communications. An entity may include any of a variety of people, organizations, businesses, groups, and so forth.

In some implementations, the estimated hold duration is determined using call characteristics of previous calls made by the user and no data from the target entity (or associated entity like a call center) is required. Such data may include data indicative of current or expected availability of agents, e.g., based on internal monitoring of agents and calls performed by the target entity or associated entities, and/or data indicative of the number of callers currently in a hold queue awaiting speech to a human agent of the target entity. For example, the target entity (or associated entity) may track human agent availability at various times and track the number of callers on hold and may be able to provide an estimate of hold duration based on that data. The techniques described herein do not require the use of such data, e.g., the techniques herein may use data related to previous calls based on the use of the user device and not requiring the use of current agent availability data, current hold queue data, or other data received from the target entity or associated entity. Thus, the described techniques may be used to estimate the hold duration of any call for which user call data is available, e.g., calls made at times and/or to entities for which no current agent availability data or hold queue data is available or known.

Block 208 may be performed as a preprocessing block that determines and stores data structures and/or models prior to initiating a call to a target entity and prior to determining and displaying the hold durations of the current call and the intended call, as described below. In various embodiments, the data structure or model may be in different forms. For example, in some implementations, the data structure is a table, graph, or other data structure that indicates particular identifiers (e.g., telephone numbers or other address information) of various entities and estimated hold durations of other call characteristics, such as call time. These estimated hold durations are determined based on various call characteristics of previous calls made to the entity by one or more users. In some implementations, a model, such as a machine learning model, may be constructed that may be trained based on data indicative of call characteristics of previous calls made by a user to an entity. In the inference phase, the machine learning model may output an estimated hold duration based on the input of one or more call characteristics.

Some examples of building data structures and holding duration models are described below with reference to FIG. 3. The method continues to block 210.

In block 210, it is determined whether the calling device is to store the data structure and/or model (or a portion thereof) in a local store of the calling device. A calling device is a device (e.g., client devices 120-126 of fig. 1 or other device) that may be used to place a call to an entity. In some implementations, the calling device may access a data structure or model that is already stored in a local store of the calling device (e.g., a local memory or other local storage device) to determine an estimated duration of hold of the entity. In some implementations, a data structure, such as a table or list, may be stored locally that stores the hold durations previously determined for particular entities or entity identifiers. The calling device may typically access such data structures faster than accessing data stored on the remote device via the network.

In some implementations, a model, such as a machine learning model, computational graph, or other model or data structure, may be stored in a local store of the calling device. The calling device may access such a local model by providing input to the model and obtaining output from the model without having to access the model (or request to use and output the model) provided by the remote device over a network connection. Accordingly, the calling device may be prepared in block 212 using the data structure and/or model to at least partially determine the hold duration of the calling device locally.

If the calling device does not store the data structure and/or model in local storage, the method continues to block 214 as described below. For example, the calling device may dynamically access data or models on the remote device to determine an estimated hold duration when needed, as described with reference to fig. 4.

If the calling device stores the data structure and/or model (or portions thereof) in a local store, the method continues to block 212 where the data and/or model(s) are downloaded by the calling device from a remote device over a network and stored in the calling device's local store. For example, the data structure (or portion thereof) of the estimated hold duration of the entity and/or entity identifier may be obtained from a remote device, such as a server, a different client device, or other device on the network. In some implementations, a subset of entity names and/or entity identifiers available on the remote device, or a portion of a data structure, may be obtained for storage on the calling device. For example, the most popular entity identifiers for calls made by users (e.g., most frequently used within a particular time period, and/or most frequently used by users located in the same geographic location or area of the calling device or having other characteristics similar to those of the user/calling device) may be downloaded to the calling device. In some implementations, a portion of the complete data structure may be downloaded to the calling device, e.g., to accommodate more limited local storage on the calling device. For example, a portion of the data structure may be downloaded that provides a duration of holding of the entity identifier in the country of the user or the country in which the calling device is currently located.

Additionally or alternatively, the model or a portion of the model may be downloaded over a network from a remote device to a local store of the calling device. Some examples of models (e.g., machine learning models) are described with reference to fig. 3. In some implementations, a portion of the model may be downloaded to the calling device, for example, to accommodate more limited local storage on the calling device. For example, a portion of a machine learning model structure may be downloaded that determines a duration of retention of entity identifiers in a country of the user or a country in which the calling device is currently located.

In some implementations, after the data structures and/or models are built in block 208, such data structures and/or models may be received by the calling device and may be updated with new data and/or new model components based on particular conditions occurring, e.g., periodically after each particular period of time, in response to updating the data or models at the remote device (e.g., based on recent calls made by the user, adding new entities or entity identifiers, etc.), etc. The method may continue to block 214.

Step 214, obtaining, by the calling device, an identifier of the target entity. The identifier may be, for example, a telephone number or other call name, or other address information (e.g., a user name, an email address, a user identifier, etc., a word mapped to the telephone number or other address information, a hash of the telephone number or other address information, etc.). The entity identifier allows a call to be initiated by the calling device to the target entity. In various embodiments and/or situations, the entity identifier may be obtained in any of several ways. For example, the entity identifier may be obtained via user input from a user of the calling device. Such user input may include a user selecting a key of a physical or virtual keypad to enter an identifier. In some examples, the entity identifier may be obtained in response to a user selecting a contact entry in a contact list stored on the calling device, which causes an identifier associated with the contact entry to be automatically retrieved from storage and provided for use. For example, the identifier may be entered or provided to an application running on the calling device, such as a dialer application that originated the call or another application that may originate the call. In some other examples, the entity identifier may be obtained from another application running on the calling device or from a remote device over a network.

In some examples, the entity identifier is received independent of the call, e.g., to view the displayed hold duration for one or more upcoming calls to the target entity, without initiating the call upon receipt of the identifier. In other examples, the entity identifier is received to initiate the call to the target entity immediately at the current time, e.g., the identifier is received in a dialer application and control of initiating the call is selected by the user or the call is initiated automatically by the calling device. In some embodiments, the entity identifier is received during the (current) call or after a call to the target entity is being or has been initiated, e.g. the entity identifier initiating the current call, which may be already in progress, or initiating a second call to a target entity different from the call already in progress is received by the calling device. Some examples of obtaining the identifier of the target entity are described below with reference to fig. 4.

In block 216, it is determined whether a call is in progress. For example, in some cases, the call in progress may be a call initiated in response to receiving an identifier of the target entity in block 214, e.g., by a user selecting a contact or other control and/or call control in the application to initiate the call. In some cases, the ongoing call may be a specified call that was previously selected by the user and was initiated at a specified call time in a previous iteration of method 200, e.g., via block 228. If there is no ongoing call, the method continues to block 220, as described below.

If there is an ongoing call (e.g., "current call"), the method continues to block 218 where an estimated hold duration associated with the current call is determined and displayed on the calling device. The hold duration is an estimated amount of time before matching with the human agent during the call, e.g., before the human agent is available, and a call speaking to the user may be joined during the call. In some implementations, the hold duration may be retrieved from a data structure, where the hold duration was previously determined based on call characteristic data. In some implementations, the hold duration may be determined using one or more models, such as machine learning models, as described herein with reference to blocks 210 and 212 and fig. 3. The data structures and/or models may be stored in a memory local to the calling device or may be accessed remotely by the calling device on a remote device over a network connection. Some examples of determining the hold duration are described with reference to fig. 3 and 4. For example, the hold duration of the current call in block 218 may be determined similar to the hold duration of one or more of the intended calls in block 220 described below.

In some implementations, it may be determined whether the calling device has been placed on hold by the target entity in the current call. For example, after a call has been initiated later and a call connection is established between the calling device and the target entity, and the user requests or selects to talk to the human agent during the call, the calling device may be placed on hold by the target entity, e.g., by the target entity's automated system, since no human agent is immediately available to the user in the call. In some implementations, the hold duration may be determined and displayed in block 218 only if the current call is on hold. In some implementations, the hold duration may be determined and displayed for the current call in block 218 regardless of whether the current call is on hold. In some implementations, the user can specify to the calling device that the call is on hold, for example, by selecting a displayed control or option in a user interface of the calling device. In some implementations, the calling device may automatically detect whether the call is on hold without user input or intervention, for example, by determining whether the entity's automated system is indicating that the call is on hold using voice recognition techniques via a particular word (e.g., "the agent may answer your call in 10 minutes, thank you for waiting") or via music play indicating a hold status.

In block 220, one or more estimated hold durations associated with one or more intended calls initiated by the calling device to the target entity at a time later than the current time are determined based on the call characteristic data and/or the model. In some implementations, the intended call is a call that has not been initiated by the calling device and that does not include any calls that are currently in progress by the calling device. For example, one or more of the intended calls may be initiated immediately after the hold duration is determined and displayed (as in block 222), or may be initiated at a further future call time, such as hours or days after the hold duration is displayed.

A plurality of hold durations may be determined in block 220, each hold duration associated with a different intended call initiated at a different intended call time later than the current time. The hold duration is determined based on call characteristic data and may be retrieved from a data structure in which it was stored after a previous determination and/or may be determined based on one or more models, such as machine learning models. The data structures and/or models may be stored in a memory local to the calling device or may be accessed remotely by the calling device on a remote device over a network connection. In various examples, the hold duration of the intended call may be determined prior to any call being initiated (e.g., prior to selecting call control), during one or more current calls in progress, after the call is terminated, etc. Some examples of determining the hold duration are described with reference to fig. 4.

In block 222, the hold duration determined in block 220 is caused to be displayed by the calling device, e.g., the hold duration is determined prior to initiating the intended call. For example, the expected time of the expected call and its associated estimated hold duration may be displayed within a user interface of the calling device, such as within an interface of a dialer application, or in a message or notification displayed on the calling device. If a call has not been initiated on the calling device, the expected call time and hold duration (or as a notification of the operating system) may be displayed in an interface of the dialer application or other application so that the user may view the expected hold duration before initiating the call. If it is determined in block 220 that a call is currently being placed on the calling device for the hold duration, the desired call time and hold duration may be displayed in separate windows or display areas and/or control of the call time and hold duration may be viewed during the call in response to user selection. In some implementations, a graphical representation of the hold duration may be displayed, for example, as a bar graph, chart, or other representation. Some examples of display hold durations are described below with reference to fig. 5-10.

In block 224, a determination is made as to whether one or more of the expected call times displayed in block 218 have been selected by the user. In some implementations, the displayed expected call time associated with the displayed estimated hold duration in block 222 may be selected by a user, for example, via a touch screen interface, voice command, or other user input. If the expected call times are not selected in block 224 (or they are not selectable in some embodiments), the method continues to block 230 as described below. If one or more of these call times are selected, the method continues to block 226 where the intended call associated with each selected call time is scheduled at that time. In some implementations, scheduling may include scheduling the selected call time in an application, such as a dialer application or other application that may provide notification. In some implementations, scheduling may include adding an entry to a user's calendar at an expected call in a calendar application executing on the calling device. For example, a user may open a calendar application or other application to view an entry showing a target entity and a scheduled call time to call the target entity. In some implementations, an option may also be provided to reschedule the scheduled intended call (e.g., via a display control in the user interface).

If the user initiates or is present in a call with the target entity, the calling device may, in some embodiments, automatically detect whether the user is on hold at some point during the call. For example, this may be detected based on detection of voice data received by the calling device from the target entity, the voice data being programmatically analyzed. In some implementations, the calling device may detect whether a human agent has been connected to the call while the call is on hold, e.g., via a particular word spoken by the agent or user, hold music or a stop of automatic voice, etc., such that the call is no longer on hold. In some implementations, for example, if a user has requested a notification indicating that a call is no longer on hold and that human agent is connected to the call, the calling device may output such a notification. In some implementations, the hold duration of the call may be stored and used to update a data structure or model, as described below. The method may continue to block 228.

In block 228, a notification is displayed at (or near) the call time of the intended call scheduled in block 226 and/or the call is automatically initiated by the calling device. For example, a notification is displayed that alerts the user that the time of the intended call is about to arrive a predetermined amount of time before the time of the intended call (e.g., 5 minutes or 10 minutes before). In some implementations, the notification may include an estimated hold duration for the call (the hold duration may be updated if the data structure or model has been updated with additional call characteristic data since the original estimated hold duration was determined). In some implementations, the user can then manually initiate the scheduled call, e.g., via a dialer application, a contact list, etc. In some implementations, the scheduled call may be initiated automatically by the calling device at the time of the call, for example, if the user has entered a preference to do so. For example, a dialer or calling application on the calling device may automatically dial the entity identifier without user input or intervention and may inform the user of the call being initiated. The method may continue to block 230.

In block 230, it is determined whether the call of the calling device has ended. For example, in some cases, the call may be the current call of the on-going euro detected in block 216. In some cases, the call may have been initiated after the display of the expected hold duration in block 222. In some cases, the call may be an intended call initiated at or after block 228. If the call has not been completed, the method may continue to block 216 to determine if the call is in progress and/or the calling device may wait for additional user input.

If the call has ended in block 230, the method continues to block 232 where call characteristic data relating to the call is obtained and, if appropriate, one or more techniques for determining the hold duration of the call are updated based on the data. For example, in the case of a user permission, the call characteristic data may include characteristics such as an identifier of the target entity of the call, a duration of hold during the call if the user is placed on hold during the call, a time of the call (including a day of the week, a day of the month, etc.), whether the call was made on a holiday, and/or any other calling device context information. The call characteristic data may be used to update the data structure and/or may be provided to update a model that is used to determine the hold duration as described herein if permitted by the user. For example, if the data structure includes an average call duration and/or average hold duration for the target entity, those averages may be adjusted based on data including the call duration and hold duration from the ending call. The model may be further trained and updated with data from the completed call and additional user calls.

In some implementations, feedback may be requested from the user during or after the call. For example, a call log of a calling device may include options or controls associated with ending a call in the log, wherein a user may select a control to input feedback regarding ending the call. For example, if the hold duration that the user was on hold during the end of the call has not been automatically determined, the user may be requested to enter such hold duration. In some implementations, the calling device may present an estimate of the hold duration that is automatically determined by the calling device (e.g., based on speech recognition techniques as described herein) and request the user to confirm the estimate or adjust the estimate if the estimate is incorrect. In this way, a more accurate hold duration may be determined for the previous call, enabling improved accuracy in determining the hold duration estimate prior to the new call.

Fig. 3 is a flow diagram illustrating an example method 300 of constructing a data structure and/or model for estimating a hold duration of an intended call based on previous calls, in accordance with some embodiments. For example, the method 300 may be implemented as block 208 or a portion of block 208 of fig. 2 to determine the hold duration based on a previous call by the user. In some implementations, the method 300 may be performed by a server or other device other than the calling device, for example, to build a data structure and/or model that may be downloaded or accessed by the calling device (e.g., client device or other device) to determine the expected and/or current hold duration of the call as described with reference to fig. 2. In some implementations, the method 300 may be performed by a calling device, such as a client device, or different portions of the method may be performed by a server device and a client device, respectively.

The method begins at block 302. In block 302, data characterizing a previous call (stored and made available for purposes of determining hold duration, model training, etc., with specific user permissions from a previous caller) is obtained. For example, the data may include call characteristics of calls between one or more users and various entities, where the call characteristics have been disassociated from the user making the call such that only the call characteristics are known. For example, a previous call may have been made by a community of users over a communication network with the user's consent using the calling device from which the call characteristics were obtained. The call characteristics may include, for example, an entity identifier of the entity being called (e.g., a telephone number, a call address, or other identifier for connecting to the target entity via a previous call), a duration of the call (time of termination or disconnection from initiation or connection of the call), a time of the call (e.g., hours and/or minutes of day, day of week, day of year), whether each call was made during (and/or shortly before) an event such as a holiday, business event, etc.

In some implementations, the obtained call characteristics may include a duration of hold that occurred in the previous call, e.g., a duration of a period of time when the user was placed on hold during the previous call. For example, if user consent has been obtained, one or more previous call hold durations may be automatically determined by the calling device (and/or by the connecting remote device) based on analysis of voice data in audio data recorded from the previous call using techniques such as voice recognition via a machine learning model or other techniques. For example, voice recognition techniques may identify when a call is placed on hold by examining call audio for a particular word, and/or other techniques may examine call audio for other audio (e.g., words spoken by an automatic call responder indicating that a user is on hold, music play indicating that a call is on hold, etc.). Such techniques may also be used to identify when the user is no longer on hold, e.g., hold music in audio data ceases, and detect (different) speech from the target entity, words (e.g., "hello" etc.) spoken from the target entity that indicate the human agent in a call answered by the user to indicate that the human agent has been connected to the call, etc. After the system has determined the initiation of the hold period in which the caller is placed on hold and the stop of the hold period, the hold duration between these time points may be determined for the previous call.

Further, in some implementations, one or more hold durations of previous calls may be determined based on user feedback, e.g., during a call or after a call has ended (e.g., similar to block 232 of fig. 2). For example, the user may input the estimated hold duration to the calling device after the call has ended.

In some implementations, one or more of the previous calls may not be associated with a hold duration that has been determined by detection in call audio as described above or by user feedback. In some implementations, the hold duration may be estimated for previous calls that do not have such hold duration, as described below with respect to blocks 306-314. The method may continue to block 304.

In block 304, a threshold and function for estimating the duration of a call for a previous call that does not have a specified hold duration is determined. These thresholds and functions may be used to estimate the hold duration of at least some previous calls for which data was obtained in block 302 as described below. For example, if the call duration of the call is above a particular threshold, the hold duration may generally be approximately related to the call duration of the call. A call duration below the threshold may not indicate a hold duration, e.g., due to various changing conditions and user behavior in a short call duration; for example, a user may prefer to disconnect a call rather than waiting to be on hold. The threshold call duration may be used to determine which of the previous calls will be used to determine the estimated hold duration. In some implementations, the function determined in block 304 may include converting the call duration to a function of the estimated hold duration. For example, the call duration of the previous call (above a threshold) and any hold durations known for the previous call may be analyzed to determine a relationship between the call duration and the hold duration. It may be determined to convert the call duration as a function of the hold duration.

In some implementations, a single threshold and a single function may be determined for general application to all previous calls. In some implementations, multiple thresholds and/or functions may be determined, each of which is modified, customized, or dedicated to a call having a particular call characteristic, such as a call having a particular target entity, a call time of a previous call, and so forth. For example, based on the call duration and hold duration of a previous call to a particular entity for which such call characteristics are known, it may be apparent that for calls to that particular entity, a call duration above a particular threshold duration is better correlated with hold duration and the particular threshold is greater than a general threshold determined from previous calls to other entities. Thus, the threshold call duration for that particular entity may be set to a higher value than the general threshold call duration. Similarly, via the call characteristics of previous calls to a particular entity, it may be apparent that the relationship between call duration and hold duration for a particular entity may be different than the relationship determined for the general function based on previous calls to other entities. Thus, a function specific to the relationship may be determined and associated with a call to the particular entity. For example, in some implementations, one or more such modified thresholds may be retrieved from a data structure storing such thresholds and/or other call characteristics associated with a particular target entity. The method may continue to block 306.

In block 306, a previous call is selected from the set of previous calls obtained in block 302. The selected previous call does not have associated hold duration data. The method continues to block 308.

In block 308, it is determined whether the selected call duration of the previous call is greater than a threshold call duration. For example, the threshold call duration may be a call duration over which the call will be more likely to have a hold duration that is related to the call duration. For calls having a call duration at a threshold call duration, the hold duration is uncorrelated with the call duration. In some implementations, as described above, the threshold call duration is a general call duration for all previous calls obtained in block 302, e.g., regardless of the target entity of the selected previous call. In some implementations, the threshold call duration may be, for example, a modified threshold tailored to the target entity and/or other call characteristics of the selected previous call, as described above for block 304.

If the call duration is greater than or equal to the threshold call duration, the method continues to block 312, as described below. If the call duration is less than the threshold call duration, the method continues to block 310 where the selected previous call is ignored for purposes of method 300, e.g., its call characteristics are ignored to determine the estimated hold duration of the target entity, and its model for training to provide the estimated hold duration is ignored. The method may continue to block 314 as described below.

In block 312, the selected call duration of the previous call has been found to be greater than the threshold, and thus its call characteristics may be used to determine the hold duration. In some implementations, the hold duration for the selected previous call is estimated based on the corresponding call duration for the previous call using a hold duration function. The function may determine a transition of the call duration to the estimated hold duration of the selected previous call based on a relationship of the call duration to the hold duration. The hold duration function is applied to previous calls having a call duration above the threshold used in block 308 because such previous calls have been found to have a call duration that is highly correlated to the hold duration. In some implementations, the function may be updated over time based on additional previous call data obtained from the user call. In some examples, the relationship between the call duration and the hold duration is a linear regression, and the hold duration function implements the linear regression via multiplication by a first factor and/or addition of a second factor to the call duration to obtain an estimated hold duration. For example, the (initial) function may be (call duration 0.66-5.22) to obtain an estimated hold duration.

In some implementations, the hold duration function may be a modified and customized function tailored, for example, to the target entity of the selected previous call or to other call characteristics, as described above for block 304. Such modified functions may be retrieved, for example, from a data structure storing such functions in association with particular target entities and/or other call characteristics. The method may continue to block 314.

In block 314, it is determined whether there are more previous calls in the set of calls obtained in block 302 that have not been associated with a hold duration and have not been processed in method 300. If so, the method continues to block 306 to select another previous call to process. If it is determined in block 314 that there are no more previous calls to process, the method continues to block 316 as described below.

In some implementations, a variety of techniques may be used to determine an estimate of the hold duration of the previous call, and the results of these techniques may be compared to determine differences, if any, between the results. The comparison may indicate a possible error in one of the techniques, e.g., if the results differ significantly, the hold duration may be recalculated or ignored.

In block 316, the data structure and/or training model is determined using call characteristics of the previous call, wherein the call characteristics include a duration of hold of the previous call. The hold durations used to determine the data structure and/or training model may include hold durations previously determined for previous calls (e.g., via automatic hold detection and/or user feedback) and estimated hold durations determined in block 312. The determined data structure and/or trained model may be used to determine the hold duration of new calls, such as current calls and anticipated calls.

In some implementations, a data structure may be determined, which may include a table, list, or other structure storing data including each target entity and a corresponding estimated hold duration for that target entity. For example, one or more estimated hold durations may be looked up in a data structure via the target entity and provided to the target entity as an estimated hold duration for the intended (or current) call, as described with respect to fig. 2. In some implementations, the estimated hold durations stored in the table may be determined as an average of all previous hold durations of the target entity known or estimated from previous calls. In some embodiments, the estimated hold durations may alternatively be different combinations of previous hold durations, such as average, median, etc. In some implementations, the data structure may also include various other call characteristics that may be looked up in the data structure to determine the duration of hold of the intended call, such as the time of the call, the day of the week of the call, whether the call was initiated on a holiday or during another event, and so forth. The hold duration for a particular call time may be based on the hold duration of a previous call initiated at that call time (e.g., within a threshold period of the call time). For example, for each entity stored in the data structure, a plurality of these call characteristics (e.g., different times of day, day of week, etc.) may be listed, and a hold duration may be associated with each call characteristic or with one or more different combinations of call characteristics. In some examples, to determine the hold duration of an intended call with a particular call time, the call time (and/or day) is looked up in a data structure to determine an estimated hold duration for the call.

In some implementations, the hold duration for a particular intended call may be determined based on call characteristics of only some of the available previous calls, such as a subset of the entire set of available previous calls. For example, it may be known that the hold duration of a particular call characteristic (such as a particular call time or target entity) falls outside of the standard estimate. For example, a particular call time on a day with non-standard user call behavior (e.g., on a holiday or a day prior to a holiday) may be determined based on call characteristics of more recent previous calls, such as calls within a threshold period of time of the call time that determines the hold duration. For example, the previous call used may have been initiated or occurred within the last hour of the particular call time.

In some implementations, one or more models can be trained based on call characteristics of previous calls or a subset thereof. For example, in some implementations, the model is a machine learning model, such as a neural network having one or more nodes, arranged according to a network architecture, such as in one or more layers, wherein the various nodes are connected via the network architecture and have associated weights. For example, in a training phase of the model, the training data may be used to train the model, and then in an inference phase (e.g., as described in fig. 2), the trained model may provide an output based on the input data. In some implementations, the model may be trained offline, for example, on a test device in a test laboratory or other setting, and the trained model may be provided to a server or calling device executing the model. In some implementations, with user permissions, one or more trained models may be updated with federal learning, for example, where individual devices may each perform local model training, and updates to the model may be aggregated to update one or more central versions of the model. Additional examples of features that may be included in the model are described below with reference to fig. 11.

Training data for the machine learning model may include user-licensed call characteristics of previous calls as described above, e.g., an identifier of the entity being called, a duration of the call, a time of the call (e.g., hours and/or minutes of the day, day of the week, etc.), whether each call was made on a weekday or weekend, whether each call was made during an event (such as a holiday, day of business event, etc.). In some embodiments, the model is trained by training data to provide as training data the hold duration for any call time or target entity for which a previous call has been obtained, including the hold duration for a particular call time or call having other particular call characteristics. For example, if the input indicates an expected call time that occurs one day before the holiday when the call volume from the user may be higher than most other days, the model may be trained to output a longer estimated hold duration.

Fig. 4 is a flow chart illustrating an example method 400 for determining a hold duration of an intended call to a target entity, according to some embodiments. For example, the method 400 may be implemented in block 214 of fig. 2, wherein the identifier is being obtained by the calling device and/or in block 220 of fig. 2, wherein the hold duration is determined for the intended call to the target entity.

The method begins at block 402. In block 402, a call time for an intended call is determined for which an estimated hold duration is to be determined. This may include determining a particular call time and/or number (amount) of intended calls for which to determine the hold duration. Each hold duration to be determined may be associated with a different expected call initiated at a different expected call time. The call time of the intended call may be based on any of a variety of factors. For example, user settings or preferences may have been provided by the user (e.g., specified on the calling device, such as in a dialer application or other application) to indicate how many different desired calls or hold durations and/or call times those desired calls are. Such preferences may indicate, for example, whether hold durations are to be provided for an intended call having a call time on different expected days, all on a day (e.g., current day), a particular period or hour of each day, a particular day of the week, etc. In some implementations, the number of expected calls and the time of the call may be based on other conditions, such as data in the user's calendar (e.g., indicating at which hours and/or days the user is available to make the call), known business hours of the target entity, and so forth.

In various examples, the determined call time for the intended call may be at various times. For example, the determined call time may span business hours of a target entity on a standard weekday and/or weekend. In further examples, the determined call times may be periodically spaced apart over a span of a day, e.g., every hour, every half hour, etc. In some implementations, the determined call time spans the remaining business hours of the day of the target entity (e.g., if the current time is near the end of the business hours of the target entity, the expected calls may include those in the remaining business hours and calls on the next or subsequent days). In some implementations, if user consent has been obtained, the determined call time may be a particular time of day based on a history (e.g., characteristics) of previous calls that the user has made to the target entity. For example, if the user has previously made a call to the target entity only between 9 am and 11 am, the time of the call within that time period may be determined for the intended call (and, for example, if the user enters a request for other time of the call, the other time of the call is not determined or is determined later). In a further example, the expected call time may be determined based on the frequency of previous calls at a particular time or for a particular period of time. For example, if the number of calls made by a user over a particular time period (e.g., on different days) exceeds a threshold number, an expected call time for the time period may be determined. In another example, previous calls to a target entity having at least a minimum or threshold call duration are eligible to be counted in the determination of call time, e.g., in the above examples and embodiments, and/or previous calls under the threshold duration may be ignored for such call time determinations.

In some embodiments, the determined call times within the time period of the previous call and/or having other characteristics may be designated as having a higher priority than other determined call times (in some embodiments, a particular number of lower priority call times may also be determined and provided as additional options to the user). For example, the hold duration associated with the higher priority call time may be part of an initial or default display of the hold duration, while the lower priority hold duration may be hidden by default and displayed if commanded by user input received from the user. In a further example, the hold duration associated with the higher priority call time may be displayed and no other or lower priority hold durations are displayed when the display area has a limited area in which information is displayed. In some implementations, the call times and hold durations may be ranked based on one or more of the factors described above (e.g., based on characteristics of previous calls in a user history of call times to target entities) such that the top X highest ranked call times/hold durations of the set of determined call times are displayed, where X may be 5, 10, etc., and the lower ranked call times and hold durations may not be displayed. The method continues to block 404.

In block 404, it is determined whether the user is currently entering an entity identifier of the target entity into the calling device, e.g., to initiate a call to the target entity. For example, the entity identifier may be in the process of being obtained in block 214 of FIG. 2, and the user has not completed the entry of the entity identifier. If the user is not currently entering an entity identifier, the method continues to block 412, described below.

If the user is currently entering an entity identifier, the method continues to block 406 where a determination is made as to whether a candidate hold duration is to be pre-fetched for the target entity before the entry or acquisition of the entity identifier is completed. For example, in some embodiments, the portion of the entity identifier that has been received may be considered as a prefix that, when completed, may be part of any candidate entity identifier of the plurality of candidate entity identifiers. The candidate hold durations associated with such candidate identifiers may be pre-fetched from the remote device and stored in the local storage of the calling device before the full identifier is obtained by the calling device. The prefetching allows the holding duration of the completed identifier to be displayed by the calling device quickly after the identifier is completed, since the holding duration is selected from the set candidate holding durations stored locally. For example, in some implementations, such prefetching may be desirable where the calling device obtains the hold duration of the intended call from a remote device such as a server or other device, e.g., where a data structure or model for determining the hold duration is not stored in the local storage of the calling device. In embodiments where the hold duration may be determined via a data structure or model stored in a local store of the calling device, the determination of the hold duration may be fast enough that it is not necessary to prefetch candidate hold durations before the entity identifier is completed.

In some implementations, the pre-fetching of the candidate hold duration is performed if a threshold portion of the full identifier has been received. In some examples, if the full entity identifier is 10 bits, the prefetch may be performed after bit 8 (or alternatively bit 9) of the partial identifier has been received, rather than before. This allows, after receipt of the full identifier (as described below), a reduction in the number of candidates to an amount of data that can be received at the calling device within a relatively short time sufficient to determine a match hold duration.

If a prefetch of candidate retention duration is not performed, the method continues to block 412, described below. If a prefetch of candidate retention time durations is to be performed, the method continues to block 408 where the candidate retention time durations are prefetched from a remote device, such as a server, based on the partial entity identifiers that have been entered by the user. For example, the calling device may send a request to the remote device and receive a candidate hold duration of the candidate entity identifier that matches the partial identifier that has been received in block 404. The remote device may determine the hold duration using, for example, a similar data structure and/or model as described above in fig. 3, and transmit the hold duration to the calling device over the network.

In some implementations, a subset of a greater number of candidate hold durations to be prefetched by the calling device is determined, for example, by the calling device or the remote device. For example, a subset of candidate retention durations may be associated with an entity identifier that is the most likely identifier entered by the user, as determined based on one or more factors. For example, the most likely identifier may be based on historical data indicating which entities the user has previously called, e.g., where the identifier of the most frequent and/or nearest entity previously called by the user is considered the most likely received identifier. In some implementations, a current or recent conversation or message of a user may be checked to determine whether any entities have been mentioned (and/or whether topics related to particular entities, such as services or products provided by the entities, have been mentioned) such that identifiers of those mentioned entities are selected as possible candidate identifiers in the subset to match the received identifiers. The hold durations associated with these possible identifiers are selected to be among the most likely hold durations to be displayed to the user and are thus prefetched to the calling device. The method continues to block 410.

In block 410, a full entity identifier has been received (e.g., the user has completed entering the identifier of the target entity into the calling device), and a duration matching the full identifier is selected from the candidate hold durations. For example, candidate retention durations that do not match the full identifier may be discarded. In some examples, if the user has entered the first 9 digits of the telephone number in block 404, candidate hold durations for entity identifiers matching those 9 digits may be extracted to the calling device in block 408, and the final and 10 th digits have been received and the hold duration associated with that entity identifier selected in block 410. The method may continue to block 222 of fig. 2 to display the selected hold duration, as described above.

In block 412, a (complete) entity identifier is received. For example, the user may have completed manually entering the entity identifier of the target entity, or the entity identifier may have been received from a different source, such as an application running on the calling device (e.g., contact entries in the user's contacts have been selected by the user, displayed telephone numbers or other call identifiers selected by the user in the application, etc.). The method may continue to block 414.

In block 414, it is determined whether the call characteristic data is cached in a local store of the calling device. For example, call characteristic data may be provided in one or more data structures storing entity identifiers and hold durations that have been estimated for those identifiers, examples of which are described with reference to block 316 of fig. 3. If the call data is not cached locally on the calling device, the method continues to block 418, described below. If the call data is cached locally on the calling device, the method continues to block 416 where the entity identifier of the target entity and the expected call time (cached call characteristic data) are looked up in a data structure to determine the hold duration of the expected call determined in block 402. The method may continue to block 222 of fig. 2 to display the determined hold duration, as described above.

In block 418, a determination is made as to whether the model for determining hold duration is stored in a local store of the calling device. For example, the model may be a machine learning model that has been trained to output an estimated hold duration based on inputs such as call characteristics, e.g., target entity, time of call, etc., examples of which are described with reference to block 316 of fig. 3. If the model is not stored locally on the calling device, the method continues to block 422, described below. If the model is stored locally on the calling device, the method continues to block 420 where call characteristics of the intended call, such as an entity identifier of the target entity, the intended call time, and/or other call characteristics, are input to the model and an output of the model is obtained, including the hold duration of the intended call determined in block 402. The method may continue to block 222 of fig. 2 to display the determined hold duration, as described above.

In block 422, one or more call characteristics of the intended call determined in block 402 are sent to a remote device, such as a server, and the hold durations of those calls are obtained from the remote device. For example, the calling device may send the identifier of the target entity and the expected time of the call determined in block 402, as well as other information that may be used to determine the hold duration (e.g., whether the time of the call occurred on a holiday, etc.) to the remote device. The remote device may determine the hold duration using, for example, a similar data structure and/or model as described above in fig. 3, and transmit the determined hold duration to the calling device over the network. The method may continue to block 222 of fig. 2 to display the determined hold duration, as described above.

In some implementations, the trained model, such as used in block 420 or block 422, may be additionally trained or updated with additional data, e.g., as described above with reference to block 232 of fig. 2. The model may be trained locally on the calling device or the model on the remote device may be trained based on data received from the calling device.

In various embodiments, one or more blocks may be omitted from method 400, for example, if particular features of those blocks are not provided in particular embodiments. For example, in some implementations in which the device uses the model locally to determine the hold duration and does not use other described techniques for determining the hold duration, blocks 404-418 and 422 may be omitted. Similarly, in some embodiments where no model is used, blocks 418 and 420 may be omitted.

The methods, blocks, and operations described herein may be performed in a different order than shown or described in fig. 2-4, and/or concurrently (partially or completely) with other blocks or operations, where appropriate. For example, blocks 216 and 218 of FIG. 2 may be performed before, after, or at least partially concurrently with blocks 220-226. Block 230 of fig. 2 may be performed at any of a variety of times in method 200. In other examples, blocks 402, 412, and 416 may be performed at least partially concurrently or in a different order than shown in the example of fig. 4. Some blocks or operations may be performed for one portion of data and later performed again, e.g., for another portion of data. Not all illustrated blocks and operations may be required to be performed in various embodiments. In some implementations, the blocks and operations may be performed in a different order and/or multiple times at different times in a method.

One or more of the methods disclosed herein may operate in several environments and platforms, e.g., as a stand-alone computer program that may be run on any type of computing device, as a mobile application ("app") running on a mobile computing device, etc.

One or more of the methods described herein (e.g., 200, 300, and/or 400) may be run in: a program running on a Web browser, a mobile application ("app") running on a mobile computing device (e.g., a cellular telephone, a smart phone, a tablet computer, a wearable device such as a wristwatch, an arm band, jewelry, headwear, virtual reality goggles or glasses, augmented reality goggles or glasses, a head-mounted display, etc.), a standalone program that may be executed on any type of computing device. In one example, a client/server architecture may be used, for example, a mobile computing device (as a client device) sending user input data to a server device and receiving final output data from the server for output (e.g., for display). In another example, all of the computations of the method may be performed within a mobile application (and/or other application) on the mobile computing device. In another example, the computation may be split between the mobile computing device and one or more server devices.

In one example, a client/server architecture may be used, for example, a mobile computing device (as a client device) sending user input data to a server device and receiving final output data from the server for output (e.g., for display). In another example, all of the computations may be performed within a mobile application (and/or other applications) on the mobile computing device. In another example, the computation may be split between the mobile computing device and one or more server devices.

The methods described herein may be implemented by computer program instructions or code that may be executed on a computer. For example, the code may be implemented by one or more digital processors (e.g., microprocessors or other processing circuitry) and may be stored on a computer program product comprising a non-transitory computer readable medium (e.g., a storage medium), such as a magnetic, optical, electromagnetic, or semiconductor storage medium, including semiconductor or solid state memory, magnetic tape, removable computer diskette, random Access Memory (RAM), read Only Memory (ROM), flash memory, rigid magnetic disk, optical disk, solid state memory drive, and the like. The program instructions may also be contained in and provided as electronic signals, for example, in the form of software as a service (SaaS) delivered from a server (e.g., a distributed system and/or cloud computing system). Alternatively, one or more of the methods may be implemented in hardware (logic gates, etc.) or in a combination of hardware and software. Example hardware may be a programmable processor (e.g., a Field Programmable Gate Array (FPGA), a complex programmable logic device), a general purpose processor, a graphics processor, an Application Specific Integrated Circuit (ASIC), etc. One or more methods may be performed as part or component of an application running on a system or as an application or software running in conjunction with other applications and operating systems.

Fig. 5 is a schematic diagram of an example user interface 500 displayed by a display screen of a calling device, in which the hold duration of a call may be displayed, according to some embodiments. For example, interface 500 may be displayed on a touch screen by a display device of a client device, such as one of client devices 120-126 as shown in FIG. 1, or a different device, such as a server device, e.g., server system 102.

In some implementations, the user interface 500 can be associated with a call application that initiates a call to other devices, answers incoming calls from other devices, and communicates with other devices via a call connection. In this example, the name 502 of the target entity is displayed, which has been selected by the user. An entity identifier 504 of the target entity is displayed near the entity name 502. Also shown is a call interface 506 that includes a standard keypad 508, an identifier entry field 510, and a call control 512. Keys of keypad 508 may be selected by a user (e.g., via a touch screen or other input device) to input an identifier 514 in input field 510, e.g., one character at a time, or a plurality of characters in other embodiments. In some implementations, the identifier 514 can be automatically entered by the calling device in the input field 510, for example, in response to a user selecting a call target entity from a different application (e.g., a map application, web browser, etc.), which causes the interface 500 to be displayed by the calling device. If call control 512 is selected by the user, call control 512 may cause the calling device to dial identifier 514 of the target entity and initiate a call to the target entity.

The user interface 500 may also include a hold duration display area 520 in which information related to the estimated hold duration may be displayed. In this example, a message 522 is displayed in the display area 520, the message 522 indicating that the estimated hold duration is in the process of being determined for the entity identifier 504/514. This is a pre-call determination of hold duration, for example, before a call is initiated to the target entity using the identifier 514 (and in this example, before the user selects the call control 512). In some implementations, message 524 may also be displayed in or associated with call control 512, for example, to indicate that the hold duration is determined.

Fig. 6 is a schematic diagram of the user interface 500 of fig. 5, wherein the hold duration is displayed after determination by the calling device, according to some embodiments. This display example precedes the initiation of a call to the target entity using identifier 514. The hold duration may be estimated using any of the techniques described herein. In this example, multiple hold durations are estimated for multiple intended calls, each at a different call time. For example, the respective hold durations have been estimated by the calling device for calls for each hour (7 AM, 8AM, etc.) of a time period in which the target entity is open to traffic and is able to provide human agents to talk to the caller. These include the expected call time after the current time. In some embodiments, the hold duration of the call time prior to the current time may be displayed for reference, and/or may be an indication of the estimated hold duration that occurred the next day at these same call times.

At least some of the determined hold durations are graphically displayed in bar graph 601 in display area 520, e.g., the height of each vertical bar 602 indicates the magnitude of the hold duration relative to the magnitude of the other estimated hold durations displayed. In this example, the selected bar 604 is highlighted with a different color, brightness, or other indication to visually distinguish it from the other bars 602 and indicate the hold duration for the particular call, which in this example is a call placed within a time period that includes the current time (e.g., the current time is closest to the time period associated with the bar). In addition, a hold duration indication 606 is visually associated with the selected bar 604 and indicates the hold duration indicated by the selected bar 604 in a text format.

In some implementations, if the hold duration is displayed during the day as shown, a set of day tags 610 may be displayed in the display area 520 adjacent to the bar chart 601 or otherwise visually associated with the bar chart 601. In this example, each tag 610 indicates a different day of the week. One tab 612 of the tab 610 is highlighted to indicate the day for which the hold duration of the bar graph 601 applies. For example, the tag 612 may be bold, underlined, and/or otherwise visually distinguished from the other tags 610. In some embodiments, other user selectable labels may be displayed, such as current month with selectable remaining days, current year with selectable remaining months, and so forth.

In some implementations, summary message 614 may be displayed in display area 520, e.g., visually associated with bar graph 501 (e.g., adjacent or proximate to bar graph 501). Summary message 614 may summarize the information indicated in bar chart 601, for example, displaying in text format the estimated hold duration of a call initiated at a selected call time or within a particular time period before and/or after the selected call time in bar chart 601. For example, in fig. 6, the selected call time is the current time (or a time immediately after the current time), and message 614 may indicate the call time (e.g., 12PM in this example) associated with the selected bar 604. For example, the call time in message 614 may be a call time representing a time period that includes the current time. In some examples, the time period represented by bar 602 may be one hour centered around the displayed call time for the bar, or may be other time periods in other embodiments. When the current time advances to the next time period represented by the next bar 602, the selected bar 604 and message 614 may be updated accordingly. For example, when the current time advances to the next time period (e.g., at 12:31PM, in one example), the selected bar 604 and message 614 may be changed to the next call time (e.g., 1 PM) of the bar graph 601.

In some implementations, the message 620 can also be displayed in or associated with the call control 512, the call control 512 indicating an estimated hold duration associated with the selected call time of the bar 604 in the bar graph 601.

Fig. 7 is a schematic diagram of the user interface 500 of fig. 6, showing examples of different estimated hold durations selected by a user, according to some embodiments. The interface 500 of fig. 7 is displayed prior to initiating a call to a target entity using the identifier 514. In this example, the user has selected a different bar 702 of the bar graph 601 via user input, e.g., tapping the displayed bar 702 on the touch screen. The bar 702 is correspondingly visually highlighted in response to the selection, and the previously selected bar 604 is no longer highlighted. The hold duration indication 606 is updated in response to the selection to indicate the estimated hold duration represented by the selected bar 702.

Fig. 8 is a schematic diagram of the user interface 500 of fig. 7, in which different estimated hold durations are selected by a user, according to some embodiments. The interface 500 of fig. 8 is displayed prior to initiating a call to a target entity using the identifier 514. In this example, the user has selected a different day of the week (not the current day) to view the hold duration of the intended call on the selected day. For example, the user may select the day tab 610 to cause the retention duration associated with the selected day to be displayed. In some examples, the tab 802 (for the next upcoming Saturday) is selected by the user in FIG. 8, causing the bar graph 804 to be displayed. In contrast to the friday bar graph 601 shown in fig. 6 and 7, the bar graph 804 includes a different set of hold durations for calls. In some implementations, if a day is selected that the target entity is not available to receive the call (e.g., no business hours on weekends, holidays, etc.), then a bar graph of hold duration is not displayed and is indicated that the target entity is not having a message to connect the human agent to the call on that day (e.g., if sunday is selected for tag 610, a message of "turn off on sunday" may be displayed).

Similar to bar 601 of fig. 6 and 7, bar 804 includes estimated hold durations at different call times for selected days. Bar 806 of bar graph 804 is selected. For example, bar 806 may have been selected by user input, or may be a default selection when a different day tab 610 is selected (e.g., the first or earliest bar in bar chart 804 may be selected). Bar 806 is correspondingly visually highlighted and the previously selected bar 702 is no longer highlighted. The hold duration indication 606 is updated in response to the selection to indicate the estimated hold duration represented by the selected bar 806.

In other embodiments, the hold duration may be displayed in other manners or formats. For example, a horizontal bar graph, color-coded numbers or areas, calendar format, or other graphical display may be used.

Fig. 9 is a schematic diagram of an example user interface 900 displayed by a display screen of a calling device, in which hold durations may be displayed during a call, according to some embodiments. For example, interface 900 may be displayed on a touch screen by a display device of a client device, such as one of client devices 120-126 as shown in FIG. 1, or a different device, such as a server device, e.g., server system 102.

Interface 900 may be a call interface that has been displayed by a calling device that initiated a call to a target entity by dialing an entity identifier of the target entity. For example, state 902 of the call is indicated. An estimated hold duration 904 is determined for the current call (e.g., as described herein), and the estimated hold duration 904 may be displayed in the interface 900. Additionally, a hold duration control 906 is displayed and may be selected by the user to cause the hold duration to be displayed for the intended call to the target entity at different call times. Disconnect control 908 may be selected by the user to hang up the current call.

In some implementations, an interface similar to interface 900 may be displayed after the call is connected to the target entity. For example, when the caller and callee are communicating via voice in a call, estimated hold duration 904 and hold duration control 906 may continue to be displayed in interface 900. The estimated hold duration 904 may also continue to be displayed if the user is placed in hold by the target entity. For example, the calling device may use speech recognition techniques, receive user selections, or other techniques to detect whether a target entity (e.g., an automated voice menu of the target entity) has placed the user on hold. While in hold, the estimated hold duration 904 may be adjusted, e.g., decreasing as the time of the hold period progresses. Hold duration control 906 may be displayed and available for selection by a user during a call and/or while on hold.

Fig. 10 is a schematic diagram of the user interface 900 of fig. 9, wherein the hold duration for an intended call has been determined by the calling device and displayed in the interface 900 during the call, according to some embodiments. In this example, a hold duration display area 1002 is displayed in interface 900, wherein display area 1002 includes a bar graph 1004 showing hold durations for a plurality of intended calls. For example, the display area 1002 may be displayed in response to a user selecting the hold duration control 906 as shown in fig. 9, or other input may be received to cause the display area 1002 to be displayed.

Bar graph 1004 may be similar to the bar graphs described above with respect to fig. 6-8. For example, multiple hold durations may be estimated for multiple intended calls, each having a different call time. Similarly, as described above, the user may select the day tab 1006 to display the holding duration for the selected day. The hold duration indication 1008 may indicate the selected hold duration in a text format similar to that described above. In some implementations, the summary message 1010 can be displayed in the display area 1002, e.g., visually associated with the bar graph 1004, similar to that described above.

In some implementations, the bar graph 1004 can continue to be displayed and responsive to user selection while the call is connected and during the call (e.g., while the caller and callee are speaking, the caller is on hold, etc.).

FIG. 11 is a block diagram of an example device 1100 that may be used to implement one or more features described herein. In one example, device 1100 may be used to implement a client device, such as any of client devices 120-126 shown in FIG. 1. Alternatively, device 1100 may implement a server device, e.g., server device 104, etc. In some implementations, the device 1100 may be used to implement a client device, a server device, or a combination thereof. Device 1100 may be any suitable computer system, server, or other electronic or hardware device as described herein.

In some implementations, the device 1100 includes a processor 1102, a memory 1104, and an I/O interface 1106. The processor 1102 may be one or more processors and/or processing circuits to execute program code and control the basic operations of the device 1100. A "processor" includes any suitable hardware system, mechanism, or component that processes data, signals, or other information. A processor may include a system with a general purpose Central Processing Unit (CPU) having one or more cores (e.g., in a single-core, dual-core, or multi-core configuration), multiple processing units (e.g., in a multi-processor configuration), a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), a Complex Programmable Logic Device (CPLD), dedicated circuitry to implement functionality, a dedicated processor to implement neural network model-based processing, a neural circuit, a processor optimized for matrix computation (e.g., matrix multiplication), or other system.

In some implementations, the processor 1102 may include one or more coprocessors that implement neural network processing. In some implementations, the processor 1102 may be a processor that processes data to produce a probabilistic output, e.g., the output produced by the processor 1102 may be inaccurate or may be accurate within a range from a desired output. For example, a processor may perform its functions in "real-time," "offline," "batch mode," etc. The computer may be any processor in communication with the memory.

Memory 1104 is typically provided in device 1100 for access by processor 1102 and may be any suitable processor-readable storage medium, such as Random Access Memory (RAM), read Only Memory (ROM), electrically erasable read only memory (EEPROM), flash memory, or the like, adapted to store instructions for execution by the processor and located separately from and/or integrated with processor 1102. The memory 1104 may store software operated by the processor 1102 on the server device 1100, including an operating system 1108, machine learning applications 1130, other applications 1112, and application data 1114. Other applications 1112 may include applications such as data display engines, communication applications (e.g., dialers or calling applications), web hosting engines, image display engines, notification engines, social networking engines, and so forth. In some implementations, the machine learning application 1130 and/or the other application 1112 may each include instructions that enable the processor 1102 to perform the functions described herein, such as some or all of the methods in fig. 2, 3, and/or 4. The application data 1114 may include call characteristics including call time, call duration, hold duration, and other characteristics of previous calls, and/or data structures (e.g., tables, lists, graphs) that may be used to determine an estimated hold duration as described herein.

The machine learning application 1130 may include one or more Named Entity Recognition (NER) implementations that may use supervised and/or unsupervised learning. The machine learning model may include a model based on multitasking learning, residual task two-way LSTM (long-term memory) with conditional random field, statistical NER, etc. One or more of the methods disclosed herein may operate in several environments and platforms, e.g., as stand-alone computer programs that may be run on any type of computing device, as Web applications with Web pages, as mobile applications ("apps") running on mobile computing devices, etc.

In various implementations, the machine learning application 1130 may utilize a bayesian classifier, support vector machine, neural network, or other learning technique. In some implementations, the machine learning application 1130 can include a trained model 1134, an inference engine 1136, and data 1132. In some implementations, the data 1132 can include training data, e.g., data used to generate the trained model 1134. For example, the training data may include any type of data suitable for training a model for determining the hold duration of a call, such as the call characteristics of a user's previous call (if user consent has been obtained), and so forth. The training data may be obtained from any source, such as a data store specially marked for training, data provided permission to be used as machine learning training data, and the like. In embodiments where one or more users permit training a machine learning model, such as trained model 1134, using their respective user data, the training data may include such user data. In embodiments where users permit use of their corresponding user data, data 1132 may include permission data.

In some implementations, the training data may include synthetic data generated for training purposes, such as data that is not based on user input or activity in the context being trained, e.g., data generated from simulations or models, etc. In some implementations, the machine learning application 1130 excludes the data 1132. For example, in these embodiments, the trained models 1134 may be generated, e.g., on different devices, and provided as part of the machine learning application 1130. In various embodiments, the trained models 1134 may be provided as data files that include model structures or forms and associated weights. The inference engine 1136 can read the data files for the trained models 1134 and implement neural networks with node connectivity, layers, and weights based on the model structure or form specified in the trained models 1134.

The machine learning application 1130 also includes one or more trained models 1134. For example, such models may include a trained model for determining an estimated hold duration of a call as described herein. In some implementations, the trained models 1134 can include one or more model forms or structures. For example, the model form or structure may include any type of neural network, such as a linear network, a deep neural network that implements multiple layers (e.g., a "hidden layer" between an input layer and an output layer, where each layer is a linear network), a convolutional neural network (e.g., a network that divides or splits input data into multiple portions or tiles, processes each tile separately using one or more neural network layers, and aggregates results from the processing of each tile), a sequence-to-sequence neural network (e.g., a network that takes sequential data such as words in sentences, frames in video, etc. as input and produces a sequence of results as output), and so forth.

The model form or structure may specify connectivity between various nodes and organization of nodes to layers. For example, a node of a first layer (e.g., an input layer) may receive data as input data 1132 or application data 1114. Such data may include, for example, call characteristics of previous calls and/or feedback from the user regarding previous calls and an estimate of the hold duration, e.g., when a trained model is used to determine the hold duration. The subsequent middle tier may receive as input the output of the node of the previous tier in accordance with the connectivity specified in the model form or structure. These layers may also be referred to as hidden layers. The final layer (e.g., output layer) produces the output of the machine learning application. For example, the output may be a set of hold durations for expected call times to be provided in the interface. In some implementations, the model form or structure also specifies the number and/or type of nodes in each layer.

In various embodiments, one or more trained models 1134 may include a plurality of nodes arranged in layers according to a model structure or form. In some implementations, a node may be a compute node without memory, e.g., configured to process one unit of input to produce one unit of output. The computation performed by the node may include, for example, multiplying each of the plurality of node inputs by a weight, obtaining a weighted sum, and adjusting the weighted sum with a bias or intercept value to produce a node output.

In some implementations, the computation performed by the node may further include applying a step/activate function to the adjusted weighted sum. In some embodiments, the step/activate function may be a non-linear function. In various embodiments, such computation may include operations such as matrix multiplication. In some implementations, the computation of the plurality of nodes may be performed in parallel, for example, using multiple processor cores of a multi-core processor, using separate processing units of a GPU, or a dedicated neural loop. In some implementations, a node may include memory, e.g., may be capable of storing and using one or more earlier inputs when processing subsequent inputs. For example, the nodes having memory may include Long Short Term Memory (LSTM) nodes. LSTM nodes may use memory to maintain "states" that allow the node to function like a Finite State Machine (FSM). Models with such nodes may be used to process sequential data, such as words in sentences or paragraphs, frames in video, speech or other audio, and so forth.

In some implementations, one or more trained models 1134 can include embedding or weights for individual nodes. For example, a model may be initiated as a plurality of nodes organized in layers specified by a model form or structure. At initialization, a corresponding weight may be applied to the connections between each pair of nodes connected in each model form, e.g., nodes in successive layers of the neural network. For example, the corresponding weights may be randomly assigned or initialized to default values. The model may then be trained, for example, using data 1132, to produce results.

For example, training may include applying supervised learning techniques. In supervised learning, training data may include a plurality of inputs (e.g., call characteristics) and corresponding desired outputs for each input (e.g., a set of hold durations for different call times). The value of the weight is automatically adjusted based on a comparison of the output of the model to the desired output, e.g., in a manner that increases the probability that the model will produce the desired output when providing similar inputs.

In some implementations, training may include applying unsupervised learning techniques. In unsupervised learning, only input data may be provided and a model may be trained to distinguish the data, e.g., to cluster the input data into groups, where each group includes input data that is similar in some way. For example, a model may be trained to determine or cluster call characteristics that are similar to each other.

In another example, a model trained using unsupervised learning may cluster calls or words based on the use of the calls or words in the data source. In some implementations, unsupervised learning may be used to generate a knowledge representation, e.g., a knowledge representation that may be used by the machine learning application 1130. In various embodiments, the trained model includes a set of weights or embeddings corresponding to the model structure. In embodiments in which the data 1132 is omitted, the machine learning application 1130 may include a trained model 1134 based on prior training, e.g., by a developer of the machine learning application 1130, by a third party, etc.

The machine learning application 1130 also includes an inference engine 1136. The inference engine 1136 is configured to apply the trained models 1134 to data, such as application data 1114, to provide inferences, such as a set of hold durations for different call times. In some implementations, the inference engine 1136 can include software code to be executed by the processor 1102. In some implementations, inference engine 1136 can specify a circuit configuration (e.g., for a programmable processor, for a Field Programmable Gate Array (FPGA), etc.) that enables processor 1102 to apply the trained model. In some implementations, inference engine 1136 may include software instructions, hardware instructions, or a combination. In some implementations, the inference engine 1136 can provide an Application Programming Interface (API) that can be used by the operating system 1108 and/or other applications 1112 to invoke the inference engine 1136, for example, to apply the trained model 1134 to the application data 1114 to generate inferences.

The machine learning application 1130 may provide several technical advantages. For example, when generating the trained models 1134 based on unsupervised learning, the inference engine 1136 may apply the trained models 1134 to generate knowledge representations (e.g., digital representations) from input data, such as application data 1114. For example, a model trained to determine a hold duration may produce a representation of the hold duration. In some implementations, such representations may help reduce processing costs (e.g., computational costs, memory usage, etc.) to generate outputs (e.g., labels, classifications, estimated characteristics, etc.). In some implementations, such representations can be provided as inputs to different machine learning applications that produce outputs from inference engine 1136.

In some implementations, the knowledge representation generated by the machine learning application 1130 may be provided to a different device for further processing, such as over a network. In such embodiments, providing a knowledge representation rather than data may provide technical benefits, e.g., faster data transfer at reduced cost.

In some implementations, the machine learning application 1130 may be implemented in an offline manner. In these embodiments, a trained model 1134 may be generated in the first stage and provided as part of the machine learning application 1130. In some implementations, the machine learning application 1130 may be implemented in an online manner. For example, in such embodiments, an application invoking the machine learning application 1130 (e.g., one or more of the operating system 1108, other applications 1112) may utilize the reasoning generated by the machine learning application 1130, e.g., provide the reasoning to the user, and may generate a system log (e.g., actions taken by the user based on the reasoning if permitted by the user; or results of further processing if used as input for further processing). The system log may be generated periodically, e.g., hourly, monthly, quarterly, etc., and may be used with the user permissions to update the trained model 1134, e.g., to update the embedding of the trained model 1134.

In some implementations, the machine learning application 1130 may be implemented in a manner that can accommodate the particular configuration of the device 1100 on which the machine learning application 1130 is executing. For example, the machine learning application 1130 may determine a computational graph that utilizes available computational resources, such as the processor 1102. For example, if the machine learning application 1130 is implemented as a distributed application across multiple devices, the machine learning application 1130 may determine the computations to be performed on the respective devices in a manner that optimizes the computations. In another example, the machine learning application 1130 may determine that the processor 1102 includes a GPU having a particular number of GPU cores (e.g., 1000) and implement the inference engine accordingly (e.g., as 1000 separate processes or threads).

In some implementations, the machine learning application 1130 may implement an integration (ensable) of the trained models. For example, the trained models 1134 may include a plurality of trained models, each trained model being applicable to the same input data. In these implementations, the machine learning application 1130 may select a particular training model, for example, based on available computing resources, success rates with previous inferences, and the like. In some implementations, the machine learning application 1130 can execute the inference engine 1136 such that a plurality of trained models are applied. In these embodiments, the machine learning application 1130 may combine the outputs from the application of the individual models, for example, using voting techniques that score the individual outputs from the application of each trained model, or by selecting one or more particular outputs. Further, in these embodiments, the machine learning application may apply a time threshold to apply the individual trained models (e.g., 0.5 ms) and utilize only those individual outputs that are available within the time threshold. The output that is not received within the time threshold may not be utilized, e.g., discarded. Such an approach may be suitable, for example, when there are time constraints specified when the machine learning application is invoked, for example, by the operating system 1108 or one or more other applications 1112.

In different implementations, the machine learning application 1130 may produce different types of output. In some implementations, the machine learning application 1130 may generate the output based on a format specified by a calling application, e.g., the operating system 1108 or one or more other applications 1112. In some implementations, the calling application may be another machine learning application. For example, such a configuration may be used in generating an countermeasure network in which output from the machine learning application 1130 is used to train a calling machine learning application, and vice versa.

Any software in the memory 1104 may alternatively be stored on any other suitable storage location or computer readable medium. In addition, the memory 1104 (and/or other connected storage devices) may store one or more messages, one or more taxonomies, electronic encyclopedias, dictionaries, knowledge bases, message data, grammars, user preferences, and/or other instructions and data used in the features described herein. Memory 1104 and any other type of storage (magnetic disk, optical disk, magnetic tape, or other tangible medium) may be considered a "storage" or "storage device.

The I/O interface 1106 may provide functionality to enable the server device 1100 to interface with other systems and devices. The interface device may be included as part of the device 1100 or may be separate from and in communication with the device 1100. For example, network communication devices, storage devices (e.g., memory 1104 and/or database 106), and input/output devices may communicate via I/O interface 1106. In some implementations, the I/O interface may be connected to interface devices such as input devices (keyboard, pointing device, touch screen, microphone, camera, scanner, sensor, etc.) and/or output devices (display device, speaker device, printer, motor, etc.).

Some examples of interface devices that may be connected to the I/O interface 1106 may include one or more display devices 1120 and one or more data stores 1138 (as discussed above). Display device 1120 may be used to display content, e.g., a user interface of an output application as described herein. Display device 1120 may be connected to device 1100 via a local connection (e.g., a display bus) and/or via a network connection, and may be any suitable display device. Display device 1120 may include any suitable display device, such as an LCD, LED or plasma display screen, CRT, television, monitor, touch screen, 3D display screen, or other visual display device. For example, the display device 1120 may be a flat display screen disposed on a mobile device, multiple display screens disposed in goggles or a head-mounted device, a projector, or a monitor screen for a computer device.

The I/O interface 1106 may interface with other input and output devices. Some examples include display devices, printer devices, scanner devices, and the like. Some embodiments may provide a microphone for capturing sound, voice commands, etc., an audio speaker device for outputting sound, or other input and output devices.

For ease of illustration, FIG. 11 shows one block of each of the processor 1102, memory 1104, I/O interface 1106, and software blocks 1108, 1112, and 1130. These blocks may represent one or more processors or processing circuitry, operating systems, memory, I/O interfaces, applications, and/or software modules. In other embodiments, device 1100 may not have all of the components shown and/or may have other elements including other types of elements in place of or in addition to those shown herein. Although some components are described as performing the blocks and operations as described in some embodiments herein, the environment 100, the device 1100, a similar system, or any suitable component or combination of components of any suitable one or more processors associated with such a system may perform the described blocks and operations.

Although the present description has been described with respect to particular embodiments, these particular embodiments are merely illustrative and not restrictive. The concepts shown in the examples may be applied to other examples and implementations.

In addition to the above description, controls may also be provided to the user that allow the user to make selections as to whether and when the systems, programs, or features described herein may enable collection of user information (e.g., information about the user's social network, social actions, or activities, professions, user preferences, or the current location of the user or user device) and whether the user is being sent content or communications from a server. In addition, certain data may be processed in one or more ways before being stored or used such that personally identifiable information is removed. For example, the identity of the user may be processed such that personally identifiable information cannot be determined for the user, or the geographic location of the user may be summarized where the location information is obtained (such as to a city, zip code, or state level) such that a particular location of the user cannot be determined. Thus, the user may have control over what information the user gathers, how to use the information, and what information is provided to the user.

Note that the functional blocks, operations, features, methods, devices, and systems described in this disclosure may be integrated or partitioned into different combinations of systems, devices, and functional blocks, as known to those of skill in the art. The routines of the particular embodiments may be implemented using any suitable programming language and programming technique. Different programming techniques may be employed, such as procedural or object oriented. The routines may execute on a single processing device or multiple processors. Although steps, operations, or computations may be presented in a specific order, the order may be changed in different specific implementations. In some embodiments, a plurality of steps or operations shown in sequence in the present specification may be performed simultaneously.

Claims (20)

1. A computer-implemented method, comprising:

obtaining an identifier of a target entity, the identifier being usable by a first calling device to initiate a call between the first calling device and the target entity;

determining a hold duration, the hold duration being an estimated amount of time before the call matches a human agent when the call is initiated at a particular time that is expected for a current time, wherein the hold duration is determined based on a plurality of previous calls between one or more calling devices and the target entity; and

The hold duration to be displayed by the first calling device is provided prior to initiating the call between the first calling device and the target entity.

2. The computer-implemented method of claim 1, wherein obtaining the identifier, determining the hold duration, and providing the hold duration to display are performed by a server device in communication with the first call device, wherein obtaining the identifier comprises receiving the identifier at the server device from the first call device that has received the identifier based on user input to the first call device, and wherein providing the hold duration to display comprises sending the hold duration from the server device to the first call device for display by the first call device.

3. The computer-implemented method of claim 1, wherein obtaining the identifier, determining the hold duration, and providing the hold duration to display are performed by the first calling device, and wherein determining the hold duration comprises:

A data structure storing a hold duration or machine learning model stored in a local store of the first calling device is accessed, the data structure outputting a hold duration in response to an input comprising the target entity and the specific time.

4. The computer-implemented method of claim 1, wherein obtaining the identifier, determining the hold duration, and providing the hold duration to display are performed by the first calling device, and wherein determining the hold duration comprises:

requesting the hold duration from the server device over the communication network,

transmitting the identifier from the first calling device to a server device, the server device determining the hold duration based on the identifier, and

before initiating the call between the first calling device and the target entity, receiving the hold duration from the server device at the first calling device,

wherein requesting the hold duration is performed before obtaining a full version of the identifier of the target entity.

5. The computer-implemented method of claim 1, wherein determining the hold duration is based on use of one of:

A machine learning model, wherein the machine learning model receives an input comprising the identifier and a time of the call and outputs a result indicative of an estimated duration of hold of the call, wherein the machine learning model is trained based on training data comprising an identifier, an initiation time of the previous call, a duration of a call of the previous call, and a duration of hold of the previous call; or alternatively

A data structure storing an estimated hold duration of an entity, wherein the estimated hold duration is based on the plurality of previous calls.

6. The computer-implemented method of claim 1, wherein the one or more calling devices are a plurality of calling devices associated with a plurality of users.

7. The computer-implemented method of claim 1, wherein the hold duration is determined based on:

call duration data indicating a plurality of call durations of the plurality of previous calls between the one or more calling devices and the target entity; and

Hold duration data indicating a plurality of hold durations of the previous call.

8. The computer-implemented method of claim 7, wherein the plurality of previous calls have a call duration that is greater than a threshold duration and exclude calls having a call duration that is less than the threshold duration, and wherein one or more of the plurality of hold durations are based on a corresponding one of the call durations that is greater than the threshold duration.

9. The computer-implemented method of claim 8, wherein the one or more of the plurality of hold durations is determined based on a function that estimates the one or more hold durations based on the call duration of the one or more previous calls, wherein the threshold duration and the function are customized for the target entity associated with the identifier.

10. The computer-implemented method of claim 1, further comprising causing the particular time to be displayed by the first calling device in association with a display of the hold duration, wherein the particular time is at least one day prior to the current time.

11. The computer-implemented method of claim 1, further comprising:

determining a plurality of hold durations for a plurality of expected calls, the plurality of hold durations including the hold duration, wherein each hold duration of the plurality of hold durations indicates a respective estimated amount of time before an associated expected call matches the human agent when the associated expected call is initiated at a respective call time prior to the current time, and wherein the respective call times are different from each other; and

the plurality of hold durations are displayed in association with their respective call times.

12. The computer-implemented method of claim 11, further comprising:

receiving user input selecting an intended call having a particular hold duration of the plurality of hold durations and a particular call time associated with the particular hold duration; and

the selected intended call is scheduled at the particular call time in a calendar associated with the first calling device.

13. The computer-implemented method of claim 12, further comprising causing a notification to be output by the first calling device indicating that the particular call time is approaching or has been reached.

14. The computer-implemented method of claim 12, further comprising automatically initiating, by the first calling device, the call between the first calling device and the target entity at the particular call time.

15. The computer-implemented method of claim 1, wherein causing the hold duration to be displayed is performed during a first call between the first calling device and the target entity, wherein the call between the first calling device and the target entity is a second call, and wherein the first call is initiated before causing the second call between the first calling device and the target entity to be initiated.

16. The computer-implemented method of claim 1, further comprising:

causing a prompt for user feedback to be displayed after the call between the first calling device and the target entity is ended;

receiving the user feedback indicating a degree of accuracy of the hold duration; and

based on the user feedback, a data structure or model for determining the hold duration is updated.

17. A system for providing hold duration estimation for a call, the system comprising:

A memory storing instructions; and

at least one processor coupled to the memory, the at least one processor configured to access the instructions from the memory to perform operations comprising:

obtaining an identifier of a target entity, the identifier usable by a first calling device to initiate a call between the first calling device and the target entity;

determining a hold duration, the hold duration being an estimated amount of time before the call matches a human agent when the call is initiated at a particular time that is expected for a current time, wherein the hold duration is determined based on a plurality of previous calls between one or more calling devices and the target entity; and

the hold duration to be displayed by the first calling device is provided prior to initiating the call between the first calling device and the target entity.

18. The system of claim 17, wherein the operation of determining the hold duration is based on:

call duration data indicating a plurality of call durations of the plurality of previous calls between the one or more calling devices and the target entity; and

Hold duration data indicating a plurality of hold durations of the previous call.

19. The system of claim 17, wherein the at least one processor performs further operations comprising:

determining a plurality of hold durations including the hold duration, wherein each hold duration of the plurality of hold durations indicates a respective estimated amount of time before the call matches the human agent when the call was initiated at a respective call time that is expected for the current time, and wherein the respective call times are different from each other; and causing the plurality of hold durations to be displayed in association with their respective call times.

20. A non-transitory computer-readable medium having instructions stored thereon, which when executed by a processor, cause the processor to perform operations comprising:

obtaining an identifier of a target entity, the identifier usable by a first calling device to initiate a call between the first calling device and the target entity;

determining a hold duration, the hold duration being an estimated amount of time before the call matches a human agent when the call is initiated at a particular time that is an expectation of a current time, wherein the hold duration is determined based on a plurality of previous calls between a plurality of calling devices and the target entity, wherein the plurality of calling devices are associated with a plurality of users; and

The hold duration to be displayed by the first calling device is provided prior to initiating a call between the first calling device and the target entity.