Patent Description:
Clients often use telephony systems to field phone calls from users seeking their services. These telephony systems may allow users to speak with a live representative of the client, or may use an interactive voice response (IVR) system. IVR is a technology that allows a human caller to call and communicate with a computer in a telephony environment. In an IVR telephony environment, the computer typically outputs prerecorded voice audio prompts that the human caller typically answers using dual-tone multi-frequency signaling (DTMF) tones as input via a keypad of the human caller's phone. IVR telephony systems are often used to determine why a human caller is calling so that the human caller can be directed to a human operator that might be able to assist the human caller. However, callers often complain that traditional IVR systems can often waste time by forcing the caller to listen to a lengthy recording reading every option of an extensive menu before the caller can make a selection. Callers can also often be placed on hold for long periods of time waiting to speak to a human operator, or the human operator may not answer the phone at all, leading to frustration.

SMS (short message service) is a text messaging service enabling text-based communication between two mobile phone devices using standardized communication protocols. MMS (multimedia message service) is a messaging service enabling communication between two mobile phone devices that can send images as well as text using standardized communication protocols. Messaging services are convenient for users in that they enable asynchronous communication, alerting users when a message comes in without the users having to pay constant attention as they would during a traditional audio-based telephone call.

<CIT> proposes methods and apparatus for enabling and managing communication sessions with flexibility relative to selection of active media channels.

Embodiments of the present disclosure provide technical solutions to address the technical challenges presented above. For example, a network device (e.g., a user's mobile phone) may be used to make a telephone call to a landline telephone associated with a client device (e.g., a business's device). If the telephone call is terminated, either the network device or the client device may generate a text message to the other and establish a communication session. The client device may present a variety of options to the network device of service requests that may be completed by text message. The network device may transmit the service request and the service request may be fulfilled by the client. At some point thereafter, the client device may terminate the communication session and hand off the conversation to a server (e.g., an aggregator associated with a plurality of client devices, and/or a plurality of terminal devices and agents). The server may accept queries and natural language communications from the network device and answer the queries as appropriate. Unlike the client device, queries made to the server do not have to be client-specific, and may relate to a plurality of clients or any other subject unrelated to the client.

According to a first aspect, there is provided a computer-implemented method as set out in claim <NUM>.

According to a second aspect, there is provided a system as set out in claim <NUM>.

According to a third aspect, there is provided a computer-program product as set out in claim <NUM>.

In the appended figures, similar components and/or features can have the same reference label. Further, various components of the same type can be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components.

The ensuing description provides examples of embodiment(s) only and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the examples of embodiment(s) will provide those skilled in the art with an enabling description for implementing examples of embodiment. It is understood that various changes can be made in the function and arrangement of elements without departing from the scope as set forth in the appended claims.

<FIG> shows a block diagram of an embodiment of a network interaction system which implements and supports certain embodiments and features described herein. Certain embodiments relate to establishing a connection channel between a network device <NUM> (which can be operated by a user <NUM>) and a client device <NUM> associated with a client <NUM>. In certain embodiments, the network interaction system can include a terminal device <NUM> (which can be operated by an agent <NUM>).

In certain embodiments, a user <NUM> can be an individual attempting to contact a client <NUM> via telephonic device <NUM>. A client <NUM> can be an entity that provides, operates, or runs a service, or individuals employed by or assigned by such an entity to perform the tasks available to a client <NUM> as described herein. The agent <NUM> can be an individual, such as a support agent tasked with providing support or information to the user <NUM> regarding the service. Out of a large number of agents, a subset of agents may be appropriate for providing support or information for a particular client <NUM>. The agent <NUM> may be affiliated or not affiliated with the client <NUM>. Each agent can be associated with one or more clients <NUM>. In some non-limiting examples, a user <NUM> can be an individual attempting to book an appointment via a cell phone, a client <NUM> can be a company that provides medical services, and an agent <NUM> can be a representative employed by the company. In various embodiments, the user <NUM>, client <NUM>, and agent <NUM> can be other individuals or entities.

While <FIG> shows only a single network device <NUM>, terminal device <NUM> and client device <NUM> coupled to a database <NUM>, an interaction system can include multiple or many (e.g., tens, hundreds or thousands) of each of one or more of these types of devices. In various implementations, different nodes of an interaction system can include repeated copies of client device <NUM>, telephonic device <NUM>, and other devices coupled to one or more shared database(s) <NUM> for client <NUM>. Similarly, while <FIG> shows only a single user <NUM>, agent <NUM> and client <NUM>, an interaction system of <FIG> can include multiple or many of each of one or more of such entities. Thus, it may be necessary to determine which terminal device is to be selected to communicate with a given network device. Further complicating matters, a remote server <NUM> may also be configured to receive and respond to select network-device communications.

A connection management system <NUM> can facilitate strategic routing of communications. A communication can include a message with content (e.g., defined based on input from an entity, such as typed or spoken input). The communication can also include additional data, such as data about a transmitting device (e.g., an IP address, account identifier, device type and/or operating system); a destination address; an identifier of a client; an identifier of a webpage or webpage element (e.g., a webpage or webpage element being visited when the communication was generated or otherwise associated with the communication) or online history data; a time (e.g., time of day and/or date); and/or destination address. Other information can be included in the communication. In some instances, connection management system <NUM> routes the entire communication to another device. In some instances, connection management system <NUM> modifies the communication or generates a new communication (e.g., based on the initial communication). The new or modified communication can include the message (or processed version thereof), at least some (or all) of the additional data (e.g., about the transmitting device, webpage or online history and/or time) and/or other data identified by connection management system <NUM> (e.g., account data associated with a particular account identifier or device). The new or modified communication can include other information as well.

Part of strategic-routing facilitation can include establishing, updating and using one or more connection channels between network device <NUM> and one or more terminal devices <NUM>. For example, upon receiving a communication from network device <NUM>, connection management system <NUM> can first estimate to which client (if any) the communication corresponds. Upon identifying a client, connection management system <NUM> can identify a terminal device <NUM> associated with the client for communication with network device <NUM>. In some instances, the identification can include evaluating a profile of each of a plurality of agents (or experts or delegates), each agent (e.g., agent <NUM>) in the plurality of agents being associated with a terminal device (e.g., terminal device <NUM>). The evaluation can relate to a content in a network-device message.

In some instances, connection management system <NUM> can determine whether any connection channels are established between network device <NUM> and a terminal device associated with the client (or remote server <NUM>) and, if so, whether such channel is to be used to exchange a series of communications including the communication.

Upon selecting a terminal device <NUM> to communicate with network device <NUM>, connection management system <NUM> can establish a connection channel between the network device <NUM> and terminal device <NUM>. In some instances, connection management system <NUM> can transmit a message to the selected terminal device <NUM>. The message may request an acceptance of a proposed assignment to communicate with a network device <NUM> or identify that such an assignment has been generated. The message can include information about network device <NUM> (e.g., IP address, device type, and/or operating system), information about an associated user <NUM> (e.g., language spoken, duration of having interacted with client, skill level, sentiment, and/or topic preferences), a received communication, code (e.g., a clickable hyperlink) for generating and transmitting a communication to the network device <NUM>, and/or an instruction to generate and transmit a communication to network device <NUM>.

In one instance, communications between network device <NUM> and terminal device <NUM> can be routed through connection management system <NUM>. Such a configuration can allow connection management system <NUM> to monitor the communication exchange and to detect issues (e.g., as defined based on rules) such as non-responsiveness of either device or extended latency. Further, such a configuration can facilitate selective or complete storage of communications, which may later be used, for example, to assess a quality of a communication exchange and/or to support learning to update or generate routing rules so as to promote particular post-communication targets.

In some embodiments, connection management system <NUM> can monitor the communication exchange in real-time and perform automated actions (e.g., rule-based actions) based on the live communications. For example, when connection management system <NUM> determines that a communication relates to a particular item (e.g., product), connection management system <NUM> can automatically transmit an additional message to terminal device <NUM> containing additional information about the item (e.g., quantity of item available, links to support documents related to the item, or other information about the item or similar items).

In one instance, a designated terminal device <NUM> can communicate with network device <NUM> without relaying communications through connection management system <NUM>. One or both devices <NUM>, <NUM> may (or may not) report particular communication metrics or content to connection management system <NUM> to facilitate communication monitoring and/or data storage.

As mentioned, connection management system <NUM> may route select communications to a remote server <NUM>. Remote server <NUM> can be configured to provide information in a predetermined manner. For example, remote server <NUM> may access defined one or more text passages, voice recording and/or files to transmit in response to a communication. Remote server <NUM> may select a particular text passage, recording or file based on, for example, an analysis of a received communication (e.g., a semantic or mapping analysis).

Routing and/or other determinations or processing performed at connection management system <NUM> can be performed based on rules and/or data at least partly defined by or provided by one or more client devices <NUM>. For example, client device <NUM> may transmit a communication that identifies a prioritization of agents, terminal-device types, and/or topic/skill matching. As another example, client device <NUM> may identify one or more weights to apply to various variables potentially impacting routing determinations (e.g., language compatibility, predicted response time, device type and capabilities, and/or terminal-device load balancing). It will be appreciated that which terminal devices and/or agents are to be associated with a client may be dynamic. Communications from client device <NUM> and/or terminal devices <NUM> may provide information indicating that a given terminal device and/or agent is to be added or removed as one associated with a client. For example, client device <NUM> can transmit a communication with IP address and an indication as to whether a terminal device with the address is to be added or removed from a list identifying client-associated terminal devices.

Each communication (e.g., between devices, between a device and connection management system <NUM>, between remote server <NUM> and connection management system <NUM> or between remote server <NUM> and a device) can occur over one or more networks <NUM>. Any combination of open or closed networks can be included in the one or more networks <NUM>. Examples of suitable networks include the Internet, a personal area network, a local area network (LAN), a wide area network (WAN), or a wireless local area network (WLAN). Other networks may be suitable as well. The one or more networks <NUM> can be incorporated entirely within or can include an intranet, an extranet, or a combination thereof. In some instances, a network in the one or more networks <NUM> includes a short-range communication channel, such as a Bluetooth or a Bluetooth Low Energy channel. In one embodiment, communications between two or more systems and/or devices can be achieved by a secure communications protocol, such as secure sockets layer (SSL) or transport layer security (TLS). In addition, data and/or transactional details may be encrypted based on any convenient, known, or to be developed manner, such as, but not limited to, Data Encryption Standard (DES), Triple DES, Rivest-Shamir-Adleman encryption (RSA), Blowfish encryption, Advanced Encryption Standard (AES), CAST-<NUM>, CAST-<NUM>, Decorrelated Fast Cipher (DFC), Tiny Encryption Algorithm (TEA), extended TEA (XTEA), Corrected Block TEA (XXTEA), and/or RC5, etc..

A network device <NUM>, terminal device <NUM> and/or client device <NUM> can include, for example, a portable electronic device (e.g., a smart phone, tablet, laptop computer, or smart wearable device) or a non-portable electronic device (e.g., one or more desktop computers, smart appliances, servers, and/or processors). Connection management system <NUM> can be separately housed from network, terminal and client devices or may be part of one or more such devices (e.g., via installation of an application on a device). Remote server <NUM> may be separately housed from each device and connection management system <NUM> and/or may be part of another device or system. While each device, server and system in <FIG> is shown as a single device, it will be appreciated that multiple devices may instead be used. For example, a set of network devices can be used to transmit various communications from a single user, or remote server <NUM> may include a server stack.

A software agent or application may be installed on and/or executable on a depicted device, system or server. In one instance, the software agent or application is configured such that various depicted elements can act in complementary manners. For example, a software agent on a device can be configured to collect and transmit data about device usage to a separate connection management system, and a software application on the separate connection management system can be configured to receive and process the data.

<FIG> shows a block diagram of another embodiment of a network interaction system. Generally, <FIG> illustrates a variety of components configured and arranged to enable a network device <NUM> to communicate with one or more terminal devices <NUM> via network connections such as router <NUM> and wide area network <NUM>. The depicted instance includes nine terminal devices <NUM> included in three local-area networks <NUM>.

In some instances, a communication from network device <NUM> includes destination data (e.g., a destination IP address) that at least partly or entirely indicates which terminal device is to receive the communication. A network interaction system such as the system described in <FIG> can include one or more inter-network connection components <NUM> that can process the destination data and facilitate appropriate routing.

Each inter-network connection components <NUM> can be connected to a plurality of networks <NUM> and can have multiple network cards installed (e.g., each card connected to a different network). For example, an inter-network connection component <NUM> can be connected to a wide-area network <NUM> (e.g., the Internet) and one or more local-area networks <NUM>. In the depicted instance, in order for a communication to be transmitted from network device <NUM> to any of the terminal devices, in the depicted system, the communication is handled by multiple inter-network connection components <NUM>. Similarly, communications with client device <NUM> via router <NUM> are also handled by inter-network connection components <NUM>.

When an inter-network connection component <NUM> receives a communication (or a set of packets corresponding to the communication), inter-network connection component <NUM> can determine at least part of a route to pass the communication to a network associated with a destination. The route can be determined using, for example, a routing table (e.g., stored at the router), which can include one or more routes that are pre-defined, generated based on an incoming message (e.g., from another router or from another device) or learned.

Examples of inter-network connection components <NUM> include a router <NUM> and a gateway <NUM>. An inter-network connection component <NUM> (e.g., gateway <NUM>) may be configured to convert between network systems or protocols. For example, gateway <NUM> may facilitate communication between Transmission Control Protocol/Internet Protocol (TCP/IP) and Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) devices.

Upon receiving a communication at a local-area network <NUM>, further routing may still be performed. Such intra-network routing can be performed via an intra-network connection component <NUM>, such as a switch <NUM> or hub <NUM>. Each intra-network connection component <NUM> can be connected to (e.g., wirelessly or wired, such as via an Ethernet cable) multiple terminal devices <NUM>. Hub <NUM> can be configured to repeat all received communications to each device to which it is connected. Each terminal device can then evaluate each communication to determine whether the terminal device is the destination device or whether the communication is to be ignored. Switch <NUM> can be configured to selectively direct communications to only the destination terminal device.

In some instances, a local-area network <NUM> can be divided into multiple segments, each of which can be associated with independent firewalls, security rules and network protocols. An intra-network connection component <NUM> can be provided in each of one, more or all segments to facilitate intra-segment routing. A bridge <NUM> can be configured to route communications across segments <NUM>.

To appropriately route communications across or within networks, various components analyze destination data in the communications. For example, such data can indicate which network a communication is to be routed to, which device within a network a communication is to be routed to or which communications a terminal device is to process (versus ignore). However, in some instances, it is not immediately apparent which terminal device (or even which network) is to participate in a communication from a network device.

To illustrate, a set of terminal devices may be configured so as to provide similar types of responsive communications. Thus, it may be expected that a query in a communication from a network device may be responded to in similar manners regardless to which network device the communication is routed. While this assumption may be true at a high level, various details pertaining to terminal devices can give rise to particular routings being advantageous as compared to others. For example, terminal devices in the set may differ from each other with respect to (for example) which communication channels are supported, geographic and/or network proximity to a network device and/or characteristics of associated agents (e.g., knowledge bases, experience, languages spoken, availability, general personality or sentiment, etc.). Accordingly, select routings may facilitate faster responses that more accurately and/or completely respond to a network-device communication. A complication is that static routings mapping network devices to terminal devices may fail to account for variations in communication topics, channel types, agent availability, and so on.

In <FIG>, connection management system <NUM> can be configured to serve as a relay and/or destination address. Thus, for example, a set of network devices <NUM> may transmit communications, each identifying connection management system <NUM> as a destination. Connection management system <NUM> can receive each communication and can concurrently monitor a set of terminal devices (e.g., so as to generate metrics for each terminal device). Based on the monitoring and a rule, connection management system <NUM> can identify a terminal device <NUM> to which it may relay each communication. Depending on the embodiment, terminal device communications may similarly be directed to a consistent destination (e.g., of connection management system <NUM>) for further relaying, or terminal devices may begin communicating directly with corresponding network devices. These embodiments can facilitate efficient routing and thorough communication monitoring.

It will be appreciated that many variations of <FIG> are contemplated. For example, connection management system <NUM> may be associated with a connection component (e.g., inter-network connection component <NUM> or intra-network connection component <NUM>) such that an application corresponding to connection management system <NUM> (or part thereof) is installed on the component. The application may, for example, perform independently or by communicating with one or more similar or complementary applications (e.g., executing on one or more other components, network devices or remotes servers).

<FIG> shows a representation of a protocol-stack mapping of connection components' operation. More specifically, <FIG> identifies a layer of operation in an Open Systems Interaction (OSI) model that corresponds to various connection components.

The OSI model can include multiple logical layers <NUM>-<NUM>. The layers are arranged in an ordered stack, such that layers <NUM>-<NUM> each serve a higher level and layers <NUM>-<NUM> is each served by a lower layer. The OSI model includes a physical layer <NUM>. Physical layer <NUM> can define parameters physical communication (e.g., electrical, optical, or electromagnetic). Physical layer <NUM> also defines connection management protocols, such as protocols to establish and close connections. Physical layer <NUM> can further define a flow-control protocol and a transmission mode.

A link layer <NUM> can manage node-to-node communications. Link layer <NUM> can detect and correct errors (e.g., transmission errors in the physical layer <NUM>) and manage access permissions. Link layer <NUM> can include a media access control (MAC) layer and logical link control (LLC) layer.

A network layer <NUM> can coordinate transferring data (e.g., of variable length) across nodes in a same network (e.g., as datagrams). Network layer <NUM> can convert a logical network address to a physical machine address.

A transport layer <NUM> can manage transmission and receipt quality. Transport layer <NUM> can provide a protocol for transferring data, such as a Transmission Control Protocol (TCP). Transport layer <NUM> can perform segmentation/desegmentation of data packets for transmission and can detect and account for transmission errors occurring in layers <NUM>-<NUM>. A session layer <NUM> can initiate, maintain and terminate connections between local and remote applications. Sessions may be used as part of remote-procedure interactions. A presentation layer <NUM> can encrypt, decrypt and format data based on data types known to be accepted by an application or network layer.

An application layer <NUM> can interact with software applications that control or manage communications. Via such applications, application layer <NUM> can (for example) identify destinations, local resource states or availability and/or communication content or formatting. Various layers <NUM>-<NUM> can perform other functions as available and applicable.

Intra-network connection components <NUM>, <NUM> are shown to operate in physical layer <NUM> and link layer <NUM>. More specifically, a hub can operate in the physical layer, such that operations can be controlled with respect to receipts and transmissions of communications. Because hubs lack the ability to address communications or filter data, they possess little to no capability to operate in higher levels. Switches, meanwhile, can operate in a link layer, as they are capable of filtering communication frames based on addresses (e.g., MAC addresses).

Meanwhile, inter-network connection components <NUM>, <NUM> are shown to operate on higher levels (e.g., layers <NUM>-<NUM>). For example, routers can filter communication data packets based on addresses (e.g., IP addresses). Routers can forward packets to particular ports based on the address, so as to direct the packets to an appropriate network. Gateways can operate at the network layer and above, perform similar filtering and directing and further translation of data (e.g., across protocols or architectures).

A connection management system <NUM> can interact with and/or operate on, in various embodiments, one, more, all or any of the various layers. For example, connection management system <NUM> can interact with a hub so as to dynamically adjust which terminal devices or client devices the hub communicates. As another example, connection management system <NUM> can communicate with a bridge, switch, router or gateway so as to influence which terminal device the component selects as a destination (e.g., MAC, logical or physical) address. By way of further examples, a connection management system <NUM> can monitor, control, or direct segmentation of data packets on transport layer <NUM>, session duration on session layer <NUM>, and/or encryption and/or compression on presentation layer <NUM>. In some embodiments, connection management system <NUM> can interact with various layers by exchanging communications with (e.g., sending commands to) equipment operating on a particular layer (e.g., a switch operating on link layer <NUM>), by routing or modifying existing communications (e.g., between a network device and a client device) in a particular manner, and/or by generating new communications containing particular information (e.g., new destination addresses) based on the existing communication. Thus, connection management system <NUM> can influence communication routing and channel establishment (or maintenance or termination) via interaction with a variety of devices and/or via influencing operating at a variety of protocol-stack layers.

<FIG> represents a multi-device communication exchange system according to an embodiment. The system includes a network device <NUM> configured to communicate with a variety of types of terminal devices and client devices over a variety of types of communication channels.

In the depicted instance, network device <NUM> can transmit a telephonic or text message communication over a cellular network (e.g., via a base station <NUM>). The communication can be routed to a client location <NUM> or a terminal location <NUM>. A connection management system <NUM> receives the communication and identifies which client device or terminal device is to respond to the communication. Such determination can depend on identifying a client to which that communication pertains (e.g., based on a content analysis or user input indicative of the client) and determining one or more metrics for each of one or more terminal devices associated with the client. For example, in <FIG>, each cluster of terminal devices 440A, 440B, and 440C can correspond to a different client or to different nodes for a particular client (e.g. nodes focused on different topics, response types, or associated with a particular routing path or parts of a routing path). The terminal devices may be geographically co-located or disperse. The metrics may be determined based on stored or learned data and/or real-time monitoring (e.g., based on availability).

Connection management system <NUM> can communicate with various terminal devices and client devices and other components via one or more routers <NUM> or other inter-network or intra-network connection components. Connection management system <NUM> may collect, analyze and/or store data from or pertaining to communications, terminal-device operations, client rules, and/or user-associated actions (e.g., online activity) at one or more data stores. Such data may influence communication routing.

For example, machine learning models can use previous data and results of routing from prior operations to improve selection of future routing. This can be done with any combination of supervised learning with constructed data sets and historical data, unsupervised learning based on expectation or projection models for current routing paths in a system and system use targets, Any such data can be used in operations for natural language processing (e.g. natural language understanding, natural language inference, etc.) to generate natural language data or to update machine learning models. Such data can then be used by the client systems or shared with applications running on a network device or on a server to improve dynamic message processing (e.g. improved intent indicator data results or response message generation).

Client device <NUM> may also be connected to a telephonic device <NUM> associated with a client location. The telephonic device <NUM> may be a landline phone associated with a telephone number in some embodiments. Network device <NUM> may have the capability to generate and transmit a text (e.g., SMS) message to the telephone number associated with the telephonic device <NUM>, which may be routed to the client device <NUM> in some embodiments. The client device <NUM> may be capable of receiving and processing text messages. In order to process received text messages from network device <NUM>, client device <NUM> may be coupled to a server <NUM>. Server <NUM> may receive and respond to inquiries from client device <NUM> for information regarding the goods or services provided at the client location <NUM>, such as product information, an appointment schedule, hours of operation, location information, contact information, and the like.

<FIG> shows a block diagram of an embodiment of a connection management system. A message receiver interface <NUM> can receive a message. In some instances, the message can be received, for example, as part of a communication transmitted by a source device (e.g., housed separately from connection management system or within a same housing), such as a network device. In some instances, the communication can be part of a series of communications or a communicate exchange, which can include a series of messages or message exchange being routed between two devices (e.g., a network device and a client device). This message or communication exchange may be part of and/or may define an interaction between the devices. A communication channel or operative channel can include one or more protocols (e.g., routing protocols, task-assigning protocols and/or addressing protocols) used to facilitate routing and a communication exchange between the devices.

In some instances, the message can include a message generated based on inputs received at a local or remote user interface. For example, the message can include a message that was generated based on button or key presses or recorded speech signals. In one instance, the message includes an automatically generated message, such as one generated upon detecting that a network device has provided a particular input command (e.g., key sequence). The message can include an instruction or request, such as one to initiate a communication exchange.

In some instances, the message can include or be associated with an identifier of a client. For example, the message can explicitly identify the client (or a device associated with the client); the message can include or be associated with a webpage or app page associated with the client; the message can include or be associated with a destination address associated with a client; or the message can include or be associated with an identification of an item (e.g., product) or service associated with the client. To illustrate, a network device may be presenting an app page of a particular client, which may offer an option to transmit a communication to an agent. Upon receiving user input corresponding to a message, a communication may be generated to include the message and an identifier of the particular client (e.g., a text message to a phone number).

A processing engine <NUM> may process a received communication and/or message. Processing can include, for example, extracting one or more particular data elements (e.g., a message, a client identifier, a network-device identifier, an account identifier, and so on). Processing can include transforming a formatting or communication type (e.g., to be compatible with a particular device type, operating system, communication-channel type, protocol and/or network).

A message assessment engine <NUM> may assess the (e.g., extracted or received) message. The assessment can include identifying, for example, one or more categories or tags for the message. Examples of category or tag types can include (for example) topic, sentiment, complexity, and urgency. A difference between categorizing and tagging a message can be that categories can be limited (e.g., according to a predefined set of category options), while tags can be open. A topic can include, for example, a technical issue, a use question, or a request. A category or tag can be determined, for example, based on a semantic analysis of a message (e.g., by identifying keywords, sentence structures, repeated words, punctuation characters and/or non-article words); user input (e.g., having selected one or more categories); and/or message-associated statistics (e.g., typing speed and/or response latency).

In some instances, message assessment engine <NUM> can determine a metric for a message. A metric can include, for example, a number of characters, words, capital letters, all-capital words or instances of particular characters or punctuation marks (e.g., exclamation points, question marks and/or periods). A metric can include a ratio, such as a fraction of sentences that end with an exclamation point (or question mark), a fraction of words that are all capitalized, and so on.

Message assessment engine <NUM> can store a message, message metric and/or message statistic in a message data store <NUM>. Each message can also be stored in association with other data (e.g., metadata), such as data identifying a corresponding source device, destination device, network device, terminal device, client, one or more categories, one or more stages and/or message-associated statistics). Various components of the connection management system (e.g., message assessment engine <NUM> and/or an interaction management engine <NUM>) can query message data store <NUM> to retrieve query-responsive messages, message metrics and/or message statistics.

An interaction management engine <NUM> can determine to which device a communication is to be routed and how the receiving and transmitting devices are to communicate. Each of these determinations can depend, for example, on whether a particular network device (or any network device associated with a particular user) has previously communicated with a client device or terminal device in a set of terminal devices (e.g., any terminal device associated with the connection management system or any terminal device associated with one or more particular clients).

In some instances, when a network device (or other network device associated with a same user or profile) has previously communicated with a given terminal device, communication routing can be generally biased towards the same terminal device. Other factors that may influence routing can include, for example, whether the terminal device (or corresponding agent) is available and/or a predicted response latency of the terminal device. Such factors may be considered absolutely or relative to similar metrics corresponding to other terminal devices. A re-routing rule (e.g., a client-specific or general rule) can indicate how such factors are to be assessed and weighted to determine whether to forego agent consistency.

When a network device (or other network device associated with a same user or account) has not previously communicated with a given terminal device, a terminal-device selection can be performed based on factors such as, for example, an extent to which various agents' knowledge base corresponds to a communication topic, availability of various agents at a given time and/or over a channel type, types and/or capabilities of terminal devices (e.g., associated with the client). In one instance, a rule can identify how to determine a sub-parameter to one or more factors such as these and a weight to assign to each parameter. By combining (e.g., summing) weighted sub-parameters, a parameter for each agent can be determined. A terminal device selection can then be made by comparing terminal devices' parameters.

With regard to determining how devices are to communicate, interaction management engine <NUM> can (for example) determine whether a client device or terminal device is to respond to a communication via (for example) SMS message, voice call, video communication, etc. A communication type can be selected based on, for example, a communication-type priority list (e.g., at least partly defined by a client or user); a type of a communication previously received from the network device (e.g., so as to promote consistency), a complexity of a received message, capabilities of the network device, and/or an availability of one or more terminal devices. Appreciably, some communication types will result in real-time communication (e.g., where fast message response is expected), while others can result in asynchronous communication (e.g., where delays (e.g., of several minutes or hours) between messages are acceptable).

Further, interaction management engine <NUM> can determine whether a continuous channel between two devices should be established, used or terminated. A continuous channel can be structured so as to facilitate routing of future communications from a network device to a specified terminal device or client device. This bias can persist even across message series. In some instances, a representation of a continuous channel (e.g., identifying an agent) can be included in a presentation to be presented on a network device. In this manner, a user can understand that communications are to be consistently routed so as to promote efficiency.

In one instance, a parameter can be generated using one or more factors described herein and a rule (e.g., that includes a weight for each of the one or more factors) to determine a connection parameter corresponding to a given network device and terminal device. The parameter may pertain to an overall match or one specific to a given communication or communication series. Thus, for example, the parameter may reflect a degree to which a given terminal device is predicted to be suited to respond to a network-device communication. In some instances, a parameter analysis can be used to identify each of a terminal device to route a given communication to and whether to establish, use or terminate a connection channel. When a parameter analysis is used to both address a routing decision and a channel decision, a parameter relevant to each decision may be determined in a same, similar or different manner.

Thus, for example, it will be appreciated that different factors may be considered depending on whether the parameter is to predict a strength of a long-term match versus one to respond to a particular message query. For example, in the former instance, considerations of overall schedules and time zones may be important, while in the latter instance, immediate availability may be more highly weighted. A parameter can be determined for a single network-device/terminal-device combination, or multiple parameters can be determined, each characterizing a match between a given network device and a different terminal device.

To illustrate, a set of three terminal devices associated with a client may be evaluated for potential communication routing. A parameter may be generated for each that relates to a match for the particular communication. Each of the first two terminal devices may have previously communicated with a network device having transmitted the communication. An input from the network device may have indicated positive feedback associated with an interaction with the communication(s) with the first device. Thus, a past-interact sub-parameter (as calculated according to a rule) for the first, second and third devices may be <NUM>, <NUM>, and <NUM>, respectively. (Negative feedback inputs may result in negative sub-parameters. ) It may be determined that only the third terminal device is available. It may be predicted that the second terminal device will be available for responding within <NUM> minutes, but that the first terminal device will not be available for responding until the next day. Thus, a fast-response sub-parameter for the first, second and third devices may be <NUM>, <NUM> and <NUM>. Finally, it may be estimated a degree to which an agent (associated with the terminal device) is knowledgeable about a topic in the communication. It may be determined that an agent associated with the third terminal device is more knowledgeable than those associated with the other two devices, resulting in sub-parameters of <NUM>, <NUM> and <NUM>. In this example, the rule does not include weighting or normalization parameters (though, in other instances, a rule may), resulting in parameters of <NUM>, <NUM> and <NUM>. Thus, the rule may indicate that the message is to be routed to a device with the highest parameter, that being the third terminal device. If routing to a particular terminal device is unsuccessful, the message can be routed to a device with the next-highest parameter, and so on.

A parameter may be compared to one or more absolute or relative thresholds. For example, parameters for a set of terminal devices can be compared to each other to identify a high parameter to select a terminal device to which a communication can be routed. As another example, a parameter (e.g., a high parameter) can be compared to one or more absolute thresholds to determine whether to establish a continuous channel with a terminal device. In some embodiments, an overall threshold for establishing a continuous channel are higher than a threshold for consistently routing communications in a given series of messages. In some embodiments, this difference between the overall threshold and threshold for determining whether to consistently route communication may be because a strong match is important in the continuous-channel context given the extended utility of the channel. In some other embodiments, an overall threshold for using a continuous channel is lower than a threshold for establishing a continuous channel and/or for consistently routing communications in a given series of messages.

Interaction management engine <NUM> can interact with an account engine <NUM> in various contexts. For example, account engine <NUM> may look up an identifier of a network device or terminal device in an account data store <NUM> to identify an account corresponding to the device. Further, account engine <NUM> can maintain data about previous communication exchanges (e.g., times, involved other device(s), channel type, resolution stage, topic(s) and/or associated client identifier), connection channels (e.g., indicating - for each of one or more clients - whether any channels exist, a terminal device associated with each channel, an establishment time, a usage frequency, a date of last use, any channel constraints and/or supported types of communication), user or agent preferences or constraints (e.g., related to terminal-device selection, response latency, terminal-device consistency, agent expertise, and/or communication-type preference or constraint), and/or user or agent characteristics (e.g., age, language(s) spoken or preferred, geographical location, interests, and so on).

Further, interaction management engine <NUM> can alert account engine <NUM> of various connection-channel actions, such that account data store <NUM> can be updated to reflect the current channel data. For example, upon establishing a channel, interaction management engine <NUM> can notify account engine <NUM> of the establishment and identify one or more of: a network device, a terminal device, an account and a client. Account engine <NUM> can (in some instances) subsequently notify a user of the channel's existence such that the user can be aware of the agent consistency being availed.

Interaction management engine <NUM> can further interact with a client mapping engine <NUM>, which can map a communication to one or more clients (and/or associated brands). In some instances, a communication received from a network device itself includes an identifier corresponding to a client (e.g., an identifier of a client, webpage, or app page). The identifier can be included as part of a message (e.g., which client mapping engine <NUM> may detect) or included as other data in a message-inclusive communication. Client mapping engine <NUM> may then look up the identifier in a client data store <NUM> to retrieve additional data about the client and/or an identifier of the client.

In some instances, a message may not particularly correspond to any client. For example, a message may include a general query. Client mapping engine <NUM> may, for example, perform a semantic analysis on the message, identify one or more keywords and identify one or more clients associated with the keyword(s). In some instances, a single client is identified. In some instances, multiple clients are identified. An identification of each client may then be presented via a network device such that a user can select a client to communicate with (e.g., via an associated terminal device).

Client data store <NUM> can include identifications of one or more terminal devices (and/or agents) associated with the client. A terminal routing engine <NUM> can retrieve or collect data pertaining to each of one, more or all such terminal devices (and/or agents) so as to influence routing determinations. For example, terminal routing engine <NUM> may maintain a terminal data store, which can store information such as terminal devices' device types, operating system, communication-type capabilities, installed applications accessories, geographic location and/or identifiers (e.g., IP addresses). Some information can be dynamically updated. For example, information indicating whether a terminal device is available may be dynamically updated based on (for example) a communication from a terminal device (e.g., identifying whether the device is asleep, being turned off/on, non-active/active, or identifying whether input has been received within a time period); a communication routing (e.g., indicative of whether a terminal device is involved in or being assigned to be part of a communication exchange); or a communication from a network device or terminal device indicating that a communication exchange has ended or begun.

It will be appreciated that, in various contexts, being engaged in one or more communication exchanges does not necessarily indicate that a terminal device is not available to engage in another communication exchange. Various factors, such as communication types (e.g., message), client-identified or user-identified target response times, and/or system loads (e.g., generally or with respect to a user) may influence how many exchanges a terminal device may be involved in.

When interaction management engine <NUM> has identified a terminal device or client device to involve in a communication exchange or connection channel, it can notify terminal routing engine <NUM>, which may retrieve any pertinent data about the terminal device from terminal data store <NUM>, such as a destination (e.g., IP) address, device type, protocol, etc. Processing engine <NUM> can then (in some instances) modify the message-inclusive communication or generate a new communication (including the message) so as to have a particular format, comply with a particular protocol, and so on. In some instances, a new or modified message may include additional data, such as account data corresponding to a network device, a message chronicle, and/or client data.

A message transmitter interface <NUM> can then transmit the communication to the terminal device or client device. The transmission may include, for example, a wired or wireless transmission to a device housed in a separate housing. The terminal device can include a terminal device in a same or different network (e.g., local-area network) as the connection management system. Accordingly, transmitting the communication to the terminal device can include transmitting the communication to an inter- or intra-network connection component.

<FIG> shows a block diagram of a network environment for dynamic and automatic message processing during communication sessions. As shown in <FIG>, a user <NUM> may use a network device <NUM> to connect to a server <NUM> over cloud network <NUM>. Network device <NUM> may be any suitable device, such as a mobile device, that is capable of transmitting and receiving communications in the form of text messages. In some embodiments, network device <NUM> may further be capable of making telephone calls. Cloud network <NUM> may be any suitable network configured to support text messaging, such as a cellular network.

Server <NUM> may be in the form of any suitable server that is also capable of sending and receiving text messages. Alternatively, server <NUM> may be in communication with another device capable of sending and receiving text messages. In some embodiments, server <NUM> may include or may be a connection management system. Server <NUM> may include a destination determination engine <NUM>, a data aggregation engine <NUM>, and a unified user profile database <NUM>. In addition, server <NUM> may be in communication with a plurality of client devices 635A-C. Although shown and described as three client devices 635A-C, it is contemplated that server <NUM> may be in communication with any number of client devices.

The destination determination engine <NUM> may be configured to, in conjunction with a processor (not shown), receive text messages from network device <NUM> over cloud network <NUM>. Destination determination engine <NUM> may determine the appropriate client device of the plurality of client devices 635A-C to which to route the text message. Destination determination engine <NUM> may, in some embodiments, determine that the server <NUM> is the appropriate destination for the text message, based on the content of the text message. In some embodiments, server <NUM> may be omitted, and text messages may be routed directly between the network device <NUM> and one or more of the client devices 635A-C. Destination determination engine <NUM> can further be configured to receive communications from the client devices 635A-C, reformat the communications as text messages, and route the text messages to the appropriate network device <NUM>.

The data aggregation engine <NUM> may be configured to, in conjunction with a processor (not shown), request and/or retrieve data relative to user <NUM> or network device <NUM> from one or more of client devices 635A-C. Data aggregation engine <NUM> may, in response to a text message from network device <NUM>, request data from client devices 635A, 635B, and 635C based on the content of the text message. For example, server <NUM> may receive a text message from network device <NUM> stating, "Send me all restaurants in McPherson Square that have a <NUM>:<NUM> PM reservation for <NUM> tonight. " Data aggregation engine <NUM> may formulate a query to client devices 635A and 635C, which are associated with restaurants in McPherson Square, regarding whether they have reservations for <NUM> at <NUM>:<NUM> PM. When responses are received, they can be stored in association with the text message and an identifier of the user <NUM> and/or the network device <NUM> in the unified user profile database <NUM>. In addition, the responses can be routed back to the network device <NUM>.

<FIG> shows a block diagram of a message environment that dynamically switches between a network device, a client device, and a connection management system (e.g. a server or aggregation server). A user <NUM> uses a network device <NUM> to send text messages to client <NUM>. The text messages may be sent to a landline telephone number associated with the client <NUM>. In some embodiments, the text messages may be sent after user <NUM> uses the network device <NUM> to place a phone call to client <NUM> on the landline telephone number. Client <NUM> may be any goods or services provider.

For example, user <NUM> may use network device <NUM> to transmit a text message <NUM> to client <NUM> stating, "Can I make an appointment?" Although shown as network device <NUM> initiating the conversation, it is contemplated that client <NUM> may alternatively initiate the conversation. For example, user <NUM> can use network device <NUM> to call a landline telephone associated with client <NUM>, and client <NUM> can respond with a text message to network device <NUM> instead of answering the call.

In response, client <NUM> can search its scheduling system to determine when available appointments are, and send a text message <NUM> (e.g. a message including a plurality of routing paths) stating, "Appointments are available Monday at <NUM> AM or <NUM> PM". Network device <NUM> can respond with a text message <NUM>, e.g., "Monday at <NUM> AM". Client <NUM> can send a text message <NUM> stating that "Monday at <NUM> AM is confirmed. " Client <NUM> can then update its scheduling system.

Meanwhile, client <NUM> can hand off the conversation to the server <NUM> of the connection management system or a similar server. Connection management system <NUM> is in operative communication with a plurality of clients <NUM> and may be configured to retrieve, aggregate, and store data relating to user <NUM> or network device <NUM>. For example, connection management system <NUM> may send a text message <NUM> to network device <NUM> asking, "See all appointments?" Network device <NUM> may respond with a text message <NUM>, "Yes. " Connection management system <NUM> may communicate with clients <NUM> to retrieve all of the user <NUM>'s appointments with all of the available clients <NUM>. Connection management system <NUM> may transmit a text message <NUM> stating, "Here are all your appointments. " The text message <NUM> may include all of the aggregated data from the clients <NUM>.

Although shown and described with respect to connection management system <NUM> (e.g. a server or an aggregation server) initiating its conversation with user <NUM> via network device <NUM>, it is contemplated that user <NUM> may alternatively initiate a conversation with the connection management system <NUM>. In addition, although shown and described as a direct connection between network device <NUM> and client <NUM>, it is contemplated that connection management system <NUM> may similarly interface between the network device <NUM> and the client <NUM>.

The connection management system <NUM> can, in some embodiments, process a message from a client device for an intent indicator data or intent data. This can include natural language processing to select an intent value associated with a message from a client device to the content management system <NUM>. For example, if client device were to text "appointments" to content management system <NUM> after message <NUM> and before receiving message <NUM>, this word could be processed by content management system <NUM> as an intent indicator data using a machine learning model at connection management system <NUM>. The content management system, using the intent indicator data with the messaging history from client <NUM> could process the text "appointments" to select an intent value from a plurality of possible intent values. Such intent values can includes an option to see all appointments, cancel appointments, reschedule appointments, or other such values. Using the machine learning model, the text "appointments" can be processed to select a response associated with an intent value. In this case, the machine learning model of connection management system <NUM> determines that receiving a response message associated with an intent value of seeing all appointments corresponds most closely with the intent indicator data "appointments", and response with message <NUM> "See all appointments?" By contrast, a new message from network device <NUM> to connection management system <NUM> "new appointment", "cx apptmt", "apt?", "nxt apt", "apt time?", or "cng apt time?" could each result in connection management system <NUM> providing a different response based on a different intent value determined from the intent indicator data identified from the message.

In some such examples, a connection management system can access or store information from previous communications with a client device or account associated with a client device. This can include information on routing paths provided to a client device and routing path selections received at a client from a network device. This information can be received at connection management system <NUM> from client <NUM>, clients <NUM>, or directly from network device <NUM>. The connection management system <NUM> then receives a new message from the network device <NUM>, with the new message including intent indicator data. The intent indicator data can be natural language text or voice information. The intent indicator data can also be metadata received as part of the new message. In some embodiments, the intent indicator data or multiple elements of intent indicator data can include combinations of such data. The connection management system <NUM> then processes the intent indicator data(s) using one or more machine learning models, and generates a response using the machine learning models. As described above, this can be a response including one or more routing paths based on the intent indicator data and any other data available to connection management system to infer an intent of a user of network device <NUM>. A response is then generated by connection management system <NUM> or a client <NUM> managed by connection management system <NUM> based on the intent indicator data and previous data (e.g. a prior selection of a routing path from communications between network device <NUM> and client <NUM>). The response is communicated to network device <NUM> using connection management system <NUM>, including information and data to facilitate display of response data on network device <NUM>.

A connection management system can include an intent processing system that uses intent indicator data to update an intent associated with a user account. The intent data, as described herein, can be collected via a communications session, history data, user profile data, or any such source. One example can include natural language text from a customer indicating an attempt to move money between a main account and a new flex account that has opened and that is associated with the customer. The intent processing system can evaluate this intent indicator data to determine the issue that the customer wishes to have addressed. In this particular instance, the customer may be having trouble transferring funds from one online account to another account. Based on the provided intent indicator data, the intent processing system may gather the intent indicator data with other context data to update intent values or other action values used to determine which client nodes and associated actions or information to take in response to the intent indicator data. This can include intent or action values associated with a context that the request or issue is shared in, a level of urgency, a stress or anxiety level of the customer, whether there is a time pressure, and the like. Further, the intent processing system may identify, based on the intent value selected, what the customer wishes to have resolved.

In one example, based on an identified intent value, an intent processing system of a connection management system identifies a selected process to in order to resolve the issue or request provided by the customer that is associated with the identified intent value. For example, based on the intent indicator data from a customer, the intent processing system may determine that accounts have to be authorized before customers can transfer funds into them. Further, the intent processing system may determine that authorizing an account can be performed online. Based on the identified process, the intent processing system may develop a strategy for responding to the customer intent in a manner that would not only resolve the intent but do so in a manner that leads to a positive customer experience. This can include directing the customer to a client customer service node, or assisting with establishing a connection channel with such a node. The intent system can include machine learning processes that may include developing a foundation for the response, a desired result of the response, and/or any positive additions to give flavor to the response. The contents of the proposed response may be generated based on customer preferences as identified in the customer profile via analysis of past customer interactions with agents as part of a machine learning system. The intent processing system may use the proposed response strategy for routing paths to be provided to a customer for additional selections and approval of the proposed response strategy. This can be part of an existing communication channel, or the intent processing system can establish a new channel for the purpose of communicating with the user and receiving approval of the strategy from the user. If the strategy is approved, the connection management system can assist with a new channel to the appropriate client node. If the strategy is rejected, a new strategy or a default fallback strategy, such as routing user communications to a help desk or help routing path, can be performed. In some systems, any such response can be customized or set based on machine learning algorithms that account for the particular intent indicator data and context data (e.g. user stress, user intent indicators, user history data, etc.) to provide routing data selected by the machine learning algorithm. In addition to customized routing paths, a system can generate customized natural language communications associated with the customized routing paths based on the data (e.g. intent indicator data, action data, user demographic data, etc.) This can include customized language and terminology for a user (e.g. "I see the issue") to provide information customized to the user. Such systems improve the operation of the devices and communication systems by reducing the system resources used by individual users to reach an appropriate resolution, and to improve communication efficiency.

The machine learning model can use a feedback system that monitors communications between a network device (e.g. customer) and a service (e.g. client). Such a performance monitoring system can monitor the interactions between the customer and client to determine whether the client is being effective in addressing the intent of a customer. For instance, the performance monitoring system may evaluate any customer utterances to determine whether the intent is being fulfilled as new intent indicator data is received from a customer (e.g. monitoring frustration levels or machine learning identified indicators that a customer is not achieving expected results from interactions with current nodes of a client system). As an illustrative example, the performance monitoring system may determine that when the customer responds with "Done," the customer has acknowledged positive results from a client provided routing path, and that the customer was able to select a routing path to achieve the customer's intent. Further, when the customer responds with "Thanks! That worked!" the performance monitoring system may determine that the customer's intent has been met. This information can then be used to update machine learning models for any aspect of the system, including analysis of other user's intent indicator data to identify intent values for future system users. For instance, the performance monitoring system may implement an investigative algorithm that monitors client metrics to determine why certain routing paths are selected with negative or positive customer results. Based on this determination, the performance monitoring system can provide feedback to a machine learning algorithm to update operations, node selections, and routing paths to improve system performance. As described herein, a server system (e.g. server <NUM>) can perform any such operations, or the operations can be part of a networked server system with different sub-systems or engines operating together to perform such operations. This can include the configuration described above where server <NUM> may include or may be a connection management system, a destination determination engine <NUM>, a data aggregation engine <NUM>, a unified user profile database <NUM>, or any combination of such elements. In other embodiments, other configurations or implementations can be used.

<FIG> is a flowchart illustrating a method of dynamic messaging processing. At step <NUM>, a message is received from a client device at a network device. The message may be a text message. The message includes a plurality of routing paths. For example, the message may include a plurality of options of service requests that may be fulfilled by the client device if requested by the network device. The message may have been generated by the client device in response to a landline telephone call made by the network device to the client device. In some embodiments, the network device may generate an initial message to the client device via the landline telephone number. The routing path within the message includes the various selection options that can be used or responded to by the network device to allow a user of the network device to indicate a selection of a particular routing path of the plurality of routing paths. One routing path can involve a request for general assistance in navigating the plurality of routing paths. Another routing path can involve selection of a specific category of service requests available from the plurality of routing paths. The plurality of routing paths can include shared branches within a complex set of paths, such with nested sub-paths in a routing tree. Additionally, particular paths in the plurality of routing paths can be associated with servers. These servers are separate from the client devices, and based on the particular information or results expected from a routing path that are associated with services or information available from a server. Additional aspects of such server are used in steps <NUM> and <NUM> below, which can involve messaging to and from such a server.

At step <NUM>, a selection of a routing path of the plurality of routing paths is generated.

A user uses the network device to select (e.g. using input interfaces of the network device) an option correlating to a service request that may be fulfilled by the client device. As described above, such a message can be received following termination of a previous communication channel (e.g. a telephone or voice channel). In some embodiments, a client machine learning model processes information from the previous channel and uses this information to select the plurality of routing paths that are provided to a network device. This can be based, as described above, on any information collected as part of the previous communication as well as any other information about a user or account associated with a network device. The client device may present the plurality of routing paths as a variety of options to the network device of service requests that may be completed by text message. In other embodiments, any such channel or combination of channels including text messaging or other messaging can be used for presentation of the options.

At step <NUM>, a two-way communication session is established between the network device and a node of the client device. This session can be established in response to selection of the routing path at the network device. A client device can have multiple nodes, with certain nodes associated with certain routing paths, so that the node for the two-way communication can be determined based on the selected routing path. For example, if the selected routing path corresponds to a service request for appointments, the associated node of the client device can be a scheduling engine. If the selected routing path is for information, the node can be an assessment and response engine. The communications between the network device and the client device may include conversations or communications regarding fulfillment of the service request. In any case, the network device participates in establishing the two-way communication as a participant in channel communications between the network device and the node.

In some examples, the communications as part of the two-way communication session can be processed and analyzed by one or more engines in a system. In one embodiment, for example natural language processing can be performed on a channel of communications to generate natural language understanding or natural language interpretation data. Such data can be generated by parsing and analyzing not only the data from the communication channel, but other context data as well. This can include metadata from the channel, location or context data derived from the selected routing path and the context of the plurality of routing paths. Other context data such as date, time, user or device identifications or associations, and any other such data can be used as part of natural language understanding or natural language interpretation data. Such data can then be used to generate a value for an intent indicator data from a limited selection of intent indicator data within a system. For example, the plurality of routing paths can be structured in the context of a system to provide data or take actions on behalf of a user, with a limited number of intents associated with the data and actions available within the system. By processing data from the communication channel, channel metadata, context data, previous routing path selection data for a particular user or network device, or any combination of such data, a value associated with an expected user intent can be generated as an intent indicator data.

At step <NUM>, termination of the two-way communication session is facilitated. For example, the client device may fulfill the service request, and no further service requests are made by the network device. The network device can the channel as part of facilitating termination of the two-way communication session. Termination of the communication session may cause the client device to transmit the selected routing path. The selected routing path.

At step <NUM>, data related to the selected routing path is received. For example, if the selected routing path relates to a reservation at one restaurant, information about the restaurant, about other reservations or appointments made, and the like may be received at the network device.

At step <NUM>, the response to the new message is received. In one embodiment, the response is a text message. In other embodiments, other communication channels, including any combination of communication channels described herein, can be used. The response.

The above description is given in a context of a restaurant reservation system. It will be apparent that aspects of such methods can apply to a wide variety of other systems. One client device, for example, can provide customer assistance for a product. The plurality of routing paths can include routing paths for device operation assistance for a functional device, device analysis and repair assistance for a non-functioning device, and ordering assistance for products related to the device. Each sub-set of such routing paths can have a different node at a client device. When a network device selects a particular routing path from among the provided routing paths, a channel is established with a node of the client device. As described above, data that is exchanged on the channel between the network device and the node of the client device as well as other data (e.g. context, metadata for the channel, etc.) can be analyzed to assist with both intent indicator data value selection at a network device and machine-analysis at the client device or server. The client device or a server can then provide additional information to the network device after a two-way communication session is terminated, and the network device can display the response. This can include details on ordering replacement parts, directions for selecting operating modes of a device, links or communication channel information for interacting with third parties about ordering related items or where to find additional information.

<FIG> is a flowchart illustrating a method of dynamic messaging processing and data aggregation. In some implementations, process <NUM> of <FIG> corresponds to server operations interacting with a network device performing corresponding operations of process <NUM>. In other embodiments, process <NUM> can interact with a network device and client devices performing other similar corresponding operations for message processing and data aggregation. Process <NUM> can be performed by a server system, such as server <NUM>, or any other such system. In some embodiments, process <NUM> can be embodied as instructions stored in a non-transitory medium that, when executed by one or more processors of a system, cause the system to perform process <NUM>.

Step <NUM> of process <NUM> involves generation of a message comprising a plurality of routing paths. As described herein, such routing paths involve runtime decisions of a system as to where to deliver a given message or event based on a certain context. The plurality of routing decisions can involve options based on expected user preferences, overviews, or expected intent(s) associated with a user to allow a user selection of a routing path of the plurality of routing paths selected by a user. The plurality of routing paths can be based on queries to various client systems or nodes of a client system that can be associated with the expected intents for a user, or with routing paths structured to efficiently allow a user to provide intent indicator data from a user's network device to the server that matches a user's intent. Such queries to nodes or client systems can gather context or other supporting data that the server can use (e.g. with machine learning algorithms) to select intent values for a user based on the context data and expected intent indicator data to be received in subsequent steps.

In step <NUM> of process <NUM>, a response is received that includes a routing path selection. The server uses this routing path selection in step <NUM> to facilitate a two-way communication session between the network device (e.g. a user's device such as a smartphone) and a node of the client device (e.g. a system associated with the routing path selected from the plurality of routing paths). The server can facilitate both the communications and the eventual termination of the two-way communication session in step <NUM> as part of connection management system (e.g. connection management system <NUM>) operations of a server. As described herein, such operations can be integrated with client devices and client nodes (e.g. clients <NUM> and <NUM>), or can be structured independently in other embodiments.

In step <NUM> of process <NUM>, intent indicator data related to the selected routing path is received at a server system. This can be part of a message being routed via a connection management system from a network device to a client node, or can be data about a user or user account from any source associated with a current user's attempt to achieve an intent within the system. In various embodiments, intent indicator data can be gathered as part of dynamic message processing and data aggregation not only in step <NUM>, but throughout any communications or interactions using the server or associated devices that share aggregated data with the server. This can include the response from step <NUM>, data exchanged as part of the two-way communication session as part of step <NUM>, or any other previous steps that include data that can be aggregated for use in assisting a user's interactions with the server (e.g. to identify an intent value from intent indicator data and to provide responses to service the intent). In step <NUM>, this data can be processed to select an updated intent value in the system. In some embodiments, the intent value is a derived value from a variety of context information including intent indicator data directly from a user's network device, as well as from any other source described herein. As data is aggregated and analyzed for current interactions with a network device, a server performing process <NUM> can update an intent value for the network device using machine learning models. The intent value is thus a mutable indicator that changes as new information is derived (e.g. from current communications with a user's network device) over time.

In some embodiments, a system can have an initial intent value based on expectations of a likely reason for a user to interact with a system. As actual interactions occur, they can confirm the prior intent, or can cause the intent value to be modified. The machine learning model can they update the intent value in the system over time without any interactions with a user, and that stored intent value based on aggregated data can be used to inform the initial interactions with a user's network device the next time a user is involved in a communication channel associated with the system (e.g. managed by a connection management system associated with the server). The data aggregated by the system can not only be data routed by the system, but can also include data input to the system by agents of the client, such as live operators that can be tasked with interacting with a user at certain points. Information about those interactions, including data automatically processed from the system and data input by the agents, can all be fed into a machine learning model. The data is stored in a fixed fashion, and is used to update the changing intent value associated with a user or user account.

Further, in addition to a server receiving intent indicator data, that data can be processed in a variety of ways for use in determining an intent value. In some embodiments, natural language processing can be performed using tools such as Lex and Dialogflow for text or automatic speech recognition. Natural language understanding (NLU) or inference systems from such tools can then be used to structure the information in the intent indicator data. In some implementations, such data can then be processed by machine learning or artificial intelligence tools (e.g. neural networks) to select an intent value from a limited set of possible intent values associated with a system. Such intent values for a system can be associated with particular client nodes and routings. In some systems, the intent values for particular nodes can be subsets of the intent values for a system, with multiple tiers or levels of decisions made using machine learning analysis at each level to determine a current intent value and update the intent value as additional information is received from a user's network device. Additional details of intent value determination are described in <CIT> titled "DYNAMIC ENDPOINT COMMUNICATION CHANNELS" which is incorporated by reference for all purposes.

In step <NUM> of process <NUM>, a communication is generated that includes suggestions corresponding to the intent value associated with the intent indicator data and the routing path from step <NUM>. In the context of step <NUM> described above and the analysis performed by a server system, once the intent value (e.g. an updated intent value based on current network device communications) is identified for a particular step, a communication including suggestions (e.g. new routing paths) is generated for a user's network device. This communication can then facilitate display of options and information on a network device that either meets a user's intent, or can be used to further communicate with the system to attempt to achieve the user's intent associated with current system interactions.

However, it is understood that the embodiments can be practiced without these specific details. For example, circuits can be shown as block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques can be shown without unnecessary detail in order to avoid obscuring the embodiments.

Implementation of the techniques, blocks, steps and means described above can be done in various ways. For example, these techniques, blocks, steps and means can be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units can be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described above, and/or a combination thereof.

Also, it is noted that portions of the embodiments can be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart can describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations can be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in the figure. A process can correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.

Furthermore, embodiments can be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and/or any combination thereof. When implemented in software, firmware, middleware, scripting language, and/or microcode, the program code or code segments to perform the necessary tasks can be stored in a machine readable medium such as a storage medium. A code segment or machine-executable instruction can represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a script, a class, or any combination of instructions, data structures, and/or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, and/or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, ticket passing, network transmission, etc..

For a firmware and/or software implementation, the methodologies can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. Any machine-readable medium tangibly embodying instructions can be used in implementing the methodologies described herein. For example, software codes can be stored in a memory. Memory can be implemented within the processor or external to the processor. As used herein the term "memory" refers to any type of long term, short term, volatile, nonvolatile, or other storage medium and is not to be limited to any particular type of memory or number of memories, or type of media upon which memory is stored.

Moreover, as disclosed herein, the term "storage medium", "storage" or "memory" can represent one or more memories for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information. The term "machine-readable medium" includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels, and/or various other storage mediums capable of storing that contain or carry instruction(s) and/or data.

Claim 1:
A computer-implemented method comprising:
receiving a message from a client device (<NUM>) at a network device (<NUM>), wherein the message includes a plurality of routing paths, and wherein the plurality of routing paths includes a plurality of options of service requests that may be fulfilled by the client device (<NUM>) if requested by the network device (<NUM>);
generating a selected routing path of the plurality of routing paths based on a user selection at the network device (<NUM>);
establishing a two-way communication session between the network device (<NUM>) and a node of the client device (<NUM>) for fulfilling the service request corresponding to the selected routing path, wherein the node is determined based on the selected routing path;
facilitating termination of the two-way communication session, wherein the termination of the two-way communication session causes the client device (<NUM>) to transmit the selected routing path to a server, wherein the server is distinct from the client device;
receiving data related to the selected routing path at the network device (<NUM>);
transmitting a new message from the network device (<NUM>) to the server, wherein the new message includes intent indicator data, wherein the intent indicator data is indicative of a desired action of a user of the network device;
receiving a response to the new message from the server, wherein the response includes one or more suggestions specific to the network device (<NUM>), wherein the one or more suggestions are generated by the server based on the selected routing path and the intent indicator data; and
facilitating display of the response at the network device (<NUM>).