Manage customer relationships using multiple chat servers designed to interface with service applications

Abstract

The interface unit provided according to one aspect of the present disclosure facilitates providing services to users based on multiple chat servers in a single chat session. In an embodiment, the interface unit receives a request for a chat dialogue from a user on a chat session, identifies a first suitable chat server for generating a response for the chat dialogue, and forwards a first input sequence received from an end user to the first suitable chat server. The corresponding response is forwarded back to the end user. The interface unit then forwards the received second input sequence to a second chat server to generate a second message sequence corresponding to the second input sequence. The interface unit forwards the second message sequence as a corresponding response to the second input sequence.

Description

[0001] Priority claim

[0002] This patent application is related to and claims priority to U.S. non-provisional patent application serial No. 15 / 957,932, filed on April 20, 2018, entitled “MANAGING CUSTOMER RELATION SHIPUSING MULTIPLE CHAT SERVERS DESIGNED TO INTERFACE WITH SERVICE APPLICATIONS,” which has the same applicant as this patent application. Technical Field

[0003] The present disclosure relates to customer relationship management (CRM), and more particularly to managing customer relationships using multiple chat servers designed to interface with service applications. Background Art

[0004] Chat servers are generally accessible on a network such as the World Wide Web (WWW) and operate based on input in a format similar to natural language. In a common scenario, the chat server receives input from an end user (human) and provides corresponding responses in an interactive manner. The chat server may employ techniques such as artificial intelligence when forming the corresponding responses, which are also well known in the relevant art.

[0005] Chat servers are often designed to interface with service applications, usually to provide end users with enhanced functionality or a convenient user interface. Examples of service applications include travel applications, weather applications, hotel reservation applications, etc.

[0006] In a common scenario, the chat server invokes services provided by appropriate service applications depending on the specific context in the interactive conversation with the end user. For example, if the end user is engaging in an online chat conversation with reference to travel, the chat server can use services of service applications related to travel, weather, etc. to serve the end user.

[0007] Aspects of the present disclosure are directed to managing customer relationships using multiple chat servers designed to interface with service applications. Summary of the invention

[0008] According to one aspect of the present disclosure, a method for managing a relationship with a user is provided, the method being performed in an interface unit, the method comprising: maintaining configuration data indicating a corresponding set of chat servers that can be used for each of a plurality of broad purposes; receiving a request for a chat dialogue for a first purpose from a user on a chat session; identifying a first chat server for the first purpose from the corresponding set of chat servers that is suitable for generating a response for the chat dialogue based on the configuration data; receiving a first input sequence from the user; interfacing with the first chat server to receive a first message sequence corresponding to the first input sequence from the first chat server; forwarding a corresponding first response to the first input sequence on the chat session, wherein each first response includes a first message The method further comprises: receiving, based on the configuration data, a second chat server for a second purpose to continue the chat session, wherein the second purpose is manifested in a conversation between the user and the first chat server on the chat session, wherein the second purpose is different from the first purpose; receiving a second input sequence from the user on the same chat session after the first input sequence; interfacing with the second chat server to receive a second message sequence corresponding to the second input sequence from the second chat server, wherein the chat conversation continues with the second chat server in the same chat session without the user selecting the second chat server; and forwarding corresponding second responses to the second input sequence on the same chat session, wherein each second response includes the text of the corresponding message of the second message sequence.

[0009] According to another aspect of the present disclosure, a non-transitory machine-readable medium storing one or more instruction sequences is provided, wherein execution of the one or more instructions by one or more processors included in an interface unit causes the interface unit to perform the following actions: maintaining configuration data indicating a corresponding set of chat servers that can be used for each of a plurality of broad purposes; receiving a request for a chat dialogue for a first purpose from a user on a chat session; identifying a first chat server for the first purpose from the corresponding set of chat servers that is suitable for generating a response for the chat dialogue based on the configuration data; receiving a first input sequence from the user; interfacing with the first chat server to receive a first message sequence corresponding to the first input sequence from the first chat server; forwarding a corresponding response to the first input sequence on the chat session; first responses, wherein each first response includes the text of a corresponding message of the first message sequence; based on the configuration data, determining a second chat server for a second purpose to continue the chat session, wherein the second purpose is manifested in a conversation between the user and the first chat server on the chat session, wherein the second purpose is different from the first purpose; receiving a second input sequence from the user on the same chat session after the first input sequence; interfacing with the second chat server to receive a second message sequence corresponding to the second input sequence from the second chat server, wherein the chat conversation continues with the second chat server in the same chat session without the user selecting the second chat server; and forwarding corresponding second responses to the second input sequence on the same chat session, wherein each second response includes the text of the corresponding message of the second message sequence.

[0010] According to another aspect of the present disclosure, an interface unit for facilitating management of a relationship with a user is provided, the interface unit comprising: a memory for storing instructions; one or more processors for executing the instructions stored in the memory so as to cause the interface unit to perform the following actions: maintaining configuration data indicating a corresponding set of chat servers that can be used for each of a plurality of broad purposes; receiving a request for a chat dialogue for a first purpose from a user on a chat session; identifying a first chat server for the first purpose from the corresponding set of chat servers suitable for generating a response for the chat dialogue based on the configuration data; receiving a first input sequence from the user; interfacing with the first chat server to receive a first message sequence corresponding to the first input sequence from the first chat server; forwarding a corresponding response to the first input sequence on the chat session; The method comprises: providing a first response to the chat conversation, wherein each first response includes the text of a corresponding message of the first message sequence; determining, based on the configuration data, a second chat server for a second purpose to continue the chat session, wherein the second purpose is manifested in a conversation between the user and the first chat server on the chat session, wherein the second purpose is different from the first purpose; receiving a second input sequence from the user on the same chat session after the first input sequence; interfacing with the second chat server to receive a second message sequence corresponding to the second input sequence from the second chat server, wherein the chat conversation continues with the second chat server in the same chat session without the user selecting the second chat server; and forwarding corresponding second responses to the second input sequence on the same chat session, wherein each second response includes the text of the corresponding message of the second message sequence. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Example embodiments of the present disclosure will be described with reference to the accompanying drawings, which are briefly described below.

[0012] Figure 1A is a block diagram illustrating an example environment in which several aspects of the present disclosure may be implemented.

[0013] Figure 1B is a block diagram illustrating an existing approach where an end user interfaces with multiple chat servers.

[0014] Figure 2 is a block diagram illustrating some features of the disclosure in an example embodiment.

[0015] Figure 3 is a flow chart illustrating a manner of managing customer (end user) relationships using multiple chat servers according to an aspect of the present disclosure.

[0016] Figure 4 is a block diagram illustrating the internal architecture of an interface unit according to an embodiment of the present disclosure.

[0017] Figure 5A-5JDepicted together are sample configuration data implemented in an interface unit in one embodiment.

[0018] Figure 6A-6C An example user interface in one embodiment of the present disclosure is depicted.

[0019] Figure 7A-7C Describes the Figure 6A-6C The corresponding events of the user interface experience.

[0020] Figure 8 is a block diagram illustrating details of a digital processing system in which aspects of the present disclosure are operable through execution of appropriate executable modules.

[0021] In the drawings, like reference numbers generally indicate identical, functionally similar, and / or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number. DETAILED DESCRIPTION

[0022] 1. Overview

[0023] The interface unit provided according to one aspect of the present disclosure facilitates providing services to users based on multiple chat servers in a single chat session. In an embodiment, the interface unit receives a request for a chat dialogue from a user on a chat session, identifies a first suitable chat server for the chat dialogue, and forwards a first input sequence received from an end user about the chat session to the first suitable chat server. The message generated as a result will be forwarded back to the end user as a corresponding response. The interface unit then forwards the received second input sequence to a second chat server to receive a second message sequence corresponding to the second input sequence. The interface unit forwards the second message sequence as a corresponding response to the second input sequence.

[0024] According to another aspect of the present disclosure, the operation of the interface unit is controlled by configuration data that can be configured by an administrator. In an embodiment, the configuration data indicates a corresponding set of chat servers that can be used for each of a plurality of broad purposes. Each of the first input sequence and the second input sequence is encapsulated in a corresponding network packet, wherein the destination field indicates that the network packet terminates at the interface unit. Each of the first message sequence and the second message sequence is encapsulated in a corresponding packet, wherein the source field indicates that the packet originates from the interface unit. The configuration data indicates that the first chat server and the second chat server are included in the first chat server set for the first broad purpose. The interface unit checks the configuration data to determine that the first input sequence will be forwarded to the first chat server and the second input sequence will be forwarded to the second chat server.

[0025] According to another aspect of the present disclosure, the configuration data further indicates a corresponding action required for each of the plurality of intents presented in the chat conversation. The interface unit may determine a sequence of current intents presented at corresponding time instances in the chat conversation, and determine a corresponding action to be performed for each current intent by examining the configuration data. The interface unit may perform the determined corresponding action.

[0026] According to another aspect, each of the input and the message is in accordance with a natural language, wherein the input is forwarded to the set of chat servers in the natural language, and the message is also received from the set of chat servers in the natural language. In an embodiment, each intent is provided by a corresponding chat server along with a response packet. In another embodiment, the switching from the first chat server to the second chat server is based on an entry in the configuration data.

[0027] According to another aspect, after completing the processing of the first purpose, the interface unit forwards a set of metadata representing the current state of the chat transaction to each of the set of chat servers as part of serving the first purpose. The interface unit determines a set of suitable chat servers depending on the corresponding responses received from each of the set of chat servers, and sets one of the set of suitable chat servers as the second chat server.

[0028] For illustration, several aspects of the present disclosure are described below with reference to examples. However, those skilled in the relevant art will recognize that the present disclosure can be practiced without one or more specific details or using other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not shown in detail to avoid obscuring the features of the present disclosure. In addition, the described features / aspects can be practiced in various combinations, but only some combinations are described here for brevity.

[0029] 2. Sample Environment

[0030] Figure 1A 1 is a block diagram illustrating an example environment in which aspects of the present disclosure may be implemented. The block diagram shown includes client systems 110A-110M (where M may be any positive integer), web servers 120A-120N (where N may be any positive integer), a communication network 125, and a cloud infrastructure 135. The cloud infrastructure 135 is further shown to include CRM systems 130A-130Q (where Q may be any positive integer), custom service providers 145A-145S (where S may be any positive integer), and chat servers 140A-140P (where P may be any positive integer).

[0031] Just for illustration, Figure 1AOnly a representative number / type of systems are shown. Many environments often contain many more systems in number and type, depending on the purpose for which the environment is designed. Figure 1A Each box of .

[0032] The communication network 125 represents a network that provides connectivity between the web servers 120A-120N, the client systems 110A-110M, and the cloud infrastructure 135. The communication network 125 may be the Internet (including the globally connected Internet), a combination of the Internet and an intranet, etc. The communication network 125 may be implemented using protocols such as the Transmission Control Protocol (TCP) and / or the Internet Protocol (IP), which are well known in the relevant art.

[0033] Generally speaking, in a TCP / IP environment, a TCP / IP packet is used as the basic transport unit, wherein the source address is set to the TCP / IP address assigned to the source system from which the packet originates, and the destination address is set to the TCP / IP address of the target system to which the packet is ultimately delivered. When the destination IP address of the packet is set to the IP address of the target system, the IP packet is said to be directed to the target system, so that the packet is ultimately delivered to the target system via the communication network 125. When the packet contains content (such as a port number) that specifies a target application, the packet may also be said to be directed to such an application.

[0034] Each of the client systems 110A-110M represents a system used by a user to interact with the chat servers 140A-140P and the CRM systems 130A-130Q, such as a terminal, a personal computer, a workstation, a mobile device, a computing tablet, etc. The chat with the chat server is conducted in "natural language", which means that the corresponding content is expressed in a language commonly used by humans to communicate, such as English, German, French, Spanish, Hindi, and Kannada.

[0035] With regard to chat, IP packets may be used to implement the interface, wherein packets from the client system are directed to the chat server at the corresponding chat server, and packets from the chat server are directed to the corresponding client system. Similarly, IP packets may also be used to interface with the CRM system, but according to the appropriate interface for the corresponding interaction.

[0036] Each of the web servers 120A-120N represents a server that provides services to external systems, such as a web / application server. In the illustrative embodiment, it is assumed that the web servers 120A-120N implement various travel-related services accessed by the chat server, such as flight reservations, hotel reservations, taxi reservations, etc., but the web servers can implement and provide any services that are suitable in the corresponding environment.

[0037] Cloud infrastructure 135 is shown hosting customer relationship management (CRM) systems 130A-130Q and chat servers 140A-140P. As is well known in the relevant art, cloud infrastructure 135 generally enables universal access to a shared pool of CRM systems 130A-130Q and chat servers 140A-140P over the Internet.

[0038] Chat servers 140A-140P implement chat servers that enable user interaction in natural language. Therefore, each chat server receives input in natural language and also generates output in natural language. The output generated (in natural language) is forwarded to the corresponding client system.

[0039] CRM systems 130A-130Q represent conventional systems that formally supplement the management of customer (end-user) relationships. Each CRM system is typically used to maintain the identity and contact information of various customers (end-users), and manage customer interactions related to any purchase, subscription, problem, or marketing effort.

[0040] Customized service providers 145A-145S are public web services accessible via the Internet. Some exemplary customized service providers are weather forecast services, map services, etc.

[0041] The description continues with the way in which the chat server can be used by end users and the problems with this approach.

[0042] 3. Existing methods

[0043] Figure 1B 1 is a block diagram illustrating an existing method, wherein an end user interfaces with multiple chat servers. The block diagram is shown as including an end user 150, chat servers 160A-160C and utility servers, such as a travel server 170A, a hotel server 170B and a weather forecast server 170C.

[0044] In existing methods, the chat server is configured to interact with one or more utility servers and provide responses to end users 150 (from one of client systems 110A-110M). Utility servers are web applications that provide services to end users. For example, utility servers may include web applications that provide travel reservation services, hotel reservation services, and weather update services.

[0045] As an example, chat server 1160A is shown interfacing with two utility servers, namely travel server 170A and hotel server 170B. Thus, chat server 1160A is configured to provide at least information about travel booking and hotel booking services to end-user 150.

[0046] Similarly, chat server 2 160B is shown as interfacing with one server (ie, hotel server 170B). Thus, chat server 2 160B is configured to provide hotel reservation services to end users 150 only.

[0047] In a similar manner, chat server 3 160C is shown as interfacing with one server, namely weather forecast server 170C. Thus, chat server 3 160C is configured to provide weather forecast services to end users 150 only.

[0048] This prior method involves several challenges.One challenge is that a single chat server configured to interface with one or more utility servers may not meet the needs of the user.For example, the chat server 1160A configured to interface with travel services and hotel services provided by a supplier may not meet the requirement of providing weather forecast services.Similarly, the chat server 3160C configured to interact with weather forecast server 170C provided by another supplier may not provide hotel services or travel services.In other words, the existing method cannot provide a solution for integrating a plurality of chat servers provided by different suppliers.Another challenge is that the existing method lacks the method for integrating chat servers with customer relationship management (CRM) application systems.Another challenge in the existing method is lacking integration between the chat servers.In other words, during the chat session, chat server 1 160A does not share any metadata with chat server 2 160B and / or chat server 3 160C, thereby can not generate additional options that the user may be interested in but are not a part of the user's request.

[0049] Aspects of the present disclosure provide a method of managing customer relationships using multiple chat servers designed to interface with service applications.

[0050] 4. Block Diagram of Example Embodiments

[0051] Figure 2 is a block diagram illustrating some features of the present disclosure in an example embodiment. The block diagram shown includes an end user 150, an interface unit 250, chat servers 260A-260P, CRM systems 280A-280Q, and customized service providers 270A-270S.

[0052] End-user 150 interacts with interface unit 250 using a chat client. Exemplary chat clients include Facebook Messenger TM , Whatsapp TM 、Line TM and WeChat TMThe interaction between the end user 150 and the interface unit 250 is a two-way communication, as represented by 245.

[0053] Each of the chat servers 260A-260P can operate similarly to the chat servers 160A-160C and interface with various services in the backend (although not shown). In other words, each chat server 260A-260P receives input in natural language on the corresponding path 256A-256P, appropriately uses (calls) the services provided by the utility servers (e.g., travel server 170A, hotel server 170B, and weather forecast server 170C), and also generates a response in natural language on a corresponding one of the paths 256A-256P. In the following description, each of the chat servers 260A-260P is implemented as a chatbot (e.g., DialogFlow product) or an AI (artificial intelligence) enabled processing engine (e.g., Clarifai application well known in the relevant field), and is thus able to provide automatic responses in natural language. In addition, each of the chat servers 260A-260P is also able to provide additional information ("intention" explained below) as part of the response.

[0054] Although not shown, each chat server may be able to provide chat sessions directly to end users without the packet content traversing the interface unit 250. In this case, the input / output interface may also be similar to the packets received / sent on the paths 256A-256P.

[0055] Each of the customized service providers 270A-270S provides publicly available web services over the Internet in a similar manner as the customized service providers 145A-145S. Each of the CRM systems 280A-280Q manages customer (end user) relationships in a similar manner as the CRM systems 130A-130Q.

[0056] The interface unit 250 provided in accordance with one aspect of the present disclosure interfaces with more than one dialog server (when needed) in providing responses to the end user 150 in a single chat session. A single chat session is characterized by a sequence of messages (in either direction) displayed in a corresponding single window in a seamless manner (i.e., without requiring the user to take any action to switch between chat servers). The sequence of messages depicts the user inputs and corresponding responses (from the chat servers) in the conversation. It is assumed that each message is contained in a packet (with a corresponding TCP / IP header).

[0057] Thus, the interface unit 250 is able to utilize the service capabilities of any chat server when interacting with an end user. The interface unit 250 can interact with a chat server 3 having an interface capability with a weather forecast server 170C and with a chat server 1 having an interface capability with a travel server 170A and a hotel server 170B to provide a response to a single end user (client system) on a single chat session. For at least this reason, the above problem of the client system being able to communicate with a chat server 3 having an interface capability with a weather forecast server 170C can be solved. Figure 1B The problem(s) mentioned.

[0058] Each user input may be a single message or a collection of messages. In an embodiment, assuming that the user input is a single message, the single message may be processed by multiple systems (e.g., by any one of the chat servers 260A-260P, CRM systems 280A-280Q, and / or customized service providers 270A-270S) to provide responses from multiple systems. In other words, one or more chat servers, CRM systems, and / or customized service providers may seamlessly process a single user input to generate corresponding messages, all of which are provided as responses to the single user input.

[0059] In an embodiment, packets from client systems 110A-110M are directed to interface unit 250 (in one direction), which in turn forwards the content to the appropriate chat server. Interface unit 250 constructs packets based on the message responses from the corresponding chat servers, and forwards the packets so constructed back to the requesting client system (end user 150) in the opposite direction. The packets in the opposite direction originate from interface unit 250 (according to the IP protocol) and terminate at client systems 110A-110M. However, as will be apparent to those skilled in the relevant art by reading the disclosure provided herein, other methods may be used to implement alternative embodiments.

[0060] In another embodiment, administrator-definable / configurable rules are used to control the operation of the interface unit 250, which simplifies the integration of additional chat servers that are appropriate in the corresponding context. The description of this rule-based implementation of the interface unit 250 continues.

[0061] 4. Rule-based interface unit

[0062] Figure 3 is a flow chart illustrating a method for managing customer relationships using multiple chat servers (designed to interface with a server) according to one aspect of the present disclosure. Figure 2The interface unit 250 and the chat servers 260A-260P of the present invention are described in the flowchart. However, without departing from the scope and spirit of the various aspects of the present invention, many of the features may also be implemented in other environments, as will be apparent to those skilled in the relevant art by reading the disclosure provided herein.

[0063] The flowchart begins at step 301, where control immediately passes to step 310. In step 310, the interface unit 250 maintains configuration data indicating the chat servers that can be used for each broad purpose and the actions that need to be taken when a message from an end user in a chat conversation for that broad purpose identifies a specific intent. A broad purpose refers to a broad range of services / utilities (available from a single service provider) that an end user may be interested in. Each broad purpose can be a travel booking purpose, a hotel booking purpose, a taxi booking purpose, etc. Figure 1B Each broad purpose achieved by a corresponding utility server (eg, travel server 170A, hotel server 170B, and weather forecast server 170C) is shown in FIG.

[0064] An intent represents a recognizable state of a chat conversation in which an end user is currently interacting with a chat server (via interface unit 250). Based on the intent recognized by interface unit 250, a corresponding action can be triggered. In the embodiments described below, an "intent" is determined by a chat server and transmitted to interface unit 250. In the absence of an intent transmitted by a chat server 260A-260P, the intent is referred to as a "blank intent" for the sake of brevity. The configuration data indicates the operations required for each such intent in the context of the chat for the corresponding purpose. Intents can be determined based on various methods (implemented in the chat server, interface unit, and / or external system), although the (one or more) embodiments described below rely on a unique intent key transmitted from the chat server for this purpose.

[0065] In step 320, the interface unit 250 receives a request for a chat session from the end user 150 in natural language. The request may also specify a broad purpose. In step 340, the interface unit 250 checks the configuration data to determine the appropriate chat server to which the control will be transferred. The interface unit 250 may accordingly select one of the chat servers indicated in the configuration data as having service capabilities corresponding to the broad purpose specified in the request.

[0066] At step 350, control is transferred to the determined chat server. Transferring control means that the interface unit 250 thereafter transfers each received input regarding the chat dialogue to the determined chat server and receives a corresponding response. The interface unit 250 forwards each response to the chat dialogue to the same client system (end user) from which the request was received.

[0067] In step 360, the interface unit 250 determines the intent expressed in the conversation. The intent is determined by examining the request / response about the conversation. Techniques such as artificial intelligence (AI) can be used, although the embodiments described below depend on the intent state generated by the chat server. Examples of intent are shown in the configuration data described in the following sections.

[0068] In step 370, the interface unit 250 identifies the action that needs to be taken when a specific intent is transmitted based on the configuration data. Thereafter, the action is performed in steps 380 and 390 as described below.

[0069] In step 380, the interface unit 250 checks whether the determined action is to end the conversation. In that case, control is transferred to step 399, where the flowchart ends. Otherwise, control is transferred to step 390.

[0070] In step 390, the interface unit 250 performs the identified action, and control is then transferred to step 360. Such an action may also be to transfer control to another chat server, which means that the interface unit 250 is able to use as many different chat servers as desired in the same chat session (as experienced by the end user, typically in a corresponding single window established for the chat session). Similarly, as described above, by appropriately selecting the configuration data, multiple messages (each from a different chat server) may be generated as a response to a single message.

[0071] Different methods can be used in corresponding embodiments to achieve the above features. The details of the exemplary embodiments are described further.

[0072] 5. Example internal architecture of the interface unit

[0073] Figure 4 4 is a block diagram illustrating the details of the interface unit 250 in the illustrated embodiment. The interface unit 250 shown includes configuration data 405, a main controller 410, logic controllers 440A-440X, helper modules 420A-420(P+Q), and engine modules 460A-460(P+Q). Each block is described in further detail below.

[0074] Configuration data 405 may be stored in one or more files and controls the operation of interface unit 250. As will become clear from the following description, the configuration data is editable and modifiable so that chat servers or CRM systems can be added or removed (as well as changing operation with respect to each system) for any wide range of purposes.

[0075] The master controller 410 transmits packets received in an incoming chat session to one of the logical controllers 440A-440X (where X can be any positive integer) according to the configuration specified in the configuration data 405. When a chat session is initially established, the session is assigned to one of the logical controllers (and a specific chat server) according to the configuration data. The master controller 410 similarly receives packets from the assigned logical controller and forwards the packets to the communication network 125 so that the packets are delivered to the corresponding client system. Thus, the master controller 410 maintains a chat session table that indicates the logical controllers and chat servers to which the chat session is currently (at that point in time) assigned.

[0076] The master controller 410 also determines when to change the logical controller and / or chat server for the session (before updating the chat session table) and orchestrates the change accordingly. In an embodiment, the master controller 410 determines when / whether a change is needed based on the configuration data associated with each response and the current intent received. When it is determined that a change is necessary, the master controller 410 forwards the current context of the chat session to each of the logical controllers 440A-440X, and the logical controllers 440A-440X forward such context to the corresponding chat server. Such context can be sent as metadata representing the material data exchanged so far on the chat session.

[0077] The responses from each chat server may be examined to determine the most qualified chat server as the next chat server. In an embodiment, each response from a chat server indicates a "weight" value based on which the degree of eligibility is determined. The chat server from which the highest value is received may be selected as the most qualified chat server. The chat session table may be updated accordingly to seamlessly continue the user's interaction with the newly selected chat server.

[0078] Logic controllers 440A-440X correspond to X (different) broad purposes and implement any additional logic specific to the corresponding broad purpose. Thus, in the illustrative example, separate logic controllers may be provided for booking travel, taxis, hotels, etc. In an embodiment, if the logic controller chooses to use more than one chat server for a given broad purpose, the logic controller determines the specific chat server or CRM system to use for the chat session and interacts with the corresponding helper module for the grouping regarding that chat session.

[0079] Helper modules 420A-420(P+Q) facilitate including custom logic in the interaction between the logic controller and the engine module. Routine customization functions may include any required data conversion (e.g., XML to PDF, etc.) and wrapper functions that facilitate compatibility with previous versions, etc.

[0080] Each engine module 460A-460(P+Q) is designed to interface with a corresponding one of the chat servers 260A-260P and CRM systems 280A-280Q. Each engine module may strip a packet header from a network packet received from the communication network 125 and append a header suitable for forwarding the resulting cloud packet to the corresponding chat server / CRM system. Each engine module may operate to provide any other packet / protocol compatibility with the corresponding chat server / CRM system.

[0081] Similarly, when cloud packets are received from the chat server / CRM system, the engine module repackages the received content into network packets suitable for delivery to the corresponding client system. Thus, each engine module maintains a session mapping of TCP / IP session information on the communication network 125 side and corresponding session information on the cloud side to achieve the repackaging required in both directions.

[0082] In an embodiment, each chat server and CRM system responds (forwarded to the chat server / CRM system) with response content and intent for each input content of the user. According to various aspects of the present disclosure, the intent is also passed to the helper module to take appropriate action. By reading the present disclosure, when the received intent is passed to the helper module as the current intent, various techniques for determining such current intent will be apparent to technicians in the relevant fields, some of which are based on the persistence of the state of previous communications. As described above, the current intent is sent back to the main controller 410, and the main controller 410 determines further actions regarding associated (network) packets, etc.

[0083] Thus, it can be appreciated that configuration data 405 controls many of the actions performed by interface unit 250. Thus, in an example embodiment, the description continues with respect to sample configuration data.

[0084] 5. Sample configuration data

[0085] Figure 5A-5J Depicted together are sample configuration data implemented in an interface unit in one embodiment. The configuration data is in accordance with the JSON format, which is described in detail in a document titled "RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format" written by T. Bray of the Internet Engineering Task Force (IETF).

[0086] Broadly speaking, for illustration, the sample configuration data is defined for only three broad purposes, namely travel, hotel and taxi booking services. Other parts of the configuration data suitable for the corresponding environment will be apparent to those skilled in the relevant art by reading the disclosure provided herein.

[0087] Broadly speaking, Figure 5A-5G Blocks 510, 520, 528, 530, 540, 550, and 560, respectively, relate to controlling communications with chat servers 260A-260C. Figure 5H Block 570 involves interfacing with the CRM systems 258A-258Q. Fig.5I Block 580 involves interfacing with the customized service providers 270A-270S. Figure 5J Block 590 relates to the various types of chat clients that may use client systems 110A-110M to access interface unit 250. Each block is described in detail below.

[0088] Figure 5A The box 510 of indicates that the data part is related to the purpose of "travel" and there are two chat servers available for travel purpose ( Figure 5A travel.ai in sub-box 511 and Figure 5A image.ai in sub-box 512). Figure 5A Sub-box 513 of indicates that the priority is 1, which means that the travel module will be used as the default module compared to other modules with higher priority numbers. Sub-box 514 indicates that the "module1" logic controller (assuming it is logic controller 440A) can be called by the main controller 410 for travel booking purposes.

[0089] Figure 5A Each of the sub-boxes 511 and 512 contains text indicating a name, a description (input format), an application id, a user id / password for the corresponding engine module to log in and use the services provided by the chat server, an identifier of the "Intent" box expressed in the corresponding chat dialogue, and a URL regarded by the chat client as accessing the chat server.

[0090] Figure 5A The input format in the sub-box 511 of is shown as nlp (natural language processing), and Figure 5A The input format in sub-box 512 is shown as an image. Figure 5A Lines 515 and 516 of indicate the intents to be defined in submodules labeled "intents_1" (for travel.ai) and "intents_2" (for image.ai), respectively. These two submodules are shown as Figure 5D Block 530 and Figure 5E Box 540.

[0091] Corresponding to "intents_1" (line 515) Figure 5D The block 530 is shown as including Figure 5D 531-535 of the sub-boxes 531-535. Each sub-box is shown as containing a header unique intent key (needed to match the incoming intent from the chat server applicable to that sub-box), a "name" of the function to be called in the logic controller, and a weight. The weight is used as a threshold number for calling the named function (e.g., only when the received weight exceeds the specified weight).

[0092] Thus, sub-box 531 is shown as having a header unique intent key "START_INTENT", "start" as the function to be called in the "intents_1" file (as indicated by line 515), and 0.7 as the weight. The remaining sub-boxes 532-535 of box 530, sub-boxes 541-542 of box 540, and sub-boxes 543-544 of box 541 are similarly interpreted. Fig. 5F Box 550 and Figure 5G The sub-box of 560 is explained similarly to the above. Figure 5B Block 520 and Figure 5B Sub-boxes 521-524 of the present invention are described below and will not be described again for the sake of brevity.

[0093] Continue to refer to Figure 5H and 5I Blocks 570 and 580, Figure 5H Sub-box 571 of depicts a CRM system that may be used for travel purposes, and Figure 5H The sub-box 572 of depicts a CRM system that can be used for hotel purposes. Each sub-box is shown as containing a name, description, application id, user id / password combination (for login).

[0094] Fig.5I Block 580 of FIG. 5 contains two sub-blocks 581 and 582 , which respectively illustrate the manner in which messages may be published to and retrieved from custom service providers (eg, custom service providers 270A and 270B) using the REST / SOAP architecture.

[0095] Figure 5J Box 590 contains two sub-boxes 591 and 592 for Acme and Beta as text and voice chat clients respectively. Sub-box 591 indicates that the text chat client will be provided as part of the Acme website / webpage. Each sub-box also indicates the credentials / endpoint details required to communicate with the chat client.

[0096] The following example explains how to use this configuration data in the above architecture.

[0097] 6. Sample transactions for a single chat session

[0098] Figure 6A-6C Depicted is a sample user interface provided in examples of the present disclosure. Fig. 6A and Figure 6B depicts a user interface provided as part of a chat session on March 20, 2018. Figure 6C Depicted is a user interface provided as part of another chat session on March 28, 2018.

[0099] In with Fig. 6A and Figure 6B In a corresponding example, an end user at client system 110A is shown booking a travel ticket and then seamlessly provided with the option to book a hotel using a different chat server, in accordance with aspects of the present disclosure. Figure 6A-6C In the Acme website shown, when the end user clicks on the icon / link (although not shown), the end user is presented with a chat client window display 600. The Acme chat client window 600 contains a display of all messages to / from the end user.

[0100] Fig. 7A and Figure 7B Describes the Fig. 6A and 6B The corresponding events of the user interface experience. Figure 7C Describes the Figure 6C The corresponding events of the user interface experience.

[0101] Figure 7A-7C is shown as having Figure 5A-5J The various files / modules called in the configuration data of the , and some internal executable modules implemented in various modules. The modules of the logic controllers 440A-440X are shown as being implemented as .js files. For example, in Figure 7A-7C , module1 and intent1 of logic controller 1 440A are seen as being implemented as module1.js and intent1.js, respectively. The helper modules (Travel.ai helper module 420A, Image.ai helper module 420B, and OSVC CRM helper module 420C) are implemented as classes in Java script. The engine modules (Travel.ai engine module 460A, Image.ai engine module 460B, and OSVC CRM engine module 460C) can be implemented as Javascript libraries, JavaScript M It can be implemented in the form of archive (JAR) files, other programming languages, etc.

[0102] At 601, the end user from the Acme chat client is shown to have entered "Hello", which is represented as event 701 to the main controller 410. In response, the main controller 410 is shown to have called module1.js of the logic controller 1 440A (in view of the main controller 410 parsing sub-box 514) to process the network packet / content at 702. In view of sub-box 591, the main controller 410 triggers the process of obtaining the customerId from the request body in the network packet header.

[0103] The main controller 410 updates the internal chat session table to indicate that the current chat session is assigned to logical controller 1 440A. Event 703 depicts the invocation of the Travel.ai helper module 420A (selected according to the implementation of logical controller 1 440A), which in turn is shown as invoking the Travel.ai engine module 460A in event 704 to process the network packet.

[0104] The Travel.ai engine module 460A strips the header of the network packet, and the packet contents (including "Hello") are encapsulated consistent with the requirements of the chat server 260A. The Travel.ai engine checks the configuration data to obtain the URL, username, and password if necessary (sub-block 511), and sends the encapsulated packet (cloud packet) to the chat server 260A corresponding to the Travel.ai helper module 420A at event 705. To enable the network packet to be reconstructed in the reverse direction, the engine module updates the session map.

[0105] At 706, the chat server 260A is shown inspecting the encapsulated packet and forwarding a response (transfer intent) assumed to represent the text "Hello, please let me know how I can help you" and the intent "+START_INTENT" to the Travel.ai engine module 460A.

[0106] At event 707, the Travel.ai engine module 460A encapsulates the response of the chat server 260A consistent with the request of the Travel.ai helper module 420A (and "+START_INTENT"). Thereafter, the Travel.ai engine module 460A forwards the encapsulated response packet to the Travel.ai helper module 420A using the session mapping. At event 708, the Travel.ai helper forwards the encapsulated response packet to module1.js of the logic controller 1440A.

[0107] The Module.js / intent.js of the logic controller appends context data to the encapsulated response packet received from the helper module. The context data indicates the module and engine of the logic controller that processed the response packet. At 709, module1.js of logic controller 1 440A appends context data to the encapsulated response packet, indicating that the encapsulated response packet has been processed by module1 and the Travel.ai engine. Thereafter, the appended response packet is forwarded to the main controller 410.

[0108] The main controller 410 identifies the intent in the attached response packet. Thereafter, the main controller intercepts the intent and context data, calls the appropriate process in intent.js (of the corresponding logic controller selected according to the configuration data and based on the context data), and forwards the attached response to the appropriate process together with the data obtained at event 702.

[0109] At 710, the host controller identifies the intent "START_INTENT" in the attached response packet and truncates the intent. In view of the context data in the attached response packet, the host controller 410 realizes that the truncated response packet has been processed by the Travel.ai engine and module1. After truncating the context data, the host controller 410 parses line 515 (of sub-box 511). The configuration data therein instructs the host controller to parse sub-box 531 (of box 530) to determine the process "start" of intent1.js to be called next. Therefore, the host controller 410 forwards the truncated response packet along with the customerID (obtained at 702) to "start" of intent1.js (of logical controller 1 440A).

[0110] In response thereto, event 711 depicts the invocation of the Osvc CRM helper module 420C (selected according to the implementation of the logic controller 1440A), which in turn is shown as invoking the Osvc CRM engine module 460C at 712 to process the identified intent.

[0111] Each engine and helper encapsulates and rebuilds network packets or response packets in a manner suitable for the corresponding chat server / CRM system as described above. For the sake of brevity, the encapsulation of network packets and the reconstruction of response packets are not repeated.

[0112] At 713, the Osvc CRM engine module 460C checks the configuration data to obtain the URL, username and password if necessary (subblock 571) and interfaces with the CRM system 1 280A. Thereafter, the Osvc CRM engine module 460C sends the truncated response packet to the CRM system 1 280A.

[0113] At 714, CRM system 1 280A forwards the response (containing the details of the end user retrieved from CRM system 1 280A based on the customerId obtained at 702) to the Osvc CRM engine module 460C.

[0114] At 715 , the Osvc CRM engine module 460C forwards the response from the CRM system 1280A to the Osvc CRM helper module 420C, which in turn forwards at event 716 to “start” of intent1.js (of logic controller 1 440A).

[0115] At 717, intent1.js "start" (of logic controller 1 440A) extracts the end user's name (e.g., John Doe) from the response of CRM system 1 280A and constructs a greeting message to be sent to the end user. Thereafter, intent1.js "start" (of logic controller 1 440A) sends the constructed response message to the main controller 410.

[0116] At event 718, the main controller 410 forwards the reconstructed response message to the corresponding Acme chat client associated with the end user. Thus, the reconstructed response message "Hello, John Doe, please let me know how I can help you?" is displayed on the end user's Acme chat client window at 602.

[0117] In response thereto, at 603 , the user is shown as having entered “I would like to book a flight from Dubai to New York”, which is represented as event 719 to the main controller 410 .

[0118] At event 720, the master controller 410 is shown to have called module1.js of logic controller 1 440A (in view of the master controller 410 parsing sub-block 514) to process the new network packet / content.

[0119] Event 721 depicts the invocation of the Travel.ai helper module 420A (selected according to the implementation of logic controller 1 440A), which in turn is shown as invoking the Travel.ai engine module 460A at 722 to encapsulate the new network packet.

[0120] The Travel.ai engine module 460A checks the configuration data to obtain the URL, username and password if necessary (sub-block 511), and sends the encapsulated packet (cloud packet) to the chat server 260A corresponding to the helper module 420A at event 723.

[0121] At 724, the chat server 260A is shown inspecting the encapsulated packet and forwarding a response to the Travel.ai engine module 460A that is assumed to represent the text "Sure, I can help you. Can you tell me the date you would like to book a flight?" with no intent attached to the response.

[0122] At event 725, Travel.ai engine module 460A encapsulates the response of chat server 260A consistent with the requirements of Travel.ai helper module 420A. Thereafter, Travel.ai engine module 460A forwards the encapsulated response packet to Travel.ai helper module 420A.

[0123] At event 726, the Travel.ai helper forwards the encapsulated response packet to module1.js of logic controller 1 440A.

[0124] At 727 , module1.js of logic controller 1 440A forwards the encapsulated response packet to the main controller 410 .

[0125] At 728, the main controller 410 recognizes that no intent is attached to the encapsulated response packet, and therefore passes the encapsulated packet to the corresponding Acme chat client associated with the end user. Thus, the encapsulated response message "Sure, I can help you. Can you tell me the date you want to book a flight?" is displayed on the end user's Acme chat client window at 604.

[0126] In response thereto, at 605 , it is shown that the user has entered “30th of this month”, which is represented as event 729 to the main controller 410 .

[0127] Event 730 is represented as an event similar to events 720-723. In a similar manner, event 731 is represented as an event similar to events 724-727. At 731, chat server 260A forwards a response that is assumed to represent the text "What time of day do you want to travel?" without an intent attached to the response.

[0128] At 732 , the host controller 410 recognizes that there is no intent to be appended to the encapsulated response packet, and thus, the encapsulated response message “What time of day would you like to travel?” is displayed on the end user's Acme chat client window at 606 .

[0129] In response thereto, at 607 , the user is shown as having entered “6am”, which is represented as event 733 to the master controller 410 .

[0130] Event 734 is similar to event 730. In a similar manner, event 735 is similar to event 731. At 731, chat server 260A forwards a response that is assumed to represent the text "Please select from the available flights listed below: 'Emirates - EK520', Etihad Airways - EY5411'" without an intent attached to the response.

[0131] At 736 , the host controller 410 recognizes that there is no intent to append to the encapsulated response packet, and thus, the encapsulated response message “Please select from the available flights listed below: 'Emirates - EK520', 'Etihad Airways - EY5411'” is displayed at 608 on the end user's Acme chat client window.

[0132] In response, the end user selects a flight from the available list and at 609 , it is displayed that the user has selected “Emirates Airlines—EK520”, which is represented as event 737 to the main controller 410 .

[0133] In response, the main controller 410 is shown at 738 as having called module1.js of the logic controller 1440A (in view of the main controller 410 parsing sub-block 514) to process the network packet / content. Further, at 738, the network packet is forwarded to module1.js of the logic controller 1440A and then forwarded to the chat server 260A via the Travel.ai helper module 420A and the Travel.ai engine module 460A.

[0134] At event 739, the chat server 260A is shown as inspecting the encapsulated packet and forwarding a response that is assumed to represent the text "Please confirm the following details: Date: March 30, 2018; Time: 6:00AM; Flight: Emirates – EK520; Cost: $1100. Yes or No" and the intent "GET_CUSTOMER_PREFERENCE" to the Travel.ai engine module 460A. The encapsulated response packet is forwarded to module1.js of logic controller 1 440A via the Travel.ai helper module 420A. In addition, module1.js of logic controller 1 440A appends context data to the encapsulated response packet, indicating that the encapsulated response packet has been processed by module1 and the Travel.ai engine module 460A. Thereafter, the appended response packet is forwarded to the main controller 410.

[0135] At 740, the host controller identifies the intent "GET_CUSTOMER_PREFERENCE" in the attached response packet and truncates the intent from the received packet. Given the context data in the attached response packet, the host controller 410 knows that the truncated response packet has been processed by the Travel.ai engine module 460A and module1. Thus, the host controller 410 parses line 515 (of sub-box 511). The configuration data therein instructs the host controller to parse sub-box 534 (of box 530) to determine the procedure "c$get_customer_info" of intent1.js to be called next. Thus, the host controller 410 forwards the truncated response packet along with the customer ID (obtained at 702) to the procedure "c$get_customer_info" of intent1.js (of logical controller 1 440A).

[0136] In response thereto, event 740 also depicts the invocation of the Osvc CRM helper module 420C (selected according to the implementation of the logic controller 1440A), which in turn is shown as invoking the Osvc CRM engine module 460C to process the identified intent. The Osvc CRM engine module 460C checks the configuration data to obtain the URL, username and password (sub-box 571) as needed, and interfaces with the CRM system 1 280A. Thereafter, the Osvc CRM engine module 460C sends the truncated response packet to the CRM system 1 280A.

[0137] At 741, CRM system 1 280A forwards the response (containing the end user's name, age, gender, and dining preferences retrieved from CRM system 1280A based on the customerId obtained at 702) to Osvc CRM engine module 460C. Osvc CRM engine module 460C forwards the response from CRM system 1 280A to Osvc CRM helper module 420C, which in turn forwards to "c$get_customer_info" of intent1.js (Logic Controller 1 440A). In response, "c$get_customer_info" of intent1.js (Logic Controller 1 440A) extracts the end user's name, age, gender, and dining preferences (e.g., John Doe, 35 years old, male, vegetables, respectively) from the response from CRM system 1 280A and constructs a confirmation message to be sent to the end user. Thereafter, “c$get_customer_info” of intent1.js (of the logic controller 1 440A) sends the constructed response message to the main controller 410 .

[0138] At event 742, the main controller 410 forwards the reconstructed response message to the corresponding Acme chat client associated with the end user. Thus, the reconstructed response message "Please confirm the following details: Name: John Doe; Age: 35; Gender: Male; Meal: Vegetable; Date: March 30, 2018; Time: 6:00 AM; Flight: Emirates Airlines - EK520; Cost: $1100. Yes or No" is displayed on the end user's Acme chat client window at 610.

[0139] In response thereto, at 611 the end user is shown confirming the details by selecting “yes”, which is represented as event 743 to the main controller 410 .

[0140] In response, at 744, the main controller 410 is shown as having called module1.js of logic controller 1 440A (given that the main controller 410 resolves sub-box 514) and module1.js forwards the network packet to the Travel.ai engine module 460A via the Travel.ai helper module 420A and the chat server 260A (confirmation message "yes").

[0141] Event 745 is similar to event 739. At event 745, the chat server 260A is shown as checking the encapsulated packet and booking the flight according to the details section confirmed at 611. Thereafter, the chat server 260A forwards a response assuming the text "Your flight has been successfully booked. Here are your flight itinerary" along with all the details of the booked flight and appending the intent "POSITIVE_END_INTENT" to the Travel.ai engine module 460A. The appended response packet is further forwarded to the Travel.ai helper module 420A and then to the main controller 410 via module1.js of the logic controller 1 440A.

[0142] At event 746, the main controller 410 reconstructs the response message to display the flight itinerary and forwards the reconstructed response message to the corresponding Acme chat client associated with the end user. Thus, the reconstructed response messages "Your flight has been successfully booked" and "Here is your flight itinerary" are displayed on the end user's Acme chat client window at 612A and 612B, respectively.

[0143] When the master controller 410 recognizes the "POSITIVE_END_INTENT", the master controller broadcasts metadata (in this example, indicating the updated status of the tasks completed in the specific module of the logic controller 440A) to the corresponding modules of the remaining logic controllers 440B-440X. For illustration, assume that the remaining logic controllers are 440B and 440C.

[0144] At events 748 and 749, in view of the "POSITIVE_END_INTENT" appended at event 745, the main controller 410 is shown as broadcasting metadata (indicating the completion of the flight booking task in module1 of logic controller 440A) to the corresponding modules of the remaining logic controllers 440B and 440C. In this example, the metadata may include the origin and destination, flight time, flight name, details of the end user (name, age), etc., with appropriate tags according to any pre-specified conventions. At event 748, module2.js of logic controller 2 440B determines whether a hotel can be booked. At event 749, module3.js of logic controller 3 440C determines whether a taxi can be booked.

[0145] In response to the broadcast of the metadata, based on the determinations at events 748 and 749, each of the logic controllers 440B and 440C sends a confidence level at events 751 and 752, respectively. The confidence level can be any number between 0 and 1 (including both). In this example, the current transaction date is shown as March 20, 2018 (10 days before the flight travel date). Therefore, logic controller 2 440B sends a confidence level of 0.8 (because a hotel can be booked 10 days before the flight date), while logic controller 3 440C sends a confidence level of 0.4 (because a taxi can be booked even after the flight travel date). Therefore, the hotel reservation (shown in module2.js of logic controller 2 440B) may be the next most qualified transaction for the current transaction.

[0146] The master controller 410 selects the logic controller with the highest confidence level / highest priority or a combination of both as the next most qualified logic controller. Thus, the master controller 410 updates the internal chat session table to indicate that the current chat session is assigned to the most qualified logic controller.

[0147] The master controller 410 determines that module2.js of logic controller 2 440B has sent the highest confidence level among those sent by the corresponding modules of the remaining logic controllers 440B-440X.

[0148] In response, the main controller 410 updates the internal chat session table to indicate that the current chat session is assigned to logical controller 2 440B for hotel reservation purposes.

[0149] At event 753, the main controller 410 calls module2.js of logic controller 2 440B (given the highest confidence level sent by logic controller 2 440B). In response, the Hotel.ai helper module 420D (selected according to the implementation of logic controller 2 440B) is called. Figure 7A-7C ), which in turn calls Hotel.ai engine module 460D (in Figure 7A-7C 4). The Hotel.ai engine module 460D checks the configuration data to obtain the URL, username and password when needed (sub-box 521), and sends the encapsulated packet (cloud packet) to the chat server 260C corresponding to the Hotel.ai helper module 420D. The chat server 260C is shown as checking the broadcasted metadata and forwarding a response that is assumed to represent the text "Hi John Doe, do you want to book a hotel in New York on March 30, 2018? Yes or No".

[0150] The events between module2.js, Hotel.ai helper module 420D, Hotel.ai engine module 460D and chat server 260C are not Figure 7B , and is similar to the interaction as explained above with respect to module1.js. At event 754, the response packet is forwarded to the main controller 410. The generated response packet is forwarded to the end user at event 755, which is displayed on the end user's Acme chat client window at 613.

[0151] It can therefore be appreciated that messages 612B and 613 from chat servers 260A and 260C, respectively, are displayed as Figure 6B in response to input 611 provided by the end user.

[0152] At 614, the user is shown selecting "No", and thus the chat session ends at that point without control of the module / intent of logic controller 2 440B.

[0153] If the user selects "Yes", then according to Figure 5B The corresponding module / intent of logic controller 2 440B is called in block 520. The corresponding operation will be obvious to the skilled person by reading the disclosure of this article.

[0154] Therefore, it can be recognized that the above Figure 6A-6B All transactions described are performed within a single chat session, meaning that the user experience is within the same window as depicted there, and the corresponding packets exchanged will also reflect continuity.

[0155] In with Figure 6CIn another corresponding example, an end user at client system 110A is shown generating a boarding pass (with a passport verified) and then seamlessly booking a taxi using a different chat server in accordance with aspects of the present disclosure.

[0156] At 620, the end user from the Acme chat client is shown to have entered "Hello," which is represented as event 760 to the main controller 410. Events 761-776 are similar to events 702-717.

[0157] At event 777, the reconstructed response message "Hello, John Doe, please let me know if there is anything I can do to help you?" and the flight itinerary are displayed on the end user's Acme chat client window at 621A and 621B, respectively. Here, the response from Travel.ai includes the end user's flight itinerary displayed at 612B.

[0158] In response thereto, at 622 , the user is shown as having entered “Can you send me a boarding pass?”, which is represented as event 778 to the main controller 410 .

[0159] Events 779-782 are similar to events 702-705. At 783, chat server 260A is shown inspecting the encapsulated packet and forwarding the assumed representation text "Sure, I can help you. Can you send a scan of your passport for verification?" and a response to the intent "+ISSUE_BOARDING_PASS" (example unique intent key) to Travel.ai engine module 460A. Events 784-786 are similar to events 707-709.

[0160] At event 787, the main controller recognizes the intent "ISSUE_BOARDING_PASS" in the attached response packet and truncates the intent. In view of the context data in the attached response packet, the main controller 410 knows that the truncated response packet has been processed by the Travel.ai engine and module1. After truncating the context data, the main controller 410 parses line 515 (of sub-box 511). The configuration data therein instructs the main controller to parse sub-box 535 (of box 530) to determine the procedure "c$issue_boarding_pass" of intent1.js to be called next. Therefore, the main controller 410 forwards the truncated response packet along with the customerID (obtained at 702) to "c$issue_boarding_pass" of intent1.js (of logical controller 1 440A).

[0161] In response thereto, event 788 depicts the invocation of the Osvc CRM helper module 420C (selected according to the implementation of the logic controller 1440A), which in turn is shown as invoking the Osvc CRM engine module 460C at 789 to process the identified intent.

[0162] At 790, the Osvc CRM engine module 460C checks the configuration data to obtain the URL, username and password if necessary (subblock 571) and interfaces with the CRM system 1 280A. Thereafter, the Osvc CRM engine module 460C sends the truncated response packet to the CRM system 1 280A.

[0163] At 791, CRM system 1 280A sends a response (containing details of the end user's passport, if any, retrieved from CRM system 1 280A based on the customerld obtained at 702) to the Osvc CRM engine module 460C.

[0164] At 792 , the Osvc CRM engine module 460C forwards the response from the CRM system 1280A to the Osvc CRM helper module 420C, which forwards at event 793 to “c$issue_boarding_pass” of intent1.js (of logic controller 1 440A).

[0165] At 794 , “c$issue_boarding_pass” of intent1.js (of logic controller 1 440A) extracts the details of the end user's passport from the response from CRM system 1 280A and forwards the extracted passport details (if any) to the main controller 410 .

[0166] The description continues assuming that CRM system 1 280A does not contain the passport details of the end user.

[0167] At event 795, the main controller 410 forwards the truncated response packet to the corresponding Acme chat client associated with the end user. Thus, the reconstructed response message "Sure, I can help you. Can you send a scan of your passport for verification?" is displayed on the end user's Acme chat client window at 623.

[0168] In response, at 624 , the user is shown as having uploaded an image file (eg, a copy of his passport) to the main controller 410 , represented as event 796 .

[0169] In response, the master controller 410 is shown as having called module1.js of logic controller 1 440A at 797 (in view of the master controller 410 parsing sub-block 514) to process the network packet / content.

[0170] Module.js of logic controllers 440A-440X is implemented to select corresponding helper modules 420A-420(P+Q) and engine modules 460A-460(P+Q) according to the input type. For example, if the input type is image, module1.js of logic controller 1 440A calls Image.ai helper module 420B; and if the input type is text, module1.js of logic controller 1 440A calls Travel.ai helper module 420A.

[0171] Event 798 depicts the calling of the Image.ai helper module 420B (selected at 624 / event 796 according to the image input type), which in turn is shown as calling the Image.ai engine module 460B at 799 to process the network packet.

[0172] At 799A, the Image.ai engine module 460B checks the configuration data to obtain the URL, username, and password if needed (sub-block 512), and sends the encapsulated packet (cloud packet) to the chat server 260B corresponding to the Image.ai helper module 420B.

[0173] At event 799B, chat server 260B is shown as inspecting the encapsulated packet and forwarding the response and the corresponding intent to Image.ai engine module 460B. The description continues assuming that the end user has uploaded a copy of a real passport. Thus, chat server 260B generates a boarding pass and sends it to Image.ai engine module 460B along with the intent "+POSITIVE_END_INTENT".

[0174] At event 799C, Image.ai engine module 460B encapsulates chat server 260B's response (along with "+POSITIVE_END_INTENT") consistent with the requirements of Image.ai helper module 420B. Thereafter, Image.ai engine module 460B forwards the encapsulated response packet to Image.ai helper module 420B using the session mapping.

[0175] At event 799D, the Image.ai helper module 420B forwards the encapsulated response packet to module1.js of logic controller 1440A.

[0176] At 799E, module1.js of logic controller 1 440A appends context data to the encapsulated response packet, indicating that the encapsulated response packet has been processed by module1 and the Image.ai engine. Thereafter, the appended response packet is forwarded to the main controller 410.

[0177] At 799F, the main controller 410 identifies the intent "POSITIVE_END_INTENT" in the attached response packet and truncates the intent. In view of the context data in the attached response packet, the main controller 410 knows that the truncated response packet is processed by the Image.ai engine module 460B and module1. After truncating the context data, the main controller 410 parses line 516 (of sub-box 512). The configuration data therein instructs the main controller to parse sub-box 541 (of box 540) to determine the process "c$image_success" of intent2.js to be called next. Therefore, the main controller 410 forwards the truncated response packet to "c$image_success" of intent2.js (of logical controller 1 440A).

[0178] Event 799G describes that the truncated response is forwarded to Travel.ai helper module 420A for further processing.

[0179] At event 799H, the Travel.ai helper module 420A reconstructs the boarding pass corresponding to the details displayed at 621B / event 777. Thereafter, the Travel.ai helper module 420A forwards the reconstructed response packet along with the image "POSITIVE_END_INTENT" to "c$image_success" of intent2.js (of logical controller 1 440A), which is then forwarded to the main controller 410 at 799I.

[0180] At Event 799J, the reconstructed boarding pass image is displayed at 625 on the end user's Acme chat client window.

[0181] At events 799L and 799M, in view of the "POSITIVE_END_INTENT" appended at event 799H, the main controller 410 is shown as broadcasting metadata (indicating the completion of the task of generating a boarding pass in module1 of the logic controller 440A) to the corresponding modules of the remaining logic controllers 440B-440X. The description continues assuming that the remaining logic controllers are 440B and 440C.

[0182] In response to the broadcast of the metadata, each of the remaining logic controllers 440B and 440C sends a confidence level at events 7990 and 799P, respectively.

[0183] The description continues assuming that the next most qualified logic controller is the logic controller 3440C for taxi booking.

[0184] The master controller 410 determines that module3.js of logic controller 3 440C has sent the highest confidence level among those sent by the corresponding modules of the remaining logic controllers 440B and 440C.

[0185] In response, the main controller 410 updates the internal chat session table to indicate that the current chat session is assigned to logical controller 3 440C for taxi booking purposes.

[0186] At event 799Q, the master controller 410 calls module3.js of logic controller 3 440C (given the highest confidence level sent by logic controller 3 440C).

[0187] In response to this, the Taxi.ai helper module 420E is called (in Figure 7A-7C ) (selected according to the implementation of logic controller 3 440C), which in turn calls Taxi.ai engine module 460E (in Figure 7A-7C 4). Taxi.ai engine module 460E checks configuration data to obtain URL, username and password when needed (box 528), and sends the encapsulated packet (cloud packet) to chat server 260D corresponding to Taxi.ai helper module 420E. Chat server 260D is shown as checking the broadcasted metadata and forwarding a response that is assumed to represent the text "Hi John Doe, do you want to book a taxi from New York Airport on March 30, 2018? Yes or No" to module3.js.

[0188] The events between module3.js, Taxi.ai helper module 420E, Taxi.ai engine module 460E and chat server 260D are Figure 7C js, and is similar to the interaction described above with respect to module1.js. At event 799R, the response packet is forwarded to the main controller 410. The generated response packet is forwarded to the end user at event 799S, which is displayed on the end user's Acme chat client window at 626.

[0189] If the user selects "No", then the chat session ends at that point without control of the module / intent of logic controller 3 440C.

[0190] If the user selects "yes", then use the corresponding intents ("intents_5" and "intents_6") according to Figure 5C Block 528 of the present invention calls the corresponding module / intent of logic controller 3 440C, which, although not shown, can be similar to the respective Figure 5D and Figure 5E The method shown in blocks 530 and 530 is implemented.

[0191] In another embodiment of the present disclosure, at event 791, assuming that CRM system 1280A contains a valid passport for the end user (e.g., based on a history of previous interactions of the end user), the reconstructed response message "Sure, I can help you with that. Can you send a scan of your passport for verification?" is replaced with the details of the valid passport and forwarded to main controller 410. Main controller 410 calls Travel.ai helper module 420A and reconstructs the boarding pass as depicted at event 799H. The process continues as described above.

[0192] It will also be appreciated that aspects of the present disclosure enable the use of multiple chat servers to seamlessly serve end users in a single chat session.

[0193] Since the interface unit 250 providing such a seamless interface is based on configuration data, the administrator is provided with more control over the specific interactions between the various systems.

[0194] By utilizing the intents provided by the chat server, the interface unit is implemented to utilize various states determined by the chat service.

[0195] Although the use of multiple chat servers by the interface unit 250 is described in the above example as being controlled by configuration data, it will be appreciated that alternative methods may be implemented to achieve similar features in other ways suitable for the corresponding environment. For example, an end user may pre-specify an interest in ticket and hotel reservations in a first message, e.g. Fig. 6A At 603 of FIG. 5 , the end user may enter “I want to book a flight from Dubai to New York, and some hotel reservations, for example.” The main controller 410 may split that message into two messages, one for the flight reservation and another for the hotel reservation, and then process the first message first according to the above description. Thereafter, based on block 520, the main controller 410 automatically services the second message upon affirmative completion of processing of the first message (e.g., upon receipt of “POSITIVE_END_INTENT”), instead of broadcasting metadata.

[0196] Various methods may be used to implement the interface unit 250 according to aspects of the present disclosure. The description continues with respect to example embodiments, wherein features are operable by executing appropriately designed executable modules.

[0197] 8. Digital processing system

[0198] Figure 8 8 is a block diagram illustrating details of a digital processing system 800 in which aspects of the present disclosure may be operated by executing appropriate executable modules. The digital processing system 800 corresponds to the interface unit 250.

[0199] The digital processing system 800 may include one or more processors (such as a central processing unit (CPU) 810), a random access memory (RAM) 820, an auxiliary storage 830, a graphics controller 860, a display unit 870, a network interface 880, and an input interface 890. All components except the display unit 870 can communicate with each other via a communication path 850, which may include several buses well known in the relevant art. The following describes in more detail Figure 8 parts.

[0200] The CPU 810 may execute instructions stored in the RAM 820 to provide several features of the present disclosure. The CPU 810 may include multiple processing units, each of which may be designed for a specific task. Alternatively, the CPU 810 may include only a single general-purpose processing unit.

[0201] RAM 820 may receive instructions from secondary storage 830 using communication path 850. RAM 820 is shown as currently containing software instructions and application 826 that make up a shared environment 825. Shared environment 825 includes an operating system, device drivers, virtual machines, etc., which provide a (common) runtime environment for executing application 826. The various modules described above may be included in application 826 executing in shared environment 825.

[0202] Graphics controller 860 generates display signals (e.g., in RGB format) to display unit 870 based on data / instructions received from CPU 810. Display unit 870 includes a display screen to display images defined by the display signals. Input interface 890 can be used with a keyboard and pointing device (e.g., touch pad, mouse) that can be used to provide appropriate input (e.g., for editing configuration data). Network interface 880 provides connectivity to a network (e.g., using an Internet protocol) and can be used to communicate with other systems (of FIG. 1) connected to the network (140 / 120).

[0203] The secondary storage 830 may include a hard disk drive 835, a flash memory 836, and a removable storage drive 837. The secondary storage 830 may store data (e.g., a portion of the configuration data, as an appropriate file) and software instructions (for implementing Figure 2 ), which enables the digital processing system 800 to provide several features according to the present disclosure. For higher execution speed, the code / instructions stored in the auxiliary memory 830 can be copied to the RAM 820 before being executed by the CPU 810, or can be executed directly by the CPU 810.

[0204] Some or all of the data and instructions may be provided on a removable storage unit 840, and the data and instructions may be read by a removable storage drive 837 and provided to the CPU 810. The removable storage unit 840 may be implemented using media and storage formats compatible with the removable storage drive 837, so that the removable storage drive 837 may read the data and instructions. Thus, the removable storage unit 840 includes a computer-readable (storage) medium having computer software and / or data stored therein. However, computer (or generally, machine) readable media may be in other forms (e.g., non-removable, random access, etc.).

[0205] In this document, the term "computer program product" is used to generally refer to a removable storage unit 840 or hard disk installed in hard disk drive 835. These computer program products are means for providing software to digital processing system 800. CPU 810 can retrieve the software instructions and execute the instructions to provide the various features of the present disclosure described above.

[0206] The term "storage medium" as used herein refers to any non-temporary medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical disks, magnetic disks, or solid-state drives, such as auxiliary memory 830. Volatile media include dynamic memory, such as RAM 820. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes, or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or boxes.

[0207] Storage media are distinct from transmission media but may be used in conjunction with them. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including the wires that make up communication path 850. Transmission media may also take the form of sound or light waves, such as those generated during radio wave and infrared data communications.

[0208] References throughout this specification to "one embodiment," "an embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0209] In addition, the described features, structures or characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. In the above description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments of the present disclosure.

[0210] Although various embodiments of the present disclosure have been described above, it should be understood that they are given as examples only, not limitations. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above exemplary embodiments, but should only be limited according to the following claims and their equivalents.

[0211] It should be understood that the drawings and / or screen shots shown in the appendix that highlight the functions and advantages of the present disclosure are provided for illustrative purposes only. The present disclosure is flexible and configurable enough that it can be used in a manner different from that shown in the drawings.

Claims

1. A method for managing a relationship with a user, the method being performed in an interface unit, the method comprising: maintaining configuration data indicating a respective set of chat servers that can be used for each of a plurality of broad purposes; receiving a request from a user for a chat conversation for a first purpose over the chat session; identifying, based on the configuration data, a first chat server from a corresponding set of chat servers suitable for generating a response for the chat conversation for the first purpose; receiving a first input sequence from a user; interfacing with the first chat server to receive from the first chat server a first message sequence corresponding to the first input sequence; forwarding respective first responses to the first input sequence on the chat session, wherein each first response includes the text of a corresponding message of the first message sequence; determining, based on the configuration data, a second chat server for a second purpose to continue the chat session without user input, wherein the second purpose is represented in a conversation between the user and the first chat server over the chat session, wherein the second purpose is different than the first purpose; generating a message prompting the user whether to continue the chat session for the second purpose; receiving, after the first input sequence, a second input sequence from the user on the same chat session; interfacing with a second chat server to receive a second message sequence corresponding to the second input sequence from the second chat server, wherein the chat conversation continues with the second chat server in the same chat session without user selection of the second chat server; as well as Respective second responses to the second input sequence are forwarded on the same chat session, wherein each second response includes the text of a corresponding message of the second message sequence.

2. The method of claim 1, wherein each of the first input sequence and the second input sequence is encapsulated in a corresponding network packet, wherein a destination field indicates that the network packet terminates at an interface unit, Each of the first message sequence and the second message sequence is encapsulated in a corresponding packet, wherein a source field indicates that the packet originates from an interface unit.

3. The method of claim 1, wherein the configuration data further indicates a corresponding action required for each of the corresponding plurality of intents represented in the chat conversation, the method further comprising: Determining a sequence of current intents manifested at corresponding time instances in the chat conversation; determining a corresponding action to be performed for each current intent by examining the configuration data; as well as Execute the corresponding action.

4. The method of claim 3, wherein each of the input and the message is in accordance with a natural language, wherein the input is forwarded to the set of chat servers in the natural language, and the message is also received from the set of chat servers in the natural language, Each intent is received from a corresponding chat server.

5. The method of claim 3, wherein the interface unit switches from the first chat server to the second chat server after performing a first action, wherein the first action is associated with the first intent in the configuration data, The first intention is included in the current intention sequence.

6. The method of claim 5, wherein the first action comprises execution of a module, which causes the following further actions: As part of the first action, forwarding a set of metadata representing a current state of the chat conversation to each chat server in the set of chat servers; determining an appropriate set of chat servers depending on the corresponding responses received from each chat server in the set of chat servers; One of the set of suitable chat servers is set as the second chat server.

7. The method of claim 6, wherein the configuration data comprises an identifier of a set of customer relationship management (CRM) systems, wherein the second action indicates that the status of the chat conversation is to be stored in one of the CRM systems, and The third action indication information will be retrieved and forwarded to the second chat server so that the second chat server can process the request from the user contained in the chat dialogue.

8. The method of claim 1, wherein a first message in the first message sequence includes a second portion specifying a second purpose, wherein the interface unit serves the first purpose in the first input sequence and then automatically sends the second portion to the second chat server so that the second purpose is also served.

9. A non-transitory machine-readable medium storing one or more sequences of instructions, wherein execution of the one or more instructions by one or more processors contained in an interface unit causes the interface unit to perform the following actions: maintaining configuration data indicating a respective set of chat servers that can be used for each of a plurality of broad purposes; receiving a request from a user for a chat conversation for a first purpose over the chat session; identifying, based on the configuration data, a first chat server from a corresponding set of chat servers suitable for generating a response for the chat conversation for the first purpose; receiving a first input sequence from a user; interfacing with the first chat server to receive from the first chat server a first message sequence corresponding to the first input sequence; forwarding respective first responses to the first input sequence on the chat session, wherein each first response includes the text of a corresponding message of the first message sequence; determining, based on the configuration data, a second chat server for a second purpose to continue the chat session without user input, wherein the second purpose is represented in a conversation between the user and the first chat server over the chat session, wherein the second purpose is different than the first purpose; generating a message prompting the user whether to continue the chat session for the second purpose; receiving, after the first input sequence, a second input sequence from the user on the same chat session; interfacing with a second chat server to receive a second message sequence corresponding to the second input sequence from the second chat server, wherein the chat conversation continues with the second chat server in the same chat session without user selection of the second chat server; as well as Respective second responses to the second input sequence are forwarded on the same chat session, wherein each second response includes the text of a corresponding message of the second message sequence.

10. The non-transitory machine-readable medium of claim 9, wherein each of the first input sequence and the second input sequence is encapsulated in a corresponding network packet, wherein a destination field indicates that the network packet terminates at an interface unit, Each of the first message sequence and the second message sequence is encapsulated in a corresponding packet, wherein a source field indicates that the packet originates from an interface unit.

11. The non-transitory machine-readable medium of claim 9, wherein the configuration data further indicates a corresponding action required for each of the corresponding plurality of intents represented in the chat conversation, the action further comprising: Determining a sequence of current intents manifested at corresponding time instances in the chat conversation; determining a corresponding action to be performed for each current intent by examining the configuration data; as well as Execute the corresponding action.

12. The non-transitory machine-readable medium of claim 11, wherein each of the input and the message is in accordance with a natural language, wherein the input is forwarded to the set of chat servers in the natural language, and the message is also received from the set of chat servers in the natural language, Each intent is received from a corresponding chat server.

13. The non-transitory machine-readable medium of claim 11, wherein the interface unit switches from the first chat server to the second chat server after performing a first action, wherein the first action is associated with the first intent in the configuration data, The first intention is included in the current intention sequence.

14. The non-transitory machine-readable medium of claim 13, wherein the first action comprises execution of a module, which causes the following further actions: As part of the first action, forwarding a set of metadata representing a current state of the chat conversation to each chat server in the set of chat servers; determining an appropriate set of chat servers depending on the corresponding responses received from each chat server in the set of chat servers; One of the set of suitable chat servers is set as the second chat server.

15. The non-transitory machine-readable medium of claim 14, wherein the configuration data comprises an identifier of a set of customer relationship management (CRM) systems, wherein the second action indicates that the status of the chat conversation is to be stored in one of the CRM systems, and The third action indication information will be retrieved and forwarded to the second chat server so that the second chat server can process the request from the user contained in the chat dialogue.

16. The non-transitory machine-readable medium of any one of claims 9 to 15, wherein a first message in the first message sequence includes a second portion specifying a second purpose, wherein the interface unit serves the first purpose in the first input sequence and then automatically sends the second portion to the second chat server so that the second purpose is also served.

17. An interface unit for facilitating management of a relationship with a user, the interface unit comprising: A memory for storing instructions; One or more processors that execute instructions stored in the memory to cause the interface unit to perform the following actions: maintaining configuration data indicating a respective set of chat servers that can be used for each of a plurality of broad purposes; receiving a request from a user for a chat conversation for a first purpose over the chat session; identifying, based on the configuration data, a first chat server from a corresponding set of chat servers suitable for generating a response for the chat conversation for the first purpose; receiving a first input sequence from a user; interfacing with the first chat server to receive from the first chat server a first message sequence corresponding to the first input sequence; forwarding respective first responses to the first input sequence on the chat session, wherein each first response includes the text of a corresponding message of the first message sequence; determining, based on the configuration data, a second chat server for a second purpose to continue the chat session without user input, wherein the second purpose is represented in a conversation between the user and the first chat server over the chat session, wherein the second purpose is different than the first purpose; generating a message prompting the user whether to continue the chat session for the second purpose; receiving, after the first input sequence, a second input sequence from the user on the same chat session; interfacing with a second chat server to receive a second message sequence corresponding to the second input sequence from the second chat server, wherein the chat conversation continues with the second chat server in the same chat session without user selection of the second chat server; as well as Respective second responses to the second input sequence are forwarded on the same chat session, wherein each second response includes the text of a corresponding message of the second message sequence.

18. The interface unit of claim 17, wherein each of the first input sequence and the second input sequence is encapsulated in a corresponding network packet, wherein a destination field indicates that the network packet terminates at the interface unit, Each of the first message sequence and the second message sequence is encapsulated in a corresponding packet, wherein a source field indicates that the packet originates from an interface unit.

19. The interface unit of claim 17, wherein the configuration data further indicates a corresponding action required for each of the corresponding plurality of intents represented in the chat conversation, and the instructions stored in the memory, when executed by the one or more processors, cause the interface unit to perform the following actions: Determining a sequence of current intents manifested at corresponding time instances in the chat conversation; determining a corresponding action to be performed for each current intent by examining the configuration data; and Execute the corresponding action.

20. The interface unit of claim 19, wherein each of the input and the message is in accordance with a natural language, wherein the input is forwarded to the set of chat servers in the natural language, and the message is also received from the set of chat servers in the natural language, Each intent is received from a corresponding chat server.

Images