Virtual agent interaction method and apparatus based on physical entity carrier, device, and medium
By acquiring and parsing the interaction event data of physical hardware devices, generating unique event identifiers and performing layered verification, the security and stability issues of virtual pets and AI intelligent agents in near-field pairing interactions are resolved, achieving low-power and consistent virtual intelligent agent state updates.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING QIBU QIBU TECH CO LTD
- Filing Date
- 2026-06-05
- Publication Date
- 2026-08-04
AI Technical Summary
Existing virtual pet and AI intelligent agent products suffer from low security, easy accidental touches and misjudgments, high hardware power consumption, large communication load, and insufficient cross-terminal collaboration capabilities during near-field pairing and interaction.
By acquiring interaction event data from physical hardware devices, parsing and encoding unique event identifiers, performing layered verification and legality validation, using the world engine and intelligent agent services to update the state of virtual intelligent agents, and combining NFC touch and inertial interaction events, interaction security and prevention of misjudgment are improved.
It achieves security and stability of virtual intelligent agent interaction based on physical carriers, reduces hardware power consumption, and ensures consistency between virtual scenes and intelligent agent states.
Smart Images

Figure CN122333437B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of virtual-real fusion interaction technology, and in particular to a virtual intelligent agent interaction method, device, equipment and medium based on a physical carrier. Background Technology
[0002] Most virtual pets and AI intelligent agents currently on the market rely solely on touchscreen, text input, or voice commands on mobile devices for human-computer interaction, generally lacking an immersive companionship experience that integrates with real-world physical carriers. While some products attempt to expand interaction methods by combining external devices and wearable hardware, the overall solutions still suffer from several technical shortcomings and user experience deficiencies. In terms of near-field pairing interaction, these products mostly rely on static device identifiers and simple pairing codes for connection, lacking a secure and reliable two-way authentication mechanism. This not only makes them prone to issues such as accidental binding and unauthorized friend additions due to close-range touches, but also poses security risks such as unauthorized misuse by secondary devices and command replay attacks. Regarding motion sensing and recognition, the accuracy of devices in recognizing body movements such as shaking and displacement is easily affected by differences in user operating habits and external environmental vibrations. Even slight vibrations in everyday scenarios can trigger misrecognition, significantly reducing interaction stability and user experience. Furthermore, the devices generally employ a high-frequency continuous sampling and frequent data reporting operating mode, resulting in excessive hardware power consumption and excessive communication network load, which is detrimental to the long-term use of the devices. In addition, the product lacks cross-platform collaboration capabilities. The operating status of the AI agent needs to be updated synchronously across multiple channels, including hardware devices, user local terminals, cloud servers, and second user terminals. During the multi-source data update process, problems such as offline data loss, duplicate information reporting, disordered command timing, and multi-terminal concurrency conflicts are prone to occur, ultimately resulting in inconsistencies between the virtual scene and the agent's status display on different terminals. Summary of the Invention
[0003] The main objective of this invention is to provide a virtual intelligent agent interaction method, device, equipment, and storage medium based on a physical carrier, aiming to solve the technical problems of low security and easy mis-touch and misjudgment in the virtual intelligent agent interaction when performing virtual-real fusion interaction.
[0004] To achieve the above objectives, the present invention provides a virtual intelligent agent interaction method based on a physical carrier, comprising: Acquire interaction event data of physical hardware devices engaging in interactive behaviors; The interaction event data is parsed, interaction event features are extracted, and the interaction event features are encoded to generate a unique event identifier; Interactive behaviors are validated in layers based on unique event identifiers and event types. When the interactive behavior validation passes, the unique event identifier and event proof are uploaded to the server via the user terminal. When the server receives the unique event identifier and event proof, it verifies the legitimacy of the event proof. If the legitimacy verification passes, the server sends the unique event identifier to the world engine and / or the intelligent agent service, and queries the corresponding target virtual intelligent agent based on the unique event identifier and the preset binding mapping relationship. The target virtual agent is updated interactively by the World Engine and / or the agent service based on the event type corresponding to the unique event identifier.
[0005] Furthermore, to achieve the above objectives, the present invention provides a virtual intelligent agent interaction device based on a physical carrier, comprising: The event acquisition module is used to acquire interaction event data of physical hardware devices engaging in interactive behavior. The feature extraction and encoding module is used to parse the interaction event data, extract interaction event features, encode the interaction event features, and generate a unique event identifier; The validity verification module is used to perform hierarchical verification of interactive behaviors based on unique event identifiers and event types. When the interactive behavior passes the verification, the unique event identifier and event proof are uploaded to the server through the user terminal. The target virtual agent module is used to verify the legitimacy of the event proof after the server receives the unique event identifier and event proof. If the legitimacy verification is successful, the unique event identifier is sent to the world engine and / or the agent service, and the corresponding target virtual agent is queried according to the unique event identifier and the preset binding mapping relationship. The state update module is used to update the interactive state of the target virtual agent by the world engine and / or agent service according to the event type corresponding to the unique event identifier.
[0006] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a virtual intelligent agent interaction program based on a physical carrier stored in the memory and executable on the processor, wherein when the virtual intelligent agent interaction program based on the physical carrier is executed by the processor, it implements the steps of the virtual intelligent agent interaction method based on a physical carrier as described above.
[0007] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a virtual intelligent agent interaction program based on a physical carrier, wherein when the virtual intelligent agent interaction program based on the physical carrier is executed by a processor, it implements the steps of the virtual intelligent agent interaction method based on the physical carrier as described above.
[0008] Beneficial Effects: This invention relates to the field of virtual-real fusion interaction technology, and discloses a method, device, equipment, and medium for virtual intelligent agent interaction based on a physical carrier. The method includes: acquiring interaction event data of interactive behaviors occurring on physical hardware devices; parsing the interaction event data, extracting interaction event features, encoding the interaction event features, and generating a unique event identifier; performing layered verification of the interaction behavior based on the unique event identifier and event type; when the interaction behavior verification passes, uploading the unique event identifier and event proof to a server via a user terminal; when the server receives the unique event identifier and event proof, verifying the legality of the event proof; if the legality verification passes, sending the unique event identifier to a world engine and / or intelligent agent service, and querying the corresponding target virtual intelligent agent based on the unique event identifier and a preset binding mapping relationship; and updating the interaction state of the target virtual intelligent agent by the world engine and / or intelligent agent service according to the event type corresponding to the unique event identifier. This invention acquires NFC touch and inertial interaction events through physical hardware, generates unique event identifiers, and drives the virtual intelligent agent to update its state, thereby improving interaction security and preventing interaction misjudgments. Attached Figure Description
[0009] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a virtual intelligent agent interaction method based on a physical carrier according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the virtual intelligent agent interaction method based on a physical carrier according to the present invention. Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the virtual intelligent agent interaction device based on a physical carrier of the present invention. Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation
[0010] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.
[0011] The virtual intelligent agent interaction method based on a physical carrier provided in this invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can obtain interaction event data of physical hardware devices interacting with each other through the client; it parses the interaction event data, extracts interaction event features, encodes the interaction event features, and generates a unique event identifier; it performs layered verification of the interaction behavior based on the unique event identifier and event type; when the interaction behavior verification passes, the unique event identifier and event proof are uploaded to the server through the user terminal; when the server receives the unique event identifier and event proof, it verifies the legality of the event proof; if the legality verification passes, it sends the unique event identifier to the World Engine and / or Intelligent Agent Service, and queries the corresponding target virtual intelligent agent based on the unique event identifier and a preset binding mapping relationship; the World Engine and / or Intelligent Agent Service updates the interaction state of the target virtual intelligent agent according to the event type corresponding to the unique event identifier. This invention obtains NFC touch and inertial interaction events through physical hardware, generates unique event identifiers, and drives the virtual intelligent agent to update its state, improving interaction security and preventing interaction misjudgment. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.
[0012] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the virtual intelligent agent interaction method based on a physical carrier provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.
[0013] like Figure 2 As shown, the virtual intelligent agent interaction method based on a physical carrier proposed in this invention includes the following steps: S100: Obtain interaction event data of physical hardware devices engaging in interactive behavior; S200. The interaction event data is parsed, interaction event features are extracted, the interaction event features are encoded, and a unique event identifier is generated. S300. Perform layered verification of interactive behavior based on unique event identifier and event type. When the interactive behavior verification passes, upload the unique event identifier and event proof to the server through the user terminal. S400. When the server receives the unique event identifier and event proof, it verifies the legality of the event proof. If the legality verification passes, the server sends the unique event identifier to the world engine and / or the intelligent agent service, and queries the corresponding target virtual intelligent agent according to the unique event identifier and the preset binding mapping relationship. S500, the World Engine and / or the Agent Service update the interactive state of the target virtual agent based on the event type corresponding to the unique event identifier.
[0014] In this embodiment, acquiring interaction event data of interactive behaviors occurring in physical hardware devices is the initial step of the entire process. The physical hardware devices have a built-in NFC (Near Field Communication Module) and inertial sensor module, enabling them to sense two types of user interaction behaviors. One type is touch-related events, which are touch session data generated when two physical hardware devices physically touch each other via NFC. This includes a session identifier (session_id), touch start time (t0), touch end time (t1), random numbers for both parties (Nonce_A and Nonce_B, i.e., "Number Used Once"), and authentication result information. The other type is motion-related events, which are motion feature data collected by the inertial sensor when a user operates a single physical hardware device through shaking, displacement, or a specific acceleration pattern. This includes raw sensor waveforms such as acceleration, angular velocity, displacement trajectory, and attitude changes. The low-power control module manages the sensor's sampling strategy, operating at a low frequency or in sleep mode when stationary, and only increasing the sampling frequency when motion interruption is detected or NFC field strength changes, thereby reducing overall power consumption.
[0015] Parsing and extracting interactive event features from the data is fundamental to subsequent processing. For touch events, the system extracts key fields such as session_id, nonce, and touch time window from the touch session data. For action events, the system performs preprocessing operations such as sliding window segmentation, noise reduction, and normalization on the raw sensor waveform, and then extracts multi-dimensional feature parameters, including root mean square value, peak value, dominant frequency, frequency band energy distribution, zero-crossing rate, and attitude change. After extraction, the system encodes the interactive event features to generate a unique event identifier (event_id). The encoding process typically uses a cryptographic hash function, concatenating fields such as event type, timestamp (ts), nonce, monotonic counter (used to prevent event replay and out-of-order execution), binding index (binding_id), and feature digest, and then performing a hash operation to ensure that each event identifier is globally unique and tamper-proof.
[0016] Layered verification of interactive behaviors based on unique event identifiers is a crucial step in ensuring event authenticity and preventing false triggers. For touch events, layered verification includes two-way challenge-response authentication, where the first hardware device sends a challenge value (Challenge_A), and the second hardware device generates a response value (Response_B) based on the key material in the secure storage module and returns it, and vice versa. If either party fails authentication, the session is terminated. Simultaneously, it verifies whether the touch session completes two-way authentication within a preset time window (ΔT), whether the touch duration is within a reasonable threshold range, and whether the round-trip time (RTT) is less than a threshold (to suppress relay spoofing). For action events, validity verification includes multi-window consistency verification, requiring consistent classification results across N consecutive sliding windows for confirmation of validity; and false positive filtering, including static suppression (excluding environmental vibrations), short-term vibration suppression (excluding instantaneous collisions), and trigger cooldown time (to prevent the same action from being repeatedly identified). When the interaction passes verification, the physical hardware device generates an event proof, which is either a Message Authentication Code (MAC, generated based on a symmetric key) or a digital signature (generated based on an asymmetric key), used to prove to the server the legitimate source and integrity of the event. Subsequently, the device uploads the unique event identifier (event_id) and the event proof to the server via a local connection (such as Bluetooth) through the event relay and caching module of the user terminal; in some implementations, the physical hardware device can also directly send an event token to the server via a cellular network or Wi-Fi.
[0017] Upon receiving the unique event identifier and event proof, the server first verifies the validity of the event proof through the event verification service. Validity verification includes: verifying the cryptographic correctness of the proof (i.e., verifying whether the MAC value or signature matches); verifying the validity of the timestamp (ts) (confirming the event has not expired); verifying whether the nonce has been used (preventing replay attacks); verifying the monotonically increasing nature of the counter (preventing event rollback or out-of-order submission); and verifying the event's time-to-live (TTL). If the validity verification passes, the server sends the unique event identifier to the virtual world engine and / or the agent service. The virtual world engine is responsible for maintaining the overall state of the virtual world, scene rendering rules, and physical interaction logic; the agent service is responsible for managing the individual states, behavioral decisions, and growth models of each virtual agent. Simultaneously, the server queries the pre-defined binding mapping relationship based on the binding index (binding_id) contained in the unique event identifier. The binding mapping relationship is maintained by the binding mapping service, recording a one-to-one correspondence between each entity hardware device and the target virtual agent identifier (Agent ID, agent_id). This relationship is established when a user is first paired: the user terminal requests a binding authorization token from the server, the entity hardware device saves the binding index binding_id, and the server stores the mapping relationship between the entity hardware device and the target virtual agent identifier. By querying the binding mapping relationship, the server determines the target virtual agent corresponding to this interaction event.
[0018] The virtual world engine and / or intelligent agent service update the interactive state of the target virtual intelligent agent based on the event type (EventType) corresponding to the unique event identifier. The event type determines the specific content and effect of the state update: if the event type is NFC Touch Add Friend, a friend relationship is established between the two target virtual intelligent agents, and the friend list status is updated; if the event type is Shake Triggered Adventure, adventure parameters, including adventure distance, difficulty level, reward probability, and emotion gain, are mapped according to motion feature data and intensity parameters to trigger the adventure task and update the adventure progress; if the event type is displacement or acceleration mode, emotion value, growth value, unlocking dwelling items, updating dwelling layout, or updating item inventory may be updated. After the state update is completed, the server writes the update event to the event tracing log, assigns a monotonically increasing sequence number and / or logical clock to the target intelligent agent, and generates a synchronization message carrying the state increment delta. The synchronization message is distributed to the user terminal and / or friend terminal through the synchronization distribution service to update the virtual world display and ensure the consistency and real-time performance of the state across multiple terminals. Meanwhile, the server performs idempotent deduplication based on the unique event identifier event_id to prevent duplicate events from causing abnormal state updates, thus ensuring the reliability of the system and the correctness of the data.
[0019] In one embodiment, prior to S100, the following is included: Obtain the first virtual intelligent agent identifier and the first physical hardware device ID corresponding to the first user terminal; The first user terminal sends a first binding authorization token instruction to the server, and the server performs identity verification and permission verification based on the first binding authorization token instruction; After the identity verification and permission verification of the first user terminal are passed, the server generates a first binding index and writes the first binding index into the secure storage module of the first physical hardware device. The server establishes a first binding mapping relationship based on the first entity hardware device ID, the first binding index, and the first virtual intelligent agent identifier; Obtain the second virtual intelligent agent identifier and the second physical hardware device ID corresponding to the second user terminal; The second user terminal sends a second binding authorization token instruction to the server, and the server performs identity verification and permission verification based on the second binding authorization token instruction. After the identity verification and permission verification of the second user terminal are passed, the server generates a second binding index and writes the second binding index into the secure storage module of the second physical hardware device; The server establishes a second binding mapping relationship based on the second entity hardware device ID, the second binding index, and the second virtual agent identifier.
[0020] In this embodiment, firstly, the first virtual agent identifier and the first physical hardware device ID corresponding to the first user terminal are obtained. The first virtual agent identifier (agent_id) is a unique identity assigned by the server to the agent created by each user in the virtual world, used to distinguish the virtual roles of different users; the first physical hardware device ID (device_id) is a unique hardware identifier fixed at the factory of the physical hardware device, usually stored in the device's secure storage module, and has the characteristic of being tamper-proof. The purpose of this step is to clarify the two parties to be bound together, that is, which virtual agent will be associated with which physical hardware device.
[0021] Next, the first user terminal sends a first binding authorization token instruction to the server. This "binding authorization token instruction" refers to the binding request sent by the user to the server through a mobile app or other terminal application. The request includes the user's identity credentials (such as a login token) and the ID of the physical hardware device to be bound. Upon receiving this instruction, the server performs identity verification and permission verification based on the first binding authorization token instruction. Identity verification verifies whether the user is a legitimate registered user, typically done by checking the validity of the login token and the normality of the user's account status. Permission verification checks whether the user has the permission to bind the hardware device, such as whether the maximum number of devices that can be bound has been reached, and whether the account has any abnormal risks. This dual verification mechanism ensures that only legitimate users with the corresponding permissions can perform the binding operation, preventing unauthorized access.
[0022] After the identity and authorization verification of the first user terminal passes, the server generates a first binding index and writes it to the secure storage module of the first physical hardware device. The binding index (binding_id) is a unique identifier generated by the server for this binding relationship; it is a logical-level mapping identifier, distinct from the physical uniqueness of the hardware device ID. After generating the binding_id, the server needs to securely write it to the secure storage module of the physical hardware device. This module is a storage area within the hardware device with encryption protection and tamper-proof capabilities, typically implemented using a secure chip or Trusted Execution Environment (TEE) technology to ensure the secure storage of the binding_id on the device side, preventing malicious reading or tampering. The writing process is usually completed through local secure channels such as Bluetooth, NFC, or USB to ensure confidentiality and integrity during transmission.
[0023] Subsequently, the server establishes a first binding mapping relationship based on the first entity hardware device ID, the first binding index, and the first virtual agent identifier. On the server side, the Binding Mapping Service creates and maintains a mapping record that associates device_id, binding_id, and agent_id. This means that when a subsequent entity hardware device reports an event via binding_id, the server can accurately map it to the corresponding virtual agent identifier agent_id, thereby determining which virtual agent's state update should be triggered by the event. This mapping relationship is the foundation for routing all subsequent interaction events. For example, when a hardware device shakes, the server uses binding_id to find agent_id and then updates the agent's exploration progress or emotion value.
[0024] On the second user terminal side, a fully symmetrical binding process is executed. The second virtual agent identifier and the second entity hardware device ID corresponding to the second user terminal are obtained. This step is logically consistent with the first user terminal side, except the object is the second user. The second user terminal sends a second binding authorization token instruction to the server. The server performs identity verification and permission verification based on the second binding authorization token instruction. The verification logic here is the same as that of the first user terminal, ensuring the legitimacy and validity of the second user's permissions. After the second user terminal's identity verification and permission verification pass, the server generates a second binding index and writes the second binding index into the secure storage module of the second entity hardware device. The generation and writing mechanism is completely consistent with the first binding index, but the value of binding_id is an independently generated unique identifier. Finally, the server establishes a second binding mapping relationship based on the second entity hardware device ID, the second binding index, and the second virtual agent identifier, forming a second independent mapping record on the server side.
[0025] Through the complete two-way binding process described above, the virtual agents of the two users establish a secure and unique mapping relationship with their corresponding physical hardware devices. This mapping relationship is a necessary prerequisite for the subsequent NFC touch-to-add-friend scenario—when the two physical hardware devices touch via NFC, the binding_id reported by each device can be mapped by the server to the corresponding agent_id, thereby establishing a friend relationship between the first and second agents. Simultaneously, the secure storage of the binding index ensures that the hardware device can still generate a valid event identifier (event_id) and event proof (proof) using the binding_id even when offline, ensuring the authenticity and traceability of the event.
[0026] In one embodiment, S100 includes: S1011. When the first physical hardware device and the second physical hardware device come into close contact, a touch session request is generated. S1012. Parse the touch session request to obtain the session identifier, the first random number, the second random number, and the touch start and end time; S1013. The session identifier, random numbers from both parties, and touch start and end times are fused to generate touch session data; S1014. Perform two-way challenge-response authentication based on the touch session data, and generate authentication result information; S1015, The touch session data and authentication information constitute the interaction event data.
[0027] In this embodiment, when a user holds a first physical hardware device (such as smart doll A) and comes into close contact with another user's second physical hardware device (such as smart doll B), the NFC modules built into the two devices establish a wireless communication link through electromagnetic induction. At this time, the system generates a touch session request. This request is the starting point for triggering the entire friend-adding process, marking the digital capture of the encounter event between the two physical carriers in the physical world.
[0028] The system performs structured parsing on the generated touch session request, extracting four core elements: session identifier (session_id, a unique number for this touch session, used for global tracking of this interaction), first random number (nonce_A, a single-use random value generated by device A to prevent replay attacks), second random number (nonce_B, a corresponding random value generated by device B), and touch start / end time (t0 / t1, timestamps recording the establishment and disconnection of the NFC field, used to determine whether the touch duration is within a reasonable threshold range). These fields together constitute the foundational data for subsequent security authentication and event tracing.
[0029] The system merges the parsed session identifier, random numbers from both parties, and touch start and end times to generate standardized touch session data (TouchSessionData). This fusion process includes not only simple field concatenation but also verification of the validity of the time window (e.g., determining whether t1-t0 is within a preset reasonable touch duration to exclude brief accidental touches). It can optionally record session round-trip time (RTT, the round-trip time from sending to receiving a data packet, used to suppress relay spoofing attacks) and field strength (reflecting the physical proximity of the two devices). The resulting touch session data is a structured data packet containing multi-dimensional information, fully describing the spatiotemporal characteristics of this physical touch event.
[0030] Based on the touch session data, the system performs two-way challenge-response authentication, a secure mechanism for mutual identity verification. Specifically, the first entity hardware device A sends a challenge value `challenge_A` to the second entity hardware device B. Device B uses pre-stored key materials in its secure storage module to generate a response value `response_B` using a Message Authentication Code (MAC) or digital signature algorithm and returns it. Simultaneously, device B sends the challenge value `challenge_B` to device A, and device A similarly generates a response value `response_A` based on its security key and returns it. Only when both parties correctly complete the challenge-response process, i.e., both-way authentications pass, will a valid authentication result (`auth_result`) be generated. If either party fails authentication, the session is immediately terminated, and no submitable event token is generated, effectively preventing unauthorized device impersonation and accidental pairing.
[0031] Finally, the system integrates the touch session data (including fields such as session_id, nonce_A, nonce_B, t0 / t1, etc.) with the authentication result information (auth_result) to form interaction event data. This data serves as the raw input and will subsequently enter the feature extraction and event identifier generation stage: the system performs hash operations on the session identifier, random numbers from both parties, touch start and end times, and event type to generate a unique event identifier (event_id), and attaches a message authentication code or digital signature as event proof, ultimately forming an event token that can be verified by the server. This token is mapped to the target agent identifier (agent_id) through a binding index (binding_id), thereby transforming the "touch" action in the physical world into a status update instruction for adding a new friend relationship between agents in the virtual world, and distributing it to the user terminals of both parties and the friend's terminal through a synchronization message (SyncMessage), achieving a seamless interactive experience that blends the virtual and real worlds.
[0032] In one embodiment, S100 includes: S1021. When the user performs a behavioral operation on the first physical hardware device and / or the second physical hardware device, the motion interruption mechanism is triggered and a motion interruption signal is generated. S1022, The physical hardware device enters the coarse detection stage, and determines whether the behavior operation is an interfering behavior operation based on the motion interruption signal; S1023. When the coarse detection is a valid action operation, enter the event window sampling mode and collect motion feature data through the inertial sensor; S1024. The motion feature data constitutes interactive event data.
[0033] In this embodiment, when a user performs actions on the first and / or second physical hardware devices (such as shaking, moving, or throwing), the inertial sensor module inside the device first detects the change in physical motion. At this time, the low-power control module in the device triggers the motion interruption mechanism and generates a motion interruption signal. This mechanism is designed to maintain extremely low power consumption when the device is stationary or in a low-activity state—in this case, the inertial sensor operates at a very low frequency, or even enters a sleep mode, and is only awakened when it detects an acceleration change or attitude change exceeding a preset threshold. This "event-driven sampling" strategy is a key means of reducing overall power consumption and avoids the battery consumption problem caused by continuous high-frequency sampling in traditional solutions.
[0034] After a motion interruption signal is generated, the physical hardware device enters a coarse detection phase. In this phase, the system preliminarily determines whether the user's action is an interfering action based on the motion interruption signal. Interfering actions typically include minor vibrations caused by environmental shocks when the device is placed on a table, brief accidental collisions, or slight shaking of the device in a user's pocket while walking—all unintentional movements. The coarse detection phase uses low-frequency sampling data for rapid filtering, filtering out obvious noise and interference by setting simple threshold conditions (such as whether the acceleration amplitude reaches the minimum effective threshold, or whether the motion duration exceeds the minimum effective duration). If the motion characteristics do not meet the basic conditions for valid behavior, the system determines the operation to be an interfering action. At this point, the device will abandon further processing and return to a low-power, stationary monitoring state, thus avoiding complete feature extraction and reporting of invalid events, further saving computing and communication resources.
[0035] When the coarse detection determines that the action is valid, the physical hardware device enters the event window sampling mode. In this mode, the low-power control module increases the sampling frequency of the inertial sensor to a preset high-frequency level. However, sampling is not unlimited but strictly limited to the "event window"—a finite time period from the start of the motion interruption to the stabilization of the motion characteristics. This windowed sampling strategy ensures that the system only captures data segments directly related to the user's intended action, avoiding the collection of a large amount of redundant static state data. This reduces both the amount of data processing and the data load for subsequent communication transmission.
[0036] During the event window sampling period, inertial sensors (typically including accelerometers, gyroscopes, etc.) acquire detailed motion characteristic data. This data includes raw sensing waveforms such as acceleration changes, angular velocity changes, displacement trajectories, and attitude changes of the device in three-dimensional space. After acquisition, the system preprocesses this raw data, including sliding window segmentation, noise reduction (such as filtering high-frequency noise and separating gravity components), and normalization, to ensure data quality and comparability. Subsequently, multi-dimensional feature parameters are extracted from the preprocessed data, including root mean square value (reflecting the overall intensity of motion energy), peak-to-peak value (reflecting the amplitude range of motion), dominant frequency (identifying the periodic characteristics of motion through frequency domain analysis), frequency band energy distribution (analyzing the energy proportion of different frequency bands to distinguish motion types), zero-crossing rate (reflecting the frequency of signal vibration), and attitude change (reflecting the angular changes of the device in space). These feature parameters together constitute a feature vector, used for subsequent behavior classification and intent recognition.
[0037] The aforementioned motion feature data further constitutes interactive event data. Specifically, the system inputs the extracted feature vectors into a lightweight classifier (such as a decision tree, support vector machine, or miniature neural network), outputting the event type (such as "shaking," "throwing," "spinning," etc.) and the corresponding confidence level. To further reduce the false positive rate, the system also implements a false positive filtering mechanism, performing consistency checks on the classification results of multiple consecutive time windows. Only when the judgment results of N consecutive windows are consistent is the event finally confirmed. Valid events confirmed after these filtering mechanisms are encoded to generate event identifiers. These identifiers include information such as event type, timestamp, random number, monotonic counter, binding ID, and event feature summary, along with an event proof that can be verified by the server (usually a message authentication code MAC or digital signature). Finally, this interactive event data is relayed through the user terminal via a local connection (such as Bluetooth) or directly uploaded to the server via the network to trigger state updates of the corresponding intelligent agent in the virtual world (such as triggering an adventure task, updating emotion values or growth values, etc.), and a synchronization distribution mechanism ensures consistency across all terminals.
[0038] In one embodiment, S300 includes: S301. When the interaction behavior is a touch event, the physical hardware device locally completes the two-way challenge-response authentication, and the server performs authentication result legality verification based on the unique event identifier. S302. After the two-way challenge response authentication verification passes, the session validity is verified. If the validity verification passes, an event proof is generated. S303. When the interactive behavior is an action-type event, the physical hardware device locally performs multi-window consistency verification, and the server performs final verification of the validity of the behavior. S304. When the multi-window consistency check passes, perform behavior validity check. If the validity check passes, generate an event proof.
[0039] In this embodiment, when a user-initiated interaction is determined to be a touch event, that is, when near-field communication physical contact occurs between the first and second physical hardware devices, the two-way challenge-response authentication is completed locally by the two physical hardware devices. The server is only responsible for receiving the event token and performing legality verification. First, the server receives the event token submitted by the hardware device. This token contains a unique event identifier (event_id). This identifier is usually generated by hashing key parameters such as the session identifier (session_id), the two-way random number (Nonce, i.e., "Number Used Once"), the touch start time (t0), the touch end time (t1), and the event type (Event Type), ensuring that each touch event is globally unique and unforgeable. Local authentication phase: The first physical hardware device sends a challenge value (Challenge_A) to the second physical hardware device, which then uses the pre-stored key material in its secure storage module to generate a response value (Response_B) and returns it. Subsequently, the second physical hardware device sends a challenge value (Challenge_B), and the first physical hardware device similarly generates a response value (Response_A) based on the key material and returns it. Only after both devices complete and confirm mutual authentication locally will reportable event data be generated. The server verifies the legitimacy, timeliness, and replay protection of the touch session solely based on the unique event identifier and event proof. If the authentication information is invalid or the verification fails, the session is immediately terminated, and no subsequent state update is performed. This "local mutual authentication + cloud-based legitimacy verification" mechanism effectively avoids the impersonation risks that may exist in one-way authentication, ensuring that only physical devices holding legitimate keys can establish trusted touch associations.
[0040] After the two-way challenge-response authentication is successful, the server further verifies the validity of the touch session. This validity verification involves a combination of multiple security rules: first, a timestamp validity check is performed to confirm that the event occurred within a reasonable time window, preventing expired events from being submitted; second, a random number unused check is performed to ensure that the random number has not been used previously, preventing attackers from replaying attacks by intercepting historical communications; third, a monotonic counter monotonicity check is performed to verify that the counter value reported by the device strictly increases, preventing events from being submitted out of order or maliciously rolled back; finally, event validity and anti-replay checks are performed to ensure that the entire touch session completes the two-way challenge-response authentication within a preset time window (ΔT), and that the touch duration is within a reasonable threshold range. In addition, the server also checks the round-trip time (RTT). If the RTT is greater than a preset threshold, the touch event is rejected to suppress spoofing attacks carried out through relay devices or forwarding devices. Only after all the above validity checks pass will the server generate an event proof for the touch event. This proof is usually a message authentication code (MAC) calculated based on a shared key or a digital signature based on an asymmetric key, used to prove to the server that the event was indeed generated by a legitimate entity hardware device and has not been tampered with.
[0041] When a user-initiated interaction is classified as an action event—that is, when the user triggers a state change in the virtual agent by performing physical operations such as shaking, displacement, or specific acceleration patterns on the physical hardware device—coarse detection and multi-window consistency verification are all performed locally on the physical hardware device to ensure low power consumption and real-time performance, and to avoid uploading invalid data. After a motion interruption is triggered, the hardware device first enters a local coarse detection phase to quickly filter out interference behaviors such as environmental vibrations and instantaneous collisions. If the action is determined to be valid, it enters an event window sampling mode, where inertial sensors collect motion feature data, and multi-window consistency verification is continuously performed locally to ensure that the action classification results of multiple consecutive windows remain consistent, eliminating single false triggers. Only action events that pass both local coarse detection and multi-window consistency verification are encapsulated into event tokens and uploaded. Upon receiving the event, the server only performs final behavior validity verification and anti-replay verification, and no longer participates in the action recognition and filtering process. This significantly reduces hardware power consumption, reduces network transmission and cloud computing pressure, and ensures the system's real-time performance and low power consumption design goals.
[0042] After the multi-window consistency check passes, the server further performs a behavior validity check. Behavior validity check is a composite false positive filtering strategy designed to eliminate various unintentional interference behaviors. Specifically, it includes: static suppression, excluding minor vibrations caused by environmental shocks when the device is placed on a desktop or in a fixed position; short-term vibration suppression, excluding instantaneous acceleration spikes caused by brief accidental collisions or drops; and trigger cooldown time verification, ensuring that the same device will not repeatedly trigger the same type of event within a short period, preventing unintentional continuous user operations from being identified as multiple independent events. Furthermore, behavior validity check can also be combined with terminal context information for joint judgment, such as verifying whether the user terminal is running in the foreground or whether adventure mode is enabled, to further reduce the probability of false triggers. Only after both the multi-window consistency check and the behavior validity check pass will the server generate an event proof (EventProof) for the action-type event. This proof also uses a Message Authentication Code (MAC) or digital signature to ensure the integrity and non-repudiation of the event during transmission to the server and subsequent synchronous distribution. Through the aforementioned layered verification mechanism, action-type events achieve high-precision recognition of genuine user intent and behavior and effective suppression of environmental interference while maintaining a low-power design.
[0043] In one embodiment, S500 includes: When the interaction behavior is a touch event, the server queries the target virtual intelligent agents of both parties according to the binding mapping relationship, establishes a friend relationship between the two virtual intelligent agents, and the world engine and / or intelligent agent service synchronously updates the friend list status. When the interaction is an action-type event, the server triggers the target virtual agent to perform the interaction action based on motion feature data and intensity parameters, and the world engine and / or agent service updates the state of the virtual agent.
[0044] In this embodiment, when a user-initiated interaction is determined to be a touch event, i.e., after the first and second physical hardware devices complete a physical touch via near-field communication and pass the server's two-way challenge-response authentication and validity verification, the server enters the friend relationship establishment phase. The server first queries the target virtual agents of both parties based on the binding mapping relationship. The binding mapping relationship establishment process is as follows: the user terminal requests a binding authorization token from the server beforehand; the physical hardware device stores the binding index in its local secure storage module; and the server maintains a one-to-one mapping relationship between the physical hardware devices and the target agent identifiers in the binding mapping service. After the touch event verification is successful, the server maps the agent identifiers of the first agent (Agent_A) and the second agent (Agent_B) respectively based on the binding index (binding_id) submitted by both hardware devices, thereby determining the target virtual agents of both parties.
[0045] After identifying the target virtual agents, the server performs a friend relationship establishment operation. Specifically, the server establishes a bidirectional friend relationship between Agent_A and Agent_B in the agent service and writes this "friend establishment event" to the event tracing log. Simultaneously, it assigns a monotonically increasing sequence number and / or logical clock to the target agent for subsequent sequential playback across multiple devices. Subsequently, the server calls the virtual world engine and / or agent service to synchronously update the friend list status. Status updates include, but are not limited to: adding the other agent's friend entry to the social relationship data structure of both agents, updating friend visibility status, and initializing friend interaction permissions. The server generates a synchronization message carrying a sequence number (seq) and / or a logical clock (clock). This message includes the target agent identifier (agent_id), state delta (here, the newly added friend relationship), acknowledgment event identifier (ack_event_id), and conflict hint (conflict_hint). The synchronization message is distributed to user terminals and / or friend terminals through the synchronization distribution service to update the friend list interface, social relationship graph, and related interaction entry points displayed in the virtual world. In addition, the server will send an acknowledgment (ACK) to the hardware device to inform it that the touch event has been successfully processed.
[0046] When a user-initiated interaction is determined to be an action event—that is, when the user performs physical operations such as shaking, displacement, or a specific acceleration pattern on a physical hardware device—and the event has passed the server's multi-window consistency check and behavior validity check, the server enters the interaction action triggering phase. The server first parses the motion characteristic data contained in the interaction event data. This characteristic data includes multi-dimensional parameters such as the root mean square (RMS, reflecting the overall intensity of motion energy), peak-to-peak value (reflecting the range of motion amplitude), dominant frequency (reflecting the periodicity of motion), frequency band energy distribution (reflecting the proportion of energy in different frequency bands), zero-crossing rate (reflecting the frequency of signal vibration), and attitude change amount (reflecting changes in the device's spatial angle). The server performs mapping calculations based on these motion characteristic data and preset intensity parameters, including but not limited to motion intensity level, duration level, and confidence level, to determine the specific interaction action type and effect parameters to be triggered for this action event.
[0047] Based on the mapping results, the server triggers the target virtual agent to execute corresponding interactive actions. The specific type of interactive action is dynamically determined based on the combination of motion characteristics and intensity parameters. For example, when a high-intensity, prolonged shaking pattern is detected, an "exploration mission" may be triggered, and exploration parameters, including exploration distance, difficulty level, reward probability, and mood gain, may be mapped according to the intensity parameters. When a medium-intensity displacement pattern is detected, a "mood value update" or "growth value update" may be triggered. When a specific acceleration pattern is detected, an "unlock residence item" or "update item inventory" may be triggered. The server sends the action execution instructions to the virtual world engine and / or the agent service, which then drives the state update of the target virtual agent in the virtual world.
[0048] After the state update is complete, the server also writes the update event to the event sourcing log, assigns a monotonically increasing sequence number (seq) and / or a logical clock (clock), and generates a synchronization message carrying the state increment (delta). This synchronization message is an incremental differential message, containing only the differential data of the state change (such as a change in emotion value +5, a change in growth value +10, an increase in exploration progress of 15%, etc.) and the corresponding sequence number range, rather than transmitting a complete snapshot of the agent's state, thus significantly reducing the communication load. The synchronization message is distributed to user terminals and / or friend terminals through a synchronization distribution service to update visual elements such as the agent's state panel, exploration progress bar, emotion expressions, growth level, and residence scene in the virtual world display in real time. For friend terminals, the synchronization message allows them to observe the dynamic changes of the other party's agent (such as "Your friend XX's agent is currently on an adventure"), enhancing the social interaction experience. At the same time, the server supports offline caching and retry mechanisms: when a terminal or physical hardware device is offline, unconfirmed events are written to a local queue; after the network is restored, they are uploaded in batches in order, and an exponential backoff strategy is used to retry until server confirmation is received. The server performs idempotent deduplication based on the unique event identifier event_id, ensuring that duplicate reported events do not cause the agent's state to be updated repeatedly, thereby guaranteeing consistency and synchronization correctness across multiple devices.
[0049] In one embodiment, it also includes: When the user terminal or physical hardware device is offline, unacknowledged interaction events are written to the local offline queue. After the network is restored, the interactive events in the offline queue are uploaded in chronological order, and the upload is retried using an exponential backoff strategy. The server uses idempotent deduplication based on the unique event identifier. When the server receives an interaction event, it performs idempotent deduplication based on the unique event identifier to avoid repeated state updates.
[0050] In this embodiment, when the user terminal or physical hardware device is offline—that is, when the network connection between the device and the server is interrupted due to signal loss, airplane mode, battery depletion, or the user actively turning off the network—the system needs to ensure that interactive events during this period are not lost. At this time, the event relay and caching module on the device side writes unconfirmed interactive events to a local offline queue. The offline queue is a persistent data structure, typically stored in the device's non-volatile memory, ensuring that event data is not lost even after the device restarts. Each event entry in the queue contains complete event token information, including a unique event identifier, event type, timestamp, random number, monotonic counter, binding index, feature digest, and event proof, among other key fields. The queue is organized according to the chronological order of event occurrence, ensuring that subsequent recovery can replay events in the original timeline. Furthermore, the queue also maintains the upload status and retry count for each event to track which events have been successfully confirmed and which are still pending upload.
[0051] Once the network is restored, i.e., the device re-detects an available network connection (such as Wi-Fi, cellular data, or Bluetooth repeater) and confirms a stable communication with the server, the device initiates an offline event synchronization mechanism. The system uploads interactive events in the offline queue in chronological order, following a "first-in, first-out" principle, prioritizing the upload of the earliest generated unconfirmed events to ensure that the server's event tracing log records events according to their true chronological order. The upload process employs a batch encapsulation strategy, merging multiple offline events into a single data packet for transmission, rather than uploading them individually, thereby reducing communication overhead and the number of connection establishments. Simultaneously, the system uses an exponential backoff strategy to retry uploads, with the server using idempotent deduplication based on unique event identifiers. Exponential backoff is a network retry algorithm whose core idea is that when an upload attempt fails, the system does not immediately attempt another, but waits for a gradually increasing delay before retrying. Specifically, the waiting time after the first failure is short (e.g., 1 second). If it fails again, the waiting time doubles (e.g., 2 seconds, 4 seconds, 8 seconds, 16 seconds, and so on) until the preset maximum backoff limit (e.g., 5 minutes) is reached. This strategy effectively avoids generating a large number of invalid retry requests when the network is unstable or the server is temporarily overloaded, preventing traffic surges to the server and reducing device power consumption. When an event is successfully uploaded and receives an acknowledgment (ACK) from the server, the event is removed from the offline queue; if it still fails after reaching the maximum number of retries, the event is marked as abnormal and a local alarm or user notification may be triggered.
[0052] When the server receives an interaction event from a user terminal or physical hardware device, it first processes it through the event verification service. The server performs idempotent deduplication based on a unique event identifier (event_id). Idempotency is a core concept in distributed systems, meaning that the same operation, whether performed once or multiple times, produces the same effect. In the context of this invention, idempotent deduplication means that regardless of whether the same interaction event is uploaded once or multiple times (e.g., due to network jitter causing the client to fail to receive an ACK and thus re-upload, or the client retrying multiple times during exponential backoff), the server only performs a valid state update for that event once, and subsequent duplicate submissions will not produce any side effects. In practice, the server maintains a set of processed event identifiers, typically stored using a high-performance distributed cache or database index structure. When a new event is received, the server first checks if the event_id already exists in the processed set. If it does, it indicates that the event has been successfully processed previously, and the server directly returns an ACK response without repeating subsequent state update logic, event tracing log writing, and synchronization message distribution operations. If it does not exist, the event_id is added to the processed set, and the complete event processing flow continues, including security verification steps such as proof verification, timestamp validity verification, random number unused verification, and counter monotonicity verification. Subsequently, the target agent's state is updated, a synchronization message is generated, and distributed to each terminal. Through an idempotent deduplication mechanism, the system effectively solves the problem of duplicate event processing caused by offline retries, network timeouts, and client retransmissions, ensuring the consistency and correctness of the virtual agent's state in a multi-terminal environment and avoiding data anomalies such as duplicate friend additions, duplicate triggering of adventure tasks, and duplicate increases or decreases in emotion or growth values.
[0053] In one embodiment, a virtual intelligent agent interaction device based on a physical carrier is provided, which corresponds one-to-one with the virtual intelligent agent interaction method based on a physical carrier described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the virtual intelligent agent interaction device based on a physical carrier according to the present invention. The modules include an event acquisition module 10, a feature extraction and encoding module 20, a validity verification module 30, a target virtual intelligent agent module 40, and a state update module 50. Detailed descriptions of each functional module are as follows: Event acquisition module 10 is used to acquire interaction event data of physical hardware devices engaging in interactive behavior; The feature extraction and encoding module 20 is used to parse the interaction event data, extract interaction event features, encode the interaction event features, and generate a unique event identifier; The validity verification module 30 is used to perform hierarchical verification of interactive behavior based on unique event identifier and event type. When the interactive behavior passes the verification, the unique event identifier and event proof are uploaded to the server through the user terminal. The target virtual agent module 40 is used to verify the legitimacy of the event proof after the server receives the unique event identifier and event proof. If the legitimacy verification is successful, the unique event identifier is sent to the world engine and / or the agent service, and the corresponding target virtual agent is queried according to the unique event identifier and the preset binding mapping relationship. The state update module 50 is used to perform interactive state updates on the target virtual agent by the world engine and / or agent service based on the event type corresponding to the unique event identifier.
[0054] In one embodiment, the initialization module includes: Obtain the first virtual intelligent agent identifier and the first physical hardware device ID corresponding to the first user terminal; The first user terminal sends a first binding authorization token instruction to the server, and the server performs identity verification and permission verification based on the first binding authorization token instruction; After the identity verification and permission verification of the first user terminal are passed, the server generates a first binding index and writes the first binding index into the secure storage module of the first physical hardware device. The server establishes a first binding mapping relationship based on the first entity hardware device ID, the first binding index, and the first virtual intelligent agent identifier; Obtain the second virtual intelligent agent identifier and the second physical hardware device ID corresponding to the second user terminal; The second user terminal sends a second binding authorization token instruction to the server, and the server performs identity verification and permission verification based on the second binding authorization token instruction. After the identity verification and permission verification of the second user terminal are passed, the server generates a second binding index and writes the second binding index into the secure storage module of the second physical hardware device; The server establishes a second binding mapping relationship based on the second entity hardware device ID, the second binding index, and the second virtual agent identifier.
[0055] In one embodiment, the event acquisition module 10 includes: When the first physical hardware device and the second physical hardware device come into close contact, a touch session request is generated. The touch session request is parsed to obtain the session identifier, the first random number, the second random number, and the touch start and end time; The session identifier, random numbers from both parties, and touch start and end times are fused together to generate touch session data; Based on the touch session data, a two-way challenge-response authentication is performed, and authentication result information is generated; The touch session data and authentication information constitute the interaction event data.
[0056] In one embodiment, the event acquisition module 10 includes: When a user performs a behavioral operation on the first physical hardware device and / or the second physical hardware device, the motion interruption mechanism is triggered and a motion interruption signal is generated. The physical hardware device enters the coarse detection stage, and determines whether the behavior operation is an interfering behavior operation based on the motion interruption signal. When the coarse detection is a valid action, the system enters the event window sampling mode and collects motion feature data through the inertial sensor. The motion feature data constitutes the interactive event data.
[0057] In one embodiment, the validity verification module 30 includes: When the interaction behavior is a touch event, the physical hardware device locally completes the two-way challenge-response authentication, and the server performs a legality verification of the authentication result based on the unique event identifier. Once the two-way challenge-response authentication verification is passed, the session validity is verified. If the validity verification is passed, an event proof is generated. When the interaction behavior is an action-type event, the physical hardware device performs multi-window consistency verification locally, and the server performs final verification of the validity of the behavior. When the multi-window consistency check passes, the behavior validity check is performed. If the validity check passes, an event proof is generated.
[0058] In one embodiment, the state update module 50 includes: When the interaction behavior is a touch event, the server queries the target virtual intelligent agents of both parties according to the binding mapping relationship, establishes a friend relationship between the two virtual intelligent agents, and the world engine and / or intelligent agent service synchronously updates the friend list status. When the interaction is an action-type event, the server triggers the target virtual agent to perform the interaction action based on motion feature data and intensity parameters, and the world engine and / or agent service updates the state of the virtual agent.
[0059] In one embodiment, an offline management module is also included: When the user terminal or physical hardware device is offline, unacknowledged interaction events are written to the local offline queue. After the network is restored, the interactive events in the offline queue are uploaded in chronological order, and the upload is retried using an exponential backoff strategy. The server uses idempotent deduplication based on the unique event identifier. When the server receives an interaction event, it performs idempotent deduplication based on the unique event identifier to avoid repeated state updates.
[0060] Specific limitations regarding virtual intelligent agent interaction devices based on physical carriers can be found in the aforementioned limitations on virtual intelligent agent interaction methods based on physical carriers, and will not be repeated here. Each module in the aforementioned virtual intelligent agent interaction device based on physical carriers can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0061] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a virtual intelligent agent interaction method based on a physical carrier on the server side.
[0062] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the client-side functions or steps of a virtual intelligent agent interaction method based on a physical carrier.
[0063] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Acquire interaction event data of physical hardware devices engaging in interactive behaviors; The interaction event data is parsed, interaction event features are extracted, and the interaction event features are encoded to generate a unique event identifier; Interactive behaviors are validated in layers based on unique event identifiers and event types. When the interactive behavior validation passes, the unique event identifier and event proof are uploaded to the server via the user terminal. When the server receives the unique event identifier and event proof, it verifies the legitimacy of the event proof. If the legitimacy verification passes, the server sends the unique event identifier to the world engine and / or the intelligent agent service, and queries the corresponding target virtual intelligent agent based on the unique event identifier and the preset binding mapping relationship. The target virtual agent is updated interactively by the World Engine and / or the agent service based on the event type corresponding to the unique event identifier.
[0064] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Acquire interaction event data of physical hardware devices engaging in interactive behaviors; The interaction event data is parsed, interaction event features are extracted, and the interaction event features are encoded to generate a unique event identifier; Interactive behaviors are validated in layers based on unique event identifiers and event types. When the interactive behavior validation passes, the unique event identifier and event proof are uploaded to the server via the user terminal. When the server receives the unique event identifier and event proof, it verifies the legitimacy of the event proof. If the legitimacy verification passes, the server sends the unique event identifier to the world engine and / or the intelligent agent service, and queries the corresponding target virtual intelligent agent based on the unique event identifier and the preset binding mapping relationship. The target virtual agent is updated interactively by the World Engine and / or the agent service based on the event type corresponding to the unique event identifier.
[0065] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.
[0066] Those skilled in the art will understand that all or part of the processes in the methods of 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, and when executed, it 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 non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0067] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.
[0068] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.
[0069] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.
Claims
1. A virtual intelligent agent interaction method based on a physical carrier, characterized in that, Includes the following steps: Acquire interaction event data of physical hardware devices engaging in interactive behaviors; The interaction event data is parsed, interaction event features are extracted, and the interaction event features are encoded to generate a unique event identifier; Interactive behaviors are validated in layers based on unique event identifiers and event types. When the interactive behavior validation passes, the unique event identifier and event proof are uploaded to the server via the user terminal. When the server receives the unique event identifier and event proof, it verifies the legitimacy of the event proof. If the legitimacy verification passes, the server sends the unique event identifier to the world engine and / or the intelligent agent service, and queries the corresponding target virtual intelligent agent based on the unique event identifier and the preset binding mapping relationship. The World Engine and / or the Agent Service update the interactive state of the target virtual agent based on the event type corresponding to the unique event identifier. The acquisition of interaction event data of interactive behavior of physical hardware devices includes: When the first physical hardware device and the second physical hardware device come into close contact, a touch session request is generated. The touch session request is parsed to obtain the session identifier, the first random number, the second random number, and the touch start and end time; The session identifier, random numbers from both parties, and touch start and end times are fused together to generate touch session data; Based on the touch session data, a two-way challenge-response authentication is performed, and authentication result information is generated; The touch session data and authentication result information constitute the interaction event data; The acquisition of interaction event data of interactive behavior of physical hardware devices includes: When a user performs a behavioral operation on the first physical hardware device and / or the second physical hardware device, the motion interruption mechanism is triggered and a motion interruption signal is generated. The physical hardware device enters the coarse detection stage, and determines whether the behavior operation is an interfering behavior operation based on the motion interruption signal. When the coarse detection is a valid action, the system enters the event window sampling mode and collects motion feature data through the inertial sensor. The motion feature data constitutes the interactive event data.
2. The virtual intelligent agent interaction method based on a physical carrier as described in claim 1, characterized in that, Before acquiring interaction event data of physical hardware devices engaging in interactive behavior, the following is included: Obtain the first virtual intelligent agent identifier and the first physical hardware device ID corresponding to the first user terminal; The first user terminal sends a first binding authorization token instruction to the server, and the server performs identity verification and permission verification based on the first binding authorization token instruction; After the identity verification and permission verification of the first user terminal are passed, the server generates a first binding index and writes the first binding index into the secure storage module of the first physical hardware device. The server establishes a first binding mapping relationship based on the first entity hardware device ID, the first binding index, and the first virtual intelligent agent identifier; Obtain the second virtual intelligent agent identifier and the second physical hardware device ID corresponding to the second user terminal; The second user terminal sends a second binding authorization token instruction to the server, and the server performs identity verification and permission verification based on the second binding authorization token instruction. After the identity verification and permission verification of the second user terminal are passed, the server generates a second binding index and writes the second binding index into the secure storage module of the second physical hardware device; The server establishes a second binding mapping relationship based on the second entity hardware device ID, the second binding index, and the second virtual agent identifier.
3. The virtual intelligent agent interaction method based on a physical carrier as described in claim 1, characterized in that, Interactive behaviors are validated hierarchically based on unique event identifiers and event types. When the interactive behavior validation passes, the unique event identifier and event proof are uploaded to the server via the user terminal, including: When the interaction behavior is a touch event, the two-way challenge-response authentication is completed locally by the physical hardware device. After the two-way challenge-response authentication verification passes, the session validity verification is performed. If the session validity verification passes, an event certificate is generated, and the server performs the authentication result legality verification based on the unique event identifier. When the interaction behavior is an action-type event, the multi-window consistency verification is performed locally by the physical hardware device. When the multi-window consistency check passes, the behavior validity check is performed. If the behavior validity check passes, an event proof is generated, and the server performs the final behavior validity check.
4. The virtual intelligent agent interaction method based on a physical carrier as described in claim 1, characterized in that, The world engine and / or agent service update the interactive state of the target virtual agent based on the event type corresponding to the unique event identifier, including: When the interaction behavior is a touch event, the server queries the target virtual agents of both parties according to the binding mapping relationship, establishes a friend relationship between the two virtual agents, and the world engine and / or agent service synchronously updates the friend list status. When the interaction is an action-type event, the server triggers the target virtual agent to perform the interaction action based on motion feature data and intensity parameters, and the world engine and / or agent service updates the state of the virtual agent.
5. The virtual intelligent agent interaction method based on a physical carrier as described in claim 1, characterized in that, Also includes: When the user terminal or physical hardware device is offline, unacknowledged interaction events are written to the local offline queue. After the network is restored, the interactive events in the offline queue are uploaded in chronological order, and the upload is retried using an exponential backoff strategy. The server uses idempotent deduplication based on the unique event identifier. When the server receives an interaction event, it performs idempotent deduplication based on the unique event identifier to avoid repeated state updates.
6. A virtual intelligent agent interaction device based on a physical carrier, characterized in that, The virtual intelligent agent interaction device based on a physical carrier includes: The event acquisition module is used to acquire interaction event data of physical hardware devices engaging in interactive behavior; The feature extraction and encoding module is used to parse the interaction event data, extract interaction event features, encode the interaction event features, and generate a unique event identifier; The validity verification module is used to perform hierarchical verification of interactive behaviors based on unique event identifiers and event types. When the interactive behavior passes the verification, the unique event identifier and event proof are uploaded to the server through the user terminal. The target virtual agent module is used to verify the legitimacy of the event proof after the server receives the unique event identifier and event proof. If the legitimacy verification is successful, the unique event identifier is sent to the world engine and / or the agent service, and the corresponding target virtual agent is queried according to the unique event identifier and the preset binding mapping relationship. The state update module is used to perform interactive state updates on the target virtual agent by the world engine and / or agent service based on the event type corresponding to the unique event identifier; The event acquisition module specifically includes: When the first physical hardware device and the second physical hardware device come into close contact, a touch session request is generated. The touch session request is parsed to obtain the session identifier, the first random number, the second random number, and the touch start and end time; The session identifier, random numbers from both parties, and touch start and end times are fused together to generate touch session data; Based on the touch session data, a two-way challenge-response authentication is performed, and authentication result information is generated; The touch session data and authentication result information constitute the interaction event data; The event acquisition module specifically includes: When a user performs a behavioral operation on the first physical hardware device and / or the second physical hardware device, the motion interruption mechanism is triggered and a motion interruption signal is generated. The physical hardware device enters the coarse detection stage, and determines whether the behavior operation is an interfering behavior operation based on the motion interruption signal. When the coarse detection is a valid action, the system enters the event window sampling mode and collects motion feature data through the inertial sensor. The motion feature data constitutes the interactive event data.
7. A computer device, characterized in that, The computer device includes a memory, a processor, and a virtual intelligent agent interaction program based on a physical carrier stored in the memory and executable on the processor. When the virtual intelligent agent interaction program based on a physical carrier is executed by the processor, it implements the steps of the virtual intelligent agent interaction method based on a physical carrier as described in any one of claims 1-5.
8. A computer-readable storage medium, characterized in that, The storage medium stores a virtual intelligent agent interaction program based on a physical carrier. When the virtual intelligent agent interaction program based on the physical carrier is executed by the processor, it implements the steps of the virtual intelligent agent interaction method based on a physical carrier as described in any one of claims 1-5.