Multi-protocol instruction semantic constraint method for intelligent terminal of Internet of Things

Abstract

The invention provides a multi-protocol instruction semantic constraint method for an intelligent terminal of the Internet of Things, and relates to the field of data processing. In the method, original control instructions from a plurality of protocol channels are received, responsibility delivery identifiers are generated, and action semantics, object semantics, conditional semantics and continuous semantics are extracted to form candidate control instruction bodies; constructing a control responsibility environment and generating a responsibility host pool; a control result site is unfolded to form a responsibility settlement draft, and responsibility host matching is completed; a responsibility transfer identification layer is used to identify the pseudo hosts capable of accepting responsibilities, and a responsibility locking record table is formed; generating responsibility fragments in a preset observation window, and executing responsibility reverse processing and multi-protocol responsibility migration judgment; and synthesizing all results to generate a semantic constraint decision, so as to realize multi-protocol control semantic constraint. By implementing the technical scheme, the control instructions with legal semantic structures and abnormal behaviors can be conveniently identified and constrained in a multi-protocol environment, and wrong control behaviors caused by a semantic abnormal mirror image structure are avoided.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a multi-protocol instruction semantic constraint method for IoT smart terminals. Background Technology

[0002] With the widespread deployment of IoT smart terminals in industrial control, smart homes, and urban infrastructure, devices from different manufacturers typically achieve interoperability through various communication protocols, such as message publish / subscribe protocols, lightweight device management protocols, and device-specific control protocols. To ensure the security and consistency of terminal control behavior, existing technologies usually introduce instruction semantic constraint mechanisms into control systems. By parsing the action semantics, object semantics, conditional semantics, and persistence semantics in control instructions, the structural legality of the instructions is verified, thereby preventing illegal control instructions from directly acting on terminal devices to a certain extent.

[0003] However, in complex multi-protocol environments, the semantic expression and parameter organization methods differ between different protocol channels. Some control systems only verify the semantic rules of the instruction structure, lacking deep constraints on the relationship between parameter content and actual control behavior. In this situation, when a device malfunctions or is maliciously controlled, an attacker may construct control instructions with legitimate semantic structures and, while maintaining the correct forms of action, object, and conditional semantics, insert anomalous parameters. This allows the control instructions to pass verification at the semantic rule level, but produces abnormal control consequences during actual execution. Furthermore, in multi-protocol control environments, malicious controllers may repeatedly send control instructions with the same semantic structure but slightly different parameter details through different protocol channels. This causes the system to identify multiple normal control behaviors during the semantic parsing phase, ignoring the abnormal patterns formed at the parameter level. This method of repeatedly constructing legitimate semantic structures and carrying anomalous parameters makes the control instructions appear legitimate at the semantic level, but produce abnormal behavior in actual control effects, thus creating a seemingly legitimate but actually abnormal semantic anomaly mirror structure.

[0004] In existing technologies, semantic constraint mechanisms primarily focus on whether the semantic structure of instructions meets preset rules. They lack effective means to identify control instructions with consistent semantic structures but abnormal parameter behavior. This is especially true in multi-protocol parallel control scenarios, where control behaviors between different protocol channels may mask each other or create responsibility transfer, making it even more difficult to identify semantically abnormal mirror structures. Therefore, how to identify and constrain control instructions with legitimate semantic structures but abnormal behavior in a multi-protocol environment, and avoid erroneous control behaviors caused by semantically abnormal mirror structures, has become a pressing technical problem to be solved in the field of IoT smart terminal control security. Summary of the Invention

[0005] This application provides a method for semantic constraint of multi-protocol instructions for IoT smart terminals, which facilitates the identification and constraint of control instructions with legal semantic structure but abnormal behavior in a multi-protocol environment, and avoids erroneous control behavior caused by semantically abnormal mirror structure.

[0006] The first aspect of this application provides a multi-protocol instruction semantic constraint method for IoT smart terminals. The method includes: acquiring raw control instructions from multiple protocol channels and generating a responsibility delivery identifier for each raw control instruction; simultaneously extracting action semantics, object semantics, conditional semantics, and persistence semantics from the raw control instructions to form candidate control instruction bodies; constructing a control responsibility environment around the target IoT smart terminal and generating a responsibility host pool, wherein the responsibility host pool consists of multiple responsibility hosts capable of assuming control consequences, each responsibility host having a host identifier, host category, host lifecycle, and host responsibility boundary; generating a control consequence bit set based on the candidate control instruction bodies, generating a consequence bit identifier for each control consequence bit, and binding the consequence bit identifier with the responsibility delivery identifier to form a responsibility settlement draft; and performing responsibility host matching processing on the control consequence bits in the responsibility settlement draft based on the responsibility host pool. Obtain the host mapping structure; construct a responsibility transfer identification layer and project the host mapping structure into the responsibility transfer identification layer to identify whether the control consequence bit is mapped to a pseudo-attributable host, and perform responsibility host locking processing on the control consequence bit in the host mapping structure and the corresponding candidate responsible host to form a responsibility locking record table; after the candidate control instruction body is executed, acquire the terminal running event in a preset observation window and generate a responsibility fragment set, and perform responsibility reverse processing on the responsibility fragment set according to the responsibility locking record table to obtain the responsibility reverse processing result, and perform multi-protocol responsibility migration judgment on the responsibility delivery identifiers from different protocol channels in the same preset observation window to obtain the multi-protocol responsibility migration judgment result; generate a semantic constraint ruling based on the responsibility settlement draft, the responsibility transfer identification layer identification result, the responsibility locking record table, the responsibility reverse processing result, and the multi-protocol responsibility migration judgment result to realize the semantic constraint on multi-protocol control instructions.

[0007] A second aspect of this application provides a multi-protocol instruction semantic constraint device for IoT smart terminals. The device includes an acquisition module and a processing module. The acquisition module acquires raw control instructions from multiple protocol channels and generates a responsibility delivery identifier for each raw control instruction. It also extracts action semantics, object semantics, conditional semantics, and persistence semantics from the raw control instructions to form candidate control instruction bodies. The processing module constructs a control responsibility environment around the target IoT smart terminal and generates a responsibility host pool. The responsibility host pool consists of multiple responsibility hosts capable of assuming control consequences, each with a host identifier, host category, host lifecycle, and host responsibility boundary. The processing module further generates a set of control consequence bits based on the candidate control instruction bodies, generates a consequence bit identifier for each control consequence bit, binds the consequence bit identifier to the responsibility delivery identifier to form a responsibility settlement draft, and performs responsibility host matching on the control consequence bits in the responsibility settlement draft based on the responsibility host pool. The processing module is further configured to: 1) obtain a host mapping structure; 2) construct a responsibility transfer identification layer and project the host mapping structure onto it to identify whether control consequence bits are mapped to pseudo-attributable hosts, and perform responsibility host locking processing on the control consequence bits and corresponding candidate responsible hosts in the host mapping structure to form a responsibility locking record table; 3) acquire terminal running events within a preset observation window after the candidate control instruction body is executed, generate a responsibility fragment set, and perform responsibility reverse processing on the responsibility fragment set according to the responsibility locking record table to obtain a responsibility reverse processing result; and 4) perform multi-protocol responsibility migration judgment on responsibility delivery identifiers from different protocol channels within the same preset observation window to obtain a multi-protocol responsibility migration judgment result; and 5) generate a semantic constraint ruling based on the responsibility settlement draft, the responsibility transfer identification layer identification result, the responsibility locking record table, the responsibility reverse processing result, and the multi-protocol responsibility migration judgment result to achieve semantic constraints on multi-protocol control instructions.

[0008] A third aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, and both the user interface and the network interface are used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method described above.

[0009] A fourth aspect of this application provides a non-transitory computer-readable storage medium storing instructions that, when executed, perform the method described above.

[0010] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: By performing unified semantic parsing on raw control commands from different protocol channels and generating responsibility delivery identifiers, control commands are converted into structurally consistent candidate control command bodies, thereby eliminating the parsing inconsistency problem caused by differences in semantic expression between different protocols. By constructing a control responsibility environment and generating a responsibility host pool, a clear scope of potential responsible parties can be established before control behavior is executed. By generating a set of control consequence bits and forming a responsibility settlement draft, control intent is transformed into a structured responsibility expression, and a stable responsibility bearing and recovery path is established through host mapping and responsibility locking mechanisms. By acquiring terminal running events after execution and performing responsibility reverse processing and multi-protocol responsibility migration judgment, the system can identify responsibility offset, responsibility drift, and cross-protocol responsibility transfer behaviors. Finally, by comprehensively analyzing various responsibility results, a semantic constraint adjudication is generated, thereby improving the security, interpretability, and abnormal behavior identification capabilities of IoT smart terminal control behavior in a multi-protocol control environment. Attached Figure Description

[0011] Figure 1 A flowchart illustrating a multi-protocol instruction semantic constraint method for IoT smart terminals provided in this application embodiment; Figure 2 A schematic diagram of a multi-protocol instruction semantic constraint device for IoT smart terminals provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0012] Explanation of reference numerals in the attached figures: 21. Acquisition module; 22. Processing module; 31. Processor; 32. Communication bus; 33. User interface; 34. Network interface; 35. Memory. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0014] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0015] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0016] To address the aforementioned technical problems, this application provides a multi-protocol instruction semantic constraint method for IoT smart terminals, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a multi-protocol instruction semantic constraint method for IoT smart terminals, provided in an embodiment of this application. The method is applied to a server and includes steps S110 to S160, as follows:

[0017] S110. Obtain raw control commands from multiple protocol channels, generate a responsibility delivery identifier for each raw control command, and extract action semantics, object semantics, conditional semantics, and persistence semantics from the raw control commands to form candidate control command bodies.

[0018] Specifically, a server refers to the core computing node deployed in an IoT control system. Its role is to uniformly access, semantically parse, analyze responsibility, and adjudicate semantic constraints on control data from multiple protocol channels. Servers are typically located at the control center or edge computing node of the IoT system, establishing communication connections with target IoT smart terminals via a network. This allows them to receive control commands sent from the terminal side or the upper-level control system and process these commands uniformly. Further, the server first deploys a multi-protocol access plane on the access side of the target IoT smart terminal. The multi-protocol access plane refers to a unified access layer established for different protocol channels, used to aggregate various protocol messages that were originally scattered into the system into a single processing framework. A protocol channel refers to an independent input path carrying a data stream of a certain type of communication protocol. It can correspond to different network ports, different message topics, different session entry points, or different protocol parsing links. The channel identifier is used to uniquely identify a protocol channel; the protocol type identifier indicates which communication protocol the channel corresponds to; the access direction identifier distinguishes whether the data stream is sent from the terminal uplink to the server or from the server downlink to the terminal; and the session boundary identifier defines whether a group of continuous interactive data belongs to the same control session in terms of time and transaction. By pre-embedding these identifiers in the multi-protocol access plane, any subsequent original control command, once entering the system, is no longer an isolated message, but is naturally bound to a clear protocol source range and access context range. The purpose of this is to provide a stable source anchor point for subsequent responsibility delivery identifier generation and candidate control command body assembly, preventing control commands from different protocol channels from losing their original context after entering the unified analysis link, thereby reducing the risk of cross-protocol confusion and responsibility source drift.

[0019] After the multi-protocol access plane is established, the server performs raw control instruction filtering on the arriving data. Arriving data refers to the raw message stream continuously entering the server from various protocol channels; raw control instructions are data units that possess actual control effect and can cause state transitions, resource usage changes, linkage changes, or execution timing changes in the target IoT smart terminal. The key to filtering is not simply checking for the presence of control fields in the message, but rather determining whether it truly belongs to a control input by considering the message's action intent, target, triggering conditions, and subsequent potential impact. For example, pure status reporting, pure heartbeat keep-alive, or pure log synchronization messages, although they enter the access side, do not directly trigger terminal control behavior and therefore will not be recognized as raw control instructions. The filtered raw control instructions need to undergo immediate raw retention processing to form a raw instruction mirror fragment. The raw instruction mirror fragment is a complete preservation result of the raw control instruction before it enters semantic expansion processing, typically including the original message byte sequence, field order, arrival time position, protocol channel, and corresponding session boundary. The purpose of this is to ensure that if it is necessary to trace back the source of action semantics, object semantics, conditional semantics, and continuous semantics in the future, we can always return to the same original source of control instructions, and the original evidence will not be lost due to subsequent normalization or semantic extraction.

[0020] After forming the original instruction image fragment, the server continues to perform channel normalization description processing on the original control instructions to form a control semantic description structure. Channel normalization description processing refers to mapping original control instructions with significantly different syntax formats under different protocol channels to a unified semantic description framework. The control semantic description structure can be understood as a standardized semantic container decoupled from specific protocol field names, which internally retains at least instruction initiation information, instruction target information, instruction triggering information, instruction validity information, and instruction-related constraint information. Instruction initiation information describes who initiated the control behavior and through what path it was delivered; instruction target information describes which target IoT smart terminal or which functional subdomain of that terminal the control behavior is to act on; instruction triggering information describes the context in which the current instruction is activated; instruction validity information describes when the control behavior takes effect, for how long it lasts, and when it terminates; instruction-related constraint information describes the magnitude constraints, priority constraints, mutual exclusion constraints, or concurrency constraints existing in the control behavior. By forming a control semantic description structure, although the original control commands in different protocol channels still retain their original command image fragments, they are all processed based on a unified description framework during subsequent semantic extraction, thereby avoiding inconsistent interpretation results for the same control intent by different protocol parsing links.

[0021] After obtaining the control semantic description structure, the server extracts the action semantics, object semantics, conditional semantics, and persistence semantics of the original control command based on the control semantic description structure. Action semantics refers to the core control behavior that the current original control command requires the target IoT smart terminal to perform, such as turning on, turning off, switching, setting, scheduling, freezing, restoring, or revoking. Object semantics refers to the actual scope of the object affected by the current control behavior, which may be the entire target IoT smart terminal, or its internal functional subdomains, resource subdomains, linkage subdomains, or security subdomains. Conditional semantics refers to the preconditions upon which the current control behavior depends, including state preconditions, permission preconditions, timing preconditions, linkage preconditions, and environmental preconditions. Persistence semantics refers to whether the current control behavior, once established, will be completed immediately, maintained periodically, continuously, conditionally maintained, or terminated after revocation. To ensure that these four types of semantics can collectively form a closed control semantic expression, the server also performs consistency verification. The purpose of consistency verification is to check whether the action semantics are compatible with the object semantics, whether the conditional semantics can support the establishment of the action semantics, and whether the persistence semantics, together with the action semantics and conditional semantics, form an executable and resolvable control logic. For example, if action semantics requires maintaining a certain operating mode continuously, but continuous semantics only supports instantaneous triggering, it indicates an inconsistency between semantics; if object semantics is limited to a local resource subdomain, but action semantics implicitly rewrites the entire terminal's global state, it also indicates a boundary violation between semantics. Only when action semantics, object semantics, conditional semantics, and continuous semantics form a coherent and executable closed relationship can the next step of responsibility delivery identifier generation and candidate control instruction body assembly be allowed.

[0022] After the consistency check passes, the server generates a responsibility delivery identifier for the current original control instruction and assembles a candidate control instruction body based on the original instruction image fragment, control semantic description structure, action semantics, object semantics, condition semantics, persistence semantics, and the responsibility delivery identifier. The responsibility delivery identifier is not merely a sequential number, but a unique responsibility entry point identifier for the current control intent to enter the responsibility analysis chain. It must be bound to at least the protocol source scope, session boundary, object semantic scope, action semantic type, condition semantic boundary, and persistence semantic features. This ensures that subsequent processes, whether generating a control consequence bit set, forming a responsibility settlement draft, or performing responsibility host matching, responsibility locking, or responsibility reversal processing, can trace back to the same original control intent along the responsibility delivery identifier. The candidate control instruction body is a structured reorganization of the current original control instruction; it is not a simple message copy, but a unified control entity that can directly participate in subsequent responsibility analysis. The candidate control instruction body simultaneously retains the traceability of the original instruction image fragment, the unified expressiveness of the control semantic description structure, the control meaning of action and object semantics, the execution boundaries of condition and persistence semantics, and the responsibility entry point attribute of the responsibility delivery identifier. Because the candidate control instruction body encapsulates this information in a unified entity, the subsequent server can directly generate the control consequence bit set, form the responsibility settlement draft, and perform responsibility host matching based on it, without having to go back to each protocol channel to repeatedly parse the original control instructions.

[0023] In summary, the multi-protocol access plane provides a unified access foundation and fixes the scope of protocol sources and access context. The raw control command screening and retention processes ensure that data objects entering the analysis link truly possess controllability and are traceable. Channel normalization description processing and control semantic description structures form a unified cross-protocol semantic carrier foundation. Action semantics, object semantics, conditional semantics, and persistence semantics are extracted and, after consistency verification, form a closed-loop control semantic expression. Finally, the responsibility delivery identifier anchors the current control intent to the unified responsibility entry point, and the candidate control command body assembles all the aforementioned results into a standardized entity that can be directly used for subsequent responsibility analysis. Thus, the entire implementation process achieves a smooth transition from multi-protocol raw messages to the unified responsibility analysis entry point. This not only solves the parsing inconsistency problem caused by differences in semantic expressions of different protocols but also provides a stable and coherent input foundation for the subsequent generation of responsibility settlement drafts, responsibility host pools, host mapping structures, responsibility locking record tables, and semantic constraint decisions.

[0024] S120. Construct a control responsibility environment around the target IoT smart terminal and generate a responsibility host pool. The responsibility host pool consists of multiple responsible hosts that can bear the control consequences. Each responsible host has a host identifier, host category, host lifecycle, and host responsibility boundary.

[0025] Specifically, a responsibility observation baseline is first established around the target IoT smart terminal. This baseline is used to uniformly express all responsibility-related facts of the target IoT smart terminal at the current control moment as a computable responsibility observation state. This responsibility observation state is not a single state value, but a composite set of states composed of terminal identifier, current terminal operating state, historical terminal control trajectory, activated terminal linkage relationships, current terminal authorization relationships, and unclosed terminal control transactions. To provide a unified entry point for subsequent responsibility host extraction and responsibility host boundary characterization, the server first performs normalized encoding on the responsibility observation state to obtain the responsibility observation baseline vector, whose expression is:

[0026]

[0027] in, This represents the responsibility observation base vector, used to uniformly carry the basic information for responsibility analysis of the current terminal; The responsible observation basis construction mapping is used to uniformly map multiple heterogeneous states into the same responsible observation representation space. This represents the current set of terminal operating states, used to describe the current working mode, function start / stop status, resource usage status, and protection status; This represents the set of historical control trajectories of the terminal, used to describe the sequence of control behaviors and their state evolution paths before the current moment; This indicates the set of activated linkage relationships for the terminal, used to describe the coupling relationships, upstream and downstream dependencies, and collaborative control relationships between terminals that are currently in effect. This represents the current set of authorization relationships for the terminal, used to describe which entities, roles, or protocol links are currently qualified to control. This represents the set of unclosed control transactions at the terminal, used to describe control processes that have begun but have not yet been confirmed, rolled back, revoked, or terminated. Through this expression, the server unifies and compresses multiple terminal responsibility contexts from different sources and with different structures into a single responsibility observation surface, thereby ensuring that all subsequent responsibility host generation processes are based on the same terminal responsibility context.

[0028] After the responsibility observation baseline is formed, the server performs control context decomposition based on the control context formed by the responsibility observation baseline. The purpose of control context decomposition is to break down the complex and mixed terminal control responsibility background into responsibility-bearing areas with relatively clear responsibilities, so as to extract the responsible host in different responsibility-bearing areas later. The server decomposes the control context into session-bearing area, protection-bearing area, linkage-bearing area, authorization-bearing area, and maintenance-bearing area. To ensure that the decomposition result is computable and has closure, the server calculates the attribution strength of each responsibility element in the responsibility observation baseline to different responsibility-bearing areas, and takes the responsibility-bearing area with the highest attribution strength as the primary attribution area. Its expression is:

[0029]

[0030]

[0031] in, Indicates the first The first element of responsibility for the first The attribution strength of each responsibility zone is used to measure which responsibility zone the responsibility element is more suitable to be assigned to. Indicates facing the first The attribution evaluation function for each responsibility-bearing area is used to calculate the degree of attribution based on the source, action path, and responsibility semantics of the responsibility element; Indicating the first in the responsible observation datum Each responsibility element can be a certain operational status item, a certain historical trajectory item, a certain linkage relationship item, a certain authorization relationship item, or a certain unclosed control transaction item; Indicates the first The primary attribution area for each element of responsibility; This represents a set of responsibility-bearing zones, whose elements include session zones, protection zones, linkage zones, authorization zones, and maintenance zones. Through this processing, the server allocates the responsibility elements in the control context to the five types of responsibility-bearing zones, ensuring that each responsibility-bearing zone retains only the responsibility semantics that match its nature of responsibility, thus providing a partitioning basis for subsequent responsibility host extraction.

[0032] After the control context is decomposed, the server performs responsibility host extraction in each responsibility-bearing area. A responsibility host is a responsible unit capable of independently assuming a certain type of control consequence. Independence does not mean that the responsible unit must exist in isolation, but rather that it has a clear origin, identifiable responsibility boundaries, and a traceable period of responsibility. To select truly independent responsible units from each responsibility-bearing area, the server calculates the degree of independent responsibility for each candidate responsible unit and retains only those candidates whose degree of independent responsibility reaches a threshold as responsibility hosts. The expression is:

[0033]

[0034]

[0035] in, Indicates the first The independent liability degree of each candidate liability unit is used to measure whether the candidate liability unit is qualified to be selected as the liability host; Indicates source clarity, used to characterize whether the candidate responsible unit has a clear source of formation; The boundary closure degree is used to characterize whether the candidate responsible unit forms a complete closure in terms of object scope, behavior scope, condition scope, and time scope. This indicates continuous traceability, which characterizes whether the candidate responsible unit can be continuously identified and tracked within subsequent observation windows; Indicates the degree of independence of liability, which is used to characterize whether the candidate liability unit can assume independent liability without relying on the primary liability of other candidate liability units; , , , This represents the weighting coefficient of each evaluation component, with a value ranging from zero to one, and a total of one. It is used to adjust the contribution of different evaluation components to the degree of independent liability. This represents the independent liability threshold, used to determine whether a candidate liability unit meets the requirements for liability host extraction; Represents the set of responsible hosts; Indicates the number of samples extracted. A responsible host. Through this process, the server can extract truly responsible hosts from the session bearer, protection bearer, linkage bearer, authorization bearer, and maintenance bearer, instead of directly including all context elements into the responsible host pool.

[0036] After the responsible host extraction is complete, the server generates a host identifier and determines the host category for each responsible host. The host identifier uniquely identifies a responsible host, and the host category indicates whether the responsible host belongs to a session-type, protection-type, linkage-type, authorization-type, or maintenance-type responsible host. To improve the stability of host category determination, the server does not directly assign a category based on the name of the responsible host region. Instead, it calculates the category fit for each responsible host to each host category separately and determines the category with the highest category fit as the host category. The expression is:

[0037]

[0038]

[0039] in, Indicates the first The responsible host for the first The class fit of a host class is used to measure the degree to which the responsible host matches the nature of the responsibility. Indicates facing the first The function for determining the category of the host class; Indicates the first The host feature vector of each responsible host is used to describe its source path, triggering method, target, liability mode and contextual dependency relationship; Indicates the first The host category ultimately determined by the responsible host; This represents a set of host categories, including session-type responsible hosts, protection-type responsible hosts, linkage-type responsible hosts, authorization-type responsible hosts, and maintenance-type responsible hosts. This process ensures that the category of each responsible host is automatically determined based on its responsibility attributes, rather than relying on manual hard-coding. This facilitates pre-screening of responsible hosts based on their category during subsequent responsible host matching.

[0040] After the host category is determined, the server performs host lifecycle characterization for each responsible host. The host lifecycle refers to the complete effective period from when a responsible host acquires responsibility to when it loses that qualification, including the lifecycle start boundary, the lifecycle maintenance phase, and the lifecycle end boundary. Since the manifestation of subsequent control consequences and responsibility fragments occurs within a preset observation window, the server must determine which periods of the responsible host are valid within that observation window. Therefore, the server constructs a lifecycle validity function for each responsible host, with the following expression:

[0041]

[0042] in, Indicates the first A responsible host at any time The lifecycle validity function, whose value of one indicates that the responsible host is qualified to assume responsibility at that time, and whose value of zero indicates that the responsible host is not qualified to assume responsibility at that time; Indicates the first The lifecycle start boundary of a responsible host is used to characterize the point in time from which it becomes eligible to assume responsibility; Indicates the first The lifecycle end boundary of a responsible host is used to characterize the point in time after which it no longer has the qualification to assume responsibility; Indicates the first A responsible host at any time The state maintenance indicator function is used to characterize whether the responsible host still meets the responsibility maintenance conditions within its lifecycle, such as whether the authorization is still valid, the protection chain is still open, the session still exists, or the maintenance transaction is still ongoing. Through this expression, the server can not only provide the existence period of each responsible host, but also determine whether it is truly effective at a specific moment by combining its real-time state. This provides a direct basis for determining whether responsibility fragments should be reclaimed to a specific responsible host during subsequent responsibility reverse processing.

[0043] After the host lifecycle is characterized, the server performs host liability boundary generation for each responsible host. The host liability boundary defines the scope of control consequences the responsible host can bear, and includes object boundaries, behavioral boundaries, conditional boundaries, and time boundaries. Object boundaries characterize the range of objects the responsible host can be responsible for; behavioral boundaries characterize the types and modes of control consequences the responsible host can bear; conditional boundaries characterize the conditions under which the responsible host is qualified to bear responsibility; and time boundaries characterize the time interval within which the responsible host can bear responsibility. To form a unified boundary representation, the server combines the four types of boundaries into a liability boundary vector and calculates whether a given control consequence falls within this liability boundary. Its expression is:

[0044]

[0045]

[0046] in, Indicates the first The responsibility boundary vector of each responsible host; Represents object boundaries, used to describe the set of objects that can bear responsibility; Indicates the boundaries of behavior, used to describe the categories of controllable consequences and the types of actions that can be taken; Indicates conditional boundaries, used to describe the authorization, status, linkage, or environmental conditions that must be met for liability to be established; Indicates time boundaries, used to describe the time interval within which liability is effective; Indicates the first The responsible host for the first The liability coverage of each control consequence candidate is used to measure whether the control consequence falls within the liability boundary of the responsible host. This represents the liability coverage calculation function, which is used to comprehensively compare the degree of object matching, behavior matching, condition matching, and time matching between control consequence candidates and liability boundary vectors. Indicates the first A vector of consequence attributes for each control consequence candidate. Through this expression, the server transforms the originally descriptive liability boundary into a computable boundary model, enabling subsequent liability host matching processing to directly filter based on liability coverage.

[0047] After establishing the host liability boundaries for each responsible host, the server performs host conflict resolution processing on the generated responsible hosts and writes the processed responsible hosts into the responsible host registration table to form a responsible host pool. The core of host conflict resolution processing is resolving the issue of primary liability attribution when multiple responsible hosts have overlapping liability boundaries. Without conflict resolution processing, the same control consequence bit might be mapped to multiple responsible hosts simultaneously in subsequent liability settlement drafts, resulting in an unclear chain of responsibility. The server calculates a priority liability score for any two overlapping responsible hosts and determines the primary and secondary responsible hosts accordingly. The expression is:

[0048]

[0049]

[0050] in, Indicates the first The priority score of each responsible host in a conflict scenario is used to characterize the priority of that responsible host in assuming primary responsibility among multiple overlapping responsible hosts; This indicates the category matching degree, which characterizes the degree to which the host category of the responsible host fits the current control semantics; This indicates lifecycle coverage, used to characterize the extent to which the responsible host covers the current control consequences within the affected period; It represents the closure degree of the liability boundary, which is used to characterize the extent to which the boundaries of the responsible host object, behavior, condition, and time boundaries accommodate the current control consequences; Indicates the continuity of responsibility source, used to characterize the degree of consistency between the responsibility host and the current responsibility delivery identifier and candidate control instruction body in terms of responsibility source; , , , This represents the weighting coefficient of each evaluation component, with a value ranging from zero to one, and a total of one. This represents a set of responsible parties whose responsibilities overlap in the same conflict of liability scenario; This indicates the host ultimately identified as the primary responsible host. Through this process, the server can clearly identify who bears primary responsibility and who bears secondary responsibility when boundaries overlap, and then write the resolved responsible hosts into the responsible host registry. The responsible host registry retains each responsible host's host identifier, host category, host lifecycle, and host responsibility boundary. The responsible host pool formed based on the responsible host registry becomes the unified responsibility foundation set for subsequent generation of control consequence bit sets based on candidate control instruction bodies and execution of responsible host matching processing.

[0051] S130. Generate a set of control consequence bits based on the candidate control instruction body, and generate a consequence bit identifier for each control consequence bit. At the same time, bind the consequence bit identifier with the responsibility delivery identifier to form a responsibility settlement draft. Perform responsibility host matching processing on the control consequence bits in the responsibility settlement draft based on the responsibility host pool to obtain the host mapping structure.

[0052] Specifically, the server first receives the candidate control instruction body formed in the preceding steps and then performs boundary determination processing based on the action semantics, object semantics, condition semantics, and persistence semantics within the candidate control instruction body to determine the control consequences. The candidate control instruction body is a unified control entity that has undergone normalization of the original control instruction, semantic extraction, and binding of responsibility delivery identifiers. Action semantics characterizes the core function of the control behavior, object semantics characterizes the scope of the control behavior, condition semantics characterizes the preconditions upon which the control behavior depends, and persistence semantics characterizes the time-based activation and maintenance of the control behavior. The essence of the control consequence decomposition boundary is to project the above four types of semantics into a multi-dimensional responsibility consequence space, thereby limiting which responsibility consequences the current candidate control instruction body can and cannot cause in terms of object scope, triggering preconditions, time intervals, and diffusion paths. To make the subsequent control consequence decomposition more distinctive, the server does not use a simple one-time mapping but introduces a composite boundary model with interaction items and gating items, specifically expressed as:

[0053]

[0054]

[0055] in, Represents the control consequence expansion boundary vector, used to uniformly describe the allowed expansion region of the current candidate control instruction body in the responsibility consequence space; This represents a boundary compression function, used to constrain the results of multi-source semantic fusion to a unified boundary expression range, making the boundary values ​​of each dimension comparable; This represents an action semantic vector, used to express the type, direction, intensity, and mode of action of the control behavior; The semantic vector of the object is used to express the scope characteristics of the control behavior acting on the target IoT smart terminal body, functional subdomain, resource subdomain or linkage subdomain. This represents a conditional semantic vector, used to express state premises, permission premises, timing premises, linkage premises, and environment premises. This represents a persistence semantic vector, used to express temporal characteristics such as immediate persistence, periodic persistence, hold persistence, conditional persistence, or undo persistence; , , , Linear mapping matrices representing action semantics, object semantics, conditional semantics, and persistence semantics, respectively, are used to project different semantics onto the same boundary space; This represents tensor interaction operations, used to explicitly preserve the coupling relationship between two types of semantics, avoiding the loss of semantic interaction information caused by simple addition; , , , These represent the interaction mapping matrices between action semantics and object semantics, action semantics and conditional semantics, object semantics and persistence semantics, and conditional semantics and persistence semantics, respectively, and are used to enhance the sensitivity of the boundary model to complex combinations of control semantics. This represents the boundary offset term, used to correct the position of the base boundary center; This represents a dimensionally gated product, used to adjust the boundary of the control consequence expansion to the current control context. This represents the context gating vector, used to introduce the current control responsibility environment into the boundary determination process; This represents a gated compression function used to constrain the context adjustment results to a stable interval; This represents the current operating state vector, used to reflect the current working state of the target IoT smart terminal; This represents the historical control trajectory vector, used to reflect the continuous relationship between the current control semantics and historical control behavior; This indicates the activated linkage vector, which reflects the limiting effect of external linkage structures on the unfolding of the current consequences; This represents the vector of unclosed control transactions, used to reflect the squeezing or amplification effect of currently unclosed transactions on the unfolding of new control consequences; , , , These represent the gating mapping matrices for various control context elements; This represents the context-gated bias term. Through this set of formulas, the server can form more detailed control consequences unfolding boundaries in high-dimensional space than simple semantic splicing, thus providing accurate premises for subsequent hierarchical unfolding.

[0056] After determining the control consequence unfolding boundary, the server performs hierarchical unfolding of control consequences based on the boundary to generate primary behavioral consequences, resource boundary consequences, protection response consequences, linkage propagation consequences, and exit convergence consequences. It then performs control consequence bit segmentation on each consequence layer to form a set of control consequence bits. The core of hierarchical unfolding of control consequences is not to equally divide all consequences, but to calculate their unfolding strength and manifestation probability based on the formation mechanism and propagation path of different consequence layers. Primary behavioral consequences are mainly driven by action semantics; resource boundary consequences are more influenced by the coupling of object semantics and persistence semantics; protection response consequences are more influenced by conditional semantic gating; linkage propagation consequences depend more on object semantics and the linkage context propagation path; and exit convergence consequences are highly correlated with persistence semantics and fallback conditions. To improve the discriminative power of hierarchical unfolding, the server adopts a hierarchical scoring model that includes primary, interaction, and inhibition terms, specifically expressed as:

[0057]

[0058]

[0059] in, Indicates the first The expansion strength of the consequence layer is used to measure the significance of the consequence layer under the current candidate control instruction body; Indicates the first The linear sensitivity vector of the consequence layer is used to measure the direct contribution of each dimension of the control consequence unfolding boundary to the consequence layer. Indicates the first The quadratic coupling matrix of the consequence layer is used to characterize the interaction enhancement or inhibition between different dimensions inside the consequence unfolding boundary; The auxiliary vector representing the control context when the consequence layer unfolds is used to introduce the additional effects of the current state, historical trajectory, linkage relationship and unclosed transactions on different consequence layers; Indicates the first The contextual response vector of the consequence layer is used to characterize the sensitivity of the consequence layer to different contextual elements; Indicates the first The center deviation suppression coefficient of the consequence layer is used to limit abnormal expansion when the current expansion boundary deviates too much from the typical center of the consequence layer; Indicates the first The typical center vector of the consequence layer is used to represent the boundary morphology center when the consequence layer usually appears; Represents the squared Euclidean distance, used to measure the degree of deviation between the current unfolded boundary and the center of the typical consequence layer; This represents the entire set of consequences, whose elements include main behavioral consequences, resource boundary consequences, protection response consequences, linkage propagation consequences, and exit convergence consequences. This represents the effective consequence layer threshold, used to filter out the consequence layers that truly need to be expanded. This represents the set of effective consequence layers. After obtaining the set of effective consequence layers, the server performs control consequence bit segmentation processing on each effective consequence layer. During control consequence bit segmentation, the server uses differences in the object of action, the direction of responsibility, the conditional gating, and the duration interval as the segmentation criteria to divide the larger-granularity consequence layers into the smallest responsible units. The resulting set of control consequence bits retains the structure of the consequence layers while also providing operability for subsequent independent mapping and locking.

[0060] After the set of control consequence bits is formed, the server generates consequence bit attributes for each control consequence bit in the set, and generates consequence bit identifiers based on the consequence bit attributes. Simultaneously, the consequence bit identifiers are bound to the responsibility delivery identifiers to form a responsibility settlement draft. The consequence bit attributes are a set of responsibility characteristic descriptions for the control consequence bits, including at least the consequence bit category, the object of the consequence bit's action, the triggering prerequisite of the consequence bit, the duration of the consequence bit, the direction of influence of the consequence bit, and the convergence method of the consequence bit. To ensure that the responsibility settlement draft is not merely a result of field assembly, but a responsibility expression with structural coupling relationships, the server constructs a high-dimensional attribute expression for each control consequence bit and adopts a consequence bit encoding model with context residual terms and responsibility entry constraint terms. Its expression is:

[0061]

[0062]

[0063] in, Indicates the first The consequence attribute vector of each control consequence bit is used to uniformly express all the responsibility attributes of the control consequence bit. This represents an attribute compression mapping function, used to merge multiple attributes into a unified expression; Indicates the first Each control consequence bit is a category feature vector used to characterize whether it belongs to the main behavior consequence bit, resource boundary consequence bit, protection response consequence bit, linkage propagation consequence bit, or exit convergence consequence bit. The feature vector of the target object is used to characterize whether it acts on the global or local domain of the target IoT smart terminal. This represents the triggering prerequisite feature vector, used to characterize under what prerequisite conditions it holds true; This represents the feature vector of the duration interval, used to characterize when it begins to appear, how long it lasts, and when it ends; This represents the eigenvector of the direction of influence, used to characterize whether it converges inward, propagates outward, propagates upward, or expands downward; The feature vector represents the convergence method, used to characterize whether it adopts a convergence mechanism of natural termination, undo termination, rollback termination, or conditional termination. to These represent the mapping matrices for each attribute component; This represents a higher-order interaction mapping matrix, used to preserve the third-order interaction structure between consequence bit categories, target objects, and triggering conditions; Indicates the attribute bias; This represents a contextual residual term, used to compensate for the offset effect of the current control context on the consequence position attribute in the final expression; This indicates the code representing the consequences of binding the responsibility entry point; This represents a vector concatenation operation, used to concatenate the consequence attribute vector with the responsibility delivery identifier into a unified responsibility representation; This represents the responsibility delivery identifier code, used to characterize the responsibility entry point corresponding to the current control consequence bit. The server receives... Next, a consequence bit identifier is generated for each control consequence bit, and the consequence bit identifier is bound to the responsibility delivery identifier one by one. Then, all consequence bit identifiers, consequence bit attribute vectors and responsibility entry codes are written into the responsibility settlement draft, thereby obtaining a structured, traceable and settlementable responsibility deployment result.

[0064] After the responsibility settlement draft is generated, the server performs a pre-screening process on the control consequence bits in the responsibility settlement draft based on the responsibility host pool. This pre-screening selects a subset of responsible hosts that meet the constraints of host category, host lifecycle, and host liability boundary. The purpose of the pre-screening is to remove responsible hosts that are clearly incompatible with the current control consequence bits, retaining only those with basic liability potential. To avoid excessive false screening caused by simple threshold comparisons, the server uses a composite pre-screening function that includes category compatibility, lifecycle coverage, object boundary coverage, behavior boundary coverage, condition boundary coverage, and time boundary coverage. Its expression is:

[0065]

[0066]

[0067] in, Indicates the first The control consequence bit and the first The pre-screening score among responsible hosts is used to measure whether the responsible host has the basic qualifications to enter the subsequent fine matching stage; This indicates category compatibility, used to characterize the degree of compatibility between the current control consequence bit category and the responsible host category; Indicates lifecycle coverage, used to characterize the effective coverage of the responsible host within the duration of the control consequences bit; Represents object boundary coverage, used to characterize the extent to which the boundary of the responsible host object encompasses the object acting on the control consequence bit; Indicates the coverage of behavioral boundaries, used to characterize the degree to which the responsible host's behavioral boundaries support the control consequence bit category and the direction of influence; This indicates the coverage of the condition boundary, which characterizes the degree to which the responsible host condition boundary satisfies the triggering premise of the control consequence bit. Indicates time boundary coverage, used to characterize the degree to which the responsible host time boundary supports the duration and convergence intervals of the control consequence bit; It indicates the continuity of responsibility source, used to characterize the continuity of responsibility source between the current responsibility host and the candidate control instruction body represented by the responsibility delivery identifier; to This represents the weighting coefficient of each pre-screening component, with a value ranging from zero to one, and a total sum of one. This represents the pre-screening threshold for responsible hosts, used to select a subset of responsible hosts; Indicates the first A subset of responsible hosts corresponding to each control consequence bit; Indicates the first One responsible host. Through this set of formulas, the server can upgrade the responsible host pre-screening process from simple rule judgment to multi-dimensional weighted screening, thereby significantly improving the accuracy and stability of subsequent responsible host matching processing.

[0068] After obtaining the subset of responsible hosts, the server performs responsibility host matching processing on the subset based on object boundary matching degree, behavior boundary matching degree, condition boundary matching degree, and time boundary matching degree to determine the primary and secondary responsible hosts corresponding to each control consequence bit. Responsibility host matching processing is the core step in the entire responsibility settlement phase, and its goal is to accurately determine who should bear primary responsibility and who can bear secondary responsibility within the subset of responsible hosts. To avoid a single boundary matching degree dominating the result, the server adopts a complex matching model with multiplicative coupling terms and difference penalty terms. Its expression is:

[0069]

[0070]

[0071]

[0072]

[0073] in, Indicates the first The control consequence bit and the first The overall matching score among the responsible hosts; Indicates object boundary matching degree, used to measure the degree of overlap between the boundaries of the control consequence bit acting on the object and the responsible host object; Indicates the behavioral boundary matching degree, used to measure the degree of fit between the control consequence category and the direction of influence and the behavioral boundary of the responsible host; This indicates the condition boundary matching degree, used to measure the degree of satisfaction between the control consequence triggering premise and the responsible host condition boundary; Indicates the time boundary matching degree, used to measure the degree of coverage between the duration of the control consequence bit and the time boundary of the responsible host and the host life cycle; A multiplicative coupling term representing the object boundary and the behavior boundary, used to enhance the credibility of accountability when the acting object and behavior type are highly matched. This represents the multiplicative coupling term between the condition boundary and the time boundary, used to enhance the stability of liability when both the triggering condition and the duration interval are reasonable. This represents a boundary matching difference penalty term, used to suppress situations where a responsible host may have a high degree of matching at individual boundaries but suffer from severe imbalance in the overall boundary structure. to This represents the weight coefficient of each matching component and penalty component, with a value ranging from zero to one, and needs to be preset according to the scenario; Indicates the first The primary responsible host corresponding to each control consequence bit; This indicates the threshold for secondary liability hosts, which restricts only liability hosts that achieve a high degree of matching to serve as secondary liability hosts. Indicates the first The matching score of the primary responsible host corresponding to each control consequence bit; This indicates the primary and secondary gap tolerance, used to constrain the matching gap between the secondary responsible host and the primary responsible host from being too large; Indicates the first Each control consequence bit corresponds to a set of secondary responsible hosts. Through the above complex matching model, the server can not only comprehensively select the primary responsible host on the multi-dimensional boundary, but also retain several high-quality secondary responsible hosts when necessary to provide local responsibility compensation and boundary enhancement in complex control scenarios.

[0074] After determining the primary and secondary responsible hosts corresponding to each control consequence bit, the server generates a host mapping structure based on the mapping relationship between each control consequence bit and its corresponding primary and secondary responsible hosts. The host mapping structure is the final output of the responsibility settlement phase. It organizes all control consequence bits in the current responsibility settlement draft and their assigned responsible hosts into a formal mapping structure that can be directly invoked by the subsequent responsibility transfer identification layer and responsibility locking processing. To ensure that the host mapping structure is not merely a simple mapping table, but a responsibility graph with interpretable boundary information, the server constructs a host mapping unit for each control consequence bit and assembles the set of mapping units into the host mapping structure. Its expression is:

[0075]

[0076]

[0077] in, Indicates the first Each control consequence bit corresponds to a host mapping unit, which is used to record the responsible host allocation result of the control consequence bit and its matching basis; Indicates the first Consequence bit identifier for each control consequence bit; This indicates that the host is primarily responsible. This represents the set of auxiliary responsible hosts; This represents the overall matching score of the primary responsible host; This represents the set of comprehensive matching scores for all auxiliary responsible hosts; , , , These represent the object boundary matching information, behavior boundary matching information, condition boundary matching information, and time boundary matching information related to the current control consequence bit, respectively, to support subsequent responsibility transfer identification and responsibility locking boundary generation; Represents the host mapping structure; Indicates the total number of bits representing the control consequences.

[0078] S140. Construct a responsibility transfer identification layer and project the host mapping structure into the responsibility transfer identification layer to identify whether the control consequence bit is mapped to a pseudo-attributable host. Perform responsibility host locking processing on the control consequence bit in the host mapping structure and the corresponding candidate responsible host to form a responsibility locking record table.

[0079] Specifically, the identification background datum is first constructed around the host mapping structure. Within this datum, the host identifier, host category, host lifecycle, and host liability boundaries in the responsible host pool are solidified. Simultaneously, the action semantics, object semantics, conditional semantics, and persistence semantics in the candidate control instruction bodies are solidified to form a responsibility transfer identification environment. The identification background datum refers to the unified responsibility context that the responsibility transfer identification layer relies on before entering specific identification. Its function is to reproject the host mapping structure, responsible host pool, and candidate control instruction bodies already formed in the previous steps into the same comparison space. This ensures that the subsequent identification of pseudo-attributable hosts is no longer limited to a single mapping relationship but is based on the joint constraints of control semantics, liability boundaries, and temporal validity. The host identifier is used to uniquely identify the responsible host; the host category is used to characterize whether the responsible host belongs to a conversational, protective, collaborative, authorized, or maintenance type of responsible host; the host lifecycle is used to characterize the effective liability range of the responsible host in the time dimension; and the host liability boundaries are used to characterize the scope of the responsible host's liability in terms of object boundaries, behavior boundaries, condition boundaries, and time boundaries. The server integrates these factors with the action semantics, object semantics, conditional semantics, and persistence semantics in the candidate control instruction body to form a responsibility transfer identification environment vector, the expression of which is:

[0080]

[0081] in, This represents the responsibility transfer identification environment vector, which is used to uniformly carry the responsibility context required for subsequent identification of pseudo-attributable hosts; This represents the environment compression function, used to constrain the multi-source fusion results within a stable range; This represents the host mapping structure encoding, used to express the mapping relationship between each control consequence bit and the candidate responsible host; This represents the responsible host pool code, used to express the host identifier, host category, host lifecycle, and host responsibility boundaries of all responsible hosts; It represents the semantic encoding of actions, used to express the type and manner of action that controls behavior; Represents the semantic encoding of an object, used to express the scope of the object on which the control behavior is applied; It represents conditional semantic encoding, used to express the state prerequisites, permission prerequisites, timing prerequisites, and linkage prerequisites upon which the control behavior depends; This represents persistent semantic encoding, used to express the temporal mode of control behavior; , , , , , These represent the mapping matrices for the host mapping structure, the responsible host pool, action semantics, object semantics, conditional semantics, and persistence semantics, respectively. This represents tensor interaction operations, used to preserve the high-order coupling between the host mapping structure and the responsible host pool; This represents the interaction mapping matrix between the host mapping structure and the responsible host pool; This expression represents the bias term for the recognition environment. Through this expression, the server unifies the results of the preceding responsibility expression and the control semantics into a unified responsibility transfer recognition environment, providing stable input for subsequent recognition processing.

[0082] After establishing a responsibility transfer identification environment, the server generates a set of pseudo-attributable hosts based on this environment and performs identification and marking solidification processing on these pseudo-attributable hosts. A pseudo-attributable host is a host that superficially possesses some qualification for liability, but should not bear the consequences of current control based on the source of liability, the boundary of liability, or the continuity of time. Historical residual hosts are those that have nearly converged in the previous control chain or whose main responsibility has been completed, but still temporarily exist in the responsibility host pool because their lifecycle has not yet fully ended; bridging transition hosts are those that only undertake protocol bridging, permission transition, or session connection functions and should not absorb the consequences of current control; circumstantial host are those that can only undertake circumstantial, witnessing, or auxiliary linkage interpretation functions and should not bear primary responsibility; background adsorption hosts are those that are in the background maintenance, inspection, diagnosis, or recovery process, superficially possessing the appearance of liability but lacking direct continuity of responsibility with the current control intent. The server calculates the attribution strength of each of these four types of pseudo-attributable hosts for each host and selects those whose attribution strength reaches a threshold to include in the pseudo-attributable host set, the expression of which is:

[0083]

[0084]

[0085] in, Indicates the first The responsible host belongs to the first The attribution strength of pseudo-attributable hosts is used to characterize the degree to which the responsible host exhibits characteristics of a historical residual host, a bridging transitional host, a circumstantial host, or a background adsorbed host. Indicates the first The host feature vector of each responsible host in the responsibility transfer identification environment is used to comprehensively express its host category, host life cycle, responsibility boundary and responsibility source location; Indicates the first The linear discriminant vector of pseudo-attributable hosts is used to characterize the typical directional features of such pseudo-attributable hosts; Indicates the first The quadratic relation matrix of pseudo-attributable hosts is used to characterize the discriminative features of such pseudo-attributable hosts in higher-order coupling structures; Indicates the first The responsible host is relative to the first Additional offsets for pseudo-attributable hosts are used to compensate for the additional effects of host lifecycle persistence, bridging degree, circumstantial dependency, or background transaction absorption. This represents a set of pseudo-attributable host categories, whose elements include historical residual hosts, bridging transitional hosts, circumstantial traction hosts, and background adsorption hosts. This represents a set of pseudo-attributable hosts; This represents the threshold for inclusion of pseudo-attributable hosts, used to determine whether a particular responsible host should be included in the pseudo-attributable host set. After the set is generated, the server assigns an identification tag to each pseudo-attributable host. This tag records its pseudo-attributable category, cause of formation, mismatch boundary, and risk level, so that it can be directly referenced during subsequent mapping review.

[0086] After the set of pseudo-attributable hosts is formed and the identification tags are solidified, the server projects the host mapping structure onto the responsibility transfer identification layer to form mapping review units. For each mapping review unit, it performs lifecycle validity identification, responsibility boundary closure identification, responsibility source continuity identification, and primary / secondary responsibility reasonableness identification to determine whether the control consequence bit has been mapped to a pseudo-attributable host. A mapping review unit is a responsibility mapping review entity built around a single control consequence bit, and it includes at least a consequence bit identifier, a primary responsible host identifier, a secondary responsible host identifier, and various boundary matching information that form the mapping relationship. The lifecycle validity identification process determines whether the current candidate liable host remains in a valid liable state throughout the period when the control consequence position manifests; the liability boundary closure identification process determines whether the object boundary, behavior boundary, condition boundary, and time boundary of the candidate liable host can fully encompass the current control consequence position; the liability source continuity identification process determines whether the liability source chain of the candidate liable host is consistent with the control intent represented by the current liability delivery identifier; the primary and secondary liability rationality identification process determines whether a natural structure of clear primary liability and compensatory secondary liability is formed between the primary and secondary liable hosts. The server calculates a comprehensive pseudo-mapping risk score for each mapping review unit, the expression of which is:

[0087]

[0088]

[0089]

[0090]

[0091]

[0092] in, Indicates the first The first control consequence bit is mapped to the first... The comprehensive pseudo-mapping risk score for each candidate responsible host is used to determine whether the candidate responsible host is a pseudo-attributable host. to This represents the weighting coefficient of each risk component, with values ​​ranging from zero to one, and a total sum of one. Indicates lifecycle effectiveness, used to measure the set of time corresponding to the control consequences. Within this context, the extent to which the candidate responsible host remains effective; Indicates the first The set of time periods during which the control consequences are manifested; Indicates the first Each candidate responsible host at time The lifetime validity indicator value, a value of one indicates validity, and a value of zero indicates invalidity; It represents the closure degree of the responsibility boundary, which is used to measure the overall degree of inclusion of the object boundary, behavior boundary, condition boundary, and time boundary in the current control consequence position; , , , These represent the object boundary closure, behavior boundary closure, condition boundary closure, and time boundary closure, respectively. Indicates the continuity of responsibility sources, used to measure the current control consequences bit encoding. Source coding of candidate responsible host Consistency in direction between them; This indicates a cosine similarity operation, used to reflect whether the sources of responsibility for the two operations are consistent. This indicates the reasonableness of primary and secondary liability, used to measure whether the division of labor between the primary and secondary liable parties is clear. This indicates the matching score of the control consequence bit to the primary responsible host. This indicates the matching score for the co-host. This indicates an extremely small positive number that prevents the denominator from being zero; Indicates the first The prior risk value of each candidate liable host belonging to the set of pseudo-attributable hosts is used to introduce the aforementioned identification marker to solidify the results. Through this set of formulas, the server integrates the four types of identification processes into a comparable risk score, and uses this score to identify whether the control consequence bit has been mapped to a pseudo-attributable host.

[0093] After completing the mapping review, the server generates a responsibility transfer identification result based on the identification processing results, and then filters the control consequence bits and corresponding candidate responsible hosts that can enter the locking stage based on the responsibility transfer identification result. The responsibility transfer identification result is a responsibility mapping risk conclusion given for each control consequence bit, including at least normal settlement result, offset warning result, and high-risk transfer result. If both the primary and secondary responsible hosts corresponding to a certain control consequence bit have low pseudo-mapping risk, then the control consequence bit is marked as a normal settlement consequence bit; if only the secondary responsible host has a high risk while the primary responsible host's risk is acceptable, then the control consequence bit is marked as an offset warning consequence bit; if the primary responsible host itself has been identified as a pseudo-attributable host, then the control consequence bit is marked as a high-risk transfer consequence bit. The server defines three types of judgment functions as follows:

[0094]

[0095]

[0096] in, Indicates the first The responsibility transfer identification result label for each control consequence position has a value of zero indicating a normal settlement result, a value of one indicating a deviation warning result, and a value of two indicating a high-risk transfer result. Indicates the first The risk score of the pseudo-mapping of each control consequence bit to the host bearing primary responsibility; Indicates the first The risk score of the pseudo-mapping of the control consequence bit to the host of the auxiliary responsibility; This indicates the threshold for normal settlement risk of the host plant that bears primary responsibility; This indicates the threshold for warning of host deviation in the auxiliary responsibility system; This indicates the high-risk transfer threshold for the primary responsible host; This represents the set of control consequence bits that can enter the locking phase. Through this processing, the server transforms the identification results into the basis for executable subsequent actions, that is, only normal settlement consequence bits and offset warning consequence bits are allowed to enter the responsible host locking phase, while high-risk transfer consequence bits will be reserved for direct use in subsequent semantic constraint adjudication.

[0097] After filtering out control consequence bits that can enter the locking phase and their corresponding candidate responsible hosts, the server generates primary and secondary locking relationships for the filtered control consequence bits and their corresponding candidate responsible hosts, and performs locking boundary solidification processing on the primary and secondary locking relationships based on object boundaries, behavior boundaries, condition boundaries, and time boundaries. The primary locking relationship refers to a fixed responsibility path where a certain control consequence bit should be preferentially recovered to the primary responsible host in the subsequent responsibility fragment recovery phase; the secondary locking relationship refers to a compensatory responsibility path that allows some responsibility fragments to be recovered along the secondary responsible host when the primary responsible host cannot independently cover all responsibility fragments within its local boundary range. The purpose of locking boundary solidification processing is to further transform the primary and secondary locking relationships from abstract mapping relationships into responsibility recovery constraints with clear boundary conditions. The server constructs a locking boundary vector for each locking relationship and calculates the boundary stability of that locking relationship, the expression of which is:

[0098]

[0099]

[0100]

[0101] in, Indicates the first The master locking boundary vector of each control consequence bit is used to describe the fixed constraints of its master locking relationship on the object boundary, behavior boundary, condition boundary and time boundary. Indicates the first A secondary locking boundary vector of each control consequence bit is used to describe the fixed constraints of its secondary locking relationship on the same four types of boundaries. and These represent the object boundaries of the primary and secondary locking relationships, respectively. and These represent the behavioral boundaries of the primary and secondary locking relationships, respectively. and These represent the conditional boundaries of the primary locking relationship and the secondary locking relationship, respectively. and These represent the time boundaries of the primary locking relationship and the secondary locking relationship, respectively. Indicates the first The stability of the locking boundary of each control consequence bit is used to measure whether the current primary locking relationship and secondary locking relationship form a clear, stable and non-drift responsibility recovery path on the multidimensional boundary; , , , These represent the object boundary stability, behavioral boundary stability, conditional boundary stability, and time boundary stability, respectively. This represents a boundary drift penalty term, used to suppress situations where the boundaries between the primary and secondary locking relationships overlap excessively, the boundaries are ambiguous, or the primary and secondary responsibilities are reversed. Through this processing, the server can further transform the responsibility mapping relationship that can enter the locking phase into a rigid responsibility recovery constraint that the subsequent responsibility reverse processing directly depends on.

[0102] After solidifying the primary locking relationship, secondary locking relationship, and locking boundary, the server generates a responsibility locking record table based on these relationships. This table is not simply a data registration form, but rather a unified basis for subsequent responsibility fragment recovery and reverse responsibility processing. It must record at least the responsibility delivery identifier, consequence bit identifier, primary responsibility host identifier, secondary responsibility host identifier, primary locking relationship, secondary locking relationship, primary locking boundary, secondary locking boundary, responsibility transfer identification result, and locking boundary stability. To enhance the traceability and subsequent judgment capabilities of the responsibility locking record table, the server constructs a responsibility locking record unit for each control consequence bit and assembles all responsibility locking record units into a responsibility locking record table, the expression of which is:

[0103]

[0104]

[0105] in, Indicates the first Each control consequence bit corresponds to a responsibility locking record unit, which is used to record all locking information that the control consequence bit should follow in the subsequent responsibility recovery phase; This indicates the responsibility delivery identifier code, used to trace the current responsibility lock record unit back to the specific control responsibility entry point; Indicates the consequence bit identifier; This indicates that the host is primarily responsible. This represents the set of auxiliary responsible hosts; Represents the primary locking boundary vector; Represents the secondary locking boundary vector; Labels indicating the results of responsibility transfer identification; Indicates the stability of the locked boundary; This is a record of liability attribution.

[0106] S150. After the candidate control instruction body is executed, the terminal running event is obtained in the preset observation window, and a responsibility fragment set is generated. At the same time, the responsibility fragment set is processed in reverse according to the responsibility locking record table to obtain the responsibility reverse processing result. In the same preset observation window, the responsibility delivery identifier from different protocol channels is judged by multi-protocol responsibility migration to obtain the multi-protocol responsibility migration judgment result.

[0107] Specifically, after the candidate control instruction body completes execution and triggers, the server establishes an observation initiation unit based on the responsibility delivery identifier and further constructs a runtime event collection base plane to continuously acquire state change events, resource change events, protection change events, linkage change events, execution receipt events, and log recording events of the target IoT smart terminal within a preset observation window. The observation initiation unit refers to the responsibility observation starting point established around a single responsibility delivery identifier. Its function is to load all the consequences bit identifiers, primary responsible host, secondary responsible host, primary locking relationship, secondary locking relationship, object boundaries, behavior boundaries, condition boundaries, and time boundaries already fixed in the previous responsibility locking record table into the current post-execution observation process. The runtime event collection base plane refers to the multi-source runtime event collection plane established for the target IoT smart terminal, used to uniformly access different types of runtime changes after terminal execution into the same responsibility analysis space. State change events characterize the state transitions of the target IoT smart terminal and its functional subdomains; resource change events characterize resource occupancy, release, contention, and quota changes; protection change events characterize protection chain activation, upgrade, rollback, and exit; linkage change events characterize adjacent terminal responses, upstream and downstream dependency changes, and collaborative link propagation; execution receipt events characterize execution confirmation, rejection, interruption, and completion; and log recording events characterize changes in system records surrounding the current candidate control command. To unify these heterogeneous events under the current responsibility delivery identifier, the server constructs an event collection intensity function for the runtime event collection baseline, the expression of which is:

[0108]

[0109]

[0110] in, Indicates time A comprehensive operational event vector is used to uniformly express various operational change events; , , , , , The channel mapping matrix represents state change events, resource change events, protection change events, linkage change events, execution receipt events, and log recording events, respectively, and is used to project different events onto a unified event space; , , , , , Representing time respectively Feature vectors of various events collected; Indicates the observation of the startup unit at time [time]. The activation vector is used to characterize the constraint result of the current responsibility delivery identifier on the running event collection process; This indicates the activation of the compression function, used to compress the fusion result to a stable range; This represents a responsibility delivery identifier mapping matrix, used to introduce the current responsibility entry point; This represents the responsibility delivery identifier code, used to uniquely identify the current control responsibility entry point; This represents the responsibility locking record table mapping matrix, used to introduce prior locking relationships; This represents the code in the responsibility lockout record table, used to express the current responsibility recovery boundary; This represents the runtime event mapping matrix, used to project the aggregate runtime event vector onto the observation space; This indicates the observation start bias term. Through this process, the server does not passively record all terminal operation information, but actively constrains the observation range with the responsibility delivery identifier as the core, so that the subsequent responsibility fragment generation process naturally revolves around the current control responsibility.

[0111] After the observation initiation unit and the operational event acquisition base are established, the server performs segmentation processing on the preset observation window to form the manifestation start segment, responsibility diffusion segment, responsibility stabilization segment, and responsibility termination segment. Based on the operational event acquisition base, it performs screening processing on the acquired terminal operational events to obtain terminal operational events associated with the responsibility delivery identifier. The preset observation window refers to the time interval covered from the start of execution of the candidate control instruction body to the completion of responsibility manifestation. The manifestation start segment represents the time segment in which the main behavioral consequences and immediate resource consequences first appear; the responsibility diffusion segment represents the time segment in which the protection response consequences and linkage propagation consequences gradually unfold; the responsibility stabilization segment represents the time segment in which the responsibility consequences persist under continuous semantic action; and the responsibility termination segment represents the time segment in which the termination consequences exit and the unclosed responsibility is recovered. The server does not divide the preset observation window equally, but dynamically generates the boundaries of each segment based on the duration interval and termination method of the control consequences in the preceding responsibility settlement draft. This can be represented as:

[0112]

[0113]

[0114]

[0115] in, Indicates the preset observation window; Indicates the start time of observation; Indicates the end time of observation; This represents the set of segments of the observation window, with its four sub-intervals corresponding to the initial display segment, the responsibility diffusion segment, the responsibility stabilization segment, and the responsibility convergence segment, respectively. Indicates the first Each segment boundary moment; Indicates the total number of bits representing the control consequences; Indicates the first The control consequence bit for the first The contribution weights of each segment boundary are used to characterize the intensity of the manifestation of the control consequence bit at different stages. Indicates the first The duration of each control consequence bit is used to characterize its time range from occurrence to termination. After segmentation, the server performs a filtering process on running events based on object boundary consistency, behavioral boundary similarity, condition boundary satisfaction, and time boundary overlap. The filtering process involves retaining running events that have a boundary association with the current responsibility delivery identifier, while excluding background events, historical remnant events, and other control chain events. The server defines the running event association score as follows:

[0116]

[0117]

[0118] in, Indicates the first The correlation score between each running event and the current responsibility delivery identifier; It represents the object boundary consistency, used to characterize whether the object affected by the running event falls within the current responsibility locking boundary; Indicates behavioral boundary similarity, used to characterize the degree of consistency between the behavioral type of the running event and the current control consequence bit category; This indicates the condition boundary satisfaction level, used to characterize whether the occurrence of the running event satisfies the triggering prerequisite of the current control consequence bit; Indicates the overlap of time boundaries, used to characterize whether the time location of the running event falls within the segment boundary of the current observation window; This indicates the consistency of the responsibility entry point, which characterizes the degree of consistency between the operational event and the current responsibility delivery identifier in terms of the source of responsibility. , , , , This represents the weight coefficient of each associated component, with a value ranging from zero to one, and a total value of one. Indicates the threshold for filtering out running events; This represents the set of terminal operation events associated with the current responsibility delivery identifier; Indicates the first Each runtime event. Through this process, subsequent responsibility fragment generation will be based on the screened responsibility-related events, without being interfered with by a large number of irrelevant runtime events.

[0119] After obtaining the terminal running event associated with the responsibility delivery identifier, the server performs responsibility fragmentation processing on the terminal running event and generates responsibility fragments. Simultaneously, it generates fragment attributes for each responsibility fragment, forming a set of responsibility fragments. A responsibility fragment is the smallest unit of responsibility manifestation separated from a single terminal running event. It must be able to be independently mapped back to a specific control consequence bit and independently returned to a specific responsibility host. The basis for responsibility fragmentation includes differences in the object of action, the direction of responsibility, the triggering conditions, and the convergence state. For example, a composite resource change event may simultaneously contain two responsibility signals: an increase in resource usage and a delay in resource release. These two responsibility signals should be divided into two different responsibility fragments. The server constructs a responsibility fragmentation function for each terminal running event and generates a fragment attribute vector. Its expression is:

[0120]

[0121]

[0122]

[0123] in, Indicates the first A set of responsibility fragments obtained by dividing the runtime events of each terminal; Indicates the first The first of the terminal running events A fragment of responsibility; Indicates the first The number of responsibility fragments obtained by dividing a terminal's runtime event; Indicates the first The fragment attribute vector of each responsibility fragment is used to uniformly express all responsibility attributes of that responsibility fragment; This represents the fragment attribute encoding function, used to compress various attributes of responsibility fragments into a unified vector; This represents the feature vector of the original terminal running event, used to characterize which running event the responsibility fragment originated from; This indicates the category of responsibility fragment, used to characterize whether the responsibility fragment belongs to the state responsibility fragment, resource responsibility fragment, protection responsibility fragment, linkage responsibility fragment, receipt responsibility fragment, or log responsibility fragment; This indicates the characteristics of the object on which the responsibility fragment operates, and is used to characterize the scope of the object on which the responsibility fragment operates; This indicates the characteristics of the time period in which the fragment of responsibility appears, and is used to characterize whether the fragment of responsibility appears in the initial stage of manifestation, the stage of responsibility diffusion, the stage of responsibility stabilization, or the stage of responsibility termination; This indicates the directional characteristics of the responsibility fragment, used to characterize whether the responsibility fragment converges inward, propagates outward, propagates upward, or expands downward; The characteristics representing the convergence state of a responsibility fragment are used to characterize whether the fragment is currently in an unconverged, partially converged, or fully converged state. This represents the set of responsibility fragments, which is the complete set of responsibility fragments obtained after dividing all relevant terminal runtime events. Through this processing, the server transforms the complex runtime event flow into a set of responsibility fragments with a clear structure, consistent granularity, and independent attributability, providing fine-grained input for subsequent reverse responsibility processing.

[0124] After the set of responsibility fragments is formed, the server performs responsibility reverse processing on the set of responsibility fragments based on the responsibility locking record table. This process involves reclaiming responsibility fragments based on object boundaries, behavior boundaries, condition boundaries, and time boundaries, generating a responsibility reverse processing result. Responsibility reverse processing refers to the process of tracing back from the responsibility manifestation result after execution to which control consequence bit and which responsibility host it should be reclaimed to. The responsibility locking record table has already solidified the primary locking relationship, secondary locking relationship, and corresponding boundaries for each control consequence bit in the previous steps. Therefore, the core of the current responsibility reverse processing is to determine whether each responsibility fragment meets the locking conditions of a certain control consequence bit and its responsibility host. The server first calculates the reverse reclamation fit for each responsibility fragment and each locking record, and then performs responsibility host reclamation according to the rule of primary locking priority and secondary locking compensation. Its expression is:

[0125]

[0126]

[0127]

[0128]

[0129]

[0130] in, Indicates the first The fragment of responsibility relative to the first The reverse reclamation adaptation of the responsibility lock record; Represents object boundary matching degree, used to measure the relationship between the object acting on the responsibility fragment and the first... The degree of overlap between the boundaries of the record objects is locked under the responsibility; Indicates the behavioral boundary matching degree, used to measure the relationship between the responsibility fragment category and responsibility direction and the first... The degree of consistency of the control consequence bit category in the liability lockout record; Indicates the condition boundary matching degree, used to measure the relationship between the conditions for the formation of responsibility fragments and the first condition boundary. The degree to which the conditions for locking down responsibility are met between the records; Indicates the time boundary matching degree, used to measure the time period in which responsibility fragments appear and the first... The degree of overlap between the time boundaries of the liability lock records; Indicates the continuity of liability sources, used to measure the degree of consistency between the source of liability fragments and the liability delivery identifier; , , , , This represents the weighting coefficient of each reverse recovery component, with a value ranging from zero to one, and the sum of the values ​​is one. This represents the index of the responsibility lock record that best matches the current responsibility fragment; This represents the primary responsibility closure threshold, used to determine whether the current responsibility fragment can be directly recycled to the primary responsible host; This indicates the threshold for secondary liability compensation, used to determine whether the current liability fragment can only be recovered along the secondary liability path; This represents a set of fragmented responsibilities that constitute a closed loop. This represents a collection of fragmented pieces of supplementary liability compensation responsibility; This represents the set of responsibility drift fragments. The server ultimately generates the responsibility reverse processing result based on the three types of responsibility fragment sets. If the primary responsibility closure fragments dominate, it indicates that the current responsibility chain is closed normally; if there are many secondary responsibility compensation fragments, it indicates that the current responsibility chain has a local dependence on the secondary responsibility host; if a large number of responsibility drift fragments appear, it indicates that the current control behavior has a significant risk of responsibility drift.

[0131] After completing the responsibility reversal process, the server collects responsibility delivery identifiers from different protocol channels within the same preset observation window and constructs a cross-protocol responsibility association graph. Based on control consequence bit overlap, responsibility host sharing, responsibility fragment competition, and time succession, it performs multi-protocol responsibility migration determination. The cross-protocol responsibility association graph refers to the responsibility relationship map constructed within the same preset observation window, using responsibility delivery identifiers from different protocol channels as nodes and potential relationships between responsibilities as edges. Control consequence bit overlap characterizes whether responsibility delivery identifiers from different protocol channels have highly overlapping control consequence bits in terms of object scope, consequence category, and time interval; responsibility host sharing characterizes whether different protocol channels jointly map control consequence bits to the same responsibility host; responsibility fragment competition characterizes whether the same responsibility fragment is simultaneously contested by different protocol responsibility chains; and time succession characterizes whether a later-arriving protocol responsibility chain has taken over the responsibility manifestation of an earlier-arriving protocol responsibility chain in time. The server calculates the cross-protocol migration strength between any two protocol responsibility nodes, expressed as:

[0132]

[0133]

[0134] in, Indicates protocol node With protocol nodes The strength of cross-protocol responsibility transfer between the two is used to measure the likelihood of responsibility transfer occurring between them. Indicates the overlap of control consequence bits, used to characterize the degree of overlap between two protocol responsible nodes at the control consequence bit level; This indicates the degree of shared responsibility host, used to characterize the extent to which two protocol responsibility nodes share the responsibility host. This indicates the degree of competition for responsibility fragments, used to characterize the extent to which two protocol responsibility nodes compete for ownership of the same responsibility fragment; Indicates time continuity, used to characterize the degree of continuity between two protocol responsibility nodes in terms of responsibility manifestation time; , , , , This represents the weight coefficient of each migration component, with a value ranging from zero to one, and a total sum of one. This term represents the coupling of overlapping and competitive relationships, and is used to strengthen the migration risk in scenarios with high overlap and high competition. This represents the cross-protocol association threshold, used to determine whether a migration edge has been established between two protocol responsible nodes; Represents a cross-protocol responsibility relationship diagram; This represents the set of responsible delivery identifier nodes; This represents the set of edges for cross-protocol migration. By constructing a cross-protocol responsibility association graph, the server unifies the responsibility chains that were originally scattered across different protocol channels into the same graph space, providing a graph structure foundation for subsequent multi-protocol responsibility migration determination.

[0135] After the cross-protocol responsibility association graph is formed, the server generates a multi-protocol responsibility migration determination result based on the multi-protocol responsibility migration determination. The multi-protocol responsibility migration determination does not simply determine whether migration exists, but rather classifies the migration pattern into different levels. If there is only partial overlap in control consequence bits between different protocol channels, but responsibility fragments are still independently recovered along their respective responsibility locking paths, it is determined as no migration overlap; if multiple protocol channels share a local responsibility host, but the responsibility source has not drifted, it is determined as boundary sharing migration; if one protocol channel clearly absorbs responsibility fragments that another protocol channel should have borne, it is determined as responsibility absorption migration; if the later-arriving protocol responsibility chain continuously takes over the responsibility manifestation and recovery paths of the earlier-arriving protocol responsibility chain in time, it is determined as responsibility succession migration. The server represents different migration modes as follows:

[0136]

[0137]

[0138] in, Indicates protocol node With protocol nodes The responsibility migration type label between them has a value of zero indicating no migration overlap, a value of one indicating boundary-shared migration, a value of two indicating responsibility-attached migration, and a value of three indicating responsibility-successive migration. This indicates the threshold for determining the overlap of control consequences. This indicates the threshold for determining the contention of responsibility fragments; Indicates the threshold for determining time continuation; This indicates that the responsible host shares the judgment threshold; This represents the set of multi-protocol responsibility migration determination results, used to record the migration relationships and migration types between all cross-protocol responsibility nodes.

[0139] S160. Based on the draft responsibility settlement, the identification results of the responsibility transfer identification layer, the responsibility locking record table, the responsibility reverse processing results, and the multi-protocol responsibility migration judgment results, a semantic constraint ruling is generated to achieve semantic constraints on multi-protocol control instructions.

[0140] Specifically, the server first constructs an adjudication convergence base plane, and within this base plane, establishes an adjudication evaluation unit for each responsibility delivery identifier. Simultaneously, the control consequence bit set, responsibility transfer identification layer recognition results, responsibility locking record table, responsibility reverse processing results, and multi-protocol responsibility migration judgment results from the responsibility settlement draft are loaded into the adjudication evaluation unit. The adjudication convergence base plane refers to the unified responsibility information carrying plane used in the semantic constraint adjudication stage. Its function is to gather the results generated separately from previous responsibility analysis stages under the same responsibility delivery identifier, forming a jointly assessable responsibility adjudication context. The responsibility delivery identifier is the unique responsibility entry identifier throughout the entire control link, used to ensure that all subsequent adjudication actions revolve around the same candidate control instruction body. The adjudication evaluation unit is the smallest adjudication entity constructed centered on a single responsibility delivery identifier. Internally, it simultaneously retains the control consequence bit set, host mapping structure, responsibility transfer identification conclusion, responsibility locking relationship, responsibility fragment recovery status, and cross-protocol migration status. To ensure that responsibility information from different sources can be uniformly placed in the same evaluation space, the server constructs an adjudication convergence vector for various input results, the expression of which is:

[0141]

[0142]

[0143] in, The adjudication convergence vector is used to uniformly project the responsibility settlement draft, the responsibility transfer identification layer identification results, the responsibility locking record table, the responsibility reverse processing results, and the multi-protocol responsibility migration judgment results onto the same adjudication space. This represents the adjudication compression function, used to constrain the value of the fused multi-source results within a stable range; This represents the set of control consequence bits encoding, used to express all control consequence bits and their attributes in the draft of the responsibility settlement; The encoding of the responsibility transfer identification layer is used to express whether there is a risk of false attributable host mapping for each control consequence bit; The code in the responsibility locking record table is used to express the primary locking relationship, secondary locking relationship, and locking boundary of each control consequence bit; This represents the encoding of the reverse processing result of responsibility, used to express the recovery result of responsibility fragments within a preset observation window; This represents the encoding of the multi-protocol responsibility migration determination result, used to express the type and intensity of cross-protocol responsibility migration; , , , , These represent the mapping matrices for each type of input result; Indicates the convergence bias term of the ruling; Represents the adjudication evaluation unit vector; This indicates a vector concatenation operation, used to connect the adjudication convergence vector with the responsibility delivery identifier code; This represents the liability delivery identifier code. Through the above processing, the server transforms the results of the preceding liability analysis into a unified adjudication input, thereby laying the foundation for subsequent multi-dimensional liability assessment.

[0144] After the adjudication evaluation unit is established, the server performs a responsibility integrity evaluation on the responsibility settlement draft based on the adjudication evaluation unit, a responsibility mapping stability evaluation on the responsibility transfer identification layer results, and a lock consistency evaluation on the responsibility lock record table to generate responsibility integrity markers, mapping stability markers, and lock credibility markers. The purpose of the responsibility integrity evaluation is to determine whether the set of control consequence bits in the responsibility settlement draft completely covers the responsibility unfolding path that the candidate control instruction body should generate based on action semantics, object semantics, condition semantics, and persistence semantics. If a certain type of main behavioral consequence, resource boundary consequence, protection response consequence, linkage propagation consequence, or exit convergence consequence that should occur is not generated, it indicates that there is a responsibility expression gap in the responsibility settlement draft. The purpose of the responsibility mapping stability evaluation is to determine whether the primary and secondary responsible hosts in the host mapping structure are stable and whether there is a risk of being mapped to a pseudo-attributable host. The purpose of the lock consistency evaluation is to determine whether the primary lock relationship, secondary lock relationship, and their lock boundaries in the responsibility lock record table are consistent with the responsibility settlement draft and the host mapping structure. The server constructs three types of evaluation functions, with the following expressions:

[0145]

[0146]

[0147]

[0148]

[0149] in, The responsibility integrity score is used to measure whether the responsibility settlement draft fully covers the control responsibility path; This represents the set of missing control consequence bits, used to record the number of control consequence bits that should have existed but were not expanded; This represents the set of broken chains of responsibility, used to record the number of consequences where the relationship between the preceding and following responsibilities is not closed, even though there are control consequences. This indicates the total number of control consequences that should theoretically exist in the draft law on responsible settlement. This indicates an extremely small positive number that prevents the denominator from being zero; This represents the stability score of the responsibility mapping, which measures whether the host mapping of all control consequence bits is stable. Indicates the total number of bits representing the control consequences; Indicates the first The risk value of liability transfer corresponding to each control consequence bit is used to characterize the degree of risk of it being mapped to a pseudo-attributable host. Indicates the first The mapping credibility weight of each control consequence bit is used to characterize the importance of that control consequence bit in the current chain of responsibility; The lockout consistency score measures the degree of consistency between the responsibility lockout record table and the control consequence bit boundary. , , , They represent the first The degree of lock consistency of each control consequence bit on object boundaries, behavior boundaries, condition boundaries, and time boundaries; , , These represent the responsibility integrity threshold, the mapping stability threshold, and the locking consistency threshold, respectively. This represents a responsibility integrity flag, with a value of one indicating completeness and a value of zero indicating incompleteness. This represents the mapping stability flag, with a value of one indicating stability and a value of zero indicating instability. This represents a trusted flag, with a value of one indicating trustworthiness and a value of zero indicating untrustworthiness. Through this set of processing steps, the server can compress the states of the responsibility expression layer, responsibility mapping layer, and responsibility locking layer into standardized flags that can be directly used for subsequent comprehensive adjudication.

[0150] After generating the responsibility integrity marker, mapping stability marker, and lock trust marker, the server performs a responsibility closure assessment on the responsibility reverse processing results based on the adjudication evaluation unit, and generates responsibility closure level markers according to the primary responsibility closure fragments, secondary responsibility compensation fragments, and drifting responsibility fragments. Responsibility closure refers to whether the responsibility fragments formed after the execution of control instructions can be naturally recovered to the primary or secondary responsible host along the preceding responsibility locking path. Primary responsibility closure fragments are those that can be directly recovered to the primary responsible host according to the primary locking relationship; secondary responsibility compensation fragments are those that cannot be completely recovered to the primary responsible host but can be recovered to the secondary responsible host under the constraints of the secondary locking relationship; drifting responsibility fragments are those that cannot be recovered under the primary and secondary locking relationships. The server constructs a responsibility closure level score based on the distribution of these three types of responsibility fragments, expressed as:

[0151]

[0152]

[0153] in, This represents the responsibility closure score, used to comprehensively measure the completeness of the recovery after the current chain of responsibility has been executed; This represents a set of fragmented responsibilities that constitute a closed loop. This represents a collection of fragmented pieces of supplementary liability compensation responsibility; Represents a set of drift responsibility fragments; , , These represent the number of fragments of responsibility in each of the three categories; This indicates the primary responsibility closure weight, used to enhance the positive contribution of primary responsibility closure fragments to the closure score; This indicates the weight of supplementary liability compensation, used to reflect the limited positive contribution of supplementary liability compensation fragments to the closure of liability; This indicates the drift penalty weight, used to reflect the negative impact of drift liability fragments on liability closure; This indicates an extremely small positive number that prevents the denominator from being zero; The value indicates the level of responsibility closure. A value of two indicates a high level of closure, a value of one indicates a medium level of closure, and a value of zero indicates a low level of closure. Indicates a high closure threshold; This indicates a low closure threshold. Through this processing, the server elevates the results of the reverse responsibility processing from observations at the fragmented level of responsibility to a level marker of the overall closure degree of the responsibility chain, thus providing a strong basis for subsequent risk classification.

[0154] After generating the responsibility closure level marker, the server performs cross-protocol consistency evaluation processing on the multi-protocol responsibility migration judgment results based on the adjudication evaluation unit to generate protocol stability markers, protocol sharing markers, protocol absorption markers, and protocol continuation markers. Cross-protocol consistency refers to whether, within the same preset observation window, responsibility delivery identifiers in different protocol channels maintain clear responsibility boundaries, independent responsibility recovery, or whether responsibility sharing, absorption, or continuation occurs. The protocol stability marker indicates that the current responsibility chain remains independent and stable across protocols; the protocol sharing marker indicates that multiple protocol chains share boundaries but the source of responsibility has not changed; the protocol absorption marker indicates that the current responsibility chain absorbs or is absorbed by responsibility fragments from other protocol chains; and the protocol continuation marker indicates that a later-arriving protocol chain takes over the responsibility manifestation of an earlier-arriving protocol chain in terms of time and responsibility path. The server constructs a cross-protocol consistency evaluation vector based on the migration type distribution in the multi-protocol responsibility migration judgment results, the expression of which is:

[0155]

[0156]

[0157]

[0158] in, This represents the cross-protocol consistency assessment vector, used to express the proportion of different cross-protocol responsibility migration types in the current responsibility delivery identifier related window; This indicates the stability of the protocol and is used to characterize the proportion of results with no migration overlap. Indicates the protocol sharing degree, used to characterize the proportion of boundary-sharing migration results; Indicates the degree of adsorption according to the agreement, used to characterize the proportion of responsible adsorption and migration results; Indicates the protocol continuity degree, used to characterize the proportion of responsibility continuity transfer results; , , , These represent the number of migrations with no overlap, boundary-shared migrations, responsibility-attracting migrations, and responsibility-succession migrations, respectively. This represents the total number of all cross-protocol migration decision relationships; This indicates an extremely small positive number that prevents the denominator from being zero; This represents the primary tag for cross-protocol consistency, and its value corresponds to the dominant category among protocol stability, protocol sharing, protocol snapping, or protocol continuation tags. Through this processing, the server compresses complex cross-protocol responsibility relationships into protocol consistency tags that can be directly incorporated into the comprehensive decision-making process.

[0159] After completing the responsibility integrity assessment, responsibility mapping stability assessment, lock consistency assessment, responsibility closure assessment, and cross-protocol consistency assessment, the server performs a comprehensive adjudication assessment based on the responsibility integrity flag, mapping stability flag, lock trust flag, responsibility closure level flag, and cross-protocol consistency assessment results to generate a semantic risk level. The semantic risk level is a comprehensive risk expression of the candidate control instruction body represented by the current responsibility delivery identifier across the entire responsibility chain. Its assessment basis is no longer limited to a single anomaly, but simultaneously considers whether the responsibility expression is complete, whether the host mapping is stable, whether the lock relationship is trustworthy, whether the responsibility recovery is closed, and whether cross-protocol behavior is abnormal. To ensure that assessment results from different dimensions can uniformly participate in risk calculation, the server constructs a semantic risk scoring function, the expression of which is:

[0160]

[0161]

[0162]

[0163] in, The semantic risk score is used to comprehensively measure the overall risk level of the current candidate control instruction body in terms of responsibility expression, responsibility mapping, responsibility locking, responsibility recovery, and cross-protocol behavior. , , , , This represents the weighting coefficient of each risk component, with values ​​ranging from zero to one, and a total sum of one. This represents a responsibility integrity flag, with a value of one indicating completeness and a value of zero indicating incompleteness. This represents the mapping stability flag, with a value of one indicating stability and a value of zero indicating instability. This represents a trusted flag; a value of one indicates trusted, and a value of zero indicates untrusted. The value indicates the level of responsibility closure, with a value of 2 representing high closure, a value of 1 representing medium closure, and a value of zero representing low closure. This represents the cross-protocol risk added value, used to map the risk level of different protocols to numerical penalties based on the cross-protocol consistency main label; The main label represents cross-protocol consistency. A value of zero indicates protocol stability, a value of one indicates protocol sharing, a value of two indicates protocol absorption, and a value of three indicates protocol continuation. The value represents the semantic risk level, with zero indicating low risk, one indicating medium risk, two indicating high risk, and three indicating extremely high risk. , , These represent the boundary thresholds between different semantic risk levels. Through this processing, the server unifies the multidimensional responsibility assessment results into a single semantic risk level that can directly drive subsequent constraint actions.

[0164] After obtaining the semantic risk level, the server generates a semantic constraint decision based on the semantic risk level and writes the semantic constraint decision back to the control instruction processing chain corresponding to the responsibility delivery identifier to achieve semantic constraints on multi-protocol control instructions. The semantic constraint decision is the final constraint action result for the candidate control instruction body corresponding to the current responsibility delivery identifier. Its function is not simply to give permission or denial, but to determine how the control instruction should be executed based on the semantic risk level. Low risk corresponds to a normal execution decision, indicating that the current candidate control instruction body can continue to be allowed along the established control chain; medium risk corresponds to a restricted execution decision, indicating that the current candidate control instruction body can only be executed within the restricted object boundary, restricted time boundary, or restricted protocol boundary; high risk corresponds to an isolation execution decision, indicating that the current candidate control instruction body must be isolated to a single protocol channel or a single responsibility chain and is not allowed to continue interacting with other protocol responsibility chains; extremely high risk corresponds to a blocking execution decision, indicating that the control behavior of the current candidate control instruction body is terminated. The server represents the decision result as follows:

[0165]

[0166]

[0167] in, Indicates the result of semantic constraint adjudication; This indicates that the ruling has been executed normally; Indicates that the ruling is subject to restricted execution. This indicates that the decision to isolate and enforce the order has been made. This indicates a blockade of the enforcement of the ruling; Indicates the status of the original control instruction processing chain corresponding to the responsibility delivery identifier; Indicates the status of the control instruction processing chain after the write-back decision; This indicates the write-back function, used to update the execution status, responsibility status, and subsequent scheduling status of the control instruction processing chain based on the responsibility delivery identifier and the semantic constraint decision result. Through this write-back process, the current semantic constraint decision not only affects the execution path of the current candidate control instruction body, but also updates the subsequent processing rules of the entire responsibility chain, so that subsequent control behaviors arriving under the same responsibility delivery identifier or the same responsibility context are continuously constrained.

[0168] This application also provides a multi-protocol instruction semantic constraint device for IoT smart terminals, referring to... Figure 2 , Figure 2This application provides a schematic diagram of a multi-protocol instruction semantic constraint device for IoT smart terminals. The device is a server, comprising an acquisition module 21 and a processing module 22. The acquisition module 21 acquires raw control instructions from multiple protocol channels and generates a responsibility delivery identifier for each raw control instruction. It also extracts action semantics, object semantics, conditional semantics, and persistence semantics from the raw control instructions to form candidate control instruction bodies. The processing module 22 constructs a control responsibility environment around the target IoT smart terminal and generates a responsibility host pool. The responsibility host pool consists of multiple responsible hosts capable of bearing control consequences, each with a host identifier, host category, host lifecycle, and host responsibility boundary. The processing module 22 also generates a set of control consequence bits based on the candidate control instruction bodies, generates a consequence bit identifier for each control consequence bit, and binds the consequence bit identifier to the responsibility delivery identifier to form a responsibility settlement draft. Finally, it processes the control consequence bits in the responsibility settlement draft based on the responsibility host pool. The processing module 22 performs a responsibility host matching process to obtain a host mapping structure. It also constructs a responsibility transfer identification layer and projects the host mapping structure into it to identify whether control consequence bits are mapped to pseudo-attributable hosts. Furthermore, it performs responsibility host locking processing on the control consequence bits in the host mapping structure and their corresponding candidate responsible hosts to form a responsibility locking record table. The processing module 22 also acquires terminal running events within a preset observation window after the candidate control instruction body is executed, generates a responsibility fragment set, performs responsibility reverse processing on the responsibility fragment set according to the responsibility locking record table, obtains the responsibility reverse processing result, and performs multi-protocol responsibility migration judgment on responsibility delivery identifiers from different protocol channels within the same preset observation window to obtain the multi-protocol responsibility migration judgment result. Finally, the processing module 22 generates a semantic constraint ruling based on the responsibility settlement draft, the responsibility transfer identification layer identification result, the responsibility locking record table, the responsibility reverse processing result, and the multi-protocol responsibility migration judgment result to achieve semantic constraints on multi-protocol control instructions.

[0169] This application also provides an electronic device, with reference to... Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: at least one processor 31, at least one network interface 34, a user interface 33, a memory 35, and at least one communication bus 32.

[0170] The communication bus 32 is used to enable communication between these components.

[0171] The user interface 33 may include a display screen and a camera. Optionally, the user interface 33 may also include a standard wired interface and a wireless interface.

[0172] The network interface 34 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0173] The processor 31 may include one or more processing cores. The processor 31 connects to various parts of the server via various interfaces and lines, executing instructions, programs, code sets, or instruction sets stored in the memory 35, and calling data stored in the memory 35 to perform various server functions and process data. Optionally, the processor 31 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 31 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 31 and may be implemented as a separate chip.

[0174] The memory 35 may include random access memory (RAM) or read-only memory. Optionally, the memory 35 may include a non-transitory computer-readable storage medium. The memory 35 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 35 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 35 may also be at least one storage device located remotely from the aforementioned processor 31. Figure 3 As shown, the memory 35, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a multi-protocol instruction semantic constraint method for Internet of Things smart terminals.

[0175] exist Figure 3 In the electronic device shown, the user interface 33 is mainly used to provide an input interface for the user and obtain the user input data; while the processor 31 can be used to call the application program stored in the memory 35, which is a multi-protocol instruction semantic constraint method for IoT smart terminals. When executed by one or more processors, the electronic device executes one or more methods as described in the above embodiments.

[0176] This application also provides a non-transitory computer-readable storage medium storing instructions. When executed by one or more processors, these instructions cause an electronic device to perform one or more of the methods described in the above embodiments.

[0177] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for semantic constraint of multi-protocol instructions for IoT smart terminals, characterized in that, The method includes: The system acquires raw control commands from multiple protocol channels and generates a responsibility delivery identifier for each raw control command. Simultaneously, it extracts the action semantics, object semantics, conditional semantics, and persistence semantics from the raw control commands to form candidate control command bodies. A control responsibility environment is constructed around the target IoT smart terminal, and a responsibility host pool is generated. The responsibility host pool consists of multiple responsible hosts that can bear the control consequences. Each responsible host has a host identifier, host category, host life cycle, and host responsibility boundary. A set of control consequence bits is generated based on the candidate control instruction body, and a consequence bit identifier is generated for each control consequence bit. At the same time, the consequence bit identifier is bound to the responsibility delivery identifier to form a responsibility settlement draft. Responsibility host matching processing is performed on the control consequence bits in the responsibility settlement draft based on the responsibility host pool to obtain the host mapping structure. A responsibility transfer identification layer is constructed, and the host mapping structure is projected into the responsibility transfer identification layer to identify whether the control consequence bit is mapped to a pseudo-attributable host. Responsibility host locking processing is performed on the control consequence bit in the host mapping structure and the corresponding candidate responsible host to form a responsibility locking record table. After the candidate control instruction body is executed, the terminal running event is acquired in the preset observation window, and a responsibility fragment set is generated. At the same time, the responsibility fragment set is processed in reverse according to the responsibility locking record table to obtain the responsibility reverse processing result. In the same preset observation window, the responsibility delivery identifier from different protocol channels is judged by multi-protocol responsibility migration to obtain the multi-protocol responsibility migration judgment result. Based on the draft responsibility settlement, the identification results of the responsibility transfer identification layer, the responsibility locking record table, the responsibility reverse processing results, and the multi-protocol responsibility migration judgment results, a semantic constraint ruling is generated to achieve semantic constraints on multi-protocol control instructions.

2. The multi-protocol instruction semantic constraint method for IoT smart terminals according to claim 1, characterized in that, The process involves acquiring raw control commands from multiple protocol channels, generating a responsibility delivery identifier for each raw control command, and extracting action semantics, object semantics, conditional semantics, and persistence semantics from the raw control commands to form candidate control command bodies. Specifically, this includes: A multi-protocol access plane is constructed on the access side of the target IoT smart terminal, and a channel identifier, protocol type identifier, access direction identifier, and session boundary identifier are fixed for each protocol channel, so that the original control command entering the system is bound to the corresponding protocol source range and access context range; The arriving data in the multi-protocol access plane is subjected to raw control instruction filtering processing, and the filtered raw control instructions are subjected to raw retention processing to form raw instruction mirror fragments. At the same time, channel normalization description processing is performed to form a control semantic description structure. Based on the control semantic description structure, the action semantics, object semantics, condition semantics, and persistence semantics of the original control instruction are extracted, and consistency verification processing is performed on the action semantics, object semantics, condition semantics, and persistence semantics. After the consistency check is passed, a responsibility delivery identifier is generated, and a candidate control instruction body is assembled based on the original instruction image fragment, the control semantic description structure, the action semantic, the object semantic, the condition semantic, the continuity semantic, and the responsibility delivery identifier.

3. The multi-protocol instruction semantic constraint method for IoT smart terminals according to claim 1, characterized in that, The process involves constructing a control responsibility environment around the target IoT smart terminal and generating a responsibility host pool. This responsibility host pool consists of multiple responsible hosts capable of assuming control consequences. Each responsible host possesses a host identifier, host category, host lifecycle, and host responsibility boundaries, specifically including: A responsibility observation baseline is established around the target IoT smart terminal, and the terminal identifier, the current operating status of the terminal, the historical control trajectory of the terminal, the activated linkage relationship of the terminal, the current authorization relationship of the terminal, and the unclosed control transactions of the terminal are solidified in the responsibility observation baseline to form the control context of the target IoT smart terminal; Based on the control context, a control context splitting process is performed to split the control context into a session bearer area, a protection bearer area, a linkage bearer area, an authorization bearer area, and a maintenance bearer area. In each responsible bearer area, a responsible host extraction process is performed to identify the responsible unit that can independently bear the control consequences and generate a responsible host. For each responsible host, a host identifier is generated and the host category is determined, wherein the host category includes session-type responsible hosts, protection-type responsible hosts, linkage-type responsible hosts, authorization-type responsible hosts, and maintenance-type responsible hosts; Perform host lifecycle characterization processing on each responsible host to determine the lifecycle start boundary, lifecycle maintenance phase and lifecycle end boundary of the responsible host; For each responsible host, a host responsibility boundary generation process is performed to generate object boundaries, behavior boundaries, condition boundaries, and time boundaries, and the scope of control consequences that the responsible host can bear is limited based on the object boundaries, behavior boundaries, condition boundaries, and time boundaries. The generated responsible hosts are processed to resolve host conflicts, and the processed responsible hosts are written into the responsible host registration table to form a responsible host pool.

4. The multi-protocol instruction semantic constraint method for IoT smart terminals according to claim 1, characterized in that, The process involves generating a set of control consequence bits based on the candidate control instruction body, generating a consequence bit identifier for each control consequence bit, and binding the consequence bit identifier with the responsibility delivery identifier to form a responsibility settlement draft. Then, responsibility host matching processing is performed on the control consequence bits in the responsibility settlement draft based on the responsibility host pool to obtain a host mapping structure. Specifically, this includes: The system receives the candidate control instruction body and performs boundary determination processing on the control consequences based on the action semantics, object semantics, condition semantics and duration semantics in the candidate control instruction body, so as to limit the object range, triggering premise and duration interval of the control consequences. Based on the control consequence expansion boundary, perform hierarchical expansion processing of control consequences to generate main behavior consequences, resource boundary consequences, protection response consequences, linkage propagation consequences, and exit convergence consequences. Then, perform control consequence bit segmentation processing on each consequence layer to form a set of control consequence bits. For each control consequence bit in the control consequence bit set, a consequence bit attribute is generated, and a consequence bit identifier is generated based on the consequence bit attribute. At the same time, the consequence bit identifier is bound to the responsibility delivery identifier to form a responsibility settlement draft. Based on the responsible host pool, the control consequence bits in the responsible settlement draft are pre-screened for responsible hosts to select a subset of responsible hosts that meet the constraints of host category, host life cycle and host liability boundary. Based on object boundary matching degree, behavior boundary matching degree, condition boundary matching degree, and time boundary matching degree, the responsibility host subset is subjected to responsibility host matching processing to determine the primary and secondary responsible hosts corresponding to each control consequence bit; A host mapping structure is generated based on the mapping relationship between each control consequence bit and its corresponding primary and secondary responsible hosts.

5. The multi-protocol instruction semantic constraint method for IoT smart terminals according to claim 1, characterized in that, The process involves constructing a responsibility transfer identification layer and projecting the host mapping structure onto it to identify whether control consequence bits are mapped to pseudo-attributable hosts. Furthermore, responsibility host locking processing is performed on the control consequence bits in the host mapping structure and their corresponding candidate responsible hosts to form a responsibility locking record table. Specifically, this includes: A recognition background base surface is constructed around the host mapping structure, and the host identifier, host category, host life cycle and host responsibility boundary in the responsible host pool are solidified in the recognition background base surface. At the same time, the action semantics, object semantics, conditional semantics and persistence semantics in the candidate control instruction body are solidified to form a responsibility transfer recognition environment. Based on the responsibility transfer identification environment, a set of pseudo-attributable hosts is generated. The set of pseudo-attributable hosts includes historical residual hosts, bridging transition hosts, circumstantial evidence-driving hosts, and background adsorption hosts. Identification, marking, and solidification processing are performed on the pseudo-attributable hosts. The host mapping structure is projected onto the responsibility transfer identification layer to form a mapping review unit. For each mapping review unit, life cycle validity identification processing, responsibility boundary closure identification processing, responsibility source continuity identification processing, and primary and secondary responsibility reasonableness identification processing are performed to identify whether the control consequence bit is mapped to a pseudo-attributable host. Based on the identification and processing results, a responsibility transfer identification result is generated, and based on the responsibility transfer identification result, control consequence bits that can enter the locking stage and corresponding candidate responsible hosts are screened. For the selected control consequence bits and corresponding candidate responsible hosts, a primary locking relationship and a secondary locking relationship are generated, and the locking boundary solidification processing is performed on the primary locking relationship and the secondary locking relationship based on the object boundary, behavior boundary, condition boundary and time boundary; A responsibility locking record table is generated based on the primary locking relationship, secondary locking relationship, and locking boundary.

6. The multi-protocol instruction semantic constraint method for IoT smart terminals according to claim 1, characterized in that, After the candidate control command body is executed, the terminal running event is acquired within a preset observation window, and a responsibility fragment set is generated. Simultaneously, responsibility reversal processing is performed on the responsibility fragment set according to the responsibility locking record table to obtain the responsibility reversal processing result. Furthermore, within the same preset observation window, multi-protocol responsibility migration determination is performed on responsibility delivery identifiers from different protocol channels to obtain the multi-protocol responsibility migration determination result. Specifically, this includes: After the candidate control instruction body is executed, an observation start unit is established based on the responsibility delivery identifier, and a running event acquisition base is constructed to acquire the target IoT smart terminal's status change events, resource change events, protection change events, linkage change events, execution receipt events, and log recording events within a preset observation window; The preset observation window is segmented to form a display start segment, a responsibility diffusion segment, a responsibility stabilization segment, and a responsibility convergence segment. Based on the running event acquisition base, the acquired terminal running events are screened to obtain terminal running events associated with the responsibility delivery identifier. The terminal running events are processed to perform responsibility fragment segmentation and generate responsibility fragments. At the same time, fragment attributes are generated for each responsibility fragment and a set of responsibility fragments is formed. Based on the responsibility locking record table, responsibility reverse processing is performed on the responsibility fragment set to perform responsibility host recycling processing on the responsibility fragments according to object boundaries, behavior boundaries, condition boundaries, and time boundaries, and to generate responsibility reverse processing results. Collect responsibility delivery identifiers from different protocol channels within the same preset observation window and construct a cross-protocol responsibility association graph. Then, perform multi-protocol responsibility migration determination based on control consequence bit overlap, responsibility host sharing, responsibility fragment competition, and time succession. The multi-protocol responsibility migration determination result is generated based on the multi-protocol responsibility migration determination.

7. The multi-protocol instruction semantic constraint method for IoT smart terminals according to claim 1, characterized in that, The process involves generating a semantic constraint ruling based on the responsibility settlement draft, the responsibility transfer identification layer identification results, the responsibility locking record table, the responsibility reverse processing results, and the multi-protocol responsibility migration determination results. This aims to achieve semantic constraints on multi-protocol control commands, specifically including: Construct an adjudication convergence base and establish an adjudication evaluation unit for each responsibility delivery identifier in the adjudication convergence base. At the same time, load the set of control consequences bits, the identification results of the responsibility transfer identification layer, the responsibility locking record table, the responsibility reverse processing results, and the multi-protocol responsibility migration judgment results from the responsibility settlement draft into the adjudication evaluation unit. Based on the aforementioned adjudication evaluation unit, the responsibility integrity assessment process is performed on the responsibility settlement draft, and the responsibility mapping stability assessment process is performed on the identification results of the responsibility transfer identification layer. At the same time, the lock consistency assessment process is performed on the responsibility lock record table to generate responsibility integrity markers, mapping stability markers, and lock credibility markers. Based on the adjudication evaluation unit, the responsibility closure evaluation process is performed on the responsibility reverse processing results, and responsibility closure level markers are generated according to the primary responsibility closure responsibility fragments, secondary responsibility compensation responsibility fragments, and drift responsibility fragments; Based on the adjudication evaluation unit, cross-protocol consistency evaluation processing is performed on the multi-protocol responsibility migration determination results to generate protocol stability markers, protocol sharing markers, protocol adsorption markers, and protocol continuation markers; A comprehensive adjudication assessment is performed based on the responsibility integrity marker, mapping stability marker, lock trust marker, responsibility closure level marker, and cross-protocol consistency assessment results to generate a semantic risk level. Based on the semantic risk level, a semantic constraint decision is generated, and the semantic constraint decision is written back to the control instruction processing chain corresponding to the responsibility delivery identifier, so as to realize the semantic constraint on the multi-protocol control instructions.

8. A multi-protocol instruction semantic constraint device for IoT smart terminals, characterized in that, The apparatus is used to execute the multi-protocol instruction semantic constraint method for IoT smart terminals as described in any one of claims 1 to 7, the apparatus comprising an acquisition module and a processing module, wherein... The acquisition module is used to acquire raw control instructions from multiple protocol channels, generate a responsibility delivery identifier for each raw control instruction, and extract action semantics, object semantics, conditional semantics and persistence semantics from the raw control instructions to form candidate control instruction bodies. The processing module is used to construct a control responsibility environment around the target IoT smart terminal and generate a responsibility host pool. The responsibility host pool consists of multiple responsibility hosts that can bear the control consequences. Each responsibility host has a host identifier, host category, host life cycle, and host responsibility boundary. The processing module is further configured to generate a set of control consequence bits based on the candidate control instruction body, generate a consequence bit identifier for each control consequence bit, bind the consequence bit identifier with the responsibility delivery identifier to form a responsibility settlement draft, and perform responsibility host matching processing on the control consequence bits in the responsibility settlement draft based on the responsibility host pool to obtain a host mapping structure. The processing module is also used to construct a responsibility transfer identification layer and project the host mapping structure into the responsibility transfer identification layer to identify whether the control consequence bit is mapped to a pseudo-attributable host, and to perform responsibility host locking processing on the control consequence bit in the host mapping structure and the corresponding candidate responsible host to form a responsibility locking record table. The processing module is also used to acquire terminal running events in a preset observation window after the candidate control instruction body is executed, generate a set of responsibility fragments, perform responsibility reverse processing on the set of responsibility fragments according to the responsibility locking record table to obtain the responsibility reverse processing result, and perform multi-protocol responsibility migration determination on responsibility delivery identifiers from different protocol channels in the same preset observation window to obtain the multi-protocol responsibility migration determination result. The processing module is also used to generate semantic constraint decisions based on the responsibility settlement draft, the responsibility transfer identification layer identification results, the responsibility locking record table, the responsibility reverse processing results, and the multi-protocol responsibility migration judgment results, so as to realize semantic constraints on multi-protocol control instructions.

9. An electronic device, characterized in that, The electronic device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1 to 7.

Images