Method, apparatus and device for serialized transmission of intent protocol instances

Abstract

The application relates to a serialization transmission method, device and equipment of an intent protocol instance. The method comprises the following steps: a sending end traverses each intent unit in the intent protocol instance, generates an intent unit frame for each intent unit, assembles a message header, encapsulates the message header and all the intent unit frames into a transmission message; an receiving end performs integrity verification on the transmission message according to a check value, returns a negotiation response carrying a supported main version range when the main version number is not within the support range, skips a dimension field block with an unknown type code and leaves a trace in a parsing abstract when the secondary version number is higher than the supported secondary version number, skips the intent unit frame not containing a required semantic dimension according to a dimension existence bitmap and a frame length, and delivers a parsing result to downstream processing together with a parsing abstract and a modal provenance sub-block. The method can enable the intent semantic structure to be carried at the message level, realize version negotiation, forward compatibility, transmission error detection and general tampering detection of intent transmission.

Description

Technical Field

[0001] This application relates to the field of communication protocols and data serialization technology, and in particular to a serialization transmission method, apparatus and device for an intent protocol instance. Background Technology

[0002] With the development of multi-agent systems and human-computer interaction technologies, structured task intentions need to be transmitted between heterogeneous systems and agents. An intent protocol instance is a type of structured data that carries task intentions. An intent protocol instance contains several intent units. Each intent unit organizes the semantic content of the task intention according to semantic dimensions such as object, action, sequence, condition, constraint, space, and time. The content of each semantic dimension can come from raw inputs of different modalities such as speech, text, and map point selection.

[0003] Currently, intent protocol instances are typically encapsulated in common serialization formats such as JSON and Protobuf when transmitted between systems. However, this transmission method has the following problems: First, generic serialization formats do not carry the semantic structure of intent. Generic formats can transmit arbitrary data, but they do not define how intent units, semantic dimensions, and modal origination are organized at the message level. The receiver cannot determine which semantic dimensions the message contains without parsing the full message, and therefore cannot skip to the required content as needed.

[0004] Secondly, there is a lack of version negotiation mechanism at the intent layer. After the protocol evolved, interoperability between new and old systems relies on offline agreements. There is no version declaration, incompatibility rejection, or negotiation response mechanism in the messages. Version mismatch will silently fail when collaborating with intelligent agents across vendors.

[0005] Third, it lacks forward compatibility. When the receiver encounters a new field, it either reports an error or discards the entire packet. There is no way to skip unknown fields and leave a record, which hinders the evolution of the protocol ecosystem.

[0006] Fourth, there is no built-in integrity verification. When the task intent is tampered with during multi-hop forwarding at the user end, orchestrator, and executor, it cannot be detected at the packet layer, and the tampered intent may directly enter the execution stage.

[0007] Fifth, inline transmission of multimodal payloads leads to message bloat, and the binding relationship between payloads and semantic fields is lost during transmission. Summary of the Invention

[0008] Therefore, it is necessary to provide a method, apparatus, computer device, and storage medium for serializing and transmitting intent protocol instances to address the aforementioned technical problems.

[0009] A method for serializing and transmitting an instance of an intent protocol, the method comprising: The sending end traverses each intent unit in the structured intent protocol instance, generates an intent unit frame for each intent unit, assembles a message header, and encapsulates the message header and all intent unit frames into a transmission message. The message header includes a message identification identifier, major version number, minor version number, instance identifier, message length, and checksum. The checksum is calculated based on the message header (excluding the checksum) and all intent unit frames. Each intent unit frame includes a unit identifier, a dimension existence bitmap, frame length, and a sequence of dimension field blocks. The dimension existence bitmap identifies the presence of dimension field blocks for each semantic dimension (object, action, sequence, condition, constraint, spatial, and temporal) in this intent unit frame. The sequence of dimension field blocks is arranged according to the bit order of the dimension existence bitmap. Each dimension field block in the sequence uses type-length-value encoding and carries a modal tracing sub-block recording the source of dimension information. The receiving end receives the transmission message, performs integrity verification on the transmission message according to the check value, and discards the transmission message and returns an error response when the integrity verification fails. When the integrity verification passes and the major version number is not within the range of major versions supported by the receiving end, the parsing of the transmission message is refused and a negotiation response is returned to the sending end; the negotiation response carries the range of major versions supported by the receiving end. When the integrity verification passes and the minor version number is higher than the minor version number supported by the receiving end, the dimension field blocks with unknown type codes in the dimension field block sequence are skipped according to the length field. The type code and length of the skipped dimension field blocks are recorded in the parsing digest, and the dimension field blocks with known type codes are parsed. Based on the existence bitmap of the dimension and the frame length, skip intent unit frames that do not contain the required semantic dimension, parse the dimension field block in the intent unit frame that contains the required semantic dimension, and deliver the parsing result, together with the parsing summary and the modality tracing sub-block, to downstream processing.

[0010] In one embodiment, generating an intent unit frame per intent unit includes: generating a dependency count and a dependency table, and writing the dependency count and the dependency table into the intent unit frame; wherein the dependency table records the unit identifiers of other intent units that the intent unit depends on, and the dependency table carries the directed dependency relationships between intent units in the intent protocol instance.

[0011] In one embodiment, the method further includes: converting media data in the intent protocol instance into a media reference block and writing it into the transport message; wherein the media reference block includes a reference address, a content hash value, and a bound dimension field path of the media data; obtaining the media data according to the reference address, comparing the obtained media data with the content hash value, and rejecting the use of the media data when the comparison is inconsistent.

[0012] In one embodiment, the modal tracing sub-block carrying the source of the recorded dimension information includes: writing the modal type code, the original input timestamp, and the semantic parsing confidence score into the modal tracing sub-block; and applying a differentiated processing strategy to the corresponding dimension field block based on the semantic parsing confidence score.

[0013] In one embodiment, assembling the message header includes: writing a flag bit into the message header, the flag bit declaring the compression state, encryption state, and fragmentation state of the transmitted message; after the receiving end receives the transmitted message, the method further includes: when the flag bit declares the transmitted message as a fragmented message, first reassembling each fragment; the check value is verified based on the message data after fragment reassembly and before decryption and decompression; after the integrity verification is passed, the transmitted message is decrypted or decompressed according to the flag bit, and then the processed transmitted message is parsed.

[0014] In one embodiment, the verification value is calculated based on the message header (excluding the verification value) and all the intent unit frames, including: using a hash algorithm to calculate the verification value on the message header (excluding the verification value) and all the intent unit frames; or using a message authentication code with a key to calculate the verification value on the message header (excluding the verification value) and all the intent unit frames; or using a digital signature to calculate the verification value on the message header (excluding the verification value) and all the intent unit frames; wherein, the key of the message authentication code with a key is pre-determined by the sending end and the receiving end, and the signature private key of the digital signature belongs to the sending end; the message header also includes a sequence number and a timeout field, wherein the timeout field is a timestamp or a random number; the receiving end maintains a sequence number record of processed transmission messages, and when the sequence number of the received transmission message already exists in the sequence number record, or the timeout field exceeds a preset valid range, the receiving end determines that the transmission message is a replay message, discards the transmission message, and returns an error response.

[0015] In one embodiment, the dimension field block also carries a disposal attribute flag, which declares that the dimension field block is an optional field block or a safety-critical field block; for a dimension field block with an unknown type code, when its disposal attribute flag is declared as an optional field block, it is skipped by the length field and recorded in the parsing digest; when its disposal attribute flag is declared as a safety-critical field block, the intent content corresponding to the intent unit frame to which the dimension field block belongs is refused to be executed, and at least one of the following processes is performed: returning a negotiation response carrying the type code to the sending end, or requesting manual confirmation from the upstream.

[0016] A receiving end processing apparatus for an intent protocol instance, the apparatus comprising: A message receiving module is used to receive transmission messages. The transmission messages are generated by the sending end through each intent unit in the structured intent protocol instance, generating intent unit frames for each intent unit, assembling a message header, and encapsulating the message header with all the intent unit frames. The message header includes a message identification identifier, a major version number, a minor version number, an instance identifier, a message length, and a checksum. The checksum is calculated based on the message header and all the intent unit frames except for the checksum. Each intent unit frame includes a unit identifier, a dimension existence bitmap, a frame length, and a sequence of dimension field blocks. The dimension existence bitmap identifies the existence of dimension field blocks for each semantic dimension in the object, action, sequence, condition, constraint, spatial, and temporal semantic dimensions in this intent unit frame. The sequence of dimension field blocks is arranged according to the bit order of the dimension existence bitmap. Each dimension field block in the sequence of dimension field blocks uses type-length-value encoding and carries a modal tracing sub-block that records the source of dimension information. The integrity verification module is used to perform integrity verification on the transmitted message based on the verification value. When the integrity verification fails, the transmitted message is discarded and an error response is returned. The version negotiation module is used to refuse to parse the transmission message and return a negotiation response to the sending end when the integrity verification passes and the major version number is not within the range of major versions supported by the device. The negotiation response carries the range of major versions supported by the device. When the integrity verification passes and the minor version number is higher than the minor version number supported by the device, the module skips dimension field blocks with unknown type codes in the dimension field block sequence according to the length field, records the type code and length of the skipped dimension field blocks in the parsing digest, and parses dimension field blocks with known type codes. The skip-read parsing module is used to skip intent unit frames that do not contain the required semantic dimension based on the existence bitmap of the dimension and the frame length, parse the dimension field block in the intent unit frame that contains the required semantic dimension, and deliver the parsing result together with the parsing summary and the modality tracing sub-block to downstream processing.

[0017] A computer device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the serialization transmission method of the above-described intent protocol instance.

[0018] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the serialization transmission method for the above-described intent protocol instance.

[0019] The serialization transmission method, apparatus, computer device, and storage medium for the aforementioned intent protocol instance allow the sending end to serialize the intent protocol instance into a transmission message containing a message header and intent unit frames. The message header carries a major version number, a minor version number, and a checksum. The intent unit frame carries a dimension existence bitmap, a frame length, and a sequence of dimension field blocks encoded using type-length-value and carrying modal sourcing sub-blocks, enabling the intent semantic structure to be carried at the message level. Interoperability between heterogeneous systems and intelligent agents no longer relies on private conventions. The receiving end first performs integrity verification based on the checksum; if the verification fails, the message is discarded, preventing transmission errors during multi-hop forwarding. General tampering is detected before parsing; when the major version number is unsupported, a negotiation response carrying the supported major version range is returned; when the minor version number is higher than the supported minor version number, dimension field blocks with unknown type codes are skipped and traced in the parsing digest, enabling the protocol to evolve and allowing new and old versions to coexist; intent unit frames that do not contain the required semantic dimensions are skipped based on the existence bitmap of the dimension and the frame length, allowing resource-constrained receivers to extract the required dimension content without fully parsing the message, and the parsing cost is proportional to the number of required dimensions; modal tracing sub-blocks are transmitted with the message, allowing the receiver to differentiate processing based on the credibility of the dimension information source. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the serialization transmission method for an instance of the intent protocol in one embodiment. Figure 2 This is a three-layer structure diagram of a transmitted message in one embodiment; Figure 3 This is a flowchart illustrating the media reference block verification process in one embodiment; Figure 4 This is a structural block diagram of a receiving end processing device for an intent protocol instance in one embodiment; Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0022] The serialization transmission method for the intent protocol instance provided in this application can be applied in the following application environments. The sending end communicates with the receiving end through a transmission channel. The sending end can be, but is not limited to, an orchestrator, a user terminal, and an intelligent agent gateway; the receiving end can be, but is not limited to, an executor, a tool gateway, and an embedded device; the transmission channel can be, but is not limited to, a Hypertext Transfer Protocol channel, a message queue, an inter-process communication channel, a Bluetooth channel, and a near-field communication channel; channel encryption can be superimposed during message transmission.

[0023] An intent protocol instance is structured data carrying task intent, containing one or more intent units. Each intent unit organizes the semantic content of the task intent according to semantic dimensions such as object, action, sequence, condition, constraint, space, and time. The content of each semantic dimension can come from raw inputs of different modalities such as speech, text, and map point selection. The problem addressed in this application is how to serialize such intent protocol instances into messages that can be transmitted between heterogeneous systems and intelligent agents, and to complete version negotiation, forward compatibility processing, and integrity verification during transmission.

[0024] In one embodiment, such as Figure 1 As shown, a serialization transmission method for an intent protocol instance is provided, which includes the following steps: Step 102: The sending end traverses each intent unit in the structured intent protocol instance, generates an intent unit frame for each intent unit, assembles the message header, and encapsulates the message header and all intent unit frames into a transmission message.

[0025] The three-layer structure of the transmission message is as follows Figure 2 As shown, the transmitted message adopts a three-layer structure: the first layer is the message header, the second layer is the intent unit frame, and the third layer is the dimension field block. The message header includes a message identification identifier, major version number, minor version number, instance identifier, message length, and checksum. The message identification identifier is a fixed value used for message identification and boundary synchronization; for example, it may be a fixed magic number of 4 bytes. The major version number increments during incompatible changes, and the minor version number increments during compatibility expansions. The instance identifier is a globally unique identifier for the protocol instance; for example, it may be 16 bytes. The message length is the total number of bytes in the message header and payload. The checksum is calculated based on the message header and all intent unit frames except for the checksum; for example, it may be a 32-byte hash value, covering the message header and all payload.

[0026] Each intent unit frame includes a unit identifier, a dimension existence bitmap, a frame length, and a sequence of dimension field blocks. The unit identifier is the identifier of the intent unit within the protocol instance, used for dependency references. The dimension existence bitmap identifies, bit by bit, whether the dimension field blocks of each semantic dimension (object, action, sequence, condition, constraint, spatial, and temporal) exist in this intent unit frame; for example, it uses 2 bytes, with each bit corresponding to one semantic dimension. The frame length is the total number of bytes in this intent unit frame, supporting frame-by-frame reading. The sequence of dimension field blocks is arranged from least significant bit to most significant bit according to the bit order of the dimension existence bitmap.

[0027] Each dimension field block in the dimension field block sequence uses type-length-value encoding. That is, each dimension field block includes a type field, a length field, and a value field in sequence. The type field carries the dimension type code, with the high-order bits reserved for extended types. The length field carries the number of bytes in the value area, and the value field carries the encoded value of the dimension's semantic content. Each dimension field block also carries a modal origination sub-block, which records the information source of that dimension field block. During serialization, the sending end calculates a dimension existence bitmap for each intent unit, encodes the content of each semantic dimension into dimension field blocks and writes them into the modal origination sub-block, then assembles the message header and calculates the checksum to complete the encapsulation of the transmitted message.

[0028] Step 104: The receiving end receives the transmission message and performs integrity verification on the transmission message according to the check value. If the integrity verification fails, the transmission message is discarded and an error response is returned.

[0029] After receiving a transmitted message, the receiving end first verifies the message identification identifier and message length. Then, it recalculates the checksum based on the message header (excluding the checksum) and the entire payload, and compares the results. Since the checksum covers the message header and the entire payload, any byte tampering during multi-hop forwarding will cause the checksum comparison to fail. During the process of the task intent being forwarded from the user end through the orchestrator to the execution unit, any modification to the message at any hop will be exposed during the integrity verification at the receiving end. When the checksum fails, the message is discarded and an error response is returned, without proceeding to subsequent semantic parsing. Transmission errors and general tampering are thus detected before parsing begins.

[0030] Step 106: When the integrity verification passes and the major version number is not within the range of major versions supported by the receiving end, the transmission message is rejected and a negotiation response is returned to the sending end.

[0031] The major version number is used to declare incompatible changes to the message format. The receiving end maintains its supported major version range. When the received major version number is outside the supported range, it indicates that the formats of both parties are incompatible, and further parsing is meaningless. The receiving end refuses to parse and returns a negotiation response, which carries the major version range supported by the receiving end and the suggested version. After receiving the negotiation response, the sending end can re-serialize and retransmit the message according to the major version range carried in the negotiation response, thus completing version negotiation at the message layer, no longer relying on offline agreements, and preventing silent failure due to version mismatch.

[0032] Step 108: When the integrity verification passes and the minor version number is higher than the minor version number supported by the receiver, skip the dimension field blocks with unknown type codes in the dimension field block sequence according to the length field, record the type code and length of the skipped dimension field blocks in the parsing digest, and parse the dimension field blocks with known type codes.

[0033] The minor version number is used to declare compatibility extensions in the message format. Higher version senders may write new dimension field blocks that the receiver does not yet recognize. The receiver reads the dimension field blocks one by one. If the type code is known, it is parsed normally; if the type code is unknown, the dimension field block is skipped according to the length field, and the skipped type code and number of bytes are recorded in the parsing digest. Parsing of known dimensions is unaffected. This skipping and logging method ensures that adding new dimensions will not cause the entire packet to be corrupted or discarded. The protocol can continue to evolve without interrupting the existing system, and the parsing digest also allows the receiver and downstream processing stages to know which content has been skipped.

[0034] Step 110: Based on the existence of the dimension bitmap and the frame length, skip the intent unit frames that do not contain the required semantic dimensions, parse the dimension field blocks in the intent unit frames that contain the required semantic dimensions, and deliver the parsing results, along with the parsing summary and modality tracing sub-block, to downstream processing.

[0035] After the receiving end reads the dimension bitmap of the intent unit frame, if the bit corresponding to the required semantic dimension is 0, then the intent unit frame does not contain the required content, and the receiving end jumps directly to the next intent unit frame by the frame length offset; if the corresponding bit is 1, then the required dimension field block is located within the frame in the order of type-length-value encoding. This mechanism allows resource-constrained receiving ends to extract the dimension content required for their duties without completely parsing the message. The parsing cost is proportional to the number of dimensions required, rather than proportional to the message size. The parsing result, along with the parsing digest and modality tracing sub-block, is delivered to downstream processing, such as the compilation or execution stage. The downstream stage can use this to determine the source of each dimension's content and any instances of skipping.

[0036] In the serialization transmission method of the aforementioned intent protocol example, the intent semantic structure is carried at the message level, and interoperability between heterogeneous systems and agents no longer relies on private agreements; integrity verification enables transmission errors and general tampering during multi-hop forwarding to be detected before parsing; major version negotiation and minor version skipping leave allow the protocol to evolve and new and old versions to coexist; on-demand skipping makes the parsing cost controllable for resource-constrained receivers; modal tracing sub-blocks are transmitted with the message, allowing the receiver to differentiate processing based on the credibility of the dimensional information source. Furthermore, the message identification identifier, version number, and dimension existence bitmap and type-length-value encoding structure are externally observable on the transmission channel, and evidence of the message layer can be obtained by packet capture.

[0037] It should be noted that the lengths of each field, the specific values ​​of the message identification identifiers, and the allocation methods of the dimension type codes in this step are all examples. From the perspective of existing technology, field lengths and identifier values ​​are conventional designs that those skilled in the art can choose according to implementation needs. The scope of protection of this application is not limited to the specific values ​​mentioned above. Any message organization method that carries a version declaration and a checksum covering the message header and payload in the message header, carries a dimension existence bitmap and frame length in the intent unit frame, or uses type-length-value encoding and carries a modal tracing sub-block in the dimension field block, all fall within the scope of protection of this application. The payload encoding can be binary type-length-value encoding, or it can be a text format implementation carrying equivalent structural semantics, i.e., text encoding that also carries version declarations, dimension existence declarations, typed fields, and tracing annotations. The transmission channel is not limited; the negotiation response can be inlined in the transmission channel or transmitted via a separate control channel.

[0038] It should also be noted that existing intent protocol compilation schemes perform version checks on protocol instances and ignore unknown extended fields during the compilation phase. This processing occurs at compile time, is executed unilaterally by the compiler, and has a processing granularity at the protocol instance level. The version negotiation in this application occurs during transmission, with the two communicating parties interacting to complete the negotiation response. The processing granularity is at the dimension field block level. The two differ in their occurrence phase, interaction objects, and processing granularity.

[0039] In one embodiment, each intent unit frame further includes a dependency count and a dependency table. The dependency table records the unit identifiers of other intent units that this intent unit depends on, and carries the directed dependency relationships between intent units in the intent protocol instance.

[0040] There may be prerequisite dependencies between the intent units in a task intent, such as locating before cleaning or retrieving before moving. A dependency count records the number of entries in the dependency table, where each entry is the unit identifier of a dependent intent unit. Dependency relationships are transmitted along with graph unit frames. The receiving end can reconstruct the directed dependencies between intent units at the message layer, allowing downstream processing stages to arrange the execution order without needing to transmit dependency information separately outside the message.

[0041] In one embodiment, the sender converts the media data in the intent protocol instance into a media reference block and writes it into the transport message. The media reference block includes the reference address of the media data, the content hash value, and the path of the bound dimension field. The receiver obtains the media data according to the reference address, compares the obtained media data with the content hash value, and refuses to use the media data when the comparison is inconsistent.

[0042] Including large media data such as voice and images in a message can lead to message bloat. For example... Figure 3 As shown, the sending end stores media data at an external access address, and the message only carries a media reference block. The reference address is the external access address of the media data, such as a Uniform Resource Identifier; the content hash value is the hash value of the media content; and the bound dimension field path records the semantic role of the media in the task intent and the location of the bound dimension field. After retrieving the media data from the reference address, the receiving end recalculates the hash value and compares it with the content hash value. If they do not match, the data is rejected and an alarm is triggered. This controls the message size, ensures the integrity of the media content, and prevents the binding relationship between the media and semantic fields from being lost during transmission.

[0043] In one embodiment, the sender receives a negotiation response, reserializes the intent protocol instance into a transport message based on the major version range carried in the negotiation response, and retransmits it to the receiver.

[0044] After receiving the negotiation response, the sending end selects a major version number supported by both parties from the major version range carried in the negotiation response, such as selecting the suggested version. Then, it reserializes and retransmits the intent protocol instance according to the message format corresponding to that major version number. Downgrading and retransmission enables interoperability between new and old systems. When collaborating across vendors' intelligent agents, devices supporting lower major versions will not be excluded from collaboration.

[0045] In one embodiment, the modal tracing sub-block includes a modal type code, an original input timestamp, and a semantic parsing confidence score; the receiving end adopts a differentiated processing strategy for the corresponding dimension field block based on the semantic parsing confidence score.

[0046] The modality sourcing sub-block employs nested type-length-value encoding. The modality type code identifies the modality of the original input, such as speech, text, or map point selection. The original input timestamp records the generation time of the original input. The semantic resolution confidence score records the confidence level when the original input is parsed into dimension content. The modality sourcing sub-block is transmitted along with the dimension field block, and the source confidence level of the field content is transmitted to the receiving end with the message. The receiving end can perform differentiated processing based on the semantic resolution confidence score; for example, dimension field blocks with high confidence scores can be used directly, while dimension field blocks with low confidence scores require confirmation before execution.

[0047] In one embodiment, the message header also includes flags that declare the compression, encryption, and fragmentation status of the transmitted message. For example, the flags are 2 bytes, with each bit declaring whether the message is compressed, encrypted, or fragmented. After receiving the transmitted message, if the flags indicate that the transmitted message is fragmented, the receiving end first reassembles the fragments. The checksum is verified based on the reassembled data before decryption and decompression, i.e., the bytes in the reassembled state are checked. After the integrity verification passes, the transmitted message is decrypted or decompressed according to the flags, and then the processed transmitted message is parsed. Thus, fragmentation reassembly precedes integrity verification, and decryption and decompression are performed after integrity verification, with the checksum field and processing order consistent. In an alternative implementation, a two-level mechanism of fragment-level verification and whole-packet authentication is adopted. Each fragment carries a fragment checksum for error detection before reassembly, and the whole-packet checksum is verified after fragmentation reassembly but before decryption and decompression.

[0048] In one embodiment, the verification value is calculated using a hash algorithm, a message authentication code with a key, or a digital signature; wherein the key of the message authentication code with a key is determined in advance by the sender and the receiver, and the signature private key of the digital signature belongs to the sender.

[0049] The checksum calculated by the hash algorithm is used to detect transmission errors and general tampering during transmission and forwarding. A man-in-the-middle can bypass hash verification by recalculating a regular hash after tampering with it. Therefore, in scenarios requiring protection against malicious forgery, the checksum is calculated using a message authentication code with a key or a digital signature. A third party without the key cannot forge a legitimate checksum, thus providing anti-counterfeiting capabilities. In cross-vendor scenarios, the message authentication code key can be determined by the sender and receiver through a key negotiation protocol during device network access or pairing, or distributed by a trusted key distribution service. When using a digital signature, the sender holds the signing private key, and the receiver obtains the sender's public key through a certificate.

[0050] In one embodiment, the message header also includes a sequence number and a validity period field, where the validity period field is a timestamp or a random number. The receiving end maintains a sequence number record of processed transmission messages. When the sequence number of a received transmission message already exists in the sequence number record, or the validity period field exceeds a preset valid range, the transmission message is determined to be a replay message, the transmission message is discarded, and an error response is returned. Therefore, the repeated delivery of legitimate old messages will not trigger repeated execution, and repeated delivery for physical execution scenarios is blocked.

[0051] In one embodiment, the dimension field block also carries a disposal attribute flag, which declares that the dimension field block is an optional field block or a safety-critical field block. For dimension field blocks with unknown type codes, when their disposal attribute flag is declared as optional, the receiver skips them by length and records it in the parsed digest; when their disposal attribute flag is declared as safety-critical, the receiver refuses to execute the intent content corresponding to the intent unit frame to which the dimension field block belongs, and performs at least one of the following processes: returns a negotiation response carrying the type code to the sender, or requests manual confirmation from the upstream. Thus, newly added fields carrying safety constraints will not be silently skipped by older versions of the receiver, and unknown safety-critical constraints are intercepted before execution.

[0052] In one embodiment, the end-to-end processing is illustrated using a robot vacuum cleaner as an example. The user expresses their task intent via voice and map selection, specifying that they want the robot vacuum cleaner to clean the living room at 8:00 AM tomorrow, avoiding the children's playpen area. The orchestrator constructs the task intent as an intent protocol instance. The intent unit within the instance includes semantic dimensions such as object, action, time, space, and constraints. The spatial dimension records the coordinates of the polygonal area in the living room and the playpen avoidance area. The modality tracing sub-block of the spatial dimension field block records the modality as map selection and a semantic resolution confidence score of 0.97.

[0053] The orchestrator serializes the intent protocol instance into a transmission message, which is then forwarded to the robot vacuum cleaner's actuator via the home gateway. The actuator firmware supports major version 2 and minor version 2. The received message has a minor version number of 3, which contains a newly added energy consumption preference dimension field block that the actuator does not recognize. The disposal attribute flag of this dimension field block is declared as an optional field block. The actuator skips this dimension field block by length field and leaves a trace in the parsing digest, while the other dimensions are parsed normally. At the same time, the actuator skips bitmaps and frame lengths by dimension, and only parses dimension field blocks related to execution, such as space and constraints.

[0054] If a message is tampered with during forwarding, such as by modifying the coordinates of a fenced area, the checksum comparison will fail during integrity verification. The executor will discard the message and return an error response. The tampered coordinates will not be included in physical execution. In cross-vendor scenarios, if another brand's robot only supports major version 1, it will return a negotiation response carrying the supported major version range after receiving the message. The orchestrator will then reserialize the intent protocol instance with major version 1 according to the negotiation response and send it, thus completing interoperability between the two parties.

[0055] It should be understood that although the steps in the flowchart above are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart above may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0056] In one embodiment, such as Figure 4 As shown, a receiver processing device for an intent protocol instance is provided, including: a message receiving module 401, an integrity verification module 402, a version negotiation module 403, and a skip-read parsing module 404, wherein: The message receiving module 401 is used to receive transmission messages. The transmission message is obtained by the sending end traversing each intent unit in the structured intent protocol instance, generating intent unit frames for each intent unit, assembling the message header, and encapsulating the message header with all intent unit frames.

[0057] The integrity verification module 402 is used to verify the integrity of the transmitted message based on the verification value. When the integrity verification fails, the transmitted message is discarded and an error response is returned.

[0058] Version negotiation module 403 is used to refuse to parse the transmission message and return a negotiation response carrying the range of major versions supported by the device when the major version number is not within the range of major versions supported by the device. When the minor version number is higher than the minor version number supported by the device, dimension field blocks with unknown type codes are skipped by the length field and the type code and length of the skipped dimension field blocks are recorded in the parsing digest. Dimension field blocks with known type codes are parsed.

[0059] The skip parsing module 404 is used to skip intent unit frames that do not contain the required semantic dimensions based on the existence bitmap of the dimension and the frame length, parse the dimension field blocks in intent unit frames that contain the required semantic dimensions, and deliver the parsing results, along with the parsing summary and modality tracing sub-block, to downstream processing.

[0060] The serialization behavior of the sending end is covered by the aforementioned method embodiments. This device embodiment is limited from the receiving end only. Only the single-sided implementer that implements the receiving end processing falls within the protection scope of this device.

[0061] In one embodiment, the intent unit frame further includes a dependency count and a dependency table. The dependency table records the unit identifiers of other intent units that this intent unit depends on, and carries the directed dependency relationships between intent units in the intent protocol instance.

[0062] In one embodiment, the device further includes a media verification module, which is used to obtain media data according to the reference address in the media reference block, compare the obtained media data with the content hash value, and refuse to use the media data when the comparison is inconsistent.

[0063] In one embodiment, the modal tracing sub-block includes a modal type code, an original input timestamp, and a semantic parsing confidence score; the skip parsing module is also used to apply differentiated processing strategies to the corresponding dimension field blocks based on the semantic parsing confidence score.

[0064] In one embodiment, the message header further includes a flag bit that declares the compression state, encryption state, and fragmentation state of the transmitted message; the device further includes a preprocessing module, which is used to first reassemble each fragment when the flag bit declares the transmitted message as a fragmented message, decrypt or decompress the transmitted message according to the flag bit after the integrity verification is passed, and then parse the processed transmitted message.

[0065] In one embodiment, the verification value is calculated using a hash algorithm, a message authentication code with a key, or a digital signature; wherein the key of the message authentication code with a key is determined in advance by the sender and the receiver, and the signature private key of the digital signature belongs to the sender.

[0066] Specific limitations regarding the receiving end processing device for the intent protocol instance can be found in the limitations on the serialization transmission method for the intent protocol instance above, and will not be repeated here. Each module in the above device can be implemented entirely or partially through software, hardware, or a combination of software and hardware. These modules can be embedded in hardware or independently of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the operations corresponding to each module.

[0067] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and the database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores intent protocol instances and transmission message data. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a serialization transmission method for intent protocol instances.

[0068] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0069] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps: The sending end traverses each intent unit in the structured intent protocol instance, generates an intent unit frame for each intent unit, assembles a message header, and encapsulates the message header and all intent unit frames into a transmission message. The message header includes a message identification identifier, major version number, minor version number, instance identifier, message length, and checksum. The checksum is calculated based on the message header and all intent unit frames except for the checksum. Each intent unit frame includes a unit identifier, a dimension existence bitmap, frame length, and a sequence of dimension field blocks. The dimension existence bitmap identifies by bit whether the dimension field blocks of each semantic dimension in the object, action, sequence, condition, constraint, spatial, and temporal semantic dimensions exist in this intent unit frame. The sequence of dimension field blocks is arranged according to the bit order of the dimension existence bitmap. Each dimension field block in the sequence of dimension field blocks uses type-length-value encoding and carries a modal tracing sub-block that records the source of dimension information. The receiving end receives the transmission message, performs integrity verification on the transmission message according to the check value, and discards the transmission message and returns an error response when the integrity verification fails. When the integrity verification passes but the major version number is not within the range of major versions supported by the receiver, the transmission message is refused to be parsed, and a negotiation response is returned to the sender; the negotiation response carries the range of major versions supported by the receiver. When the integrity verification passes and the minor version number is higher than the minor version number supported by the receiving end, the dimension field blocks with unknown type codes in the dimension field block sequence are skipped according to the length field. The type code and length of the skipped dimension field blocks are recorded in the parsing digest. The dimension field blocks with known type codes are parsed. Based on the existence of the dimension bitmap and frame length, skip intent unit frames that do not contain the required semantic dimension, parse the dimension field block in the intent unit frame that contains the required semantic dimension, and deliver the parsing result along with the parsing summary and modality tracing sub-block to downstream processing.

[0070] In one embodiment, the processor, when executing a computer program, also performs the following steps: Each intent unit frame also includes a dependency count and a dependency table. The dependency table records the unit identifiers of other intent units that this intent unit depends on, and carries the directed dependency relationships between intent units in the intent protocol instance.

[0071] The sending end converts the media data in the intent protocol instance into a media reference block and writes it into the transport message. The media reference block includes the reference address of the media data, the content hash value, and the path of the bound dimension field. The receiving end obtains the media data according to the reference address, compares the obtained media data with the content hash value, and refuses to use the media data when the comparison is inconsistent.

[0072] The sending end receives the negotiation response, re-serializes the intent protocol instance into a transport message based on the major version range carried in the negotiation response, and retransmits it to the receiving end.

[0073] The modality tracing sub-block includes the modality type code, the original input timestamp, and the semantic parsing confidence score; the receiving end adopts a differentiated processing strategy for the corresponding dimension field block based on the semantic parsing confidence score.

[0074] The message header also includes flags that declare the compression, encryption, and fragmentation status of the transmitted message. After receiving the transmitted message, when the flags indicate that the transmitted message is a fragmented message, the receiving end first reassembles the fragments. The checksum is verified based on the message data after fragment reassembly and before decryption and decompression. After the integrity verification is passed, the transmitted message is decrypted or decompressed according to the flags, and then the processed transmitted message is parsed.

[0075] The verification value is calculated using a hash algorithm, a message authentication code with a key, or a digital signature. The key for the message authentication code with a key is determined in advance by the sender and receiver, and the private key for the digital signature belongs to the sender.

[0076] The message header also includes a sequence number and a timeout field, where the timeout field is a timestamp or a random number. The receiving end maintains a sequence number record of processed transmission messages. When the sequence number of the received transmission message already exists in the sequence number record, or the timeout field exceeds the preset valid range, the transmission message is determined to be a replay message, the transmission message is discarded, and an error response is returned.

[0077] The dimension field block also carries a disposal attribute flag, which declares that the dimension field block is an optional field block or a safety-critical field block. For dimension field blocks with unknown type codes, when the disposal attribute flag is declared as an optional field block, the length field is skipped and recorded in the parsing digest. When the disposal attribute flag is declared as a safety-critical field block, the intent content corresponding to the intent unit frame to which the dimension field block belongs is refused to be executed, and at least one of the following processes is performed: returning a negotiation response carrying the type code to the sender, or requesting manual confirmation from the upstream.

[0078] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the serialization transmission method of the intent protocol instance described above.

[0079] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory may include read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable programmable read-only memory, or flash memory. Volatile memory may include random access memory or external cache memory.

[0080] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0081] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for serializing and transmitting an instance of an intent protocol, characterized in that, The method includes: The sending end traverses each intent unit in the structured intent protocol instance, generates an intent unit frame for each intent unit, assembles a message header, and encapsulates the message header and all intent unit frames into a transmission message. The message header includes a message identification identifier, major version number, minor version number, instance identifier, message length, and checksum. The checksum is calculated based on the message header (excluding the checksum) and all intent unit frames. Each intent unit frame includes a unit identifier, a dimension existence bitmap, frame length, and a sequence of dimension field blocks. The dimension existence bitmap identifies the presence of dimension field blocks for each semantic dimension (object, action, sequence, condition, constraint, spatial, and temporal) in this intent unit frame. The sequence of dimension field blocks is arranged according to the bit order of the dimension existence bitmap. Each dimension field block in the sequence uses type-length-value encoding and carries a modal tracing sub-block recording the source of dimension information. The receiving end receives the transmission message, performs integrity verification on the transmission message according to the check value, and discards the transmission message and returns an error response when the integrity verification fails. When the integrity verification passes and the major version number is not within the range of major versions supported by the receiving end, the transmission message is refused to be parsed, and a negotiation response is returned to the sending end; the negotiation response carries the range of major versions supported by the receiving end. When the integrity verification passes and the minor version number is higher than the minor version number supported by the receiving end, the dimension field blocks with unknown type codes in the dimension field block sequence are skipped according to the length field. The type code and length of the skipped dimension field blocks are recorded in the parsing digest. The dimension field blocks with known type codes are parsed. Based on the existence bitmap of the dimension and the frame length, skip intent unit frames that do not contain the required semantic dimension, parse the dimension field block in the intent unit frame that contains the required semantic dimension, and deliver the parsing result, together with the parsing summary and the modality tracing sub-block, to downstream processing.

2. The method according to claim 1, characterized in that, The generation of intent unit frames per intent unit includes: Generate a dependency count and a dependency table, and write the dependency count and the dependency table into this intent unit frame; The dependency table records the unit identifiers of other intent units that this intent unit depends on, and the dependency table carries the directed dependency relationships between intent units in the intent protocol instance.

3. The method according to claim 1, characterized in that, The method further includes: The media data in the intent protocol instance is converted into a media reference block and written into the transport message; The media reference block includes the reference address of the media data, the content hash value, and the path of the bound dimension field; The media data is obtained according to the reference address, and the obtained media data is compared with the content hash value. If the comparison is inconsistent, the media data is rejected.

4. The method according to claim 1, characterized in that, The modal tracing sub-block carrying the source of the recorded dimension information includes: Write the modality type code, the original input timestamp, and the semantic parsing confidence into the modality tracing sub-block; Based on the semantic parsing confidence level, a differentiated processing strategy is adopted for the corresponding dimension field blocks.

5. The method according to claim 1, characterized in that, The assembly of the message header includes: writing a flag bit into the message header; The flag bits declare the compression state, encryption state, and fragmentation state of the transmitted message; After receiving the transmission message, the receiving end further includes: when the flag bit declares that the transmission message is a fragmented message, reassembling each fragment first; The verification value is verified based on the message data after fragmentation and reconstruction, and before decryption and decompression; After the integrity verification is passed, the transmitted message is decrypted or decompressed according to the flag bit, and then the processed transmitted message is parsed.

6. The method according to claim 1, characterized in that, The checksum is calculated based on the message header excluding the checksum and all the intent unit frames, including: The check value is obtained by using a hash algorithm to calculate the check value by combining the message header (excluding the check value) with all the intent unit frames. Alternatively, a keyed message authentication code can be used to calculate the verification value by examining the message header (excluding the verification value) and all intent unit frames; wherein the key of the keyed message authentication code is pre-determined by the sending end and the receiving end. Alternatively, a digital signature can be used to calculate the verification value by combining the message header (excluding the verification value) with all the intent unit frames; wherein the signature private key of the digital signature belongs to the sending end. The message header also includes a sequence number and a timeliness field; wherein the timeliness field is a timestamp or a random number; The receiving end maintains a sequence number record of processed transmission messages. When the sequence number of the received transmission message already exists in the sequence number record, or when the timeliness field exceeds the preset valid range, the receiving end determines that the transmission message is a replay message, discards the transmission message, and returns an error response.

7. The method according to claim 1, characterized in that, The dimension field block also carries a disposal attribute flag; The disposal attribute flag declares that the dimension field block is an optional field block or a safety-critical field block; For dimension field blocks with unknown type codes, when their disposal attribute flag is declared as an optional field block, they are skipped by length field and recorded in the parsing summary. When its disposal attribute flag is declared as a security critical field block, the intent content corresponding to the intent unit frame to which the dimension field block belongs is refused to be executed, and at least one of the following processes is performed: returning a negotiation response carrying the type code to the sending end, or requesting manual confirmation from the upstream.

8. A receiving end processing apparatus for an intent protocol instance, characterized in that, The device includes: A message receiving module is used to receive transmission messages. The transmission messages are generated by the sending end through each intent unit in the structured intent protocol instance, generating intent unit frames for each intent unit, assembling a message header, and encapsulating the message header with all the intent unit frames. The message header includes a message identification identifier, a major version number, a minor version number, an instance identifier, a message length, and a checksum. The checksum is calculated based on the message header and all the intent unit frames except for the checksum. Each intent unit frame includes a unit identifier, a dimension existence bitmap, a frame length, and a sequence of dimension field blocks. The dimension existence bitmap identifies the existence of dimension field blocks for each semantic dimension in the object, action, sequence, condition, constraint, spatial, and temporal semantic dimensions in this intent unit frame. The sequence of dimension field blocks is arranged according to the bit order of the dimension existence bitmap. Each dimension field block in the sequence of dimension field blocks uses type-length-value encoding and carries a modal tracing sub-block that records the source of dimension information. The integrity verification module is used to perform integrity verification on the transmitted message based on the verification value. When the integrity verification fails, the transmitted message is discarded and an error response is returned. The version negotiation module is used to refuse to parse the transmission message and return a negotiation response to the sending end when the integrity verification passes and the major version number is not within the range of major versions supported by the device. The negotiation response carries the range of major versions supported by the device. When the integrity verification passes and the minor version number is higher than the minor version number supported by the device, the module skips dimension field blocks with unknown type codes in the dimension field block sequence according to the length field, records the type code and length of the skipped dimension field blocks in the parsing digest, and parses dimension field blocks with known type codes. The skip-read parsing module is used to skip intent unit frames that do not contain the required semantic dimension based on the existence bitmap of the dimension and the frame length, parse the dimension field block in the intent unit frame that contains the required semantic dimension, and deliver the parsing result together with the parsing summary and the modality tracing sub-block to downstream processing.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images