Systems and methods for facilitating robot communication

Abstract

A method for delivering messages from clients to bots, the method comprising providing a bot gateway and, in accordance with a process, formatting and sending a message. The bot gateway comprises bot schemas, each bot schema defining an arrangement of data fields for sending a request to a particular bot. The process comprises receiving a first message and therefrom determining a first client, a first tenant, a first bot, and a text message from the first client to the first bot. The process comprises providing a bot configuration data set, selecting a first bot schema belonging to the first bot, creating a formatted request via mapping the text message and the data values defined in the bot configuration data set into corresponding data fields defined in the arrangement of data fields, and sending the formatted request to the first bot.

Description

BACKGROUND

[0001] The present invention relates generally to telecommunications systems in the field of customer relationship management, including customer assistance via internet-based service options. More specifically, but not by way of limitation, the present invention relates to systems and methods for facilitating bot communications via a bot gateway implemented via a public cloud.

[0002] Cross Reference to Related Patent Applications

[0003] This application claims the benefit of U.S. Patent Application No. 16 / 569,519, filed September 12, 2019, entitled “Systems and Methods for Facilitating Bot Communications.” SUMMARY

[0004] Embodiments of the present invention can include processor-implemented systems and methods that facilitate the passing of messages from customers to bots, where tenants use software programs over a network to manage interactions with respective ones of the customers. The method can include the steps of providing a bot gateway, and using the bot gateway to format messages for passing to bots according to a process. The bot gateway can include a bot schema library having a plurality of bot schemas stored therein, where each of the bot schemas defines an arrangement of data fields according to a unique template for sending requests to a particular one of the bots. The process can include the steps of receiving a first one of the messages (hereinafter “first message”), analyzing the first message to determine therefrom: a relevant one of the customers (hereinafter “first customer”), a relevant one of the tenants (hereinafter “first tenant”), a relevant one of the bots (hereinafter “first bot”), and a text message from the first customer intended to be passed to the first bot, providing a bot configuration data set including data values related to a use case that pairs the first tenant with the first bot, selecting a first one of the plurality of bot schemas belonging to the first bot (hereinafter “first bot schema”) from the bot schema library, creating a formatted request via mapping the text message and the data values defined in the bot configuration data set to corresponding data fields defined in the arrangement of data fields of the first bot schema, and sending the formatted request to the first bot. BRIEF DESCRIPTION OF DRAWINGS

[0005] The present invention, together with its many attendant features and advantages, will become more fully apparent as the invention is more fully described by reference to the following detailed description, when considered in conjunction with the accompanying drawings, in which like reference numerals refer to like parts throughout the several views, and wherein:

[0006] Figure 1is a block diagram of a contact center according to an embodiment of the present application;

[0007] Figure 2 is a block diagram of a computing device according to an embodiment of the present application;

[0008] Figure 3 is a schematic block diagram showing further details of a chat server operating as part of a chat system according to an embodiment of the present application;

[0009] Figure 4 is a schematic block diagram of a chat module according to an embodiment of the present application;

[0010] Figure 5 is a schematic block diagram of a system configuration according to an embodiment of the present application;

[0011] Figure 6 is an exemplary customer chat interface according to an embodiment of the present application;

[0012] Figure 7 is a representation of the formatting progress of a request sent to a bot according to an embodiment of the present application; and

[0013] Figure 8 is a flowchart showing a method according to an embodiment of the present application. DETAILED DESCRIPTION

[0014] For the purposes of promoting an understanding of the principles of the application, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the application is intended by this specification. Alterations and further modifications of the described embodiments, and any further applications of the principles of the application as described herein are contemplated as would normally occur to one ordinarily skilled in the art to which the application relates.

[0015] The present application relates to telecommunications systems, and more particularly, but not exclusively, to contact centers. As general background art, contact centers are staffed with employees or agents (referred to herein as human agents or simply agents) who act as an interface between an organization such as a company or business and external entities such as customers and other end users (referred to herein generally as customers). For example, the human agents of a contact center can assist customers in making a purchase decision, and can receive purchase orders from such customers. Likewise, the human agents of a contact center can give customers assistance or support in resolving problems with products or services provided by the organization. Such interactions between the contact center agents and the external entities or customers can be conducted by voice (e.g., telephone calls or Voice over IP or VoIP calls), video (e.g., video conferencing), text (e.g., email and text chat), or by other media.

[0016] To remain competitive, companies continually strive to provide high quality customer service through such contact centers while minimizing the cost of providing these services. One option is to provide live human agents to handle each interaction with a customer. However, this option is often very expensive, with the high costs to the company ultimately being passed on to the consumer in the form of increased product prices. Additionally, coordinating the availability of live human agents qualified to handle various customer needs is complex and time consuming, and often results in decreased customer satisfaction due to long wait times for a specialized human agent to become available. Thus, most contact centers utilize some degree of automated processes in place of live agents. In many cases, this has proven to be a successful strategy, as automated processes - which can also be referred to herein as bots or simply "machines" - can efficiently handle certain types of interactions, thereby reducing costs by reducing the need for human agents. Automated interactions can also be built in a way that optimizes efficiency and improves repeatability. Given that a human agent can forget to ask certain questions or follow up on particular details, such errors can often be avoided through the use of automated bots.

[0017] Thus, contact centers are increasingly relying on automated processes or bots or "machines" as described herein to interact with customers, with automated chat modules or "chatbots" being one of the preferred ways in which to conduct the interactions. One of the benefits of utilizing such chatbots is that this allows contact centers to use human agents for more difficult customer interactions. As will be seen, embodiments of the present invention are directed to systems and methods for organizing and integrating bots and / or chatbots into enterprise websites. More specifically, according to certain embodiments, the present invention includes systems and methods for facilitating bot communications via a public cloud implemented gateway.

[0018] Reference is now made to Figure 1, presents a block diagram illustrating an embodiment of a communication infrastructure or contact center system according to the present application, referred to as contact center 100. The contact center 100 can generally be used to provide various types of contact center services. As will be seen, aspects of the contact center 100 can be used to engage in and manage chat sessions in which automated chat bots or machines and / or human agents communicate with customers or other end users. It should be appreciated that the contact center 100 can be used as an in-house facility for a company or enterprise for servicing the enterprise in performing sales and service functions related to products and services available through the enterprise. In another aspect, the contact center 100 can be operated by a third-party service provider. According to another embodiment, the contact center 100 can operate as a hybrid system in which some components are hosted on-premises and others are hosted remotely (e.g., in a cloud-based environment). The contact center 100 can be deployed on equipment dedicated to the enterprise or third-party service provider, and / or deployed in a remote computing environment such as, for example, a private or public cloud environment having infrastructure for supporting multiple contact centers for multiple enterprises. As discussed in greater detail below, the contact center can include software applications or programs that can be executed on-premises or remotely or some combination thereof. It should also be appreciated that the various components of the contact center can also be distributed in various geographic locations and computing environments and need not necessarily be contained in a single location, computing environment or even in computing devices.

[0019] According to Figure 1 embodiments, the components or modules of the contact center 100 can include: a plurality of client devices 105A, 105B, 105C; a communication network 110 (also referred to simply as network 110); a switch / media gateway 115; a call controller 120; an interactive media response (IMR) server 125; a routing server 130; a storage device 135; a statistical or stat server 140; a plurality of agent devices 145A, 145B, 145C including work areas 146A, 146B, 146C, respectively; a multimedia / social media server 150; a knowledge management server 152 coupled to a knowledge system 154; a chat server 155, a web server 158; an interaction (iXn) server 160; a universal contact server (UCS) 165; a reporting server 170; and a media services 175. As will be seen, the contact center 100 manages resources (e.g., personnel, computers, telecommunication equipment, etc.) to enable service delivery via telephone, email, chat or other communication mechanisms. Such services can vary depending on the type of contact center and range from customer service to help desk, emergency response, telemarketing, order taking, etc.

[0020] For example, according to the implementation scheme, a customer or other end user who expects to receive services from contact center 100 initiates inbound communication (e.g., telephone call, email, chat, etc.) to be sent to contact center 100 via client device 105. Although Figure 1 Three such client devices, namely client devices 105A, 105B, and 105C, are shown; however, it should be understood that any number of client devices may exist. Each client device in client device 105 can be a conventional communication device in the art, such as a telephone, cordless phone, smartphone, personal computer, tablet computer, or laptop computer, to name only a few non-limiting examples. Typically, client device 105 is used by customers to initiate, manage, and respond to telephone calls, emails, chat, text messages, web browsing sessions, and other multimedia transactions according to any of the functions described herein. For example, a customer can use client device 105 to contact contact center 100 via a chat channel, where text is transmitted to a chatbot or human agent. A response can be generated from the chatbot or human agent and transmitted as text to client device 105.

[0021] Inbound and outbound communications to and from client device 105 can traverse network 110, the nature of which depends on the type of client device and the form of communication used. As an example, network 110 may include communication networks for telephone, cellular, and / or data services, and may also include private or public switched telephone networks (PSTN), local area networks (LANs), private wide area networks (WANs), and / or public wide area networks such as the Internet. Network 110 may also include wireless carrier networks, including Code Division Multiple Access (CDMA) networks, Global System for Mobile Communications (GSM) networks, or any wireless network / technology conventional in the art, including but not limited to 3G, 4G, LTE, etc.

[0022] An implementation of contact center 100 may include a switch / media gateway 115 connected to network 110 to receive and send telephone calls between customers and contact center 100. The switch / media gateway 115 may include a telephone exchange or communications exchange configured to act as a central exchange for agent-level routing within the center. The exchange may be a hardware switching system or a software-implemented softswitch. For example, the switch 115 may include an automatic call distributor, a private branch exchange (PBX), an IP-based software switch, and / or any other switch with dedicated hardware and software configured to receive interactions from the Internet and / or from the telephone network from customers, and to route those interactions to, for example, agent telephones or communications devices. In this example, the switch / media gateway establishes a voice path / connection between the calling customer and the agent telephone equipment, for example, by establishing a connection between the customer's telephone equipment and the agent telephone equipment.

[0023] In one implementation, a switch is coupled to a call controller 120, which, for example, acts as an adapter or interface between the switch and the remainder of the contact center's routing, monitoring, and other communication processing components. The call controller 120 may be configured to handle PSTN calls, VoIP calls, etc. For example, the call controller 120 may be configured with Computer Telephony Integration (CTI) software for engaging with the switch / media gateway and contact center equipment. In one implementation, the call controller 120 may include a Session Initiation Protocol (SIP) server for handling SIP calls. The call controller 120 may also extract data about customer interactions, such as the caller's telephone number (e.g., Automatic Number Identification (ANI) number), the customer's Internet Protocol (IP) address, or email address, and communicate with other components of the call center system 100 while processing interactions.

[0024] An implementation of contact center 100 may include an interactive media response (IMR) server 125. IMR server 125 may also be referred to as a self-service system, virtual assistant, etc. IMR server 125 may be similar to an interactive voice response (IVR) server, except that IMR server 125 is not limited to voice and may additionally cover various media channels. In an example illustrating voice, IMR server 125 may be configured with IMR scripts to query customers for their needs. For example, a bank's contact center may inform a customer via an IMR script to "press 1" if they wish to retrieve their account balance. By continuing to interact with IMR server 125, the customer may be able to complete the service without speaking to the agent. IMR server 125 may also ask open-ended questions such as "How can I help you?", and the customer may state or otherwise enter the reason for contacting the contact center. Routing server 130 may use the customer's response to route the call or communication to the appropriate contact center 100 resource.

[0025] For example, if communication is to be routed to an agent, call controller 120 can interact with routing server (also called orchestration server) 130 to find the appropriate agent to handle the interaction with a specific customer. The selection of the appropriate agent for routing inbound customer interactions can be based on, for example, the routing strategy employed by routing server 130, and further on stored information about customers and agents (which, as described in more detail below, can be maintained in a customer and agent database on storage device 135) and other routing parameters, such as those provided by statistics server 140, which aggregates data related to the performance of call center 100. For example, routing server 130 can query such data via ANI. Therefore, typically, routing server 130 can query data related to an incoming interaction to route that interaction to the most appropriate contact center.

[0026] Regarding data storage, Contact Center 100 may include one or more high-capacity storage devices, typically represented by Storage Device 135, which stores one or more data databases considered relevant to the functionality of Contact Center 100. For example, Storage Device 135 may store customer data maintained in a Customer Database (also CDB) 137. Customer data may include customer profiles, contact information, Service Level Agreements (SLAs), and interaction history (e.g., details of each previous interaction with a customer, including the nature of the previous customer contact, the reason for the interaction, data disposition, wait times, processing times, and actions taken by the Contact Center to resolve customer issues). As another example, Storage Device 135 may store agent data in an Agent Database (also known as an ADB) 138. Agent data may include agent availability, profiles, schedules, skills, etc. More generally, it should be understood that, unless otherwise stated, Storage Device 135 is configured to include databases and / or store data related to any type of information described herein, which may be accessed by other modules or servers of Contact Center 100 in a manner that contributes to the functionality described herein. For example, a server or module of contact center 100 can query a database to retrieve specific data stored therein and transfer the data to the database for storage. Storage device 135 can take the form of a hard disk, a disk array, or any other storage medium conventional in the art. Storage device 135 can be included as part of contact center 100 or operated remotely by a third party. The database can be Cassandra or any NoSQL database. The database can also be an SQL database and managed by any database management system, such as Oracle, IBM DB2, Microsoft SQL Server, Microsoft Access, PostgreSQL, etc., to name just a few non-limiting examples.

[0027] In the implementation, agent device 145 is configured to interact with various components and modules of call center 100 in a manner that facilitates the functions described herein. For example, agent device 145 may include a telephone suitable for regular telephone calls, VoIP calls, etc. Agent device 145 may also include a computer for communicating with one or more servers of contact center 100 and performing data processing associated with contact center operations, as well as for connecting to a customer interface via voice and other multimedia communication mechanisms according to the functions described. Although Figure 1 Three such agent devices are shown, namely agent devices 145A, 145B and 145C, but it should be understood that any number of agent devices may exist.

[0028] Once it is determined that inbound communications should be handled by a human agent, the functionality within the routing server 130 can select an agent from among those available to route the communications. As already discussed, this selection can be based on which agent is best suited to handle the inbound communications. Once a suitable agent is selected, the contact center 100 establishes a connection between the client device 105 and the agent device 145 corresponding to the selected agent. As part of this connection, information about the customer and / or their history can be provided to the selected agent via their agent device 145. This information typically includes data that helps the selected agent better serve the customer.

[0029] According to the implementation scheme, contact center 100 may include a multimedia / social media server 150 for participating in media interactions other than voice interactions with client device 105 and / or web server 155. Media interactions may be related to, for example, email, voicemail (via email), chat, video, text messaging, web, social media, shared browsing, etc. The multimedia / social media server 150 may take the form of any IP router conventional in the art with dedicated hardware and software for receiving, processing, and forwarding multimedia events.

[0030] An implementation of Contact Center 100 may include a knowledge management server 152 to facilitate interaction between a client operating client device 105 and a knowledge system 154. Knowledge system 154 may be included as part of Contact Center 100 or remotely operated by a third party. Generally, knowledge system 154 may be a computer system capable of receiving questions or queries and providing answers as responses. Knowledge system 154 may include an artificial intelligence computer system capable of answering questions posed in natural language, as is known in the art, by retrieving information from sources such as encyclopedias, dictionaries, newsletter articles, literary works, or other documents submitted to knowledge system 154 as reference material. As an example, although other types of systems may also be used, knowledge system 154 may be implemented using IBM... Further details of the knowledge management server and knowledge system are provided in U.S. Application Serial No. 14 / 449,018, entitled “System and Method for Controlled Knowledge System Management,” filed July 31, 2014, the contents of which are incorporated herein by reference.

[0031] According to the implementation scheme, contact center 100 may include chat server 155 for conducting and managing electronic chat communications with customers operating client devices 105. As will be seen, chat communications can be conducted by chat server 155 in a manner whereby the customer communicates with both an automated system, also known as a chatbot, and a human agent, also simply referred to as an agent. According to the implementation scheme, chat server 155 may be configured to implement and maintain chat sessions, generate chat logs, and determine whether chat communications are completed (e.g., based on timeout or by the customer closing the chat window). In the implementation scheme, chat server 155 may also operate as a chat orchestration server, distributing actual chat sessions between chatbots or available human agents. The processing logic of chat server 155 may be rule-driven and utilize, for example, intelligent workload distribution protocols and various business rules to route communications. Chat server 155 may also implement, manage, and facilitate user interfaces (UIs) associated with chat features, including those generated by client device 105 or agent device 145. Furthermore, chat server 155 may orchestrate and implement chats conducted by human agents and automated chatbots. According to the implementation plan, the chat server 155 is configured to transfer chat between automated and human sources within a single chat session with a specific customer, such as transferring the chat session from a chatbot to a human agent or from a human agent to a chatbot.

[0032] Chat server 155 can also connect to knowledge management server 152 and knowledge system 154 to receive suggestions and answers to queries made by customers during automated chat, provide links to knowledge articles, etc. Furthermore, chat server 155 can be configured to facilitate (e.g., monitor and coordinate) the self-learning of certain chatbots. For example, before modifying the characteristics of a single chatbot, chat server 155 can determine whether feedback from customers leading to modifications is suspicious or malicious (e.g., by searching or identifying keywords or phrases, and / or marking potential issues for agent review). Although chat server 155 in... Figure 1 The implementation is described as a standalone server component, but those skilled in the art will recognize that the functionality of the chat server 155 can be incorporated into other servers such as, for example, a multimedia / social media server 150 or an IMR server 125.

[0033] According to the implementation plan, web server 155 may include hosting for various known social networking sites that customers can subscribe to, such as Facebook, Twitter, Instagram, etc., to name just a few non-limiting examples. In this implementation plan, although web server 155 is described as part of contact center 100, web server 155 may also be provided by a third party and / or maintained outside the contact center's premises. Web server 155 may also provide web pages for businesses supported by contact center 100. Customers can browse the web pages and obtain information about the businesses' products and services.

[0034] Web pages can also provide mechanisms for contacting the contact center via, for example, web chat, voice calls, email, Web Real-Time Communication (WebRTC). For example, widgets can be deployed on a website hosted on a web server. As used herein, a widget refers to a user interface component that performs certain specific functions. In some implementations, a widget may include graphical user interface controls that can be overlaid on a web page displayed on the Internet. Widgets may display information in windows or text boxes, and / or include buttons or other controls that allow users to access certain functions, such as sharing or opening files. In some implementations, widgets are user interface components with a generic appearance and portable code that can be installed and executed in a separate web-based page without compilation. Some components may include corresponding and / or additional user interfaces and have access to various resources, such as local resources (e.g., calendars, contact information, etc. on the user's device) and / or remote / network resources (e.g., instant messaging, email, social network updates, etc.).

[0035] Furthermore, the implementation of call center 100 can be configured to manage deferable interactions or activities (also referred to as deferable activities) and route them to human agents for completion. It should be understood that deferable activities include background work that can be performed offline, such as replying to emails, letters, attending training sessions, and other activities that do not require real-time communication with customers. For this purpose, the interaction (iXn) server 160 is configured to interact with the routing server 130 to select an appropriate agent to handle each deferable activity among the deferable activities. Once assigned to a specific agent, the deferable activity is pushed to that agent, for example, appearing on the selected agent's agent device 145. As an example, the deferable activity appears in work area 146 as a task to be completed by the selected agent. The functionality of work area 146 can be implemented via any conventional data structure, such as, for example, a linked list, an array, etc. Each of the agent devices 145 can include work area 146; therefore, work areas 146A, 146B, and 146C can be maintained in agent devices 145A, 145B, and 145C, respectively. As an example, workspace 146 can be stored in the buffer memory of the corresponding agent device 145.

[0036] According to the implementation scheme, contact center 100 may include a general contact server (UCS) 165, which is configured to retrieve information stored in customer database 137 and guide the storage of that information. For example, UCS 165 may be used as part of a chat feature to maintain a history of how chats for a particular customer were handled, which can then be used as a reference for future chat communications. UCS 165 may also be configured to facilitate maintaining a history of customer preferences regarding media channels, such as whether chat communication was acceptable and whether the customer preferred alternative media channels. Furthermore, UCS 165 may be configured to record the interaction history of each customer, capturing and storing data on comments from agents, customer communication history, etc. Each of these data types may be stored on customer database 137 or on other modules required for the described functionality.

[0037] A sample implementation of contact center 100 may further include a reporting server 170 configured to generate reports from data aggregated by statistics server 140. Such reports may include near real-time or historical reports related to resource status (such as average wait times, abandonment rates, agent occupancy, etc.). Reports may be generated automatically or in response to specific requests from requesters (e.g., agents / administrators, contact center applications, etc.).

[0038] According to the implementation plan, Media Service 175 can provide audio and / or video services to support contact center features such as IVR or IMR system prompts (e.g., playback of audio files), hold music, voicemail / one-way recording, multi-way recording (e.g., multi-way recording of audio and / or video calls), speech recognition, dual-tone multi-frequency (DTMF) recognition, fax, audio and video transcoding, Secure Real-Time Transport Protocol (SRTP), audio conferencing, video conferencing, tutorials (e.g., enabling coaches to listen to interactions between customers and agents and enabling coaches to provide comments to agents when customers have not heard the comments), call analytics, and keyword targeting.

[0039] Figure 1 The various components, modules, and / or servers (and other figures included herein) may each include one or more processors that execute computer program instructions and interact with other system components to perform the various functions described herein. The computer program instructions may be stored in memory implemented using standard memory devices such as, for example, random access memory (RAM), or in other non-transitory computer-readable media such as, for example, CD-ROMs, flash drives, etc. Although the functionality of each server is described as being provided by a specific server, those skilled in the art will recognize that the functionality of various servers may be combined or integrated into a single server, or the functionality of a particular server may be distributed across one or more other servers, without departing from the scope of embodiments of the invention. Furthermore, the terms “interaction” and “communication” are used interchangeably and generally refer to any real-time or non-real-time interaction using any communication channel, including but not limited to telephone calls (PSTN or VoIP calls), email, voicemail, video, chat, screen sharing, text messaging, social media messaging, WebRTC calls, etc. Access to and control of components of the contact system 100 can be influenced by a user interface (UI) that may be generated on client device 105 and / or agent device 145. As described above, the contact center 100 can operate as a hybrid system, with some or all of its components remotely hosted, such as in a cloud-based environment. For convenience, aspects of embodiments of the invention can be described herein in relation to providing modular tools from a cloud-based environment to components housed on-site.

[0040] Now go to Figure 2 , Figure 2 Exemplary computing devices that can be used to implement aspects of the present invention are shown. Those skilled in the art will understand that each of the various servers, controls, switches, gateways, engines, and / or modules (collectively, servers) depicted in the described figures can be implemented by hardware or firmware (e.g., ASIC). Each of the various servers can be implemented in one or more computing devices (such as, for example, ASICs). Figure 2A process or thread running on one or more processors in a computing device 200 executes computer program instructions and interacts with other system components to perform the various functions described herein. Those skilled in the art will recognize that a computing device can be implemented via firmware (e.g., an application-specific integrated circuit), hardware or software, or a combination of firmware and hardware. Furthermore, it should be understood that, without departing from the scope of the exemplary embodiments of the invention, the functions of various computing devices can be combined or integrated into a single computing device, or the functions of a particular computing device can be distributed across one or more other computing devices. A server can be a software module, which may also be simply referred to as a module. For example, the modules of contact center 100 may include one or more of the included servers.

[0041] Various servers may be located on on-site computing equipment in the same physical location as the contact center's agents, or they may be located off-site (or in the cloud) in geographically different locations (e.g., in a remote data center) connected to the contact center via a network such as the Internet. Furthermore, some servers may be located on on-site computing equipment at the contact center, while others may be located off-site, or servers providing redundancy may be provided via both on-site and off-site computing equipment to provide greater fault tolerance. In some implementations, functionality provided by servers on off-site computing equipment may be accessed and provided via a Virtual Private Network (VPN) as if such servers were on-site, or functionality may be provided using Software as a Service (SaaS) to provide functionality over the Internet using various protocols, such as exchanging data using data encoded in Extensible Markup Language (XML) or JSON.

[0042] Now for specific reference Figure 2 The diagram provides an exemplary embodiment of a computing device 200 that can be used in embodiments of the present invention. The computing device 200 may include a main processor or CPU 205 and a main memory unit 210. The computing device 200 may also include a storage device 215, a removable media interface 220, and a network interface 225. The computing device 200 may include one or more input / output (I / O) devices 235, which in the illustrated embodiment include an I / O controller 230, a display device 235A, a keyboard 235B, and a pointing device 235C (e.g., a mouse). The storage device 215 may include, but is not limited to, storage for operating systems and software. The computing device 200 may also include additional optional elements such as a memory port 240, a bridge 245, one or more additional input / output devices 235D, 235E, 235F, and a cache memory 250 communicating with the CPU 205.

[0043] CPU 205 is any logic circuit that responds to and processes instructions fetched from main memory unit 210. It may be implemented, for example, as an integrated circuit, as a microprocessor, microcontroller, or graphics processing unit, or as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). Main memory unit 210 may be one or more memory chips capable of storing data and allowing central processing unit 205 direct access to any memory location. Although other configurations are possible, as shown in the example, central processing unit 205 may communicate directly with main memory 210 via memory port 240 and indirectly with storage device 215 via system bus 255.

[0044] In one embodiment, CPU 205 may include multiple processors and may provide functionality for executing multiple instructions simultaneously or for executing an instruction on more than one piece of data simultaneously. In another embodiment, computing device 200 may include a parallel processor having one or more cores. In yet another embodiment, computing device 200 includes a shared-memory parallel device having multiple processors and / or multiple processor cores, thereby accessing all available memory as a single global address space. In yet another embodiment, computing device 200 is a distributed-memory parallel device with multiple processors, each processor accessing only local memory. Computing device 200 may have both a shared type of memory and a type of memory that can be accessed only by a specific processor or subset of processors. CPU 205 may include a multi-core microprocessor that combines two or more independent processors into a single package, for example, into a single integrated circuit (IC). For example, computing device 200 may include at least one CPU 205 and at least one graphics processing unit.

[0045] In one implementation, CPU 205 provides Single Instruction Multiple Data (SIMD) functionality, for example, executing a single instruction on multiple data lines simultaneously. In another implementation, several processors within CPU 205 may provide functionality for executing multiple instructions on multiple data lines simultaneously (MIMD). CPU 205 may also use any combination of SIMD cores and MIMD cores in a single device.

[0046] Figure 2An embodiment in which the CPU 205 communicates directly with the cache memory 250 via a second bus (sometimes referred to as the back-side bus) is depicted. In other embodiments, the CPU 205 communicates with the cache memory 250 using the system bus 255. The cache memory 250 typically has a faster response time than the main memory 210. As shown, the CPU 205 communicates with various I / O devices 235 via the local system bus 255. According to conventional techniques, various buses can be used as the local system bus 255. For an embodiment where the I / O device is a display device 235A, the CPU 205 communicates with the display device 235A via the Advanced Graphics Port (AGP). As further shown, the CPU 205 can communicate directly with the I / O device 235F. Although other configurations are also possible, Figure 2 The following implementation is described: local bus and direct communication are mixed: CPU 205 communicates directly with I / O device 235, while also communicating with other I / O devices 235 via local system bus 255.

[0047] A wide variety of I / O devices 235 may be present in computing device 200. Input devices include one or more keyboards 235, mice, touchpads, trackballs, microphones, and plotters, to name just a few non-limiting examples. Output devices include video display devices, speakers, and printers. I / O controller 230 may be used to control one or more I / O devices, such as, for example, keyboard 235B and pointing devices 235C (e.g., mouse or light pen).

[0048] As shown in the figure, computing device 200 may support one or more removable media interfaces 220, such as floppy disk drives, CD-ROM drives, DVD-ROM drives, tape drives of various formats, USB ports, secure digital or compact FLASH memory. TM A memory card port, or any other device suitable for reading data from or writing data to a read-only medium or a read-write medium. The removable media interface 220 can, for example, be used for installing software and programs. The computing device 200 may also include storage devices 215, such as one or more hard disk drives or hard disk drive arrays, for storing the operating system and other related software, as well as for storing application software programs. Optionally, the removable media interface 220 may also be used as a storage device. For example, the operating system and software may run from a bootable medium (e.g., a bootable CD).

[0049] In implementations, computing device 200 may include or be connected to multiple display devices 235A. Therefore, either I / O device 235 and / or I / O controller 230 may include any type and / or form of suitable hardware, software, or a combination of hardware and software to support, enable, or provide computing device 200 with connectivity to and use of multiple display devices 235A. For example, computing device 200 may include any type and / or form of video adapters, video cards, drivers, and / or libraries for engaging, communicating, connecting, or otherwise using multiple display devices 235A. In implementations, video adapters may include multiple connectors for engaging to multiple display devices 235A. In another implementation, computing device 200 may include multiple video adapters, each connected to one or more display devices of display device 235A. In other implementations, one or more display devices of display device 235A may be provided by one or more other computing devices connected via a network to, for example, computing device 200. These implementations may include any type of software designed and configured to use the display device of another computing device as a second display device 235A of computing device 200. Those skilled in the art will recognize and understand that the computing device 200 can be configured in various ways and implementations to have multiple display devices 235A.

[0050] exist Figure 2 The computing device 200, generally indicated in the embodiments, can operate under the control of an operating system that controls task scheduling and access to system resources. The computing device 200 can run any operating system, any embedded operating system, any real-time operating system, any open-source operating system, any proprietary operating system, any operating system for mobile computing devices, or any other operating system capable of running on a computing device and performing the operations described herein. The computing device 200 can be any workstation, desktop computer, laptop or notebook computer, server machine, handheld computer, mobile phone or other portable telecommunications device, media playback device, gaming system, mobile computing device, or any other type and / or form of computing, telecommunications, or media device capable of communication and having sufficient processor power and memory capacity to perform the operations described herein. In embodiments, the computing device 200 can have a different processor, operating system, and input devices consistent with the device. In other embodiments, the computing device 200 is a mobile device. Examples may include a Java-enabled cellular phone or personal digital assistant (PDA), smartphone, digital audio player, or portable media player. In embodiments, the computing device 200 includes combinations of devices, such as a mobile phone combined with a digital audio player or portable media player.

[0051] Computing device 200 may be one of a plurality of machines connected by a network, or it may include a plurality of machines so connected. The network environment may include one or more local machines, clients, client nodes, client machines, client computers, client devices, endpoints, or endpoint nodes that communicate with one or more remote machines (which may also be referred to as server machines or remote machines) via one or more networks. In one embodiment, the local machine has the capability to act as a client node seeking access to resources provided by the server machine, and as a server machine to provide access to hosted resources as other clients. The network may be a LAN or WAN link, a broadband connection, a wireless connection, or any or a combination of the foregoing. Various communication protocols may be used to establish connections. In one embodiment, computing device 200 communicates with other computing devices 200 via any type and / or form of gateway or tunneling protocol (such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS)). The network interface may include a built-in network adapter (such as a network interface card) adapted to connect the computing device to any type of network capable of communicating and performing the operations described herein. I / O devices may be bridges between system buses and external communication buses.

[0052] In one implementation, the network environment can be a virtual network environment in which various components of the network are virtualized. For example, various machines can be virtual machines implemented as software-based computers running on physical machines. Virtual machines can share the same operating system. In other implementations, different operating systems can run on each virtual machine instance. In one implementation, a "hypervisor" type of virtualization is implemented, where multiple virtual machines run on the same host physical machine, each acting as if it had its own dedicated box. Virtual machines can also run on different host physical machines. Other types of virtualization are also envisioned, such as networking (e.g., via Software-Defined Networking (SDN)). Functions (such as session boundary controller functions and other types of functions) can also be virtualized, such as via Network Functions Virtualization (NFV).

[0053] Turn Figure 3 and Figure 4 For background art purposes, exemplary specific implementations of chat servers and chatbots are presented. As those skilled in the art will understand, regarding... Figure 3 and Figure 4 The described systems and methods can be used or modified for embodiments of the present invention. For example, such modifications may include, as will be apparent to those skilled in the art, certain aspects of implementing the system via a cloud or serverless architecture—related to… Figures 5 to 8 The described system and its functions are consistent.

[0054] Now for specific reference Figure 3 A more detailed schematic diagram of chat server 155 is provided. As mentioned above, Figure 3 Provided for background art purposes and as an exemplary specific implementation of a chat server. As will be understood by those skilled in the art, such as regarding Figures 5 to 8 The provided aspects of chat server 155 can be used or modified for implementation of the present invention. As already described, chat server 155 can be connected via data communication network 110 to (e.g., electrical communication) a client device 105 operated by a client. Chat server 155 can be used by a company or enterprise as a contact center 100 (e.g., Figure 1 As part of a system, the chat server 155 operates to implement and organize various aspects of chat sessions with company clients, including both automated chat and chat with human agents. Regarding automated chat, the chat server 155 may host one or more chat automation modules or chatbots 205A to 205C (collectively referred to as 205), which are configured with computer program instructions for participating in automated chat sessions. Therefore, typically, the chat server 155 implements chat functionality, including text-based exchange or chat communication between client device 105 and agent device 145, and between client device 105 and chatbot 260. As will be discussed in more detail below, the chat server 155 may include a client interface module 265 and an agent interface module 266 for generating specific user interfaces included in the chat functionality at client device 105 and agent device 145, respectively.

[0055] Chatbot 205 can operate, for example, as an executable program that can be launched as needed for a specific chatbot. According to an implementation, chat server 155 can operate as the execution engine or environment for chatbot 205, similar to loading a VoiceXML file onto a media server for interactive voice response (IVR) functionality. Loading and unloading can be controlled by chat server 155, similar to how VoiceXML scripts are controlled in an IVR environment. Chat server 155 can provide a means of capturing and collecting user data in a unified manner, similar to capturing user data in an IVR environment. Such data can be stored (e.g., in a CMR database), shared, and used in subsequent session steps, whether with the same chatbot, different chatbots, agent chat, or even different media types. According to an implementation, chat server 155 is configured to orchestrate data sharing between various chatbots 205 when interaction shifts from one chatbot to another or from one chatbot to a human agent. According to an implementation, data captured during interaction with a specific chatbot can be transmitted along with a request to invoke a second chatbot or a human agent.

[0056] In the implementation scheme, the number of chatbots 205 can vary depending on the design and functionality of the chat server 155, and is not limited to... Figure 3The number shown. For example, different chatbots can be created with different profiles. A specific chatbot profile can be used to select a chatbot with expertise that helps customers control specific topics, such as how the chatbot communicates with a particular customer. Using profiles tailored to specific types of customers may allow for more effective communication with these users. For example, one chatbot might be designed or specialized for a first communication topic (e.g., opening a new account in Enterprise 104), while another chatbot might be designed or specialized for a second communication topic (e.g., providing technical support for products or services offered by Enterprise 104), which differs from the first communication topic. In another example, chatbots can be configured to utilize different dialects or slang, or can have different personality traits or characteristics. For example, the vocabulary of different chatbots can be customized to use slang or terminology from young people, older people, people from specific countries or regions, and / or people with specific language or ethnic backgrounds. Chat server 155 can also host a default chatbot, which can be invoked at the start of a chat session if there is insufficient information about the customer to invoke a more specialized chatbot. For example, if the customer's intent is unknown at the start of the conversation, a default chatbot can be invoked to ask questions about the customer's intent. According to the implementation, the chatbot can be selectable by the customer through a user interface, based on factors such as accent, appearance, age group, and language. Furthermore, the chatbot can be assigned to a customer based on their demographic information. According to the implementation, the chatbot profile can be selected based on information obtained from publicly available information about the customer (e.g., social media information).

[0057] According to the implementation plan, the profile of chatbot 260 can be stored in a profile database hosted on storage device 135. The chatbot profile data may include, but is not limited to, the chatbot's personality, gender, demographics, and area of ​​expertise. According to the implementation plan, for a given topic, including reception and concierge services, and experts on specific products or services (e.g., travel booking, account opening, etc.), there may be several different chatbots 205, each with its own personality or profile.

[0058] Each of the different chatbots 205 can be configured, together with chat server 155, to learn and evolve their behavior and responses based on customer input. For example, in response to a user's negative reaction to certain words, phrases, or responses, chatbot 205 can learn to use different words, phrases, or responses. Such learning can be supervised to prevent undesirable evolution of the chatbot 205's personality or profile. For example, changes to the chatbot 205's personality or profile can be approved or verified by a human administrator first, certain keywords or phrases can be identified or labeled, and customer feedback can be analyzed. According to the implementation, in addition to learning based on customer or agent feedback, the different chatbots 205 can be configured to learn from each other. For example, the different chatbots 205 can be configured to communicate and exchange data with each other. In the implementation, by exchanging data with each other, the different chatbots 205 can operate as neural networks for deep learning and self-learning capabilities.

[0059] As described above, chat server 155 may include a client interface module 265 and an agent interface module 266. As described in more detail below, client interface module 265 may be configured to generate a user interface (UI) for display on client device 105, which facilitates chat communication between the client and chatbot 205, and between the client and a human agent. Chat server 155 may include agent interface module 266, which generates a specific UI on agent device 145 that facilitates chat communication between the agent operating agent device 145 and the client operating client device 105. Agent interface module 266 may also generate a UI on agent device 145 that allows the agent to monitor various aspects of the ongoing chat between chatbot 260 and the client. Therefore, client interface module 265 and agent interface module 266 can operate to facilitate the exchange of chat communication between client device 105 and one of chatbot 205 and / or agent device 145. For example, the client interface module 265 can send a signal to the client device 105 during a chat session, the signal being configured to generate a specific UI on the client device 105. As will be seen, those UIs generated on the client device 105 may include text messages sent from the chatbot 205 or a human agent, as well as other non-text graphics, such as emoticons or animations, intended to accompany the text messages for display alongside them. Similarly, the agent interface module 266 can send a signal to the agent device 145 during a chat session, the signal being configured to generate a specific UI on the agent device 145. As will be seen, those UIs generated on the agent device 145 may include text messages sent from the client device 105. The UI generated on the agent device 145 may also include an interface that helps the agent select non-text graphics that will accompany the text messages sent to the client.

[0060] According to the implementation plan, the chat server 155 can be implemented in a layered architecture, in which the media layer, media control layer and chatbot are executed through the IMR server 125 (similar to executing VoiceXML on an IVR media server).

[0061] like Figure 1 As shown, chat server 155 can also be configured to interact with knowledge management server 152 to query knowledge information from the server. Queries may be based, for example, on questions received from the client during the chat. The response received from knowledge management server 152 can then be provided to the client as part of the chat response.

[0062] According to the implementation plan, chat server 155 can communicate with... Figure 1The contact center 100 shown runs on the same computer as the other servers. Chat server 155 can also run on a computer equipped with a processor or central processing unit (CPU) (such as...). Figure 2 The chat server 155 operates on a standalone computer (as shown) that executes program instructions and interacts with other system components to perform various methods and operations according to embodiments of the invention. The chat server 155 may also run on a cloud or serverless architecture. The chat server 155 may include memory that operates as an addressable memory unit for storing software instructions to be executed by a central processing unit. The memory may be implemented using any suitable memory device such as random access memory (RAM) and may additionally operate as a computer-readable storage medium in which non-transitory computer-readable instructions are stored, which, when executed by the processor, cause the processor to control and manage automated chat communication between the chat server 155, client device 105, and / or agent device 145.

[0063] Now for specific reference Figure 4 A more detailed block diagram of an exemplary chat automation module or chatbot 260 is provided. As mentioned above, Figure 4 Provided for background art purposes and as an exemplary embodiment of a chatbot. As those skilled in the art will understand, aspects of chatbot 260 can be used or modified for implementations of the present invention. In the illustrated embodiment, chatbot 260 includes a text analysis module 270, a dialogue manager 272, and an output generator 274. The text analysis module is configured to analyze and understand natural language. In this regard, the text analysis module may be configured with a language dictionary, a syntax / semantic parser, and grammar rules for decomposing phrases provided by client device 105 into internal syntactic and semantic representations. According to the embodiment, the configuration of the text analysis module depends on the specific profile associated with the chatbot. For example, certain slang terms may be included in the dictionary of one chatbot but not in the dictionary of another.

[0064] In operation, the dialogue manager 272 receives syntactic and semantic representations from the text analysis module 270 and manages the general flow of the session based on a set of decision rules. At this point, the dialogue manager 272 maintains the history and state of the session and generates outbound communications based on this history and state. Communications may follow a script for a specific session path selected by the dialogue manager 272. As described in further detail below, the session path may be selected based on an understanding of the specific purpose or topic of the session. The script for the session path can be generated using any of a variety of languages ​​and frameworks common in the art, such as, for example, Artificial Intelligence Markup Language (AIML), SCXML, etc.

[0065] During a chat session, the dialogue manager 272 selects responses deemed appropriate at specific points in the conversation flow / script and outputs the responses to the output generator 274. According to an implementation, the dialogue manager 272 can also be configured to calculate the confidence level of the selected responses and provide that confidence level to the agent device 145. According to an implementation, each segment, step, or input in the chat communication can have a corresponding list of possible responses. Responses can be categorized based on topics (determined using appropriate text analysis and topic detection schemes) and suggested next actions can be assigned. Actions can include, for example, responses with answers, additional questions, transfer to a human agent for assistance (e.g., by explicitly addressing the input from the customer), etc. Confidence levels can be used to help the system determine whether the detection, analysis, and response to customer input are appropriate, suitable, or whether a human agent should be involved. For example, a threshold confidence level can be assigned based on one or more business rules to invoke human agent intervention. According to an implementation, confidence levels can be determined based on customer feedback. For example, confidence levels can be decreased in response to detecting a negative reaction from a customer to an action or response taken by the chatbot. Conversely, confidence levels can be increased in response to detecting a positive reaction from a customer.

[0066] According to the implementation scheme, the response selected by the dialogue manager 272 may include information provided by the knowledge management server 152. For example, this information may be a link to a knowledge article that the chatbot might want to recommend to the customer in response to a customer's question.

[0067] In one implementation, output generator 274 uses a semantic representation of the response provided by dialogue manager 272 to map the response to a chatbot profile or personality (e.g., by adjusting the language of the response according to the chatbot's dialect, vocabulary, or personality) and outputs outbound text to be displayed at client device 105. The output text may be intentionally presented so that the client interacting with the chatbot is unaware that they are interacting with an automated process rather than a human agent. As will be seen, according to other implementations, the output text may be linked to visual representations (such as emoticons or animations) integrated into the client's user interface.

[0068] In reference Figures 5 to 8 Before continuing with the description of the invention, an explanatory description will be provided regarding the reference system components already described in the preceding figures, such as modules, servers, components, and other systems. As will be understood by those skilled in the art, regardless of whether subsequent references include… Figures 1 to 4 The corresponding reference numerals in the accompanying drawings should be understood to incorporate the examples discussed above, and unless specifically limited, can be implemented based on those examples and / or other conventional techniques capable of achieving the desired functionality. Therefore, for example, the term "contact center" mentioned subsequently should be understood to refer to...Figure 1 The exemplary “Contact Center 100” and / or other conventional technologies used to implement a contact center. As an additional example, subsequent references to “client device,” “storage device,” “agent device,” “chat server,” “computing device,” “chatbot,” or “client interface module” should be understood as referring to respectively Figures 1 to 4 Exemplary “client device 105”, “storage device 135”, “agent device 145”, “chat server 155”, “computing device 200”, “chatbot 260” or “client interface module 265”, and conventional technologies for achieving the same functionality.

[0069] Now for reference Figure 5 An exemplary system configuration is provided, illustrating an environment in which a robot gateway 400 can be used according to an embodiment of the invention. According to one possible arrangement, the robot gateway 400 is configured to facilitate communication between one or more users or clients (via the illustrated client device 105) and one or more robots 405, which are also commonly referred to as automated processes, web robots, or internet robots. As used herein, a robot is a software application that runs automated tasks or scripts over the internet, for example, performing simple and structurally repetitive tasks at a rate higher than that possible for humans. According to a preferred embodiment, the robot 405 of the invention includes a chatbot, such as the chatbot 260 discussed above. As used herein, a chatbot is defined as software that engages in conversation via auditory or textual methods. It should be understood that chatbots are generally designed to convincingly mimic human behavior as a conversational partner. Chatbots are commonly used in dialogue systems for a variety of practical purposes, including customer service or information gathering. Some chatbots use sophisticated natural language processing systems, but many simpler chatbots scan for keywords in the input and then extract responses from a database with the most matching keywords or the most similar wording patterns. Chatbots can be categorized by use, such as conversational commerce (e-commerce via chat), analytics, communication, customer support, social networking, and travel.

[0070] Although other types of specific implementations are also possible, such as Figure 5 As shown, the robot gateway 400 can be implemented using a serverless architecture in which one or more cloud components (e.g., cloud database 430, cloud cache 435, and cloud computing functions 440, which will be discussed in more detail below) are maintained and executed in the cloud, i.e., maintained and executed in a cloud computing platform, or, as used herein, maintained and executed in a cloud platform 450.

[0071] In the example shown, software program 455 may be commercially provided to several enterprises, or, as used herein, to tenant 460. Although not intended to be limiting unless otherwise stated, the term "tenant" is used because software program 455 may be provided to a tenant in a multi-tenant arrangement. In such an arrangement, tenant 460 will access and thereby use software program 455 via a connection on network 110. In a preferred embodiment, software program 455 may be a program for managing interactions between an enterprise or tenant 460 and corresponding users or customers. For example, software program 455 may relate to the realm of customer relationship management and / or include aspects related to the operational management of a call or contact center, such as those described above. Figure 1 The discussion focuses on an example contact center. Therefore, typically, software programs 455 can be configured to facilitate certain interactions or services between businesses or tenants 460 and their respective customers. (As will be combined...) Figure 6 In more detail, one feature included in software program 455 may be a chat feature having a user interface generated on the screen of client device 105 that facilitates the client's input of characters or text. This functionality can allow the client to prepare and send text messages intended to be delivered to robot 405. While other types of specific implementations are also possible, the chat feature could be implemented by an interactive widget that generates the chat user interface within a predefined area of ​​the tenant-initiated webpage being viewed on client device 105.

[0072] exist Figure 5 In the exemplary scenario shown, each tenant 460 of software application 455 can have permissions for one or more robots 405, which in Figure 5 The dashed lines representing robots 405 connected to their respective tenants 460 are used to represent this. Such robots 405 may include local robots developed by tenant 460, third-party robots developed by robot providers for tenant 460, robots built by partners, etc. Tenant 460 may wish to make such robots available to its customers, preferably by integrating them and making them available within the tenant's customer relationship platform. Figure 5 In this context, the customer relationship platform is represented by software program 455. However, in a conventional system, this would require considerable integration and maintenance costs. From tenant 460's perspective, it would be ideal if a robot orchestration service were available to flexibly utilize such robots at a high level without requiring specific robot provider knowledge. It should be understood that if such a service were available, tenants' resources could be utilized more fully while still avoiding costly integration and maintenance work.

[0073] To address this issue, the robot gateway 400 of this invention provides a unified interface for accessing different robots from various robot providers. Typically, the robot gateway 400 harmonizes the differences between robots and robot providers while also supporting specific feature sets that ideally make different robots and robot providers unique. As will be seen, the robot gateway 400 achieves this in a way that can be efficiently maintained. While conventional systems require API updates and complex integrations whenever a robot provider adds a new feature or makes API changes to their robots, the robot gateway 400 is configured to make these unnecessary. As discussed in detail below, the robot gateway 400 achieves this by defining the implementation environment according to a schema that describes how to communicate with different robots. By providing this level of indirection, the specific implementation environment can be abstracted into JSON-compliant schema objects applicable to robot, session, management, or query (intent, entity, environment) use cases. Furthermore, the robot gateway 400 of this invention does not require code changes to add new robot providers. Instead, the robot gateway 400 can be implemented using a REST-based schema approach for seamless integration with partners, customers, suppliers, or robot providers. Understandably, for customer relationship platforms focused on delivering the omnichannel customer journey (where text-based interactions occur across multiple channels), the ability to naturally orchestrate bot flows in queues, workgroups, or other such mechanisms represents a significant operational advantage. The Bot Gateway 400 provides this type of functionality, thereby eliminating limitations that hinder the effective integration of bots into the customer experience.

[0074] One way to achieve this is by implementing a serverless robot gateway. Specifically, such as... Figure 5 As shown, the robot gateway 400 can be implemented by one or more components (also referred to as cloud components) that are maintained and executed in the cloud (i.e., cloud platform 450). As used herein, a serverless architecture is defined as a computational execution model in which the service provider of the cloud platform dynamically manages the allocation and provisioning of remote servers to achieve desired functionality. It should be understood that a “serverless” cloud platform can dynamically manage the allocation of computing resources, but servers are still required. In the example implementation, the cloud component of the robot gateway 400 may include one or more cloud databases 430, which, as discussed in more detail below, can be used to persistently store robot patterns and robot configuration datasets. The cloud component of the robot gateway 400 may also include one or more cloud caches 435. As discussed in more detail below, the cloud cache 435 can be used to temporarily store session state data for use when executing logical functions within a session. The cloud component may also include one or more cloud computing functions 440 for stateless execution of the logic associated with the implementation provided herein, particularly… Figure 7and 8 The methods described in [the document].

[0075] Now, a brief reference will be provided. Figure 6 The illustration shows an exemplary webpage 500 with chat feature 505. For example, webpage 500 may be associated with a tenant's company or enterprise website to initiate interaction between potential or current customers accessing the webpage and a contact center associated with the enterprise. As shown, chat feature 505 may be included within the definition section of webpage 500 and may be implemented as a widget or application, for example, via the aforementioned systems and components and / or any other conventional means. As will be understood, chat feature 505 includes an exemplary manner in which a user or customer inputs a text message, which the bot gateway 400 formats and passes to various bots, which will then combine... Figure 7 and Figure 8 Let's discuss this in more detail.

[0076] As an example, webpage 500 can be accessed by a client via a client device that provides a communication channel for interacting with the bot, chatting with the chatbot, etc. In an implementation, as shown, chat feature 505 includes an interface generated on the screen of a client device such as client device 105. This user interface of chat feature 505 may be referred to herein as client chat interface 510. As already described, client chat interface 510 may, for example, be generated by a client interface module of a chat server. The client interface module may send a signal to the client device configured to generate the desired client chat interface 510 based on the content of chat messages sent by a chatbot named "Kate," as shown. Client chat interface 510 may be contained within a designated area or window that covers a designated portion of webpage 500. Client chat interface 510 may also consist of a text display area 515 dedicated to displaying received and sent text messages, and a text input area 520 for the client to input text messages. While this can be achieved in other ways, Figure 6 The chat interface demonstrates a method by which text messages can be entered by the client and directed to the robot gateway 400.

[0077] The discussion will now focus on how to properly format customer text messages within the robot gateway once received, so that they can be ultimately delivered to the robot. According to an example implementation, the invention may initially include providing a robot gateway, such as the robot gateway 400 discussed above. As mentioned above, the robot gateway of the present invention can be built on a serverless or cloud platform. For example, this can be achieved using cloud platforms offered under trade names such as Amazon Web Services or Google.

[0078] According to the example implementation, the robot gateway 400 can store or access data related to robot patterns. As used herein, a robot pattern defines the arrangement of data fields based on a unique template used to send a request to a specific robot. That is, a robot pattern includes a template that defines how the robot gateway communicates with different robots. In the example implementation, the data associated with the robot pattern can be persistently stored in the cloud, for example, stored in [location missing]. Figure 5 The cloud database 430 is used. According to an exemplary implementation, multiple robot patterns can be deployed in a robot pattern library stored in the cloud. For example, in practice, the robot pattern library can be stored in a database with the trade name DynamoDB. In use, as will be seen, robot patterns can be used to dynamically generate request templates based on the specific deployment required by each robot, and to support synchronous responses from those robots.

[0079] According to the example implementation, the robot gateway can further store or access robot configuration datasets. Each robot configuration dataset in the robot configuration dataset can include data values ​​that relate to a corresponding usage that pairs a specific robot with a specific tenant. Therefore, according to the example implementation, the robot configuration dataset can include tenant-based information relating to identifying a specific tenant in relation to a request directed to a specific robot. For example, a robot provider can use the robot configuration dataset to authenticate a tenant's use of a specific robot. In the example implementation, the data associated with the robot configuration dataset can be persistently stored in the cloud. For example, multiple robot configuration datasets can be arranged in a robot configuration library, which is stored in the cloud, for example, stored in... Figure 5 Within the cloud database 430. For example, similar to the robot pattern library, the robot configuration library can be stored in a database with the trade name DynamoDB. In an alternative implementation, the robot configuration dataset can be provided to the robot gateway in a manner that does not require storage and retrieval in the cloud database. For example, data associated with the robot configuration dataset can be appended to a customer message and provided to the robot gateway along with the customer message.

[0080] The robot gateway may also include session state data, which can be used by the robot / robot provider during the session to determine the next action. In an example implementation, such session state data is temporarily stored in a cache. For example, the cache may be maintained in the cloud, for example, […]. Figure 5 The cloud cache 435. For example, in practice, embodiments of the present invention may use a cache with the trade name Redis.

[0081] Robot gateways can also include cloud computing capabilities, such as... Figure 5 The cloud computing functionality 440 is used for stateless execution of logic associated with the methods and processes of the present invention. According to an exemplary embodiment, the robot gateway can be configured as a sum of cloud computing functions orchestrated as a “state machine.” For example, a cloud computing function with the trade name AWS Lambda Function can be used. In such a case, the AWS Lambda Function can be orchestrated into this “state machine” via an AWS step function workflow. According to an embodiment, such a workflow can be triggered by monitoring a data stream or event bus related to robot-related events. As an example, a data stream with the trade name “Kinesis” can be monitored for robot-related events such as customer messages, and this robot-related event then activates the robot gateway workflow.

[0082] In an example implementation, the invention also includes the use of a robot gateway 400 in the process of formatting customer messages for delivery to a robot. An example of one of these processes may include the following steps.

[0083] First, a message from a customer can be received by the robot gateway; for this example, this message will be referred to as the first message. As described above, according to the example implementation, the step of receiving the first message may include monitoring an event bus or data stream to detect the first message therein, thereby triggering the reception of the first message. Other conventional methods and systems can also be used by the robot gateway to receive the first message.

[0084] Second, the received first message can be analyzed to determine the recipient, relevant party, or related party, as well as other information. For example, relative to the first message, this step may include: identifying a relevant customer among customers, i.e., who the first message originated from (hereinafter referred to as the "first customer"); a relevant tenant among tenants, i.e., which tenant is the customer's first customer (hereinafter referred to as the "first tenant"); and / or a relevant robot among robots, i.e., the robot to which the first message is addressed (hereinafter referred to as the "first robot"). This step may also include identifying any text messages included in the first message. It is understood that the text message is the actual text entered by the first customer, intended to be delivered to the first robot.

[0085] Third, a robot configuration dataset can be provided. As mentioned above, the robot configuration dataset can include data values ​​related to the usage scenario of pairing a first tenant with a first robot. According to an example implementation, the data values ​​stored in the robot configuration dataset include data values ​​used to authenticate the use of a specific robot by a particular tenant (or, more specifically, the use of a specific robot by a particular tenant's customer). Thus, as used herein, the term "usage scenario" refers to a particular tenant-robot pairing where the data values ​​in the robot configuration dataset are used to authenticate and allow the desired usage to occur. For example, the data values ​​in the robot configuration dataset can be used to authenticate the use of the first robot by a first customer based on the relationship between the first customer and the first tenant (e.g., customer relationship). In the case of providing a robot configuration library, the step of providing a robot configuration dataset can include selecting an appropriate robot configuration dataset from the robot configuration library. It is understood that this selection can be based on the relevance or correlation between the robot configuration dataset and the specific usage scenario of pairing the first tenant with the first robot.

[0086] Fourth, the first robot pattern (hereinafter referred to as the "first robot pattern") belonging to the first robot can be selected from the robot pattern library. As mentioned above, each robot pattern in the robot pattern library can define the data field layout based on a unique template used to send a request to a specific robot. Therefore, in this example, the first robot pattern can define the data field layout based on the template used to send a request to the first robot. It is understood that these types of templates can be defined by different robot providers.

[0087] Fifth, a formatted request can be created by mapping text messages (i.e., text messages entered by the customer) and data values ​​defined in the robot configuration dataset to corresponding data fields defined in the data field layout of the first robot mode. An example of how to accomplish this step is in... Figure 7 The formatting progress shown is best illustrated in the diagram.

[0088] Sixth, once the customer message is correctly formatted, the formatted request can be sent to the first robot.

[0089] Now for specific reference Figure 7 and Figure 8 It provides concrete examples to illustrate how the above methods can be implemented in practice. It is understandable that... Figure 7 Includes example formatting progress 600, which shows how a customer message is formatted before being sent to a specific bot. Figure 8 Includes a flowchart describing an example method 700 that can be used to accomplish this operation.

[0090] about Figure 7 It provides a sample formatting progress 600, which shows how a customer's message progresses from a text message to a formatted request that can be successfully sent to a specific bot. This will be understood. Figure 7 This includes three such progress snapshots: the first progress snapshot 600A, the second progress snapshot 600B, and the third progress snapshot 600C. As noted in each progress, the formatted request typically consists of two main parts: an endpoint section and a body section.

[0091] As shown in the figure, the first progress snapshot 600A reflects the initial stage of formatting a customer message by the robot gateway. As indicated by several question marks, much of the required data is unknown upon initial receipt. More specifically, in this initial stage, both the endpoint portion and the body portion contain unknowns.

[0092] As shown in the figure, the second progress snapshot 600B reflects a customer message further progressing in the formatting process. In this snapshot, the message has been formatted according to the selected robot pattern. Therefore, data fields have been identified and named in the data field layout defined by the robot pattern. However, the actual data values ​​for these data fields (e.g., possibly from the robot configuration dataset) are still empty. Also as shown, the robot pattern can include templates for formatting endpoint statements for use in the endpoint section of the message. It should be understood that endpoint statements provide a way to direct the formatting request to the intended robot's destination. However, at this stage of formatting, the actual data values ​​in the statement are still empty. It will be understood that the data values ​​stored in the robot configuration dataset can include data values ​​used to insert or complete endpoint statements.

[0093] Finally, the third progress snapshot 600C reflects the fully formatted request, where data values ​​from the appropriate robot configuration dataset and text message have been mapped to the corresponding data fields in the robot pattern. At this point, the data field layout defined by the robot pattern has been populated with the appropriate data values ​​found in the robot configuration dataset. Furthermore, as shown, the text in the customer message has been mapped to the corresponding data fields defined in the body section.

[0094] like Figure 8 As shown, a method 700 is proposed according to the present invention. Method 700 may include an initial step 705, in which a client inputs a message for the robot. At step 710, the robot gateway may receive the message. As mentioned above, at this point, the message may have an unknown endpoint and an unknown subject value.

[0095] At step 715, the robot gateway can identify a specific robot pattern used when constructing a request template for a message. Then, in step 720, using that specific robot pattern, the robot gateway can populate the attribute names of data fields based on the request template defined by the robot pattern.

[0096] At step 725, the robot gateway identifies robot configuration data and the customer's text message to map to the appropriate data fields for the attribute names of a given request template. Then, at step 730, the robot gateway populates the request template by mapping the robot configuration data and text message to the appropriate data fields. Now that the request template has been constructed and the data fields populated, at step 735, the robot gateway sends the correctly formatted request to the intended robot.

[0097] While the invention has been shown and described in detail in the accompanying drawings and the foregoing description, it should be considered exemplary rather than restrictive. It should be understood that only preferred embodiments have been shown and described, and protection is intended for all equivalents, changes, and modifications falling within the spirit of the invention as set forth herein and / or as described in the appended claims. Therefore, the appropriate scope of the invention should be determined only by the broadest interpretation of the appended claims in order to cover all such modifications and relationships equivalent to those shown in the drawings and described in the specification.

Claims

1. A processor-implemented method that facilitates passing messages from customers to bots, wherein tenants use a software program to manage interactions with respective ones of the customers over a network, the method comprising the steps of: providing a bot gateway, wherein: the bot gateway comprises a bot schema library, wherein a plurality of bot schemas are stored in the bot schema library; and each of the plurality of bot schemas defines a data field arrangement according to a unique template for sending requests to a particular one of the bots, the data field arrangement comprising an endpoint portion and a body portion; the bot gateway is implemented based on a serverless architecture, wherein one or more cloud components are maintained and executed within a cloud platform, the cloud components comprising: a cloud compute function for stateless execution of logic associated with a process; a cloud database configured to persistently store the bot schema library and a bot configuration library; and formatting the messages for passing to the bots using the bot gateway according to a process, the process comprising the steps of: receiving a first one of the messages, hereinafter "first message"; analyzing the first message to determine therefrom: a relevant one of the customers, hereinafter "first customer"; a relevant one of the tenants, hereinafter "first tenant"; a relevant one of the bots, hereinafter "first bot"; and a text message from the first customer that is intended to be passed to the first bot; providing a bot configuration data set comprising data values that are relevant to a use case that pairs the first tenant with the first bot and that are used to authenticate access rights of the first customer to the first bot; selecting a first one of the plurality of bot schemas belonging to the first bot from the bot schema library, hereinafter "first bot schema"; creating a formatted request via mapping the text message and the data values defined in the bot configuration data set to corresponding data fields defined in the data field arrangement of the first bot schema, wherein the formatted request comprises: an endpoint portion containing a destination identifier for directing the first bot; a body portion mapping the text message to content fields defined in the data field arrangement; and sending the formatted request to the first bot.

2. The method of claim 1, wherein the software program is provided to the tenants according to a multi-tenant arrangement, and wherein the software program is involved in customer relationship management via managing operational aspects of a contact center; the feature comprises a user interface that facilitates the first customer entering the text message of the first message; wherein the first bot comprises a chat bot. wherein the software program comprises features, ​ ​ 3. The method of claim 1, wherein the robot gateway comprises a robot configuration library that stores robot configuration data sets, each of the robot configuration data sets comprising data values that are relevant to respective use cases that pair a particular one of the robots with a particular one of the tenants; wherein the step of providing the robot configuration data set comprises selecting the robot configuration data set from the robot configuration library based on the robot configuration data set’s relevance to the use case that pairs the first tenant with the first robot.

4. The method of claim 1, wherein the step of providing the robot configuration data set comprises receiving the robot configuration data set as part of the first message.

5. The method of claim 1, wherein the robot gateway comprises a serverless architecture in which one or more cloud components are maintained and executed within a cloud platform.

6. The method of claim 5, wherein the one or more cloud components comprise a first cloud component that comprises one or more cloud computing functions for stateless execution of logic associated with the process.

7. The method of claim 6, wherein the robot gateway comprises a second cloud component that comprises one or more cloud databases; wherein the one or more cloud databases are configured to persistently store the robot schema library; and wherein the first robot comprises a chatbot.

8. The method of claim 7, wherein the robot gateway comprises a robot configuration library that stores robot configuration data sets, each of the robot configuration data sets comprising data values that are relevant to respective use cases that pair a particular one of the robots with a particular one of the tenants; wherein the step of providing the robot configuration data set comprises selecting the robot configuration data set from the robot configuration library based on the robot configuration data set’s relevance to the use case that pairs the first tenant with the first robot; and wherein the one or more cloud databases are configured to persistently store the robot configuration library.

9. The method of claim 8, wherein the robot gateway comprises a third cloud component that comprises one or more cloud caches; wherein the one or more cloud caches are configured to temporarily store session state data for use in the step of executing the process; and wherein the software program is provided to the tenants according to a multi-tenant arrangement, and wherein the software program is configured to manage operational aspects of a contact center.

10. The method of claim 8, wherein the step of receiving the first message comprises monitoring an event bus data stream for the first message therein.

11. The method of claim 8, wherein the data values stored in the bot configuration data set include data values for authenticating use of the first bot by the first customer based on a relationship between the first customer and the first tenant.

12. The method of claim 8, wherein the formatted request includes two parts: an endpoint part; and a body part; wherein the first bot pattern includes a template for formatting an endpoint statement for use within the endpoint part of the first message, the endpoint statement providing a destination for directing the formatted request to the first bot; and wherein the data values stored in the bot configuration data set include data values for completing the endpoint statement.

13. The method of claim 12, wherein the text message is mapped to corresponding data fields defined within the body part.

14. The method of claim 12, wherein, When received by the bot gateway, the first message includes an unknown endpoint part and an unknown body part.

15. A system that facilitates passing messages from customers to bots, wherein tenants use software programs over a network to manage interactions with respective ones of the customers, the system comprising: a hardware processor; and a bot gateway, wherein: the bot gateway includes a bot pattern library, wherein a plurality of bot patterns are stored in the bot pattern library; and each of the plurality of bot patterns defines a data field arrangement according to a unique template for sending requests to a particular one of the bots; a machine-readable storage medium having instructions stored thereon that cause the hardware processor to perform a process that uses the bot gateway to format messages for passing to the bots, wherein the process includes the steps of: receiving a first one of the messages, hereinafter "first message” analyzing the first message to determine therefrom: a relevant one of the customers, hereinafter "first customer”; a relevant one of the tenants, hereinafter "first tenant”; a relevant one of the bots, hereinafter "first bot”; and a text message from the first customer that is intended to be passed to the first bot; providing a bot configuration data set that includes data values related to a use case that pairs the first tenant with the first bot; selecting a first one of the plurality of bot patterns belonging to the first bot, hereinafter "first bot pattern”, from the bot pattern library; creating a formatted request by mapping the text message and the data values defined in the bot configuration data set to corresponding data fields defined in the data field arrangement of the first bot pattern; and sending the formatted request to the first bot.

16. The system of claim 15, wherein the first bot includes a chat bot; and wherein the software program is provided to the tenants according to a multi-tenancy arrangement, and wherein the software program is configured to manage operational aspects of a contact center.

17. The system of claim 15, wherein the bot gateway comprises a bot configuration library that stores bot configuration data sets, each of the bot configuration data sets comprising data values that relate to respective use cases that pair a particular one of the bots with a particular one of the tenants; and wherein the step of providing the bot configuration data set comprises selecting the bot configuration data set from the bot configuration library based on the bot configuration data set’s relevance to the use case that pairs the first tenant with the first bot.

18. The system of claim 17, wherein the bot gateway comprises a serverless architecture in which one or more cloud components are maintained and executed within a cloud platform; and wherein the one or more cloud components comprise: one or more cloud computing functions for stateless execution of logic associated with the process; and one or more cloud databases configured to persistently store the bot schema library and the bot configuration library.

19. The system of claim 18, wherein the one or more cloud components comprise one or more cloud caches configured to temporarily store session state data for use in the step of executing the process.

20. The system of claim 18, wherein the step of receiving the first message comprises monitoring an event bus data stream for the first message; and wherein the data values stored in the bot configuration data set comprise data values for authenticating use of the first bot by the first customer based on a relationship between the first customer and the first tenant.

21. The system of claim 20, wherein the data values stored in the bot configuration data set comprise data values for authenticating use of the first bot by the first customer based on a relationship between the first customer and the first tenant.

22. The system of claim 21, wherein the data values stored in the bot configuration data set comprise data values for authenticating use of the first bot by the first customer based on a relationship between the first customer and the first tenant.

23. The system of claim 22, wherein the data values stored in the bot configuration data set comprise data values for authenticating use of the first bot by the first customer based on a relationship between the first customer and the first tenant.

24. The system of claim 23, wherein the data values stored in the bot configuration data set comprise data values for authenticating use of the first bot by the first customer based on a relationship between the first customer and the first tenant.

25. The system of claim 24, wherein the data values stored in the bot configuration data set comprise data values for authenticating use of the first bot by the first customer based on a relationship between the first customer and the first tenant.

Images