A customizable multi-terminal cooperative OA office tracking method and system

Abstract

The application provides a customizable multi-terminal cooperative OA office tracing method and system. The method comprises the following steps: obtaining multi-terminal operation event data, calculating a multi-dimensional context fingerprint, and weighting to obtain a suture degree, and constructing a cross-terminal tracing chain by using suture operation event pairs; then, combining the number of countersigners, the number of terminal switching times, and the rule template, calculating the operation risk dimension factor and inputting the scoring model, determining the tracing granularity level and selecting the data; then, generating an operation dependency graph by taking the operation event as a node and the dependency relationship as an edge; finally, matching an abnormal topological pattern to output a detection result. Thus, the cross-terminal operation is accurately connected, the tracing granularity is dynamically adapted, and the abnormality is intelligently identified, which adapts to the multi-scene cooperative office tracing needs of enterprises, and improves the tracing accuracy, flexibility and security.

Description

Technical Field

[0001] This application relates to the field of office automation technology, and more specifically, to a customizable multi-terminal collaborative OA office traceability method and system. Background Technology

[0002] With the continuous deepening of information technology construction, OA (Office Automation) systems have become the core infrastructure for daily operations of enterprises. Modern OA systems not only carry basic office functions such as approval, workflow, and collaboration, but also face multi-dimensional requirements such as multi-terminal access, flexible process customization, and full-chain operation auditing.

[0003] Existing technologies already include solutions for multi-terminal collaborative office work and operation log analysis. For example, invention patent CN121864412A, "Intelligent Synchronization and Privacy Protection Method for Multi-Terminal Collaborative Office Data," discloses a technical solution for synchronizing office data among multiple terminals. It can identify the type of terminal device and execute data synchronization strategies, but it only focuses on data-level synchronization and privacy protection, without addressing multi-dimensional tracing of operational behavior or the seamless analysis of data flow between process nodes. Invention patent CN120602314A, "Business Log Analysis Method, Device, Electronic Equipment, and Storage Medium," discloses an abnormal operation detection scheme based on log analysis. It achieves anomaly identification through semantic analysis of business logs, but it relies on post-event log analysis, lacks real-time risk classification of operational behavior, and does not support dynamic adjustment of audit strategies based on operational sensitivity.

[0004] However, the above-mentioned existing technical solutions still have the following shortcomings in practical applications:

[0005] 1) Traceability chain breakage issue. Existing OA systems typically only record log information for a single operation node. In scenarios where users switch between different terminals and sessions, it is difficult to link scattered operation records into a complete operation chain. When a user initiates an approval on a PC and then switches to a mobile device to continue processing, the system often treats the two operations as independent events, causing the traceability chain to break at the terminal switch and making it impossible to restore the complete operation context.

[0006] 2) Waste of audit resources. Existing solutions typically employ a uniform logging strategy, recording all operations at the same granularity. However, the risk levels of different operations vary significantly—the sensitivity of ordinary document browsing differs drastically from that of critical financial approvals. A uniform logging strategy results in a large number of low-risk operations consuming storage and computing resources, while high-risk operations may not be adequately logged due to resource contention.

[0007] 3) Delayed anomaly detection. Existing solutions mostly rely on post-event log analysis to identify abnormal behavior, such as batch deletion and signature skipping, lacking real-time risk perception capabilities during the operation execution phase. By the time abnormal behavior has occurred, it often causes irreversible business impact.

[0008] 4) Insufficient customizability. Existing OA systems typically have workflows pre-configured by administrators, preventing users from flexibly customizing approval processes, traceability rules, and auditing strategies according to their own business needs. This rigid architecture struggles to adapt to traceability requirements in dynamic scenarios such as organizational restructuring and the formation of temporary projects.

[0009] Effective technical solutions are urgently needed to address the above problems. Summary of the Invention

[0010] The purpose of this application is to provide a customizable multi-terminal collaborative OA office traceability method and system. This method acquires multi-terminal operation event data, calculates multi-dimensional contextual fingerprints, and weights them to obtain the stitching degree. Operation event pairs are stitched together to construct a cross-terminal traceability chain. Then, combining the number of signatories, the number of terminal switches, and rule templates, operational risk dimension factors are calculated and input into a scoring model to determine the traceability granularity level and select data for discarding. Subsequently, an operation dependency graph is generated with operation events as nodes and dependencies as edges. Finally, anomaly topology patterns are matched to output detection results. This achieves precise cross-terminal operation chaining, dynamic adaptation of traceability granularity, and intelligent anomaly identification, adapting to the multi-scenario collaborative office traceability needs of enterprises and improving traceability accuracy, flexibility, and security.

[0011] This application also provides a customizable multi-terminal collaborative OA office traceability method, including the following steps:

[0012] Acquire operation event data from multiple terminal devices. The operation event data includes operation metadata, operation context, and terminal device identifier.

[0013] Multi-dimensional contextual fingerprints are calculated based on operation event data. The stitching degree between operation event pairs is obtained by combining preset dimension weight coefficients. The operation event pairs are stitched together based on the comparison between the stitching degree and the preset stitching evaluation threshold to construct a cross-terminal traceability chain.

[0014] Obtain the number of co-signers and approvers, the number of cross-terminal switching times, and the preset traceability rule templates; combine these with operational event data processing to obtain operational risk dimension factors in the cross-terminal traceability chain.

[0015] Operational risk scores are obtained by processing operational risk dimension factors through a preset operational risk scoring model. Based on the operational risk scores, threshold comparisons are performed to obtain traceability granularity levels and corresponding mapping rules. Based on the traceability granularity levels and mapping rules, data selection is performed on operational event data in the cross-terminal traceability chain.

[0016] Each operation event in the cross-terminal traceability chain is treated as a node in the graph, and directed edges are constructed based on the dependencies between operation events to generate an operation dependency graph.

[0017] Perform subgraph matching of the operation-dependent graph using a preset abnormal topology pattern and output the abnormality detection results.

[0018] Optionally, in the customizable multi-terminal collaborative OA office traceability method described in this application, the step of obtaining operation event data from multiple terminal devices, whereby the operation event data includes operation metadata, operation context, and terminal device identifier, specifically includes:

[0019] Obtain operation metadata, including operation type, operation timestamp, operation user ID, and the business process ID to which it belongs;

[0020] Obtain the operation context, including the differences in business status snapshots before and after the operation, document identifiers involved in the operation, and identifiers of associated approval nodes;

[0021] Obtain the terminal device identifier, including device type, device number, and device session identifier.

[0022] Optionally, in the customizable multi-terminal collaborative OA office traceability method described in this application, the step of calculating a multi-dimensional contextual fingerprint based on operation event data, processing it with preset dimension weight coefficients to obtain the stitching degree between operation event pairs, and stitching the operation event pairs together based on the comparison between the stitching degree and a preset stitching evaluation threshold to construct a cross-terminal traceability chain specifically includes:

[0023] Multi-dimensional contextual fingerprints include user-dimensional fingerprints, process-dimensional fingerprints, time-dimensional fingerprints, device-dimensional fingerprints, and session-dimensional fingerprints;

[0024] Normalized similarity is calculated for each of the multi-dimensional context fingerprints, and the stitching degree is obtained by weighted summation based on each normalized similarity and the preset dimension weight coefficients.

[0025] The stitching degree is compared with a preset stitching evaluation threshold. If the stitching degree is greater than or equal to the preset stitching evaluation threshold, the operation event is stitched to build a cross-terminal traceability chain.

[0026] Optionally, in the customizable multi-terminal collaborative OA office traceability method described in this application, the step of obtaining the number of co-signers, the number of cross-terminal switching times, and the preset traceability rule template, and combining this with operation event data processing to obtain the operation risk dimension factor in the cross-terminal traceability chain, specifically includes:

[0027] The preset traceability rule template includes process type identifier, sensitive operation keywords, required operation type, keyness weight coefficient, normalized baseline value of the number of participants in the signing, normalized baseline value of the number of cross-terminal switching times, and granularity threshold configuration.

[0028] By combining operational event data processing, operational risk dimension factors in the cross-terminal traceability chain are obtained, including operational sensitivity score, process node criticality score, number of participants in the signing process, and number of cross-terminal switching events.

[0029] Calculate the operation sensitivity score based on sensitive operation keywords and required operation types;

[0030] Calculate the criticality score of each process node based on the criticality weighting coefficient;

[0031] The number of participants in the joint signing process is calculated as the ratio of the number of people who jointly approve the signing process to the normalized baseline value of the number of participants in the joint signing process.

[0032] The cross-terminal handover frequency factor is calculated based on the ratio of the cross-terminal handover frequency to the normalized baseline value of the cross-terminal handover frequency.

[0033] Optionally, in the customizable multi-terminal collaborative OA office traceability method described in this application, the step of obtaining an operation risk score by processing the operation risk dimension factors through a preset operation risk scoring model, obtaining the traceability granularity level and corresponding mapping rule by comparing the operation risk score with a threshold, and performing data selection and discarding on the operation event data in the cross-terminal traceability chain according to the traceability granularity level and mapping rule, specifically includes:

[0034] The operation risk score is obtained by inputting the operation sensitivity score, process node criticality score, number of participants in the signing process, and number of cross-terminal switching times into the preset operation risk scoring model.

[0035] Extract the first preset threshold, the second preset threshold, and the third preset threshold according to the granularity threshold configuration;

[0036] If the operational risk score is less than the first preset threshold, the traceability granularity level is lightweight, and the operational event record only records the operational type and operational timestamp.

[0037] When the operation risk score is greater than or equal to the first preset threshold and less than the second preset threshold, the traceability granularity level is standard level, and the operation event record also includes the difference in business status snapshots before and after the operation.

[0038] When the operation risk score is greater than or equal to the second preset threshold and less than the third preset threshold, the traceability granularity level is depth level, and the operation event record also includes the operation context and related data snapshots.

[0039] When the operational risk score is greater than or equal to the third preset threshold, the traceability granularity level is full-scale, and the operational event record also includes full-scale status snapshots, operational environment information, and upstream and downstream records of the operational chain.

[0040] Optionally, in the customizable multi-terminal collaborative OA office traceability method described in this application, the step of treating each operation event in the cross-terminal traceability chain as a node in a graph, constructing directed edges based on the dependencies between operation events, and generating an operation dependency graph specifically includes:

[0041] Each operation event in the cross-terminal traceability chain is treated as a node;

[0042] For pairs of operation events that satisfy a temporal sequence relationship, determine one or more dependency types in sequence, such as temporal dependency, state transit dependency, process node advancement dependency, and countersignature aggregation dependency.

[0043] For operation event pairs that satisfy at least one dependency type, a directed edge is established from the preceding operation to the succeeding operation. The directed edge attributes are marked with a set of dependency type labels that satisfy the dependency type, thereby constructing an operation dependency graph.

[0044] Optionally, in the customizable multi-terminal collaborative OA office traceability method described in this application, the step of performing subgraph matching of a preset abnormal topology pattern on the operation dependency graph and outputting the abnormal detection result specifically includes:

[0045] Load one or more preset abnormal topology patterns from the preset abnormal topology pattern library. Each preset abnormal topology pattern includes a reference subgraph structure, node attribute matching constraints, and directed edge attribute matching constraints. The node attribute matching constraints include matching conditions for operation type, operation user identifier, and process node number. The directed edge attribute matching constraints include matching conditions for dependency type labels.

[0046] For each preset abnormal topology pattern, based on the number of nodes and edges in the reference subgraph structure, a set of candidate subgraphs with node and edge sizes within the preset tolerance range is extracted from the operation dependency graph.

[0047] For each candidate subgraph in the candidate subgraph set, perform a subgraph isomorphism determination with the preset abnormal topology pattern, including checking whether the attributes of each node in the candidate subgraph meet the node attribute matching constraints, and checking whether the dependency type labels of each directed edge in the candidate subgraph meet the directed edge attribute matching constraints.

[0048] For candidate subgraphs that pass the subgraph isomorphism determination, an anomaly confidence score is calculated. The anomaly confidence score is obtained by weighted summation of the proportion of matching nodes to the total number of nodes in the reference subgraph, the proportion of matching edges to the total number of directed edges in the reference subgraph, and the risk scores of the operation events involved.

[0049] Candidate subgraphs with anomaly confidence scores greater than or equal to a preset anomaly confidence threshold are identified as anomalous subgraphs. The anomalous topology pattern type, the set of operation event nodes involved, and the anomaly confidence scores of each anomalous subgraph are summarized, and the anomaly detection results are output.

[0050] Secondly, this application provides a customizable multi-terminal collaborative OA office traceability system, which includes: a memory and a processor. The memory stores a program for a customizable multi-terminal collaborative OA office traceability method. When the program for the customizable multi-terminal collaborative OA office traceability method is executed by the processor, it implements the following steps:

[0051] Acquire operation event data from multiple terminal devices. The operation event data includes operation metadata, operation context, and terminal device identifier.

[0052] Multi-dimensional contextual fingerprints are calculated based on operation event data. The stitching degree between operation event pairs is obtained by combining preset dimension weight coefficients. The operation event pairs are stitched together based on the comparison between the stitching degree and the preset stitching evaluation threshold to construct a cross-terminal traceability chain.

[0053] Obtain the number of co-signers and approvers, the number of cross-terminal switching times, and the preset traceability rule templates; combine these with operational event data processing to obtain operational risk dimension factors in the cross-terminal traceability chain.

[0054] Operational risk scores are obtained by processing operational risk dimension factors through a preset operational risk scoring model. Based on the operational risk scores, threshold comparisons are performed to obtain traceability granularity levels and corresponding mapping rules. Based on the traceability granularity levels and mapping rules, data selection is performed on operational event data in the cross-terminal traceability chain.

[0055] Each operation event in the cross-terminal traceability chain is treated as a node in the graph, and directed edges are constructed based on the dependencies between operation events to generate an operation dependency graph.

[0056] Perform subgraph matching of the operation-dependent graph using a preset abnormal topology pattern and output the abnormality detection results.

[0057] Optionally, in the customizable multi-terminal collaborative OA office traceability system described in this application, operation event data from multiple terminal devices is obtained. The operation event data includes operation metadata, operation context, and terminal device identifiers, specifically including:

[0058] Operation metadata includes operation type, operation timestamp, operation user identifier, and the identifier of the business process to which it belongs;

[0059] The operation context includes the differences in business status snapshots before and after the operation, the document identifiers involved in the operation, and the identifiers of associated approval nodes;

[0060] Terminal device identification includes device type, device number, and device session identifier.

[0061] Optionally, in the customizable multi-terminal collaborative OA office traceability system described in this application, the step of calculating multi-dimensional contextual fingerprints based on operation event data, processing them with preset dimension weight coefficients to obtain the stitching degree between operation event pairs, and stitching the operation event pairs together based on the comparison between the stitching degree and a preset stitching evaluation threshold to construct a cross-terminal traceability chain specifically includes:

[0062] Multi-dimensional contextual fingerprints include user-dimensional fingerprints, process-dimensional fingerprints, time-dimensional fingerprints, device-dimensional fingerprints, and session-dimensional fingerprints;

[0063] Normalized similarity is calculated for each of the multi-dimensional context fingerprints, and the stitching degree is obtained by weighted summation based on each normalized similarity and the preset dimension weight coefficients.

[0064] The stitching degree is compared with a preset stitching evaluation threshold. If the stitching degree is greater than or equal to the preset stitching evaluation threshold, the operation event is stitched to build a cross-terminal traceability chain.

[0065] As described above, the customizable multi-terminal collaborative OA office traceability method and system provided in this application acquires multi-terminal operation event data, calculates multi-dimensional context fingerprints and weights them to obtain the stitching degree, stitching operation event pairs to construct a cross-terminal traceability chain; then, combining the number of signatories, the number of terminal switching times, and rule templates, it calculates operation risk dimension factors and inputs them into a scoring model to determine the traceability granularity level and select data for discarding; subsequently, it generates an operation dependency graph with operation events as nodes and dependencies as edges; finally, it matches abnormal topology patterns and outputs detection results. This achieves precise cross-terminal operation chaining, dynamic adaptation of traceability granularity, and intelligent anomaly identification, adapting to the multi-scenario collaborative office traceability needs of enterprises and improving traceability accuracy, flexibility, and security.

[0066] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

[0067] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0068] Figure 1A flowchart illustrating a customizable multi-terminal collaborative OA office traceability method provided in this application embodiment;

[0069] Figure 2 A flowchart illustrating the acquisition of operation event data in a customizable multi-terminal collaborative OA office tracing method provided in this application embodiment;

[0070] Figure 3 The flowchart illustrates the construction of the cross-terminal traceability chain and the acquisition of operational risk dimension factors in the customizable multi-terminal collaborative OA office traceability method provided in this application embodiment. Detailed Implementation

[0071] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0072] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0073] Please refer to Figure 1 , Figure 1 This is a flowchart of a customizable multi-terminal collaborative OA office tracing method according to some embodiments of this application. This customizable multi-terminal collaborative OA office tracing method is used in terminal devices, such as computers and mobile phones. The customizable multi-terminal collaborative OA office tracing method includes the following steps:

[0074] S11. Obtain operation event data from multiple terminal devices. The operation event data includes operation metadata, operation context, and terminal device identifier.

[0075] S12. Calculate and obtain multi-dimensional context fingerprints based on operation event data, combine them with preset dimension weight coefficients to obtain the stitching degree between operation event pairs, and stitch the operation event pairs according to the comparison between the stitching degree and the preset stitching evaluation threshold to construct a cross-terminal traceability chain.

[0076] S13. Obtain the number of co-signers, the number of cross-terminal switching times, and the preset traceability rule template. Combine the operation event data processing to obtain the operation risk dimension factor in the cross-terminal traceability chain.

[0077] S14. Based on the operational risk dimension factors, an operational risk score is obtained through a preset operational risk scoring model. The operational risk score is compared with a threshold to obtain the traceability granularity level and the corresponding mapping rule. Based on the traceability granularity level and the mapping rule, data selection is performed on the operational event data in the cross-terminal traceability chain.

[0078] S15. Treat each operation event in the cross-terminal traceability chain as a node of the graph, construct directed edges based on the dependency relationship between operation events, and generate an operation dependency graph.

[0079] S16. Perform subgraph matching of the operation-dependent graph using the preset abnormal topology pattern and output the abnormal detection results.

[0080] Among them, by deploying a lightweight operation event collection agent on each terminal device, the system can capture all user operation behaviors in the OA system in real time and automatically generate standardized structured operation records. Each record contains three core information elements: operation metadata, operation context, and terminal device identifier. Operation metadata identifies the basic attributes of the operation; operation context records the differences in business status snapshots before and after the operation, as well as related documents and approval node information; and terminal device identifier locates the physical terminal and login session where the operation occurred, creating a unique and complete digital file for each operation. Based on this, a five-dimensional context fingerprint (user, process, time, device, session) is calculated for each operation event. For any two operation events, the normalized similarity of each dimension's fingerprint is calculated, and then weighted and summed using the enterprise's preset dimension weight coefficients to obtain the stitching degree between the two operations. When the stitching degree is greater than or equal to a preset stitching assessment threshold, the two operations are determined to belong to the same business chain and intelligent association stitching is completed, automatically connecting scattered operations across different terminals into a complete end-to-end cross-terminal traceability chain. Subsequently, the system loads the enterprise's custom traceability rule template (adaptable to different business types, compliance requirements, and risk preferences) to calculate four core risk dimension factors for each operation in the cross-terminal traceability chain: operation sensitivity score, process node criticality score, number of co-signing participants factor, and cross-terminal switching frequency factor. These factors are then input into the preset... The operational risk scoring model uses weighted calculations to obtain a comprehensive risk score for each operation. Then, based on the comparison between the score and preset three-level granularity thresholds, operations are divided into four traceability granularity levels: lightweight, standard, deep, and full-scale. Corresponding detailed record content ranges are matched to achieve precise allocation of traceability resources. Furthermore, each operational event in the cross-terminal traceability chain is mapped to a node in a directed graph, with node attributes containing the operation's core metadata and traceability granularity level. Finally, based on four core relationships between operations—temporal dependencies, state propagation dependencies, process node advancement dependencies, and countersignature aggregation dependencies—a previous... The system sets directed edges that point to subsequent operations and labels the edges with the required dependency types, thus elevating the linear traceability chain into an operation dependency graph with rich topological information. Finally, the system loads various predefined violation operation patterns from a pre-defined abnormal topology pattern library, extracts candidate subgraphs that meet the required scale from the operation dependency graph, and performs subgraph isomorphism determination by dual verification of node and edge attributes. Then, it filters false alarms by using an anomaly confidence score that combines structural matching degree and operational risk, identifies genuine abnormal operations, and finally outputs a complete detection result including the anomaly type, the involved operational events, and the confidence level.

[0081] Please refer to Figure 2 , Figure 2This is a flowchart illustrating the acquisition of operation event data in a customizable multi-terminal collaborative OA office tracing method according to some embodiments of this application. According to embodiments of the present invention, the acquisition of operation event data from multiple terminal devices includes operation metadata, operation context, and terminal device identifiers, specifically including:

[0082] S21. Obtain operation metadata, including operation type, operation timestamp, operation user identifier, and the identifier of the business process to which it belongs;

[0083] S22. Obtain the operation context, including the differences in business status snapshots before and after the operation, document identifiers involved in the operation, and identifiers of associated approval nodes;

[0084] S23. Obtain the terminal device identifier, including device type, device number and device session identifier.

[0085] The "Operation Type" identifies the specific action performed by the user, such as: submitting an application, approval, rejection, uploading attachments, data modification, node rollback, and process forwarding. The "Operation Timestamp" records the precise time the operation occurred, typically in UTC timestamp format (accurate to milliseconds), used for subsequent time-series dependency determination and time window matching. The "Operation User Identifier" uniquely identifies the user account performing the operation, typically using a user ID or employee ID, used for subsequent user-level fingerprint calculation and operation attribution tracing. The "Related Business Process Identifier" identifies the OA business process instance to which the operation belongs, typically using a process instance ID, used to bind the operation event to a specific business process context. The "Business Status Snapshot Difference Before and After Operation" records changes in key fields of business objects before and after the operation, such as: reimbursement amount changing from 5000 to 8000, or approval status changing from "pending approval" to "approved." This difference is usually recorded in key-value pair format for easy comparison and auditing. The "Document Identifier Involved in the Operation" records document objects referenced or generated during the operation, such as attachment file IDs and form template IDs. "Associated Approval Node Identifier" identifies the location of the operation within the approval process node, such as "Department Manager Approval Node" or "Financial Review Node," used for subsequent process-level fingerprint calculation and process advancement dependency determination. "Device Type" identifies the category of the terminal device, such as desktop computer, laptop, or smartphone, used for device-level fingerprint calculation. "Device Number" is the unique hardware identifier of the terminal device, which can be the device's MAC address or device registration ID. "Device Session Identifier" identifies the user's login session on this terminal device, typically using a SessionID, used to distinguish operations by different users on the same device and operations by the same user at different time periods. The three-dimensional structure design of operation event data (metadata-context-device identifier) ​​enables comprehensive recording of operation behavior: operation metadata answers the basic question of "who did what operation at what time," operation context answers the deeper question of "in what business environment did the operation occur and what impact did it have," and terminal device identifier answers the physical location question of "on which terminal did the operation occur." This three-dimensional structure provides a complete data foundation for subsequent multi-dimensional context fingerprint calculation.

[0086] In this embodiment, assume that user Zhang San (user ID: U10086) performed a reimbursement approval operation (operation type: approval) on his office computer (device type: PC, device number: DEV-PC-001, session ID: SESSION-20260415-A) at 14:30:22 on April 15, 2026. This operation belongs to a reimbursement process instance (business process ID: PROC-EXP-2026-0415), associated with the department manager approval node (approval node ID: NODE-DEPT-MGR), and the reimbursement document number involved is DOC-EXP-0089. The difference in the business status snapshot before and after approval is that the approval status changed from "pending approval" to "approved", and the approved amount changed from "not set" to "5000.00". Then the operation event record generated by the system will contain all the above fields. By recording operational event data in a three-dimensional structure, each operational event has a unique and complete digital profile, providing sufficient data support for subsequent cross-terminal integration, risk assessment, and anomaly detection.

[0087] Please refer to Figure 3 , Figure 3 This application provides a flowchart illustrating the construction of a cross-terminal traceability chain and the acquisition of operational risk dimension factors in a customizable multi-terminal collaborative OA office traceability method. According to an embodiment of the invention, the step of calculating a multi-dimensional context fingerprint based on operational event data, processing it with preset dimension weight coefficients to obtain the stitching degree between operational event pairs, and stitching the operational event pairs together based on a comparison of the stitching degree with a preset stitching evaluation threshold to construct a cross-terminal traceability chain specifically includes:

[0088] Multi-dimensional contextual fingerprints include user-dimensional fingerprints, process-dimensional fingerprints, time-dimensional fingerprints, device-dimensional fingerprints, and session-dimensional fingerprints;

[0089] Normalized similarity is calculated for each of the multi-dimensional context fingerprints, and the stitching degree is obtained by weighted summation based on each normalized similarity and the preset dimension weight coefficients.

[0090] The stitching degree is compared with a preset stitching evaluation threshold. If the stitching degree is greater than or equal to the preset stitching evaluation threshold, the operation event is stitched to build a cross-terminal traceability chain.

[0091] The meanings and calculation methods of each fingerprint dimension are as follows: User-dimensional fingerprint, constructed based on the user identifier, measures whether two operation events were executed by the same user or users with a related relationship. User-dimensional fingerprints can use exact matching (user-dimensional normalized similarity is 1 if the user identifier is the same, otherwise it is 0), or can be extended to fuzzy matching based on user role similarity or organizational relationship distance, with a value range of [0,1]. Process-dimensional fingerprint, constructed based on the business process identifier and associated approval node identifier, measures the positional correlation of two operation events within the same business process. Operations within the same process instance have higher process-dimensional similarity, and operations on adjacent approval nodes have even higher similarity, with a process-dimensional normalized similarity value range of [0,1]. Time-dimensional fingerprint, constructed based on the operation timestamp, measures the temporal proximity of two operation events. It is usually calculated using a time decay function; the shorter the time interval between two operations, the higher the time-dimensional similarity, with a time-dimensional normalized similarity value range of [0,1]. Device-dimensional fingerprint, constructed based on device type and device number, measures the correlation of two operation events on the terminal device. Operations on the same device exhibit high device-level similarity, while operations on different device types show lower similarity. The device-level normalized similarity ranges from [0,1]. Session-level fingerprints, constructed based on device session identifiers and operation contexts, measure the continuity and contextual consistency of two operation events at the session level. Operations within the same session exhibit high session-level similarity, and cross-session operations with coherent contexts also show some similarity. The session-level normalized similarity ranges from [0,1]. The formula for calculating the stitching degree is...

[0092] ;

[0093] in, For operation With operation The suture degree between the two, with a value range of [0,1]. Normalize similarity for user dimensions. To normalize the similarity across the process dimensions, To normalize the similarity over time, To normalize similarity across device dimensions, Normalize similarity for the conversation dimension. , , , , For preset characteristic coefficients and The configuration of weight coefficients for each dimension reflects the importance of different dimensions in the stitching judgment. In actual deployment, , , , , The values ​​are 0.3, 0.25, 0.2, 0.1, and 0.15.

[0094] Stitching score is a quantitative score used to measure whether two operational events are "on the same business chain and how strong their association is." The value is generally between 0 and 1, with higher values ​​indicating a stronger association. If the stitching score is less than the preset stitching assessment threshold, the two operational events are determined not to belong to the same traceability chain. Dimension weight coefficients can be flexibly configured according to the enterprise's actual business scenarios. For example, for enterprises with frequent cross-terminal collaborative work, the weights of the device and session dimensions can be appropriately increased to make the system focus more on operational associations in terminal switching scenarios; for enterprises with intensive multi-role collaborative approvals, the weights of the user and process dimensions can be appropriately increased to make the system focus more on the continuity of operations in the approval chain. The stitching assessment threshold can generally be set between 0.6 and 0.8, and the specific value can be adjusted according to the enterprise's requirements for traceability chain accuracy and the system's computational resource constraints. Through the above weighted stitching score formula, information from five dimensions—user identity, business process, time interval, device type, and session context—can be comprehensively considered to quantitatively assess the association probability of operational event pairs, avoiding misjudgments caused by simple binary matching and improving the accuracy of cross-terminal traceability chain construction.

[0095] According to an embodiment of the present invention, the step of obtaining the number of co-signers, the number of cross-terminal switching times, and the preset traceability rule template, and combining this with operational event data processing to obtain operational risk dimension factors in the cross-terminal traceability chain, specifically includes:

[0096] The preset traceability rule template includes process type identifier, sensitive operation keywords, required operation type, keyness weight coefficient, normalized baseline value of the number of participants in the signing, normalized baseline value of the number of cross-terminal switching times, and granularity threshold configuration.

[0097] By combining operational event data processing, operational risk dimension factors in the cross-terminal traceability chain are obtained, including operational sensitivity score, process node criticality score, number of participants in the signing process, and number of cross-terminal switching events.

[0098] Calculate the operation sensitivity score based on sensitive operation keywords and required operation types;

[0099] Calculate the criticality score of each process node based on the criticality weighting coefficient;

[0100] The number of participants in the joint signing process is calculated as the ratio of the number of people who jointly approve the signing process to the normalized baseline value of the number of participants in the joint signing process.

[0101] The cross-terminal handover frequency factor is calculated based on the ratio of the cross-terminal handover frequency to the normalized baseline value of the cross-terminal handover frequency.

[0102] The preset traceability rule template is a template file that enterprise administrators can customize through the rule configuration interface. It is used to guide the system in conducting risk assessments of operational events in the cross-terminal traceability chain. The preset traceability rule template includes the following parameters: process type identifier, which identifies the type of business process to which the rule template applies, such as "procurement approval process", "reimbursement approval process", "contract signing process", etc. Different business process types can be configured with different risk assessment parameters; sensitive operation keywords, which defines a list of sensitive operation types that need to be focused on under this process type, such as "amount modification", "approval rejection", "attachment deletion", "process return", etc. When the type of an operation event matches a sensitive operation keyword, its operation sensitivity score increases accordingly; Required operation type defines a list of operation types that must be included under this process type, such as "Submit Application" and "Approval Passed," used to check the completeness of the process; Criticality weight coefficient defines the criticality weight of each approval node in the process, with a value range of [0,1]. The higher the criticality weight coefficient of a node (such as the general manager's approval node), the higher its operation risk score; Normalized baseline value of the number of co-signing participants is used to convert the actual number of co-signing approvals into a baseline value of the normalization factor. For example, if the normalization baseline value is set to 5 people, when the actual number of co-signing participants is 3, the co-signing participant factor is 3 / 5 = 0.6; Normalized baseline value of cross-terminal switching times: used to convert the number of times the same user switches terminals within a preset time window into a baseline value of the normalization factor. For example, if the normalization baseline value is set to 3 times, and the actual number of switching times is 2 times, the cross-terminal switching time factor is 2 / 3, which is approximately equal to 0.67; granularity threshold configuration defines the operational risk scoring thresholds corresponding to four traceability granularity levels: lightweight, standard, deep, and full.

[0103] Based on the preset traceability rule template, the following four operational risk dimension factors are calculated. Operational sensitivity score: This score is based on whether the type of the operational event matches sensitive operational keywords. Specifically, it involves iterating through the list of sensitive operational keywords in the preset traceability rule template, counting the number of keywords matched by the operational event type, and then normalizing the result to a score value in the range [0,1]. For example, if the list of sensitive operational keywords contains 10 keywords, and the operational event type matches 3 of them, the operational sensitivity score is 3 / 10 = 0.3. Furthermore, a comprehensive evaluation can be made in conjunction with mandatory operational types: if the operational type is mandatory, the operational sensitivity score remains at the base value; if the operational type is not mandatory but matches sensitive keywords, a penalty coefficient is added to the score. Process node criticality score: This score is directly obtained based on the criticality weight coefficient configured in the preset traceability rule template for the approval node where the operational event is located. For example, if the operation event is at the "General Manager's Approval Node," and the criticality weighting coefficient for this node is 0.9, then the criticality score of the process node is 0.9; if it is at the "Regular Review Node," and the criticality weighting coefficient is 0.4, then the criticality score of the process node is 0.4. The number of participants in the countersigning process is calculated based on the ratio of the actual number of participants in the current approval node to the normalized baseline value of the number of participants in the countersigning process. The calculation formula is as follows:

[0104] ;

[0105] in, The number of participants in the joint signing process is a factor. This represents the actual number of participants in the current approval process. This is a normalized baseline value for the number of participants in the pre-configured traceability rule template. When the actual number of participants exceeds the baseline value, a truncation process can be implemented (e.g., setting the upper limit to 1.0) to reflect the diminishing marginal effect of operational risk in multi-person co-signing scenarios. The cross-terminal switching frequency factor is calculated based on the ratio of the number of times the same user switches terminal devices within a preset time window to the normalized baseline value for cross-terminal switching frequency. A higher cross-terminal switching frequency indicates more terminal device changes involved in the operation, correspondingly increasing the operational risk and audit requirements. These four operational risk dimensions quantify the risk characteristics of operational events from four different perspectives: the sensitivity of the operational content, the criticality of process nodes, the degree of multi-person participation, and the frequency of cross-terminal switching. The combination of these four factors can comprehensively reflect the risk level of an operational event in terms of business compliance. The customizability of the traceability rule template allows enterprises to flexibly adjust the calculation parameters of each factor according to their own business characteristics.

[0106] According to an embodiment of the present invention, the step of obtaining an operational risk score by processing operational risk dimension factors through a preset operational risk scoring model, obtaining a traceability granularity level and corresponding mapping rule by comparing the operational risk score with a threshold, and performing data selection and discarding on operational event data in the cross-terminal traceability chain according to the traceability granularity level and mapping rule, specifically includes:

[0107] The operation risk score is obtained by inputting the operation sensitivity score, process node criticality score, number of participants in the signing process, and number of cross-terminal switching times into the preset operation risk scoring model.

[0108] Extract the first preset threshold, the second preset threshold, and the third preset threshold according to the granularity threshold configuration;

[0109] If the operational risk score is less than the first preset threshold, the traceability granularity level is lightweight, and the operational event record only records the operational type and operational timestamp.

[0110] When the operation risk score is greater than or equal to the first preset threshold and less than the second preset threshold, the traceability granularity level is standard level, and the operation event record also includes the difference in business status snapshots before and after the operation.

[0111] When the operation risk score is greater than or equal to the second preset threshold and less than the third preset threshold, the traceability granularity level is depth level, and the operation event record also includes the operation context and related data snapshots.

[0112] When the operational risk score is greater than or equal to the third preset threshold, the traceability granularity level is full-scale, and the operational event record also includes full-scale status snapshots, operational environment information, and upstream and downstream records of the operational chain.

[0113] The formula for calculating the operational risk score is as follows:

[0114] ;

[0115] In the formula, The operational risk score for the operational event is set, with a value range of [0,1]. Assess operational sensitivity. Score the criticality of process nodes. The number of participants in the joint signing process is a factor. The cross-terminal switching frequency factor is defined by α (weighting coefficient for operational sensitivity score), β (weighting coefficient for process node criticality score), γ (weighting coefficient for number of participants in the countersigning process), and δ (weighting coefficient for cross-terminal switching frequency factor), where α + β + γ + δ = 1. These weighting coefficients can be configured by the enterprise administrator in the traceability rule template.

[0116] Based on the granularity threshold configuration, the system extracts a first preset threshold, a second preset threshold, and a third preset threshold, satisfying the condition that the first preset threshold < the second preset threshold < the third preset threshold. The operation risk score is compared with these three thresholds to determine the traceability granularity level of the operation event and the corresponding mapping rules: Lightweight level: Operation event records only two basic pieces of information—operation type and operation timestamp. This level is suitable for low-risk operations to minimize storage overhead. For example, a regular employee's daily form submission operation has a low risk score; the system only records "submitted application" and the operation time, without saving detailed information such as business status snapshots. Standard level: Operation event records, based on the lightweight level, add a snapshot difference of the business status before and after the operation. This level is suitable for medium-risk operations and requires recording the impact of the operation on business data. For example, a department manager's routine approval operation; in addition to recording basic operation information, the system also records the status difference before and after approval (e.g., the approval status changes from "pending approval" to "approved"). At the Depth Level, operation event logging builds upon the Standard Level by adding operation context and associated data snapshots. This level is suitable for higher-risk operations, requiring a complete operation context to support in-depth auditing. For example, in financial auditing operations involving monetary modifications, the system records the complete operation context, including the specific monetary values ​​before and after the modification, associated documents and approval node information, and complete snapshots of the form fields involved in the operation. At the Full Level, operation event logging builds upon the Depth Level by adding a full state snapshot, operation environment information, and upstream and downstream records of the operation chain. This level is suitable for the highest-risk operations, requiring the preservation of the most complete audit evidence chain. For example, in the final approval operation of a general manager on a key procurement contract, the system records a full snapshot of the business object status at the time the operation occurs, terminal information of the operation environment (device type, IP address, geographical location, etc.), and summary records of all upstream and downstream operation events in the approval chain.

[0117] The design of the four traceability granularity levels follows the principle of "the higher the risk, the more complete the record," achieving precise allocation of traceability resources. In typical enterprise deployments, the granularity thresholds can be configured sequentially as 0.3, 0.6, and 0.8. Statistical analysis shows that most routine operations (approximately 60%-70%) fall into the lightweight level, medium-risk operations (approximately 20%-25%) fall into the standard level, and high-risk operations (approximately 8%-12%) fall into the deep and full levels. This ensures complete auditing of high-risk operations while significantly reducing overall storage overhead. These measures avoid the resource waste or insufficient information problems caused by the "one-size-fits-all" fixed granularity recording in existing technologies, achieving an intelligent traceability strategy that dynamically adjusts the level of record detail based on the operational risk level, significantly reducing system storage overhead while ensuring compliance audit requirements.

[0118] According to an embodiment of the present invention, the step of treating each operation event in the cross-terminal traceability chain as a node of a graph, constructing directed edges based on the dependencies between operation events, and generating an operation dependency graph specifically includes:

[0119] Each operation event in the cross-terminal traceability chain is treated as a node;

[0120] For pairs of operation events that satisfy a temporal sequence relationship, determine one or more dependency types in sequence, such as temporal dependency, state transit dependency, process node advancement dependency, and countersignature aggregation dependency.

[0121] For operation event pairs that satisfy at least one dependency type, a directed edge is established from the preceding operation to the succeeding operation. The directed edge attributes are marked with a set of dependency type labels that satisfy the dependency type, thereby constructing an operation dependency graph.

[0122] Among them, temporal dependency is determined as follows: If the timestamp of operation event a is earlier than the timestamp of operation event b, and there is a reasonable causal temporal relationship between the two (the time interval is within a preset reasonable range), then temporal dependency is satisfied. For example, the "submit application" operation must precede the "approval" operation, and the two satisfy temporal dependency. Temporal dependency is the most basic dependency type, indicating that there is a temporal constraint between operations. State transitivity dependency is determined as follows: If operation event b references or modifies the business data generated or changed by operation event a, then state transitivity dependency is satisfied. For example, if a is the operation "fill in the reimbursement amount of 5000 yuan", and b is the operation "review and confirm the reimbursement amount of 5000 yuan", b directly references the amount data generated by a, and the two satisfy state transitivity dependency. State transitivity dependency reflects the data flow relationship between operations. Process node advancement dependency is determined as follows: If the approval node where operation event a is located is the predecessor node of the approval node where operation event b is located in the business process definition, then process node advancement dependency is satisfied. For example, the "Department Manager Approval" node is a prerequisite node for the "General Manager Approval" node in the process definition. Operations at the "Department Manager Approval" node and operations at the "General Manager Approval" node satisfy process node progression dependency, reflecting the node sequence constraints defined in the business process. For countersigning aggregation dependency, if operation events a and b are approval operations by different users at the same countersigning approval node, and this countersigning node requires approval from all participants before proceeding to the next node, then countersigning aggregation dependency is satisfied. For example, at a countersigning node requiring simultaneous approval from both the department manager and the finance manager, the department manager's approval operation and the finance manager's approval operation satisfy countersigning aggregation dependency. Countersigning aggregation dependency reflects the synchronization constraints in parallel approval scenarios. The operation dependency graph transforms the linear cross-terminal traceability chain into a graph structure with rich topological relationships. The four dependency types characterize the structured relationships between operation events from four dimensions: time, data, process, and collaboration. Temporal dependencies ensure the correctness of causal relationships, state transitive dependencies ensure the integrity of data flow, process node advancement dependencies ensure the compliance of process definitions, and signature aggregation dependencies ensure the synchronization of multi-person collaboration.

[0123] For example, in a procurement approval process, suppose the traceability chain includes the following operation events: O1 (User A submits a procurement request), O2 (User B enters the procurement amount of 100,000 yuan on the PC), O3 (User C executes the department manager's approval on the mobile phone), O4 (User D executes the financial review confirmation), and O5 (User E executes the general manager's signature approval). In the operation dependency graph constructed by the system: O1 to O2 satisfy temporal dependency and process node advancement dependency; O2 to O3 satisfy temporal dependency, state transit dependency, and process node advancement dependency (because O3 references the amount entered by O2); O3 to O4 satisfy temporal dependency and process node advancement dependency; O4 to O5 satisfy temporal dependency and process node advancement dependency. If there is also a countersigning relationship between O3 and O4 (requiring approval from both the department manager and the financial manager), then O3 to O4 also satisfies countersigning aggregation dependency. By constructing an operation dependency graph, the flat operation event records are upgraded into a graph structure with rich topological information, providing a structured analytical basis for subsequent graph pattern-based anomaly detection. This enables the system to identify hidden anomaly patterns that cannot be found by rule-based methods alone.

[0124] According to an embodiment of the present invention, the step of performing subgraph matching of a preset abnormal topology pattern on the operation-dependent graph and outputting anomaly detection results specifically includes:

[0125] Load one or more preset abnormal topology patterns from the preset abnormal topology pattern library. Each preset abnormal topology pattern includes a reference subgraph structure, node attribute matching constraints, and directed edge attribute matching constraints. The node attribute matching constraints include matching conditions for operation type, operation user identifier, and process node number. The directed edge attribute matching constraints include matching conditions for dependency type labels.

[0126] For each preset abnormal topology pattern, based on the number of nodes and edges in the reference subgraph structure, a set of candidate subgraphs with node and edge sizes within the preset tolerance range is extracted from the operation dependency graph.

[0127] For each candidate subgraph in the candidate subgraph set, perform a subgraph isomorphism determination with the preset abnormal topology pattern, including checking whether the attributes of each node in the candidate subgraph meet the node attribute matching constraints, and checking whether the dependency type labels of each directed edge in the candidate subgraph meet the directed edge attribute matching constraints.

[0128] For candidate subgraphs that pass the subgraph isomorphism determination, an anomaly confidence score is calculated. The anomaly confidence score is obtained by weighted summation of the proportion of matching nodes to the total number of nodes in the reference subgraph, the proportion of matching edges to the total number of directed edges in the reference subgraph, and the risk scores of the operation events involved.

[0129] Candidate subgraphs with anomaly confidence scores greater than or equal to a preset anomaly confidence threshold are identified as anomalous subgraphs. The anomalous topology pattern type, the set of operation event nodes involved, and the anomaly confidence scores of each anomalous subgraph are summarized, and the anomaly detection results are output.

[0130] Common preset abnormal topology patterns include, but are not limited to: skip-signature mode (jumping directly from a lower-level node to a higher-level node, bypassing necessary intermediate approval nodes), loop operation mode (reversing from an abnormal state of a subsequent node to a preceding node), parallel bypass mode (the same user simultaneously operating process nodes that should not be parallel on different terminals), and single-person proxy signing mode (the same user ID continuously completing approval operations for multiple different roles within a short period of time). The selection criteria for candidate subgraphs are that the node size and edge size of the candidate subgraph are within a preset tolerance range, where the tolerance parameter can be configured by the system administrator. This step significantly reduces the search space for subsequent subgraph isomorphism determination through size filtering, improving detection efficiency. Node attribute verification compares the operation type, user ID, process node number, and other attributes of each node in the candidate subgraph to see if they meet the node attribute matching constraints defined in the preset abnormal topology pattern; directed edge attribute verification compares the dependency type label set of each directed edge in the candidate subgraph to see if it meets the directed edge attribute matching constraints defined in the preset abnormal topology pattern (e.g., requiring edges to contain the "process node advancement dependency" label). Candidate subgraphs are determined by subgraph isomorphism only if all node attributes and all directed edge attributes satisfy the constraints.

[0131] The formula for calculating the anomaly confidence score is:

[0132] ;

[0133] in, Scoring the anomaly confidence of candidate subgraphs. This represents the number of operation nodes marked as abnormal in the subgraph. This refers to the total number of nodes in the reference subgraph. This represents the number of matching edges in the candidate subgraph that satisfy the directed edge attribute matching constraint. The total number of directed edges in the reference subgraph; This is the sum of the operation risk scores corresponding to all matching nodes in the candidate subgraph; , , For the preset weighting coefficients, and + + =1. The design of the anomaly confidence score comprehensively considers two factors: structural matching degree and operational risk degree. Structural matching degree (the matching ratio of nodes and edges) reflects the similarity between the candidate subgraph and the anomaly pattern in terms of topological structure, while operational risk degree (the average risk score of matching nodes) reflects the actual risk level of the anomalous operation. Through the weighted fusion of structural matching degree and risk degree, the anomaly confidence score can effectively distinguish between genuine anomalous operations and normal operations that are topologically similar. The information of each anomalous subgraph is summarized, and the anomaly detection results are output, including: the type of anomalous topological pattern (such as "skip-signature pattern", "loop operation pattern", etc.), the set of operation event nodes involved (i.e., the list of specific operation events involved in the anomalous operation), and the anomaly confidence score (quantifying the credibility of the anomaly).

[0134] For example, suppose the preset abnormal topology pattern library defines a "skip-signature pattern": the reference subgraph structure has 2 nodes and 1 directed edge. Node attribute constraints require the starting node to be a normal approval node type and the ending node to be an advanced approval node type. The directed edge attribute constraints require it to contain the "process node advancement dependency" tag. In the operation dependency graph, the system detects a directed edge from the "Initiate Application" node directly to the "General Manager Approval" node, which satisfies all constraints of the node attributes and directed edge attributes. After calculation, =2 / 2=1.0, =1 / 1=1.0, the operational risk scores of the two matching nodes are 0.7 and 0.95 respectively. =(0.7+0.95) / 2=0.825. Let... =0.3, =0.3, =0.4, then =0.3×1.0+0.3×1.0+0.4×0.825=0.3+0.3+0.33=0.93. If the preset anomaly confidence threshold is 0.7, then 0.93 is greater than or equal to 0.7, and the system determines that the candidate subgraph is an anomaly subgraph, outputting the anomaly detection result: the anomaly pattern type is "skipping signature pattern", the nodes involved are the "initiate application" and "general manager approval" operation events, and the anomaly confidence score is 0.93. By matching anomaly topological pattern subgraphs based on operation dependency graphs, anomaly detection is upgraded from simple keyword rule matching to topological analysis based on graph structure patterns. Compared with existing technologies, this method can discover the following anomaly patterns that are difficult to identify by existing technologies: skipping signature behavior across multiple steps; bypass behavior involving parallel operations of multiple terminals; and composite anomaly patterns utilizing temporal and state transit relationships.

[0135] It is worth mentioning that after outputting the anomaly detection results, the following are also included:

[0136] Send the abnormal operation event markers in the anomaly detection results to the enterprise auditor's terminal;

[0137] Obtain and receive audit feedback from auditors regarding abnormal operational events. The audit feedback includes confirming the abnormality or ruling out false alarms.

[0138] The preset abnormal topology pattern library is updated based on the audit feedback. When the same type of abnormal operation event is marked as a false alarm multiple times in a row, the weight coefficient of the abnormal topology pattern in subsequent matching is reduced.

[0139] The marking information for abnormal operation events includes the abnormal topology pattern type, details of the involved operation event (operation type, operating user, operation time, associated process, etc.), and anomaly confidence score. Auditors can view the complete abnormal event context on their terminals. Confirming an anomaly means the auditor confirms that the operation event is indeed an abnormal operation requiring further processing; ruling out false alarms means the auditor determines that the operation event is actually a normal business activity, and the system marks it as a false alarm. The weighting coefficient adjustment strategy can be configured as follows: when the same abnormal topology pattern is marked as a false alarm N times consecutively, the weighting coefficient of that pattern is reduced to k times its original value (N and k can be configured by the enterprise administrator, generally N=5, k=0.5). When the pattern weighting coefficient drops to a preset lower limit, the system marks the pattern as "low priority," and matching is only performed when manually triggered for auditing, no longer automatically triggering anomaly alarms. The design motivation for the audit feedback closed-loop mechanism is that the subgraph matching of abnormal topology patterns is based on predefined pattern templates, while the actual business operations of an enterprise may have reasonable exceptions (such as senior management authorizing skip-signature approvals in emergency situations). These reasonable workarounds may resemble anomalous patterns in terms of graph structure, leading to false alarms. By incorporating auditor feedback and dynamically adjusting the weighting of anomalous patterns accordingly, the system can gradually learn and adapt to the company's actual business practices.

[0140] It is worth mentioning that it also includes:

[0141] Obtain the computational load data when calculating the stitch length, and compare the system computational load data with the preset load threshold;

[0142] If the calculated load is greater than or equal to the preset load threshold, it will automatically switch to a simplified stitching mode based on business process identifiers and operation time windows.

[0143] The simplified stitching mode only matches operation event pairs with an operation time interval of less than a preset time window under the same business process identifier;

[0144] When the computational load recovers to below the preset load threshold, it automatically reverts to the full stitching mode based on multi-dimensional context fingerprints.

[0145] The computational load data can be measured using metrics such as system CPU utilization, memory utilization, and the length of the queue of pending operation events, or a weighted combination of these metrics. The preset load threshold can be determined based on the system's hardware configuration and Service Level Agreement (SLA). The simplified stitching mode only matches operation events based on two dimensions: business process identifier and operation time window, without calculating multi-dimensional context fingerprints such as user, device, and session dimensions. Specifically, the simplified stitching mode only stitches operation event pairs that meet the following two conditions: first, the two operation events have the same business process identifier; second, the time interval between the two operation events is less than the preset time window. The recovery process employs a smooth transition strategy to avoid a surge in computational requests during mode switching, which could cause the load to exceed limits again. The motivation for the degradation strategy is that calculating the stitching degree of multi-dimensional context fingerprints requires pairwise comparison of operation events, resulting in a computational complexity of O(n²). When the number of operation events is large (such as during concentrated approval periods at the end of the month or batch report processing at the end of the quarter), the computational load may increase sharply, leading to system response delays or service unavailability. The simplified stitching mode uses only two dimensions for matching: business process identifier and operation time window. This narrows the matching search space from all global operation events to operation events within the same business process, reducing computational complexity to near O(n). This ensures the availability of basic system functions under high load conditions. In actual deployment, the preset load threshold is typically set to 80% of the system CPU utilization, and the preset time window is typically set to the maximum allowed interval between consecutive operations within the same business process (usually 30 minutes). Load monitoring can use a sliding window averaging algorithm to avoid frequent mode switching due to instantaneous load fluctuations. These operations achieve elastic management of computing resources while ensuring the availability of core system functions. Under high load, the simplified mode ensures basic services, while under low load, the full mode provides high-precision stitching, avoiding service unavailability due to computational overload and improving system robustness and availability.

[0146] It is worth mentioning that it also includes:

[0147] Extract the traceability granularity level tags and business process identifiers for each OA office operation event from the operation event records;

[0148] The data retention strategy template is matched according to the business process identifier. The data retention strategy template includes a basic retention period and compliance extension rules that are configured differently according to the traceability granularity level.

[0149] Obtain the current retention time of each operation event record. If the current retention time exceeds the basic retention period, determine whether there are conditions for extending the retention period according to the compliance extension rules. The compliance extension conditions include at least one of the following: the anomaly detection result associated with the operation event record is confirmed as an anomaly, the business process involved in the operation event record is in an unclosed state, or the operation event record is marked as locked for compliance audit.

[0150] For operation event records that meet the conditions for extended retention, their retention period will be extended to the corresponding extended retention period; for operation event records that do not meet the conditions for extended retention and whose current retention time exceeds the basic retention period, differentiated downgrade processing will be performed according to their traceability granularity level.

[0151] Data change audit logs are generated for operation events that perform differentiated downgrade processing. The data change audit logs include the change type, change time, summary of the previous record, and change triggering conditions, and the data change audit logs are permanently saved.

[0152] The basic retention period is configured differently based on the level of traceability granularity, following the principle of "the more detailed the record, the longer it is retained." For example, the basic retention period for lightweight operation event records can be configured as 90 days, standard level as 180 days, deep level as 365 days, and full level as 730 days (2 years). The compliance extension rules define the conditions for extended retention and the corresponding extended retention periods. Compliance extension conditions include at least one of the following: First, when an operation event is confirmed as an abnormal operation by auditors, its records need to be retained for a longer period to support subsequent compliance investigations and legal evidence collection. The extended retention period can be configured as twice the basic retention period or a fixed extension to the compliance-required retention period (e.g., 3 years). Second, when the business process to which the operation event belongs is not yet completed (e.g., the approval process is in progress or there are unresolved appeals), the operation event record must continue to be retained. The extended retention period is when the business process is closed or the maximum retention period is exceeded. For operation event records that meet the extended retention conditions, the system extends their retention period to the corresponding extended retention period.

[0153] For operation event records that do not meet the extended retention conditions and whose current retention period exceeds the basic retention period, the system performs differentiated degradation processing based on their traceability granularity. Differential degradation processing follows a step-by-step degradation principle: full-level records are first downgraded to deep-level (removing full state snapshots and operation environment information), deep-level records are downgraded to standard-level (removing associated data snapshots), standard-level records are downgraded to lightweight-level (removing differences in business state snapshots), and lightweight records are securely deleted after reaching their final retention period. Each level of degradation further frees up storage space. Data change audit logs are permanently stored, including the change type (e.g., "full-level downgraded to deep-level"), change time, a summary of the record before the change (including the original values ​​of key fields such as operation type, operation user identifier, and operation timestamp), and the change triggering conditions (e.g., "exceeding the basic retention period of 730 days and not meeting the extended retention conditions"). The design motivation for the data retention lifecycle management mechanism is that operation event records will occupy a large amount of storage space over time, especially full-level and deep-level records which contain a large amount of state snapshots and context data. By employing differentiated retention strategies and compliance extension rules based on traceability granularity, the system achieves optimal allocation of storage resources while meeting compliance audit requirements. The differentiated degradation process uses a step-by-step degradation strategy rather than a one-time deletion, ensuring that basic operational traceability information is retained during the degradation process. The permanently stored data change audit log provides complete lifecycle audit tracing capabilities.

[0154] The present invention also discloses a customizable multi-terminal collaborative OA office traceability system, including a memory and a processor. The memory stores a customizable multi-terminal collaborative OA office traceability method program. When the customizable multi-terminal collaborative OA office traceability method program is executed by the processor, it implements the steps of the customizable multi-terminal collaborative OA office traceability method.

[0155] This invention discloses a customizable multi-terminal collaborative OA office traceability method and system. It acquires multi-terminal operation event data, calculates multi-dimensional contextual fingerprints, and weights them to obtain the stitching degree, stitching operation event pairs to construct a cross-terminal traceability chain. Then, combining the number of signatories, terminal switching times, and rule templates, it calculates operation risk dimension factors and inputs them into a scoring model to determine the traceability granularity level and select data for discarding. Subsequently, it generates an operation dependency graph with operation events as nodes and dependencies as edges. Finally, it matches abnormal topology patterns and outputs detection results. This achieves precise cross-terminal operation chaining, dynamic adaptation of traceability granularity, and intelligent anomaly identification, adapting to the multi-scenario collaborative office traceability needs of enterprises and improving traceability accuracy, flexibility, and security.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0157] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0158] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

Claims

1. A customizable multi-terminal collaborative OA office traceability method, characterized in that, include: Acquire operation event data from multiple terminal devices. The operation event data includes operation metadata, operation context, and terminal device identifier. Multi-dimensional contextual fingerprints are calculated based on operation event data. The stitching degree between operation event pairs is obtained by combining preset dimension weight coefficients. The operation event pairs are stitched together based on the comparison between the stitching degree and the preset stitching evaluation threshold to construct a cross-terminal traceability chain. Obtain the number of co-signers and approvers, the number of cross-terminal switching times, and the preset traceability rule templates; combine these with operational event data processing to obtain operational risk dimension factors in the cross-terminal traceability chain. Operational risk scores are obtained by processing operational risk dimension factors through a preset operational risk scoring model. Based on the operational risk scores, threshold comparisons are performed to obtain traceability granularity levels and corresponding mapping rules. Based on the traceability granularity levels and mapping rules, data selection is performed on operational event data in the cross-terminal traceability chain. Each operation event in the cross-terminal traceability chain is treated as a node in the graph, and directed edges are constructed based on the dependencies between operation events to generate an operation dependency graph. Perform subgraph matching of the operation-dependent graph using a preset abnormal topology pattern and output the abnormality detection results.

2. The customizable multi-terminal collaborative OA office traceability method according to claim 1, characterized in that, The acquisition of operation event data from multiple terminal devices includes operation metadata, operation context, and terminal device identifiers, specifically including: Obtain operation metadata, including operation type, operation timestamp, operation user ID, and the business process ID to which it belongs; Obtain the operation context, including the differences in business status snapshots before and after the operation, document identifiers involved in the operation, and identifiers of associated approval nodes; Obtain the terminal device identifier, including device type, device number, and device session identifier.

3. The customizable multi-terminal collaborative OA office traceability method according to claim 1, characterized in that, The process involves calculating a multi-dimensional context fingerprint based on operation event data, combining it with preset dimension weighting coefficients to obtain the stitching degree between operation event pairs, and stitching the operation event pairs together based on a comparison of the stitching degree with a preset stitching evaluation threshold to construct a cross-terminal traceability chain. Specifically, this includes: Multi-dimensional contextual fingerprints include user-dimensional fingerprints, process-dimensional fingerprints, time-dimensional fingerprints, device-dimensional fingerprints, and session-dimensional fingerprints; Normalized similarity is calculated for each of the multi-dimensional context fingerprints, and the stitching degree is obtained by weighted summation based on each normalized similarity and the preset dimension weight coefficients. The stitching degree is compared with a preset stitching evaluation threshold. If the stitching degree is greater than or equal to the preset stitching evaluation threshold, the operation event is stitched to build a cross-terminal traceability chain.

4. The customizable multi-terminal collaborative OA office traceability method according to claim 1, characterized in that, The process of obtaining the number of co-signers, the number of cross-terminal switching times, and the preset traceability rule template, combined with operation event data processing, to obtain the operation risk dimension factors in the cross-terminal traceability chain, specifically includes: The preset traceability rule template includes process type identifier, sensitive operation keywords, required operation type, keyness weight coefficient, normalized baseline value of the number of participants in the signing, normalized baseline value of the number of cross-terminal switching times, and granularity threshold configuration. By combining operational event data processing, operational risk dimension factors in the cross-terminal traceability chain are obtained, including operational sensitivity score, process node criticality score, number of participants in the signing process, and number of cross-terminal switching events. Calculate the operation sensitivity score based on sensitive operation keywords and required operation types; Calculate the criticality score of each process node based on the criticality weighting coefficient; The number of participants in the joint signing process is calculated as the ratio of the number of people who jointly approve the signing process to the normalized baseline value of the number of participants in the joint signing process. The cross-terminal handover frequency factor is calculated based on the ratio of the cross-terminal handover frequency to the normalized baseline value of the cross-terminal handover frequency.

5. The customizable multi-terminal collaborative OA office traceability method according to claim 4, characterized in that, The process involves obtaining an operational risk score by processing operational risk dimension factors through a preset operational risk scoring model, comparing the operational risk score with thresholds to obtain the traceability granularity level and corresponding mapping rules, and performing data selection / discarding on operational event data in the cross-terminal traceability chain based on the traceability granularity level and mapping rules. Specifically, this includes: The operation risk score is obtained by inputting the operation sensitivity score, process node criticality score, number of participants in the signing process, and number of cross-terminal switching times into the preset operation risk scoring model. Extract the first preset threshold, the second preset threshold, and the third preset threshold according to the granularity threshold configuration; If the operational risk score is less than the first preset threshold, the traceability granularity level is lightweight, and the operational event record only records the operational type and operational timestamp. When the operation risk score is greater than or equal to the first preset threshold and less than the second preset threshold, the traceability granularity level is standard level, and the operation event record also includes the difference in business status snapshots before and after the operation. When the operation risk score is greater than or equal to the second preset threshold and less than the third preset threshold, the traceability granularity level is depth level, and the operation event record also includes the operation context and related data snapshots. When the operational risk score is greater than or equal to the third preset threshold, the traceability granularity level is full-scale, and the operational event record also includes full-scale status snapshots, operational environment information, and upstream and downstream records of the operational chain.

6. The customizable multi-terminal collaborative OA office traceability method according to claim 5, characterized in that, The step of treating each operation event in the cross-terminal traceability chain as a node in a graph, constructing directed edges based on the dependencies between operation events, and generating an operation dependency graph specifically includes: Each operation event in the cross-terminal traceability chain is treated as a node; For pairs of operation events that satisfy a temporal sequence relationship, determine one or more dependency types in sequence, such as temporal dependency, state transit dependency, process node advancement dependency, and countersignature aggregation dependency. For operation event pairs that satisfy at least one dependency type, a directed edge is established from the preceding operation to the succeeding operation. The directed edge attributes are marked with a set of dependency type labels that satisfy the dependency type, thereby constructing an operation dependency graph.

7. The customizable multi-terminal collaborative OA office traceability method according to claim 1, characterized in that, The subgraph matching of the operation-dependent graph using a preset abnormal topology pattern, and the output of the abnormality detection result, specifically includes: Load one or more preset abnormal topology patterns from the preset abnormal topology pattern library. Each preset abnormal topology pattern includes a reference subgraph structure, node attribute matching constraints, and directed edge attribute matching constraints. The node attribute matching constraints include matching conditions for operation type, operation user identifier, and process node number. The directed edge attribute matching constraints include matching conditions for dependency type labels. For each preset abnormal topology pattern, based on the number of nodes and edges in the reference subgraph structure, a set of candidate subgraphs with node and edge sizes within the preset tolerance range is extracted from the operation dependency graph. For each candidate subgraph in the candidate subgraph set, perform a subgraph isomorphism determination with the preset abnormal topology pattern, including checking whether the attributes of each node in the candidate subgraph meet the node attribute matching constraints, and checking whether the dependency type labels of each directed edge in the candidate subgraph meet the directed edge attribute matching constraints. For candidate subgraphs that pass the subgraph isomorphism determination, an anomaly confidence score is calculated. The anomaly confidence score is obtained by weighted summation of the proportion of matching nodes to the total number of nodes in the reference subgraph, the proportion of matching edges to the total number of directed edges in the reference subgraph, and the risk scores of the operation events involved. Candidate subgraphs with anomaly confidence scores greater than or equal to a preset anomaly confidence threshold are identified as anomalous subgraphs. The anomalous topology pattern type, the set of operation event nodes involved, and the anomaly confidence scores of each anomalous subgraph are summarized, and the anomaly detection results are output.

8. A customizable multi-terminal collaborative OA office traceability system, characterized in that, The system includes a memory and a processor. The memory contains a customizable multi-terminal collaborative OA office tracing method program. When the processor executes the customizable multi-terminal collaborative OA office tracing method program, it performs the following steps: Acquire operation event data from multiple terminal devices. The operation event data includes operation metadata, operation context, and terminal device identifier. Multi-dimensional contextual fingerprints are calculated based on operation event data. The stitching degree between operation event pairs is obtained by combining preset dimension weight coefficients. The operation event pairs are stitched together based on the comparison between the stitching degree and the preset stitching evaluation threshold to construct a cross-terminal traceability chain. Obtain the number of co-signers and approvers, the number of cross-terminal switching times, and the preset traceability rule templates; combine these with operational event data processing to obtain operational risk dimension factors in the cross-terminal traceability chain. Operational risk scores are obtained by processing operational risk dimension factors through a preset operational risk scoring model. Based on the operational risk scores, threshold comparisons are performed to obtain traceability granularity levels and corresponding mapping rules. Based on the traceability granularity levels and mapping rules, data selection is performed on operational event data in the cross-terminal traceability chain. Each operation event in the cross-terminal traceability chain is treated as a node in the graph, and directed edges are constructed based on the dependencies between operation events to generate an operation dependency graph. Perform subgraph matching of the operation-dependent graph using a preset abnormal topology pattern and output the abnormality detection results.

9. The customizable multi-terminal collaborative OA office traceability system according to claim 8, characterized in that, The acquisition of operation event data from multiple terminal devices includes operation metadata, operation context, and terminal device identifiers, specifically including: Obtain operation metadata, including operation type, operation timestamp, operation user ID, and the business process ID to which it belongs; Obtain the operation context, including the differences in business status snapshots before and after the operation, document identifiers involved in the operation, and identifiers of associated approval nodes; Obtain the terminal device identifier, including device type, device number, and device session identifier.

10. The customizable multi-terminal collaborative OA office traceability system according to claim 9, characterized in that, The process involves calculating a multi-dimensional context fingerprint based on operation event data, combining it with preset dimension weighting coefficients to obtain the stitching degree between operation event pairs, and stitching the operation event pairs together based on a comparison of the stitching degree with a preset stitching evaluation threshold to construct a cross-terminal traceability chain. Specifically, this includes: Multi-dimensional contextual fingerprints include user-dimensional fingerprints, process-dimensional fingerprints, time-dimensional fingerprints, device-dimensional fingerprints, and session-dimensional fingerprints; Normalized similarity is calculated for each of the multi-dimensional context fingerprints, and the stitching degree is obtained by weighted summation based on each normalized similarity and the preset dimension weight coefficients. The stitching degree is compared with a preset stitching evaluation threshold. If the stitching degree is greater than or equal to the preset stitching evaluation threshold, the operation event is stitched to build a cross-terminal traceability chain.

Images