Method for implementing a chatbot, chatbot system and medium

Abstract

The present disclosure relates to methods for implementing chatbots, chatbot systems, and media. A computer-implemented method for an adaptive multi-domain chatbot system receives a user query via text, audio, or video and determines a relevant functional domain based on user-specific contextual data. The query is routed to a domain-specific processing module in a plurality of modules, each module connected to a different functional domain. Based on the domain-level context, one or more tools are selected and executed from a centralized repository to process the query. The system generates an interactive action card displayed on a graphical user interface allowing user interaction, where input from the user triggers execution of an associated operation. The method includes intent recognition for domain routing, dynamic generation of domain-specific prompts, and application of system-level parameters to standardize response tone, format, compliance, and interaction behavior.

Description

Technical Field

[0001] This invention primarily relates to chatbot systems, and more specifically, to a computer-implemented adaptive chatbot system that utilizes large language models (LLM), contextual domain detection, dynamic tool invocation, and user-oriented action cards to support multi-domain business operations. Background Technology

[0002] Chatbot systems have become indispensable to digital platforms, particularly in areas such as customer service, business process automation, and merchant support. These systems are designed to simulate conversational interactions between users and service providers through natural language interfaces. Their applications span a wide range of functions, including order tracking, product consultation, knowledge base access, and task execution. Despite the increasing popularity of chatbot systems, traditional chatbot systems still suffer from significant technical limitations that reduce their effectiveness, especially in complex and multifunctional environments such as retail, e-commerce, and fast-service business operations.

[0003] A major limitation of existing chatbot systems lies in their domain-specific design. Most implementations are tailored to operate within a single functional domain or a narrow set of tasks. For example, a chatbot designed to manage menu item updates typically cannot handle promotional campaign analysis or respond to sales performance inquiries without manual configuration or dedicated integration. This lack of cross-domain adaptability leads to a fragmented user experience, requiring users to interact with multiple bots or systems to complete workflows across different operational silos.

[0004] From a technical perspective, existing chatbot systems can be broadly categorized into two types: template-driven systems and intent-based modular systems. Template-driven systems rely on predefined scripts, static decision trees, or rule-based logic to generate responses. These systems are easy to implement but have limited flexibility, poor context awareness, and cannot support dynamic content. Intent-based systems use structured intents and entity recognition to handle slightly more dynamic queries, but typically lack the ability to connect to real-time backend systems, thus their intelligence level is only slightly higher. Both types of systems are limited by hard-coded logic and cannot be extended to new application scenarios without significant reprogramming.

[0005] Another challenge lies in real-time data processing and tool integration. Current chatbots typically only provide information; they can retrieve data but cannot perform actions. They are often not configured to support end-to-end operational tasks such as changing available items, initiating campaigns, or adjusting prices. When such actions are required, users need to manually access external platforms such as point-of-sale (POS) systems, marketing dashboards, or analytics portals. This disrupts conversational workflows, increases cognitive load, leads to inefficiency, and increases the risk of human error.

[0006] Existing systems also lack personalization. They rarely consider contextual data, such as the user's role (e.g., manager or cashier), past interaction history, current operational metrics, or business performance indicators. This results in generic and repetitive interactions that fail to adapt to the user's business context, preferences, or behaviors. The lack of personalized insights or recommendations often leads to decreased user engagement, especially in high-frequency, high-intensity operation settings.

[0007] Scalability and modularity represent additional technical drawbacks. Many chatbot platforms employ a monolithic architecture with tightly coupled components, leading to difficulties in maintenance, expansion, and configuration. Adding new domains, such as customer feedback analytics or delivery performance monitoring, typically requires significant backend changes and manual adjustments to the existing logic tree. Furthermore, these systems often lack a centralized mechanism to manage shared tools, prompts, and access controls across multiple business areas.

[0008] Finally, most chatbot systems are configured to operate purely passively. They wait for users to initiate queries and then respond accordingly. They cannot proactively offer hints, insights, or suggestions based on business conditions or behavior. For example, they cannot notify merchants that popular menu items are out of stock, nor can they suggest discount campaigns based on declining sales. This lack of proactive interaction limits the system's ability to guide user behavior or improve business outcomes.

[0009] Therefore, there is a need for improved chatbot systems that can overcome these limitations by providing multi-domain adaptability, real-time tool integration, proactive user engagement, and personalized interaction within a scalable modular framework, thereby simplifying complex business workflows. Summary of the Invention

[0010] The implementation provides a chatbot system and computer-based method configured to receive user queries and provide intelligent, context-aware responses across multiple business functions. The system is configured with a modular and scalable architecture, specifically designed to assist businesses by delivering real-time insights, enabling controlled automation of operational tasks, and proactively engaging with users through intelligent messaging. Unlike traditional chatbots that rely on static templates or limited keyword matching, the disclosed system is configured to integrate domain-aware processing, dynamic tool invocation, and context memory tracking to streamline business workflows and support efficient decision-making.

[0011] The chatbot system is configured with a structured architecture, including a domain detection unit, a global configuration layer, domain-specific processing modules, a centralized tool unit, and a context memory module. Incoming queries are dynamically analyzed using user-specific context parameters (such as user ID, role, and permissions), enabling the system to identify relevant business domains (e.g., sales performance, event evaluation, menu management). Queries are then routed to the appropriate domain-specific modules, each acting as an independent automated agent capable of invoking suitable tools from a centralized repository.

[0012] Each domain module is configured to access one or more tools from a centralized toolkit that supports many-to-many mappings between tools and domains. Tools are categorized into data retrieval tools and action-triggered tools. Data retrieval tools provide real-time access to structured business data (such as POS databases, inventory systems, or activity analytics), while action-triggered tools generate system instructions that require user confirmation before execution on the backend. Results from these tools are aggregated into action cards, interactive UI elements that present suggested actions to the user with options to confirm, modify, or cancel.

[0013] The system's global configuration unit is configured to define key behavioral parameters across all domain modules, including response tone, formatting rules, role definitions, and compliance guidelines. This ensures that all user interactions, whether they involve sales analytics, item updates, or performance monitoring, remain consistent, policy-compliant, and brand-assured.

[0014] In addition to handling user-initiated queries, the system also supports proactive interaction through casual conversation and push-based recommendations. These features enable the chatbot to autonomously interact with users based on real-time business conditions, such as recommending promotional activities or reminding users of low inventory during off-seasons.

[0015] The system is configured to personalize through dynamic data integration and contextual memory. It is also configured to track session-based and historical interactions to tailor responses, preserve context, and minimize redundant queries. This enables the chatbot to deliver relevant and continuously optimized outputs that match each merchant's operational needs and historical behavior.

[0016] By integrating core components such as domain detection, layered prompts, centralized tool invocation, contextual memory, and proactive interaction, the publicly available chatbot system significantly improves operational efficiency, reduces manual operations, and provides a superior user experience. It supports role-based access control, merchant-specific configurations, and can be rapidly expanded to integrate future domains and tools, making it a powerful and scalable solution for modern business environments. Attached Figure Description

[0017] The embodiments are described by way of example and not limitation in the accompanying drawings, wherein the same reference numerals denote similar elements, and wherein: Figure 1 A system architecture block diagram of a chatbot system 100 according to an embodiment is shown; Figure 2 A flowchart 200 is shown for a method for facilitating adaptive multi-domain chatbot interaction according to an embodiment; Figure 3 A schematic block diagram of a conversation flow 300 between a user and a chatbot system 100 according to an embodiment is shown; Figure 4 A schematic diagram of an implementation 400 of a chatbot system 100 according to an embodiment is shown; Figure 5 An architecture diagram of the recommendation module 500 in a chatbot system 100 according to an exemplary embodiment is shown; Figure 6 An exemplary computing environment is shown on which the embodiments described herein can be implemented, according to the embodiments described herein. Detailed Implementation

[0018] The following detailed description includes references to the accompanying drawings, which form part of the detailed description. The drawings illustrate illustrations according to exemplary embodiments. These exemplary embodiments (also referred to herein as “examples”) are described in sufficient detail to enable those skilled in the art to practice the subject matter. However, it will be apparent to those skilled in the art that the invention can be practiced without these specific details. In other instances, well-known methods, steps, and components have not been described in detail to avoid unnecessarily obscuring certain aspects of the embodiments. Embodiments may be combined, other embodiments may be utilized, or structural, logical, and design changes may be made without departing from the scope of the claims. Therefore, the following detailed description should not be considered limiting, and its scope is defined by the appended claims and their equivalents.

[0019] In this document, the terms “a” or “an” are used, as is the convention in patent documents, to mean one or more. In this document, the term “or” is used to refer to a non-exclusive “or”, and therefore, unless otherwise stated, “A or B” includes “A but not B”, “B but not A”, and “A and B”.

[0020] The term "one embodiment" or "implementation" as used in the specification refers to a specific feature, structure, or characteristic associated with an embodiment that is included in at least one embodiment of the invention, and multiple mentions of "one embodiment" or "implementation" should not be construed as necessarily referring to the same embodiment.

[0021] refer to Figure 1 The diagram illustrates the system architecture of a chatbot system 100. The chatbot system 100 is configured to utilize a large language model (LLM), dynamic tool invocation, and a role-based modular architecture to achieve intelligent, multi-domain, context-aware user interaction. This system is particularly suitable for applications involving business operations, encompassing sales, menu management, activity analytics, and business intelligence functions.

[0022] In this implementation, system 100 includes at least an input unit 102, a processing circuit 104, a context memory unit 118, and an output unit 106. The processing circuit 104 further includes a domain detection unit 110, a global configuration unit 112, one or more domain-specific modules 114, one or more centralized tool units 116, and a context memory unit 118. A communication channel 108 is configured to interconnect all system components to establish communication between the interconnected components.

[0023] In one implementation, the input unit 102 may include one or more hardware and software components configured to facilitate user interaction with the chatbot system 100. The input unit may include, but is not limited to, a keyboard, physical or virtual keypad, touchscreen, microphone, camera, barcode scanner, voice assistant interface, wearable sensors, and graphical user interface (GUI) elements. It may also include application programming interfaces (APIs), SMS gateways, social media messaging platforms, and IoT-connected input devices.

[0024] In retail and commercial implementations, the input unit can be integrated with merchant-specific systems such as point-of-sale (POS) terminals, kiosk interfaces, and inventory control systems. Furthermore, the input unit can connect to environmental sensors, biometric authentication systems, and geofencing modules to enable context-aware interaction. In some implementations, it can also support real-time audio or video streaming and integrate buffering and decoding logic to handle continuous input.

[0025] The input unit also supports multilingual interaction, voice-assisted tools, and gesture input methods, thereby enhancing the user experience for different user groups. Once the input data is collected, it is transmitted to the processing circuit 104 via the communication interface for semantic analysis and routing.

[0026] In this implementation, input unit 102 is configured to receive one or more user queries directed to chatbot system 100. Input unit 102 is configured to support multimodal input, allowing users to interact with system 100 via text, audio, and / or video queries. The ability to accept different input formats enables broader system accessibility and seamless integration with various platforms, including web-based dashboards, mobile applications, voice self-service terminals, and third-party messaging interfaces.

[0027] In text-based interactions, input unit 102 can be configured to receive queries via a chat interface, command-line prompts, or embedded controls. In audio-based implementations, input unit 102 can be configured to include or engage with different speech recognition modules that use a natural language processing (NLP) engine to convert spoken language into structured text. Similarly, for video input (e.g., video captured via a customer service kiosk or smart device), input unit 102 can be configured to integrate a speech-to-text pipeline or gesture recognition subsystem to extract actionable content from the video stream.

[0028] Upon receiving input data, it can be selectively preprocessed to standardize its format for subsequent downstream processing. Preprocessing includes operations such as word segmentation, language normalization, intent annotation, and entity recognition. These preprocessing steps help ensure that the downstream domain detection unit 110 receives semantically consistent input, thereby achieving accurate classification and routing.

[0029] In some implementations, input unit 102 may be configured to associate user metadata with each query. Such metadata may include user identifiers, session tokens, device information, timestamps, or geographic locations, which will be forwarded to processing circuitry 104 for personalized, context-aware interpretation.

[0030] The design of input unit 102 emphasizes scalability, allowing integration with third-party input sources such as customer messaging platforms or voice assistants. Input unit 102 may also include input filtering logic to reject unsupported formats or flag potentially harmful content, thereby ensuring that system 100 operates securely and within expected parameters.

[0031] In this implementation, the processing circuit 104 is configured to perform one or more computational operations that are crucial for enabling context-aware interpretation of user input, determining applicable business logic, invoking relevant computational tools, generating structured responses, and maintaining the continuity of the dialogue during interaction. The processing circuit 104 is operatively coupled to the input unit 102 and the output unit 106 and is configured to execute the core logic and computational processes of the chatbot system.

[0032] Processing circuitry 104 may include one or more hardware processors, such as a central processing unit (CPU), graphics processing unit (GPU), digital signal processor (DSP), or system-on-a-chip (SoC) device. In some implementations, processing circuitry 104 may be deployed in a distributed environment, utilizing cloud-hosted infrastructure, a local edge computing environment, or a hybrid of both, depending on system requirements. Processing circuitry 104 may communicate with other system components via secure communication interfaces and may operate synchronously or asynchronously relative to input and output operations.

[0033] The processing circuitry 104 may include multiple subsystems, such as, but not limited to, a domain detection unit 110, a global configuration unit 112, one or more domain-specific processing modules 114 (114a, 114b…114n), one or more centralized tool units 116 (116a, 116b…116n) (each centralized tool unit 116 being associated with a corresponding domain-specific processing module 114), and a context memory unit 118. Each subsystem is configured to be functionally distinct to support specific aspects of multi-domain query processing and response generation.

[0034] In this implementation, the domain detection unit 110 is configured to determine the most appropriate functional domain for a given user query by evaluating a set of user-specific and contextual parameters. These parameters may include the user identifier, assigned role, permission level, previous interaction history, and inferred query intent. Based on this evaluation, the domain detection unit 110 may be configured to route the query to the appropriate domain-specific processing module 114 for further analysis and response generation.

[0035] In this implementation, the global configuration unit 112 is configured to apply system-level parameters defining the operational characteristics of the chatbot system 100. These parameters may include tone specifications, output format rules, role and brand definitions, policy constraints, and consistency metrics. The global configuration unit 112 is configured to ensure that the output generated across various business domains conforms to predefined standards and regulatory requirements. Each domain-specific module can be an autonomous processing component configured to manage specific categories of business operations, such as sales analysis, inventory control, promotional activity optimization, or menu configuration. These modules can be instantiated independently and configured to invoke computing tools from the centralized tool unit 116 to retrieve data or generate executable operations related to the backend system.

[0036] In one implementation, the centralized tool unit 116 includes a reusable, callable tool library accessible to all domain-specific modules. These tools may include at least one of the following: a data retrieval tool 120 configured to interact with point-of-sale (POS) systems, order tracking platforms, and analytics engines; and an action triggering tool 122 that generates executable instructions for updating backend services. In some implementations, the centralized tool unit 116 may be configured to generate action cards encapsulating suggested actions, which are then presented to the user via output unit 106 for review, approval, or modification.

[0037] In an implementation, system 100 includes one or more data retrieval tools 120 (120a, 120b...120n) and one or more action triggering tools 122 (122a, 122b...122n), each tool being associated with a corresponding centralized tool unit 116 (116a, 116b...116n), which in turn may be associated with a corresponding domain-specific module 114 (114a, 114b...114n).

[0038] In this implementation, the context memory unit 118 is configured to store and manage dialogue state and historical interaction data. This data may include short-term session memories, long-term behavioral characteristics, and context-specific metadata used to guide subsequent interactions. By maintaining and updating these memory structures, the system can provide context-sensitive personalized responses within a user session.

[0039] In this implementation, the domain detection unit 110 is configured to identify the appropriate business domain to process user queries, thereby enabling accurate and context-sensitive task execution within the chatbot system 100. In this context, a "business domain" refers to a discrete functional area, such as inventory control, menu management, sales performance analysis, or campaign evaluation. By identifying the correct business domain, system 100 ensures that each query is interpreted and processed using logic, data, and tools most relevant to the operational context.

[0040] The domain detection process can include both user-specific data and contextual data. This includes attributes such as user identifiers (which can uniquely distinguish each user in system 100) and role assignments (which can reflect a user's role in the organization and control their access permissions to various business modules). Domain detection unit 110 can be configured to retrieve this information from session metadata or persistent user profiles and use this information to narrow down the range of eligible domains for further consideration. In addition to user metadata, domain detection unit 110 can also be configured to evaluate the semantic content of queries, using natural language processing techniques to assess intent and extract entities relevant to the domain classification.

[0041] In this implementation, the domain detection unit 110 can be configured to support dynamic prompt generation. After identifying potentially relevant domains, the system 100 can be configured to construct a domain-specific prompt that integrates contextual values ​​(such as a merchant identifier, time range, or product reference). This prompt can be generated using modular logic templates tailored to each domain and can be used to clarify the user's intent or to build subsequent interactions with the language model or domain-specific modules.

[0042] Once a relevant domain is identified, the domain detection unit can be configured to route the query and its associated metadata to the appropriate domain-specific module 114. This routing process can be performed based on system configuration rules and role-based access control. For example, if a user's role does not authorize access to the identified domain, system 100 can return a restricted access message or invoke an alternative workflow. The routing logic can also include a fallback procedure for low-confidence classification, enabling system 100 to forward the request to a general handler or request clarification from the user.

[0043] The output of the domain detection unit 110 may include a structured set of parameters, including the selected domain, user context, and any generated domain-specific hints. This information can be transmitted to the domain-specific module 114, which can use it as the basis for performing related tasks and generating responses.

[0044] In this implementation, system 100 includes multiple domain-specific modules 114, each configured to manage computational tasks and data processing operations associated with a specific business domain. These domains may include, for example, sales analysis, inventory management, promotional activity evaluation, or menu configuration. Each domain-specific module 114 can be implemented as an autonomous processing unit with internal logic, domain-specific configured rules, and access permissions to relevant tools. Each domain-specific module 114 can communicate with a domain detection unit 110 and a centralized tool unit 116. Domain-specific modules 114 are configured to receive queries and contextual metadata, such as user identifiers, permission attributes, and session-specific data, from the domain detection unit 110. Domain-specific modules 114 are also configured to select or generate structured prompts / domain-specific prompts using modular logic rules defined for their respective domains. These prompts can be used to interact with downstream models or tools in system 100.

[0045] In this implementation, each domain-specific module 114 is also configured to access tools within the centralized tool unit 116. These tools may include a data retrieval tool 120 for accessing structured business data, and an action triggering tool 122 for constructing system commands or updates. The selection of specific tools may be determined based on the set of rules within the domain-specific module 114 that interprets query content and context.

[0046] In this implementation, the domain-specific module 114 can be configured to invoke one or more tools from the centralized tool unit 116 depending on whether the query requires data retrieval or action execution. If the task requires interaction with the backend system, the domain-specific module 114 identifies the appropriate action-triggering tool 122, but does not build the action card itself. Instead, this responsibility is delegated to the tool unit. This module acts as a logical intermediary, responsible for preparing and transmitting input parameters and processing the output returned by the tools (including the action card), which is then forwarded to the output unit 106 for presentation to the user.

[0047] Domain-specific module 114 can also generate structured outputs, such as natural language responses or formatted data views. These outputs can be generated using internal rendering logic that conforms to system-level configuration policies. In cases where tool output includes action cards, the module is responsible for ensuring that the action cards are passed to output unit 106 so that the user can view, confirm, or modify them before final execution. Each domain-specific module 114 includes embedded access control logic to enforce role-based usage policies. Access to tools, functions, or data is filtered based on the user's role, determined by the session context or retrieved identity attributes. This selective access ensures operational security, compliance, and functional relevance for each user interaction.

[0048] The modular architecture of the domain-specific module 114 enables scalability and extensibility across business functions. New modules can be integrated into system 100 by associating them with functional domains, registering their interface parameters with the domain detection unit 110, and defining allowed tool bindings in the centralized tool unit 116. This model supports rapid deployment of new features without requiring extensive reconfiguration of existing components.

[0049] In this implementation, the context memory unit 118 is configured to store the conversation history and maintain context relevance during user interaction. The context memory unit 118 enables the chatbot system 100 to maintain conversation continuity and achieve personalized interaction within short-term and long-term interaction windows. The context memory unit 118 acts as a persistent memory layer for tracking conversation states and user behavior across multiple sessions.

[0050] Context memory unit 118 can be configured to maintain a hierarchical memory model that includes session-based memory, historical usage profiles, and domain-specific interaction trajectories. Session memory allows system 100 to maintain the coherence of ongoing dialogue by referencing previous user input, identifying missed parameters, and preserving utterance structure. This capability supports multi-turn dialogues, clarification prompts, and continuity across task flows.

[0051] Simultaneously, the long-term memory layer can be configured to store behavioral summaries, including interaction frequency, preference areas, query types, and tool usage trends. These summaries can be dynamically updated and used to personalize system behavior for individual users, enabling personalized prompts, responses, and tool recommendations.

[0052] In this implementation, the context memory unit 118 can be operatively connected to the domain detection unit 110, the domain-specific module 114, and the output unit 106. During domain detection, the context memory can be referenced to improve classification accuracy or provide domain-specific hints. Similarly, the domain module 114 can utilize stored context information to autocomplete or narrow the scope of tool invocation logic. The output can also be formatted or prioritized according to previously stored preferences.

[0053] In implementation, the context memory unit 118 may include predetermined memory management logic, including rules for data retention, expiration, and access control. Memory content can be selectively retained, deleted, or anonymized based on data privacy policies and system configuration. Access to specific context data can also be restricted through user roles or domain-level permissions. By retaining conversation history and adapting to each user's behavioral context, the context memory unit 118 aims to enhance the system's ability to provide relevant, efficient, and personalized interactions.

[0054] In this implementation, the global configuration unit 112 (also known as the global prompting layer) is a centralized subsystem that can be configured to define the interactive behavior of the chatbot system 100 across all business domains. The global configuration unit 112 is configured to establish and enforce a uniform set of parameters that control how the system 100 generates responses, applies tone and format standards, manages role-based interaction rules, and complies with compliance and policy requirements.

[0055] The global configuration unit 112 may include configuration data specifying system-level interaction parameters. These parameters may include: tone guidelines for determining the language characteristics of the system response (e.g., formal, friendly, concise); formatting rules for constructing output (e.g., list-based summaries, paragraph narratives, tables); persona attributes defining the chatbot's operating voice and style; and compliance safeguards that enforce restrictions on sensitive data exposure, disclaimers, or mandatory response structures. In implementations, the global configuration unit 112 may also define success metrics or performance standards for guiding or evaluating system responses.

[0056] The global configuration unit 112 can communicate with the domain detection unit 110, the domain-specific module 114, and the output unit 106, and provide them with relevant global configuration data at runtime. The domain-specific module references these settings during query interpretation, prompt generation, and tool selection, thereby ensuring that responses always conform to system-level interaction principles and corporate brand requirements.

[0057] In implementation, the global configuration unit 112 supports dynamic rule evaluation based on user roles, business contexts, or merchant-specific preferences. For example, executive users may receive richer or more strategically oriented responses, while frontline employees may receive simplified task summaries. Furthermore, the system can apply stricter formatting or policy rules in areas subject to industry-specific regulations.

[0058] The Global Configuration Unit 112 can also function as a policy enforcement layer. It can be configured to perform runtime validation checks, edit operations, or pre-response audits to ensure output complies with legal, regulatory, or contractual requirements. These validation mechanisms are applicable across all domains, making this unit crucial for enterprise-level governance. By standardizing the interaction behavior and output generation of all chatbot modules, the Global Configuration Unit 112 ensures consistency in system performance, brand consistency, and policy compliance. It simplifies maintenance, supports cross-domain scalability, and enhances operational consistency across different use cases and deployment environments.

[0059] In this implementation, output unit 106 is configured to present system-generated content to the end user in a structured, coherent, and context-aware manner. Output unit 106 can be configured as the final delivery layer of the chatbot system, responsible for rendering various types of responses, insights, and interactive elements, including action cards. Output unit 106 facilitates communication between the system's internal processing components and the user interface.

[0060] Output unit 106 may include one or more hardware and software components configured to support multiple user interface modes. These components may include a graphical user interface (GUI) rendering engine, display driver, speech synthesis module, web output service, or platform-specific rendering framework. Output unit 106 can be integrated with various types of display hardware, such as touchscreens, desktop displays, mobile device displays, self-service kiosks, or embedded system panels. Output unit 106 may also support voice-based responses via an audio output interface connected to a speaker or headphone system.

[0061] Output unit 106 can be configured to present various types of content. This content includes plain text responses, structured information (such as tables or charts), and interactive components (such as action cards). Action cards can be generated by the tool unit and transmitted to output unit 106 for presentation. Each card includes operation details and embedded interface elements, allowing the user to approve, reject, or modify suggested operations before execution in the backend. Output unit 106 can also support drag-and-drop, click confirmation, or gesture-based input associated with operation elements.

[0062] In an implementation, the communication channel 108 is configured to enable structured data exchange between various subsystems of the chatbot system 100, which include an input unit 102, a processing circuit 104, an output unit 106, and all their internal components, such as a domain detection unit 110, a domain-specific module 114, a centralized tool unit 116, a context memory unit 118, and a global configuration unit 112.

[0063] Communication channel 108 may include hardware and software components for supporting inter-component communication. These components may include a high-speed data bus, a shared memory interface, a message queue, an application-layer API, or a service communication protocol (such as HTTP, gRPC, or WebSocket). The design of communication channel 108 may vary depending on the system deployment architecture and may support centralized or distributed configurations. Communication channel 108 may be configured to handle synchronous and asynchronous data transfers, support real-time interaction when needed, and support delayed or batch communication during background operations. Communication may be event-driven or request-response based, depending on the operational context of the interacting subsystem. Transport protocols may include provisions for data integrity, authentication, and encryption to ensure the security and verifiability of inter-component messaging.

[0064] In this implementation, communication channel 108 can be configured to route messages between various functional units of the system. For example, an incoming user query received by input unit 102 can be transmitted to processing circuitry 104, where it is further routed to domain detection unit 110, and then to the appropriate domain-specific module 114. Similarly, the formatted output of action cards generated by centralized tool unit 116 or global configuration unit 112 will be transmitted to output unit 106 for user viewing.

[0065] In this implementation, the chatbot system 100 can be configured to interact with one or more external client servers to retrieve operational data and perform backend tasks. These external client servers may be operated by merchants, business partners, or third-party platforms and may include integrated systems such as point-of-sale (POS) databases, order management systems, inventory platforms, or analytics engines. The external client servers may expose data or services that the chatbot system 100 can access through defined interfaces. Communication between the chatbot system 100 and the external client servers can be established via an external communication network. This external communication network can be a wired or wireless connection and may include public or private networks such as the Internet, Virtual Private Network (VPN), cloud interconnect, or a dedicated enterprise backbone. Data can be transmitted over this network using secure, authenticated protocols such as HTTPS, TLS-encrypted REST APIs, WebSocket, or message broker architectures.

[0066] In an implementation, the centralized tool unit 116 can be configured to call external APIs or service endpoints exposed by an external client server via an external communication network. For example, when a user submits a query requiring real-time sales data, the relevant data retrieval tool 120 can be configured to construct a request (which can be transmitted over the network to a suitable integrated system), receive a response, and return structured output to the domain-specific module 114 for processing.

[0067] External communication networks can also support event-driven communication models, enabling chatbot systems to receive real-time notifications, webhook events, or push updates from external client servers. This facilitates proactive interaction, task automation, and context-based response generation based on changes in the merchant's system state. The integration of external communication networks with the modular client integration layer of the system module allows chatbot systems to operate efficiently across various external platform ecosystems.

[0068] Figure 2 A method 200 for facilitating adaptive multi-domain chatbot interaction according to an embodiment is shown.

[0069] At step 202, the input unit 102 of the chatbot system 100 receives a user query. The input unit 102 is configured to support multimodal user interaction and is operable to receive one or more modal inputs, including text, audio, or video. The system 100 is also configured to retrieve user-specific contextual data and domain-level contextual data. This enables the chatbot system 100 to operate across various access interfaces, such as web-based dashboards, mobile applications, voice-activated terminals, and embedded self-service terminal systems.

[0070] In this implementation, users can enter queries in text format via a graphical user interface (GUI). For example, a store manager could enter a query such as "Show the best-selling drinks this month" in the chat interface of a desktop control panel. Input unit 102 can be configured to capture text and convert it into a structured format suitable for downstream processing by processing circuitry 104.

[0071] In this implementation, the input unit 102 may receive audio input via a microphone or a voice-enabled device. The chatbot system 100 may include an automatic speech recognition (ASR) module or be coupled with an ASR module to convert spoken language into transcribed text. For example, a user could say, "What is the current stock of bottled water?", and the input unit 102 could generate a corresponding structured query using the ASR component for further analysis.

[0072] In one implementation, the input unit 102 may include a camera or gesture recognition system for capturing video input. For example, a user interacting with a smart point-of-sale (POS) terminal may trigger a predefined gesture representing a replenishment request. The gesture recognition subsystem may interpret this input as a predefined command, equivalent to a text query such as "replenish beverage inventory".

[0073] In addition to the query content, input unit 102 can also be configured to capture or associate one or more contextual metadata elements that describe the characteristics of the user and their environment at the time the query is submitted. Such metadata may include, but is not limited to: user identifier (e.g., usr_02345 or user email address), session identifier for stateful interaction (e.g., sess_00981), device type (e.g., desktop_browser, mobile_app, or kiosk_terminal), timestamp indicating the time the query was received (e.g., 2025-05-23T14:42:11Z), merchant identifier or store ID (e.g., store_0456), optional geographic coordinates (e.g., 37.7749°N, 122.4194°W), and language or localization preference (e.g., en-US).

[0074] In implementations, user-specific contextual data may include one or more of the following: user role designation (e.g., "manager", "owner"), user identifier, merchant ID, activity permissions, previous query history, and current session metadata.

[0075] In implementation, domain-level context data may include one or more of the following: domain identifier, merchant identifier, one or more product or service categories extracted from user queries, time range or reporting period, user role designation, and permission set associated with user access level.

[0076] These metadata parameters can be transmitted along with the query to the processing circuit 104, where they are used to support domain identification, personalization, role-based access control, and a consistent format for system responses.

[0077] At step 204, the chatbot system 100, through processing circuitry 104, determines the relevant functional domain of the received user query, at least in part based on user-specific contextual data. This operation is performed by the domain detection unit 110, which is configured to analyze the query content in conjunction with the contextual parameters extracted in previous steps.

[0078] User-specific contextual data can be used by the domain detection unit 110 to constrain and guide the domain selection process, ensuring that the system 100 identifies business functions that the user is both entitled to and that conform to the context.

[0079] Domain detection unit 110 can employ a combination of rule-based classifiers, keyword matching logic, prompt templates, or machine learning models to infer the most applicable domain. In some implementations, domain detection unit 110 dynamically constructs domain-specific prompts or feature vectors that capture both the semantic context of the query and the user's operational context.

[0080] For example, when user "user_001" has the "Manager" role and the permissions "read_sales_data" and "initiate_promotions," and submits the query "Why did hamburger sales decline this week?", the domain detection unit 110 identifies key markers: "sales," "burger," and "this week," and combines them with role and permission data. Based on this analysis, system 100 selects the "Sales Analysis" domain as the most relevant functional domain. The query is then ready to be routed to the "Sales Analysis Module"—a domain-specific module 114 configured to support queries related to product-level sales performance.

[0081] This domain defines steps to ensure that queries are processed in the appropriate operational context, enabling subsequent modules to execute logic, access tools, and generate responses consistent with user responsibilities and business functions.

[0082] At step 206, the chatbot system 100 routes the user query to a domain-specific processing module 114 selected from multiple domain-specific processing modules via processing circuitry 104. Each domain-specific processing module 114 is an independent processing unit for performing operations related to a specific functional domain, such as sales analysis, inventory control, menu management, or promotional activity management.

[0083] Processing circuit 104 refers to the domain-to-module routing mapping or registry to determine the target module corresponding to the identified domain. Then, system 100 forwards the user's query along with relevant contextual information (such as user ID, store ID, role, and session details) to the selected domain-specific module for processing.

[0084] Prior to final routing, processing circuitry 104 enforces role-based access control. If a user's role does not have permission to access the selected domain, system 100 can return a restricted access message or redirect the query to an alternative domain where access is permitted. Access policies are centrally managed by global configuration unit 112 and can be updated based on merchant-specific rules or system-level compliance policies.

[0085] For example, when a store manager with the role "floor_supervisor" and the identifier "user_001" issues the voice command "Replenish bottled water and juice," the domain detection unit 110 will categorize the query into the inventory management domain. Then, the processing circuit 104 will query the routing registry and resolve this query to the inventory module, a domain-specific module 114 configured to manage product-level inventory operations. The payload is then passed to the inventory module via an internal function call.

[0086] At step 208, the chatbot system 100 is configured to select and execute one or more tools from the centralized tool unit 116 via processing circuitry 104, based on domain-level context data. Each tool can be invoked by a corresponding domain-specific module 114 and is configured to process data or initiate operations related to a specific functional domain to which the query is routed.

[0087] In one implementation, domain-level context data is available to the domain-specific module 114 to select an appropriate tool configured to manipulate domain-related data and return structured output or suggested operations.

[0088] Domain-specific module 114 can be configured to invoke tools mapped to the current activity domain. These tools may include data retrieval tool 120 (configured to access structured business data from integrated systems, such as point-of-sale databases, inventory systems, and activity performance metrics) and action triggering tool 122 (configured to build suggested operational changes, such as price updates or availability toggles, and return them in an interface-ready format).

[0089] Tool selection can be based on domain-level context data, which may include parameters such as domain identifiers, merchant IDs, entry categories, user roles, previous tool usage, and operational context extracted from the query itself. Once a tool is selected, System 100 can execute it to obtain real-time output, such as an analysis summary or suggested changes configured in the backend.

[0090] For example, if a user query is “Why are burger sales down this week?”, and this query is routed to the domain-specific module 114 corresponding to the sales analytics domain, the following domain-level context data can be derived: domain identifier: “sales_analytics”, merchant ID: “store_0456”, item category: “burgers”, time range: “current_week vs previous_week”, user role: “manager”, access permissions: [“view_sales_data”, “view_trends”]. Based on these parameters, the domain-specific module 114 can select one or more tools from the centralized tool unit 116, such as: a sales trend comparison tool (configured to retrieve and compare weekly sales metrics for the selected item category) and a category performance summary tool (configured to return sales comparisons between the queried category and other major item categories).

[0091] System 100 executes the selected tool using the provided context parameters and returns the generated data to domain-specific module 114 for downstream processing, such as generating action cards and formatting responses.

[0092] In this implementation, the centralized tool unit 116 simultaneously supports both the data retrieval tool 120 and the action triggering tool 122. The data retrieval tool 120 is configured to access structured business data from an integrated backend system (e.g., a point-of-sale database, an analytics engine), while the action triggering tool 122 is configured to construct executable operations, such as status updates or price changes, subject to user confirmation.

[0093] At step 210, the chatbot system 100 is configured to generate one or more action cards via processing circuitry 104, based on output received from tools within the previously executed domain-specific module 114. Each action card is a structured artifact usable for the interface, including suggested actions, recommendations or system-generated insights, and interface elements configured to enable user interaction.

[0094] Action cards can be constructed using tool outputs from the domain-specific module 114, along with any other domain-related data fields derived from user queries, context parameters, and session state. Each action card may include, for example: a text summary of the suggested task, one or more user-selectable options (e.g., approve, modify, cancel), relevant identifiers (e.g., project ID, activity code, or schedule reference), and embedded metadata for traceability, compliance, or backend execution. In implementations, action cards can be categorized as informational (e.g., presenting trend data, performance alerts) or action-triggered, the latter proposing a specific change that can be executed by the system upon user confirmation.

[0095] For example, after executing a sales trend comparison tool, the domain-specific module 114 (which can be called the sales analytics module) detected a 12% decrease in hamburger sales compared to the previous week. Based on predefined business rules, module 114 generates an action card that proposes a promotional campaign. The generated action card may include: a title: "Sales Decline Detected: Hamburgers", a summary: "Hamburger sales have decreased by 12% this week. Would you be willing to offer a 10% weekend discount to boost demand?", and data fields including: item: "Hamburgers", discount: "10%", validity period: "Saturday to Sunday", store ID: "store_0456", and action options: "[Approve]", "[Edit]", "[Cancel]".

[0096] The action card can be formatted according to the uniform layout specified by the global configuration unit 112 and then provided to the output unit 106 for user-facing display.

[0097] In implementation, multiple action cards can be generated from a single query, especially when the tool output includes comparison options, alternative actions, or upgrade suggestions. Each card can be assigned a unique identifier, which is recorded by the system for traceability and auditing.

[0098] At step 212, the chatbot system 100 is configured to present one or more action cards to a user on a graphical user interface (GUI) of a computing device via output unit 106. Output unit 106 may be responsible for rendering the action cards in a format that supports interactive user participation, consistent with the system-level behavior and format parameters defined by global configuration unit 112.

[0099] The presentation of action cards can include visual elements such as buttons, drop-down menus, sliders, or input boxes embedded in the graphical user interface (GUI), enabling users to view suggested tasks, modify parameters, approve, or cancel actions. Output unit 106 formats these elements according to a role-based display strategy and accessibility guidelines to ensure clarity and ease of use.

[0100] In this implementation, the output unit 106 supports multiple interface platforms, including web browsers, mobile applications, voice assistants with visual display capabilities, and integrated point-of-sale terminals.

[0101] For example, building on the previous step, the manager's mobile app interface would display an event card proposing a 10% discount on weekend burgers. This card would include: a clear promotional title and summary, interactive buttons labeled [Approve], [Edit], and [Cancel], and fields for the discount percentage and expiration date that the user can edit after clicking the [Edit] button.

[0102] After viewing the card, the user can interact with it to confirm or modify the suggested activity plan. The output unit 106 captures the user input and transmits it back to the processing circuit 104 for subsequent operations.

[0103] The output unit 106 can also record user interactions with the action card for auditing and analysis purposes, thereby gaining a deeper understanding of user behavior and system effectiveness.

[0104] At step 214, the chatbot system 100 is configured to perform one or more operations associated with an action card via processing circuitry 104, these operations being based on user input in response to the presented action card. Processing circuitry 104 receives user selections or modifications from output unit 106 and processes these inputs to initiate corresponding backend tasks.

[0105] In this implementation, the execution of backend operations may involve invoking action triggering tools 122 from centralized tool unit 116. These tools generate executable instructions or signals to enable changes in the integrated business system, such as updating menu item availability, adjusting prices, launching promotional campaigns, or modifying inventory records.

[0106] This system ensures that all backend operations comply with applicable access control, role-based permissions, and compliance rules enforced by the global configuration unit 112. Operations are executed only after explicit user approval or confirmation, thereby maintaining oversight and preventing accidental changes.

[0107] Upon successful execution, the processing circuit 104 generates an acknowledgment message or an updated status report and sends it back to the output unit 106 for display to the user. If execution fails, an error message or alternative solutions are provided for the user to take corrective action.

[0108] For example, after approving a 10% discount card, processing circuitry 104 invokes action triggering tool 122 within centralized tool unit 116 to activate a burger promotion for store "store_0456". This tool constructs backend instructions and sends them to the merchant's activity management system to schedule the discount to be executed on the specified weekend date.

[0109] System 100 can then be configured to provide the user with confirmation feedback: "This weekend's 10% off burger promotion has been successfully arranged." If activation fails due to a system error or permission issue, the system will notify the user and provide options to retry or modify the promotion.

[0110] In implementation, the global configuration unit 112 plays a crucial role throughout the operation of the chatbot system by enforcing system-level behavioral policies and configuration parameters across all functional domains. The global configuration unit 112 defines various aspects of interactive behavior, such as response tone, formatting standards, compliance constraints, and role-based access policies. At each step, from query reception to domain detection, tool execution, action card generation, and backend operation execution, the global configuration unit 112 ensures consistent adherence to brand guidelines and regulatory requirements. It also manages access control by verifying user roles and permissions, thereby preventing unauthorized access or manipulation of domain-specific modules.

[0111] In this implementation, the context memory unit 118 is configured to maintain the continuity and personalization of the conversation by storing multi-level context data, including session-based interaction history and long-term behavior profiles. This unit provides relevant contextual information to the domain detection unit 110 and the domain-specific module 114 to enhance query interpretation and tool selection. It also retains user responses to action cards and tracks changes in system interactions over time, enabling progressive optimization of responses and proactive interaction. By retaining contextual information across multiple user interactions, the context memory unit 118 supports a coherent, efficient, and personalized user experience throughout the chatbot's workflow.

[0112] Figure 3 A schematic block diagram of a dialogue flow 300 between a user and a chatbot system 100 according to an embodiment of the present disclosure is shown. The dialogue flow 300 includes a series of executable blocks arranged in a predetermined order. The flow includes a pull-push block 302, an intent block 304, a recommendation block 306, and an operation block 308. The pull-push block 302 initiates the dialogue flow, followed by the sequential execution of the intent block 304, the recommendation block 306, and finally the operation block 308.

[0113] The chatbot system 100 can be configured to support two main dialogue initiation modes: user-initiated (pull) interaction and system-initiated (push) interaction. The pull / push block 302 enables both modes, thus supporting both passive and active interaction strategies. This dual-mode approach enhances system usability, encourages frequent user interaction, and improves operational efficiency by supporting both user requests and system-initiated recommendations.

[0114] In user-initiated (pull) mode, the interaction begins with the user submitting a query to system 100. System 100 is configured to analyze the received query intent and determine the appropriate response or action. For example, when a user requests to create a new menu item, system 100 processes the request and generates an action card including relevant fields and options for the user to review and confirm before execution. This ensures that the user's intent is accurately captured, and subsequent operations are executed only after explicit user approval.

[0115] In system-initiated (push) mode, the chatbot system 100 proactively initiates conversations with users. These interactions can include lighthearted small talk to maintain user engagement or actionable suggestions based on contextual business data. For example, system 100 can detect a high-demand product being out of stock and initiate a conversation suggesting restocking, along with an action card for quick user action. Integrating these two conversation initiation modes enables seamless, context-aware interaction and facilitates proactive operations management.

[0116] Intent block 304 is responsible for parsing user queries and system-initiated messages. Intent block 304 is configured to identify the problem, understand the request, and respond to user input to complete the task. Recommendation block 306 is configured to provide suggestions based on system insights, recommending answers to the problem or appropriate actions to perform the task. Action block 308 is configured to perform actions based on these suggestions and complete the task according to user interaction or authorization by system protocols.

[0117] Figure 4 A schematic view of an implementation 400 of the chatbot system 100 according to an embodiment of the present disclosure is shown. Implementation 400 illustrates various types of conversational interactions supported by the system 100, including general chat 402a, 402b, and personalized chat 404, etc. These interactions encompass a variety of messages generated by the chatbot, designed to enhance user engagement and operational efficiency.

[0118] The chatbot system 100 incorporates a casual conversation mechanism configured to proactively initiate dialogue prompts, not limited to direct transaction inquiries. This casual conversation feature can generate various types of messages, differing in personalization and contextual relevance.

[0119] General chat logs 402a and 402b can include predefined messages generated from static templates. These messages can be sent at predetermined time intervals (e.g., daily or weekly) and typically include general business tips, incentives, or reminders designed to maintain regular communication with users and encourage continued use of the system.

[0120] In contrast, personalized 404 messages can be dynamically generated based on a merchant's specific operational data and relevant business metrics. This information can be customized based on the merchant's recent activities and performance. For example, System 100 can detect high sales during a specific period and send supportive prompts such as, "Your sales yesterday looked great! Want to learn some tips to improve customer engagement?" This approach increases relevance and fosters more meaningful interactions.

[0121] Furthermore, System 100 can integrate large language models (LLMs) to generate context-sensitive dialogue output in real time. This LLM-generated chat content can dynamically adjust based on changing business conditions and user behavior, providing nuanced and natural language interaction that reflects ongoing business engagement.

[0122] System 100 also supports customer retention chat, designed to re-engage merchants whose activity has decreased or who may be churning. By analyzing historical interaction patterns and conversation history stored in the context memory unit 118, the chatbot system 100 generates targeted messages to reignite user interest. For example, a retention message might say: “Hi, [username], long time no see! Need help setting up a new promotion to attract more customers?”

[0123] By integrating these different types of small talk (including generic, personalized, LLM-generated, and user retention-focused), System 100 can be configured to implement a comprehensive proactive communication strategy. This strategy supports sustained user engagement, provides contextualized assistance, and promotes business growth by maintaining an interactive and responsive conversational environment.

[0124] Figure 5 An architecture diagram of the recommendation module 500 in a chatbot system 100 according to an exemplary embodiment is shown. The recommendation module 500 is designed to implement a structured push recommendation function that operates independently of the aforementioned general chat mechanism.

[0125] In this implementation, the recommendation module 500 includes, but is not limited to, one or more recommendation engines, one or more recommendation domains, and one or more delivery channels. The recommendation engine can be configured to generate recommendations based on various inputs, including but not limited to: competitor activity, root cause analysis (RCA) of sales anomalies, passenger (Pax) reviews, predefined rules, and neighboring workgroup (TF) data. Recommendation domains may include functional areas such as menu management, customer satisfaction, brand display, operations, inventory management, marketing, customer insights, financial services, and training. The generated recommendations can be delivered through one or more channels, including, for example, AI assistant interfaces, inbox notifications, and email communications. The module may also include a data store (implemented as a database) configured to persistently store recommendation-related attributes at the store ID level.

[0126] The merchant recommendation delivery system in module 500 is configured to optimize conversion rates based on recommendation domain, delivery time / day of the week, and delivery channel.

[0127] System 100 can integrate a centralized recommendation engine configured to generate and provide merchants with tailored, context-aware suggestions. These suggestions are generated based on multiple parameters, including the applicable recommendation domain (e.g., menu optimization, promotional campaign strategies, or order flow management), a time logic for identifying the optimal interaction window (e.g., before peak business hours), and preferred communication channels (which may include chatbot interfaces, email notifications, or in-dashboard alerts).

[0128] In this architecture, the AI ​​assistant embedded in System 100 can be configured to act as the main interface for recommendation delivery. System 100 can present actionable suggestions using structured user interface elements, particularly action cards, allowing merchants to directly view and implement system-generated recommendations. For example, when a decline in weekday lunch sales is detected, the system can generate a notification: “Your weekday lunch sales are declining. Would you like to set a 10% lunch discount to attract more customers?” An action card will be displayed next to this notification, allowing users to approve, modify, or reject the suggested discount, thus providing both user convenience and ensuring user control over business decisions.

[0129] The integration of push notifications and chat functionality allows the chatbot system 100 to both passively respond to user queries and proactively initiate interactions based on real-time business contexts. This combination enhances merchant engagement and improves operational efficiency.

[0130] The recommendation module can be built on a modular and scalable framework that leverages domain-specific processing modules, a hierarchical suggestion structure, historical session data stored in context memory unit 118, and a centralized toolkit. This architecture supports precise query routing, real-time data access, and user-authorized execution of critical business operations, thereby simplifying workflows and reducing manual intervention.

[0131] In a further implementation, system 100 may employ advanced machine learning techniques to perform dynamic domain classification and generate personalized responses based on historical user interactions and merchant behavior characteristics. These improvements aim to continuously enhance the level of automation, decision support capabilities, and overall user satisfaction in the chatbot environment.

[0132] refer to Figure 6 An exemplary computing environment is disclosed that can be used to implement the embodiments described herein. An exemplary computing environment suitable for implementing one or more embodiments described herein will be described below. This computing environment is for illustrative purposes only and should not be construed as limiting the scope or functionality of any of the embodiments described herein. Reference to known computing components and processes does not imply that any disclosed embodiment is merely a simple combination of such known elements. Rather, the disclosed embodiments involve specific configurations and programming to form a machine specifically designed to perform the methods and systems described herein.

[0133] An exemplary environment includes one or more client devices 602 and a system 100, which is located on a remote server configured to communicate via a communication network 604.

[0134] In this implementation, one or more client devices 602 may include computing devices operable by end users or enterprise operators, such as desktop computers, laptops, smartphones, tablets, point-of-sale (POS) terminals, self-service terminals, or wearable devices. These client devices 602 may include one or more processors, memory, display interfaces, input / output subsystems, and network communication hardware. Each client device 602 is configured to execute a user interface application, such as a web-based dashboard, mobile application, or voice interface, through which a user can interact with the chatbot system 100 via text, audio, or video.

[0135] In this implementation, client device 602 may be configured to render interactive elements (e.g., action cards), receive and transmit user input, and display system responses generated by chatbot system 100. These interactions may be implemented through a graphical user interface (GUI), a speech synthesis and recognition engine, or a multimodal interface. Client device 602 may also be configured to transmit contextual metadata (e.g., user identifier, role, geolocation data, and session token) as part of each interaction.

[0136] In this implementation, the communication network 604 can be configured to enable secure, bidirectional data exchange between the client device 602 and the chatbot system 100 deployed on a remote server. It can include a combination of public and private networks, such as the Internet, VPN, LAN, and wireless cellular networks (e.g., 4G, 5G), and supports various communication protocols, including HTTPS, WebSocket, and gRPC. The network supports real-time and asynchronous interaction across text, audio, and video modes and may include encryption, authentication, and API gateway layers to ensure data integrity and access control. Furthermore, the network can connect to external systems (e.g., POS or analytics platforms) to support backend operations triggered by user interaction.

[0137] In this implementation, the system 100 implemented on the remote server includes at least one processor 606 (or a cluster of processors). One or more processors 606 may be configured to execute the core logic of an adaptive multi-domain chatbot and include dedicated sub-components such as a domain detection unit 610, a global unit 608, and a context / intent detection unit 612. These modules may be configured to work collaboratively to categorize incoming queries, apply enterprise-level interaction strategies, and infer user intent based on semantic input and contextual metadata.

[0138] In one implementation, system 100 includes at least one processor 606, which may be implemented using one or more processors configured as hardware, software, firmware, or any suitable combination thereof. Depending on system requirements, processor 606 may include a central processing unit (CPU), a graphics processing unit (GPU), or other dedicated processing hardware such as a TPU or FPGA. Processor 606 may be operatively coupled to other system components via system bus 624 and is responsible for coordinating and executing the core functions of chatbot system 100. In a software- or firmware-based implementation, processor 606 may execute computer-executable instructions stored in a database / memory. These instructions may be written in any suitable programming language and configured to perform operations such as domain detection, intent classification, context management, tool invocation, recommendation generation, and system orchestration. In a distributed environment, multiple processor instances may run in parallel across cloud or edge infrastructure to support scalable real-time performance.

[0139] In some implementations, system 100 also includes an input / output (I / O) interface 614 configured to manage communication between system 100 and external devices or networks. I / O interface 614 may include hardware and software components capable of receiving user input in various ways, including text, voice, and video, and transmitting system responses or interactive elements (e.g., action cards). It may also support integration with peripheral devices such as microphones, cameras, touchscreens, keyboards, and display panels. I / O interface 614 may be operatively coupled to processor 606 and other system components via system bus 624 and is responsible for formatting, routing, and validating incoming and outgoing data. In some implementations, I / O interface 614 may support communication via various protocols such as HTTP, HTTPS, WebSocket, gRPC, or proprietary APIs, enabling seamless interaction with client devices, external systems, and third-party platforms. I / O interface 614 may also include input filters and output formatting logic consistent with system-level configuration parameters defined by global unit 608.

[0140] In an implementation, database 616 may be configured to store persistent and transient data used by one or more processors 606 during execution. Database 616 may include a combination of volatile memory (e.g., random access memory or RAM) and non-volatile memory (e.g., solid-state drive, hard disk drive, or flash memory). It may also support removable or external storage, such as CompactFlash cards, Secure Digital (SD) cards, or other portable storage formats. Database 616 may be implemented as main memory and secondary memory, providing dedicated locations for system instructions, intermediate computations, and long-term data persistence. Database 616 may be configured to store executable program instructions, configuration parameters, and system-level data, including user profiles, context memory states, session history, access control rules, and interaction logs. Database 616 may also retain pre-trained language model parameters, tool call maps, and rule sets for domain-specific modules. During runtime, processor 606 may be configured to retrieve, update, and write data from database 616 to support real-time dialogue processing, tool execution, personalization, and recommendation generation. Depending on performance and consistency requirements, memory modules can be implemented using relational databases, NoSQL databases, key-value stores, or in-memory data grids.

[0141] In the implementation method, as referenced Figure 5 As shown and described, recommendation engine 618 is configured to generate personalized, context-aware, and domain-specific recommendations for users. Recommendation engine 618 can be configured to analyze real-time operational data, user behavior patterns, historical interaction logs, and business performance metrics to identify relevant actions or insights. These recommendations may include promotional suggestions, inventory alerts, pricing optimizations, or interactive guidance, depending on the functional domain relevant to the current user interaction. Recommendation engine 618 can collaborate with domain detection unit 610, context unit 612, and one or more large language models 620 to construct structured outputs, such as action cards or system-generated prompts. Recommendation engine 618 includes rule-based logical, statistical, or machine learning algorithms for evaluating thresholds, detecting anomalies, or predicting trends. The generated recommendations can be proactively offered to users or provided in response to specific queries, and presented through output units in an interactive format that supports user approval, modification, or rejection.

[0142] In implementation, one or more large language models (LLMs) 620 can be configured to facilitate natural language understanding, semantic interpretation, prompt generation, and dynamic response construction. The LLMs 620 can be implemented as fine-tuned Transformer-based architectures, such as GPT, BERT, or other base models trained on large-scale corpora. Depending on performance, latency, and deployment constraints, these LLM models 620 can be hosted locally in the system infrastructure or accessed via secure API calls to third-party AI service providers. In operation, the LLMs 620 can be invoked by domain-specific modules, context / intent detection units 612, or recommendation engines 618 to perform functions such as query interpretation, entity extraction, contextual reasoning, and natural language generation. The LLM models 620 can use structured prompts assembled from contextual memory and system parameters and return structured or free text output for further processing or presentation. Multiple instances of the LLM models 620 can be used simultaneously for different business domains or user roles, and their output can be filtered or refined through post-processing logic based on a global configuration strategy.

[0143] In this implementation, one or more application programming interfaces (APIs) 622 can be configured to facilitate secure and structured communication between internal system components and external platforms. These APIs can be implemented using standard protocols such as REST, gRPC, GraphQL, or WebSocket and are operable for transmitting and receiving data related to user queries, system responses, tool execution, business metrics, and action card payloads. API 622 can seamlessly interoperate with merchant systems, including point-of-sale (POS) platforms, inventory databases, analytics engines, marketing dashboards, and third-party messaging services. Internally, API 622 can also be used to execute data flows between system modules, such as the domain detection unit 610, recommendation engine 618, and context / intent detection unit 612. These interfaces ensure modularity, scalability, and functional abstraction, enabling components to evolve independently while maintaining system cohesion. API 622 can be protected using authentication mechanisms such as OAuth 2.0, API keys, or mutual TLS and may include rate limiting, logging, and access control layers to enforce security, privacy, and compliance policies.

[0144] In this implementation, components of system 100 (including processor 606, I / O interface 614, database 616, large language model 620, recommendation engine 618, and API 622, etc.) can be configured to communicate with each other via system bus 624. System bus 624 can be configured to provide a communication backbone that facilitates structured, high-speed data exchange and synchronization between functional modules. System bus 624 may include one or more hardware- and / or software-based interconnects, such as parallel buses, serial buses, or messaging interfaces, and may support point-to-point or broadcast communication modes. Depending on the operational requirements of each module, system bus 624 can be configured to support event-driven, synchronous, or asynchronous communication. System bus 624 can be implemented using technologies such as shared memory, message queues, middleware brokers (e.g., RabbitMQ, Kafka), or an internal API layer. It ensures the modularity, scalability, and coordination of the distributed system, enabling coherent, low-latency execution of chatbot workflows, real-time tool invocation, and the provision of context-aware recommendations.

[0145] In this embodiment, the function of global unit 608 may correspond to the function of global unit 114 described in the previous embodiment. Similarly, the area detection unit 610 may be equivalent to the area detection unit 110, and the processor 606 may correspond to the processing circuit 104. Furthermore, the function of system bus 624 may be equivalent to the communication channel 108 described in the previous embodiment, and may be configured to facilitate communication between components within the system.

[0146] In an implementation, a non-transitory computer-readable medium may be provided that stores instructions that, when executed by one or more data processing devices, cause those devices to perform the methods and processes described herein. The non-transitory computer-readable medium may include, but is not limited to, a hard disk, optical disk, solid-state drive, flash memory, or any other suitable medium capable of storing executable instructions. When operatively connected to a processing system configured to execute such instructions, the stored program code enables the system to perform the functions and operations described above.

[0147] It should be noted that the above process is described in the form of a step sequence; this is merely for ease of explanation. Therefore, it is possible to add some steps, omit some steps, rearrange the order of steps, or perform some steps simultaneously. Although embodiments have been described with reference to specific implementations, it is obvious that various modifications and changes can be made to these embodiments without departing from the broader scope of the system 100 and method described herein. Therefore, the specification and drawings should be considered exemplary rather than restrictive.

[0148] Those skilled in the art will undoubtedly discover many changes and modifications to the present invention after reading the above description. It should be understood that the wording or terminology used herein is for description only and not for limiting the invention. It should be understood that the above description includes many specific descriptions; these descriptions should not be construed as limiting the scope of the invention, but are merely examples of some preferred embodiments of the invention. Therefore, the scope of the invention should be determined by the appended claims and their equivalents, and not by the examples given.

Claims

1. A method for implementing a chatbot, the method being executed by one or more processors, the method comprising: Receive user queries in one or more modalities, including text, audio, or video; Based on user-specific contextual data, determine the relevant functional areas for user queries; The query is routed to a domain-specific processing module among multiple modules, each of which is configured to perform operations related to a different functional domain associated with the user; Select and execute one or more tools from a centralized tool repository, each tool being configured to process and identify data associated with functional domains based on domain-level context data. Based on the output received from the selected and executed tool, one or more action cards are generated, wherein each action card enables user interaction; The one or more action cards are presented on a graphical user interface to enable user interaction with the one or more action cards; as well as Based on the input received from the user in response to the one or more action cards, perform one or more operations associated with the one or more action cards.

2. The method according to claim 1, further comprising identifying the user's intent based on the received query, wherein, The query is routed to the domain-specific processing module based on the identified user intent.

3. The method according to claim 1, wherein: The user-specific context data includes at least one of the following: a user identifier, a role designation indicating the user's access level, and a list of domain-specific modules that the user is allowed to access; as well as The domain-level context data includes at least one of the following: a domain identifier corresponding to the selected functional domain, and operational parameters related to the identified domain.

4. The method according to claim 3, wherein, The relevant functional areas include: Based on the user-specific context data, dynamically generate domain-specific prompts; and The generated domain-specific prompts are provided as input to the domain detection unit for selecting the relevant functional domain from multiple functional domains.

5. The method according to claim 1, wherein, Each domain-specific module is configured with access to a centralized tool unit, which includes: One or more data retrieval tools are configured to access structured business data from an integrated system, said integrated system including at least one of a point-of-sale database, a sales analytics engine, and an inventory system; and One or more action triggering tools are configured to build executable signals for backend task execution.

6. The method according to claim 1, wherein, Each action card includes one or more user-selectable options to confirm, modify, or cancel the proposed action.

7. The method of claim 1 further includes a set of application system-level configuration parameters to standardize and constrain response generation across domain-specific modules.

8. The method according to claim 7, wherein, The set of system-level configuration parameters includes at least one of the following: response tone specifications, output format rules, regulatory compliance constraints, and interaction behavior configuration files.

9. A chatbot system comprising one or more processors, the system being configured to: Receive user queries in one or more modalities, including text, audio, or video; Based on user-specific contextual data, determine the relevant functional areas for user queries; The query is routed to a domain-specific processing module among multiple modules, each of which is configured to perform operations related to a different functional domain associated with the user; Select and execute one or more tools from a centralized tool repository, each tool being configured to process and identify data associated with functional domains based on domain-level context data. Based on the output received from the selected and executed tool, one or more action cards are generated, wherein each action card enables user interaction; The one or more action cards are presented on a graphical user interface to enable user interaction with the one or more action cards; as well as Based on the input received from the user in response to the one or more action cards, perform one or more operations associated with the one or more action cards.

10. The system according to claim 9, wherein, The system is also configured to identify the user's intent based on the received query, wherein routing the query to the domain-specific processing module is based on the identified user's intent.

11. The system according to claim 9, wherein: The user-specific context data includes at least one of the following: a user identifier, a role designation indicating the user's access level, and a list of domain-specific modules that the user is allowed to access; as well as The domain-level context data includes at least one of the following: a domain identifier corresponding to the selected functional domain, and operational parameters related to the identified domain.

12. The system according to claim 11, wherein, The domain detection unit is configured as follows: Based on the user-specific context data, dynamically generate domain-specific prompts; and The generated domain-specific prompts are provided as input to the domain detection unit for selecting the relevant functional domain from multiple functional domains.

13. The system according to claim 9, wherein, Each domain-specific module is configured with access to a centralized tool unit, which includes: One or more data retrieval tools are configured to access structured business data from an integrated system, said integrated system including at least one of a point-of-sale database, a sales analytics engine, and an inventory system; and One or more action triggering tools are configured to build executable signals for backend task execution.

14. The system according to claim 9, wherein, Each action card includes one or more user-selectable options to confirm, modify, or cancel the proposed action.

15. The system of claim 9 further includes a global control unit configured as a set of application system-level configuration parameters to standardize and constrain response generation across domain-specific modules.

16. The system according to claim 15, wherein, The set of system-level configuration parameters includes at least one of the following: response tone specifications, output format rules, regulatory compliance constraints, and interaction behavior configuration files.

17. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a system, cause the system to perform a method for facilitating a chatbot system, the method comprising: Receive user queries in one or more modalities, including text, audio, or video; Based on user-specific contextual data, determine the relevant functional areas for user queries; The query is routed to a domain-specific processing module among multiple modules, each of which is configured to perform operations related to a different functional domain associated with the user; Select and execute one or more tools from a centralized tool repository, each tool being configured to process and identify data associated with functional domains based on domain-level context data. Based on the output received from the selected and executed tool, one or more action cards are generated, wherein each action card enables user interaction; The one or more action cards are presented on a graphical user interface to enable user interaction with the one or more action cards; as well as Based on the input received from the user in response to the one or more action cards, perform one or more operations associated with the one or more action cards.

Images