Voice-driven public information interaction terminal and scene skill loading system and method thereof

Abstract

The application belongs to the technical field of human-computer interaction and intelligent terminal, and particularly relates to a voice-driven public information interaction terminal and a scene skill loading system and method thereof. The system comprises a dispatch server and a public information interaction terminal, and the terminal is provided with a voice acquisition device, a display screen and a loudspeaker. The terminal carries a scene type identifier during registration; the server matches a self-declared applicable scene type list of each skill package according to the identifier, generates a scene skill routing table and issues it. The terminal performs local routing of user intent according to the routing table, and independently executes offline relying on the local routing table. The same skill package is configured differently through scene parameterization in different scenes. The application also comprises corresponding methods and terminals. The application solves the problems of lack of scene adaptation of the public information interaction terminal and service interruption in offline service, and improves scene adaptability and service continuity.

Description

Technical Field

[0001] This application belongs to the field of human-computer interaction and intelligent terminal technology, specifically involving voice-driven public information interaction terminals and their scene skill loading systems and methods. Background Technology

[0002] Public information interaction terminals, such as shopping mall wayfinding screens, hospital triage screens, and community announcement screens, are widely deployed in public places. The interactive functions of traditional terminals are usually provided by a fixed set of skills embedded in the device. Each skill can only run independently with uniform parameters and cannot automatically differentiate its service behavior and interaction process according to the type of deployment location.

[0003] To address these issues, existing technologies have introduced cloud-based skill routing solutions, such as cloud-based skill store models. In these solutions, the cloud server routes the corresponding skill pack based on the user's intent. However, the skill packs operate with a uniform configuration across various deployment scenarios, and the terminal cannot perceive its own physical location type, nor can it automatically switch the available skill set based on the location type. At the same time, the terminal relies on a continuous network connection to complete intent recognition and routing, resulting in service interruption in weak network or disconnection scenarios.

[0004] Therefore, existing technical solutions have long been limited by problems such as lack of scenario adaptation and offline service interruption when dealing with the multi-scenario deployment of public information interaction terminals, and there is a lack of a technical solution that can systematically solve the above defects. Summary of the Invention

[0005] This application proposes a voice-driven public information interaction terminal scenario skill loading scheme, which aims to solve the problems of scenario adaptation deficiency and offline service interruption in the deployment of existing technologies in multiple scenarios.

[0006] The first aspect of this application provides a voice-driven public information interaction terminal scene skill loading system, including a scheduling server and a public information interaction terminal connected by communication; The public information interaction terminal includes a voice acquisition device, a display screen for displaying interactive information, and a speaker for broadcasting voice feedback;

[0007] The scheduling server is configured as follows: Register a skill pack, which includes at least intent definition and scenario parameterization configuration, and declares a list of applicable scenario types during registration. The scenario parameterization configuration defines the differentiated behavior parameters of the skill pack under different scenario types. Receive a registration request sent by the public information interaction terminal, wherein the registration request includes a scenario type identifier; Check whether the applicable scenario type list of each skill package contains the scenario type identifier. If it does, add the skill package to the scenario skill routing table of the public information interaction terminal and send the scenario skill routing table to the public information interaction terminal so that the public information interaction terminal can perform local intent routing based on the scenario skill routing table in offline mode. The system receives an intent routing request sent by the public information interaction terminal. The intent routing request carries a user intent. According to the scene skill routing table, the user intent is routed to the target skill package. The scene type identifier is passed to the target skill package so that the target skill package selects the corresponding differentiated behavior parameters from its scene parameterization configuration according to the scene type identifier and executes the service operation of the skill package according to the differentiated behavior parameters.

[0008] The public information interaction terminal is configured as follows: Send a registration request to the scheduling server, the registration request including a scenario type identifier; Receive and store the scene skill routing table issued by the scheduling server; Collect user voice input; The user intent, target skill pack, and scene type identifier are obtained based on the communication reachability between the public information interaction terminal and the scheduling server. Based on the target skill package identifier corresponding to the user's intent, the corresponding target skill package is invoked and a scene type identifier is passed to it, so that the target skill package executes the service operation of the skill package according to the differentiated behavior parameters corresponding to the scene type identifier.

[0009] In some embodiments of this application, the scheduling server queries whether the applicable scenario type list declared by each skill package contains the scenario type identifier. If it does, the skill package is added to the scenario skill routing table of the public information interaction terminal. The method further includes: The scheduling server queries the custom skill packages registered by B2-level entities in the locations under the jurisdiction of the B1-level entity based on the B1-level entity identifier bound to the public information interaction terminal, and adds the custom skill packages to the scene skill routing table of the public information interaction terminal. Among them, the B1 level entity is the venue management party, the B2 level entity is the entity that occupies the venue, and the B2 level entity is under the jurisdiction of the B1 level entity; The public information interaction terminal receives and stores the scene skill routing table containing the custom skill package issued by the scheduling server.

[0010] In some embodiments of this application, the public information interaction terminal receives and stores the scene skill routing table issued by the scheduling server, and further includes: The public information interaction terminal maintains an active scenario skill routing table and a backup scenario skill routing table; In response to the scheduling server sending a scene skill routing table update to the public information interaction terminal, the public information interaction terminal writes the received update into the backup scene skill routing table, and after writing is completed, switches the backup scene skill routing table to the active scene skill routing table through atomic switching to achieve non-blocking update.

[0011] In some embodiments of this application, the public information interaction terminal is configured to obtain user intent, target skill pack, and scene type identifier based on the communication reachability between the public information interaction terminal and the scheduling server, including: In online mode, the voice input is sent to the scheduling server, and the user intent, target skill pack identifier, and scene type identifier returned by the scheduling server are received; or In offline mode, the user intent is determined, and the user intent is routed to the target skill pack according to the locally stored scene skill routing table, and the target skill pack identifier is obtained.

[0012] The second aspect of this application provides a voice-driven method for loading skills in a public information interaction terminal scenario, executed by a scheduling server in the system described in the first aspect of this application, including: Register a skill pack, which includes at least intent definition and scenario parameterization configuration, and declares a list of applicable scenario types during registration. The scenario parameterization configuration defines the differentiated behavior parameters of the skill pack under different scenario types. Receive a registration request sent by the public information interaction terminal, wherein the registration request includes a scenario type identifier; Check whether the applicable scenario type list of each skill package contains the scenario type identifier. If it does, add the skill package to the scenario skill routing table of the public information interaction terminal and send the scenario skill routing table to the public information interaction terminal so that the public information interaction terminal can perform local intent routing based on the scenario skill routing table in offline mode. The system receives an intent routing request sent by the public information interaction terminal. The intent routing request carries a user intent. Based on the scene skill routing table, the system routes the user intent to a target skill package and passes the scene type identifier to the target skill package. This enables the target skill package to select corresponding differentiated behavior parameters from its scene parameterization configuration based on the scene type identifier and execute the service operation of the skill package according to the differentiated behavior parameters.

[0013] In some embodiments of this application, the step of routing the user intent to the target skill package according to the scene skill routing table further includes: In the context of a voice dialogue session, based on the parsed intent parameters or invoked skill records in the dialogue context, the current user intent is routed to the associated skill package associated with the invoked skill, or the current user intent is routed to the subsequent skill package that depends on the invoked skill as a prerequisite skill, so as to realize intent relay across skill packages.

[0014] A third aspect of this application provides a voice-driven method for loading scene skills on a public information interaction terminal, executed by the public information interaction terminal in the system described in the first aspect of this application, including: Send a registration request to the scheduling server, the registration request including a scenario type identifier;

[0015] The system receives and stores the scene skill routing table issued by the scheduling server. The scene skill routing table is generated by the scheduling server by matching the applicable scene type list declared by the registered skill package according to the scene type identifier. The skill package includes at least an intent definition and a scene parameterization configuration. The scene parameterization configuration defines the differentiated behavior parameters of the skill package under different scene types. The user's voice input is collected through the voice acquisition device; The user intent, target skill pack, and scene type identifier are obtained based on the communication reachability between the public information interaction terminal and the scheduling server. The target skill package is invoked according to the target skill package identifier and the scene type identifier is passed to it, so that the target skill package performs the service operation of the skill package according to the differentiated behavior parameters corresponding to the scene type identifier.

[0016] In some embodiments of this application, the step of invoking the corresponding target skill package based on the target skill package identifier further includes: If the scene skill routing table stored locally marks the associated prerequisite skill of the target skill package, then the action processor of the prerequisite skill package is called and executed first, and then the action processor of the target skill package is called and executed to achieve local execution relay across skill packages.

[0017] A fourth aspect of this application provides a voice-driven public information interaction terminal, including a voice acquisition device, a display screen for displaying interactive information, a speaker for broadcasting voice feedback, a memory, and a processor. The memory stores a computer program, which, when executed by the processor, implements the method described in the third aspect of this application.

[0018] In some embodiments of this application, the voice acquisition device is a microphone array.

[0019] In summary, the voice-driven public information interaction terminal scene skill loading system, method, and public information interaction terminal provided in the embodiments of this application firstly, by carrying a scene type identifier during terminal registration, the scheduling server matches skill packages according to the identifier and generates a scene skill routing table, enabling the terminal to automatically load different skill sets in different locations; simultaneously, through scene parameterization configuration, the same skill package adaptively adjusts its interaction logic and service behavior in different scenarios, solving the problem of scene adaptation deficiency; secondly, by distributing the scene skill routing table to the terminal and configuring it to complete intent routing based on the local routing table in offline mode, the terminal can still autonomously invoke skills in weak network or disconnected environments, thereby solving the problem of offline service interruption. Finally, the above technical features work together synergistically, enabling the terminal to achieve a balance between multi-scene adaptation and offline availability while maintaining a unified core engine, achieving the beneficial effect of improving the terminal's multi-scene deployment flexibility and environmental adaptability. Attached Figure Description

[0020] The features and advantages of this application will become clearer with reference to the accompanying drawings, which are illustrative and should not be construed as limiting the application in any way. In the drawings:

[0021] Figure 1 This is a general diagram of a four-layer platform architecture shown in some embodiments of this application;

[0022] Figure 2 This is a flowchart illustrating the terminal startup and loading process according to some embodiments of this application;

[0023] Figure 3 This is a timing diagram of the full-link intent routing for voice interaction according to some embodiments of this application;

[0024] Figure 4 This is a flowchart illustrating a new scenario plug-in extension based on some embodiments of this application;

[0025] Figure 5 This is a system architecture diagram of a voice-driven public information interaction terminal scenario skill loading system according to some embodiments of this application;

[0026] Figure 6 This is a complete data structure stored in the cloud by the terminal in one embodiment of this application;

[0027] Figure 7 This is a flowchart illustrating a voice-driven skill loading method for a public information interaction terminal scenario, according to some embodiments of this application. The method comprises... Figure 5 The scheduling server executes the command.

[0028] Figure 8 This is a flowchart illustrating a voice-driven skill loading method for a public information interaction terminal scenario, according to some embodiments of this application. The method comprises... Figure 5 Execution of public information interaction terminals in China;

[0029] Figure 9 This is a schematic diagram of the structure of a public information interaction terminal according to some embodiments of this application. Detailed Implementation

[0030] In the following detailed description, numerous specific details of this application are illustrated by example to provide a thorough understanding of the relevant disclosure. However, it will be apparent to those skilled in the art that this application can be practiced without these details. It should be understood that the terms “system,” “apparatus,” “unit,” and / or “module” used in this application are one way of distinguishing different parts, elements, sections, or components at different levels in a sequential arrangement. However, these terms may be replaced with other expressions if other expressions can achieve the same purpose.

[0031] It should be understood that when a device, unit, or module is referred to as being "on," "connected to," or "coupled to" another device, unit, or module, it may be directly connected to or coupled to or communicate with other devices, units, or modules, or there may be intermediate devices, units, or modules present, unless the context explicitly indicates otherwise. For example, the term "and / or" as used herein includes any one and all combinations of one or more of the relevant listed items.

[0032] The terminology used in this application is for the purpose of describing specific embodiments only and is not intended to limit the scope of this application. As shown in the specification and claims of this application, unless the context clearly indicates otherwise, words such as "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate that explicitly identified features, integrals, steps, operations, elements, and / or components are included, and such expressions do not constitute an exclusive list, and other features, integrals, steps, operations, elements, and / or components may also be included.

[0033] Referring to the following description and accompanying drawings, these and other features and characteristics, operating methods, functions of related structural elements, combinations of parts, and economics of manufacture of this application can be better understood, wherein the description and drawings form part of the specification. However, it is clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. It is understood that the drawings are not drawn to scale.

[0034] Various structural diagrams are used in this application to illustrate various variations of the embodiments according to this application. It should be understood that the preceding or following structures are not intended to limit this application. The scope of protection of this application is determined by the claims.

[0035] Public information interaction terminals refer to devices deployed in public places such as shopping malls, hospitals, communities, and airports, integrating displays, microphones, speakers, and network communication modules to provide information display and interactive services to the public. Their core functions are provided by several skill packages, each containing intent definitions, scene parameterization configurations, and action processors to complete a specific service task (such as parking payment, department navigation, or community announcement inquiry).

[0036] Currently, typical public information interaction terminals employ either pre-installed skill packages or cloud-based routing solutions. In these solutions, skill packages operate with a uniform configuration, failing to automatically differentiate their service behaviors and interaction processes based on the type of deployment location. Furthermore, the terminals rely on a continuous network connection to complete intent recognition and skill routing, resulting in service interruptions in weak network or disconnection scenarios.

[0037] As described in the background section, this solution has the following drawbacks: lack of scenario adaptation due to the skill pack running with a unified configuration, and offline service interruption due to reliance on a continuous network connection.

[0038] To systematically address the aforementioned shortcomings, this application proposes a voice-driven public information interaction terminal scenario skill loading scheme. The scheme aims to achieve scenario-adaptive, all-time availability, and rapid expansion of terminal service capabilities by constructing an architecture system of "unified cloud configuration, terminal scenario awareness, and skill plug-in operation".

[0039] like Figure 1 (As shown in the overall diagram of the four-layer platform architecture in some embodiments of this application), this application constructs a four-layer technical architecture that decouples from the core engine to specific skills. This architecture uses a unified core engine (ASR / NLU / DM / TTS) as its brain, decoupling devices from scenarios through a scenario adaptation layer, loading differentiated business skill packages through a skill plug-in architecture, and then enabling on-demand overlay of custom skills by the entrant through a B2-level subject association layer, thereby forming a flexibly pluggable service capability foundation on the physical terminal.

[0040] Based on this, this application establishes as follows Figure 2 (A flowchart illustrating the terminal startup and loading process shown in some embodiments of this application) and Figure 3 The dual-path operation mechanism is shown in the timing diagram of the full-link intent routing for voice interaction illustrated in some embodiments of this application. Figure 2 As shown, during the startup phase, the terminal receives the latest scenario configuration and routing table from the cloud, enabling automated updates and local caching of business skills; while during the runtime phase, as... Figure 3 As shown, the system queries the locally cached scene skill routing table to accurately map the user's natural language intent to the skill package applicable to the current scene and execute it. When the network is available, the system synchronizes the routing table version update from the cloud. When the network is interrupted, it directly completes routing and execution independently based on the local routing table, ensuring a seamless service experience for the terminal under network fluctuations.

[0041] Furthermore, in response to the complex commercial environment involving multiple merchants and multiple buildings, this application has designed the following... Figure 4 The low-threshold expansion solution shown in the flowchart of the new scenario plug-in expansion shown in some embodiments of this application. This solution allows the backend to quickly complete the deployment of new scenarios and the association of nearby services of B2-level entities without modifying the terminal core firmware through simple "scenario type registration" and "skill package association" operations, thereby realizing the continuous expansion of the system ecosystem and cross-scenario collaboration.

[0042] The technical solution of this application will be further described below with reference to the accompanying drawings.

[0043] Figure 5 This is a system architecture diagram of a voice-driven public information interaction terminal scenario skill loading system according to some embodiments of this application. For example... Figure 5 As shown, this application provides a voice-driven public information interaction terminal scene skill loading system, the system including a scheduling server and a public information interaction terminal connected by communication.

[0044] The public information interaction terminal is deployed in public places such as shopping malls, hospitals, communities, airports, and industrial parks. It includes a voice acquisition device, a display screen for showing interactive information, a speaker for broadcasting voice feedback, a memory, and a processor. The voice acquisition device is used to collect user voice input; the display screen is used to show users interactive information, business processing interfaces, and advertising content; the speaker is used to broadcast voice feedback; the memory is used to store program instructions and local data (including scene skill routing tables); and the processor is used to execute the program instructions.

[0045] In some embodiments of this application, the public information interaction terminal maintains an active scene skill routing table and a backup scene skill routing table. In response to the scheduling server issuing a scene skill routing table update to the public information interaction terminal, the public information interaction terminal writes the received update into the backup scene skill routing table, and after writing, switches the backup scene skill routing table to the active scene skill routing table via an atomic switch to achieve non-blocking updates.

[0046] The scheduling server is connected to the public information interaction terminal and is used to manage functions such as skill package registration, device registration, scene-skill mapping, and intent routing.

[0047] At the software functionality level, such as Figure 1 As shown, this application adopts a four-layer architecture: "Core Engine Layer + Scene Adaptation Layer + Skill Plugin Layer + B2-Level Entity Association Layer". The core engine layer, primarily deployed on the scheduling server, provides basic engine capabilities such as Automatic Speech Recognition (ASR), Non-Local Understanding (NLU), Dialogue Management (DM), Text-to-Speech (TTS), and Wake Detection, as well as functions like session management and intent routing. It serves as the intelligent hub of the entire system. The scene adaptation layer is distributed on both sides of the scheduling server and the public information interaction terminal. It is responsible for matching skill packages based on the terminal's scene type identifier and generating a scene skill routing table, which is received and stored locally by the terminal, achieving decoupling between the device and the scene. The skill plugin layer is also distributed on both sides. The scheduling server maintains a skill registration center to manage the registration and declaration of skill packages. The terminal is responsible for downloading and storing skill packages with a local execution mode, carrying differentiated business capabilities. The B2-level entity association layer, deployed on the scheduling server, is used to query custom skill packages registered by B2-level entities and add them to the routing table, enabling on-demand expansion of services for entrants. In addition, the system also includes a management backend layer and an infrastructure layer: the management backend layer provides supporting services such as B-end account management, content review, device management and settlement and billing; the infrastructure layer provides basic capabilities such as database, venue topology services, message push and payment gateway, providing operational support for the above four-layer core architecture.

[0048] The public information interaction terminal (hereinafter referred to as the interaction terminal) of this application is deployed in various scenarios such as shopping malls, hospitals, communities, and airports. Different locations within the same scenario often house different entities—merchants, departments, enterprises, etc. These entities each have differentiated service needs (such as customized skills, exclusive activities, and data isolation). Therefore, it is necessary to establish a clear location organizational hierarchy under a unified platform architecture to distinguish the boundaries of rights and responsibilities between the location management and the occupants, and to provide an organizational foundation for subsequent mechanisms such as skill loading, data isolation, and proximity association.

[0049] Based on this, this application adopts a two-tier organizational structure to manage physical locations and their tenants. The B1-level entity is the location manager, responsible for the overall operation of one or more physical locations; the B2-level entity is the tenant, belonging to the location scope under the jurisdiction of the B1-level entity. The specific meanings of B1 / B2 vary depending on the scenario type. Typical B1 / B2-level entities for typical scenario types are shown in Table 1:

[0050] Table 1: B1 / B2 level subjects for typical scene types community Property Management Center Merchants (convenience stores, laundromats, pet shops, etc.) shopping mall Shopping Mall Operations Department Merchants (restaurants, retail stores, cinemas, etc.) Hospital Hospital management Departments / faculties (Internal Medicine, Laboratory, Pharmacy, etc.) Industrial park Park Management Committee Resident companies (technology companies, startup teams, etc.) airport Airport management Airlines, duty-free shops, restaurants, etc.

[0051] Each interactive terminal is bound to a B1-level entity, and the service scope and skills of the B2-level entity are associated with that B1-level entity. The core function of this hierarchical relationship is that when a user interacts with the terminal via voice, the system automatically limits its "service scope" to the location and surrounding area. For example, "What are some good restaurants nearby?" searches for restaurants within the mall, not restaurants throughout the city; "Help me register for an appointment" searches for departments and available appointments at the hospital, not hospitals throughout the city.

[0052] Based on the aforementioned B1 / B2 tiered system, this application adopts a two-tier skill loading mechanism. The first tier consists of basic scene skills, defined by the scene→skill mapping table. Terminals automatically load these skills according to the scene type, representing the minimum common skill set for that scene type. The second tier comprises B2-level entity-defined skills, independently registered by each B2-level entity within the venue. The final terminal skill list = basic platform skills (all scenes) + basic scene skills + B2-level entity-defined skills for that venue. Merging rules: basic platform skills have the highest priority, followed by basic scene skills, and B2-level customized skills are loaded last. Skills with the same name are overwritten by those with higher version numbers. Within the same mall scene, Mall A loads additional customized skills due to the presence of hot pot restaurants and cinemas, while Mall B loads different skills due to the presence of different merchants—thus achieving the flexibility of "scene type minimum guarantee + B2-level entity on-demand expansion."

[0053] This application also supports cross-scenario sharing of skill packages. Some skill packages can be effective simultaneously in multiple scenario types, eliminating the need to register or maintain multiple versions separately for each scenario. For example, the ad_audit (ad audit management) skill package, as a basic platform skill, is enabled by default on terminals in all scenarios such as communities, shopping malls, hospitals, and airports, ensuring consistent execution of advertising strategies across all scenarios. Another example is that chain merchants can register their custom skills simultaneously in both community and shopping mall scenario types. The same skill package can use community discounts as the main path in the community scenario and shopping mall promotions as the main path in the mall scenario—achieving differences through scenario parameterization configuration, while sharing the same core dialogue logic and ad audit rules.

[0054] The scene type identifier (scene_type) is used to identify the type of physical location where the terminal is deployed. Table 2 shows the typical scene type configurations for the basic skill packages in this application.

[0055] Table 2: Typical Scenario Basic Skill Package Configuration Community Community Housing Parking lot entrances and exits, building entrances and elevators, community square parking + flea_market + home_service + pet_care + monthly_card shopping mall Business Center Elevator entrance, floor corridors, atrium, parking lot brand_guide + coupon_center + indoor_nav + ad_interact + parking_link Hospital Hospital Outpatient lobby, waiting area, inpatient entrance, parking lot med_guide + registration + payment + queue_info + dept_intro Industrial Park Industrial Park Office building lobby, cafeteria entrance, shuttle bus stop recruitment + space_rental + shuttle_bus + canteen + meeting_room Airport Airport Terminal, parking lot, arrival hall flight_info + gate_nav + baggage + pickup + duty_free

[0056] In addition, the basic platform skills, including qr_bridge (QR code bridging), im_sync (online and offline IM synchronization), and ad_audit (ad review management), are not included in the scenario-specific configuration and are enabled by default in the skill routing table of all terminals as platform infrastructure.

[0057] The scheduling server maintains a scene-to-skill mapping table, which records the set of available skill packs under each scene type identifier. This mapping table is dynamically constructed by matching the list of applicable scene types declared when the skill pack is registered.

[0058] Before providing services, each interactive terminal needs to determine its own scene type and location in order to obtain a matching set of skills. In some embodiments of this application, the device-scene binding mechanism is as follows:

[0059] Before deployment, each interactive terminal is pre-configured for its location information by the administrator in the backend. After registration, a complete device profile is generated in the cloud, including fields such as device identifier, scene type, location information, bound B1-level entity identifier, and a list of B2-level entities registered in that location. The scene type, location, and affiliated B1 organization fields in the device registration request are primarily obtained through administrator pre-configuration. Before installation and deployment, the B1-level administrator pre-creates the terminal's configuration profile through the backend management system, specifying the scene type, location name, detailed location, and affiliated B1 organization. The backend generates a device registration code (a 6-digit alphanumeric code) or a registration QR code. After the terminal is powered on for the first time, the installer enters the registration code or scans the registration QR code on the terminal's local interface. When the terminal initiates a registration request to the cloud, it only carries the registration code and its own hardware information (model, MAC address, screen parameters, etc.). The cloud queries the pre-configured profile based on the registration code to complete the device-location binding and returns a complete scene_config. This method ensures the accuracy of location information and the authority of location attribution, and the terminal does not need to repeatedly report location information during registration.

[0060] In addition, the binding information can be obtained or updated in the following ways: If the terminal has a built-in GPS / BeiDou positioning module (suitable for outdoor deployment scenarios, such as parking lot entrances and exits), it can automatically obtain latitude and longitude coordinates, but the organizational affiliation information such as scene_type and b1_org_id still needs to be manually specified by the administrator; After the terminal is connected to the network, the cloud can roughly infer the city and administrative region based on its public IP address as an auxiliary verification method; If the terminal is migrated from location A to location B, the administrator can change its bound b1_org_id and location in the background, and the terminal will receive the new scene configuration and automatically adjust the skill list when it receives its next heartbeat.

[0061] Figure 6 In one embodiment of this application, the terminal stores a complete data structure in the cloud, wherein fields such as scene_type, location, and b1_org_id are pre-configured by the administrator in the background, hardware_info is reported when the terminal registers, and affiliated_b2_entities are automatically maintained by the background based on the B2 level entity entry status of the venue.

[0062] This application also supports proximity association for B2-level entities. The location information (latitude and longitude coordinates) carried during terminal registration is used not only to determine the scene type and location affiliation, but also to automatically discover other B2-level entities near the terminal. For example, in a community scenario, an all-in-one machine deployed at the west gate parking lot entrance of the community can, in addition to associating with B2-level entities (merchants within the community) located in the community, automatically discover other B2-level entities within a 500-meter radius (such as street-front shops outside the community) based on the terminal's location, and incorporate their services into the terminal's scene skill routing table. The proximity association range (e.g., 500 meters, 1 kilometer) can be configured by scene type through the backend management system, enabling the system to provide users with a wider range of services beyond the boundaries of a single location.

[0063] In this application, the skill package is an independent, pluggable functional module. The actual implementation of the skill package is divided into the following three types, each corresponding to a different access method, but all sharing the same intent definition, dialogue flow, and UI / TTS template specifications.

[0064] Table 3: Implementation Methods of Skill Packs Built-in code package `bundled` Submitted as a .zip archive, containing action handlers (JS / WASM), to be deployed locally on the client or run in a cloud sandbox. Skills required for complex business logic and tightly coupled NLU processes. MCP tools `mcp` Developers provide the URL of the MCP (Model Context Protocol) Server and the tool description JSON. The platform uses the MCP protocol to call the tools exposed by this server to complete skill execution. Scenarios requiring existing third-party services with MCP Server and dynamic discovery tool capabilities. HTTPAPI `http_api` Developers provide the HTTP API endpoint URL and request / response schema (OpenAPI 3.0 format). When a skill is triggered, the platform sends an HTTP request to this endpoint and parses the response. Integration with existing RESTful APIs and third-party SaaS services.

[0065] Regardless of the integration type, skill packs must submit the following common components: manifest.json (skill pack metadata, including integration type, list of applicable scenario types, priority, etc.), intent_definitions (NLU intent definitions, including training data and regular expressions / templates), dialog_flows (dialogue flow definitions, including multi-turn dialogue state machines), action_handlers (intent action handlers, only provided for bundled types), ui_templates (terminal screen display templates), and tts_templates (TTS broadcast templates).

[0066] Each skill pack declares a list of applicable scenario types during registration and includes scenario parameterization configurations, defining its differentiated behavioral parameters in different scenarios. Taking the parking skill pack as an example, in a community scenario, its main functional paths are "finding your own parking space," "monthly pass renewal," and "shared parking space"; in a shopping mall scenario, its main functional paths are "free parking with a certain spending amount," "receiving parking coupons," and linkage with merchant consumption; and in a hospital scenario, its main functional path is "parking discounts for medical visits." The same skill pack does not require developing two sets of code; the differences are achieved solely through scenario parameterization configurations. These differentiated parameters cover multiple dimensions, including primary_flow, features, payment_priority, and linked_skills. The skill pack also supports both cloud execution and local terminal execution modes, suitable for most business scenarios and latency-sensitive or offline-running scenarios, respectively.

[0067] Figure 7 This is a flowchart illustrating a voice-driven skill loading method for a public information interaction terminal scenario, according to some embodiments of this application. The method comprises... Figure 5 The scheduling server executes the command. For example... Figure 7 As shown, the method includes:

[0068] S710, Register a skill package, wherein the skill package includes at least intent definition and scene parameterization configuration, and declares a list of applicable scene types during registration, wherein the scene parameterization configuration defines the differentiated behavior parameters of the skill package under different scene types.

[0069] The S710 is used to register skill packages to integrate different service capabilities into the platform as standardized plug-ins. Specifically: The scheduling server maintains the skill registry center for registering skill packages. Each skill package is an independent, pluggable functional module, containing at least an intent definition, scenario parameterization configuration, and priority information, and declaring a list of applicable scenario types during registration. The intent definition describes the user semantic goals that the skill package can handle; the scenario parameterization configuration defines the differentiated behavioral parameters of the skill package in different scenario types; and the priority information is used for arbitration and ranking when multiple skill packages match the same user intent. After a developer submits a skill package, the platform automatically verifies and registers it in the skill library, and the administrator then associates the skill package with the target scenario type.

[0070] S720, receive a registration request sent by the public information interaction terminal, the registration request including a scenario type identifier.

[0071] The S720 is used to receive registration requests from public information interaction terminals to establish a binding relationship between the terminal and the scenario type. Specifically: The scheduling server receives a registration request from a public information interaction terminal, the registration request containing a scene type identifier. Based on the information in the registration request, the scheduling server completes the device-location binding and returns the complete scene configuration.

[0072] S730, query whether the applicable scenario type list of each skill package contains the scenario type identifier. If it does, add the skill package to the scenario skill routing table of the public information interaction terminal, and send the scenario skill routing table to the public information interaction terminal so that the public information interaction terminal can perform local intent routing based on the scenario skill routing table in offline mode.

[0073] The S730 is used to generate and distribute scene skill routing tables to enable terminals to have local intent routing capabilities. Specifically: The scheduling server queries the scene-skill mapping table to determine the set of skill packages corresponding to the scene type identifier in the registration request, and adds these skill packages to the terminal's scene skill routing table. Simultaneously, based on the B1-level entity identifier bound to the terminal, the scheduling server queries the custom skill packages registered by B2-level entities within locations under the jurisdiction of that B1-level entity, and adds these custom skill packages to the terminal's scene skill routing table as well. The scheduling server then distributes the complete scene skill routing table to the terminal, allowing the public information interaction terminal to perform local intent routing based on the scene skill routing table in offline mode.

[0074] S740, receive the intent routing request sent by the public information interaction terminal. The intent routing request carries the user intent. According to the scene skill routing table, route the user intent to the target skill package and pass the scene type identifier to the target skill package so that the target skill package selects the corresponding differentiated behavior parameters from its scene parameterization configuration according to the scene type identifier and executes the service operation of the skill package according to the differentiated behavior parameters.

[0075] The S740 is used to receive intent routing requests and route user intents to the target skill set to complete the service execution for voice interaction. Specifically: The scheduling server receives intent routing requests sent by public information interaction terminals, which carry the user's intent. For example... Figure 3 As shown, after the user's voice input undergoes ASR→NLU processing, the NLU engine outputs the user's intent and its confidence score. The skill scheduling engine in the scheduling server executes the following routing logic based on the terminal's scene skill routing table:

[0076] Step 1: Query the device scenario. Obtain the scenario type identifier bound to the terminal based on the terminal identifier.

[0077] Step 2: Obtain the list of available skills for the scene. Filter the available skill packs for the scene using the Scene → Skill Mapping table. This set must contain at least the scene's basic skills and the B2-level custom skills for that location.

[0078] Step 3, Intent → Skill Matching. Traverse the set of available skill packages, match the current user's intent with the intent definition of each skill package to form a candidate set, and record the priority and NLU confidence of each candidate skill.

[0079] Step 4, Priority Arbitration. If the candidate set is empty, a general fallback skill is returned to handle unidentified intents; if there is a unique match, that skill is returned directly; if multiple skills match the same intent, the highest-ranked skill is returned based on a combination of priority and confidence.

[0080] Some embodiments of this application also include cross-skill package intent relay. That is, within the context of a voice dialogue session, the skill scheduling engine routes the current user intent to an associated skill package related to the invoked skill, or routes the current user intent to a subsequent skill package that depends on the invoked skill, based on the parsed intent parameters or invoked skill records in the dialogue context, thus achieving cross-skill package intent relay. For example, if a user says "Check flights to Beijing for tomorrow" and "Book a flight for me" in a dialogue, the first statement is routed to the `flight_query` skill package, parsing out the intent parameters "tomorrow" and "Beijing"; the second statement, based on the parsed intent parameters and the invoked skill record `flight_query` in the context, is routed to the `booking` skill package as a subsequent skill execution. The `booking` skill package directly reuses the parsed time and destination parameters, without requiring the user to provide them again.

[0081] Step 5, Skill Execution. The action handler of the target skill package is invoked to execute the service operation, while the scene type identifier and device context are passed to the target skill package. The scene type identifier enables the target skill package to select corresponding differentiated behavior parameters from its scene parameterization configuration and execute according to those parameters. For example, the parking skill package presents different functional paths in community and shopping mall scenarios. The same skill package does not need to develop two sets of code; the differences are achieved solely through scene parameterization configuration.

[0082] Step 6, Context Update. Using the session management mechanism described in the system embodiment, the context information of this interaction is recorded, including the current skill, current intent, and execution result, providing contextual basis for multiple rounds of interaction in the current session.

[0083] Figure 8 This is a flowchart illustrating a voice-driven skill loading method for a public information interaction terminal scenario, according to some embodiments of this application. The method comprises... Figure 5 Executed by a public information interaction terminal. For example... Figure 8 As shown, the method includes: S810, a registration request is sent to the scheduling server, the registration request containing a scenario type identifier.

[0084] The S810 is used to send a registration request to the scheduling server to complete the binding between the terminal and the scene type. Specifically: The interactive terminal sends a registration request to the scheduling server, carrying a registration code and hardware information. The scheduling server completes the device-location binding based on the registration code and then returns the scene configuration.

[0085] S820, receive and store the scene skill routing table issued by the scheduling server, wherein the scene skill routing table is generated by the scheduling server by matching the applicable scene type list declared by the registered skill package according to the scene type identifier, and the skill package includes at least intent definition and scene parameterization configuration, and the scene parameterization configuration defines the differentiated behavior parameters of the skill package under different scene types.

[0086] The S820 is used to receive and store scene skill routing tables to establish local intent routing criteria. Specifically: The interactive terminal receives the scene skill routing table from the scheduling server and stores it locally. For example... Figure 2 As shown, when the interactive terminal starts up, it reads the local cache and then obtains the latest scene configuration from the cloud. It compares the version number of the scene configuration in the local cache with the version number in the cloud. If the cloud has been updated, it compares the skill list item by item. For skill packages with execution mode of local and updated, it initiates download and updates to the local machine. For skill packages with execution mode of cloud, it only updates the routing table entries.

[0087] S830, the user's voice input is collected through the voice acquisition device.

[0088] The S830 is used to collect user voice input to trigger voice interaction processes. Specifically: The terminal collects user voice input through a voice acquisition device, which is then converted into text by an ASR engine. In some embodiments of this application, the voice acquisition device is a microphone array. In scenarios with high traffic, such as shopping malls and hospital lobbies, the terminal extracts the target user's voice input from noisy backgrounds through sound source localization to improve voice recognition accuracy.

[0089] S840, obtain the user intent, target skill package and scene type identifier based on the communication reachability between the public information interaction terminal and the scheduling server.

[0090] The S840 is used to select online or offline mode based on network reachability to complete intent routing and ensure service continuity. Specifically: In online mode, the terminal sends voice input to the scheduling server, which completes the entire link from ASR to NLU to intent routing and receives the returned user intent, target skill package identifier, and scene type identifier. In offline mode, the terminal reads the locally cached scene skill routing table, determines the user intent, matches the user intent to the target skill package according to the local routing table, and obtains the target skill package identifier. Skills in cloud mode can still be invoked normally offline through cached routing entries.

[0091] S850, the corresponding target skill package is invoked according to the target skill package identifier and the scene type identifier is passed to it, so that the target skill package executes the service operation of the skill package according to the differentiated behavior parameters corresponding to the scene type identifier.

[0092] The S850 is used to invoke the target skill pack and pass in a scene type identifier so that it executes according to scene-specific parameters. Specifically: The terminal invokes the corresponding skill package based on the target skill package identifier and passes in a scene type identifier. The skill package, based on the passed scene type identifier, selects the corresponding differentiated behavior parameters from its scene parameterization configuration and executes them. For skill packages with a local execution mode, the terminal executes their action handlers locally; for skill packages with a cloud execution mode, the terminal displays the execution results returned by the server.

[0093] In some embodiments of this application, if the scene skill routing table stored locally marks the associated prerequisite skill of the target skill package, the terminal first calls and executes the action handlers of the prerequisite skill package, and then calls and executes the action handler of the target skill package to achieve local execution relay across skill packages. For example, in a community scenario, a user queries "How do I renew my parking space monthly card when it expires?" The intent route first matches the parking skill package (target skill package), and the routing table of the parking skill package marks the associated prerequisite skill monthly_card. The terminal first calls the action handler of the monthly_card skill package to query the monthly card information, and then calls the action handler of the parking skill package to perform the renewal operation. Both skill calls and executions are completed locally in sequence without cloud intervention.

[0094] Figure 9 This is a schematic diagram illustrating the structure of a public information interaction terminal according to some embodiments of this application. The interaction terminal is installed in a public setting and is used to provide content display and business processing services adapted to the deployment scenario through voice interaction. Figure 9 As shown, the public information interaction terminal 900 includes: Display screen 910: Connected to the processor 940, used to display interactive information, business processing interface and advertising content, etc.

[0095] Microphone array 920: Connected to the processor 940, it consists of multiple microphones and is used to collect the voice signals of the target user.

[0096] Speaker 950: Connected to the processor 940, used for broadcasting voice feedback.

[0097] Memory 930: Connected to the processor 940, used to store computer-executable programs and local data (including scene skill routing tables).

[0098] Processor 940: Used to implement the method described in S810-S850 when executing the computer-executable program.

[0099] To more clearly illustrate the practical application logic of this application, one embodiment of this application takes the "parking payment" business, which is the most typical in public scenarios, as an example to demonstrate the differentiated operation logic of the same parking skill package under different scenario types.

[0100] Community Scene Mr. Zhang, a resident of Xingfuli Community, was about to leave the community when he stopped his car in front of the all-in-one machine at the parking lot exit. The machine was registered as a community scenario during deployment, and the B1-level entity bound to it was "Xingfuli Property Management Center". The B2-level entities included resident merchants such as a milk tea shop, a pet store, and a laundry service.

[0101] During startup, the terminal obtains the scene skill routing table from the scheduling server, which includes the basic skill package for the community scene (parking, flea_market, home_service, pet_care, monthly_card) as well as the custom skill packages registered by each B2-level entity. In the scene parameterization configuration of the parking skill package under the community scene, primary_flow is "resident_parking", and the main functional paths are "find your own parking space", "monthly card renewal", and "shared parking space", with monthly card priority.

[0102] After Mr. Zhang spoke the wake-up word to the all-in-one machine, the terminal switched from standby mode to dialogue mode. Mr. Zhang said, "I want to pay the parking fee." The terminal communicated normally with the dispatch server and sent the voice message to the dispatch server in online mode. The dispatch server's skill scheduling engine executed the routing logic: query the device scene type "community" → obtain the list of available skills for the community scene → match the "pay parking fee" intent to the parking skill package → pass the scene type identifier "community" to the parking skill package. The parking skill package, based on the community scene parameterization configuration, executed the monthly card deduction as the main path. After querying Mr. Zhang's vehicle information, it announced, "Monthly card account balance is sufficient, 12 yuan has been automatically deducted, please leave within 15 minutes," and the screen simultaneously displayed a payment success confirmation.

[0103] If the network connection between the terminal and the scheduling server is interrupted, the terminal switches to offline mode: it reads the locally cached scene skill routing table, determines the user's intent as "parking_payment" on the terminal side, and routes the user to the parking skill package based on the local routing table. The parking skill package executes its action_handlers locally, calls the locally cached vehicle information to complete the monthly card deduction, and feeds back the result to Mr. Zhang through the display screen and speaker. Throughout the offline execution process, the terminal continuously retryes cloud synchronization in the background, and re-uploads the interaction records after the network is restored.

[0104] Shopping mall scene In contrast, the same parking skill package exhibits different behaviors when deployed in a shopping mall scenario. In Mall A, a customer, Ms. Li, says "I need to pay my parking fee" at the parking exit terminal. This terminal is registered as a mall scenario, and the bound B1-level entity is "Mall A Operations Department". In the scene parameterization configuration of the parking skill package in the mall scenario, primary_flow is "shopper_parking", the main function path is "free parking for purchases over a certain amount" and "receive parking coupons", and the payment priority is consumption deduction first.

[0105] After the scheduling server passes the scene type identifier "mall" to the parking skill package, the skill package retrieves Ms. Li's shopping records at the mall today. Finding that her spending has reached the threshold for free parking, it announces, "Your spending today has reached 200 yuan, qualifying you for 3 hours of free parking. This has been automatically deducted from your payment. Happy shopping!" Ms. Li can then leave without any further payment. The same skill package eliminates the need to develop two sets of code; completely different business logic can be presented in community and mall scenarios simply through scene parameterization configuration.

[0106] Another embodiment of this application takes the registration of custom skills in a milk tea shop in a community scenario as an example to demonstrate the loading process of custom skills for a B2 level subject.

[0107] A milk tea shop, a resident business in the Xingfuli residential community, registered a custom skill called "New Product Tasting Invitation" in the property management center's backend. This skill includes the intent definition "taste_invitation" and the corresponding dialogue flow and coupon distribution logic. When registering the skill, the applicable scenario type was declared as "community" and it was associated with the B1 level entity "Xingfuli Property Management Center".

[0108] When generating the scene skill routing table for the integrated machine at the community entrance, the scheduling server, in addition to loading the basic community scene skills, also queries the custom skills registered by a certain milk tea shop, a B2-level entity under the jurisdiction of the property management center, based on the B1-level entity identifier bound to the terminal, and adds them to the routing table. When a user says "I want to drink milk tea" to the integrated machine, the scheduling server routes the user's intent to the custom skill of the milk tea shop. After the skill is executed, it announces "This week's new product at [Milk Tea Shop Name], Mango Pomelo Sago, is buy one get one free. Do you need a coupon?", and the coupon QR code is displayed on the screen simultaneously.

[0109] Another embodiment of this application demonstrates the new scene plug-in expansion capability of this application by taking the addition of a "sports stadium" scene type as an example.

[0110] The operator needs to deploy an interactive terminal in a sports stadium, a scenario type that does not exist in the existing system. The operator registers a new scenario type, "stadium," in the backend management system and associates it with default skill packages: venue_guide (venue navigation), ticket_query (ticket inquiry), concept_stand (food and beverage sales), and parking_link (parking linkage). Subsequently, all B2-level entities (such as various food and beverage merchants) registered under this scenario type are associated with this scenario.

[0111] Terminals deployed in this sports venue carry the scene type identifier "stadium" during registration. The scheduling server, upon finding that this scene type is already registered, retrieves the default skill package list from the scene→skill mapping table, overlays the custom skills of each B2-level subject, generates a scene skill routing table, and distributes it to the terminal. The terminal can then provide services normally. The entire process requires no modification to the core engine code or terminal firmware upgrades. When similar terminals are deployed in other sports venues, the configuration of this scene type can be directly reused, achieving rapid expansion through "one-time registration, multi-venue reuse." The above-mentioned new scene plug-in expansion process is as follows: Figure 4 As shown.

[0112] To verify the technical effectiveness of the technical solution described in this application, one embodiment of this application uses the newly added "Government Service Center" scenario as a typical case to compare the workload of the traditional single-scenario dedicated system solution and the plug-in skill package solution of this application. The calculation assumptions are as follows: the team configuration is a 3-person development team (1 backend engineer + 1 NLU / dialogue engineer + 1 frontend / UI engineer), all of whom have experience in public terminal system development; the core functions to be implemented in the new scenario include service guide query, window appointment and number collection, processing progress query, material list preparation, and frequently asked questions, totaling 5 service capabilities; it needs to connect to 3 external systems: government queuing and calling API, service progress query API, and material list database. The traditional solution assumes that the existing mall scenario codebase is used as the starting point for copying, and scenario adaptation and secondary development are carried out on the basis of the existing code.

[0113] Development workload based on traditional solutions Traditional single-scenario dedicated system solutions adopt a code library copying + adaptation approach, and the workload of each stage is shown in Table 4:

[0114] Table 4: Development Workload for Government Service Center Scenarios Based on Traditional Solutions Requirements and Analysis Scenario Requirements Survey 6 Requirements and Analysis API Integration Survey 3 Core Development Copy the existing scene codebase and trim it. 5 Core Development NLU model retraining (≥5,000 corpus annotations + training + evaluation) 15 Core Development Dialogue management process development (state machine with 5 intents) 18 Core Development Backend API integration development (3 APIs including authentication / retry) 12 Core Development Terminal UI template development (approximately 20 template pages) 12 Core Development TTS broadcast template writing (approximately 60 templates) 5 Testing and integration Unit testing + integration testing + regression testing 10 Testing and integration On-site joint debugging and UAT 8 Deployment and Documentation Production Deployment + Gray Scale 5 Deployment and Documentation Operations and maintenance documentation + training 3 total 102 people-days

[0115] Based on a team of 3 people and an average of 20 working days per month, it would take approximately 5.1 months to develop and launch a new scenario using traditional solutions.

[0116] Workload of this application plan This application adopts a plug-in-based skill package development scheme, and the workload of each stage is shown in Table 5:

[0117] Table 5: Development Workload for Government Service Center Scenarios Based on This Application's Solution Skill pack development NLU intent definition (intents.yaml for 5 intents, approximately 400 example sentences) 3 No large-scale corpus annotation is required; only example corpora are needed for incremental fine-tuning of NLU in the cloud. Skill pack development Dialogue flow definition (state machine of 5 intents, reusing the platform's DM framework) 5 Reusing the DM framework reduces state machine coding work by approximately 70%. Skill pack development Action handler development (5 handlers, calling 3 APIs) 6 Handler runs in the V8 sandbox, eliminating the need for authentication (it's injected uniformly at the platform level). Skill pack development UI template development (approximately 10 templates, reusing platform standard card components) 3 Reusing component libraries reduces UI development by approximately 60%. Skill pack development TTS Template Writing (Approximately 30 broadcast templates) 1.5 Reuse universal prompts across different scenarios Skills Registration Submit registration + 6-step automatic verification 1 Automated verification, no manual review required Scene-Skill Association In the backend, link skill packs and scenarios, and select reusable skills. 0.5 Management backend UI operation test Intent route testing 2 Automated testing + some manual verification test Integration and debugging (hot update deployment of 1 test terminal) 3 Online Gray-scale release + full rollout (hot updates pushed from the cloud, no terminal restart required) 1 Skill packs are enabled for real-time management backend operations. total 26 people / days

[0118] Based on a team of 3 people and an average of 20 working days per month, it would take approximately 1.3 months (about 4 weeks) to develop and launch a new scenario based on this application.

[0119] The comparison between the two development models is shown in Table 6:

[0120] Table 6: Comparison of Development Based on Traditional Solutions and Development Based on the Solution in This Application for Government Service Center Scenarios Total Humanity 102 people-days 26 people 74.5% Calendar Time (3-person team) ≈5.1 months ≈1.3 months (approximately 4 weeks) 74.5% Core engine code modification Modifications are needed (copying, pruning, or retraining the NLU). Zero modifications 100% Existing scenario regression testing It is necessary to verify that existing scenarios are not affected. No need for (skill pack isolation) 100% NLU model retraining Complete retraining is required (≥5,000 corpora). No retraining required (only incremental fine-tuning of the example corpus). 100% Should the service be discontinued? Yes (service restart is required for code deployment) No (skill packs can be hot-updated with zero downtime) 100%

[0121] The above breakdown of calculations shows that the core savings come from three structural factors: First, the proposed solution does not require copying and trimming the codebase (the traditional solution requires approximately 5 person-days, while this solution requires zero); second, the proposed solution does not require retraining the NLU model (the traditional solution requires approximately 15 person-days, while this solution only requires 3 person-days to write example corpora); and third, it does not require regression testing of existing scenarios (the traditional solution requires approximately 10 person-days, while this solution requires zero, because skill package isolation ensures that the intent routing table of existing scenarios is not affected). These three factors combined contribute approximately 27 person-days of savings, accounting for 35.5% of the total savings (76 person-days); the remaining 64.5% of the savings come from the built-in platform capabilities such as dialogue management framework reuse, UI component library reuse, and API authentication weight trial, which are systemic efficiency improvements brought about by the plug-in architecture.

[0122] The calculation data in Table 5 is based on the internal work time records of the prototype platform of this application during the development and launch of the Airport scenario skill package in Q1-Q2 of 2026 (the Airport scenario includes 3 skill packages and 13 intents, with a total of 22 person-days spent by a 3-person team); the data in Table 4 for the traditional solution references the actual work time records of copying the code library from the Mall scenario and deriving the Park scenario in a smart park project in Shenzhen (the Park scenario copying and adaptation took approximately 4.8 months / 98 person-days). The above data should be understood as estimates based on representative cases with reasonable assumptions, rather than precise predictions of all possible scenarios.

[0123] In summary, the voice-driven public information interaction terminal scene skill loading system, method, and public information interaction terminal provided in the embodiments of this application firstly, by carrying a scene type identifier during terminal registration, the scheduling server matches skill packages according to the identifier and generates a scene skill routing table, enabling the terminal to automatically load different skill sets in different locations; simultaneously, through scene parameterization configuration, the same skill package adaptively adjusts its interaction logic and service behavior in different scenarios, solving the problem of scene adaptation deficiency; secondly, by distributing the scene skill routing table to the terminal and configuring it to complete intent routing based on the local routing table in offline mode, the terminal can still autonomously invoke skills in weak network or disconnected environments, thereby solving the problem of offline service interruption. Finally, the above technical features work together synergistically, enabling the terminal to achieve a balance between multi-scene adaptation and offline availability while maintaining a unified core engine, achieving the beneficial effect of improving the terminal's multi-scene deployment flexibility and environmental adaptability.

[0124] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. The appended claims are intended to cover all variations and modifications falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.

Claims

1. A voice-driven public information interaction terminal scene skill loading system, characterized in that, This includes a scheduling server for communication connections and a public information interaction terminal; The public information interaction terminal includes a voice acquisition device, a display screen for displaying interactive information, and a speaker for broadcasting voice feedback; The scheduling server is configured as follows: Register a skill pack, which includes at least intent definition and scenario parameterization configuration, and declares a list of applicable scenario types during registration. The scenario parameterization configuration defines the differentiated behavior parameters of the skill pack under different scenario types. Receive a registration request sent by the public information interaction terminal, wherein the registration request includes a scenario type identifier; Check whether the applicable scenario type list of each skill package contains the scenario type identifier. If it does, add the skill package to the scenario skill routing table of the public information interaction terminal and send the scenario skill routing table to the public information interaction terminal so that the public information interaction terminal can perform local intent routing based on the scenario skill routing table in offline mode. The system receives an intent routing request sent by the public information interaction terminal. The intent routing request carries a user intent. According to the scene skill routing table, the user intent is routed to the target skill package. The scene type identifier is passed to the target skill package so that the target skill package selects the corresponding differentiated behavior parameters from its scene parameterization configuration according to the scene type identifier and executes the service operation of the skill package according to the differentiated behavior parameters. The public information interaction terminal is configured as follows: Send a registration request to the scheduling server, the registration request including a scenario type identifier; Receive and store the scene skill routing table issued by the scheduling server; Collect user voice input; The user intent, target skill pack, and scene type identifier are obtained based on the communication reachability between the public information interaction terminal and the scheduling server. Based on the target skill package identifier corresponding to the user intent, the corresponding target skill package is invoked and a scene type identifier is passed to it, so that the target skill package executes the service operation of the skill package according to the differentiated behavior parameters corresponding to the scene type identifier; The public information interaction terminal is configured to receive and store the scene skill routing table issued by the scheduling server, including: The public information interaction terminal maintains an active scenario skill routing table and a backup scenario skill routing table; In response to the scheduling server sending a scene skill routing table update to the public information interaction terminal, the public information interaction terminal writes the received update into the backup scene skill routing table, and after writing is completed, switches the backup scene skill routing table to the active scene skill routing table through an atomic switch to achieve non-blocking update; The public information interaction terminal is configured to obtain user intent, target skill package, and scene type identifier based on the communication reachability between the public information interaction terminal and the scheduling server, including: In online mode, the voice input is sent to the scheduling server, and the user intent, target skill pack identifier, and scene type identifier returned by the scheduling server are received; or In offline mode, the user intent is determined, and the user intent is routed to the target skill pack according to the locally stored scene skill routing table to obtain the target skill pack identifier.

2. The system according to claim 1, characterized in that, The scheduling server queries whether the applicable scenario type list declared by each skill package contains the scenario type identifier. If it does, it adds the skill package to the scenario skill routing table of the public information interaction terminal. The query also includes: The scheduling server queries the custom skill packages registered by B2-level entities in the locations under the jurisdiction of the B1-level entity based on the B1-level entity identifier bound to the public information interaction terminal, and adds the custom skill packages to the scene skill routing table of the public information interaction terminal. Among them, the B1 level entity is the venue management party, the B2 level entity is the entity that occupies the venue, and the B2 level entity is under the jurisdiction of the B1 level entity; The public information interaction terminal receives and stores the scene skill routing table containing the custom skill package issued by the scheduling server.

3. A voice-driven method for loading skills in a public information interaction terminal scenario, executed by a scheduling server in the system described in any one of claims 1-2, characterized in that, include: Register a skill pack, which includes at least intent definition and scenario parameterization configuration, and declares a list of applicable scenario types during registration. The scenario parameterization configuration defines the differentiated behavior parameters of the skill pack under different scenario types. Receive a registration request sent by the public information interaction terminal, wherein the registration request includes a scenario type identifier; Check whether the applicable scenario type list of each skill package contains the scenario type identifier. If it does, add the skill package to the scenario skill routing table of the public information interaction terminal and send the scenario skill routing table to the public information interaction terminal so that the public information interaction terminal can perform local intent routing based on the scenario skill routing table in offline mode. The system receives an intent routing request sent by the public information interaction terminal. The intent routing request carries a user intent. Based on the scene skill routing table, the system routes the user intent to a target skill package and passes the scene type identifier to the target skill package. This enables the target skill package to select corresponding differentiated behavior parameters from its scene parameterization configuration based on the scene type identifier and execute the service operation of the skill package according to the differentiated behavior parameters.

4. The method according to claim 3, characterized in that, The step of routing the user intent to the target skill package according to the scenario skill routing table further includes: In the context of a voice dialogue session, based on the parsed intent parameters or invoked skill records in the dialogue context, the current user intent is routed to the associated skill package associated with the invoked skill, or the current user intent is routed to the subsequent skill package that depends on the invoked skill as a prerequisite skill, so as to realize intent relay across skill packages.

5. A voice-driven method for loading scene skills in a public information interaction terminal, executed by the public information interaction terminal in the system described in any one of claims 1-2, characterized in that, include: Send a registration request to the scheduling server, the registration request including a scenario type identifier; The system receives and stores the scene skill routing table issued by the scheduling server. The scene skill routing table is generated by the scheduling server by matching the applicable scene type list declared by the registered skill package according to the scene type identifier. The skill package includes at least an intent definition and a scene parameterization configuration. The scene parameterization configuration defines the differentiated behavior parameters of the skill package under different scene types. The user's voice input is collected through the voice acquisition device; The user intent, target skill pack, and scene type identifier are obtained based on the communication reachability between the public information interaction terminal and the scheduling server. The target skill package is invoked according to the target skill package identifier and the scene type identifier is passed to it, so that the target skill package performs the service operation of the skill package according to the differentiated behavior parameters corresponding to the scene type identifier.

6. The method according to claim 5, characterized in that, The step of calling the corresponding target skill package based on the target skill package identifier further includes: If the scene skill routing table stored locally marks the associated prerequisite skill of the target skill package, then the action handlers of the prerequisite skill package are called and executed first, and then the action handlers of the target skill package are called and executed to achieve local execution relay across skill packages.

7. A voice-driven public information interaction terminal, comprising a voice acquisition device, a display screen for displaying interactive information, a speaker for broadcasting voice feedback, a memory, and a processor, characterized in that, The memory stores a computer program that, when executed by the processor, implements the method as described in claim 5.

8. The public information interaction terminal according to claim 7, characterized in that: The voice acquisition device is a microphone array.

Images