Multi-terminal collaborative intelligent office internal management system

Abstract

The invention relates to the technical field of multi-terminal collaborative management, in particular to a multi-terminal collaborative intelligent office internal management system, which comprises a terminal behavior acquisition unit, a user behavior analysis unit, a state synchronization protocol unit and a terminal collaborative unit, a terminal behavior acquisition unit captures an operation behavior to generate an event stream containing an operation type and a sensor state; a user behavior analysis unit identifies a non-editing action sequence, generates an implicit intention abandoning label and triggers a conflict signal when detecting a multi-terminal space-time overlapping conflict; a state synchronization protocol unit dynamically broadcasts an authority instruction according to the label; according to the system, the problems that intention recognition is fuzzy, authority synchronization lags behind and conflict processing is missing are solved, and the office efficiency and the data security are improved.

Description

Technical Field

[0001] This invention relates to the field of multi-terminal collaborative management technology, and more specifically, to an intelligent office internal management system for multi-terminal collaboration. Background Technology

[0002] Multi-terminal collaborative management is an important technology. In the context of the current widespread adoption of remote work and multi-device collaboration, this technology is the core of ensuring office efficiency and data security. By coordinating users' operating behaviors on different terminals in real time, it can enable users to seamlessly switch between office tasks across multiple terminals, avoiding repetitive operations. It can also prevent multiple terminals from competing for the same office resources, reducing data overwriting and formatting issues. Furthermore, it can automatically identify idle terminals and release resource permissions, improving resource utilization efficiency. It is a key support for promoting the upgrade of enterprise office work from single-terminal independent operation to multi-terminal collaborative intelligent management.

[0003] However, existing multi-terminal collaborative office management technologies suffer from core problems such as ambiguous operation intent recognition, delayed permission synchronization, and lack of conflict handling. These problems stem from three practical limitations: First, there is a lack of accurate identification mechanisms for implicit user abandonment of operations. Relying solely on users manually exiting editing or closing the terminal to determine operation termination fails to capture implicit abandonment behaviors such as prolonged cursor hovering or frequent tab switching without editing, leading to idle terminals occupying resource permissions for extended periods. Second, permission synchronization is not dynamically adjusted based on user behavior, relying on fixed-period broadcasting of resource status. When one terminal releases permissions, other collaborative terminals cannot obtain updates in time, still displaying resource lockouts, delaying work progress. Third, there is no effective solution for multi-terminal operation conflicts. When the same user's operation intent overlaps across multiple terminals—for example, one terminal preparing to release permissions while another is still editing—the system cannot determine permission ownership, easily causing data synchronization chaos and even leading to the loss of unsaved operations. These problems can have a cascading effect.

[0004] Inaccurate implicit relinquishment recognition leads to invalid resource permissions being occupied, preventing timely editing on other terminals and reducing office efficiency. Delayed permission synchronization causes users to encounter permission asynchrony when switching between multiple terminals, requiring repeated refreshes or restarts of the application, wasting time. Inadequate conflict handling can cause damage or loss of office data, increasing data recovery costs and potentially raising user doubts about system reliability. Ultimately, existing technologies cannot meet enterprises' needs for accurate intent recognition, real-time permission synchronization, and efficient conflict arbitration in multi-terminal collaborative work. There is an urgent need for an intelligent management system that can automatically recognize users' implicit operation intentions, dynamically synchronize permission status, and properly handle multi-terminal conflicts. To solve this technical problem, we provide an intelligent internal management system for multi-terminal collaborative office work. Summary of the Invention

[0005] The purpose of this invention is to provide an intelligent office internal management system that enables multi-terminal collaboration, in order to solve the problems mentioned in the background art.

[0006] 1. Due to the lack of a precise mechanism for identifying implicit user abandonment of operations, idle terminals occupy resource permissions for a long time. Therefore, this case uses the terminal behavior acquisition unit to capture operation behavior and generate event streams, and the user behavior analysis unit to identify non-editing sequences and generate intent tags, which can accurately identify implicit abandonment behavior and release resource permissions in a timely manner.

[0007] 2. Since there is no solution for handling conflicts in multi-terminal operations, data may become disordered or lost. Therefore, this case uses the state synchronization protocol unit to freeze the operation tokens of conflicting terminals, generate an arbitration request packet, and the terminal collaboration unit pops up an arbitration interface, which can clearly define the ownership of permissions and avoid data problems.

[0008] To achieve the above objectives, a multi-terminal collaborative intelligent office internal management system is provided, including a terminal behavior acquisition unit that captures user operation behavior in real time to generate a raw operation event stream. This event stream includes operation type, timestamp, terminal device sensor status, and interface focus status, and is uploaded to the user behavior analysis unit.

[0009] Based on the original operation event flow, the user behavior analysis unit identifies continuous non-editable action sequences and generates intent tags that represent the user's implicit abandonment of the operation. When it detects that the intent tags of the same user on multiple terminals overlap and conflict in time and space, it automatically triggers a conflict prediction signal and marks the conflicting terminal ID.

[0010] After receiving the intent tag and conflict prediction signal, the state synchronization protocol unit dynamically adjusts the state broadcast strategy:

[0011] If there is only an implicit abandonment tag on a single terminal, an operation permission release instruction is broadcast to all collaborating terminals, including the ID of the released resource and the intent tag type. In response to the operation permission release instruction, the terminal collaboration unit immediately updates the local resource status to editable and renders a visual identifier of the intent tag on the interface.

[0012] If a conflict prediction signal is detected, the operation token of the relevant terminal is frozen, and a conflict arbitration request packet is generated and sent to the target user terminal. The terminal coordination unit responds to the conflict arbitration request packet and pops up an arbitration interface for the user to manually confirm the operation ownership.

[0013] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0014] 1. By capturing operation type and sensor status through the terminal behavior acquisition unit to generate the original operation event stream, and combining it with the user behavior analysis unit to identify continuous non-editing action sequences using the sliding window algorithm and generate intent labels, the technical effect of accurately identifying implicit abandonment of operation by the user is achieved. This solves the problem that existing technologies cannot capture implicit abandonment behavior and idle terminals occupy resource permissions for a long time. It has the advantages of timely release of resources and improved resource utilization efficiency.

[0015] 2. After receiving the intent tag through the state synchronization protocol unit, the broadcast strategy is dynamically adjusted. When a single terminal implicitly relinquishes its permission, a real-time or delayed broadcast permission release instruction is broadcast. The terminal collaboration unit immediately updates the resource status, achieving the technical effect of real-time synchronization of permissions for multiple terminals. This solves the problem of delayed permission synchronization and delayed office progress caused by existing fixed-period broadcasts, and has the advantages of reducing user operation waiting time and improving office smoothness.

[0016] 3. When a conflict is detected by the state synchronization protocol unit, the relevant terminal operation tokens are frozen and an arbitration request packet is generated. The terminal collaboration unit pops up an arbitration interface containing a three-dimensional timeline, etc., which achieves the technical effect of efficiently handling multi-terminal operation conflicts. It solves the problem of existing conflict-free handling solutions that are prone to data chaos and loss. It has the advantages of clear permission ownership and ensuring the security of office data. Attached Figure Description

[0017] Figure 1 This is an overall block diagram of the present invention.

[0018] The meanings of the labels in the diagram are as follows:

[0019] 1. Terminal behavior acquisition unit; 2. User behavior analysis unit; 3. Status synchronization protocol unit. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] This invention provides a multi-terminal collaborative intelligent office internal management system. Please refer to [link / reference]. Figure 1 As shown, the system includes a terminal behavior acquisition unit 1, which captures user operation behavior in real time to generate a raw operation event stream. This event stream includes the operation type, timestamp, terminal device sensor status, and interface focus status, and is uploaded to the user behavior analysis unit 2. When generating the raw operation event stream, the terminal behavior acquisition unit 1 captures user interaction events as basic data for the operation type using operating system-level hook technology, specifically including:

[0022] Document scrolling, cursor hover timeout, and window scaling actions simultaneously utilize the terminal device's built-in accelerometer and distance sensor to acquire 3D spatial displacement data as sensor status. The current application and its child windows are polled via the rendering engine interface to determine the interface focus status. All data is appended with a high-precision system clock timestamp and then encrypted to form a structured event stream. The timestamp is accurate to the millisecond level and includes a time zone identifier. The sensor status data includes the device's orientation angle and the quantized distance from the user. The interface focus status is differentiated into three levels: active in the foreground, suspended in the background, and minimized.

[0023] User behavior analysis unit 2 identifies continuous non-editable action sequences based on the original operation event flow, generates intent tags that represent the user's implicit abandonment of the operation, and automatically triggers a conflict prediction signal and marks the conflicting terminal ID when it detects that the intent tags of the same user on multiple terminals overlap in time and space.

[0024] When the user behavior analysis unit 2 identifies a continuous sequence of non-editing actions, it uses a sliding window algorithm to slice the original operation event stream. The window length is dynamically adjustable. Sequence recognition is triggered when a non-productive operation event is detected to occur a preset number of times within the window. The non-productive operation events include document content with zero input for a duration exceeding a threshold, frequent tab switching without selecting an editing area, and mouse trajectories forming closed shapes in non-working areas. Simultaneously, sensor status data is associated, and the confidence level of sequence recognition is enhanced when the device remains stationary and the distance increases.

[0025] It should be further explained that after the terminal behavior acquisition unit 1 captures the original operation event stream through operating system-level hook technology and sensors, including operation type, timestamp, sensor status, and interface focus status, the user behavior analysis unit 2 needs to identify continuous non-editing action sequences from it. These sequences are the core basis for determining whether the user has implicitly abandoned the operation. Relying solely on a single non-editing action is prone to misjudgment, such as the user briefly switching tabs and then returning to editing. Therefore, a sliding window algorithm is used to slice the event stream to ensure accurate identification of continuous non-editing trends. The specific implementation method is as follows:

[0026] First, the process of segmenting the original operation event stream using a sliding window algorithm is executed. This algorithm requires clarifying the core parameters and slicing logic of the window. A sliding window is a time window that slides across a continuous stream of original operation events at fixed time intervals. The window contains several operation events. The behavior type is determined by analyzing the characteristics of the events within the window. The dynamically adjustable window length means that the time span of the window is not fixed, but adaptively adjusted according to the event density of the original operation event stream. Specifically, when the event density is high, such as when a user triggers 3 tab switching within 1 second and the event interval is short, the window length is set to 5 seconds to ensure that at least 10 events are covered, avoiding missing continuous behaviors due to an excessively short window. When the event density is low, such as when a user triggers only 1 cursor hover within 3 seconds and the event interval is long, the window length is automatically extended to 8 seconds to prevent insufficient events within the window due to sparse events, making it impossible to determine the behavior trend. The adjustment of the window length is achieved by real-time statistics of the average interval time of the first 10 events, with the formula being: Window length = Average interval time × 10. A lower limit of 3 seconds and an upper limit of 10 seconds are set for the window length to balance the real-time performance and accuracy of the recognition. The specific steps of sliding slicing are as follows:

[0027] The initial left boundary of the window is determined by the timestamp of the first non-editable event (such as document scrolling) in the original operation event stream. The right boundary is determined by the currently calculated window length (e.g., if the initial event timestamp is 10:00:00.000 and the window length is 5 seconds, then the right boundary is 10:00:05.000). All events with timestamps between the left and right boundaries are selected from the original operation event stream to form a window event set, which includes three types of events: document scrolling, cursor hover timeout, and tab switching. After processing each window, the left boundary is moved to half the position of the original right boundary. For example, if the original right boundary is 10:00:05.000, the new left boundary is 10:00:02.500. Recalculate the right boundary of the new window to form an overlapping sliding mode. This mode avoids the break in continuous behavior caused by non-overlapping windows, such as when a continuous non-editing action is mistakenly split across two non-overlapping windows, ensuring that the continuous non-editing action sequence is captured completely. After each window is processed, the proportion of non-productive operation events in that window is output, providing basic data for subsequent sequence recognition. After completing the behavior slicing, sequence recognition needs to be triggered when a preset number of consecutive non-productive operation events are detected within the window. The preset number refers to the number of consecutive non-productive operation events required to trigger sequence recognition. This number needs to be calibrated based on the user's usual operating habits in an office scenario. This is achieved by statistically analyzing 1000 sets of user office operation data. It was found that when three consecutive non-productive operation events occur, the probability of a user continuing to edit drops below 30%. Therefore, the default preset number of times is set to three, while allowing the system to dynamically adjust based on the user's historical operation habits. For example, if a user frequently returns to editing after two consecutive non-editing operations, the system will adjust the preset number to four to avoid misjudgment. The detection process requires first clarifying the three specific forms of non-productive operation events and their judgment criteria. The first type is when zero input of document content continues for more than a threshold duration. The threshold duration is set differently according to document type: 30 seconds for text documents and 45 seconds for table documents, as table editing often requires more time for thinking. The system determines whether there is content input by listening to input events in the document editing area, such as keyboard input. The first category is the paste operation. If, since the last input event, the interface focus remains on the editing area without any input, and the duration exceeds a threshold, it is considered a non-productive operation. The second category is frequent tab switching without selecting an editing area. Frequent switching is defined as switching tabs ≥ 3 times within 10 seconds. The system also detects the interface focus state to distinguish between foreground active, background suspended, and minimized states. If the document corresponding to the switched tab does not have an active editing area (e.g., the cursor is not positioned in a text box or a cell is not selected), it is considered a non-productive operation. The third category is when the mouse trajectory forms a closed shape in a non-working area. The non-working area refers to the interface area outside the document editing area, such as the menu bar, toolbar, and blank desktop space. The system collects mouse trajectory data. The module records mouse coordinates. If the coordinate trajectory forms a closed polygon, it is verified by a polygon closure judgment algorithm. That is, the distance between the starting point and the ending point of the trajectory is ≤5 pixels, and the trajectory contains at least 3 turning points. Then it is judged as a non-productive operation. When three consecutive non-productive operation events that meet the above criteria are detected in the window, it will be initially judged that there is a continuous non-editing action sequence. However, in order to avoid misjudgment due to temporary user operations, such as briefly tidying up the desktop and then returning to editing, the system also needs to associate sensor status data. When the device is continuously stationary and the distance increases, the confidence of sequence recognition is enhanced. The continuous stationary state of the device is determined by the accelerometer built into the terminal device. If the three-dimensional spatial displacement data (X, Y, Z axis displacement) collected by the sensor is ≤0 for 10 consecutive seconds, the result is determined.If the device moves no more than 5mm, excluding cases where the user moves the device while holding it, it is considered stationary. Increased distance is determined by a distance sensor, which measures the distance between the device and the user in real time. For example, a laptop's distance sensor measures the distance between the screen and the user's face. If the distance increases from an initial 30-50cm (normal office distance) to over 80cm and remains there for more than 5 seconds, it is considered an increased distance. The confidence level for sequence recognition is calculated using a weighted summation method. The base confidence level (based only on non-productive operation events) is set to 0.6. If the device remains stationary, the confidence level increases by 0.2. If the distance increases simultaneously, the confidence level increases by another 0.15 (to 0.95). If only one condition is met, the confidence level increases by 0.1 (e.g., to 0.7 if only stationary). When the confidence level is ≥ 0.8, continuous non-editing action sequence recognition is officially triggered. The start timestamp of the sequence, the types of non-productive operation events included, and the confidence score are output. This provides an accurate basis for subsequently generating labels indicating the user's implicit abandonment of the operation. This avoids misjudgments caused by relying solely on operation events and enhances the reliability of recognition through sensor data, ensuring that the sequence recognition results closely match the user's true operation intentions.

[0028] When generating intent labels representing implicit user abandonment of an operation, behavioral weights are assigned to the identified continuous non-editing action sequences. An abandonment intent probability model is constructed based on the correlation between operation types, with cursor hover timeout given the highest weight and window scaling action given the second highest weight. When the weighted total score of the sequence exceeds the dynamic threshold, a first-level abandonment label is generated. If the device sensor is simultaneously detected to return to a state far from the user, a second-level abandonment label is generated. The label data structure includes the sequence start timestamp, the main event type code, and the confidence score.

[0029] It needs further explanation that after the user behavior analysis unit 2 identifies a continuous sequence of non-editing actions using the sliding window algorithm, simply confirming the existence of the sequence is insufficient to accurately determine whether the user has implicitly abandoned the operation. Different non-editing actions reflect varying degrees of abandonment intent; for example, a prolonged cursor hover is more likely to represent abandonment than a brief window zoom. Therefore, it is necessary to quantify the intent intensity through behavior weight assignment and an abandonment intent probability model, ultimately generating corresponding intent labels. The specific implementation method is as follows:

[0030] The first step involves assigning weights to the identified sequences of continuous non-editing actions. This process requires clarifying the criteria for weight allocation. The weight is positively correlated with the action's representation of the abandoned operation; the higher the correlation, the greater the weight. By analyzing the mapping data of 1000 sets of user office operations and their final behaviors, such as recording whether users actually abandoned their operations after continuous non-editing actions, the weights of three core non-productive operation events are determined. The highest weight is assigned to cursor hover timeout, with a weight value set to 0.6. This is because cursor hover timeout, such as when the cursor remains stationary in the editing area for more than 30 seconds, usually means that the user's attention has left the current document, and the probability of abandoning the operation is as high as 85%, making it the action that most directly reflects the intention to abandon. The second highest weight is assigned to window shrinking. For actions like window scaling (e.g., shrinking the document window to half-screen or switching to full-screen), while it might indicate the user is adjusting the interface layout, the probability of abandoning editing after multiple scaling actions is about 60%. Therefore, its strength in representing the intention to abandon editing is weaker than cursor hover timeout, hence its lower weight. Additionally, the weight for frequently switching tabs without selecting an editing area is set to 0.3 (base weight). This type of action might indicate the user is searching for information, and the probability of returning to editing later is still 40%, making it the least relevant. When assigning weights, it's necessary to iterate through each event in the sequence of consecutive non-editing actions and match the corresponding weight according to the event type. For example, if the sequence includes cursor hover timeout → window scaling → frequently switching tabs, then assign weights of 0.6, 0.4, and 0.3 respectively. After assignment, an abortion intent probability model is constructed based on the correlation between operation types. This abortion intent probability model is a mathematical model that quantifies the likelihood of a user abandoning an operation through weighted summation. Its core logic is to multiply the weight values ​​of all events in a continuous non-editing action sequence by the event duration coefficients and then sum them to obtain a weighted total score. The higher the total score, the stronger the user's abortion intent. The specific expression of the model is: S = Σ((ωi × ti / tmax), where S is the weighted total score, ωi is the weight value of the i-th non-editing action, ti is the duration of the i-th action (e.g., cursor hover timeout lasts 35 seconds, window scaling lasts 5 seconds), and tmax is the threshold duration for this type of action (cursor hover timeout threshold is 30 seconds, window scaling has no fixed threshold). The longest action in the sequence is taken to have a duration of 5 seconds. `ti / tmax` is the duration coefficient. The longer the action duration, the closer the coefficient is to 1, and the greater its contribution to the total score. For example, if the cursor hover timeout lasts 35 seconds, the coefficient is 35 / 30 ≈ 1.17, and the weight is 0.6 × 1.17 ≈ 0.702; if it lasts 60 seconds, the coefficient is 2, and the weight is 0.6 × 2 = 1.2. By introducing the duration coefficient, we can avoid treating short-term hovering and long-term hovering the same, thus improving the model's accuracy. For example, in the above sequence, the cursor hover timeout lasts 35 seconds (coefficient 1.17), window scaling lasts 5 seconds (coefficient 1), and frequent tab switching lasts 20 seconds, with a coefficient of 20 / 20 = 1. If the threshold duration is set to 20 seconds, then the weighted total score S = 0.6 × 1.17 + 0.4 × 1 + 0.3 × 1 ≈ 0.702 + 0.4 + 0.3 = 1.402. After the model calculates the sequence-weighted total score, it needs to be compared with a dynamic threshold to determine the label level. The dynamic threshold is the critical total score value for determining whether to generate an abandonment label. It is not a fixed value, but is dynamically adjusted according to the user's historical operation habits and the current document editing progress. For high-frequency editing users (editing documents for more than 5 hours per day on average), the probability of the user returning to editing after a short absence is higher, and the dynamic threshold is set to 1.8 (a higher total score is required to determine abandonment). For low-frequency editing users (editing for less than 1 hour per day on average), the threshold is set to 1.2 (lower threshold). (The total score can be used to determine this). Simultaneously, if the current document editing progress exceeds 80%, the probability of the user abandoning the task decreases, and the threshold increases by 20%. If the progress is below 20%, the threshold decreases by 10%. Real-time adjustment of the dynamic threshold is achieved by calling the user behavior history database and the document editing progress statistics module, ensuring that the threshold adapts to different users and scenarios and reducing misjudgments. When the sequence-weighted total score exceeds the dynamic threshold, a first-level abandonment label is generated. This first-level label indicates that the user has a high intention to abandon the task, but there is still a certain probability of returning to editing. After the label is generated, the operation permission is not released immediately; it is only marked as a pending observation state. If, at the same time as generating the first-level label, a device... If the sensor returns a "far from user" status, indicating the distance between the device and the user exceeds 80cm for more than 5 seconds and the accelerometer shows no movement, it means the user has physically moved away from the terminal and has a strong intention to abandon the operation. In this case, the first-level abandonment tag is upgraded to a second-level abandonment tag. The second-level tag indicates that the user has a high probability of completely abandoning the operation, and the system will trigger a subsequent operation permission release process. Finally, a tag data structure is constructed containing a sequence start timestamp, a major event type code, and a confidence score to record the start time of the continuous non-editable action sequence, facilitating the tracing of the behavior's origin. The major event type code uses a two-digit encoding, such as 0. 1 represents cursor hover timeout, 02 represents window scaling, and 03 represents frequent tab switching. The two events with the highest weight in the sequence are selected as the primary events. If the sequence includes cursor hover timeout and window scaling, the type codes are 01 and 02. This quickly identifies the core basis for the label. The confidence score is calculated by the ratio of the weighted total score of the abandonment intent probability model to the dynamic threshold. The higher the score, the stronger the reliability of the label. A score ≥ 1 indicates that the threshold has been exceeded and the label generation conditions have been met. This data structure is stored in JSON format, which facilitates subsequent parsing and transmission by the state synchronization protocol unit 3, providing accurate intent data support for multi-terminal operation permission management.

[0031] When a spatiotemporal overlap conflict is detected between intent tags of the same user on multiple terminals, a spatiotemporal coordinate system for user operations on multiple terminals is established. The time stamp of intent tag generation is used as the time axis base point, and the GPS positioning data of the terminal device is used as the spatial coordinate. When the time intervals of intent tags generated by two terminals of the same user overlap and the spatial distance between the devices is less than the collaboration radius within the preset conflict detection period, it is determined to be a spatiotemporal overlap conflict. The collaboration radius is dynamically configured according to the type of office scenario.

[0032] It needs further explanation that after the user behavior analysis unit 2 generates intent tags for multiple user terminals, if the same user operates the office system simultaneously on multiple terminals such as computers, tablets, and mobile phones, spatiotemporal overlap of intent tags may occur. This overlap can lead to conflicts in operation permissions for the same office resource across multiple terminals. For example, if terminal A determines that the user is abandoning the operation and is preparing to release permissions, but terminal B is still editing, releasing permissions at this time can easily cause data loss. Therefore, it is necessary to detect spatiotemporal overlap conflicts first. Specifically, quantitative judgment is achieved by establishing a spatiotemporal coordinate system for user multi-terminal operation. The specific implementation method is as follows:

[0033] The first step is to establish a spatiotemporal coordinate system for user multi-terminal operations. This system is a three-dimensional coordinate system that integrates time and space dimensions. It is used to intuitively present the timing and location relationships of the same user's operations on different terminals. The time dimension (T-axis) uses the user account as a unique identifier and integrates the time data of intent tags generated by all terminals of the user. The space dimensions (X-axis, Y-axis) are based on the physical location of the terminal devices to construct planar coordinates. The core value of this coordinate system lies in transforming abstract multi-terminal operations into quantifiable and comparable coordinate points, avoiding reliance solely on... To prevent misjudgments due to manual judgment, the system first retrieves a list of all currently logged-in terminal devices from the user account center during the system's construction. For example, Device 1: Laptop, Device 2: Tablet. Then, it collects key data for each terminal. In terms of time, it extracts the generation timestamps of the intent tags for each terminal, including time zone identifiers. For example, the timestamp for Device 1 tag is 2024-10-09 09:40:15.230, and the timestamp for Device 2 tag is 2024-10-09 09:40:18.560. The earliest timestamp is set as the origin of the T-axis, such as 9:40:15 for Device 1.230 represents T=0. Subsequent times are converted to T-axis coordinates using millisecond differences. The T-coordinate of device 2 is 18560 - 15230 = 3330 milliseconds. Spatially, the built-in GPS positioning module of each terminal device is invoked. If the terminal does not have GPS, such as a desktop computer, the physical location mapping data corresponding to the office network IP is used to obtain the latitude and longitude of the device. The latitude and longitude are converted into X and Y coordinates in a Cartesian coordinate system using a Gaussian projection algorithm, ultimately forming a unique coordinate point for each terminal's intent tag in the TXY three-dimensional coordinate system, which is used for subsequent timing... The collision detection mechanism provides a spatial reference. After the coordinate system is established, it is necessary to monitor spatiotemporal overlap within a preset collision detection period. The preset collision detection period refers to the time window during which the system determines whether there is a correlation between intent tags from multiple terminals. The duration of this period needs to balance the timeliness and accuracy of collision detection. If the period is too short (within 10 seconds), it is easy to miss the temporal correlation of cross-terminal operations. For example, if a user generates a tag on a computer first and then generates a tag on a tablet 15 seconds later, the short period will misjudge that there is no correlation. If the period is too long (more than 60 seconds), it will cause a delay in collision detection, affecting performance. To improve permission synchronization efficiency, considering the typical intervals between user terminal switching in office scenarios, statistics show that 80% of users switch terminals within 30 seconds. The default conflict detection cycle is set to 30 seconds, with the option to fine-tune it according to different office scenarios. The system starts an independent conflict detection timer for each user, beginning when an intent tag is generated on a particular terminal. If other terminals also generate the same user's intent tag within 30 seconds, these tags are included in the same conflict detection batch. If no new tags are generated within 30 seconds, the timer is reset, and the collected tags are considered to have no temporal correlation, requiring no further conflict detection. Within the same conflict detection batch, the intent tag time interval must be determined first. This interval refers to the time range covered by a single intent tag, not just the generation timestamp. It extends from the start of a continuous non-editing action sequence to the end of the system's preset observation period after tag generation. The purpose is to cover the complete process from the user's initial intention to abandon the intent to their final confirmation of abandonment, avoiding time matching discrepancies caused by judging solely at the moment of generation. The calculation rule for the time interval is as follows:

[0034] The interval start time equals the timestamp of the first event in the continuous non-editable action sequence. For example, if the first event time in the sequence for device 1 is 9:40:10:120, the interval end time equals the intent label generation timestamp plus the observation duration. The observation duration is set according to the label level: 10 seconds for a level 1 abandonment label and 5 seconds for a level 2 abandonment label. This is because level 2 labels represent a stronger abandonment intent and therefore require a shorter observation duration. For example, if device 1 generates a level 1 abandonment label (generation time 9:40:15:230), then the time interval is 9:40:10:120-9:40:25:230. If device 2 generates a level 2 abandonment label (generation time 9:40:18:560), then the time interval is 9:40:10:120-9:40:25:230. The time interval is 9:40:13.340-9:40:23.560. To determine time overlap, the two time intervals only need to overlap in any way. For example, if the 9:40:18.560-9:40:23.560 segment of device 1 completely overlaps with the time interval of device 2, then the condition of overlapping time intervals is met. This step is the core basis for the time dimension of conflict determination. Simultaneously, the spatial distance between devices needs to be calculated and compared with the collaboration radius. The collaboration radius refers to the maximum spatial distance between multiple terminals in a collaborative state. When the distance between multiple terminals of the same user is less than this radius, it is highly likely that the users are in the same office area. Switching between devices, such as using a computer and tablet simultaneously at a desk, poses a risk of operational conflicts. If the distance is greater than the radius, it likely indicates that the user is using different devices in different areas, such as a computer in the office and a mobile phone in a meeting room. In such cases, the operational resources are unlikely to overlap, and the risk of conflict is low. The collaboration radius is dynamically configured based on the type of office scenario. In fixed-workstation office scenarios, such as individual employee desks, where the user's activity range is small, the collaboration radius is set to 5 meters, covering the workstation and surrounding area. In open-plan office scenarios, such as shared workstations or break rooms, where the user's activity range is slightly larger, the collaboration radius is set to 15 meters. In large meeting room scenarios, considering multiple people sharing the space, the collaboration radius is set to 3 meters. 0 meters. If the terminal is a fixed device without GPS, such as a desktop computer, then the fixed distance of the physical installation location of the device is used directly. For example, if two desktop computers are in the same office and the distance is 3 meters, which is less than the 5-meter collaboration radius, the spatial distance between the devices is calculated based on the X and Y coordinates of the spatiotemporal coordinate system mentioned above, using the Euclidean distance formula: distance D=√[(XX)2+(YY)2]. For example, if device 1X=12500m, Y=8600m, and device 2X=12505m, Y=8603m, then D=√[(5)2+(3)2]=√34≈5.83 meters. If the current scenario is a fixed workstation with a collaboration radius of 5 meters, then 5.If the distance is 83 meters (>5 meters), the spatial condition is not met. In an open-plan office environment with a collaboration radius of 15 meters, the condition that the spatial distance between devices is less than the collaboration radius is met. When the same user, within a preset conflict detection period, simultaneously meets both the conditions of overlapping time intervals for two terminal intent tags and a spatial distance between devices less than the collaboration radius, the system determines it as a spatiotemporal overlap conflict. For example, if the tags of device 1 and device 2 overlap in time intervals and are 5.83 meters apart within a 30-second detection period in an open-plan office environment, a conflict prediction signal is triggered. Subsequently, the state synchronization protocol unit 3 executes the process of freezing the operation token and generating an arbitration request packet. If only one condition is met, such as overlapping time intervals but a distance greater than the collaboration radius, or distance meeting the standard but no overlap in time intervals, it is determined as no conflict, and no subsequent arbitration is triggered. This dual-dimensional (time + space) judgment avoids misjudgments based on a single dimension, such as only considering overlapping time intervals while ignoring the absence of long-distance conflicts, or only considering distance while ignoring the lack of temporal correlation. It also ensures that conflict detection accurately reflects the actual office environment, providing a reliable basis for collaborative management of multi-terminal operation permissions.

[0035] When a conflict prediction signal is triggered, a conflict terminal topology map is constructed. Based on the intent label confidence score and device usage priority, the primary conflict terminal and the secondary conflict terminal are marked. The primary conflict terminal is marked as a terminal with a high intent label confidence score and a device type of fixed workstation. At the same time, a conflict coding protocol data packet is generated. This data packet contains the conflict time interval fingerprint, spatial coordinate hash value, and a list of conflict terminal IDs. The terminal ID adopts a dual identification mechanism of device fingerprint and user account.

[0036] It needs further explanation that, after determining that there is a spatiotemporal overlap and conflict in the intent tags of multiple terminals for the same user, directly performing the same control action on all conflicting terminals, such as freezing operation tokens at the same time, can easily cause the shared document being edited to become unusable due to permission confusion. Therefore, it is necessary to first trigger a conflict prediction signal, clarify the conflict role of each terminal by constructing a conflict terminal topology map, and then generate a standardized conflict coding protocol data packet for subsequent arbitration. The specific implementation method is as follows:

[0037] The first step is to construct a conflict terminal topology map. This map is a visual network structure diagram that intuitively presents the relationships between all conflicting terminals. Its core function is to clearly label the conflict attributes and interrelationships of each terminal, avoiding role confusion caused by three or more terminals clashing simultaneously. During construction, the system first obtains basic information about all conflicting terminals from the conflict detection module, including terminal ID, intent label confidence score, fixed workstation / mobile terminal, time interval, and spatial coordinates. Then, with each terminal as an independent node, the topology map is drawn according to the following rules:

[0038] Node size is positively correlated with intent label confidence score. Node colors distinguish device types: blue for fixed workstations and orange for mobile terminals. Nodes are connected by lines, with line thickness representing the degree of overlap in time intervals; the higher the proportion of overlap time to total detection cycles, the thicker the line. Line color represents spatial distance; the closer the distance, the darker the color (e.g., dark red for within 5 meters, light red for 10-15 meters). This topology map allows for rapid location of core conflicting terminals and their correlation strength. After the topology map is constructed, primary and secondary conflicting terminals are marked according to intent label confidence scores and device usage priority. The primary conflicting terminal refers to the terminal that has the most dominant control over access to office resources in a conflict scenario. Its determination requires meeting two conditions simultaneously: First, its intent label confidence score must be the highest among all conflicting terminals. Higher confidence indicates a stronger reliability in the user's abandonment of intent, and subsequent permission adjustments should prioritize the intent of this terminal. Second, it must be a fixed workstation. These terminals are typically used for long-term, highly complex document writing and data processing, and users rely on them far more heavily than on mobile terminals. Secondary conflicting terminals are those other than the primary conflicting terminal, mostly mobile terminals, and have low intent label confidence scores. For the primary conflicting terminal, its operating permissions need to be adapted and adjusted according to the status of the primary conflicting terminal. The marking process consists of two steps. The first step is to filter high-confidence terminals, extracting the terminals with the top two intention tag confidence scores from the conflicting terminals. The second step is to determine the device type and priority. If there is a fixed workstation among the high-confidence terminals, such as terminal A being a fixed workstation, then that terminal is directly marked as the primary conflicting terminal, and the other terminals (B, C) are secondary conflicting terminals. If all high-confidence terminals are mobile terminals, then they are marked according to device usage priority. The system's preset priority is: tablet > mobile phone > other mobile devices. For example, terminal B (tablet > mobile phone > other mobile devices) is marked as a primary conflicting terminal. If the board (B) has a higher priority than terminal C (mobile phone), then B is the primary conflicting terminal and C is the secondary conflicting terminal. After marking, the primary conflicting terminal node is highlighted with a red border in the conflicting terminal topology diagram, and the secondary conflicting terminal nodes are added with gray shading to facilitate quick identification of roles during subsequent arbitration. After identifying the primary and secondary conflicting terminals, a conflict encoding protocol data packet is generated simultaneously. This data packet is a standardized data carrier for transmitting conflict information within the system and must contain all the key information required for arbitration to ensure that the target user terminal and state synchronization protocol unit 3 can accurately parse the conflict details. The data packet generation process requires filling in the preset fields one by one:

[0039] First, there's the conflict time interval fingerprint. This fingerprint is a unique code for the time interval of the intent tags of all conflicting terminals. It's generated by extracting the start and end timestamps (in milliseconds) of each terminal's time interval, converting these timestamps into hexadecimal strings, sorting them by terminal ID, concatenating them, and then encrypting them using the SHA-256 algorithm to generate a 32-bit fingerprint. This fingerprint can quickly verify the uniqueness of the conflict time interval, preventing tampering during data transmission. Second, there's the spatial coordinate hash value. The X and Y plane coordinates of the main conflicting terminals are extracted, the coordinate values ​​are concatenated after retaining integer values, and then a 16-bit hash value is generated using the MD5 algorithm. This hash value protects the privacy of the terminal's precise physical location and can also serve as a spatial hash value. The final verification basis is the list of conflicting terminal IDs. This list must use a dual identification mechanism of device fingerprint and user account. Each terminal ID consists of two parts: the first half is the device fingerprint, and the second half is the user account. The two are connected by @ to form a complete terminal ID. The list is arranged in the order of master and slave conflicting terminals, with the master conflicting terminal ID first and the slave conflicting terminal ID second, separated by commas. After all fields are filled, the data packet is encapsulated in JSON format and sent to the state synchronization protocol unit 3 through the system's encrypted transmission channel. This provides standardized conflict data support for subsequent freezing of operation tokens and generation of arbitration request packets, ensuring that the transmission of conflict information between multiple terminals is accurate, secure, and unambiguous.

[0040] After receiving the intent tag and conflict prediction signal, state synchronization protocol unit 3 dynamically adjusts the state broadcast strategy:

[0041] If there is only an implicit abandonment tag for a single terminal, then broadcast an operation permission release instruction to all collaborative terminals, including the released resource ID and intent tag type. In response to the operation permission release instruction, the terminal collaboration unit 4 immediately updates the local resource status to editable and renders a visual identifier of the intent tag on the interface.

[0042] When broadcasting the operation permission release command to all collaborative terminals, a hierarchical broadcast strategy is adopted, and the broadcast delay parameter is selected according to the intent tag type, specifically including:

[0043] The first-level abandonment of the label triggers real-time broadcasting, while the second-level abandonment of the label adopts a mild broadcasting mode with a random delay window. The instruction data packet encapsulates the distributed hash value of the resource ID and the intent label type code.

[0044] Further explanation is needed: After the state synchronization protocol unit 3 receives the intent tag transmitted by the user behavior analysis unit 2 and confirms that there is no spatiotemporal overlap conflict among multiple terminals (i.e., only an implicit relinquishment tag exists for a single terminal), in order to avoid synchronization chaos when the operation permission release command is transmitted between multiple terminals, a hierarchical broadcast strategy needs to be adopted. Different broadcast rhythms are adapted according to the intent tag type, while ensuring that the command data packet contains key information to achieve precise permission control. The specific implementation method is as follows:

[0045] The process of first executing the instruction to release operation permissions to all collaborative terminals employs a tiered broadcast strategy. This strategy differentiates the timeliness and transmission priority of the instruction broadcast based on the strength of the user's abandonment intent reflected in the intent tag. The core logic is that the clearer the user's abandonment intent, the more timely the broadcast, quickly releasing resources for other terminals. When the intent is relatively ambiguous, the broadcast is appropriately delayed to allow for the possibility of the user returning to the operation, reducing operation interruptions caused by accidental release. The system first extracts the tag type from the intent tag data, then calls the preset broadcast strategy configuration table to determine the broadcast delay parameters, transmission channel priority, and retry mechanism for the corresponding tag type. For example, a level 1 abandonment tag corresponds to a high-priority channel + real-time transmission + 1 retry; a level 2 abandonment tag corresponds to a medium-priority channel + delayed transmission + 3 retries. This tiered approach ensures the rapid delivery of high-urgency instructions while providing fault tolerance for low-urgency instructions, preventing instruction loss due to network fluctuations. The broadcast delay parameters are selected based on the intent tag type, specifically including:

[0046] The Level 1 abandonment tag triggers real-time broadcasting. Real-time broadcasting refers to an instant transmission mode with a broadcast delay parameter set to zero milliseconds. This mode is applicable to Level 1 abandonment tags, which are generated when the sequence weighted total score exceeds a dynamic threshold. This indicates that the user has a high intention to abandon the device but has not physically moved away from the terminal. Delayed broadcasting could cause other terminals to wait due to not obtaining permissions in time, affecting work efficiency. In specific implementation, after confirming that the tag type is Level 1, the state synchronization protocol unit 3 immediately encapsulates the operation permission release instruction into a data packet and sends it through the system's internal high-priority transmission channel. This channel is dedicated to real-time instruction transmission and temporarily blocks non-urgent data such as log reports to ensure sufficient bandwidth. All collaborative terminals, with the collaborative terminal list provided by the terminal management module, include all terminals currently bound to the user account and online. If no confirmation is received from a terminal within 100 milliseconds after sending, the system will automatically retry once. If no confirmation is received, the terminal is marked as offline and awaiting synchronization. Once it comes back online, the command will be pushed first to ensure that all online terminals can obtain permission release information in real time and update their local resource status promptly. Then, a secondary abandonment tag is used, employing a gentle broadcast mode with a random delay window. Gentle broadcast mode is a delayed transmission mode relative to real-time broadcast. The random delay window refers to setting a time with multiple selectable delay values ​​for command transmission. The system randomly selects one value as the actual broadcast delay to avoid all cooperating terminals simultaneously receiving instructions and executing resource status updates, which could lead to excessive instantaneous server load. For secondary abandonment tags, the user generates a primary tag and the device sensor detects a distance from the target state, indicating a strong abandonment intention. The random delay window is preset to 500 to 1000 milliseconds. The system selects an integer delay value within this range using a built-in random number generator, avoiding peak network periods. By monitoring the system's network bandwidth utilization in real time, if the utilization exceeds 80%, a larger delay value (e.g., above 900 milliseconds) is prioritized; otherwise, a smaller value is selected. In specific operations, the status... Synchronization protocol unit 3 first records the generation time of the secondary abandonment tag, then counts down according to the selected delay value. After the countdown ends, the instruction is sent through the medium-priority transmission channel. If no acknowledgment is received after sending, it will retry after a 200-millisecond interval, with a maximum of 3 retries. This ensures that the instruction is eventually delivered and also distributes the terminal response pressure through delay, avoiding system load fluctuations. Finally, the instruction data packet encapsulates the distributed hash value of the resource ID and the intent tag type code. This is crucial to ensure that the instruction can be accurately parsed by the collaborative terminal. Among them, the distributed hash value of the resource ID is a unique identifier of the office resource corresponding to the released operation permission, that is, the encrypted processing result of the resource ID, and the generation method is as follows:

[0047] First, the resource ID is obtained, and then converted into a 64-bit string using a distributed hash algorithm. This hash value is used to prevent the resource ID from being tampered with during transmission, and to ensure that the hash calculation results for the same resource ID are consistent across different terminals, preventing resource matching errors due to differences in terminal calculations. The intent tag type code is a standardized encoding of the tag type using two digits. A first-level abandonment tag corresponds to 01, and a second-level abandonment tag corresponds to 02. The purpose of this encoding is to allow collaborative terminals to quickly identify the tag type and execute the corresponding response action without parsing the complete tag data. For example, if 01 is identified, the resource status is updated immediately; if 02 is identified, an additional notification is pushed after the status is updated. When the data packet is encapsulated, the data is first organized according to a preset format: the header is the type code, the middle is the distributed hash value, and the tail is the checksum. Then, the data packet size is reduced using a compression algorithm to ensure fast transmission even in low-bandwidth environments. The final generated data packet will be appended with a system timestamp and the sender's signature. After receiving the data, the collaborative terminal first verifies the signature and checksum. After confirming that the data has not been tampered with, it then parses the type code and hash value to complete the local resource status update and visual identifier rendering, ensuring that the entire permission release process is accurate, secure, and efficient.

[0048] When updating the local resource status, the current rendering thread is interrupted to insert a high-priority status update transaction. A double buffering mechanism is used to avoid screen flickering. When the rendering intent label is visualized, a preset icon library is matched according to the type code, and a status change summary card is pushed to the system notification center.

[0049] Further explanation is needed: After the collaborative terminal receives the operation permission release instruction broadcast by the state synchronization protocol unit 3 and completes data packet parsing to extract the distributed hash value of the resource ID and the intent tag type code, it needs to immediately update the local resource status to ensure data consistency across multiple terminals. However, if the status update is performed directly in the thread currently responsible for interface rendering, thread blocking can easily lead to document scrolling stutters, delayed button highlighting, and even interface flickering. Therefore, it is necessary to ensure smooth updates by interrupting the rendering thread, inserting high-priority transactions, and using a double-buffering mechanism. Simultaneously, visual indicators and push notifications are rendered synchronously to allow users to intuitively perceive permission changes. The specific implementation method is as follows:

[0050] When updating local resource status, the current rendering thread is interrupted to insert a high-priority status update transaction. The current rendering thread is the dedicated thread on the terminal device responsible for drawing UI elements. From minor actions like cursor blinking and text color rendering to major actions like window scaling and menu expansion, all are executed frame-by-frame by this thread. High-priority status update transactions are operations with higher priority than ordinary rendering tasks. Because resource status is directly related to user operation permissions, it must be completed first to avoid permission conflicts. The specific process is as follows:

[0051] After parsing the command, the terminal first checks whether the current rendering thread is busy through the thread monitoring module. If it is busy, a temporary pause signal is immediately sent to the rendering thread. Upon receiving the signal, the rendering thread automatically saves its current task progress and then releases thread resources. After the thread is paused, the system immediately inserts a state update transaction. The first step of the transaction is to match the resource ID in the local resource database based on the distributed hash value to find the target office resource corresponding to the hash value. The second step is to modify the resource status, changing the original locked editable state (where only terminals that triggered the permission release had editing rights) to unlocked editable state, allowing all collaborative terminals to apply for editing rights. At the same time, the permission change details are recorded in the resource log, including the permission release time and the triggering time of the change. The process involves several steps: first, determining the intent label type and execution terminal ID; second, adding a temporary mutex lock to prevent other tasks from modifying resource states simultaneously during transaction execution; and third, strictly controlling the entire transaction execution time to within 50 milliseconds. After execution, the system sends a resumption signal to the rendering thread, which loads the previously saved progress and continues the paused interface rendering task, ensuring that users perceive only a very short, smooth, or even completely imperceptible delay. A double-buffering mechanism is used to avoid interface flickering. This mechanism uses two memory buffers, a front-end buffer and a back-end buffer, to collaboratively handle interface rendering. The front-end buffer displays the already rendered content on the screen, while the back-end buffer renders new content in memory, avoiding direct rendering of the front-end content. During the rendering of the foreground buffer, a flickering phenomenon of half-drawn and half-displayed elements occurs. In practice, after the state update transaction is completed, the interface needs to be refreshed to reflect the change in resource state. At this time, the system does not directly operate on the foreground buffer, but first activates the background buffer. This background buffer has the same resolution and size as the foreground buffer. The system renders the updated interface elements in the background buffer, such as drawing an editable icon to the right of the target resource name, deleting the original lock icon, and adjusting the background color of the resource item. During the rendering process, the foreground buffer continues to display the old interface, and the user cannot see any incomplete screen during the rendering process. After the background buffer has completed rendering all updated elements, the system uses a hardware-level fast switching command to switch the foreground buffer and the background buffer. The roles of the buffer zones are reversed: the original back buffer becomes the foreground for display, and the original foreground buffer becomes the back buffer awaiting the next rendering. The entire switching process takes less than 10 milliseconds, completely imperceptible to the naked eye. Even with frequent updates to multiple resource states in a short period, the interface remains smooth, completely avoiding the flickering problem caused by traditional single-buffer rendering. Then, when rendering the intent label visualization, a preset icon library is matched according to the type code. The intent label visualization is an intuitive icon displayed on the interface to inform the user of the trigger reason for the release of resource permissions, rather than just displaying a text prompt that permissions have been released. The preset icon library is a set of icon files pre-stored locally on the terminal, indexed according to the intent label type code to ensure fast matching. The specific process is as follows:

[0052] First, the intent label type codes are extracted from the parsed instructions. The first-level abandonment label corresponds to type code 01, and the second-level abandonment label corresponds to type code 02. Next, the local preset icon library is called. This icon library stores PNG format icons categorized by type code, supports transparent backgrounds to avoid obscuring other interface elements, and matches the yellow temporary abandonment icon (a semi-transparent clock pattern with the clock hand pointing to a paused state, symbolizing the user may temporarily leave). The 02 type code matches the red away abandonment icon (a semi-transparent silhouette of the user leaving, accompanied by the text "away," symbolizing the user has physically moved away from the device). The icon library also includes preset display rules: the icon size is fixed at 20×... The icon is 20 pixels high and positioned 25 pixels to the right of the target resource name to avoid obscuring it. A tooltip will appear when the mouse hovers over it. After the icon and display rules are finalized, the system draws the icon in the background buffer, synchronously with previously updated resource status elements. After the double buffering switches, the icon appears in the foreground along with other interface elements. Users do not need to check the permission log; they can quickly determine the specific reason for permission release simply by looking at the icon. Finally, a status change summary card is pushed to the system notification center. The system notification center is a message aggregation module for terminal devices, used to centrally display non-urgent but user-needed messages. The status change summary card is a concise structured message card. This includes core information about permission changes, avoiding users receiving lengthy text notifications. In practice, while rendering the visual identifier, the terminal automatically generates a summary card. The card content includes three parts: basic resource information (retrieving the resource name corresponding to the distributed hash value from the local resource library, such as "2024 Q4 Project Plan.docx"), to prevent users from being unable to identify resources due to hash values; details of status changes (text description: operation permissions have been released, all current collaborative terminals can apply for editing); and trigger reason (converted to plain text based on the type code, such as "Level 1 Abandon Tag: User may temporarily leave the terminal" or "Level 2 Abandon Tag: User has moved away from the terminal, indicating a strong intention to abandon"). The bottom of the card... A quick jump button is also provided, which can directly open the corresponding office resources after clicking, without requiring users to search in the resource list. After the card is generated, the terminal pushes it to the notification center through the system notification interface. The notification center prioritizes messages, with status changes having medium priority, which is higher than advertising notifications and lower than system fault alarms. Cards are retained for 10 minutes by default, and are automatically archived to the notification history folder after 10 minutes, making it convenient for users to track permission change records later. At the same time, it avoids notification pile-up that will interfere with normal office work. The entire push process is completed synchronously with the interface rendering, ensuring that users receive notification reminders while seeing changes in interface icons, forming a dual perception of visual and text messages and reducing information omissions.

[0053] If a conflict prediction signal is detected, the operation token of the relevant terminal is frozen, and a conflict arbitration request packet is generated and sent to the target user terminal. The terminal coordination unit 4 responds to the conflict arbitration request packet and pops up an arbitration interface for the user to manually confirm the operation ownership.

[0054] When freezing the operation token of the relevant terminal, a token hibernation command is sent to the target terminal. This command carries the state rollback point version number. After receiving the command, the terminal immediately suspends local editing cache writing, encapsulates the unsynchronized operation data into a differential data packet and adds a state snapshot fingerprint. At the same time, the editing interface is switched to read-only mode and a watermark layer is superimposed. The token freeze state continues until the arbitration result is received or the system timeout reset command is received.

[0055] Further explanation is needed: After the state synchronization protocol unit 3 generates the conflict coding protocol data packet and confirms the master and slave conflicting terminals, to prevent conflicting terminals from competing to edit the same office resource before the arbitration result is issued—for example, if the master conflicting terminal intends to release permissions while the slave conflicting terminal is still modifying content, ultimately leading to data overwriting or formatting errors—it is necessary to freeze the operation tokens of the relevant terminals. This operation token is the unique credential for a terminal to obtain editing permissions for office resources. Each terminal is given a unique token by the system when requesting to edit resources. Only when the token is valid can write, delete, and format adjustment operations be performed. Freezing the token temporarily revokes editing permissions. The specific implementation method is as follows:

[0056] When freezing the operation tokens of relevant terminals, a token dormancy command is sent to the target terminals. This command carries the state rollback point version number. The target terminals are all terminals identified as having spatiotemporal overlap conflicts, including primary and secondary conflict terminals. The system extracts the IDs of these terminals from the conflict terminal ID list in the conflict encoding protocol data packet and sends the token dormancy command through a TLS 1.3 encrypted transmission channel. This channel is specifically used for transmitting permission control commands to prevent the commands from being intercepted or tampered with. The command structure includes three parts: first, a unique token identifier, which is completely consistent with the edit token ID currently held by the terminal, ensuring that the terminal can recognize that the command is for its own token; second, the state rollback point version number, which is the historical version encoding that the resource can currently be stably rolled back to. The system generates a version snapshot for each office resource every 5 minutes. The rollback point version number corresponds to the latest complete snapshot. This version number is included for subsequent arbitration; if invalid operations during the freeze period need to be revoked, the resource can be quickly rolled back to this version to avoid data corruption. Thirdly, the freeze reason is encoded for easy terminal log recording. To ensure command delivery, the system waits for the terminal's confirmation after sending. If no confirmation is received within 100 milliseconds, it will automatically retry twice. If still no confirmation is received, the terminal is marked as offline and frozen pending confirmation. Commands will be pushed preferentially once the terminal comes back online, ensuring all conflicting terminals can receive the hibernation command. Upon receiving the command, the terminal immediately pauses local editing cache writing. The local editing cache is a temporary buffer allocated in local memory by the terminal to improve editing smoothness. In the storage area, when users edit resources, the text they input and the table data they modify are first stored in this cache, and then periodically synchronized to the server. If cache writing is not paused, user operations during the freeze period will still be stored in the cache, which may later conflict with data from other terminals. The specific process is as follows: After the terminal parses the token sleep command, it immediately calls the local cache management module to send a pause signal to the cache write interface. Upon receiving the signal, the interface immediately closes the write channel, prohibiting any new edit data from being stored in the cache. At the same time, the cache management module marks the current state of the cache as frozen read-only, allowing only reading of existing data in the cache, and disallowing modification or addition. The entire pause process is controlled within 20 milliseconds to ensure that users cannot still perform valid editing operations after the cache is frozen, avoiding... Subsequent data synchronization issues led to unsynchronized operation data being encapsulated into differential data packets and accompanied by state snapshot fingerprints. Unsynchronized operation data refers to operation records stored in the local editing cache before the terminal received the freeze command but not yet synchronized to the server. Discarding this data would result in lost user operations, while direct synchronization might cause conflicts. Therefore, it needs to be temporarily stored as differential data packets. Specifically, the terminal first uses a cache comparison tool to extract the difference data between the cache and the latest version on the server, i.e., the state rollback point version. For example, if page 5 of the server version document is empty, but page 5 in the cache contains 3 lines of text, these 3 lines of text constitute the difference data. Next, the difference data is organized into a JSON-formatted differential data packet according to a preset format, and then a state snapshot fingerprint is generated.This is a unique identifier for the complete content of the difference data packet. The packet content is encrypted using the SHA-256 algorithm to obtain a 32-bit string. Adding a fingerprint is for subsequent data synchronization after arbitration, where comparing the fingerprint confirms the data packet has not been tampered with, ensuring data integrity. Finally, the difference data packet and the state snapshot fingerprint are stored together in the terminal's local frozen temporary storage directory, with access permissions set to system-only read-only to prevent accidental deletion by users. Simultaneously, the editing interface is switched to read-only mode and a watermark layer is overlaid. Read-only mode means the terminal prohibits users from performing any editing operations on resources. Switching to this mode is to visually and functionally restrict access, allowing users to intuitively understand that they currently lack editing permissions, avoiding confusion caused by repeated attempts. The watermark layer is a semi-transparent indicator overlaid on the editing interface to reinforce the read-only prompt and prevent users from ignoring the interface status. The specific switching process is as follows:

[0057] The terminal first invokes the interface control module to disable all editing-related controls on the editing interface. This includes graying out the save, delete, and format painter buttons, and preventing the cursor from being positioned in the document editing area. When the user clicks these controls, a pop-up message appears stating that the operation token is frozen and editing is currently unavailable. Next, a preset watermark configuration is loaded. The watermark content reads "Operation token frozen, currently in read-only mode, awaiting arbitration results." The style is set to semi-transparent gray, the font is SimSun 14pt, italicized at 45 degrees, and the spacing is 50 pixels x 50 pixels, covering the entire editing area from the top left to the bottom right corner of the interface. The watermark layer is lower than the text content layer to ensure it does not obscure the document's readability; it serves only as a status indicator. The switching and watermark overlay processes occur simultaneously, taking no more than 30 milliseconds. Users experience virtually no delay and can quickly understand the current permission status. Finally, the token freeze state continues until the arbitration result is received or the system times out and resets the token. To avoid delays caused by arbitration... To prevent prolonged terminal freezing from impacting office work, the system employs a dual termination mechanism. First, arbitration result triggering: once the state synchronization protocol unit 3 generates an arbitration result, it immediately sends an arbitration command to all frozen terminals. Upon receiving the command, if a terminal determines it needs to retain its token, it deletes the difference data packet, resumes cache writing, switches back to edit mode, and deletes the watermark. If it determines it needs to release the token, it deletes the difference data packet, clears the local cache, and remains in read-only mode until the user abandons editing. Second, system timeout reset: if an arbitration result is not received for an extended period due to network failure or arbitration module malfunction, the system starts a timeout timer. The default timeout is set to 3 minutes, starting from when the token freezes. After the timeout, it automatically sends a timeout reset command to all frozen terminals. Upon receiving this command, the terminal automatically releases the token, clears the cache, switches to read-only mode, and pushes a notification to the user that the arbitration timeout has occurred and read-only mode has been restored, preventing indefinite terminal freezing. Regardless of the mechanism, the terminal will record the freeze duration, the reason for termination, and the result of differential data packet processing in the local operation log after the freeze state ends. This facilitates subsequent troubleshooting, ensures that the entire freeze process is controllable and traceable, avoids data conflicts, and protects the user's operating experience.

[0058] When generating a conflict arbitration request packet, the conflict terminal topology map data, original sequence summary of intent tags, and resource version snapshot are aggregated to construct an interactive arbitration matrix view. This view includes a three-dimensional timeline comparison module, an operation trajectory heatmap, and a one-click takeover button group. The data packet uses block compression encoding, and key data segments are appended with digital signatures. When sent to the target user terminal, the complexity of the data packet is adaptively adjusted according to the device type.

[0059] Further explanation is needed: after freezing the operation tokens of relevant terminals to prevent data conflicts caused by competitive editing across multiple terminals, relying solely on automatic system judgment cannot fully reflect the user's actual operational intentions. For example, the user may want to retain the temporary edited content on the mobile terminal, rather than assigning permissions based on device type priority by default. Therefore, state synchronization protocol unit 3 needs to generate a conflict arbitration request packet, integrating all key conflict data into a visual view for the user to make a manual decision, ensuring that the arbitration result meets the user's expectations. The specific implementation method is as follows:

[0060] When generating a conflict arbitration request packet, the conflict terminal topology map data, the original sequence summary of intent tags, and resource version snapshots are aggregated. Aggregation refers to integrating conflict-related data scattered across different modules according to a preset format, avoiding the need for users to switch between multiple interfaces when viewing arbitration information. The conflict terminal topology map data is the structured data corresponding to the previously constructed visualized network structure diagram; it is not a direct image transmission but contains the core attributes of each terminal node and node relationships. The original sequence summary of intent tags is a concise extract of the continuous non-editable action sequences of each terminal, rather than the full event stream. The summary includes the sequence start / end timestamps, core non-productive operation events, and a weighted total score, avoiding excessively large data packets due to transmitting the full sequence. The system allows users to clearly see the actual state of resources before a conflict, avoiding misjudgments due to incomplete information during arbitration. An interactive arbitration matrix view is constructed, comprising a 3D timeline comparison module, an operation trajectory heatmap, and a one-click takeover button group. This interactive arbitration matrix view is the core visualization interface for the arbitration request package, employing a modular design that allows users to view conflict details through clicks and zooms, rather than static images. The 3D timeline comparison module uses time as the X-axis, terminal ID as the Y-axis, and operation type as the Z-axis. The time interval for each terminal's intent label is displayed using corresponding colored bars, with overlapping time areas marked by red dashed borders. Clicking a bar brings up specific operation events within that time period, intuitively presenting the temporal relationship of the conflict. The operation trajectory heatmap is generated based on the operation records of each terminal one minute before the conflict. Using the editing interface of office resources as the base map, the heatmap uses light and dark colors to represent operation frequency. For example, if terminal A has intensive mouse clicks and text input on pages 4-6 of the document, the corresponding area on the heatmap will be dark red; if terminal B only has a few browsing operations on page 2, the corresponding area will be light red. This helps users determine which terminal has more in-depth operation on the resource, assisting in permission allocation decisions. A one-click takeover button group is located at the bottom of the view, with one button for each conflicting terminal to take over editing rights. There are also two auxiliary buttons: one for viewing full difference data and one for one-click rollback to the snapshot version. Users can quickly submit arbitration choices by clicking the corresponding buttons without manually entering commands, simplifying the operation process. Data packets are segmented... Block compression encoding addresses the issue that arbitration request packets, which aggregate various data types including topology maps, snapshots, and view configurations, can be quite large. Direct transmission of these packets is prone to timeouts or data loss due to network fluctuations. Block compression encoding, on the other hand, splits the data packet into multiple independent data blocks based on data type, with each block size controlled within 100KB. Each block is then processed individually using the GZIP compression algorithm, achieving a compression rate of 30%-50%. The advantages of block compression are: if a data block fails to transmit, only that block needs to be retransmitted, rather than the entire data packet, thus improving transmission fault tolerance; simultaneously, the terminal can parse data block by block, loading the view configuration block and timeline block first to allow the user to quickly see the core interface, and then loading the snapshot block and heatmap block in the background, avoiding interface lag caused by waiting for the full data.Subsequently, a digital signature is attached to the critical data segment. The critical data segment refers to the core data that directly affects the arbitration result, including the content hash of the resource version snapshot, the list of conflicting terminal IDs, and the weighted total score of intent tags. If this data is tampered with, it will cause serious permission chaos. Therefore, it is necessary to ensure its integrity and authenticity through digital signature. The specific process is as follows:

[0061] The system uses a dedicated private key, held only by the state synchronization protocol unit, and is updated periodically. It encrypts the content of critical data segments, generating a 128-bit digital signature. The signature information, including the signature generation time and private key version number, is appended to the end of the corresponding data segment. Upon receiving the data packet, the target user terminal calls the system's built-in public key, pairs it with the private key, and decrypts the signature on all collaborating terminals. If the decrypted data matches the content of the critical data segment, the data is considered tamper-proof, and the view loads normally. If decryption fails or the content does not match, a data error message is displayed, suggesting a re-acquisition of the arbitration packet to prevent arbitration errors caused by malicious attacks. Finally, when sending the data packet to the target user terminal, the complexity of the data packet is adaptively adjusted according to the device type. The target user terminal prioritizes the primary conflict terminal. If the primary conflict terminal is offline, a terminal used by the user within the last 30 minutes is selected to ensure the user can receive the arbitration request promptly. Device types include fixed workstations and mobile terminals. Different devices have significant differences in screen size, computing power, and network environment. Directly sending data packets of the same complexity may lead to slow loading or interface errors on mobile devices. The specific adjustment rules are as follows:

[0062] For fixed workstations, a complete complexity data package is distributed, including a high-definition heatmap, a fully detailed 3D timeline, and all difference data. Users can zoom in and out to view snapshot thumbnails and expand all operation events. For tablets, the heatmap details are simplified, retaining only high-frequency operation area annotations and removing low-frequency areas. The 3D timeline is converted to 2D, Z-axis operation types are hidden, and color differentiation is used. The snapshot thumbnail resolution is compressed. For mobile phones, it is further simplified to a core information list + simplified view, retaining only timeline comparisons, high-frequency operation area text descriptions, and one-click buttons. The heatmap and high-definition snapshots are removed to ensure the interface adapts to mobile phone screens and allows users to operate with one hand. When the data package is distributed, the system first detects the target terminal's device type, determines the complexity based on the hardware information associated with the terminal ID, and then loads the corresponding complexity configuration file to generate the data package. Through adaptive adjustment, it ensures that different devices can smoothly display the arbitration interface, guaranteeing users can efficiently complete permission decisions.

[0063] In this invention, the terminal behavior acquisition unit 1 captures operational behaviors and generates an event stream containing operation type and sensor status. The user behavior analysis unit 2 identifies non-editing action sequences, generates implicit abandonment intent tags, and triggers a conflict signal when multiple terminals' spatiotemporal overlap conflicts are detected. The status synchronization protocol unit 3 dynamically broadcasts permission instructions according to the tags. In case of conflict, the operation token is frozen and an arbitration packet is generated. The terminal collaboration unit 4 responds to the instructions to update the resource status or pops up an arbitration interface. This system solves the problems of ambiguous intent recognition, delayed permission synchronization, and lack of conflict handling, thereby improving office efficiency and data security.

[0064] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as defined by the appended claims and their equivalents.

Claims

1. A multi-terminal collaborative intelligent office internal management system, characterized in that, It includes a terminal behavior acquisition unit (1), which captures user operation behavior in real time to generate a raw operation event stream. The event stream includes operation type, timestamp, terminal device sensor status and interface focus status, and uploads it to the user behavior analysis unit (2). The user behavior analysis unit (2) identifies a continuous non-editing action sequence based on the original operation event flow, generates an intent label representing the user's implicit abandonment of the operation, and automatically triggers a conflict prediction signal and marks the conflicting terminal ID when it detects that the intent labels of the same user on multiple terminals have spatiotemporal overlap and conflict. After receiving the intent tag and conflict prediction signal, the state synchronization protocol unit (3) dynamically adjusts the state broadcast strategy: If there is only an implicit abandonment tag for a single terminal, then broadcast the operation permission release instruction to all collaborative terminals, including the released resource ID and intent tag type. In response to the operation permission release instruction, the terminal collaboration unit (4) immediately updates the local resource status to editable and renders the intent tag visual identifier on the interface. If a conflict prediction signal is present, the operation token of the relevant terminal is frozen, and a conflict arbitration request packet is generated and sent to the target user terminal. The terminal coordination unit (4) responds to the conflict arbitration request packet and pops up an arbitration interface for the user to manually confirm the operation ownership.

2. The intelligent office internal management system with multi-terminal collaboration according to claim 1, characterized in that: When the terminal behavior acquisition unit (1) generates the raw operation event stream, it captures user interaction events as basic data for operation types using operating system-level hook technology, specifically including: Document scrolling, cursor hover timeout, and window scaling actions simultaneously utilize the terminal device's built-in accelerometer and distance sensor to acquire 3D spatial displacement data as sensor status. The current application and its child windows are polled via the rendering engine interface to determine the interface focus status. All data is appended with a high-precision system clock timestamp and then encrypted to form a structured event stream. The timestamp is accurate to the millisecond level and includes a time zone identifier. The sensor status data includes the device's orientation angle and the quantized distance from the user. The interface focus status is differentiated into three levels: active in the foreground, suspended in the background, and minimized.

3. The intelligent office internal management system with multi-terminal collaboration according to claim 2, characterized in that: When the user behavior analysis unit (2) identifies a continuous non-editing action sequence, it uses a sliding window algorithm to slice the original operation event stream. The window length is dynamically adjustable. When a non-productive operation event is detected to occur a preset number of times in the window, sequence recognition is triggered. The non-productive operation events include document content zero input for a continuous duration exceeding a threshold, high-frequency tab switching without selecting an editing area, and mouse trajectory forming a closed shape in the non-working area. At the same time, it associates sensor status data and enhances the confidence of sequence recognition when the device remains stationary and the distance increases.

4. The intelligent office internal management system with multi-terminal collaboration according to claim 3, characterized in that: When generating intent labels representing implicit user abandonment of an operation, behavioral weights are assigned to the identified continuous non-editing action sequences. An abandonment intent probability model is constructed based on the correlation between operation types, with cursor hover timeout given the highest weight and window scaling action given the second highest weight. When the weighted total score of the sequence exceeds the dynamic threshold, a first-level abandonment label is generated. If the device sensor is simultaneously detected to return to a state far from the user, a second-level abandonment label is generated. The label data structure includes the sequence start timestamp, the main event type code, and the confidence score.

5. The intelligent office internal management system with multi-terminal collaboration according to claim 4, characterized in that: When a spatiotemporal overlap conflict is detected between intent tags of the same user on multiple terminals, a spatiotemporal coordinate system for user operations on multiple terminals is established. The time stamp of intent tag generation is used as the time axis base point, and the GPS positioning data of the terminal device is used as the spatial coordinate. When the time intervals of intent tags generated by two terminals of the same user overlap and the spatial distance between the devices is less than the collaboration radius within the preset conflict detection period, it is determined to be a spatiotemporal overlap conflict. The collaboration radius is dynamically configured according to the type of office scenario.

6. The intelligent office internal management system for multi-terminal collaboration according to claim 5, characterized in that: When a conflict prediction signal is triggered, a conflict terminal topology map is constructed. Based on the intent label confidence score and device usage priority, the primary conflict terminal and the secondary conflict terminal are marked. The primary conflict terminal is marked as a terminal with a high intent label confidence score and a device type of fixed workstation. At the same time, a conflict coding protocol data packet is generated. This data packet contains the conflict time interval fingerprint, spatial coordinate hash value, and a list of conflict terminal IDs. The terminal ID adopts a dual identification mechanism of device fingerprint and user account.

7. The intelligent office internal management system with multi-terminal collaboration according to claim 6, characterized in that: When broadcasting the operation permission release command to all collaborative terminals, a hierarchical broadcast strategy is adopted, and the broadcast delay parameter is selected according to the intent tag type, specifically including: The first-level abandonment of the label triggers real-time broadcasting, while the second-level abandonment of the label adopts a mild broadcasting mode with a random delay window. The instruction data packet encapsulates the distributed hash value of the resource ID and the intent label type code.

8. The intelligent office internal management system with multi-terminal collaboration according to claim 7, characterized in that: When updating the local resource status, the current rendering thread is interrupted to insert a high-priority status update transaction. A double buffering mechanism is used to avoid screen flickering. When the rendering intent label is visualized, a preset icon library is matched according to the type code, and a status change summary card is pushed to the system notification center.

9. The intelligent office internal management system for multi-terminal collaboration according to claim 1, characterized in that: When freezing the operation token of the relevant terminal, a token hibernation command is sent to the target terminal. This command carries the state rollback point version number. After receiving the command, the terminal immediately suspends local editing cache writing, encapsulates the unsynchronized operation data into a differential data packet and adds a state snapshot fingerprint. At the same time, the editing interface is switched to read-only mode and a watermark layer is superimposed. The token freeze state continues until the arbitration result is received or the system timeout reset command is received.

10. The intelligent office internal management system for multi-terminal collaboration according to claim 1, characterized in that: When generating a conflict arbitration request packet, the conflict terminal topology map data, original sequence summary of intent tags, and resource version snapshot are aggregated to construct an interactive arbitration matrix view. This view includes a three-dimensional timeline comparison module, an operation trajectory heatmap, and a one-click takeover button group. The data packet uses block compression encoding, and key data segments are appended with digital signatures. When sent to the target user terminal, the complexity of the data packet is adaptively adjusted according to the device type.

Images