Task management processing system based on multi-terminal cooperation

Abstract

This specification provides a task management and processing system based on multi-terminal collaboration. This system includes an authentication unit, a synchronization unit, a storage unit, a control unit, and a security unit. It processes user tasks across multiple terminals. By constructing an integrated processing system, it achieves unified authentication and session sharing of user identities, ensures real-time, consistent synchronization and reliable persistent storage of task states across multiple terminals, supports precise recovery from task breakpoints, ensures consistency of cross-terminal interaction through dynamic front-end interface adaptation and operation normalization, and provides security control throughout the entire communication, storage, and access process. This significantly improves the smoothness, reliability, and overall security of multi-terminal collaborative task processing.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of data processing technology, and in particular to a task management and processing system based on multi-terminal collaboration. Background Technology

[0002] In existing technologies, multi-terminal task management systems often face problems such as isolated identity authentication between terminals, delayed status synchronization, difficulty in seamlessly continuing tasks after interruption, operational confusion caused by differences in interaction logic between different terminals, and security risks in cross-network data transmission. These factors together restrict the efficiency of cross-terminal collaborative task processing and user experience.

[0003] Therefore, a better solution is urgently needed. Summary of the Invention

[0004] In view of this, the embodiments of this specification provide a task management and processing system based on multi-terminal collaboration to solve the technical defects existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a task management and processing system based on multi-terminal collaboration is provided. The system includes an authentication unit, a synchronization unit, a storage unit, a control unit, and a security unit, for processing user tasks on multiple terminals, wherein the processing steps include:

[0006] The authentication unit receives and verifies the user authentication credentials from the first terminal. After successful verification, it generates unified user session information and distributes it to the first and second terminals. A real-time communication connection is established between the first terminal, the second terminal and the backend service through the synchronization unit. When the first terminal modifies the task status, the backend service receives the task status change event sent by the first terminal and updates the maintained task status mapping table. Then, the status update information is pushed to the second terminal through the real-time communication connection. The task status data in the background service is persistently saved to the distributed database through the storage unit, and the task context is saved when a task interruption is detected, and the saved task status and task context are loaded from the distributed database when a task recovery request is received. The control unit dynamically adjusts the rendering state of interface elements on the first and second terminals based on the status update information obtained from the background service, and normalizes the interactive operations from different terminals into internal system events to maintain interaction consistency. The security unit verifies user session information during the establishment of real-time communication connections, encrypts and stores task status data, and records user operation logs.

[0007] In one possible implementation, generating unified user session information and distributing it to both the first and second terminals includes: After verifying the user's authentication credentials, an encrypted session token is generated. The session token contains user identity information, time-limited data, and terminal binding identifier. The session token is sent to the first terminal that initiated the login, and the session token is synchronously shared to the second terminal associated with the user's identity information through a secure channel; The terminal binding identifier is used to associate user session information with the device feature codes of the first and second terminals in the background service, so that when any terminal goes offline, the session state is managed by the other online terminals and is synchronously restored when the offline terminal comes back online.

[0008] In one possible implementation, the real-time communication connection established by the synchronization unit is a persistent connection based on the WebSocket or MQTT protocol, and the synchronization unit is configured with a protocol adaptive selection mechanism. The protocol adaptive selection mechanism includes dynamically switching between the WebSocket protocol and the MQTT protocol based on the current network latency and stability parameters of the first or second terminal to optimize communication efficiency.

[0009] In one possible implementation, the backend service also includes a conflict arbitration step; The conflict arbitration process includes: When conflicting status change events are received from the first terminal and the second terminal almost simultaneously, the final task status is determined by arbitration based on the timestamps carried by each event and the preset operation priority rules. The task status mapping table is then updated based on the final task status before being pushed. The operation priority rules are predefined based on the task operation type and the category of the initiating terminal, with approval operations from government desktop terminals being given higher priority than editing operations from mobile smart terminals.

[0010] In one possible implementation, the step of the storage unit persistently saving task state data to a distributed database includes: A complete task snapshot is saved according to a preset time strategy, and incremental change logs are recorded in real time. The task context includes task progress, runtime environment parameters, and uncommitted temporary data drafts. When loading the saved task state and task context, the storage unit performs data consistency verification. By comparing the time series of the complete task snapshot and the incremental change log, the accurate task state at the breakpoint is reconstructed.

[0011] In one possible implementation, the control unit dynamically adjusts the rendering state of interface elements, including: This is achieved through a dynamic rendering engine embedded in the front-end interface. The dynamic rendering engine responds to status update information and, in conjunction with the terminal device capability description file obtained from the back-end service, adapts and updates the button status, progress display, and layout and interaction logic of the operable areas in the interface in real time.

[0012] In one possible implementation, the steps for the security element to verify user session information include: Perform validity verification and role-based access control checks on the session token carried in each transmitted message; The security unit also integrates a session heartbeat monitoring mechanism, which periodically verifies the activity of session tokens, reclaims sessions that exceed the preset silent duration, and pushes a forced logout warning to all associated terminals through the synchronization unit before reclamation.

[0013] In one possible implementation, the security unit also runs a rule-based behavior analysis engine; The behavior analysis engine continuously monitors the operation sequence and frequency in the user operation log and compares them with the preset normal behavior profile model. When abnormal behavior patterns that deviate from the normal behavior profile model are detected, a security alarm is triggered and the operation permissions of the relevant tasks are temporarily frozen.

[0014] In one possible implementation, the storage unit uses a sharding strategy based on user geographic distribution and terminal access frequency in the distributed database, combined with an asynchronous replication strategy across data centers, to ensure high data availability and low latency for local access. The metadata for the sharding strategy is managed by the backend service.

[0015] In one possible implementation, the first terminal is a government desktop terminal, and the second terminal is a mobile smart terminal; The mobile smart terminal is equipped with a lightweight offline processing module. When the network is unavailable, the offline processing module takes over the user's operation and records it in a local temporary queue. After the network is restored, it will automatically synchronize with the background service. The government desktop terminal is equipped with a batch task scheduling module, which is used to process the set of tasks synchronized from the mobile smart terminal that are marked as pending batch processing.

[0016] This specification provides a task management and processing system based on multi-terminal collaboration. This system includes an authentication unit, a synchronization unit, a storage unit, a control unit, and a security unit. It processes user tasks across multiple terminals. By constructing an integrated processing system, it achieves unified authentication and session sharing of user identities, ensures real-time, consistent synchronization and reliable persistent storage of task states across multiple terminals, supports precise recovery from task breakpoints, ensures consistency of cross-terminal interaction through dynamic front-end interface adaptation and operation normalization, and provides security control throughout the entire communication, storage, and access process. This significantly improves the smoothness, reliability, and overall security of multi-terminal collaborative task processing. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of a task management and processing system based on multi-terminal collaboration, provided in one embodiment of this specification. Detailed Implementation

[0018] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0019] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0020] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0021] This specification provides a task management and processing system based on multi-terminal collaboration, which will be described in detail in the following embodiments.

[0022] See Figure 1 , Figure 1 This diagram illustrates a multi-terminal collaborative task management system according to an embodiment of this specification. The system includes an authentication unit, a synchronization unit, a storage unit, a control unit, and a security unit. It processes user tasks across multiple terminals. The processing steps include: receiving and verifying user authentication credentials from a first terminal via the authentication unit; generating unified user session information and distributing it to both the first and second terminals upon successful verification; establishing real-time communication connections between the first and second terminals and a background service via the synchronization unit; and receiving task status change events from the first terminal and updating the maintained task status mapping table when the first terminal modifies its task status. The system then updates the status information. The task status data is pushed to the second terminal via real-time communication connection; the task status data in the background service is persistently saved to the distributed database through the storage unit, and the task context is saved when a task interruption is detected, and the saved task status and task context are loaded from the distributed database when a task recovery request is received; the rendering state of the interface elements on the first and second terminals is dynamically adjusted through the control unit according to the status update information obtained from the background service, and the interactive operations from different terminals are normalized into internal system events to maintain interaction consistency; the user session information is verified during the establishment of the real-time communication connection through the security unit, and the task status data is encrypted for storage and transmission, while the user operation log is recorded.

[0023] The system comprises the following modules: Authentication Unit: This unit receives and verifies user credentials, generates and distributes session information, and is a fundamental module ensuring system access security. It integrates multiple authentication algorithms to achieve accurate user verification. Synchronization Unit: This unit establishes a real-time communication link between the terminal and the backend service, enabling real-time transmission of task status change information. It is a core module ensuring consistency across multiple terminals. Storage Unit: This unit is responsible for persistent storage of task data, backup of task context, and data loading for breakpoint recovery. It interacts with a distributed database to ensure data reliability and recoverability. Control Unit: This unit coordinates the rendering state of multiple terminal interfaces and unifies interactive operation specifications, ensuring a consistent user experience and data display across different terminals. Security Unit: This unit is responsible for session verification, data encryption, and operation log recording, providing comprehensive security for system data transmission, storage, and access. User Authentication Credentials: These are information carriers used by users to prove their identity, including but not limited to account and password combinations, dynamic verification codes, and biometric information. User Session Information: This is the unique identity information generated by the system after successful user authentication. It is used to confirm user identity throughout the interaction process and typically includes key information such as session tokens and validity periods. Task Status Change Event: This refers to the information packet triggered when an end user edits, approves, or deletes a task, informing the backend service of the change in task status. It includes core data such as task identifier, change type, and post-change status. Task Status Mapping Table: This is a data table maintained by the backend service that records the current status of all tasks and associated terminal information. It is the core data carrier for achieving multi-terminal status synchronization. Task Context: This refers to the relevant environment and progress information during task execution, including task progress, runtime environment parameters, and unsubmitted temporary data drafts, providing data support for task recovery after interruption. Distributed Database: This refers to a database system deployed using a distributed architecture, which can distribute data across multiple nodes, featuring high availability, high scalability, and low access latency. Interface Element Rendering Status: This refers to the display style and operable status of various interactive components on the terminal interface (such as buttons, progress bars, input boxes, etc.), dynamically adjusted by the system based on the task status.

[0024] The following detailed implementation example from a government office scenario will further illustrate the aforementioned system: In a government approval task management scenario, staff need to perform approval operations through a government desktop terminal (i.e., the first terminal) and at the same time, they can view the task progress in real time through a mobile smart terminal (i.e., the second terminal). The aforementioned task management and processing system based on multi-terminal collaboration needs to realize the synchronization of task information, operation collaboration, and data security between the two terminals.

[0025] The aforementioned system includes an authentication unit, a synchronization unit, a storage unit, a control unit, and a security unit. These units work together to manage and process multi-terminal tasks. The specific working process is as follows: First, staff members enter their account and password as user authentication credentials through the government desktop terminal. After receiving the credentials, the authentication unit verifies them using a password-salted hash verification algorithm. Upon successful verification, the authentication unit generates unified user session information containing a unique session token with a validity period of 8 hours. This information is then distributed through encrypted channels to both the government desktop terminal and the staff member's pre-bound mobile smart terminal, completing user authentication and session initialization.

[0026] Subsequently, the synchronization unit initiates the real-time communication connection establishment process, negotiating communication parameters with both the government desktop terminal and the mobile smart terminal to establish a real-time communication connection between the terminals and the backend service. When a staff member performs an "approval approved" operation on an approval task through the government desktop terminal, the government desktop terminal generates a task status change event containing a task identifier, a change type of "approval approved," and a change timestamp, and sends it to the backend service. Upon receiving the event, the backend service immediately updates the status information of the corresponding task in its maintained task status mapping table, updating the original status "pending approval" to "approved," and extracts the status update information, pushing it to the mobile smart terminal through the real-time communication connection established by the synchronization unit to ensure that the mobile terminal obtains the latest task status in real time.

[0027] While the background service updates the task status, the storage unit simultaneously initiates a data persistence process, encapsulating the updated task status data according to a preset format and writing it to the task status data table in the distributed database. If the task is interrupted due to a sudden power outage on the government desktop terminal, the storage unit detects the interruption signal and immediately collects the current task progress (e.g., approval process completion 80%), terminal operating environment parameters (e.g., operating system version, network configuration), and unsubmitted draft approval opinions, etc., and packages and stores them in the breakpoint recovery data table of the distributed database. When the staff restarts the terminal and initiates a task recovery request, the storage unit loads the corresponding task status data and task context information from the distributed database and pushes them to the background service, ensuring that the task can continue execution from the breakpoint.

[0028] The control unit obtains task status updates from the background service in real time and dynamically adjusts the rendering status of interface elements on both the government desktop terminal and the mobile smart terminal based on their device characteristics. For example, when the task status is updated to "Approved," the control unit instructs the government desktop terminal to set the corresponding "Approval" button to a grayed-out, unclickable state, while displaying a "Approval Completed" message at the top of the interface; it instructs the mobile smart terminal to add a "Approved" label to the task entry in the task list and update the progress display on the task details page to 100%. Simultaneously, the control unit unifies the "Approval" operation from the government desktop terminal and the "View Details" operation from the mobile smart terminal into internal "Task Status Change" and "Task Information Query" events, employing a unified event handling process to ensure consistency in interactive operations across different terminals.

[0029] During the establishment of a real-time communication connection by the synchronization unit, the security unit verifies the user session information sent by both terminals, checking the legality and validity of the session tokens. Only terminals that pass verification can successfully establish a communication connection. For task status data during transmission, the security unit uses the AES-256 encryption algorithm to ensure data transmission security. For task data stored in the distributed database, transparent data encryption technology is used for encrypted storage to prevent data leakage. Simultaneously, the security unit records all user operations in real time, including terminal type, operation time, operation content, task identifier, etc., generating and archiving user operation logs to provide data support for subsequent security audits.

[0030] The system operates as follows: A user initiates a login request through any terminal. After the authentication unit verifies the user's identity and obtains session information, the synchronization unit establishes a real-time communication connection, and the system enters a multi-terminal collaborative task processing state. When a user performs a task operation on a particular terminal, the background service receives a status change event and updates the mapping table. The synchronization unit pushes the updated information to other terminals, the storage unit performs data persistence and context backup, the control unit adjusts the interface rendering state, and the security unit ensures communication and data security throughout the process. This implementation method ensures that government staff can efficiently collaborate on approval tasks across different terminals, improving work efficiency.

[0031] The beneficial effects of this embodiment include at least the following: by constructing a multi-terminal collaborative task management and processing system integrating five major units—authentication, synchronization, storage, control, and security—real-time synchronization of task information and collaborative operation among multiple terminals are achieved, effectively improving task processing efficiency; through task context backup and breakpoint recovery mechanisms, data loss and repetitive work caused by task interruption are avoided, ensuring the continuity of task processing; through unified interactive operation normalization processing, the consistency of the operating experience for different terminal users is ensured; and through a full-process security protection design, the transmission, storage, and access security of task data are guaranteed, making it particularly suitable for scenarios such as government affairs with high requirements for security and collaboration.

[0032] In one possible implementation, generating unified user session information and distributing it to a first terminal and a second terminal includes: generating an encrypted session token after verifying the user authentication credentials; the session token containing user identity information, timeliness data, and a terminal binding identifier; sending the session token to the first terminal that initiated the login, and synchronously sharing the session token with the second terminal associated with the user identity information through a secure channel; the terminal binding identifier is used to associate the user session information with the device feature codes of the first terminal and the second terminal in a background service, so that when either terminal is offline, the session state is managed by the remaining online terminals and synchronously restored when the offline terminal comes back online.

[0033] Among them, user authentication credentials can refer to data submitted by users when logging into the system to prove their identity, such as a username and password combination, smart card, or biometric template, used to verify the legitimacy of the user's identity; encrypted session tokens can refer to strings generated after being processed by encryption algorithms, carrying user session information, and uniquely identifying the user's valid identity within the current login period; user identity information can refer to data fields encapsulated in the session token used to identify individual user attributes, to distinguish different users within the system and associate their operation permissions; timeliness data can refer to time control parameters contained in the session token, used to limit the valid start and end times of the session; terminal binding identifiers can refer to terminal association markers generated and stored together with the session token, which can lock a specific session to the terminal device that initiated the login; the first terminal can refer to the device used when the user first initiates an authentication request, serving as the initial distribution target of the session token; the second terminal can refer to other terminal devices associated with the user's identity information besides the first terminal, used to receive the synchronously shared session token; and a secure channel. This can refer to an encrypted communication link established at the network transport layer, ensuring the confidentiality and integrity of the session token during distribution; a background service can refer to a software module running on the server side, responsible for handling authentication logic and session management, to centrally maintain the association between user session information and terminals; a device identifier can refer to the unique hardware or software identifier of the terminal device, such as IMEI, MAC address, or device certificate serial number, used to establish the binding relationship between the session token and the specific terminal in the background service; session state can refer to the user's activity context during the current login period, including authenticated identity, active task list, and interface operation permissions, enabling the maintenance of user work continuity across terminals; online terminal hosting can refer to the temporary takeover of the session state of an offline terminal by other online terminals when a bound terminal goes offline, to ensure uninterrupted user tasks; offline terminal re-entry can refer to the process where an offline terminal device restores its network connection and re-establishes communication with the background service, used to synchronously restore its session state and task progress during the offline period from the hosted terminal or background service.

[0034] As a concrete example: Suppose user Li Si uses the government desktop terminal T-101 as the primary terminal in the government service hall, submitting user authentication credentials by inserting a USB key and entering a six-digit PIN code. After successful verification by the authentication unit, a session token encrypted with the AES algorithm is generated. The user identity information embedded in this token is "Li Si, employee number GZ-2047," the validity period is set to "valid for four hours from the time of generation," and the terminal binding identifier is "bound to T-101." The session token is first sent to the government desktop terminal T-101. Subsequently, the background service synchronously shares the session token with Li Si's mobile smart terminal (device model Ph) through a secure channel established by the TLS protocol. (OneX, device identifier is MAC address); Five minutes later, the government desktop terminal T-101 went offline due to an unexpected power outage for maintenance. The backend service detected the offline event based on the terminal binding identifier and immediately transferred the entire session state of T-101 to Li Si's mobile smart terminal. At this time, Li Si could still view his to-do list and continue operating on the mobile terminal. Twenty minutes later, the government desktop terminal T-101 restarted and connected to the network, sending an online request to the backend service. After verifying the terminal device identifier, the backend service fully synchronized the session state managed on the mobile smart terminal back to T-101. Li Si's task interface on the government desktop terminal was restored to the exact state before offline, without the need to log in again.

[0035] This embodiment achieves cross-terminal authentication status sharing and offline session hosting by using a unified user session information generation and distribution mechanism, combined with the association management of terminal binding identifiers and device feature codes. This significantly improves the identity consistency and operational continuity of the multi-terminal collaborative task management system, avoids repeated authentication and task interruption caused by terminal offline or switching, optimizes the seamless working experience for users between government desktop terminals and mobile smart terminals, and ensures the security of identity data transmission throughout the entire process through encrypted session tokens and secure channels.

[0036] In one possible implementation, the real-time communication connection established by the synchronization unit is a persistent connection based on the WebSocket or MQTT protocol, and the synchronization unit is configured with a protocol adaptive selection mechanism. The protocol adaptive selection mechanism includes dynamically switching between the WebSocket protocol and the MQTT protocol based on the current network latency and stability parameters of the first or second terminal to optimize communication efficiency.

[0037] Among them, WebSocket protocol: refers to an application layer protocol that performs full-duplex communication over a single TCP connection, supports real-time data transmission between clients and servers, and features low latency and long connection duration, making it suitable for scenarios with frequent data interaction. MQTT protocol: refers to a lightweight IoT communication protocol based on a publish / subscribe model, featuring low overhead, low power consumption, and strong network adaptability, suitable for scenarios with limited network bandwidth or poor stability. Persistent connection: refers to a long-term, stable communication connection established between the terminal and the backend service. Once established, the connection is maintained continuously without needing to re-establish it before each data transmission, reducing connection establishment overhead and improving communication efficiency. Protocol adaptive selection mechanism: refers to a decision-making mechanism built into the synchronization unit that dynamically selects the optimal communication protocol based on the terminal's network status. Its core is to evaluate network quality by collecting network parameters and matching the corresponding communication protocol. Network latency: refers to the total time required for data to be sent from the terminal to the backend service, and then for the backend service to send response data back to the terminal; it is a key indicator for evaluating network communication efficiency. Stability parameters: refer to parameters used to characterize the stability of network connections, including packet loss rate and connection interruption frequency, and are important bases for evaluating network reliability.

[0038] The following detailed implementation of the aforementioned multi-terminal collaborative task management and processing system will be further illustrated through a government office scenario: In the aforementioned government approval task management scenario, the synchronization unit, as the core collaborative module of the aforementioned system, needs to adapt to different network environments such as government desktop terminals (usually in a stable local area network environment) and mobile smart terminals (which may be in a 4G / 5G mobile network or an unstable WiFi environment). Therefore, the synchronization unit adopts a persistent connection based on the WebSocket protocol or the MQTT protocol and is configured with a protocol adaptive selection mechanism to ensure communication efficiency and stability under different network environments.

[0039] The synchronization unit incorporates a protocol adaptation module and a network parameter acquisition module. The network parameter acquisition module is responsible for collecting network latency and stability parameters from the first terminal (government desktop terminal) and the second terminal (mobile smart terminal) in real time. Specifically, the network parameter acquisition module obtains network latency data by periodically sending probe data packets to the terminals and calculating the round-trip time of the data packets; it also calculates the data packet loss rate by statistically analyzing the number of probe data packets lost within a preset time period, and records the number and duration of connection interruptions as core indicators of stability.

[0040] The protocol adaptive selection mechanism presets two sets of protocol trigger thresholds: when network latency is ≤50ms and packet loss rate is ≤1%, the network quality is considered excellent, and the WebSocket protocol is selected first; when network latency is >50ms or packet loss rate is >1%, the network quality is considered average or poor, and the MQTT protocol is switched to. After the synchronization unit starts, it first collects the initial network parameters of the two terminals through the network parameter acquisition module. If the government desktop terminal is in the unit's local area network environment, the collected network latency is 20ms and the packet loss rate is 0.2%, which meets the WebSocket protocol trigger threshold, and the synchronization unit establishes a persistent connection with the government desktop terminal based on the WebSocket protocol; if the mobile smart terminal is in an outdoor 4G network environment, the collected network latency is 80ms and the packet loss rate is 2.5%, which triggers the MQTT protocol selection condition, and the synchronization unit establishes a persistent connection with the mobile smart terminal based on the MQTT protocol.

[0041] During system operation, the network parameter acquisition module continuously collects network parameters from both terminals. When a change in the network environment of the mobile smart terminal is detected (e.g., staff entering indoors to connect to stable WiFi), the network latency drops to 35ms, the packet loss rate drops to 0.5%, and this state persists for more than 30 seconds, the protocol adaptive selection mechanism determines that the network quality meets the conditions for using the WebSocket protocol and automatically triggers the protocol switching process. The synchronization unit first sends a protocol switching notification to the mobile smart terminal. After the terminal confirms, the current MQTT protocol connection is disconnected, and a persistent connection based on the WebSocket protocol is re-established to ensure improved data transmission efficiency. If a sudden increase in network latency to 120ms and a packet loss rate to 5% are detected on the government desktop terminal due to a local area network failure, the protocol adaptive selection mechanism triggers a switch to the MQTT protocol to avoid communication interruptions caused by degraded network quality.

[0042] When staff complete the approval process through the government desktop terminal, the background service generates status update information. The synchronization unit then quickly pushes the information to the government desktop terminal via the WebSocket protocol. Simultaneously, based on the current communication protocol of the mobile smart terminal, if it is the MQTT protocol, the status update information is published to the corresponding topic through the MQTT publish / subscribe mode. The mobile smart terminal receives this information as a subscriber, ensuring that both terminals can obtain task status updates in real time.

[0043] The beneficial effects of this embodiment include at least the following: by adopting a persistent connection method that combines the WebSocket protocol and the MQTT protocol, and configuring a protocol adaptive selection mechanism, the synchronization unit can dynamically adjust the communication protocol according to the actual network environment of the terminal. When the network quality is good, the high transmission efficiency of the WebSocket protocol is utilized, and when the network quality is poor, the strong adaptability of the MQTT protocol is utilized. This effectively improves the stability and efficiency of communication between multiple terminals and the background service, avoids the limitations of a single protocol in complex network environments, and ensures the smoothness of multi-terminal collaborative task processing.

[0044] In one possible implementation, the backend service also includes a conflict arbitration step; The conflict arbitration process includes: When conflicting status change events are received from the first terminal and the second terminal almost simultaneously, the final task status is determined by arbitration based on the timestamps carried by each event and the preset operation priority rules. The task status mapping table is then updated based on the final task status before being pushed. The operation priority rules are predefined based on the task operation type and the category of the initiating terminal, with approval operations from government desktop terminals being given higher priority than editing operations from mobile smart terminals.

[0045] The conflict arbitration process refers to a built-in backend service procedure for resolving state conflicts arising from multiple terminals initiating task state change operations nearly simultaneously. Its core is determining the optimal task state through preset rules. A conflict state change event refers to a state change event initiated by two or more terminals on the same task within a very short time (usually within 1 second), potentially leading to inconsistent task states. A timestamp refers to the precise time information when a state change event is generated, typically recorded with millisecond precision, used to determine the order in which events are initiated. Operation priority rules refer to a set of predefined rules used by the system to distinguish the priority of different types of operations and operations initiated by different terminals; this is the core basis for conflict arbitration. Approval operations refer to operations that make critical decisions regarding whether a task is approved or rejected, directly determining the task's flow direction and possessing irreversible characteristics. Editing operations refer to operations that modify the basic information of a task (such as task name, description, and responsible person), typically not affecting the core flow state of the task. The following detailed implementation of the multi-terminal collaborative task management system, using a government approval task management scenario, further illustrates this process. In the aforementioned government approval task management scenario, in addition to undertaking the functions of task status update and information push, the backend service also integrates a conflict arbitration module to perform conflict arbitration steps and resolve the conflict problem when the first terminal (government desktop terminal) and the second terminal (mobile smart terminal) initiate task status change operations almost simultaneously.

[0046] The system predefines operation priority rules, which are clearly defined: operation priorities from highest to lowest are "approval operations from government desktop terminals," "editing operations from government desktop terminals," "approval operations from mobile smart terminals," and "editing operations from mobile smart terminals," with approval operations from government desktop terminals having the highest priority and editing operations from mobile smart terminals having the lowest priority. Additionally, each task status change event generated by each terminal carries a timestamp accurate to milliseconds, serving as supplementary evidence for conflict arbitration.

[0047] When a specific approval task is in the "pending approval" state, staff member A initiates an approval operation of "approved" through the government affairs desktop terminal. At the same time, staff member B (a collaborator) initiates an editing operation of "modify the person in charge" for the task through a mobile smart terminal. The time interval between the two operations is 300 milliseconds, which is a conflicting state change event initiated almost simultaneously. The background service receives these two events almost at the same time.

[0048] After receiving two conflict events, the conflict arbitration module of the backend service first extracts the operation type, initiating terminal category, and timestamp information carried by the two events. Analysis shows that the operation initiated by the government desktop terminal is an approval operation, while the operation initiated by the mobile smart terminal is an editing operation. According to the preset operation priority rules, the approval operation from the government desktop terminal has a higher priority than the editing operation from the mobile smart terminal. Therefore, the conflict arbitration module directly determines that the "approval passed" operation initiated by the government desktop terminal is valid, and determines the final task status as "approval passed."

[0049] If two conflicting events involve operations of the same priority, for example, if staff member A initiates an "approval approved" operation through a government affairs desktop terminal, and staff member C initiates an "approval rejected" operation through another government affairs desktop terminal, both operations are approval-related operations on the government affairs desktop terminal and have the same priority. In this case, the conflict arbitration module will use the timestamp as the basis, determining that the event with the earlier timestamp is valid and identifying the corresponding task status as the final status.

[0050] After determining the final task status, the conflict arbitration module sends the final status information to the status update module of the background service. The status update module updates the task status mapping table based on the final task status, and then pushes the final status update information to the first terminal and the second terminal through the synchronization unit. At the same time, it sends a prompt message "Operation conflict, high priority operation result has been adopted" to the terminal that initiated the low priority operation, ensuring that the task status of all terminals remains consistent.

[0051] The beneficial effects of this embodiment include at least the following: by setting a conflict arbitration step in the background service, and combining timestamps and preset operation priority rules to resolve state conflicts caused by near-simultaneous operations of multiple terminals, the uniqueness and consistency of task states are ensured; by prioritizing the effectiveness of high-importance operations (such as approval operations on government desktop terminals), the system meets the requirements of seriousness and standardization of task processing in government and other scenarios, avoids task flow chaos caused by invalid or erroneous operations, and improves the reliability and availability of the system.

[0052] In one possible implementation, the step of the storage unit persistently saving task state data to a distributed database includes: A complete task snapshot is saved according to a preset time strategy, and incremental change logs are recorded in real time. The task context includes task progress, runtime environment parameters, and uncommitted temporary data drafts. When loading the saved task state and task context, the storage unit performs data consistency verification. By comparing the time series of the complete task snapshot and the incremental change log, the accurate task state at the breakpoint is reconstructed.

[0053] The system includes the following features: **Preset Time Strategy:** Rules pre-configured to determine the frequency of saving complete task snapshots. These can be flexibly set based on task importance and data update frequency. **Complete Task Snapshot:** A complete backup of the current state and related data of all tasks at a preset time point, essentially a "panoramic record" of task data at that point in time. **Incremental Change Log:** Log data that records every change to the task state since the last complete snapshot, recording only the changed information, including change time, change content, and previous state. **Data Consistency Verification:** The process where the storage unit verifies data integrity and accuracy by comparing relevant information from different data sources (complete task snapshots and incremental change logs) when loading data, ensuring the loaded data is authentic and valid. **Time Series:** Time information from complete task snapshots and incremental change logs arranged chronologically, used to trace the task state change process and ensure the accuracy of state reconstruction. **Breakpoint:** The specific time point when a task interruption occurs, the point at which the task needs to be restarted upon recovery.

[0054] The following detailed implementation of the aforementioned multi-terminal collaborative task management system will further illustrate this through a specific example in a government affairs approval task management scenario: In the aforementioned government approval task management scenario, the storage unit undertakes the core functions of task data persistence, context backup, and breakpoint recovery. The step of persistently saving task status data to the distributed database is achieved by combining complete task snapshots with incremental change logs, while ensuring the accuracy of breakpoint recovery data through data consistency verification.

[0055] The system's default time strategy is to save a complete task snapshot every 2 hours, while simultaneously recording incremental change logs for each task status change in real time. The storage unit has a built-in snapshot generation module and a log recording module. The snapshot generation module automatically collects the current status (e.g., pending approval, under approval, approved, rejected), basic task information (task name, number, responsible person, deadline, etc.), and associated terminal information of all tasks in the distributed database at preset times such as 0:00, 2:00, 4:00...22:00 each day. It then packages these information into a complete task snapshot, named in the format "snapshot_year_month_date_time," and stores it in the snapshot storage partition of the distributed database, while also recording the precise timestamp of the snapshot generation.

[0056] The logging module collects incremental change information in real time every time the task status changes, including the change time (accurate to milliseconds), task identifier, state before change, state after change, terminal type initiating the change, and operator information. It generates incremental change log entries according to a preset log format and writes them to the log storage partition of the distributed database, ensuring that every change is traceable. When a task interruption is detected (such as terminal power failure, program crash, network interruption, etc.), the context backup module of the storage unit immediately starts, collecting the current task context information, specifically including task progress (such as which steps of the approval process have been completed and which node it is currently at), runtime environment parameters (such as terminal operating system version, CPU utilization, memory usage, network configuration information), and unsubmitted temporary data drafts (such as unsubmitted approval comments from staff, half-finished task descriptions, etc.). This information is bound to the task identifier and interruption timestamp and stored in the context storage partition of the distributed database.

[0057] When a worker initiates a task recovery request, the storage unit's recovery module first queries the corresponding task context information from the distributed database based on the task identifier to obtain the timestamp of the task interruption (i.e., the breakpoint time). Then, the recovery module queries the most recent complete task snapshot before the breakpoint time; for example, if the breakpoint time is 10:30 AM, the most recent complete task snapshot would be the one generated at 10:00 AM. Next, the recovery module extracts all incremental change log entries from the complete task snapshot to the breakpoint time and sorts these log entries according to their time sequence.

[0058] Next, the recovery module performs data consistency verification: First, it checks the timestamp of the complete task snapshot with the timestamp of the incremental change log entries to ensure that all extracted incremental change logs are generated after the snapshot and before the breakpoint. Then, it compares the change records of the same task in the incremental change log to check for logical conflicts (such as two different post-change states at the same time point). If a conflict exists, it is marked as an anomaly and the log entry with the earlier timestamp is used. Finally, it verifies whether the task state in the complete task snapshot and the task state obtained by superimposing all incremental change log entries are logically consistent to ensure the integrity and accuracy of the data.

[0059] After data consistency verification passes, the recovery module uses the complete task snapshot as a basis and applies incremental change log entries sequentially according to the time sequence to reconstruct the precise task status at the breakpoint. For example, in the complete task snapshot at 10:00 AM, a task status is "Pending Approval." The incremental change log at 10:15 AM records that the task has changed to "Under Approval." If the task is interrupted at 10:30 AM, the recovery module overlays the snapshot status with the 10:15 AM change log to reconstruct the task status at the breakpoint as "Under Approval." Simultaneously, it loads the corresponding task context information (such as the approval progress at the time of interruption, unsubmitted approval comments, etc.) and pushes it to the backend service. The backend service then pushes this information to the corresponding terminals, allowing staff to continue processing the task from the breakpoint without having to start over.

[0060] The beneficial effects of this embodiment include at least the following: by combining complete task snapshots with incremental change logs for persistence, the resource consumption of snapshot saving is reduced while ensuring that every task change is accurately recorded; the task context backup mechanism provides comprehensive data support for task recovery after interruption; and the data consistency verification and time series reconstruction ensure the accuracy of the task status at the breakpoint, avoid data loss or errors, and guarantee the continuity of task processing, which is especially suitable for tasks such as government approvals with long processing cycles and high data importance.

[0061] In one possible implementation, the control unit dynamically adjusts the rendering state of interface elements, including: This is achieved through a dynamic rendering engine embedded in the front-end interface. The dynamic rendering engine responds to status update information and, in conjunction with the terminal device capability description file obtained from the back-end service, adapts and updates the button status, progress display, and layout and interaction logic of the operable areas in the interface in real time.

[0062] The dynamic rendering engine, embedded in the terminal's front-end interface, is a core engine that dynamically adjusts the display state and interaction logic of interface elements based on external commands and data. It is a key component for achieving adaptive interface design. The terminal device capability description file records information such as the terminal device's hardware characteristics, software environment, and interface display parameters, including terminal type (desktop / mobile), screen size, resolution, operating system version, and supported interaction methods. Button states indicate the interactive state of operation buttons on the interface, including clickable, non-clickable (grayed out), selected, and unselected, directly reflecting whether the operation is available in the current task. Progress display shows elements on the interface used to display the task completion progress, including progress bars, percentage numbers, and stage markers, intuitively reflecting the current processing stage of the task. The layout of operable areas arranges the areas on the interface where users can interact, requiring adaptation based on the terminal's screen size and device characteristics to ensure ease of operation. Interaction logic refers to the interface and system's response rules after a user interacts with interface elements, ensuring consistent response methods across different terminals.

[0063] The following detailed implementation of the aforementioned multi-terminal collaborative task management system will further illustrate this through a specific example in a government affairs approval task management scenario: In the aforementioned government approval task management scenario, the control unit uses a dynamic rendering engine embedded in the front-end interface of government desktop terminals and mobile smart terminals to dynamically adjust the rendering state of interface elements, ensuring that different terminals can obtain an interface display and interactive experience adapted to their own device characteristics when the task status is updated.

[0064] First, when the terminal establishes a connection with the backend service for the first time, the backend service sends a device capability collection request to the terminal. After responding to the request, the terminal encapsulates its own device capability information (government desktop terminal: 27-inch screen size, 2560×1440 resolution, Windows 11 operating system, supports mouse and keyboard interaction; mobile smart terminal: 6.7-inch screen size, 2400×1080 resolution, Android 14 operating system, supports touch interaction) into a terminal device capability description file, and sends it to the backend service for storage. The control unit can retrieve this description file from the backend service at any time to provide a basis for interface adaptation.

[0065] The dynamic rendering engine is embedded in the front-end interface code of the terminal, and listens for status update information from the control unit in real time. When the background service pushes the task status update information to the control unit through the synchronization unit, the control unit immediately parses the status update information, extracts core information such as task identifier, new task status, and change time, and then sends the interface adjustment instruction to the corresponding terminal. At the same time, it also passes the terminal device capability description file obtained from the background service to the dynamic rendering engine.

[0066] Taking the update of an approval task status from "Pending Approval" to "Approving" as an example: For government desktop terminals, after the dynamic rendering engine responds to the interface adjustment command, it makes the following interface adjustments based on the device capability description file (large screen, supports mouse and keyboard interaction): The "Initiate Approval" button corresponding to the task is set to gray and unclickable, while the "Cancel Approval" button is set to clickable; a progress bar is added to the task details area, showing a progress of 30% (corresponding to the first node of the approval process), and the name of the current approval node is marked below the progress bar; the layout of the operable area is maintained in a multi-column distribution, with the approval opinion input box, attachment upload area, and collaborator selection area arranged on the left side of the interface, and the task history area arranged on the right side, making it convenient for staff to operate quickly with mouse and keyboard.

[0067] For mobile smart terminals, the dynamic rendering engine is adapted to its device capability description file (small touch screen): the "Initiate Approval" button is grayed out and not clickable, while the "Cancel Approval" button is clickable, but its size is appropriately enlarged for easier touch operation; the progress display uses a circular progress bar with percentage numbers, placed below the task name for greater intuitiveness; the layout of the operable area is adjusted to a single-column vertical distribution, with the approval opinion input box, attachment upload area, and collaborator selection area arranged sequentially to avoid accidental touch operations; at the same time, the interaction logic is optimized, the pop-up keyboard of the input box is set to a simplified mode suitable for mobile devices, and attachment upload supports direct photo upload, conforming to the usage habits of mobile terminals.

[0068] If the task status is further updated to "Approved", the dynamic rendering engine will respond to the adjustment command again: For both terminals, the operation buttons such as "Initiate Approval" and "Cancel Approval" will be set to an unclickable state, the progress display will be updated to 100% and marked with the words "Approved"; the government desktop terminal will display a green success prompt box at the top of the interface, while the mobile smart terminal will display the prompt information in the form of a pop-up window. At the same time, the operable areas of both terminals will be updated with subsequent operation buttons such as "Print Approval Result" and "Export Task Report", and the interaction logic will be consistent (clicking the button will trigger the file generation and download process).

[0069] The beneficial effects of this embodiment include at least the following: by embedding a dynamic rendering engine and combining it with the terminal device capability description file to achieve dynamic adaptation and adjustment of interface elements, it not only ensures the consistency and accuracy of the interface display when the task status of multiple terminals is updated, but also takes into account the characteristic differences of different terminal devices, thereby improving the ease of operation for users of each terminal; by unifying the interaction logic, it avoids the confusion caused by the difference in operation methods when switching between different terminals, reduces the learning cost, and further improves the efficiency of multi-terminal collaborative task processing.

[0070] In one possible implementation, the steps for the security element to verify user session information include: Perform validity verification and role-based access control checks on the session token carried in each transmitted message; The security unit also integrates a session heartbeat monitoring mechanism, which periodically verifies the activity of session tokens, reclaims sessions that exceed the preset silent duration, and pushes a forced logout warning to all associated terminals through the synchronization unit before reclamation.

[0071] The system includes the following components: Session Token: A unique identifier string generated by the system after successful user authentication. It contains encrypted data such as user identity information and session validity duration, serving as the core carrier of session information. Legality Verification: The security unit verifies the validity of the session token carried in the transmitted message, including verifying the token's format, whether it has been tampered with, and whether it is within its validity duration. Role-Based Access Control: Based on the user's role (e.g., administrator, regular staff, viewer), the system checks whether the user has the permission to perform the current operation or access the current data, representing the core method of access control. Session Heartbeat Monitoring Mechanism: A built-in monitoring mechanism within the security unit that periodically sends heartbeat packets to verify the session token's activity status, used to promptly detect invalid sessions. Heartbeat Packet: A small detection message periodically sent between the security unit and the terminal to confirm the session connection's normality and the user's activity. Preset Inactivity Duration: The maximum allowed time for a user to remain inactive, as set in advance. Exceeding this duration indicates an inactive session that must be reclaimed. Session revocation: This refers to the security unit marking inactive session tokens as invalid, terminating the corresponding user session, and revoking the user's system access permissions to ensure system security. Forced logout warning: This refers to a notification message pushed by the system to associated terminals before session revocation, informing the user that the session is about to expire and they need to log in again to avoid data loss due to session expiration.

[0072] The following detailed implementation of the aforementioned multi-terminal collaborative task management system will further illustrate this through a specific example in a government affairs approval task management scenario: In the aforementioned government approval task management scenario, the security unit serves as the core of the system's security protection. Through session token verification, permission checks, and session heartbeat monitoring mechanisms, it comprehensively safeguards user session security and prevents security risks such as unauthorized access and session hijacking.

[0073] The specific steps for the security unit to verify user session information are as follows: After successful user authentication, the user session information generated by the authentication unit contains a unique session token. This token is encrypted using the AES encryption algorithm and contains core information such as user ID, assigned role (e.g., government approval administrator, general approval personnel, task viewer), session generation time, and validity period. When the terminal transmits data with the backend service, this session token is carried in the header of each transmission message. After receiving the transmission message, the security unit's token verification module first extracts the session token from the message header, decrypts the token using the corresponding decryption algorithm, and verifies whether the token format conforms to the system's preset specifications (e.g., token length, character combination rules, etc.). If the format is incorrect, the message is directly rejected, and a "session token invalid" message is sent to the terminal.

[0074] After the format verification passes, the token verification module further verifies whether the token has been tampered with. It compares the checksum in the token with the checksum recalculated by the system. If they do not match, the token is determined to have been tampered with, message transmission is rejected, and a security log is recorded. If the token has not been tampered with, the validity period of the token is checked to determine whether the current time is within the validity period of the token. If it has expired, the message is rejected and the message "Session expired, please log in again" is displayed.

[0075] After the legitimacy verification passes, the security unit's permission check module initiates a role-based access control check. The permission check module extracts the user's role from the decrypted session token, queries the system's preset role permission table (e.g., approval administrators have permissions to approve, modify, delete tasks, and view all tasks; ordinary approvers have permissions to approve and view tasks they are responsible for; task viewers only have permissions to view tasks), and combines this with the operation type corresponding to the current message (e.g., approval, task modification, task viewing) to check whether the user role has the corresponding operation permission. For example, if a task viewer initiates an approval operation, the permission check module determines that the operation is not authorized, refuses to execute, and provides a "No permission for this operation" message.

[0076] Meanwhile, the security unit integrates a session heartbeat monitoring mechanism. The system's preset heartbeat monitoring cycle is 30 seconds, and the preset silence duration is 30 minutes. Every 30 seconds, the security unit's heartbeat monitoring module sends a heartbeat packet to all terminals with established sessions. The heartbeat packet contains a session token verification request. After receiving the heartbeat packet, if the user is in an active state (i.e., has performed an operation within 30 seconds), the terminal automatically responds to the heartbeat packet, carrying the current session token back to the security unit; if the user is in a silent state (has not performed any operation within 30 seconds), the terminal will still respond to the heartbeat packet, but will be marked as "silent".

[0077] The heartbeat monitoring module analyzes the received heartbeat responses. If no heartbeat response is received from a terminal multiple times (e.g., twice), or if the terminal remains in a "silent" state for 25 minutes (approaching the preset silence duration of 30 minutes), a forced logout warning message stating "Session is about to expire; please click 'Confirm' to continue use" is pushed to that terminal and other associated terminals (such as government desktop terminals and mobile smart terminals bound to the same user). If no confirmation is received from the user within 5 minutes (i.e., the silence duration reaches 30 minutes), the heartbeat monitoring module performs a session recycling operation, marking the session token as invalid, updating the system's session management table, and simultaneously pushing a "Session expired; forced logout" message to all associated terminals via the synchronization unit. Upon receiving the message, the terminal automatically exits the login interface. If the user clicks 'Confirm' within 5 minutes, the silence duration timer is reset, and the session remains valid.

[0078] The beneficial effects of this embodiment include at least the following: by performing full-process legality verification on the session token in each transmitted message, unauthorized users are effectively prevented from accessing the system by forging tokens; by implementing role-based access permission checks, fine-grained permission control is achieved, ensuring that users of different roles can only perform operations within their own permission scope, preventing data leakage and misoperation; and by using a session heartbeat monitoring mechanism and a silent session recycling strategy, the security risks caused by long-term inactive sessions are avoided, and by pushing forced logout warnings in advance, the security of user operation data is protected, thereby improving the overall security and reliability of the system.

[0079] In one possible implementation, the security unit also runs a rule-based behavior analysis engine; The behavior analysis engine continuously monitors the operation sequence and frequency in the user operation log and compares them with the preset normal behavior profile model. When abnormal behavior patterns that deviate from the normal behavior profile model are detected, a security alarm is triggered and the operation permissions of the relevant tasks are temporarily frozen.

[0080] The system includes the following components: **Rule-based Behavior Analysis Engine:** This refers to the core engine built into the security unit that analyzes and judges user behavior based on preset rules, identifying normal and abnormal behavior. **Operation Sequence:** This refers to the sequential order of a series of operations performed by a user within a certain time period. For example, "login → view task → initiate approval → logout" constitutes a complete operation sequence. **Operation Frequency:** This refers to the number of times a user performs a certain type of operation within a unit of time. For example, initiating 5 approval operations within 1 minute or viewing 20 different tasks within 10 minutes. **Normal Behavior Profile Model:** This refers to a model constructed by the system based on a large amount of historical normal user operation data to characterize the features of normal user behavior. It includes core features such as normal operation sequence patterns, operation frequency ranges, and operation time ranges. **Abnormal Behavior Patterns:** These refer to user behavior patterns that deviate from the normal behavior profile model, potentially indicating security risks (such as account theft or malicious operations). **Security Alerts:** These are warning messages triggered by the system after detecting abnormal behavior patterns, used to notify system administrators and relevant users. They include details of the abnormal behavior, the time of occurrence, associated users, and terminals. Temporarily freeze access to related tasks: This means that after the system detects abnormal behavior, it temporarily restricts the user's access to related tasks to prevent further losses caused by abnormal operations. The freeze will be lifted after the security risk is eliminated.

[0081] The following detailed embodiments, based on the aforementioned multi-terminal collaborative task management system and the session security mechanism in claim 7, further illustrate the process through a government approval task management scenario: In the aforementioned government approval task management scenario, the security unit, in addition to implementing session verification and heartbeat monitoring, further runs a rule-based behavior analysis engine. Through real-time monitoring and analysis of user operation behavior, it promptly detects and handles security risks such as malicious operations and account theft, thereby improving the system's security protection level.

[0082] First, the system constructs a normal behavior profile model based on a large amount of historical normal user operation data in government office scenarios. This model includes the following core features: normal operation sequence patterns (such as "login → view personal assigned tasks → view task details → initiate approval / rejection → view approval results → log out" or "login → view task list → search for specific tasks → view task history → log out"); normal operation frequency range (such as a single user initiating no more than 2 approval operations per minute, viewing no more than 50 tasks per hour, and modifying task information no more than 10 times per day); and normal operation time range (such as most users' operation time is concentrated between 8:30 and 18:00 on weekdays, with extremely low operation frequency outside of working hours). Simultaneously, the rule-based behavior analysis engine pre-sets multiple rules for judging abnormal behavior, such as "operation sequence deviates from the normal pattern and cannot match any known normal sequence," "the frequency of a certain type of operation exceeds 3 times or more of the normal range within a unit of time," and "a large number of highly sensitive operations are continuously initiated outside of working hours (such as deleting tasks, batch approvals)," etc.

[0083] The behavior analysis engine works in conjunction with the security unit's log recording module to continuously extract user operation sequences and frequency data from user operation logs. The operation data is then organized and analyzed according to a preset time window (e.g., every 10 seconds is an analysis window), and the organized operation features are compared with a preset normal behavior profile model in real time.

[0084] For example, a user's normal operating behavior is between 9:00 and 17:00 on weekdays, initiating no more than 2 approval operations per minute, with the operation sequence typically being "login → view task → initiate approval → view result". If, at a certain moment, the behavior analysis engine detects that the user logs into the system at 2:00 AM (outside of working hours) and initiates 10 approval operations within one minute, with the operation sequence being "login → initiate approval → initiate approval → delete task → initiate approval", the operation time, frequency, and sequence of this behavior all deviate from the normal behavior profile model, triggering the abnormal judgment rules of "continuously initiating a large number of highly sensitive operations outside of working hours" and "operation frequency exceeding the normal range by more than 3 times".

[0085] At this moment, the behavior analysis engine immediately triggers a security alert: On one hand, it pushes a security alert message to the system administrator's management terminal, including the user ID of the abnormal behavior, the associated terminal IP address, the time of the abnormal operation, and the specific content of the abnormal operation (login at 2:00 AM, 10 approvals and 1 deletion within 1 minute); on the other hand, it pushes a pop-up alert to the terminal currently logged in by the user, indicating that "abnormal operation behavior has been detected. To ensure account security, the relevant task operation permissions have been temporarily frozen." Simultaneously, the security unit initiates the permission freezing process, temporarily freezing the user's approval, deletion, and modification permissions for all tasks, retaining only viewing permissions to prevent malicious operations from causing task data corruption or leakage.

[0086] Upon receiving a security alert, the system administrator investigates the abnormal behavior. If account theft is confirmed, the user's password is immediately reset, and the user is notified to reset their password. If the investigation reveals that the user has special work needs (such as urgent overtime to handle sudden approval tasks), the administrator manually lifts the temporary freeze on the user's relevant task operation permissions through the system's backend permission management module, recording the reason for the lift, the operation time, and the administrator's information in the operation log to ensure traceability. After the permission freeze is lifted, the behavior analysis engine will continue to closely monitor the user's operations. If subsequent operations return to normal, the regular monitoring mode will be restored; if abnormal behavior recurs, stricter security control measures will be triggered, such as extending the permission freeze duration and restricting login IPs.

[0087] In addition, the behavior analysis engine regularly summarizes and analyzes the operation logs of all users to continuously optimize the normal behavior profile model. For example, if it finds that multiple users have concentrated overtime approval operations during specific holidays, the system will automatically update the operation time range of the normal behavior profile model, including the specific holiday period in the normal operation time range, avoiding misjudgments caused by the limitations of the conventional model, and improving the accuracy and flexibility of behavior analysis.

[0088] The beneficial effects of this embodiment include at least the following: by using a rule-based behavior analysis engine to monitor and analyze user behavior in real time, it is possible to promptly identify and address abnormal security risks such as account theft and malicious operations, providing proactive security protection for the system; by dynamically optimizing the normal behavior profile model, the probability of misjudging abnormal behavior is reduced, improving the adaptability and accuracy of behavior analysis; and by combining temporary permission freezing and triggering security alerts, while ensuring system security, the losses caused by abnormal operations are minimized, further enhancing the system's security and reliability in sensitive scenarios such as government affairs.

[0089] In one possible implementation, the system also includes a permission configuration unit, which is used to preset a multi-dimensional task operation permission matrix based on task type and user role; The permission configuration unit also allows administrators to customize permission rules through the backend terminal. Custom permission rules include temporary permission assignment for specific tasks and permission validity period settings. When a user initiates a task operation through the terminal, the control unit will call the permission data of the permission configuration unit and combine it with the permission check result of the security unit to realize the secondary verification of the operation permission.

[0090] The system comprises several key components: **Permission Configuration Unit:** This unit is responsible for pre-setting and managing user task operation permissions. It is the core module for achieving refined permission control and can configure permissions through both a permission matrix and custom rules. **Multi-Dimensional Task Operation Permission Matrix:** This matrix is ​​a permission lookup table built based on two core dimensions: task type (e.g., approval, filing, archiving) and user role (e.g., administrator, general approver, assistant). It clarifies the operational scope of different roles for different types of tasks. **Custom Permission Rules:** These are permission rules flexibly set by administrators according to actual business needs. They differ from system-preset rules and allow for personalized permission configuration for specific scenarios, tasks, or users. **Temporary Permission Assignment:** This grants users temporary operation permissions for specific tasks. Permissions automatically expire after the task is completed, suitable for scenarios such as sudden task collaboration or temporary staff filling in. **Permission Validity Setting:** This sets a valid time range for configured permissions. Permissions are automatically revoked after the expiration date, avoiding security risks associated with long-term permission validity. **Secondary Verification:** After the user's operation is checked by the basic permission check of the security unit, the control unit re-verifies the permission data from the permission configuration unit to ensure the accuracy and comprehensiveness of the permission judgment.

[0091] The following detailed implementation of the aforementioned multi-terminal collaborative task management system will further illustrate this through a specific example in a government affairs approval task management scenario: In the aforementioned government approval task management scenario, the system adds a permission configuration unit that works in conjunction with the security unit and control unit to achieve refined permission control based on task type and user role, meeting the differentiated permission needs of different levels and different businesses in government scenarios.

[0092] The permission configuration unit first constructs a multi-dimensional task operation permission matrix based on common task types in government office work (such as administrative licensing approval, filing and registration, document archiving, and task supervision) and user roles (such as approval administrator, first-level approver, second-level approver, assistant, and archivist). The matrix clearly states: Approval administrators can perform all operations such as approval, modification, deletion, and assignment for all types of tasks; first-level approvers can perform approval and viewing operations for administrative licensing approval and filing and registration tasks, but have no right to delete; second-level approvers can only perform approval and viewing operations for filing and registration tasks; assistants have no approval permissions, but can only perform viewing and attachment upload operations for all types of tasks; and archivists can only perform archiving and viewing operations for archiving tasks. After this permission matrix is ​​preset, it is synchronized to the security unit and control unit as the basis for basic permission judgment.

[0093] Meanwhile, the permission configuration unit allows administrators to customize permission rules through the backend management terminal. For example, if a task related to handling a public emergency requires temporary assistance from a technician to upload relevant materials and view the approval progress, the administrator can access the permission configuration interface through the backend terminal, select the emergency task as a specific task, select the technician's account, assign them temporary permissions to "view task details and upload relevant attachments," and set the permission validity period to 3 days. The permission configuration unit stores this custom rule in the permission database and synchronizes it to the permission check module of the security unit.

[0094] When a user initiates a task operation through a terminal, a secondary verification process for operation permissions will be triggered. Taking an assistant's approval operation for an administrative license approval task initiated through a mobile smart terminal as an example, firstly, the interactive event generated by the user's operation is normalized into an internal system event by the control unit and then sent to the security unit. The security unit extracts the user's role as an assistant based on the role access permission check module, queries the preset permission matrix, finds that the assistant does not have approval permissions, initially determines that the operation is not authorized, and feeds back to the control unit. The control unit further calls the permission data of the permission configuration unit for secondary verification, confirms that the assistant does not have approval permissions for administrative license approval tasks, nor does it have temporary approval permissions assigned by the administrator, and finally determines that the operation is invalid, pushes the prompt message "No approval permission for this task, please contact the administrator" to the mobile smart terminal, and prohibits the operation from being executed.

[0095] For example, when technicians access the aforementioned emergency tasks via the government desktop terminal, their operations undergo a preliminary check by the security unit: the technician's default role is that of a regular staff member, lacking the relevant permissions for emergency tasks; however, the security unit detects the existence of temporary permission rules configured for them by the administrator; the control unit calls the data from the permission configuration unit for a secondary verification, confirming that the temporary permission is valid (not exceeding the 3-day validity period), and that the scope of operation (viewing details, uploading attachments) conforms to the rule settings, thus determining the operation to be valid, allowing the technician to perform the relevant operations, and simultaneously recording the operation log. When the 3-day validity period expires, the permission configuration unit automatically revoks the temporary permission; when the technician attempts to access it again, the secondary verification fails, and the relevant operations cannot be performed.

[0096] The permission configuration unit also supports batch management and real-time updates of permission rules. When government business processes are adjusted (such as adding a "cross-departmental collaborative approval" task type), the administrator can directly update the multi-dimensional permission matrix through the backend terminal, add the "cross-departmental collaborative approval" task dimension and the permissions corresponding to each role. The updated permission data is synchronized to the relevant units in real time and takes effect without restarting the system, ensuring smooth connection of business processes.

[0097] The beneficial effects of this embodiment include at least the following: by adding a permission configuration unit and a multi-dimensional permission matrix, refined and standardized control of task operation permissions is achieved, which meets the strict requirements of permission classification in government scenarios; administrators can customize temporary permissions and permission validity periods, which improves the flexibility and adaptability of permission configuration and meets the needs of special scenarios such as sudden tasks and temporary collaborations; through the secondary verification mechanism of operation permissions, the accuracy of permission judgment is further improved, avoiding omissions or errors that may occur in single permission checks; the real-time update function of permission rules ensures rapid adaptation of permissions when business processes are adjusted, which improves the business scalability and usability of the system.

[0098] In one possible implementation, the system also includes a traceability unit, which is used to build a traceability chain for the entire lifecycle of a task based on the operation logs and task status change records of the storage unit. The traceability chain includes complete information on task creation, status change, operator, operating terminal, operation time, operation content, and approval opinions; The traceability unit allows administrators to query the traceability chain by task identifier, operator, time range, and other conditions through the backend terminal, and generate standardized traceability reports; it also supports the tracing and location of abnormal operations, associates abnormal behavior records of security units, and assists in the verification of security incidents.

[0099] The traceability unit is a functional unit responsible for building the entire lifecycle traceability chain of a task, providing traceability query and report generation functions. It is the core module for achieving traceability and auditability of task operations. The entire lifecycle traceability chain of a task refers to the complete link that records information on all key nodes throughout the entire process from task creation to completion (or termination), ensuring that every operation of the task is traceable. Traceability query conditions refer to the filtering conditions that administrators can select when querying the traceability chain, including task identifier, operator, operation time range, task type, etc., facilitating quick location of the traceability information of the target task. Standardized traceability report refers to a uniformly formatted and complete report document generated by the traceability unit based on the query results, containing all the core information of the traceability chain, and can be directly used for auditing, verification, and other work. Abnormal operation traceability and location refers to accurately locating the occurrence node, operating entity, and operation details of abnormal operations through the traceability chain, providing data support for the verification of security incidents.

[0100] The following detailed implementation of the aforementioned multi-terminal collaborative task management system will further illustrate this through a specific example in a government affairs approval task management scenario: In the aforementioned government approval task management scenario, the system adds a traceability unit that works in conjunction with the storage unit and the security unit. Based on the operation logs and task status change records recorded by the storage unit, a full lifecycle traceability chain for tasks is constructed to meet the core needs of task auditing and accountability in government scenarios.

[0101] The traceability unit first establishes a data synchronization connection with the storage unit, retrieving data in real time from the log storage partition and task status storage partition of the storage unit. This data includes task creation information (creator, creation time, creation terminal, task type, task content), records of each status change (status before change, status after change, change time, operator of the change, terminal of the change, reason for the change), user operation logs (operation type, operation content, operation time, operation terminal, session information), and approval opinions (approver, approval time, content of approval opinion, approval attachments), etc. The traceability unit sorts and correlates this data according to the time sequence, using the task identifier as the core index to construct a full lifecycle traceability chain for each task, ensuring that the information of each node in the chain is complete and the timeline is clear.

[0102] For example, the traceability record for a certain "Business License Application" approval task is as follows: At 9:00 AM on August 10, 2025, staff member A created the task (task ID: SP20250810001) through the government affairs desktop terminal; the task type was administrative licensing approval; at 9:05 AM, staff member A uploaded the enterprise application materials (operation terminal: government affairs desktop terminal); at 9:10 AM, the system automatically assigned the task to first-level approver B; at 9:15 AM, approver B viewed the task and application materials through the government affairs desktop terminal (operation log record); at 9:20 AM... At 9:25, approver B executes the "Approval Approved" operation, changing the task status to "Level 1 Approval Approved" and the approval comment to "Materials Complete and Meets Requirements" (approval comment record); at 9:30, approver C automatically transfers the task to level 2 approver C; at 9:35, approver C views the task via a mobile smart terminal and executes the "Approval Approved" operation, changing the task status to "Approval Completed"; at 9:40, archivist D archives the task via a government desktop terminal, changing the task status to "Archived," with archiving time at 9:40 and archiving terminal: government desktop terminal. All the above information is linked to the task's traceability chain in chronological order, forming a complete lifecycle record.

[0103] The traceability unit supports administrators in performing multi-condition traceability queries through the backend management terminal. When an administrator needs to verify administrative licensing approval tasks within a specific time period, they can select "Task Type: Administrative Licensing Approval" and "Time Range: August 1, 2025 - August 15, 2025" as query conditions on the traceability query interface. After clicking query, the traceability unit filters tasks that meet the conditions from all traceability chains and displays basic information such as task identifier, task name, creator, and completion status. Clicking on a task identifier allows the administrator to view the complete traceability chain for that task, including detailed information such as the operator, operation time, and operation content for each node. If an audit report is required, the administrator can click the "Generate Traceability Report" button. The traceability unit automatically integrates the traceability chain information of the task according to the preset government audit report format, generating a standardized traceability report that supports export and printing in PDF format.

[0104] When the security unit's behavior analysis engine detects abnormal operations and triggers a security alert, the tracing unit can link these abnormal behavior records to the security unit, enabling the tracing and location of the abnormal operations. For example, if a user account is suspected of being stolen and batch-deleting approval tasks outside of working hours, after the security unit triggers an alert, the administrator can use the tracing unit to select "Operator: This user account," "Operation type: Deletion," and "Time range: Period in which abnormal behavior occurred" as search criteria to quickly locate all deleted tasks and detailed information about the deletion operations (deletion time, deletion terminal IP, and session information at the time of deletion). Combined with the security unit's abnormal behavior records, this forms a complete basis for security incident verification, assisting the administrator in quickly handling security risks (such as locking the account, recovering deleted tasks, and tracing the IP source).

[0105] The beneficial effects of this embodiment include at least the following: by constructing a full lifecycle traceability chain for tasks through the addition of traceability units, the entire process of task operations is made traceable and auditable, meeting the strict requirements of government scenarios for business standardization and accountability; the multi-condition query and standardized traceability reporting functions improve the efficiency of permission verification and business auditing, and reduce the workload of administrators; by associating with security units to achieve abnormal operation traceability and location, complete data support is provided for the rapid verification and handling of security incidents, further strengthening the system's security control capabilities and problem handling efficiency, and ensuring the seriousness and standardization of government task processing.

[0106] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0107] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0108] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A task management and processing system based on multi-terminal collaboration, characterized in that, The system includes an authentication unit, a synchronization unit, a storage unit, a control unit, and a security unit, and is used to process user tasks on multiple terminals. The processing steps include: The authentication unit receives and verifies user authentication credentials from the first terminal. After successful verification, it generates unified user session information and distributes it to the first terminal and the second terminal. The synchronization unit establishes a real-time communication connection between the first terminal and the second terminal and the background service. When the first terminal modifies the task status, the background service receives the task status change event sent by the first terminal and updates the maintained task status mapping table. Then, the status update information is pushed to the second terminal through the real-time communication connection. The storage unit persistently saves the task status data in the background service to the distributed database, saves the task context when a task interruption is detected, and loads the saved task status and task context from the distributed database when a task recovery request is received. The control unit dynamically adjusts the rendering state of interface elements on the first terminal and the second terminal based on the status update information obtained from the background service, and normalizes interactive operations from different terminals into internal system events to maintain interaction consistency. The security unit verifies the user session information during the establishment of the real-time communication connection, encrypts and stores the task status data, and transmits it in encrypted form, while also recording user operation logs.

2. The task management and processing system based on multi-terminal collaboration according to claim 1, characterized in that, The generation of unified user session information and its distribution to the first terminal and the second terminal includes: After verifying the user authentication credentials, an encrypted session token is generated. The session token contains user identity information, timeliness data, and terminal binding identifier. The session token is sent to the first terminal that initiated the login, and the session token is synchronously shared to the second terminal associated with the user's identity information through a secure channel; The terminal binding identifier is used to associate the user session information with the device feature codes of the first terminal and the second terminal in the background service, so that when any terminal is offline, the session state is managed by the other online terminals and is synchronously restored when the offline terminal comes back online.

3. The task management and processing system based on multi-terminal collaboration according to claim 1, characterized in that, The real-time communication connection established by the synchronization unit is a persistent connection based on the WebSocket protocol or the MQTT protocol, and the synchronization unit is configured with a protocol adaptive selection mechanism. The protocol adaptive selection mechanism includes dynamically switching between the WebSocket protocol and the MQTT protocol based on the current network latency and stability parameters of the first terminal or the second terminal.

4. The task management and processing system based on multi-terminal collaboration according to claim 1, characterized in that, The back-end service also includes a conflict arbitration process; The conflict arbitration steps include: When conflicting status change events are received from the first terminal and the second terminal almost simultaneously, the final task status is determined by arbitration based on the timestamps carried by each event and the preset operation priority rules, and the task status mapping table is updated based on the final task status before being pushed. The operation priority rules are predefined based on the task operation type and the category of the initiating terminal, wherein approval operations from government desktop terminals are given higher priority than editing operations from mobile smart terminals.

5. The task management and processing system based on multi-terminal collaboration according to claim 1, characterized in that, The step of the storage unit persistently saving task status data to the distributed database includes: A complete task snapshot is saved according to a preset time strategy, and an incremental change log is recorded in real time; the task context includes task progress, runtime environment parameters, and unsubmitted temporary data drafts; When loading the saved task state and the task context, the storage unit performs a data consistency check, and reconstructs the accurate task state at the breakpoint by comparing the time series of the complete task snapshot with the incremental change log.

6. The task management and processing system based on multi-terminal collaboration according to claim 1, characterized in that, The control unit dynamically adjusts the rendering state of interface elements, including: This is achieved through a dynamic rendering engine embedded in the front-end interface. The dynamic rendering engine responds to the status update information and, in conjunction with the terminal device capability description file obtained from the back-end service, adapts and updates the button status, progress display, and layout and interaction logic of the operable area in the interface in real time.

7. The task management and processing system based on multi-terminal collaboration according to claim 1, characterized in that, The steps for the security unit to verify the user session information include: The session token carried in each transmission message is validated for validity and subject to role-based access control. The security unit also integrates a session heartbeat monitoring mechanism, which periodically verifies the activity of the session token, reclaims sessions that exceed a preset silence period, and pushes a forced logout warning to all associated terminals through the synchronization unit before reclaiming the session.

8. The task management and processing system based on multi-terminal collaboration according to claim 7, characterized in that, The security unit also runs a rule-based behavior analysis engine; The behavior analysis engine continuously monitors the operation sequence and frequency in the user operation log and compares them with a preset normal behavior profile model. When an abnormal behavior pattern that deviates from the normal behavior profile model is detected, a security alarm is triggered and the operation permissions of the relevant tasks are temporarily frozen.

9. The task management and processing system based on multi-terminal collaboration according to claim 1, characterized in that, The storage unit employs a sharding strategy based on user geographic distribution and terminal access frequency in the distributed database, combined with an asynchronous replication strategy across data centers, to ensure high data availability and low latency for local access. The metadata of the sharding strategy is managed by the backend service.

10. The task management and processing system based on multi-terminal collaboration according to claim 1, characterized in that, The first terminal is a government affairs desktop terminal, and the second terminal is a mobile smart terminal; The mobile smart terminal is equipped with a lightweight offline processing module. When the network is unavailable, the offline processing module takes over the user's operation and records it in a local temporary queue. After the network is restored, it automatically performs differential synchronization with the background service. The government desktop terminal is equipped with a batch task scheduling module, which is used to process the set of tasks synchronized from the mobile smart terminal and marked as pending batch processing.

Images