System and method for dialog management

Abstract

A method is presented for executing a dialog turn in a conversation by a dialog manager, the method including receiving task-related input from a user; passing the input to an NLU engine on a first task path; receiving a list of candidate intents associated with the task, the list of candidate intents including an associated confidence level for each of the candidate intents; applying context-aware rescoring of the confidence levels from the weighted NLU engine to one or more tasks currently active with the user; selecting an intent based on the rescored confidence levels; determining a new task path within a hierarchy of intents based on the confirmed intent; confirming the selected intent and associated slot; selecting a response flow for the new task path within the hierarchy of intents; and executing the response flow.

Description

Technical Field

[0001] (Claims of Priority and Cross - References to Related Applications) This application claims the benefit of and priority to U.S. Provisional Patent Application No. 62 / 939,183, filed on November 22, 2019, entitled "REACTIVE BOT DIALOG MANAGER". This application is related to U.S. Provisional Patent Application No. 62 / 938,951, filed on November 22, 2019, entitled "SYSTEM AND METHOD FOR MANAGING A DIALOG BETWEEN A CONTACT CENTER SYSTEM AND A USER THEREOF".

[0002] (Field of the Invention) The present invention generally relates to telecommunication systems and methods. More specifically, the present invention relates to the operation of contact centers and the management of dialogs therein.

Background Art

[0003] In a contact center environment, a dialogue typically involves a conversation between two or more parties (e.g., a customer, an agent, and / or a system) to resolve a problem, either by fulfilling a request or otherwise accomplishing several tasks / achieving several goals. Conversations can take place through various media channels, such as voice, chat, desktop, and web, to name a few non-limiting examples. An engine (i.e., a dialogue engine) can be used to understand the state of the dialogue at every turn. A turn can include events from any party to the conversation or dialogue, such as a response or a question. The dialogue engine can be further used to control the next action taken through the system, guiding the conversation toward the goals of the contact center or business. The dialogue engine may include a “conversational AI,” which further includes making contextual decisions through interactions with customers in natural language and multimodal media. Actions can be directed to parties in various ways. For example, an action may be directed to the customer through a message within the dialogue channel. In another example, an action may be directed to the agent, either directly or indirectly through recommended responses such as coaching hints or other helpful guidance on the agent's desktop. In another example, an action may be directed to the system in the form of an information request or the execution of a reservation.

[0004] Chat / voice bot dialogue management systems generally fall into one of two categories: probabilistic (i.e., utilizing machine learning) or deterministic (rule-based). While probabilistic approaches can offer advanced conversational capabilities such as contextual awareness and natural-sounding discourse markers, incorporating business logic into such systems is extremely difficult, especially when business rules change frequently. These bots may often appear "intelligent" to end-users from a conversational perspective, but in the business self-service world, they are only suitable for the simplest transactions. Their underlying conversational models require a lot of data for training and, once trained, are not easily modified. Training is typically done using human-to-human conversations, making it difficult to pinpoint where business rules apply in those conversations, and subsequently, given portions of the training conversations rely on those implicit business rules.

[0005] On the other hand, while the deterministic approach offers far more flexibility and freedom in specifying the business logic aspects of a conversation, dialogue management is traditionally limited to simple forms such as filling in frames (i.e., once the end-user's primary intent is established, the system abandons the use of natural language comprehension and instead requests the remaining information using a "one-at-a-time" approach). This approach often uses a finite state machine (FSM) to track the end-user's progress through pre-scripted dialogues. While very complex business transactions can be scripted using this approach, the limitations of FSM scalability leave interactions with these deterministic bots with little ability to direct the conversation to the end-user. Mapping transitions from each state to all other potential states is not feasible.

[0006] This specification presents a dialogue manager that combines conversational enhancements (e.g., contextual awareness) provided by a probabilistic dialogue manager that offers flexibility and predictability (e.g., for incorporating business logic) provided by a more traditional rule-based approach. [Overview of the Initiative]

[0007] In one embodiment, a computer implementation method for performing a dialogue turn in a conversation by a dialogue manager is presented, the method comprising: the dialogue manager receiving task-related input from a user; passing the user input to an NLU engine on a first task path; receiving a list of intent candidates associated with the task from the NLU engine, wherein the list of intent candidates includes the associated confidence level of each intent candidate; applying weighted, context-aware rescoring of the confidence levels from the NLU engine to the user and one or more currently active tasks; selecting an intent based on the rescored confidence levels; determining a new task path in the intent hierarchy based on the confirmed intent; confirming the selected intent and associated slots; selecting a response flow for the new task path in the intent hierarchy and executing the response flow.

[0008] Input may include typed text or transcripts from automated speech recognition.

[0009] The list of intent candidates includes one or more slot values ​​for each intent candidate.

[0010] A task path contains the location of a single instance of an intent associated with a task in a hierarchy. A task path may also contain a sequence of intent names, starting from the root of the hierarchy. Intentions associated with a task may also appear in multiple locations within the hierarchy. Determining a new task path involves at least one of the following: continuing a first task path, initiating a child task path of the first task path, reopening a closed task path, switching from the first task path to a new task, switching to a pending task path, or removing ambiguity between different task paths associated with the same task.

[0011] Verification can be performed automatically by the user or the dialog manager, or by one of the following means.

[0012] Rescoring includes the steps of configuring the NLU engine with a list of all available intentions, wherein the NLU engine does not recognize the conversational context; and the steps of increasing the confidence of an intention candidate, wherein the intention candidate matches one or more criteria associated with tasks in the hierarchy, matches tasks associated with recently completed tasks, and matches tasks associated with pending tasks.

[0013] In one embodiment, determining a new task path further includes filtering a list of intent candidates to include results that exceed a threshold, where the results have the same intent but use different task paths; automatically determining the simplest different task path to each result; presenting the simplest different task path to the user for selection; and setting the simplest different task path as the new task path.

[0014] In another embodiment, determining a new task path further includes filtering a list of intent candidates to include results that exceed a threshold, filtering results to have different intents, confirming the results with the user, determining the simplest different task path to each result, and presenting the user with the simplest different task paths for selection.

[0015] A response flow may include a modular structure that further contains a directed graph, where each node in the directed graph performs an action. An action may include selecting which node to visit next. A response flow may also include a default node, which contains a path to other nodes in the directed graph.

[0016] In one embodiment, response flow selection further includes executing a node and retrieving the results associated with the node, determining whether the node includes a path that shares a name with the results, and if it is determined that the names are not shared, determining whether the default node includes a path that shares a name with the results, and if it is determined that the names are not shared, and exiting the response flow, and if the node's results include the selected response flow.

[0017] These and other features of the present application will become more apparent upon consideration of the following detailed description of exemplary embodiments in conjunction with the drawings and the appended claims. [Brief explanation of the drawing]

[0018] A more complete understanding of the present invention, as well as many of its associated features and aspects, will become more readily apparent, as the invention is better understood by referring to the following detailed description when considered in conjunction with the accompanying drawings in which similar reference numerals indicate similar components.

[0019] [Figure 1]Shows an embodiment of a schematic block diagram of a computing device according to an exemplary embodiment of the present invention and / or by which an exemplary embodiment of the present invention can be enabled or executed.

[0020] [Figure 2] Shows an embodiment of a schematic block diagram of a communication infrastructure or contact center by which an exemplary embodiment of the present invention can be enabled or executed.

[0021] [Figure 3] Shows an embodiment of a schematic block diagram showing further details of a chat server operating as part of a chat system.

[0022] [Figure 4] Shows an embodiment of a schematic block diagram of a chat module.

[0023] [Figure 5] Shows an embodiment of a schematic block diagram of an intention hierarchy.

[0024] [Figure 6] Shows an embodiment of a process for executing a dialog turn by a dialog manager.

[0025] [Figure 7] Shows an embodiment of a process for task routing selection.

[0026] [Figure 8] Shows an embodiment of a process for verifying an intention and a slot.

[0027] [Figure 9] Shows an embodiment of a process for a response flow.

MODE FOR CARRYING OUT THE INVENTION

[0028] For the purpose of facilitating an understanding of the principles of the present invention, exemplary embodiments illustrated in the drawings are described herein using specific terminology. However, it will be apparent to those skilled in the art that detailed materials provided in the examples may not be necessary to carry out the present invention. In other examples, well-known materials or methods are not described in detail to avoid obscuring the present invention. Furthermore, further modifications to the examples provided or to the application of the principles of the present invention, as presented herein, are intended to be ordinarily conceivable to those skilled in the art.

[0029] Where used herein, non-limiting examples and illustrative phrases include "e.g.," "i.e.," "for example," and "for instance." Furthermore, throughout this specification, references such as "an embodiment," "one embodiment," "present embodiment," "exemplary embodiment," and "certain embodiment" mean that certain features, structures, or characteristics described in relation to a given embodiment may be included in at least one embodiment of the present invention. Therefore, the appearance of phrases such as "an embodiment," "one embodiment," "present embodiment," and "exemplary embodiment" does not necessarily refer to the same embodiment or example. Furthermore, certain features, structures, or characteristics may be combined in any preferred combination and / or partial combination in one or more embodiments or examples.

[0030] Embodiments of the present invention may be implemented as apparatus, methods, or computer program products. Accordingly, exemplary embodiments may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects. In each case, exemplary embodiments may generally be referred to as “modules,” “systems,” or “methods.” Furthermore, exemplary embodiments may take the form of computer program products embodied in any tangible medium, having computer-usable program code embodied in the medium.

[0031] It will be further understood that the flowcharts and block diagrams provided in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to exemplary embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that performs a particular function or operation. These computer program instructions may also be stored on computer-readable media that can cause a computer or other programmable data processing device to function in a particular way such that the instructions stored on the computer-readable media generate a manufactured article containing instruction means that implements the function / operation specified in the flowchart and / or block diagram blocks or blocks. Computing devices

[0032] Referring here to Figure 1, a schematic block diagram of an exemplary computing device 100 is shown, in which embodiments of the present invention and / or exemplary embodiments of the present invention are enabled or can be implemented. Those skilled in the art will recognize that the various systems and methods disclosed herein can be implemented using many different forms of data processing equipment, such as a digital microprocessor and associated memory running a suitable software program. Therefore, it should be understood that Figure 1 is provided as a non-limiting example.

[0033] The computing device 100 may be implemented via firmware (e.g., application-specific integrated circuits), hardware, or a combination of software, firmware, and hardware. It will be understood that each of the servers, controllers, switches, gateways, engines, and / or modules in the following figures may be implemented via one or more of the computing devices 100. For example, a diverse server may be a process or thread running on one or more processors of one or more computing devices 100, executing computer program instructions and interacting with other system modules to perform the various functions described herein. Unless particularly limited, functions described in relation to multiple computing devices may be integrated into a single computing device, or various functions described in relation to a single computing device may be distributed across several computing devices. Furthermore, with respect to the computing systems described herein, such as the contact center system 200 in Figure 2, its diverse servers and computer devices may be located on local computing devices 100 (i.e., on-site, in the same physical location as the contact center agents), remote computing devices 100 (i.e., off-site or cloud-based or computing environments, e.g., in a remote data center connected via a network), or some combination thereof. In exemplary embodiments, functions provided by servers located on off-site computing devices may be accessed and provided via a virtual private network (VPN) as if these servers were on-site, or functions may be provided using software as a service (SaaS) delivered as a service accessed over the internet using various protocols, such as exchanging data via an extensible markup language (XML), JSON, etc.

[0034] As shown in the illustrated example, the computing device 100 may include a central processing unit (CPU) or processor 105 and main memory 110. The computing device 100 may also include a storage device 115, a removable media interface 120, a network interface 125, and one or more input / output (I / O) devices 135, which may include an I / O controller 130, a display device 135A, a keyboard 135B, and a pointing device 135C, as shown. The computing device 100 may also further include additional elements such as a memory port 140, a bridge 145, I / O ports, one or more additional input / output devices 135D, 135E, 135F, and a cache memory 150 that communicates with the processor 105.

[0035] The processor 105 may be any logic circuit that responds to and processes instructions fetched from the main memory 110. For example, the processor 105 may be implemented by an integrated circuit, such as a microprocessor, microcontroller, or graphics processing unit, or a field-programmable gate array or application-specific integrated circuit. As shown in the figure, the processor 105 may communicate directly with the cache memory 150 via a secondary bus or back-side bus. The cache memory 150 typically has a faster response time than the main memory 110. The main memory 110 may be one or more memory chips that store data and allow the stored data to be directly accessed by the central processing unit 105. The storage device 115 may provide storage for the operating system and software running on the computing device 100. The operating system may control scheduling tasks and control access to system resources. Unless particularly limited, the operating system and software may include any that can perform the operations described herein as understood by those skilled in the art.

[0036] As shown in the illustrated example, the computing device 100A may include a wide variety of I / O devices 135. As shown, an I / O controller 130 may be used to control one or more I / O devices. As shown, input devices may include, for example, a keyboard 135B and a pointing device 135C, which may be a mouse or an optical pen. Output devices may include, for example, a video display device, a speaker, and a printer. The I / O devices 135 and / or the I / O controller 130 may include suitable hardware and / or software to enable the use of multiple display devices. The computing device 100 may also support one or more removable media interfaces 120, such as a disk drive, a USB port, or any other device suitable for reading data from or writing data to any type of computer-readable medium. The removable media interface 120 may be used, for example, to install software and programs.

[0037] Computing device 100 may be any workstation, desktop computer, laptop or notebook computer, server machine, virtual device, mobile phone, smartphone, portable telecommunications device, media playback device, game system, mobile computing device, or any other type of computing, telecommunications or media device capable of performing the operations described herein without limitation. Computing device 100 may have several input devices, each having a different processor and operating system. Computing device 100 may include a mobile device that combines several devices, such as a mobile phone having a digital audio player or a portable media player.

[0038] Computing device 100 may be one of several devices connected by a network or connected to other systems and resources via a network. As used herein, a network includes one or more computing devices, machines, clients, client nodes, client machines, client computers, client devices, endpoints, or endpoint nodes communicating with one or more other computing devices, machines, clients, client nodes, client machines, client computers, client devices, endpoints, or endpoint nodes. For example, a local machine may have the ability to function as both a client node seeking access to resources provided by a server and a server providing access to hosted resources for other clients. The network may be a LAN or WAN link, a broadband connection, a wireless connection, or a combination thereof, and the connection is established using an appropriate communication protocol. Computing device 100 may communicate with other computing devices 100 via any type and / or form of gateway or tunneling protocol, such as secure socket layer or transport layer security. Network interfaces may include built-in network adapters, such as network interface cards, which are suitable for interfaceping the computing device to any type of network capable of performing the operations described herein. Furthermore, the network environment may be a virtual network environment in which various network components are virtualized. For example, the various machines may be virtual machines implemented as software-based computers running on physical machines. The virtual machines may share the same operating system, or, in other embodiments, different operating systems may run on each virtual machine instance. For example, a "hypervisor" type of virtualization is used in which multiple virtual machines run on the same host physical machine, each functioning as if it had its own dedicated box.Other types of virtualization can also be conceived, such as networks (e.g., software-defined networking) or functions (e.g., via network function virtualization). Contact Center

[0039] Referring here to Figure 2, a communications infrastructure or contact center system 200 may be provided by and / or implemented by exemplary embodiments of the present invention. In this specification, the term “contact center system” is used to refer to the system and / or its components shown in Figure 2, and the term “contact center” is used more generally to refer to the contact center system, customer service provider, and / or associated organization or company that operates those systems. Therefore, unless specifically limited, the term “contact center” generally refers to the contact center system (such as contact center system 200), the associated customer service provider (a specific customer service provider that provides customer services through contact center system 200), and the organization or company to which those customer services are provided instead.

[0040] As background, customer service providers generally provide many types of services through contact centers. Such contact centers may be staffed with employees or customer service agents (or simply “agents”), who act as an interface between companies, corporations, government agencies, or organizations (hereinafter interchangeably referred to as “organizations” or “corporations”) and users, individuals, or customers (hereinafter interchangeably referred to as “individuals” or “customers”). For example, a contact center agent may assist a customer in making a purchase decision, receiving an order, or resolving an issue with a product or service already received. Within a contact center, such interactions between a contact center agent and an external entity or customer may take place via various communication channels, such as voice (e.g., telephone or IP or VoIP calls), video (e.g., video conferencing), text (e.g., email and text chat), screen sharing, and co-browsing.

[0041] Operationally, contact centers generally strive to provide customers with good service while minimizing costs. For example, one way for a contact center to function is to handle all customer interactions with live agents. While this approach may score well in terms of service quality, it would be very expensive due to the high cost of agent labor. For this reason, most contact centers utilize some level of automated processes instead of live agents, such as interactive voice response (IVR) systems, interactive media response (IMR) systems, internet robots or "bots," automated chat modules, or "chatbots." In many cases, this has proven to be a successful strategy, as automated processes can be very efficient at handling certain types of interactions and are effective in reducing the need for live agents. Such automation can target the use of human agents for more difficult customer interactions, while automated processes handle more repetitive or routine tasks. Furthermore, automated processes can also be structured in a way that optimizes efficiency and promotes reproducibility. Humans or living agents may forget to follow up on certain details or ask specific questions, but such mistakes are typically avoided by using automated processes. Customer service providers are increasingly relying on automated processes to interact with customers, but the use of such technologies by customers remains far from development. Thus, IVR systems, IMR systems, and / or bots are used to automate the contact center-side part of the conversation, leaving the customer-side actions to be performed manually by the customer.

[0042] Referring specifically to Figure 2, the contact center system 200 may be used by a customer service provider to provide various types of services to customers. For example, the contact center system 200 may be used to engage in and manage interactions in which automated processes (or bots) or human agents communicate with customers. As understood, the contact center 100 may be used as an in-house facility of a business or company to perform sales and service functions related to products and services available through the company. In another aspect, the contact center system 200 may be operated by a third-party service provider contracted to provide services to another organization. Furthermore, the contact center system 200 may be deployed on equipment dedicated to the company or the third-party service provider, and / or may be deployed in a remote computing environment such as a private or public cloud environment with infrastructure to support multiple contact centers for multiple companies, for example. The contact center 200 may include software applications or programs that can run on-premises, remotely, or a combination of both. Moreover, naturally, the various components of the contact center system 200 may also be distributed across various geographical locations and are not necessarily contained in a single location or computing environment.

[0043] Unless otherwise specified, it should be further understood that any of the computing elements of the present invention may be implemented in a cloud-based or cloud computing environment. As used herein, “cloud computing” (or simply “cloud”) is defined as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned via virtualization and scaled with minimal administrative effort or service provider interaction. Cloud computing can be comprised of various characteristics (e.g., on-demand self-service, broad network access, resource sharing, rapid scalability, and measurable services), service models (e.g., Software as a Service, "SaaS", Platform as a Service, "PaaS", Infrastructure as a Service, "IaaS"), and deployment models (e.g., private cloud, community cloud, public cloud). Often referred to as a "serverless architecture," the cloud execution model generally involves a service provider that dynamically manages the allocation and provisioning of remote servers to achieve the desired functionality.

[0044] As shown in the example in Figure 2, the components, or modules, of the contact center 200 may include multiple customer devices 205A, 205B, 205C, a communication network (or simply "Network") 210, a switch / media gateway 212, a call controller 214, an interactive media response (IMR) server 216, a routing server 218, a storage device 220, a statistics (or "stat") server 226, multiple agent devices 230A, 230B, 230C, each containing workbins 232A, 232B, 232C, a multimedia / social media server 234, a knowledge management server 236 coupled to a knowledge system 238, a chat server 240, a web server 242, an interaction (or "iXn") server 244, a universal contact server (or "universal contact server, UCS") 246, a reporting server 248, a media services server 249, and an analytics module 250. It should be understood that any of the computer implementation components, modules, or servers described in relation to Figure 2, or in any of the following figures, may be implemented via a type of computing device, such as the computing device 100 in Figure 1. As should be understood, the contact center system 200 generally manages resources (e.g., personnel, computers, telecommunications equipment, etc.) to enable the provision of services via telephone, email, chat, or other communication mechanisms. Such services may vary depending on the type of contact center and may include, for example, customer service, help desk functions, emergency response, telemarketing, order taking, etc.

[0045] A customer wishing to receive services from the contact center system 200 may initiate inbound communication (e.g., telephone calls, emails, chats, etc.) to the contact center system 200 via a customer device 205. Figure 2 shows three such customer devices, namely customer devices 205A, 205B, and 205C, but it should be understood that any number of customer devices may exist. A customer device 205 may be a communication device such as a telephone, smartphone, computer, tablet, or laptop. According to the functions described herein, a customer can generally use a customer device 205 to initiate, manage, and perform communications with the contact center system 200, such as telephone calls, emails, chats, text messages, web browsing sessions, and other multimedia transactions.

[0046] Inbound and outbound communications to and from customer devices 205 may traverse network 210, and the nature of the network typically depends on the type of customer device being used and the form of communication. For example, network 210 may include telephone, cellular, and / or data service communication networks. Network 210 may be a private or public switched telephone network (PSTN), a local area network (LAN), a private wide area network (WAN), and / or a public WAN such as the Internet. Furthermore, network 210 may include code division multiple access (CDMA) networks, global system for mobile communications (GSM) networks, or wireless carrier networks including, but not limited to, 3G, 4G, LTE, 5G, and any conventional wireless network / technology in the art.

[0047] With respect to the switch / media gateway 212, it may be coupled to the network 210 to receive and transmit telephone calls between the customer and the contact center system 200. The switch / media gateway 212 may be a telephone or communications switch configured to function as a central switch for agent-level routing within the center. The switch may be a hardware switching system or it may be implemented via software. For example, the switch 215 may be an automated call distributor, a private branch exchange (PBX), an IP-based software switch, and / or any other switch having dedicated hardware and software configured to receive internet-sourced and / or telephone network-sourced conversations from customers and route these conversations to, for example, one of the agent devices 230. Thus, in general, the switch / media gateway 212 establishes a voice connection between the customer and the agent by establishing a connection between the customer device 205 and the agent device 230.

[0048] As further shown, the switch / media gateway 212 may be coupled to a call controller 214 that functions as an adapter or interface between the switch and other routing, monitoring, and communication handling components of the contact center system 200. The call controller 214 may be configured to handle PSTN calls, VoIP calls, etc. For example, the call controller 214 may include computer-telephony integration (CTI) software for interfaced with the switch / media gateway and other components. The call controller 214 may include a session initiation protocol (SIP) server for handling SIP calls. The call controller 214 may also extract data about incoming interactions, such as customer telephone numbers, IP addresses, or email addresses, and then communicate these with other contact center components when processing the interactions.

[0049] With respect to the Interactive Media Response (IMR) server 216, it may be configured to enable self-help or virtual assistant functionality. Specifically, the IMR server 216 may be similar to an Interactive Voice Response (IVR) server, except that the IMR server 216 is not limited to voice and may cover a variety of media channels. In an embodiment illustrating voice, the IMR server 216 may consist of IMR scripts for querying customer needs. For example, a bank contact center may, via an IMR script, instruct a customer to "press 1" if they want to retrieve their account balance. Through continuous interaction with the IMR server 216, a customer may receive services without needing to speak with an agent. The IMR server 216 may also be configured to determine why a customer is contacting the contact center so that communications can be routed to the appropriate resources. IMR configuration may be performed through the use of self-service and / or assisted service tools, including web-based tools for developing IVR and routing applications to run in a contact center environment (e.g., Genesys® Designer).

[0050] With respect to the routing server 218, it can function to route incoming conversations. For example, if it is determined that an inbound conversation should be handled by a human agent, the functions within the routing server 218 can select the most appropriate agent and route the conversation. This agent selection may be based on the best agent to handle the conversation. More specifically, the selection of the appropriate agent may be based on a routing strategy or algorithm implemented by the routing server 218. In doing so, the routing server 218 may query data related to the incoming conversation, such as a specific customer, available agents, and data related to the type of conversation, which may be stored in a specific database, as described in more detail below. Once an agent is selected, the routing server 218 can interact with the call controller 214 to route (i.e., connect) the incoming conversation to the corresponding agent device 230. As part of this connection, customer information may be provided to the selected agent via its agent device 230. This information is intended to enhance the services that the agent can provide to the customer.

[0051] With respect to data storage, the contact center system 200 may include one or more mass storage devices (generally referred to as storage device 220) that store data in one or more databases related to the functions of the contact center. For example, storage device 220 may store customer data maintained in customer database 222. Such customer data may include customer profiles, contact information, service level agreements (SLAs), and interaction history (e.g., details of previous interactions with a particular customer, such as the nature of the previous interaction, processing data, wait times, handling times, and actions taken by the contact center to resolve the customer's issue). As another example, storage device 220 may store agent data in agent database 223. Agent data maintained by the contact center system 200 may include agent availability and agent profiles, schedules, skills, handling times, etc. As yet another example, storage device 220 may store interaction data in interaction database 224. Interaction data may include data on numerous past interactions between the customer center and the contact center. More generally, unless otherwise specified, the storage device 220 may be configured to store data relating to any type of information described herein, including databases, and / or such data may be accessible to other modules or servers of the contact center system 200 in a manner that facilitates the functions described herein. For example, a server or module of the contact center system 200 may query such databases to retrieve data stored therein or transmit data for storage. The storage device 220 may take the form of any conventional storage medium, for example, and may be locally housed or operated remotely.For example, a database can be a Cassandra database, a NoSQL database, or an SQL database, and may be managed by a database management system such as Oracle, IBM DB2, Microsoft SQL Server, Microsoft Access, or PostgreSQL.

[0052] With respect to the statistics server 226, it may be configured to record and aggregate data related to the performance and operating characteristics of the contact center system 200. Such information may be compiled by the statistics server 226 and made available to other servers and modules, such as the reporting server 248, and then used to generate reports used to manage the operating characteristics of the contact center and to perform automated actions in accordance with the functions described herein. Such data may relate to the status of contact center resources, such as average latency, rejection rate, agent utilization rate, and the requirements for the functions described herein.

[0053] The agent device 230 of the contact center 200 may be a communication device configured to interact with various components and modules of the contact center system 200 in a manner that facilitates the functions described herein. For example, the agent device 230 may include a telephone adapted for regular telephone calls or VoIP calls. The agent device 230 may further include a computing device configured to communicate with the server of the contact center system 200, perform data processing associated with its operation, and interface with customers via voice, chat, email, and other multimedia communication mechanisms according to the functions described herein. Figure 2 shows three such agent devices, namely agent devices 230A, 230B, and 230C, but it should be understood that any number of agent devices may exist.

[0054] With respect to the multimedia / social media server 234, it may be configured to facilitate (non-voice) media interaction with customer devices 205 and / or server 242. Such media interaction may involve, for example, email, voicemail, chat, video, text messaging, the web, social media, co-browsing, etc. The multimedia / social media server 234 may take the form of any conventional IP router in the art, using specialized hardware and software for receiving, processing, and forwarding multimedia events and communications.

[0055] With respect to the knowledge management server 234, it may be configured to facilitate interaction between the customer and the knowledge system 238. Generally, the knowledge system 238 may be a computer system capable of receiving questions, i.e., queries, and providing answers thereto. The knowledge system 238 may be included as part of the contact center system 200 or may be operated remotely by a third party. The knowledge system 238 may include an artificial intelligence computer system capable of answering questions presented in natural language by retrieving information from sources such as encyclopedias, dictionaries, newswire articles, literary works, or other documents submitted to the knowledge system 238 as reference material, as is known in the art. As an example, the knowledge system 238 may be embodied as IBM Watson or a similar system.

[0056] With respect to the chat server 240, it may be configured to conduct, coordinate, and manage electronic chat communications with customers. Generally, the chat server 240 is configured to implement, maintain chat conversations, and generate chat transcripts. Such chat communications may be conducted by the chat server 240 so that customers communicate with an automated chatbot, a human agent, or both. In an exemplary embodiment, the chat server 240 may operate as a chat coordination server that prioritizes chat conversations between chatbots and responsive human agents. In such a case, the processing logic of the chat server 240 may be rule-driven to leverage an intelligent workload distribution among available chat resources. The chat server 240 may further implement, manage, and support user interfaces (UIs) related to chat functionality, such as user interfaces (also referred to as UIs) generated on either the customer device 205 or the agent device 230. The chat server 240 may be configured to transfer chats within a single chat session with a particular customer between automated and human sources, for example, to transfer chat sessions from a chatbot to a human agent, or from a human agent to a chatbot. The chat server 240 may also be coupled with the knowledge management server 234 and the knowledge system 238 to receive suggestions and answers to queries presented by the customer during the chat, so as to be able to provide links to relevant articles.

[0057] With respect to the web server 242, such a server may include providing site hosting for various social interaction sites that customers subscribe to, such as Facebook, Twitter, and Instagram. Although shown as part of the contact center system 200, it should be understood that the web server 242 may be provided by a third party and / or maintained remotely. The web server 242 may also provide corporate web pages supported by the contact center system 200. For example, a customer may browse a web page and receive information about a particular company's products and services. Within such a corporate web page, a mechanism may be provided for initiating interaction with the contact center system 200, for example, via web chat, voice, or email. An example of such a mechanism is a widget that can be deployed on a web page or website hosted on the web server 242. As used herein, a widget refers to a user interface component that performs a specific function. In some embodiments, a widget may include a graphical user interface control that can be overlaid on a web page displayed to a customer over the Internet. A widget may include a window or text box, etc., that can display information, or a button or other control that allows a customer to access a specific function, such as sharing or opening a file, or initiating communication. In some embodiments, a widget includes a user interface component having a portable portion of code that can be installed within a separate web page and executed without compilation. Some widgets may include a corresponding or additional user interface and may be configured to access various local resources (e.g., calendar or contact information on a customer's device) or remote resources via a network (e.g., instant messaging, email, or social networking updates).

[0058] With respect to the Interaction (iXn) server 244, it may be configured to manage the routing of deferred activities of the contact center to human agents for completion. As used herein, deferred activities include back-office work that can be performed offline, such as responding to emails, participating in training, and other activities that do not involve real-time communication with customers. As an example, the Interaction (iXn) server 244 may be configured to interact with the routing server 218 to select an agent suitable for handling each of the deferred activities. Once assigned to a particular agent, the deferred activity is pushed to that agent and consequently appears on the agent device 230 of the selected agent. The deferred activity may appear in the workbin 232 as a task for the selected agent to complete. The functionality of the workbin 232 may be implemented, for example, through conventional data structures such as linked lists or arrays. Each of the agent devices 230 may include a workbin 232, with workbins 232A, 232B, and 232C maintained on agent devices 230A, 232B, and 232C, respectively. For example, the workbin 232 may be maintained in the buffer memory of the corresponding agent device 230.

[0059] With respect to the Universal Contact Server (UCS) 246, it may be configured to retrieve information stored in the customer database 222 and / or transmit information to be stored therein. For example, UCS 246 may be used as part of the chat function to facilitate the maintenance of a history of how chats with a particular customer were handled, which may be used as a reference for how future chats should be handled. More generally, UCS 246 may be configured to facilitate the maintenance of a history of customer preferences, such as preferred media channels, and the best time to contact. To do this, UCS 246 may be configured to identify data related to each customer's interaction history, such as data related to comments from agents, customer communication history, etc. Each of these data types may then be stored in the customer database 222 or other modules as required by the functions described herein.

[0060] Regarding the reporting server 248, it may be configured to generate reports from data compiled and aggregated by the statistics server 226 or other sources. Such reports may include near real-time or historical reports on the status and performance characteristics of contact center resources, such as average latency, rejection rate, and agent utilization. Reports may be generated automatically or in response to specific requests from requesters (e.g., agents / administrators, contact center applications, etc.). The reports may then be used to manage contact center operations in accordance with the functions described herein.

[0061] With respect to the media service server 249, it may be configured to provide audio and / or video services to support contact center features. According to the features described herein, such features may include audio and / or video services to support contact center functions such as prompting of IVR or IMR systems (e.g., playback of audio files), hold music, voicemail / single-party recording, multi-party recording (e.g., audio and / or video calls), speech recognition, dual-tone multi-frequency (DTMF) recognition, fax, audio and video transcoding, secure real-time transport protocol (SRTP), voice conferencing, video conferencing, coaching (e.g., support for coaches to listen to conversations between customers and agents, and support for coaches to provide comments to agents without customers hearing the comments), call analysis, and keyword spotting.

[0062] With respect to the analysis module 250, it may be configured to provide a system and method for performing analysis on data received from multiple different data sources as a function described herein. According to exemplary embodiments, the analysis module 250 may also generate, update, train, and modify predictors or models 252 based on collected data such as, for example, customer data, agent data, and interaction data. Model 252 may include customer or agent behavior models. Behavior models may be used to predict customer or agent behavior in various situations, for example, thereby enabling embodiments of the invention to tailor interactions based on such predictions or allocate resources for preparation for predicted characteristics of future interactions, thereby improving overall contact center performance and customer experience. Although the analysis module 250 is presented as part of a contact center, it will be understood that such behavior models may also be implemented in customer systems (or, as used herein, also on the "customer side" of interactions) and used for the benefit of the customer.

[0063] According to an exemplary embodiment, the analysis module 250 may have access to data stored in the storage device 220, including a customer database 222 and an agent database 223. The analysis module 250 may also have access to a dialogue database 224, which stores data related to dialogues and dialogue content (e.g., transcripts of dialogues and events detected therein), dialogue metadata (e.g., customer identifier, agent identifier, dialogue medium, dialogue length, dialogue start and end times, department, tagged category), and application settings (e.g., dialogue path through the contact center). Furthermore, as will be discussed in more detail below, the analysis module 250 may be configured to retrieve data stored in the storage device 220 for use in development and training algorithms and models 252, for example, by applying machine learning techniques.

[0064] One or more of the included Model 252 may be configured to predict customer or agent behavior and / or manner related to contact center operations and performance. Furthermore, one or more of the Model 252 may be used in natural language processing, including, for example, intent recognition. A Model 252 may be developed based on 1) a known first principle equation describing the system, 2) data resulting from an empirical model, or 3) a combination of a known first principle equation and data. When developing a model for use in this embodiment, it is often preferable to build an empirical model based on collected and stored data, as the first principle equation is often unavailable or not readily derived. It may be preferable for Model 252 to be nonlinear in order to adequately capture the relationship between operational / disturbance variables and controlled variables in a complex system. This is because a nonlinear model can represent a curved rather than linear relationship between operational / disturbance variables and controlled variables, which is common in complex systems such as those discussed herein. Given the requirements described above, machine learning or neural network-based approaches are currently preferred embodiments for implementing Model 252. For example, neural networks can be developed based on empirical data using sophisticated regression algorithms.

[0065] The analysis module 250 may further include an optimizer 254. As can be understood, the optimizer can be used to minimize a “cost function” that is subject to a set of constraints, the cost function being a mathematical representation of a desired objective or system behavior. Since Model 252 can be nonlinear, the optimizer 254 may be a nonlinear programming optimizer. However, the present invention is intended to be implemented by using various different types of optimization approaches, including but not limited to linear programming, quadratic programming, mixed-integer nonlinear programming, probabilistic programming, global nonlinear programming, genetic algorithms, particle / swarm techniques, etc., individually or in combination.

[0066] According to exemplary embodiments, Model 252 and Optimizer 254 may be used together within an optimization system 255. For example, the analysis module 250 may utilize the optimization system 255 as part of an optimization process, thereby optimizing, or at least enhancing, aspects of contact center performance and operation. This may include aspects related to customer experience, agent experience, dialogue routing, natural language processing, intent recognition, or other functions related to automated processes, for example.

[0067] Each of the various components, modules, and / or servers in Figure 2 (and other figures included herein) may include one or more processors that execute computer program instructions and interact with other system components to perform the various functions described herein. Such computer program instructions may be stored in memory implemented using standard memory devices such as random access memory (RAM), or in other non-temporary computer-readable media such as CD-ROMs or flash drives. Although each function of a server is described as being provided by a particular server, those skilled in the art should understand that the functions of various servers may be combined or integrated into a single server, or that the functions of a particular server may be distributed among one or more other servers without departing from the scope of the present invention. Furthermore, the terms “interaction” and “communication” are used interchangeably and generally refer to any real-time and non-real-time interactions using any communication channel, including telephone calls (PSTN or VoIP calls), email, Vmail, video, chat, screen sharing, text messages, social media messages, WebRTC calls, etc. Access to and control of the components of the contact system 200 may be affected via a user interface (UI) that may be generated on the customer device 205 and / or agent device 230. As described above, the contact center system 200 may be operated as a hybrid system in which some or all of its components are hosted remotely, such as in a cloud-based or child cloud computing environment. Chat system

[0068] Referring to Figures 3 and 4, various embodiments of chat systems and chatbots are shown. As can be seen, these embodiments may include or be enabled by such chat features, which generally enable the exchange of text messages between different parties. The parties may include living individuals such as customers and agents, as well as automated processes such as bots or chatbots.

[0069] As background, a bot (also known as an "Internet bot") is a software application that performs automated tasks or scripts over the internet. Typically, bots perform simple, structured, and repetitive tasks at a much higher speed than a human could. A "bot creator" refers to the person who builds and / or manages a bot. A chatbot is a specific type of bot, defined as software and / or hardware that engages in conversation via auditory or textual means, as used herein. To be understood, chatbots are designed to convincingly simulate how a human would behave as a conversational partner. Chatbots are typically used in dialogue systems for a variety of practical purposes, such as customer service or information retrieval. Some chatbots use sophisticated natural language processing systems, while simpler ones scan keywords in the input and select a response from a database based on matching keywords or expression patterns.

[0070] Before continuing the description of the present invention, notes should be made regarding the system components already described in the previous drawings, such as modules, servers, and other components. Where referred to hereafter, whether or not the corresponding numerical identifiers used in the previous drawings are included, such references should be understood to encompass the embodiments described in the previous drawings and may be carried out according to those embodiments or other prior art that can satisfy the desired function, as understood by those skilled in the art, unless otherwise particularly limited. Thus, for example, hereafter referred to as “Contact Center System” should be understood to refer to the exemplary “Contact Center System 200” in Figure 2 and / or other prior art for carrying out a contact center system. As an additional example, hereafter referred to as “Customer Device,” “Agent Device,” “Chat Server,” or “Computing Device” should be understood to refer to the exemplary “Customer Device 205,” “Agent Device 230,” “Chat Server 240,” or “Computing Device 200” in Figures 1 and 2, respectively, and prior art for satisfying the same function.

[0071] Here, chat features and chatbots are discussed with greater specificity, referring to exemplary embodiments of the chat server and chatbot shown in Figures 3 and 4, respectively. While these embodiments are provided with respect to chat systems implemented on the contact center side, such chat systems can be used on the customer side of the interaction. Therefore, it should be understood that the exemplary chat systems in Figures 3 and 4 can be modified for similar customer-side implementations, including the use of a customer-side chatbot configured to interact with contact center agents and chatbots on behalf of the customer. It should also be understood that chat features can be utilized through voice communication via text-to-speech and / or speech-to-text conversion.

[0072] Referring here to Figure 3, a more detailed block diagram of a chat server 240 that may be used to implement the chat system and its features is provided. The chat server 240 may be coupled to (i.e., electronically communicate with) a customer device 205 that the customer operates via a data communication network 210. The chat server 240 may be operated by a company as part of a contact center to implement and coordinate chat conversations with customers, for example, including both automated chat and chat with human agents. With regard to automated chat, the chat server 240 may host chat automation modules, i.e., chatbots 260A-260C (collectively referred to as 260), which are configured using computer program instructions to engage in chat conversations. Thus, the chat server 240 generally implements chat functionality, including text-based communication or chat communication exchanges between the customer device 205 and the agent device 230 or chatbot 260. As will be discussed in more detail below, the chat server 240 may include a customer interface module 265 and an agent interface module 266 for generating specific UIs on the customer device 205 and agent device 230, respectively, to facilitate chat functionality.

[0073] With respect to the chatbots 260, each can operate as an executable program that is launched on demand. For example, the chat server 240 can operate as the execution engine for the chatbots 260, similar to loading a VoiceXML file into a media server for an interactive voice response (IVR) function. Loading and unloading can be controlled by the chat server 240, similar to how a VoiceXML script can be controlled in the context of an IVR. The chat server 240 can further provide means for acquiring and collecting customer data in a unified manner, similar to customer data capture in the context of IVR. Such data can be stored, shared, and used in subsequent conversations, whether from the same chatbot, different chatbots, agent chats, or even different media types. According to an exemplary embodiment, the chat server 240 is configured to coordinate the sharing of data among various chatbots 260 when a conversation is transferred or migrated from one chatbot to another, or from one chatbot to a human agent. Data acquired during an interaction with a specific chatbot may be transmitted along with a call request to a second chatbot or human agent.

[0074] In exemplary embodiments, the number of chatbots 260 may vary depending on the design and functionality of the chat server 240 and is not limited to the number illustrated in Figure 3. Furthermore, different chatbots may be created to have different profiles and then selected to match a particular chat or a particular customer subject. For example, a particular chatbot profile may include expertise to assist customers with a specific target audience or communication style aimed at specific customer preferences. More specifically, one chatbot may be designed to handle a first communication topic (e.g., opening a new account at a business), and another chatbot may be designed to handle a second communication topic different from the first (e.g., technical support regarding products or services offered by a business). Alternatively, chatbots may be configured to use various dialects or slang, or have various personalities or characteristics. Involvement of chatbots with profiles that cater to specific types of customers can enable more effective communication and results. Chatbot profiles may be selected based on information known about the other party, such as demographic information, conversation history, or data available on social media. The chat server 240 may host a default chatbot to be invoked if there is insufficient information about the customer to invoke a more specialized chatbot. Optionally, different chatbots may be customer-selectable. According to an exemplary embodiment, the chatbot 260's profile may be stored in a profile database hosted within the storage device 220. Such a profile may include the chatbot's personality, demographics, area of ​​expertise, and so on.

[0075] The customer interface module 265 and the agent interface module 266 may be configured to generate a user interface (UI) on the customer device 205 to facilitate chat communication between the customer and the chatbot 260 or a human agent. Similarly, the agent interface module 266 may generate a specific UI on the agent device 230 to facilitate chat communication between the agent operating the agent device 230 and the customer. The agent interface module 266 can also generate a UI on the agent device 230 that allows the agent to monitor the status of an ongoing chat between the chatbot 260 and the customer. For example, the customer interface module 265 may, during a chat session, send a signal to the customer device 205 configured to generate a specific UI on the customer device 205, which may include the display of text messages sent from the chatbot 260 or a human agent, as well as other non-text graphics intended to accompany text messages, such as emoticons or animations. Similarly, the agent interface module 266 may, during a chat session, send a signal to the agent device 230 configured to generate a UI on the agent device 230. Such a UI may include an interface that facilitates agent selection of non-text graphics for accompanying outgoing text messages to customers.

[0076] In an exemplary embodiment, the chat server 240 may be implemented in a layered architecture using a media layer, a media control layer, and a chatbot executed by the IMR server 216 (similar to the execution of VoiceXML on an IVR media server). As described above, the chat server 240 may be configured to interact with the knowledge management server 234 and query the server for knowledge information. For example, the query may be based on a question received from the customer during the chat. The response received from the knowledge management server 234 may then be provided to the customer as part of the chat response.

[0077] Referring specifically to Figure 4, a block diagram of an exemplary chat automation module, i.e., a chatbot 260, is provided. As illustrated, the chatbot 260 may include several modules, including a text analysis module 270, a dialogue manager 272, and an output generator 274. The text analysis module 270 may be configured to analyze and understand natural language. In this regard, the text analysis module may be configured with a language dictionary, a syntactic parser, a semantic parser, and grammatical rules for dividing phrases provided by the customer device 205 into syntactic and semantic internal representations. The configuration of the text analysis module depends on the specific profile associated with the chatbot. For example, certain words may be included in the dictionary of one chatbot but not in another.

[0078] The Dialogue Manager 272 receives syntactic and semantic expressions from the Text Analysis Module 270 and manages the general flow of the conversation based on a set of decision rules. In this regard, the Dialogue Manager 272 maintains the history and state of the conversation and generates outbound communications based on them. Communications may follow a script of a specific conversation path selected by the Dialogue Manager 272. As will be described in more detail below, conversation paths may be selected based on an understanding of the specific purpose or topic of the conversation. The script of a conversation path may be generated using any of the various languages ​​and frameworks conventional in the art, such as Artificial Intelligence Markup Language (AIML) or SCXML.

[0079] During a chat conversation, the dialog manager 272 selects a response deemed appropriate at a specific point in the conversation flow / script and outputs the response to the output generator 274. According to an exemplary embodiment, the dialog manager 272 may also be configured to calculate the confidence level of the selected response and provide the confidence level to the agent device 230. Every segment, step, or input in the chat communication may have a corresponding list of possible responses. Responses may be categorized based on a topic (determined using a suitable text analysis and topic detection scheme) and assigned a proposed next action. Actions may include, for example, a response with an answer, an additional question, or transfer to a human agent to provide assistance. The confidence level may be used to help the system determine whether the detection, analysis, and response to customer input are appropriate or whether a human agent should be involved. For example, a threshold confidence level may be assigned to prompt human agent intervention based on one or more business rules. According to an exemplary embodiment, the confidence level may be determined based on customer feedback. As described, the response selected by the dialog manager 272 may include information provided by the knowledge management server 234.

[0080] In an exemplary embodiment, the output generator 274 obtains a semantic representation of the response provided by the dialogue manager 272, maps the response to a chatbot profile or personality (for example, by adjusting the language of the response according to the chatbot's dialect, vocabulary, or personality), and outputs output text to be displayed on the customer device 205. The output text may be presented intentionally so that the customer interacting with the chatbot does not realize that they are interacting with an automated process rather than a human agent.

[0081] Figure 5 illustrates an embodiment of the intent hierarchy. Referring to Dialog Manager 272, a bot author may define a hierarchical list of all possible user intents, including intents for tasks (e.g., "I want to order a meal") and intents for other diagnostics, such as notifications of new slot values ​​(e.g., "for my flight to Denver next Thursday"). For example, in the hierarchical list shown in Figure 5, "Task: Order a special meal" 505a may be associated with the phrase "I want to order a vegetarian meal." Response 510 is associated with task 505 via mapping by the bot author. The bot author may map some or all of the intents in the hierarchy to "response flows." These responses use a flowchart-like design to explain the logic of what to do next, taking into account the current state of the conversation. If the same intent is active in a subsequent dialogue turn, the same flowchart is re-executed from its beginning. Thus, the bot can be programmed to appropriately respond to any new intent and / or slot values ​​at any point in the conversation, which is a task that is not feasible using a traditional FSM-based approach.

[0082] During execution, the dialog manager 272 monitors the end user's current position in a hierarchical list of intentions and uses that position, along with knowledge of recently completed and pending intentions, to refine the confidence score of each new intention and thus make a decision on whether to perform confirmation or whether to consider it the most likely intention.

[0083] Figure 6 shows an embodiment of the process for executing a dialog by the dialog manager, generally referred to as 600. Process 600 occurs in the dialog manager 272.

[0084] In operation 605, input is received. For example, input in the course of a conversation between a user and a bot may be received, for example, by typed text or as a result of a transcription of spoken language by an automatic speech recognition system. The input is passed to the natural language understanding (NLU) engine 610. The NLU engine may determine a listing of intent candidates, each of which may contain one or more slot values. This list is passed to the dialogue manager. In one embodiment, each intent may have an associated confidence level.

[0085] In operation 615, context-aware rescoring of NLU confidence is applied to intent candidates. During the rescoring process, weights may be added to the confidence levels. For example, intents assumed to be related to tasks the user has recently been working on will have their associated confidence levels increased accordingly. The process of rescoring NLU signals based on the current context may be carried out as follows: The NLU engine (which may be a third-party engine) consists of a flat list of all available intents. The engine does not understand the context of the current conversation. Within the dialog manager's memory, the following information may be stored for each session: a list of task paths to "recently completed" tasks, including paths to currently active tasks in the intent hierarchy, details of when they were completed, and a list of paths to tasks that are currently "pending," including details of when they were purely pending (for example, the user initially activated a task but switched to a different task, so the first task is pending).

[0086] When a new intent is detected, its confidence score may increase in several situations, including when the intent is a child of the current task intent (by intent hierarchy) or when the intent matches a task (or a child of a task) in the “Recently Completed” or “Pending” task list. In one embodiment, the more recent the task added to the list, the greater the increase in confidence of the new intent. If the intent in question appears in multiple locations in the intent hierarchy, separate scores may be determined for each different path of the intent, which would be considered separate intent hypotheses in subsequent processing.

[0087] In operation 620, an intent is selected. Then, based on the selected intent 625, it is determined which of the intent hierarchies should be the currently active task path. In one embodiment, the same task intent may appear in multiple different locations within the intent hierarchy. A “task path” can describe the location of a single instance of that task intent within the hierarchy. A task path takes the form of a sequence of intent names, starting from the root of the hierarchy. Determining the currently active task path may include: checking whether it was previously the current task path based on conversation with the dialog manager; launching a child task of what was previously the current task path; reopening a “recently closed” task path; switching away from what was previously the current task path; switching back to a previously “pending” task path; or removing ambiguity for the same intent across different paths. The process of determining the task path is illustrated in detail in Figure 7 below.

[0088] From the list of hypothetical intentions, the intention with the highest scoring is identified.630 In one embodiment, this may be done directly with the user or based on heuristic or machine learning techniques. This process is described in more detail in Figure 8 below.

[0089] In operation 635, a response flow is selected for the active task path in the intent hierarchy and executed from the start. In one embodiment, the response flow outputs channel-specific prompts, executes business logic, and pauses when it needs to wait for new input from the user. If the currently active task does not have a response flow but has child tasks in the hierarchy, the system can then automatically prompt the user to select which child task they want to activate. If the user triggers a task for which no flow is associated and that task has multiple child tasks, the system can then present the user with a list of those child tasks so that the user can easily drill down into the subtasks. The information that generates this menu system can be collected directly from the intent hierarchy without the bot creator having to configure any additional logic. One example is:

[0090] User: "I have a question regarding my lost package."

[0091] System: "Which of these lost package tasks would you prefer: 1) Report a lost package, or 2) Check the status of your lost package."

[0092] User: "2"

[0093] System: "Understood. Do you have the lost baggage ticket number?"

[0094] Returning to the process of determining the task path, Figure 7 shows an embodiment of the process for task path selection, generally indicated by 700. Process 700 may be performed by the dialog manager 272. The bot can use only information specific to the intent hierarchy to address different styles of user input (e.g., subsequent questions, removing ambiguity of similar intent in multiple places). An example of a subsequent question is illustrated below.

[0095] User: "What time will Flight GA100 land?"

[0096] System: (Starts "flight_status" task) "Flight GA100 will land at 8:24pm" (Moves from "flight_status" to "Recently Completed" tasks)

[0097] User: "What about Flight GA101?"

[0098] System (Move back from "flight_status" to "Current") "Flight GA101 will land at 10:40pm" (Move from "flight_status" to the "Recently Completed" task list) "Is there anything else I can help with?"

[0099] Subsequently, if the user triggers an intent that is a child of one of the completed task paths (and not a child of the current task path, if any), then, assuming the confidence score is sufficiently high, the system can move the task path from "Recently Completed" to "Current."

[0100] An example of deambiguation typically occurs with a common intent (e.g., "inform_flight_details"), which can be used across multiple different tasks (i.e., multiple matching task paths exist). If one of these task paths exactly or partially matches the "current" task path, or is in a list of "recently completed" or "pending" task paths, the system then applies a corresponding weight to that task path. If there is still no clear choice, the system looks at the partial task paths with the lowest non-common denominator and can present them to the user as a list of candidate choices to deambiguate.

[0101] When a list of rescored intent hypotheses is generated in process 600, the bot executes process 700. The list is filtered to include only the highest-scoring hypotheses or those that meet a specified threshold 705. It is determined whether only one hypothesis remains in the filtered list 710. If it is determined that only one hypothesis remains, the NLU intent of the hypothesis is confirmed 715. In one embodiment, the confirmation is performed by the user. The task path of the hypothesis is set to be the “current” task path 720, and a “context switch” message is output to the user as needed. In one embodiment, if the user triggers a different task intent while in the middle of processing a task intent, the bot should make it clear to the end user that it is switching tasks (e.g., “Okay, you want to check the flight status. You can come back and order a special meal later”). If the new task triggered by the user is a child of the current task path according to the intent hierarchy, then the bot should not output any context switch messages.

[0102] If it is determined that two or more hypotheses remain, it is determined whether all the remaining hypotheses use the same intention but have different paths to that intention 725.

[0103] If it is determined that not all hypotheses use the same intent, the simplest different paths to each hypothesis are calculated 730. The list of paths may be presented to the end user to remove ambiguity. The end user is presented with paths and selects a path 735. The selected path is then used to further filter the list of hypotheses 740. The end user then determines whether only a single remaining hypothesis exists 745. If it is determined that only a single hypothesis remains, the NLU intent of the hypothesis is confirmed 750. In one embodiment, this may be done by the user. The task path of the hypothesis is set to the "current" task path 755. Where appropriate, a context switch message is output to the user, as described above. If it is determined that no single hypothesis remains, a first NLU intent is selected and confirmed to the user 760. If the user rejects this intent, the next NLU intent is confirmed, and so on. The task path of the selected hypothesis is set to the "current" task path 765. Where appropriate, a context switch message is output to the user, as described above.

[0104] If operation 725 determines that all hypotheses use the same intent but have different paths to that intent, the hypothesis NLU intent is confirmed 770. In one embodiment, this may be confirmed to the user. The simplest different paths to each hypothesis are then determined and presented to the end user for disambiguation 775. The end user selects one of these paths 780. The selected path is then used to identify the complete task path and set as the current task path 785. Where appropriate, a context switch message is output to the user, as described above.

[0105] Figure 8 shows an embodiment of the process for verifying intent and slots, generally indicated as 800. Process 800 includes an algorithm for verifying intent and managing multiple slot values ​​at once, allowing the user to reject the entire intent and slots, accept the intent with some modified slots, select a different intent, or accept the intent and slots. This allows the user to correct the system's interpretation of input using natural language. The user can further confirm that the system has received all the information provided via the input signals. Verifying intent and all slots also indicates that the bot does not need to make business decisions based on potentially uncertain intent or slot values.

[0106] For each intent, the bot creator defines one or more trigger phrases and one or more confirmation prompts. A trigger phrase may contain placeholders for one or more slots, and at least one confirmation prompt variation should be configured for each combination of slots in the trigger phrase. When a user triggers a trigger phrase containing one or more slots, the dialog manager selects a confirmation prompt variation that matches the slots provided by the user, and thus simultaneously confirms both the intent and slot values ​​provided by the user.

[0107] In operation 805, the user responds to a confirmation prompt. The NLU engine maps the user response to an intent and a slot 810. It is determined 815 whether the user response begins with an affirmation (e.g., "yes" or "yes, but").

[0108] If it is determined that the user response begins with an affirmative (e.g., "yes" or "yes, but"), it is further determined whether the new intent is a "task intent" 820. If it is determined that the new intent is a "task intent", the new intent is added to the pending tasks list and the original intent and original slot are accepted 825. If it is determined that the new intent is not a "task intent", it is further determined whether the new intent is a "non-task" intent 830. If the new intent is not a non-task intent (e.g., "notification"), the original intent and slot are accepted 835. If the new intent is a non-task intent, the original intent is then accepted 840 and may be further confirmed by the user. The new slot and any of the original slots not provided for the new user input are also accepted.

[0109] If it is determined that the user response does not begin with an affirmative (e.g., "yes" or "yes, but"), then it is further determined whether the user response begins with a negative (e.g., "no").845 If it is determined that the user response does not begin with a negative, then the original intent and slot are rejected850 and the new intent and slot are accepted (these may be further confirmed by the user). If it is determined that the user response begins with a negative, then it is further determined whether the new intent is a "task intent".855 If it is determined that the new intent is a "task intent", then the original intent and slot are rejected850 and the new intent and slot are accepted (these may be further confirmed by the user). If it is determined that the new intent is not a "task intent", then it is further determined whether the new intent is a non-task intent (e.g., "notification").860 If the new intent is a non-task intent, then the original intent is accepted840 and may be further confirmed by the user. The new slot and any of the original slots not provided for the new user input are also accepted. If the new intent is not a non-task intent, the original intent / slot will be rejected along with the new intent / slot (865).

[0110] Figure 9 shows one embodiment of the process for a response flow, generally represented by 900. The response flow includes a modular structure consisting of a directed graph, where each node in the graph performs several actions and selects which designated output path (or edge) to follow, and therefore which node to visit next. Each response flow includes a special "default" node, which may also have paths leading to other nodes on the graph. The "result" of a node, which can be any string, determines which path to follow in the graph. The result may have several parts separated by dots. Any path that matches the initial substring of the result may be a match. For example, a path called "error.badfetch" matches results such as "error.badfetch" and "error.badfetch.timeout", but not simply "error".

[0111] In operation 905, the current node is executed and its “result” is obtained. In operation 910, it is determined whether the current node has a path with the same name as the result obtained in operation 905. If it is determined that the current node has a path with the same name as the result, then the path is followed in 915. If it is determined that the current node does not have a path with the same name as the result, it is further determined in 920 whether the “default” node has a path with the same name as the result. If it is determined that the “default” node has a path with the same name as the result, then the path is followed in 925. If it is determined that the “default” node does not have a path with the same name as the result, the response flow is exited in 930. The result of the response flow is the result of the node. In one embodiment, the result of the link node calling the response flow will be the same as the result of the current node.

[0112] An example of a response flow configuration is shown in the following YAML format. interfaces: - node_name:Start node_type: Start output_paths: success:Ask number of widgets - node_name:Ask number of widgets node_type: AskForSlot slot_name: WidgetCount prompts: initial:”How many widgets would you like?” retry:”Sorry,tell me how many widgets you want to add to the order.” ... output_paths: success:Perform identification and verification - node_name: Perform identification and verification node_type: Link target_flow_id:3829389 output_paths: success:Fulfill order error:Reset password - node_name:Reset password node_type:Link target_flow_id:948494 output_paths: success:Perform identification and verification - node_name:Fulfill order node_type: Webhook url:https: / / www.genesys.com / widgets / orders method:POST fields:[AccountNumber,WidgetCout] - node_name:Handle error node_type:Say prompt:”Sorry,an error occurred.Please try again later.” default: output_paths: Error: Handle error

[0113] A node can query a context (including a list of active intents and slot values) and queue up output prompts to display to the user. A node can also pause and wait for new input from the user if it needs to. Different types of customizable nodes may include some of the following examples: The "Say" type outputs a message from the user. The "Ask for Slot" type pauses until the configured slot is filled by the user. The "logic" type executes custom logic and / or calls a web service. The "Link" type may call another response flow and return the result to the current response flow. The "Return" type may terminate the execution of a response flow and return a given result to the response flow that called it. To prevent undesirable execution of any node, it can be configured in "Memory" so that if the node has already executed successfully (current or previous turn), its execution is skipped on subsequent visits and the same result as the last is used. Memory may depend on specific named slot values ​​so that the node's execution is skipped unless the values ​​of those slots change after the node has fully executed.

[0114] As those skilled in the art will understand, other possible embodiments of the invention can be formed by further selectively applying many of the various features and configurations described above with respect to some exemplary embodiments. For brevity and to consider the capabilities of those skilled in the art, each of the possible iterations is not provided or discussed in detail, but all combinations and possible embodiments encompassed by some of the following claims or otherwise are intended to be part of this application. Furthermore, from the above description of some exemplary embodiments of the invention, those skilled in the art will recognize improvements, changes, and modifications. Such improvements, changes, and modifications within the technical scope of those skilled in the art are also intended to be covered by the appended claims. Furthermore, the above should be made clear that numerous changes and modifications can be made without departing from the spirit and scope of this application, relating only to the embodiments described in this application and as defined by the following claims and their equivalents.

Claims

1. A computer implementation method for performing dialogue turns in a conversation using a dialogue manager, The aforementioned dialog manager receives task-related input from the user, The input from the user is passed to the NLU engine, Receiving a list of intent candidates associated with the task from the NLU engine, wherein the list of intent candidates includes the associated confidence score for each of the intent candidates, and the list of intent candidates includes at least one detected new intent together with its associated confidence score. The confidence level of the intent candidate from the NLU engine is rescored using weights applied to the relevant confidence levels of one or more tasks currently active by the user. Select an intent based on the rescored confidence level, Based on the selected intent, determine a new task path within the intent hierarchy, Confirm the selected intent and associated slot, This includes selecting a response flow for the new task path within the hierarchy of intents and executing the response flow, The aforementioned rescoring, The steps include configuring the NLU engine with a list of all available intentions, wherein the NLU engine does not recognize the conversational context; The dialog manager stores session information, including the current task path, a list of one or more recently completed task paths, and a list of one or more pending task paths. The associated confidence score of the at least one detected new intent is increased based on one or more of the following steps: - The aforementioned new intent is a child of the aforementioned current task path, - The new intent matches a task in the list of recently completed task paths, and - A method by which the new intent matches a task in the list of pending task paths.

2. The method according to claim 1, wherein the input includes one of typed text or a transcription from automatic speech recognition.

3. The method according to claim 1, wherein the list of candidate intentions includes one or more slot values ​​for each of the candidate intentions.

4. The method according to claim 1, wherein the task path of the task includes the location of a single instance of the intent associated with the task in a hierarchy.

5. The method according to claim 4, wherein the task path includes a sequence of intent names starting from the root of the hierarchy.

6. The method according to claim 4, wherein the intent associated with the task appears in multiple locations within the hierarchy.

7. The method according to claim 1, wherein determining the new task path includes at least one of continuing the current task path, starting a child task path of the current task path, reopening a closed task path, switching from the current task path to a new task, and switching to a pending task path.

8. The method according to claim 1, wherein the verification is performed automatically by the user or the dialog manager, or by one of the following:

9. Determining the new task path is The steps include filtering the list of candidate intentions so that it includes results in which the rescored confidence exceeds a predetermined threshold, If there are two or more filtered candidate intentions, and the candidate intentions are the same but have different paths, A step to automatically determine the simplest different task path to each result, A step of presenting the user with the simplest different task path for selection, The method according to claim 1, further comprising the step of setting the simplest different task path as the new task path.

10. Determining the new task path is The steps include filtering the list of candidate intentions so that it includes results in which the rescored confidence exceeds a predetermined threshold, If there are two or more filtered candidate intentions, and the candidate intentions are the same but have different paths, The steps include having the user confirm the results, The step of determining the simplest different task paths to each result, The method according to claim 1, further comprising the step of presenting the user with the simplest different task path for selection.

11. The method according to claim 10, wherein the response flow comprises a modular structure further comprising a directed graph, and the action associated with each node in the directed graph comprises selecting which node to visit next.

12. The method according to claim 11, wherein the response flow includes a default node, and the default node includes a path to other nodes in the directed graph.

Images