Cross-device interaction control method and device, computer device, computer readable storage medium and program product

Abstract

The invention relates to a cross-device interaction control method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: acquiring output rhythm control information of a target interaction process; the output rhythm control information comprises execution time sequence constraints aiming at a plurality of selectable output events in the target interaction process; receiving an execution request of target equipment for the target output event; acquiring historical execution conditions of other selectable devices on the plurality of selectable output events; according to the output rhythm control information and a historical execution condition, determining a constraint satisfaction condition of an output time sequence of the target output event to an execution time sequence constraint under the condition of responding to the execution request; and controlling the execution time sequence of the target output event on the target equipment according to the constraint satisfaction condition. By adopting the method, the user experience of cross-device interaction can be improved.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a cross-device interactive control method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of mobile internet, the Internet of Things, and distributed computing technologies, smart terminal devices are becoming increasingly diversified. In their daily work and life, users often own and use multiple devices simultaneously, such as mobile phones, tablets, smartwatches, smart speakers, and in-vehicle systems.

[0003] To ensure service continuity, related technologies often employ session synchronization or state migration mechanisms. For example, when a user switches from a mobile phone to a tablet to continue a task, cloud synchronization migrates the current task's progress, entered data, and other contextual information to the new device, allowing the user to resume operation from where they left off.

[0004] However, the relevant technologies only focus on synchronizing interactive content and business status, which leads to conflicts and confusion such as duplicate output and disordered output order when the same interactive session is presented on different devices, thus affecting the efficiency, accuracy and user experience of the interaction. Summary of the Invention

[0005] Therefore, it is necessary to provide a cross-device interactive control method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve interaction efficiency and interactive experience in response to the above-mentioned technical problems.

[0006] In a first aspect, this application provides a cross-device interactive control method, including:

[0007] Obtain the output rhythm control information corresponding to the target interaction process; the output rhythm control information includes the execution timing constraints for multiple optional output events in the target interaction process;

[0008] Receive an execution request from a target device in response to a target output event; wherein the target device is at least one of a plurality of optional devices associated with the target interaction process; and the target output event is at least one of the plurality of optional output events;

[0009] Obtain the historical execution status of each of the other optional devices for the plurality of optional output events;

[0010] Based on the output rhythm control information and the historical execution status, determine whether the output timing of the target output event satisfies the execution timing constraint when responding to the execution request;

[0011] The execution timing of the target output event on the target device is controlled based on the constraint satisfaction status.

[0012] In some embodiments, the optional output events represent the smallest interactive unit with independent interactive semantics; the output rhythm control information is associated with and stored in conjunction with the interactive process identifier of the target interactive process; the optional devices include different types of terminals and different application instances running within the same terminal; the execution timing constraints include execution order constraints among the plurality of optional output events;

[0013] The step of determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraints in response to the execution request, includes:

[0014] Based on the execution order constraint, determine the preceding output event associated with the target output event from the plurality of optional output events;

[0015] Based on the historical execution status, determine whether the preceding output event has been completed, and obtain the first determination result;

[0016] The constraint satisfaction status is determined based on the first judgment result; wherein, if the preceding output event has been completed, it is determined that the output timing of the target output event satisfies the execution order constraint in response to the execution request.

[0017] In some embodiments, the execution timing constraint includes an execution time interval constraint for the target output event; determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraint in response to the execution request includes:

[0018] Determine the execution completion timestamp of the preceding output event associated with the target output event based on the historical execution data;

[0019] Calculate the time difference between the current time and the execution completion timestamp, and compare the time difference with the minimum interval threshold required by the execution time interval constraint to obtain the comparison result;

[0020] The constraint satisfaction status is determined based on the comparison result; wherein, if the time difference is greater than or equal to the minimum interval threshold, it is determined that the output timing of the target output event satisfies the execution time interval constraint in response to the execution request.

[0021] In some embodiments, the execution timing constraint includes an execution frequency constraint for the target output event; determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraint in response to the execution request includes:

[0022] Based on the historical execution data, the total number of times the optional output events have been executed within the unit time window defined by the execution frequency constraint to which the current time belongs is counted.

[0023] Determine whether the total number of executions is less than the maximum number of executions defined by the execution frequency constraint to obtain a second determination result;

[0024] Based on the second judgment result, the constraint satisfaction status is determined; wherein, if the total number is less than the maximum execution number, it is determined that, in response to the execution request, the output timing of the target output event satisfies the execution frequency constraint.

[0025] In some embodiments, the execution timing constraint includes an execution count constraint for the target output event; determining whether the execution request satisfies the execution timing constraint based on the output rhythm control information and the historical execution status includes:

[0026] Based on the historical execution data, the number of times the target output event has been executed during the target interaction process is counted.

[0027] Determine whether the number of executions is less than the maximum number defined by the execution count constraint to obtain a third determination result;

[0028] Based on the third judgment result, the constraint satisfaction status is determined; wherein, if the number of executions is less than the maximum number of executions, it is determined that, in response to the execution request, the output timing of the target output event satisfies the execution count constraint.

[0029] In some embodiments, controlling the execution timing of the target output event on the target device according to the constraint satisfaction includes:

[0030] If the constraint satisfaction condition indicates that the execution timing constraint is satisfied, the execution request is responded to so that the target device currently executes the target output event, and the historical execution status is updated after the target output event is executed;

[0031] If the constraint satisfaction condition indicates that the execution timing constraint is not satisfied, a timing conflict resolution operation is performed on the execution request; wherein, the timing conflict resolution operation includes a delay operation or a skip operation; the delay operation is used to postpone the response to the execution request until the target time that satisfies the execution timing constraint; the skip operation is used to abort the response to the execution request.

[0032] In some embodiments, the historical execution data is stored on a coordination server or distributed locally on each of the optional devices; obtaining the historical execution data of the other optional devices for the plurality of optional output events includes:

[0033] The target device sends a status query request to the coordination server to obtain the historical execution status.

[0034] Alternatively, the target device may query other optional devices according to a preset consensus protocol to obtain the historical execution status;

[0035] The step of controlling the target device to execute the target output event if the constraint is satisfied indicates that the execution timing constraint is met, and updating the historical execution status after the target output event is executed includes:

[0036] In response to the completion of the target output event on the target device, an execution completion notification for the target output event is generated; the execution completion notification includes at least one of the identifier of the target output event, the identifier of the target device, and an execution completion timestamp;

[0037] The execution completion notification is sent to the coordination server, or broadcast to other optional devices via a distributed synchronization protocol to update the historical execution status.

[0038] Secondly, this application also provides a cross-device interactive control device, the device comprising:

[0039] The first acquisition module is used to acquire output rhythm control information corresponding to the target interaction process; the output rhythm control information includes execution timing constraints for multiple optional output events in the target interaction process;

[0040] A receiving module is configured to receive an execution request from a target device in response to a target output event; wherein the target device is at least one of a plurality of optional devices associated with the target interaction process; and the target output event is at least one of the plurality of optional output events.

[0041] The second acquisition module is used to acquire the historical execution status of each of the other optional devices for the plurality of optional output events;

[0042] The determination module is used to determine, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the constraint of the execution timing constraint in response to the execution request.

[0043] The control module is used to control the execution timing of the target output event on the target device according to the constraint satisfaction status.

[0044] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0045] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0046] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0047] The aforementioned cross-device interactive control methods, devices, computer equipment, computer-readable storage media, and computer program products define the timing constraints of output events by introducing unified "output rhythm control information" and synchronizing "historical execution status" among all participating devices. This allows any device to determine whether the current output is compliant based on the global state before preparing to output, thereby dynamically coordinating the output rhythm of each end, rather than forcing all devices to output the same content simultaneously or in complete synchronization. This ensures that when output events in the same interactive process are presented on multiple devices or interfaces, their output timing remains consistent and does not cause conflicts. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 This is an application environment diagram of a cross-device interactive control method in one embodiment;

[0050] Figure 2 This is a flowchart illustrating a cross-device interaction control method in one embodiment;

[0051] Figure 3 This is a structural block diagram of a cross-device interaction control device in one embodiment;

[0052] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0053] 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.

[0054] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0055] Before describing the embodiments of this application, the relevant technologies and their existing problems will be further explained:

[0056] The ability of the same digital service or interactive system (such as personal assistants, smart home controls, continuous workflow applications, etc.) to run seamlessly across multiple devices and provide a consistent experience has become a key requirement for improving user experience.

[0057] Related technologies primarily focus on synchronizing interactive content with business status, but generally neglect the time coordination issues at the output presentation layer of the interaction process itself. Specifically, in scenarios where multiple devices are used in parallel or switch rapidly, when the system needs to output interactive information to the user (such as operation guidance, status notifications, confirmation prompts, etc.), each device typically decides the timing, order, and frequency of output independently based on its local logic, sensor status, or network response. This lack of globally coordinated output mode easily leads to conflicts and confusion in the output rhythm when the same interactive session is presented on different devices, for example:

[0058] Duplicate output: A prompt message that the user has received and confirmed on device A may be re-output when switching to device B, because device B does not realize that the output has been completed, resulting in information redundancy and interference.

[0059] Disordered sequence: Multiple guiding steps with logical cause-and-effect relationships may be presented in reverse order on different devices due to slight differences in response speed or triggering conditions, thus disrupting the logic of the interaction.

[0060] Disrupted pacing: High-performance devices may advance the notification stream quickly, while low-performance devices or devices with poor network conditions may output slowly, resulting in inconsistent information delivery speeds perceived by users on different devices and a fragmented experience.

[0061] The aforementioned problems caused by inconsistent output rhythms disrupt the smoothness, consistency, and user experience of cross-device interactions. In summary, related technologies lack a lightweight, universal mechanism focused on coordinating the output timing itself, capable of effectively ensuring a harmonious and consistent output rhythm across multiple devices or interfaces for the same interactive session without deep involvement in specific business logic and content generation. Therefore, how to achieve consistent control of interactive output rhythms across devices and interfaces has become a pressing technical problem for improving the distributed human-computer interaction experience. The cross-device interaction control method provided in this application can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0062] In one exemplary embodiment, such as Figure 2 As shown, a cross-device interactive control method is provided, which can be applied to... Figure 1 Taking server 102 as an example, the following steps are included:

[0063] Step 202: Obtain the output rhythm control information corresponding to the target interaction process; the output rhythm control information includes the execution timing constraints for multiple optional output events in the target interaction process.

[0064] In this context, the target interaction process refers to a continuous human-computer interaction session that unfolds around a specific task objective and spans multiple devices or interfaces. This process begins with task initiation and ends with task completion or termination, forming a complete interactive context unit. Specifically, the interaction process can be a collaborative process between a user and a distributed interactive system composed of multiple devices / interfaces. Users can exchange information with the system through different terminals (such as mobile phones, tablets, and wearable devices) and application interfaces to achieve a common goal. For example, a user initiates a "home environment adjustment" task: first, they set the target temperature on a mobile app; then, they inquire about the current room temperature on a smart speaker; and finally, they view an energy consumption report on a tablet. This series of operations and feedbacks across different devices collectively constitutes the target interaction process. Each such process is identified and associated with a unique interaction process identifier (such as a session ID), ensuring that the system can distinguish and manage multiple independent sessions running simultaneously.

[0065] In multi-device collaborative scenarios, various interactive information (such as prompts, guidance, and feedback) needs to be output to users. Output rhythm refers to the patterns and characteristics of this information over time. This can include at least one of the following: the output order of different information, the time interval between adjacent information, the output frequency per unit time, and the allowed number of times a specific piece of information is output throughout the entire session. Understandably, output rhythm is a key factor affecting the consistency and smoothness of the user experience. Output rhythm control information is a predefined set of rules used to constrain and coordinate the aforementioned output rhythm. It should be noted that output rhythm control information may not contain specific interactive content, such as which content to output to the user during specific optional output events.

[0066] In complex interactive environments involving multiple devices and events, the lack of unified control over the output timing of user-facing information can easily lead to conflicting information. For example, if each device independently decides its output timing based on its local logic, it can result in duplicated information output (e.g., a confirmation message on a mobile device is replayed when switching to a tablet). It can also cause disordered output events (e.g., background information followed by operational instructions might be presented in reverse order due to varying device response speeds). Furthermore, it can lead to conflicting output rhythms (e.g., prompts are pushed forward quickly on mobile devices like smartphones for efficiency, while output is slower on wearable devices like watches due to performance or network limitations), resulting in inconsistent perceived information flow speeds for the user across different devices. These chaotic output rhythms severely disrupt the consistency of interaction, causing user confusion and reducing task completion efficiency. Therefore, in this embodiment, output timing rules are centrally controlled to ensure that even when multiple devices are running concurrently or switching, and a target interaction process flows across multiple devices and experiences multiple output events, the user still receives a unified, coherent, and conflict-free information reception experience. The output rhythm control information can be pre-configured statically by the interaction designer, or it can be dynamically generated or optimized by the algorithm based on historical interaction data. This application embodiment does not impose any restrictions on this.

[0067] It is important to clarify that the core of this application's embodiments lies in how to utilize existing "output rhythm control information" to achieve cross-device timing coordination and conflict resolution, without involving the generation method or optimization process of the control information itself. Whether the control information is statically configured, provided by an external system, or dynamically generated through other algorithms, it does not affect the execution of the coordination logic in this solution. Therefore, this application's embodiments are positioned as a coordination and control layer for cross-device consistent execution, functionally decoupled from the control information generation layer.

[0068] Optional output events refer to the smallest unit of output with independent interactive semantics that the system may present to the user during the target interaction process. Each output event represents a complete output action, such as a voice announcement, an interface pop-up, a vibration alert, or a visual highlight. It should be noted that, considering the user participation and openness of the target interaction process, the triggering timing of each optional output event can be uncertain. It may be triggered asynchronously by external user actions (such as clicking a button), fulfilling preset business conditions (such as data update completion), or timer events. Therefore, the system needs a mechanism to coordinate these output requests triggered at uncertain times.

[0069] Execution timing constraints define the temporal relationships and limitations between output events from multiple dimensions. They are multi-dimensional constraints that establish a deterministic, globally followed timing framework for uncertain triggering events. Specifically, the constraint type of execution timing constraints can include at least one of the following: sequence constraints, used to define the logical execution order of multiple output events. For example, specifying that the "operation confirmation prompt" must be output after the "operation guidance instructions" to ensure that the user understands before operating.

[0070] Time interval constraints define the minimum (or maximum) time interval that must be maintained between two related output events. For example, it can be specified that at least 3 seconds must pass after an "error warning" output before a "fix suggestion" can be output, giving the user time to react.

[0071] Frequency constraints define the upper limit on the number of similar or all events allowed to be output within a specific time window. For example, it can stipulate that "non-critical status reminders" can appear no more than once per minute to prevent information overload from disturbing the user.

[0072] Execution frequency constraints define the maximum number of times a specific output event is allowed to be executed during the entire interaction (usually once, i.e., a one-time event). For example, it might stipulate that a "welcome message" or "task completion summary" should only be broadcast once during the entire session. For instance, in an interactive parameter measurement process, timing constraints might stipulate that event A ("start measurement prompt") must be executed before event B ("measurement completion confirmation") (sequence constraint); event C ("preliminary results briefing") must be executed at least 5 seconds after event A is completed (time interval constraint); the total number of various prompt events output by the system within any one minute cannot exceed 3 (frequency constraint); and event D ("final analysis report") can only be successfully output once during the entire interaction (frequency constraint). Output rhythm control information can be stored as configuration files, database records, or in-memory policy objects for use in coordinating logic queries.

[0073] Step 204: Receive an execution request from the target device for the target output event; wherein the target device is at least one of a plurality of optional devices associated with the target interaction process; and the target output event is at least one of the plurality of optional output events.

[0074] In this context, device participation in the target interaction process can refer to an application instance or service on the device binding itself to a unique identifier (session ID) of the interaction process through registration, subscription, or establishing a connection with the central coordinator, declaring its willingness and ability to execute output events or respond to related instructions within the context of the session. Specifically, this participation relationship can be established when a user initiates a task through the device or actively migrates / shares an ongoing task session to the device. For example, a user first starts watching a movie on a smart TV (initiating the interaction process), and then remotely controls it through a mobile app. At this point, the mobile app participates in this "movie viewing control" interaction process as a new "optional device."

[0075] Given the flexible and mobile work and lifestyles of users in modern digital life, scenarios involving multiple devices in the same interactive process are common. Typical scenarios may include at least one of the following: parallel use, such as a user editing a document on a computer while simultaneously receiving relevant notifications and quick operation prompts on a smartwatch; continuous switching, such as a user listening to news on their phone during their commute and seamlessly transferring playback to a smart speaker via voice command upon arriving home; and collaborative complementarity, such as in health management where a body fat scale outputs measurement data, a mobile app displays detailed reports and trend charts, and a smartwatch provides real-time exercise reminders. In these scenarios, user interactions are distributed and dynamic, potentially involving input on different devices, triggering a series of logically related but physically dispersed output events across devices.

[0076] In this embodiment, optional devices maintain session associations via network or local communication protocols (such as Wi-Fi, Bluetooth, LAN, or cloud-based message queues). Maintaining this dynamic association allows a logically unified "interaction session" to transcend physical device boundaries, achieving state synchronization and instruction distribution, providing users with a continuous service experience. However, this cross-device capability brings new challenges to "output rhythm control": when a user or system switches from one device to another, if the newly added device is unaware of the session's output history, it may output information that is no longer appropriate in the current global timeline, driven by local logic. For example, a watch might trigger a "get up and move around" reminder after detecting that the user has been sitting for too long; however, the user may have just completed and confirmed a complete fitness guide on their mobile phone, making the watch's reminder abrupt and repetitive. Therefore, in this embodiment, the output rhythm during device switching (or more broadly, multi-device parallelism) is controlled to prevent this "out-of-control output" that violates global timeline logic due to information asymmetry.

[0077] Target output events are typically generated automatically by local business logic modules or event triggers on the target device when specific conditions are met. The triggering conditions for target output events can be varied, such as: sensor data reaching a threshold (e.g., high heart rate), timer expiration (e.g., alarm clock), receiving a server push notification, the user performing a specific interface operation, or the local state machine entering a phase requiring a user notification. Considering that the execution of the output event ultimately needs to be carried out by specific device hardware and software (e.g., screen display, speaker playback), the target device requests an output execution request. This execution request signifies that the device is ready and, from the target device's local perspective, considers the current moment an appropriate time for output.

[0078] However, this "appropriate timing" based on a local perspective may be "non-compliant" from a global perspective. The execution request's output rhythm may be non-compliant, specifically due to the following reasons: Information silos, such as device A executing a one-time event, but device B, due to network latency or lack of timely synchronization, is unaware and still triggers the event's output request based on outdated local state. Or, rhythm differences, such as device A having strong performance and a good network, resulting in a fast output rhythm; device B having weak performance and a poor network, resulting in a slow output rhythm. If each operates independently, the information flow presented to the user will feel disjointed. Device B might request the output of information that has already timed out in device A's "fast rhythm" during its "slow rhythm." Or, logical conflicts, such as user cross-operations on multiple devices, may trigger multiple output events with logical sequence requirements from different paths. Without coordination, this may lead to disordered order (e.g., a subsequent prompt appearing before an initial explanation).

[0079] For example, during home security interaction, when a door / window sensor is triggered, the security service module of the smart speaker (target device) installed indoors immediately generates an execution request containing the event identifier "ALERT_DOOR_OPEN," intending to play a voice warning, "An abnormal opening of the front door has been detected." This request will be sent to the coordination mechanism for arbitration. In summary, the execution request is an output intent originating locally on the device but potentially "pending review" from a global temporal perspective, providing specific pending matters for subsequent global coordination.

[0080] Step 206: Obtain the historical execution status of each of the other optional devices for the plurality of optional output events.

[0081] In determining the compliance of an output request, it's crucial to consider not only static timing rules but also, more importantly, what output events have actually occurred during the interaction. For example, determining whether an "operation confirmation prompt" can be output requires confirming whether its dependent "operation guidance instructions" have been output and completed. Therefore, it's necessary to understand what other "session partner" devices have performed, i.e., obtaining a global, historical output record. Specifically, to achieve truly effective cross-device output rhythm coordination, the device making the arbitration decision (which could be the target device itself or a central coordinator) cannot rely solely on its local information.

[0082] Unlike related technologies that synchronize the complete session context and historical data across all devices in real time, this application embodiment only synchronizes the metadata most relevant to the output timing decision (i.e., historical execution status). The historical execution status is essentially a lightweight, structured "event log" that records "what event", "on which device", and "when" it was completed.

[0083] This design separates the "control plane" from the "data plane": control logic (rhythm coordination) relies on streamlined metadata; while specific content presentation and interface rendering are handled independently by each device based on its own business logic and context. This reduces network and computing overhead, making it more suitable for mobile network environments. Furthermore, it eliminates the need to synchronize potentially sensitive user interaction details, allowing the output content generation logic to evolve independently, unconstrained by the rhythm coordination mechanism. Lightweight state synchronization can also be completed more quickly, supporting real-time rhythm decisions.

[0084] Specifically, historical execution data is a dynamically updated global state dataset that centrally or distributedly records the execution footprint of all optional output events across all associated devices during the current target interaction. Specifically, historical execution data may include: identifiers of executed output events, device identifiers that executed the events, and timestamps indicating completion of the output events. Obtaining historical execution data can be achieved through at least one of the following two modes: Querying a centralized state database: Maintaining a coordination server as a single source of truth, to which all devices report after executing outputs. When the target device (or coordinator) needs to make a decision, it sends a state query request to this server to obtain authoritative and up-to-date global historical records. This approach ensures strong data consistency and global uniqueness of decisions, making it a logically simple and reliable choice. It should be noted that the historical execution data in this embodiment does not include user input, business state details, or output content; it only includes minimal metadata for time-series verification, such as output event identifiers / device identifiers / completion timestamps. Alternatively, a synchronized distributed state replica can be used: Without a central node, each participating device maintains a local copy of its historical execution status. These copies are synchronized across devices using a pre-defined consensus protocol (such as vector clocks, CRDTs, or blockchain technology) to achieve state consistency. During decision-making, the target device can use its latest locally synchronized copy or quickly aggregate information from neighboring devices through lightweight peer-to-peer queries. This approach enhances decentralized fault tolerance and privacy. With minimal data overhead, it breaks down information barriers between devices, laying a solid factual foundation for subsequent rule-based intelligent arbitration, thereby accurately identifying and avoiding potential cross-device output conflicts.

[0085] Step 208: Based on the output rhythm control information and the historical execution status, determine whether the output timing of the target output event satisfies the execution timing constraint when responding to the execution request.

[0086] In complex multi-device parallel environments, if non-compliant output is actually presented to the user (e.g., repeated prompts or garbled pop-ups), it causes irreversible damage to the user experience. Therefore, in this embodiment, to avoid the output rhythm of the entire session violating pre-defined timing rules due to the assumption of immediate approval and execution of the target device's output request, a "compliance checkpoint" based on global rules and global state is introduced before the output behavior occurs. This aims to intercept all potential timing conflicts (such as repetition, out-of-order, and overclocking) before they occur, thereby ensuring that the interaction process is clear, consistent, and conforms to the design from the beginning. Specifically, the process of determining the constraint satisfaction can be a logical comparison and numerical calculation between dynamic facts (historical execution status) and static rules (execution timing constraints). The basic principle is: for each type of timing constraint involved in the target output event, check whether the current (after simulated output) global state satisfies all conditions of the constraint. Only when all relevant constraints are satisfied is the constraint finally determined to be satisfied.

[0087] Specifically, for an execution request awaiting adjudication, the following analysis can be performed: Extract all execution timing constraints related to the "target output event" from the output rhythm control information (e.g., which preceding events it depends on, when it has interval requirements, and whether it is subject to frequency or number of times limitations). Using the current historical execution status as a baseline, virtually add the result that "the target output event is completed by the target device at this moment" to form a "future state snapshot" for simulation. For each extracted constraint, verify it in this simulation state: check whether all "preceding output events" on which the target event depends have been marked as "completed" in the simulation state.

[0088] For example, if the rule stipulates that the "payment success notification" must be after the "payment confirmation operation," then the validation process needs to confirm that a "payment confirmation operation" completion record already exists in the historical execution data. Find the completion timestamp of the "preceding executed events" associated with the target event from the historical execution data, calculate the difference between this timestamp and the current time (simulated execution time), and determine if this difference is greater than or equal to the minimum interval required by the constraint. For example, if the rule stipulates that the "error notification" and "solution notification" must be at least 2 seconds apart, then the difference between the current time and the completion time of the most recent "error notification" needs to be calculated. In simulation mode, count the total number of all executed output events (including the simulated event) within the time window defined by the constraint (e.g., the most recent 1 minute), and determine if this total exceeds the constraint limit. For example, if it stipulates that "status notifications" cannot exceed 2 times per minute, then it needs to count how many "status notifications" have been executed in the current minute.

[0089] In simulation mode, the system counts the total number of times the target output event is executed throughout the entire session history (including the current simulation) to determine if the maximum allowed number (usually one) has been exceeded. For example, if a "welcome message" can only appear once, it checks if a "welcome message" record already exists in the history. Finally, the results of the above item-by-item checks are combined. If all checks pass, the "constraint satisfaction" is determined to be "satisfied". If any check fails, the "constraint satisfaction" is determined to be "unsatisfied", and this is usually associated with a specific type of constraint violation (such as "violation of sequence constraint" or "violation of frequency constraint"). This results in a clear, binary (or typed) compliance label, such as "satisfied" or "unsatisfied (reason: preceding event X was not completed)". This label provides a precise and interpretable basis for subsequent control actions. Through this rigorous logical comparison and calculation, the system incorporates uncertain, asynchronous device output requests into a deterministic, globally controllable timing framework.

[0090] It should be noted that the compliance judgments based on "whether the preceding output event is completed," "whether the time interval is met," "whether the frequency exceeds the limit," and "whether the number of times exceeds the limit" are temporal reviews of the sequence of output events that have occurred and those that are yet to occur. They are independent of the business logic rules that drive the evolution of session content or the transition of business states. For example, in this application embodiment, the determination of whether an "operation confirmation prompt" can be output is based on whether the "operation guidance instructions" on which it depends have been output (output timing compliance), rather than determining whether the user has understood the content or whether the session meets the conditions for entering the next business stage (session state transition).

[0091] Therefore, the embodiments of this application are output timing arbitrators located in the interactive presentation layer, rather than state transition controllers in the business logic layer.

[0092] Step 210: Control the execution timing of the target output event on the target device according to the constraint satisfaction status.

[0093] The constraint satisfaction criteria serve as a basis for decisions made from the perspective of maintaining global temporal consistency and logical correctness throughout the multi-device interaction process. When the determination result is "satisfied," it means that the output request is approved (i.e., responded to and processed), without disrupting the established output rhythm framework. This ensures the correct causal order of information in cross-device interactions (users see the premise first, then the subsequent events), appropriate timing (moderate information density, allowing users time to process), and uniqueness of events (key prompts are not repeated or disruptive). Conversely, if the determination is "unsatisfied" but a response is still made, it will directly lead to the aforementioned "rhythm conflict" problem. For example, a reversal of the logical order will confuse users; excessively frequent output will create information overload, drowning out important information; and repetitive output will reduce the system's professionalism and waste user attention.

[0094] Specifically, if the constraint satisfaction condition is represented as "satisfied," it indicates that the output is safe from a timing compliance perspective. Therefore, an execution request is responded to. The specific response method could be sending an "execution allowed" instruction to the target device, or directly triggering execution logic, causing the target device to execute the target output event at the current moment. After execution, a crucial post-processing operation is to update the historical execution status. For example, a new execution record is reported to the coordination server, or an "execution completion notification" is broadcast to other devices via a distributed synchronization protocol (this notification at least includes the identifier of the target output event, the identifier of the target device, and the execution completion timestamp). By updating the historical execution status, the global state is kept synchronized with the actual situation, enabling subsequent output requests from other devices to be judged for compliance based on the latest history containing the current event, thereby maintaining the continuity and correctness of the decision-making chain.

[0095] Correspondingly, a constraint satisfaction condition is represented as "non-satisfied," meaning that executing the target output event immediately on the target device would result in a timing conflict. Therefore, proactive timing conflict resolution operations can be implemented for this execution request. This is an intelligent control strategy designed to resolve conflicts and achieve the final output as much as possible, rather than simply discarding the request. Timing conflict resolution strategies can include delaying or skipping operations. For example, the earliest feasible future time point (target time) that satisfies all relevant constraints can be calculated. For instance, for a request that violates a time interval constraint, the target time = the completion timestamp of the preceding event + the required minimum interval.

[0096] The system then reschedules the output request to the target time for re-triggering, or sets a timer to wake up at the target time and resubmit the request for adjudication. This is equivalent to telling the device, "Output cannot be output now; please try again at X o'clock and X minutes." Alternatively, it can directly abort the response to the current execution request and abandon the current output. This is mainly applicable to scenarios that violate "execution count constraints" (such as a one-time event already executed by another device) or certain strict "sequence constraints" (and have no subsequent scheduling significance). For example, when the watch is about to output a "welcome message," if the system finds that the mobile device has already output it at the start of the session, it will skip the watch's output to avoid duplication.

[0097] This application embodiment decouples and centrally coordinates the timing control logic (output rhythm control information) with the global execution state (historical execution status), providing a lightweight and scalable control rhythm coordination mechanism for the output behavior in a multi-device system, effectively solving the problem of rhythm conflicts caused by the independent output of each device in related technologies.

[0098] It should be noted that the cross-device interaction control method, apparatus, and related products provided in this application focus on the timing coordination and control of interactive output events in a cross-device environment. Specifically, this application only addresses the coordination of "when, in what order, and at what frequency" the output of interactive information, and does not involve the specific content of the output information, health judgments of user behavior, intervention decisions, or any form of medical diagnosis and treatment. This application does not generate, interpret, or rely on any decision logic related to user physiological health or behavioral pattern judgments; its functional boundaries are strictly limited to the compliance arbitration and conflict resolution of the output timing.

[0099] In some embodiments, the optional output events represent the smallest interactive unit with independent interactive semantics; the output rhythm control information is associated with and stored in conjunction with the interactive process identifier of the target interactive process; the optional devices include different types of terminals and different application instances running within the same terminal; the execution timing constraints include execution order constraints among the plurality of optional output events;

[0100] The step of determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraints in response to the execution request, includes:

[0101] Based on the execution order constraint, determine the preceding output event associated with the target output event from the plurality of optional output events;

[0102] Based on the historical execution status, determine whether the preceding output event has been completed, and obtain the first determination result;

[0103] The constraint satisfaction status is determined based on the first judgment result; wherein, if the preceding output event has been completed, it is determined that the output timing of the target output event satisfies the execution order constraint in response to the execution request.

[0104] In the context of sequence constraints, each optional output event is a logically complete "step" or "information block," and the sequence constraints manage the sequential relationship between these units. For example, "Step 1: Introduce Function A," "Step 2: Demonstrate Operation B," and "Step 3: Request Confirmation C" are each independent units. The timing rules (including sequence constraints) defined for a specific interaction process (such as "User Zhang San's smart home setup session") are indexed and retrieved using the session's unique interaction process identifier (e.g., session_id: zhangsan_home_setup_20231027). This ensures that the rhythm control rules between concurrent sessions of different users or different task sessions of the same user are isolated and do not interfere with each other. Optional devices include different types of terminals and different application instances within the same terminal. Therefore, the coordination of sequence constraints not only occurs between different types of physical terminals such as mobile phones, watches, and TVs, but may also occur between multiple application or service instances running within the same terminal. For example, on a mobile phone, there may be a need to coordinate the output order between a notification pop-up from the system notification center (application instance A) and a guide pop-up from the currently foreground app (application instance B).

[0105] First, we need to prepare for the sequence validation by identifying which "precondition" events the output event to be validated (the target output event) depends on in the global event sequence. Execution sequence constraints can exist in the form of a dependency graph or a rule list. Specifically, we can obtain the corresponding output rhythm control information through the identifier of the target interaction process. From this, we can parse the sequence constraint rules associated with the "target output event identifier." This rule indicates that the output of the target event requires the completion of one or more specified preceding output events as a prerequisite. For example, in a cross-device workflow, the rule might stipulate that the output "Start next meeting reminder" (target event) on the smartwatch can only be executed after the output "Current topic summary ended" (preceding event A) on the smart screen in the meeting room. Based on this, we can locate event A from all available output events as the specific preceding event that needs to be considered in this validation.

[0106] Then, query the historical execution dataset associated with the interaction process identifier. For each preceding output event (such as preceding event A) in the aforementioned steps, search the dataset to check if there is a corresponding execution record. If the "event identifier" of the record matches the preceding event, and its "execution status" or the existence of the record itself indicates that the event has been completed (usually, the existence of an "execution completion timestamp" indicates completion).

[0107] Specifically, if all specified preceding output events have corresponding completion records retrieved in the historical execution records, the first judgment result is "all preceding events have been completed". If at least one specified preceding output event has not had a completion record retrieved in the historical execution records, the first judgment result is "a preceding event has not been completed". Continuing with the previous example, suppose a record is found in the historical execution records showing that "the current topic summary has ended" was completed on the smart screen in the conference room (device identifier: ConfRoom-Screen-01) at 14:29:30.

[0108] Therefore, for the target event "Start the next meeting reminder," the first judgment result is "All preceding events have been completed." Finally, only when all logically preceding steps are actually completed is the output of subsequent steps compliant in terms of timing. If the first judgment result is "All preceding events have been completed," it indicates that all prerequisites for outputting the target event have been met, and its output will not disrupt the logical order of events. Therefore, it can be determined that responding to the execution request and outputting the target event at this time satisfies the execution order constraint. The entire judgment process ends, and the constraint satisfaction status will include the conclusion "Sequence constraint passed."

[0109] Correspondingly, if the first judgment result is "there is an incomplete preceding event," it indicates that there is a gap in the logical chain, and outputting the target event will result in "order disorder." Therefore, the system determines that responding to the execution request and outputting the target event at this time will not satisfy the execution order constraint. The constraint satisfaction will be marked as "not satisfied," and may be accompanied by specific information such as "Reason: violation of order constraint, preceding event X is incomplete."

[0110] This application's embodiments transform abstract sequence constraint rules into precise, automatically executable verification logic, ensuring a globally consistent logical output sequence is maintained regardless of the device or application from which the output request originates, even in complex environments with multiple devices and application instances. This prevents issues such as skipped guidance steps and inverted prompt logic that could disrupt the continuity of the user experience due to differences in device capabilities, network latency, or cross-device user operations. It allows the distributed interaction process to proceed in an orderly and causally correct manner, much like a single-threaded program.

[0111] In some embodiments, the execution timing constraint includes an execution time interval constraint for the target output event; determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraint in response to the execution request includes:

[0112] Determine the execution completion timestamp of the preceding output event associated with the target output event based on the historical execution data;

[0113] Calculate the time difference between the current time and the execution completion timestamp, and compare the time difference with the minimum interval threshold required by the execution time interval constraint to obtain the comparison result;

[0114] The constraint satisfaction status is determined based on the comparison result; wherein, if the time difference is greater than or equal to the minimum interval threshold, it is determined that the output timing of the target output event satisfies the execution time interval constraint in response to the execution request.

[0115] To control the pace of interaction and ensure a buffer for user cognition, this application introduces an execution time interval constraint. This constraint defines the minimum (or sometimes maximum) time interval between two related output events. The execution time interval constraint is typically tied to a specific pair of output events. For example, it might stipulate that the output interval between an "error warning" event and the immediately following "fix suggestion" event must not be less than 3 seconds. This prevents information output from being too dense, causing users to be unable to process it (too short an interval), or avoids overly slow responses in scenarios requiring tight feedback (too long an interval). This application primarily focuses on the most common minimum interval constraint. Specifically, to determine whether the current output is "too early," it is necessary to first find the "preceding event" that serves as a time reference and its precise completion time. First, determine which "preceding output event" the time interval constraint is associated with for the current target output event. This information comes from the definition of the time interval constraint in the output pace control information. For example, a rule might explicitly state: "The event 'Operation Result Brief' needs to be output at least 5 seconds after the event 'Data Submission Confirmation' is completed." Then, "Data Submission Confirmation" is the associated preceding event. The historical execution dataset is then queried. Based on the identifier of the preceding event, the corresponding execution record is retrieved, and the execution completion timestamp is extracted from it. This timestamp serves as the reference point for calculating the time difference.

[0116] Furthermore, to quantify the time elapsed since the completion of the last related event and determine whether this period has met the minimum waiting period required by the rules, the system's current time (i.e., the simulated moment when the planned response to the execution request is immediately output) is obtained. This time is subtracted from the execution completion timestamp obtained in the previous step to obtain the time difference (ΔT) in seconds (or milliseconds). ΔT = Current time - Previous event completion time. The minimum interval threshold (T_min) defined for this event pair is read from the output rhythm control information. For example, T_min = 5 seconds. Then, a logical comparison is performed: it is determined whether ΔT ≥ T_min. If ΔT ≥ T_min, it indicates that more than or equal to the required minimum interval time has elapsed since the completion of the previous event. In this case, the comparison result can be marked as "Minimum interval requirement met". Conversely, if ΔT < T_min, it indicates that the elapsed time since the completion of the previous event is less than the required minimum interval. In this case, the comparison result can be marked as "Minimum interval requirement not met".

[0117] For example: Suppose the rule stipulates that a "system notification" must be output at least 2 seconds after the "user login successful" event. The history shows that "user login successful" was completed at 12:00:00. Currently, the watch device triggers a "system notification" output request at 12:00:01. The calculated ΔT = 1 second, which is less than T_min (2 seconds). Therefore, the comparison result is "minimum interval requirement not met".

[0118] If the comparison result is "Minimum interval requirement met": This indicates that immediately outputting the target event is compliant in terms of timing, providing the user with sufficient buffer or waiting time. Therefore, responding to the execution request at this time ensures that the output timing of the target event meets the execution time interval constraint. If the comparison result is "Minimum interval requirement not met": This indicates that immediate output would be too rushed, violating the preset timing rules. Therefore, responding to the execution request at this time does not ensure that the output timing of the target event meets the execution time interval constraint. Constraint satisfaction will be marked as "Not satisfied," usually accompanied by detailed information such as "Reason: Violation of time interval constraint, X seconds remaining."

[0119] This application's embodiments transform time interval constraints into precisely measurable timing control logic, enabling fine-grained management of the rhythm density of output events. This effectively avoids issues such as a single device responding too quickly and "crowding out" user processing time in multi-device parallel scenarios, or information flow fluctuating due to network timing differences. By enforcing reasonable time intervals, it ensures a smooth interaction, guaranteeing users sufficient time to understand and respond to preceding information, thereby improving the overall comfort and usability of cross-device interaction.

[0120] In some embodiments, the execution timing constraint includes an execution frequency constraint for the target output event; determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraint in response to the execution request includes:

[0121] Based on the historical execution data, the total number of times the optional output events have been executed within the unit time window defined by the execution frequency constraint to which the current time belongs is counted.

[0122] Determine whether the total number of executions is less than the maximum number of executions defined by the execution frequency constraint to obtain a second determination result;

[0123] Based on the second judgment result, the constraint satisfaction status is determined; wherein, if the total number is less than the maximum execution number, it is determined that, in response to the execution request, the output timing of the target output event satisfies the execution frequency constraint.

[0124] To prevent information overload and avoid "information bombardment," this application introduces an execution frequency constraint, which defines the upper limit of the number of (same type or all) events allowed to be output within a specified unit time window. Under this constraint, the output density of the target output event at the current moment is judged for compliance based on historical execution data.

[0125] Specifically, the specific constraint parameters for execution frequency constraints can include: time window length (e.g., "per minute," "per 10 seconds") and maximum allowed execution count (e.g., "no more than 3 times"). These parameters constrain the overall density of output events per unit time at the system level, ensuring the information flow is presented at a user-acceptable, non-intrusive pace. This better manages non-critical status reminders and periodic update notifications, avoiding a decline in user experience due to short-term, high-frequency triggering. Specifically, the process based on frequency constraint judgment can include: determining whether the current output will cause "overclocking," and counting how many outputs have occurred in the most recent time period matching the constraint definition. Obtaining the unit time window defined by the frequency constraint from the output rhythm control information. For example, if the constraint is "status reminders no more than 2 times per minute," then the time window length is 60 seconds. Using the current time (planned execution time) as the end point of the window, calculating the start time point of the window backwards.

[0126] Within this sliding time window, the system queries the historical execution dataset. Depending on the granularity of the constraints, the target of the statistics may be all types of optional output events (global frequency limit) or events of a specific type or identifier (local frequency limit). The system counts the total number (N_historical) of output event records that meet the conditions within this window. For example, assuming the current time is 14:30:45, and the frequency constraint is "all prompt-type events no more than 5 times per minute," then the statistics window is from 14:29:45 to 14:30:45. The system counts the total number of execution records in the historical records within this time period that have the event type "prompt."

[0127] Next, compare the historical occurrence count with the upper limit allowed by the rules to determine if there is still "quota" available in the current window. First, read the maximum number of executions (N_max) defined by the frequency constraint from the output rhythm control information. For example, N_max = 5. Check if N_historical < N_max. If N_historical < N_max, it means that the number of executions within the current time window has not yet reached the specified upper limit, and there is still "output quota" remaining in the window. In this case, the second judgment result is "not overclocked, there is still margin". If N_historical ≥ N_max, it means that the number of executions within the current time window has reached or exceeded the specified upper limit. In this case, the second judgment result is "overclocked or no margin". Continuing with the previous example: Suppose that within the window from 14:29:45 to 14:30:45, the historical record shows that the "prompt" event has been executed 4 times. N_historical = 4, which is less than N_max = 5. Therefore, the second judgment result is "not overclocked, there is still margin".

[0128] If the second judgment result is "Not overclocked, still has margin": This means that immediately executing the target output event will not cause the total number of events within the current time window to exceed the limit, meeting the density control requirements. Therefore, the system determines that responding to the execution request at this time will ensure that the output timing of the target output event meets the execution frequency constraint. If the second judgment result is "Overclocked or no margin": This means that the output density of the current time window is saturated, and immediate execution will violate the frequency limit. Therefore, the system determines that responding to the execution request at this time will not ensure that the output timing of the target output event meets the execution frequency constraint. Constraint satisfaction will be marked as "Not satisfied," usually accompanied by detailed information such as "Reason: Violation of frequency constraint, current window has reached its limit." The system may then trigger conflict resolution operations, such as delaying the current output until after the current time window ends.

[0129] This application's embodiments transform frequency constraints into dynamically computable flow control logic. This enables the system to perform real-time "throttling" control on the output streams generated concurrently by multiple devices, using a sliding time window as the granularity. This effectively prevents the problem of multiple devices triggering outputs almost simultaneously due to independently detecting the same or different conditions in parallel scenarios, thus avoiding the problem of users being "overwhelmed" by a large amount of information in a very short time.

[0130] In some embodiments, the execution timing constraint includes an execution count constraint for the target output event; determining whether the execution request satisfies the execution timing constraint based on the output rhythm control information and the historical execution status includes:

[0131] Based on the historical execution data, the number of times the target output event has been executed during the target interaction process is counted.

[0132] Determine whether the number of executions is less than the maximum number defined by the execution count constraint to obtain a third determination result;

[0133] Based on the third judgment result, the constraint satisfaction status is determined; wherein, if the number of executions is less than the maximum number of executions, it is determined that, in response to the execution request, the output timing of the target output event satisfies the execution count constraint.

[0134] To ensure the uniqueness of the output actions of key events and prevent duplicate interference, this application introduces an execution count constraint. The execution count constraint is used to constrain whether a specific output event has reached its allowed execution limit during the entire interaction process. Specifically, the execution count constraint can define the maximum number of times a specific output event is allowed to be successfully executed during the entire target interaction process (e.g., it can be 1 time, i.e., a one-time event that is only output once).

[0135] In the embodiments of this application, the execution count constraint can be strongly bound to a specific output event identifier, such as "welcome message", "task completion summary", "first use guide", etc., thereby ensuring that certain outputs with special meaning or only valid at a specific stage of the session will not be unintentionally or incorrectly repeated to the user, which is conducive to maintaining the seriousness of the interaction, avoiding redundant information and achieving clear state progression.

[0136] The specific process for determining the execution count constraint may include the following: Query the historical execution dataset corresponding to the target interaction process (associated through the interaction process identifier). Filter this dataset to find all execution records where the "event identifier" exactly matches the current "target output event" identifier. Then, count the number of these matching records. This number (N_executed) represents the number of times the event has been executed in this session. The scope of the count is the entire session history, not limited by a time window, because the execution count constraint is applied to the session lifecycle.

[0137] For example, in the "Smart Home Device Network Configuration" interaction process, the target output event is "Network configuration successful notification".

[0138] Querying the historical records reveals two records with the event identifier "NETWORK_SETUP_SUCCESS", executed by the mobile app and smart speaker earlier, respectively. Therefore, N_executed = 2. From the output rhythm control information, the maximum allowed execution count (N_max) for this target output event is read. For most one-time events, N_max = 1. A judgment is made: Is N_executed < N_max true? If N_executed < N_max, it indicates that the number of times the event has been executed in the current session has not yet reached the allowed limit. In this case, the third judgment result is "not exceeded, execution allowed". Conversely, if N_executed ≥ N_max, it indicates that the number of times the event has been executed in the current session has reached or exceeded the allowed limit. In this case, the third judgment result is "exceeded, execution prohibited". Continuing with the previous example, suppose the rule stipulates that "network configuration success notification" is executed a maximum of 1 time in the entire network configuration session (N_max = 1). However, historical statistics show that it has been executed 2 times (N_executed = 2). Since N_executed (2) ≥ N_max (1), the third judgment result is "execution has exceeded the limit, execution is prohibited".

[0139] If the third judgment result is "Not exceeded, execution allowed": This means that executing the target output event this time will not cause the total number of executions of the event in the entire session to exceed the limit. Therefore, responding to the execution request at this time ensures that the output sequence of the target output event satisfies the execution count constraint. If the third judgment result is "Exceeded, execution prohibited": This means that the event has reached the execution count limit in this session, and any further execution request would be redundant and violate the rules. Therefore, responding to the execution request at this time ensures that the output sequence of the target output event does not satisfy the execution count constraint. Constraint satisfaction will be explicitly marked as "Not satisfied," with detailed information such as "Reason: Violation of the count constraint; this event is a one-time event and has already been completed." This usually leads to a "skip operation" in the conflict resolution process, directly abandoning this output.

[0140] This application's embodiments transform the frequency constraint into a rigorous check logic for the global state of the session. This enables the system to accurately identify and prevent repeated output requests for "one-time events," especially in scenarios involving multiple devices. For example, when a user completes a crucial step on their mobile phone and receives a confirmation prompt, even if they subsequently switch to a tablet, it prevents the tablet from outputting the same prompt again due to outdated local state. This completely solves the persistent problem of "repeated broadcasts" common when switching between devices, ensuring the authority and uniqueness of critical information output.

[0141] In some embodiments, controlling the execution timing of the target output event on the target device according to the constraint satisfaction includes:

[0142] If the constraint satisfaction condition indicates that the execution timing constraint is satisfied, the execution request is responded to so that the target device currently executes the target output event, and the historical execution status is updated after the target output event is executed;

[0143] If the constraint satisfaction condition indicates that the execution timing constraint is not satisfied, a timing conflict resolution operation is performed on the execution request; wherein, the timing conflict resolution operation includes a delay operation or a skip operation; the delay operation is used to postpone the response to the execution request until the target time that satisfies the execution timing constraint; the skip operation is used to abort the response to the execution request.

[0144] For time-compliant output requests, the goal is to execute the output securely and promptly, and synchronously update the global state to provide the latest factual basis for subsequent decisions. Specifically, when the constraint satisfaction condition is "satisfied," the execution request will be approved. This can be achieved by sending an explicit "execution permission" instruction to the target device, or by directly triggering the output logic that has been suspended on the device. The result is that the target device begins and completes the presentation of the target output event at the current moment (or within a very short acceptable delay), such as playing audio, displaying a pop-up window, or triggering vibration. Correspondingly, after the output execution is completed, the historical execution status is updated, thereby maintaining the consistency of the global state of the output event execution status. Optionally, in a centralized architecture, the target device (or its agent) sends an execution completion notification to the coordination server. This notification may include: an interaction process identifier, a target output event identifier, a target device identifier, and a precise execution completion timestamp. The server appends this record to the historical execution data set of the session.

[0145] Optionally, in a distributed architecture, the target device broadcasts the aforementioned execution completion notification to all other optional devices in the session via a pre-defined distributed synchronization protocol (such as broadcast, multicast, or consensus-based log replication). Upon receiving the notification, each device adds this record to its locally maintained copy of the historical execution data. This branch ensures smooth compliant output and an uninterrupted user experience. Simultaneously, by updating the historical execution data in real time, the system implements a "feedforward" state mechanism. This allows any subsequent output request from any device to be judged based on the latest and most complete global history containing the current event, thereby ensuring the continued correctness of the entire coordination chain and avoiding a new round of decision-making errors caused by delayed state updates.

[0146] Correspondingly, for output requests that violate timing rules, unlike direct rejection, this embodiment adopts the most appropriate strategy based on the type of violation to intelligently resolve conflicts and maintain timing rules with minimal user experience overhead. Specifically, after a timing violation is determined, at least one of the following timing conflict resolution operations is triggered, where timing delay operations mainly target violations of time interval constraints (output too early) or frequency constraints (current window is full). These violations are usually temporal rather than logical errors. Their execution may include calculating a future target time that satisfies all relevant constraints.

[0147] For example, for interval constraints, the target time = the completion timestamp of the preceding event + the minimum interval requirement; for frequency constraints, the target time = the end time of the current time window. Subsequently, the system reschedules the current output request to the target time. This can be achieved by setting a timer to automatically re-trigger the original execution request at the target time, or by placing it in a delayed execution queue. It is understood that in this embodiment, the delayed operation means "not now, but perhaps later." It preserves the output intent, only adjusting the timing of its occurrence; it is a non-destructive conflict resolution method suitable for most violations caused by untimely timing.

[0148] Optionally, the timing conflict resolution operation may also include a skip operation. Skip operations primarily target violations of execution count constraints (one-time events have been executed) or certain absolute order constraints (and have no further execution significance). These violations are usually logical, meaning that the output event has lost its meaning in the current session context or should not occur again. Skip operations can be executed by directly aborting the response to the current execution request, discarding the current output, and not scheduling any future retries. The execution request is silently discarded or marked as "skipped." It is understood that a skip operation means "it is not needed this time or in the future." As a final conflict resolution method, it is used to handle redundant and unnecessary output requests and is a core means of avoiding information duplication.

[0149] For example, when the watch attempts to output a "welcome message," the system detects that the phone has already output it (violating the frequency constraint), so it skips the message. If the tablet immediately attempts to output a "detailed solution" immediately after the phone completes an "error report" (violating the time interval constraint), the system calculates the time point after 2 seconds and performs a delay. Through intelligent mitigation strategies, potentially poor user experiences (conflicts occurring) are transformed into controlled and predictable system behavior (delay or silence). Users will not experience confusion or repetition; they will only perceive a smooth and logical system output rhythm. This demonstrates the system's proactive management capabilities in complex multi-device environments.

[0150] This application embodiment translates the abstract goal of "rhythm consistency" into controllable behavior for each specific output event, ensuring that in a dynamic environment of multi-device concurrency and switching, the output performance of the entire system can be like a single, coordinated entity, always providing users with a consistent, clear, and conflict-free interactive experience, fundamentally solving the rhythm coordination problem of distributed output systems.

[0151] In summary, the embodiments of this application implement a pure "output pipeline" coordination mechanism. Its input is the output execution requests asynchronously generated by each device, and its output is an arbitration instruction for these requests to "allow execution," "delay execution," or "skip execution." It does not contain or rely on any business logic decisions (such as judging user health status, recommending the next step, or generating guidance content). Therefore, the embodiments of this application can be widely applied to any scenario requiring cross-device output timing coordination (such as multi-screen workflows, smart home security reminders, conference system prompts, device network configuration guidance, etc.). Its versatility is independent of business domains, and it is specifically not applicable to fields requiring professional judgment, such as medical diagnosis, health intervention, or behavior regulation.

[0152] In some embodiments, the historical execution data is stored on a coordination server or distributed locally on each of the optional devices; obtaining the historical execution data of the other optional devices for the plurality of optional output events includes:

[0153] The target device sends a status query request to the coordination server to obtain the historical execution status.

[0154] Alternatively, the target device may query other optional devices according to a preset consensus protocol to obtain the historical execution status;

[0155] The step of controlling the target device to execute the target output event if the constraint is satisfied indicates that the execution timing constraint is met, and updating the historical execution status after the target output event is executed includes:

[0156] In response to the completion of the target output event on the target device, an execution completion notification for the target output event is generated; the execution completion notification includes at least one of the identifier of the target output event, the identifier of the target device, and an execution completion timestamp;

[0157] The execution completion notification is sent to the coordination server, or broadcast to other optional devices via a distributed synchronization protocol to update the historical execution status.

[0158] In this application, historical execution data serves as the factual basis for all time-series compliance judgments. The embodiments of this application introduce two physical storage and synchronization modes for historical execution data: centralized storage on a coordination server and distributed storage on each selectable device. These two modes represent classic trade-offs in different dimensions such as data consistency, system complexity, fault tolerance, and privacy.

[0159] Specifically, after each participating device completes any output event locally, it must immediately (or within an agreed-upon delay) send an execution completion notification to the pre-defined coordination server. The coordination server receives and persistently stores these notifications, organizing them into a complete, time-series historical execution record based on the interaction process identifier. When any target device needs to make an output decision, it initiates a status query request to the coordination server. This request carries the interaction process identifier for the current session. Upon receiving the request, the coordination server retrieves all historical execution records corresponding to that session from the database and returns them to the target device. Because all reads and writes pass through a single node, the data exhibits strong consistency, and the decision-making basis is authoritative and unambiguous. Furthermore, devices do not require complex peer-to-peer synchronization logic; they only need to communicate with the central server, reducing client complexity. This model is well-suited for scenarios with extremely high consistency requirements, stable device networks, and a reliable central service.

[0160] Optionally, each device can also maintain a local copy of the historical execution of this interaction process. When a device finishes executing an output event, it does not report it to the center. Instead, it broadcasts or synchronizes this new record to other devices in the session through a pre-defined consensus protocol (e.g., CRDT based on operation transformation, version vector, or blockchain light node synchronization in a trusted environment). All devices use the protocol algorithm to ensure that all copies ultimately contain the same, ordered event records.

[0161] Correspondingly, when the target device needs to make a decision, it can directly query its own locally synchronized latest copy (if the protocol guarantees that reading and writing locally is the latest). Alternatively, when stronger consistency guarantees are required, it can send peer queries to multiple other devices, collect responses, and aggregate or verify an authoritative global view according to protocol rules (such as comparing version numbers or retrieving the latest). In this mode, the records of output events are directly synchronized between devices without passing through a third-party server, making it suitable for privacy-sensitive scenarios, scenarios with variable network topologies (such as local area networks only), or edge computing scenarios requiring high robustness.

[0162] In the aforementioned centralized architecture, the responsibility for state updates rests with the device that has completed its task. The device generates a notification containing core metadata and sends it peer-to-peer to the coordination server. The server then appends this as an immutable new record to the session's history log. This operation is a prerequisite for all subsequent devices to access the latest history.

[0163] Correspondingly, in the aforementioned distributed architecture, the responsible party for state updates is also the device that has completed the execution, but the recipients are all peer devices. After generating a notification, the device broadcasts it to all known peer devices in the session via multicast, broadcast, or flooding in the overlay network. Each peer device receives, verifies, and merges this notification into its local copy according to the consensus protocol. Through the guarantee of the protocol, all copies eventually converge to consistency.

[0164] This application provides flexible and robust infrastructure support for the cross-device rhythm coordination mechanism of the present invention by defining two complementary global state management paradigms. The centralized mode is characterized by simplicity and strong consistency, while the distributed mode is characterized by resilience and privacy protection. Regardless of the mode adopted, the core is to ensure that the key dataset of "historical execution status" can be shared reliably and timely among all decision nodes, so that the timing compliance judgment based on this data can be executed accurately and consistently throughout the distributed system.

[0165] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to 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 flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0166] Based on the same inventive concept, this application also provides a cross-device interaction control device for implementing the cross-device interaction control method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more cross-device interaction control device embodiments provided below can be found in the limitations of the cross-device interaction control method described above, and will not be repeated here.

[0167] In one exemplary embodiment, such as Figure 3 As shown, a cross-device interactive control device 300 is provided, including:

[0168] The first acquisition module 302 is used to acquire output rhythm control information corresponding to the target interaction process; the output rhythm control information includes execution timing constraints for multiple optional output events in the target interaction process;

[0169] The receiving module 304 is configured to receive an execution request from the target device for a target output event; wherein the target device is at least one of a plurality of optional devices associated with the target interaction process; and the target output event is at least one of the plurality of optional output events.

[0170] The second acquisition module 306 is used to acquire the historical execution status of each of the other optional devices for the plurality of optional output events;

[0171] The determining module 308 is used to determine, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the constraint of the execution timing constraint in response to the execution request.

[0172] The control module 310 is used to control the execution timing of the target output event on the target device according to the constraint satisfaction status.

[0173] In some embodiments, the optional output events represent the smallest interactive unit with independent interactive semantics; the output rhythm control information is associated with and stored in association with the interaction process identifier of the target interactive process; the optional devices include different types of terminals and different application instances running within the same terminal; the execution timing constraints include execution order constraints among the plurality of optional output events; the determining module 308 is further configured to:

[0174] Based on the execution order constraint, determine the preceding output event associated with the target output event from the plurality of optional output events;

[0175] Based on the historical execution status, determine whether the preceding output event has been completed, and obtain the first determination result;

[0176] The constraint satisfaction status is determined based on the first judgment result; wherein, if the preceding output event has been completed, it is determined that the output timing of the target output event satisfies the execution order constraint in response to the execution request.

[0177] In some embodiments, the execution timing constraint includes an execution time interval constraint for the target output event; the determining module 308 is further configured to:

[0178] Determine the execution completion timestamp of the preceding output event associated with the target output event based on the historical execution data;

[0179] Calculate the time difference between the current time and the execution completion timestamp, and compare the time difference with the minimum interval threshold required by the execution time interval constraint to obtain the comparison result;

[0180] The constraint satisfaction status is determined based on the comparison result; wherein, if the time difference is greater than or equal to the minimum interval threshold, it is determined that the output timing of the target output event satisfies the execution time interval constraint in response to the execution request.

[0181] In some embodiments, the execution timing constraint includes an execution frequency constraint for the target output event; the determining module 308 is further configured to:

[0182] Based on the historical execution data, the total number of times the optional output events have been executed within the unit time window defined by the execution frequency constraint to which the current time belongs is counted.

[0183] Determine whether the total number of executions is less than the maximum number of executions defined by the execution frequency constraint to obtain a second determination result;

[0184] Based on the second judgment result, the constraint satisfaction status is determined; wherein, if the total number is less than the maximum execution number, it is determined that, in response to the execution request, the output timing of the target output event satisfies the execution frequency constraint.

[0185] In some embodiments, the execution timing constraint includes an execution count constraint for the target output event; the determining module 308 is further configured to:

[0186] Based on the historical execution data, the number of times the target output event has been executed during the target interaction process is counted.

[0187] Determine whether the number of executions is less than the maximum number defined by the execution count constraint to obtain a third determination result;

[0188] Based on the third judgment result, the constraint satisfaction status is determined; wherein, if the number of executions is less than the maximum number of executions, it is determined that, in response to the execution request, the output timing of the target output event satisfies the execution count constraint.

[0189] In some embodiments, the control module 310 is further configured to:

[0190] If the constraint satisfaction condition indicates that the execution timing constraint is satisfied, the execution request is responded to so that the target device currently executes the target output event, and the historical execution status is updated after the target output event is executed;

[0191] If the constraint satisfaction condition indicates that the execution timing constraint is not satisfied, a timing conflict resolution operation is performed on the execution request; wherein, the timing conflict resolution operation includes a delay operation or a skip operation; the delay operation is used to postpone the response to the execution request until the target time that satisfies the execution timing constraint; the skip operation is used to abort the response to the execution request.

[0192] In some embodiments, the historical execution data is stored on a coordination server or distributed locally on each of the optional devices; the second acquisition module 302 is further configured to:

[0193] The target device sends a status query request to the coordination server to obtain the historical execution status.

[0194] Alternatively, the target device may query other optional devices according to a preset consensus protocol to obtain the historical execution status;

[0195] In some embodiments, the second acquisition module 302 is further configured to:

[0196] In response to the completion of the target output event on the target device, an execution completion notification for the target output event is generated; the execution completion notification includes at least one of the identifier of the target output event, the identifier of the target device, and an execution completion timestamp;

[0197] The execution completion notification is sent to the coordination server, or broadcast to other optional devices via a distributed synchronization protocol to update the historical execution status.

[0198] Each module in the aforementioned cross-device interactive control device 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, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0199] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. 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 and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a cross-device interactive control method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0200] Those skilled in the art will understand that Figure 4 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.

[0201] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0202] 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 included in any of the foregoing method embodiments.

[0203] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0204] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0205] 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, 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 can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchain. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logic devices based on quantum computing, artificial intelligence (AI) processors, etc., and are not limited to these.

[0206] 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 application.

[0207] 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 this patent application. 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 cross-device interactive control method, characterized in that, The method includes: Obtain the output rhythm control information corresponding to the target interaction process; the output rhythm control information includes the execution timing constraints for multiple optional output events in the target interaction process; Receive an execution request from a target device in response to a target output event; wherein the target device is at least one of a plurality of optional devices associated with the target interaction process; and the target output event is at least one of the plurality of optional output events; Obtain the historical execution status of each of the other optional devices for the plurality of optional output events; Based on the output rhythm control information and the historical execution status, determine whether the output timing of the target output event satisfies the execution timing constraint when responding to the execution request; The execution timing of the target output event on the target device is controlled according to the constraint satisfaction status.

2. The method according to claim 1, characterized in that, The optional output events represent the smallest interactive unit with independent interactive semantics; the output rhythm control information is associated with and stored in relation to the interactive process identifier of the target interactive process; the optional devices include different types of terminals and different application instances running within the same terminal; the execution timing constraints include the execution order constraints among the multiple optional output events; The step of determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraints in response to the execution request, includes: Based on the execution order constraint, determine the preceding output event associated with the target output event from the plurality of optional output events; Based on the historical execution status, determine whether the preceding output event has been completed, and obtain the first determination result; The constraint satisfaction status is determined based on the first judgment result; wherein, if the preceding output event has been completed, it is determined that the output timing of the target output event satisfies the execution order constraint in response to the execution request.

3. The method according to claim 2, characterized in that, The execution timing constraints include execution time interval constraints for the target output event; determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraints in response to the execution request includes: Determine the execution completion timestamp of the preceding output event associated with the target output event based on the historical execution data; Calculate the time difference between the current time and the execution completion timestamp, and compare the time difference with the minimum interval threshold required by the execution time interval constraint to obtain the comparison result; The constraint satisfaction status is determined based on the comparison result; wherein, if the time difference is greater than or equal to the minimum interval threshold, it is determined that the output timing of the target output event satisfies the execution time interval constraint in response to the execution request.

4. The method according to claim 2, characterized in that, The execution timing constraints include execution frequency constraints for the target output event; determining, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the execution timing constraints in response to the execution request includes: Based on the historical execution data, the total number of times the optional output events have been executed within the unit time window defined by the execution frequency constraint to which the current time belongs is counted. Determine whether the total number of executions is less than the maximum number of executions defined by the execution frequency constraint to obtain a second determination result; Based on the second judgment result, the constraint satisfaction status is determined; wherein, if the total number is less than the maximum execution number, it is determined that, in response to the execution request, the output timing of the target output event satisfies the execution frequency constraint.

5. The method according to claim 2, characterized in that, The execution timing constraint includes a constraint on the number of executions for the target output event; determining whether the execution request satisfies the execution timing constraint based on the output rhythm control information and the historical execution status includes: Based on the historical execution data, the number of times the target output event has been executed during the target interaction process is counted. Determine whether the number of executions is less than the maximum number defined by the execution count constraint to obtain a third determination result; Based on the third judgment result, the constraint satisfaction status is determined; wherein, if the number of executions is less than the maximum number of executions, it is determined that, in response to the execution request, the output timing of the target output event satisfies the execution count constraint.

6. The method according to claim 1, characterized in that, The step of controlling the execution timing of the target output event on the target device based on the constraint satisfaction includes: If the constraint satisfaction condition indicates that the execution timing constraint is satisfied, the execution request is responded to so that the target device currently executes the target output event, and the historical execution status is updated after the target output event is executed; If the constraint satisfaction condition indicates that the execution timing constraint is not satisfied, a timing conflict resolution operation is performed on the execution request; wherein, the timing conflict resolution operation includes a delay operation or a skip operation; the delay operation is used to postpone the response to the execution request until the target time that satisfies the execution timing constraint; the skip operation is used to abort the response to the execution request.

7. The method according to claim 6, characterized in that, The historical execution data is stored on a coordination server or distributed locally on each of the optional devices; obtaining the historical execution data of each of the other optional devices for the plurality of optional output events includes: The target device sends a status query request to the coordination server to obtain the historical execution status. Alternatively, the target device may query other optional devices according to a preset consensus protocol to obtain the historical execution status; The step of controlling the target device to execute the target output event if the constraint is satisfied indicates that the execution timing constraint is met, and updating the historical execution status after the target output event is executed includes: In response to the completion of the target output event on the target device, an execution completion notification for the target output event is generated; the execution completion notification includes at least one of the identifier of the target output event, the identifier of the target device, and an execution completion timestamp; The execution completion notification is sent to the coordination server, or broadcast to other optional devices via a distributed synchronization protocol to update the historical execution status.

8. A cross-device interactive control device, characterized in that, The device includes: The first acquisition module is used to acquire output rhythm control information corresponding to the target interaction process; the output rhythm control information includes execution timing constraints for multiple optional output events in the target interaction process; A receiving module is configured to receive an execution request from a target device in response to a target output event; wherein the target device is at least one of a plurality of optional devices associated with the target interaction process; and the target output event is at least one of the plurality of optional output events. The second acquisition module is used to acquire the historical execution status of each of the other optional devices for the plurality of optional output events; The determination module is used to determine, based on the output rhythm control information and the historical execution status, whether the output timing of the target output event satisfies the constraint of the execution timing constraint in response to the execution request. The control module is used to control the execution timing of the target output event on the target device according to the constraint satisfaction status.

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.

11. A computer program product, comprising a computer program, 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