Intelligent processing method and system for document flow data of intranet mobile terminal

Abstract

The invention provides an intelligent processing method and system for document flow data of an intranet mobile terminal, and relates to the field of data processing. The method comprises the following steps: acquiring a to-be-approved document of a first intranet mobile terminal; encrypting the to-be-approved official document to obtain an encrypted official document; according to the federal behavior prediction model, approval scene data of a second intranet mobile terminal is determined, and the second intranet mobile terminal is a direct official document transfer node of the first intranet mobile terminal; if it is determined that the approval scene data of the second intranet mobile terminal does not meet the preset condition, a third intranet mobile terminal is determined, and the third intranet mobile terminal is an available document transfer node of the first intranet mobile terminal; and sending the encrypted official document to a third intranet mobile terminal for the third intranet mobile terminal to perform decryption approval. By implementing the technical scheme provided by the invention, the efficiency of processing the document flow data of the intranet mobile terminal can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of data processing, and in particular to a method and system for intelligently processing document circulation data on an intranet mobile terminal. Background Art

[0002] With the rapid development of mobile Internet technology, more and more organizations have begun to rely on mobile terminals to receive, circulate, approve and archive internal documents, so as to enable business processing anytime and anywhere, thereby improving overall office efficiency.

[0003] Currently, the document circulation process relies heavily on manual triggering and judgment, lacking automated data collection and processing capabilities. This can easily lead to transmission delays or duplicate operations, impacting approval efficiency. Furthermore, current platforms generally lack dynamic awareness of user behavior, device status, and approval scenarios, making it impossible to intelligently determine document circulation paths based on actual circumstances. This results in approval tasks easily accumulating at unavailable nodes, impacting overall circulation progress. Consequently, this approach can easily lead to low efficiency in document circulation data processing on mobile intranet terminals.

[0004] Therefore, there is an urgent need for an intelligent processing method and system for official document circulation data on an intranet mobile terminal. Summary of the Invention

[0005] The present application provides a method and system for intelligently processing official document circulation data on an intranet mobile terminal, which is convenient for improving the efficiency of processing official document circulation data on an intranet mobile terminal.

[0006] In a first aspect of the present application, a method for intelligent processing of official document circulation data on an intranet mobile terminal is provided, the method comprising: obtaining an official document to be approved from a first intranet mobile terminal; encrypting the official document to be approved to obtain an encrypted official document; determining the approval scenario data of a second intranet mobile terminal based on a federal behavior prediction model, the second intranet mobile terminal being a direct official document circulation node of the first intranet mobile terminal; if it is determined that the approval scenario data of the second intranet mobile terminal does not meet a preset condition, determining a third intranet mobile terminal, the third intranet mobile terminal being an available official document circulation node of the first intranet mobile terminal; and sending the encrypted official document to the third intranet mobile terminal for decryption and approval by the third intranet mobile terminal.

[0007] By adopting the above technical solution and introducing a federated behavior prediction model, the system dynamically and intelligently determines the document flow path, significantly improving the efficiency and reliability of document approval in a mobile office environment. This method first encrypts documents for approval, ensuring data security during transmission and minimizing the risk of confidentiality leaks. Secondly, the system not only forwards files based on a fixed process, but also proactively acquires approval scenario data from a second intranet mobile terminal. Leveraging user behavior models trained within a federated learning framework, the system accurately predicts whether that node has the ability to respond promptly, thus preventing documents from being stranded at inefficient or unavailable nodes. If the response condition of a node is detected to fall below a preset threshold, the system adjusts the flow path in real time, automatically identifying a third intranet mobile terminal as a new available node, and enabling intelligent bypass of the document. This mechanism effectively addresses the rigidity of approval paths, delayed responses, and reliance on manual judgment in traditional systems, offering greater process flexibility and intelligence, thereby improving the efficiency of document flow data processing on intranet mobile terminals.

[0008] Optionally, obtaining the official document awaiting approval from the first intranet mobile terminal specifically includes: reading the official document entry with the awaiting approval label from the local database or cache of the first intranet mobile terminal; querying the local index service based on the unique identifier in the official document entry to obtain metadata, the metadata including the official document title, source department and creation time; determining the official document awaiting approval based on the official document title, source department and creation time.

[0009] By adopting the above technical solution, firstly, the method can complete the initial data reading without relying on external server requests, and preferentially extract document entries marked as pending approval from the local database or cache, which greatly reduces the system response delay and is especially suitable for office scenarios in intranet or weak network environments. Secondly, by extracting the unique identifier in the official document entry and combining it with the local index service for metadata retrieval, the uniqueness and consistency of the obtained document information are ensured, avoiding multi-version document conflicts and misoperation problems. The core fields contained in the metadata, such as the official document title, source department and creation time, not only have strong recognition capabilities, but also provide a stable and reliable basis for subsequent encryption processing, approval scenario modeling and intelligent flow decision-making.

[0010] Optionally, encrypting the document to be approved to obtain an encrypted document specifically includes: determining a symmetric encryption key based on the document to be approved; dividing the document to be approved to obtain multiple data blocks; reading binary data according to the data blocks, and encrypting each of the read binary data in blocks using the symmetric encryption key, and appending a random initialization vector to obtain the encrypted document.

[0011] By employing this technical solution, fine-grained data partitioning and a high-strength encryption mechanism effectively enhance the data security and tamper resistance of documents awaiting approval during mobile transmission. This method first automatically generates or selects symmetric encryption keys based on the document's content, ensuring consistency and confidentiality during the encryption process. It then partitions the document into multiple data blocks, making the encryption operation more controllable and parallelizable, reducing the overall encryption computational burden and making it particularly suitable for efficient execution on resource-constrained mobile devices. By reading the corresponding binary data for each data block and performing block-by-block encryption using a symmetric encryption algorithm, and appending a separate random initialization vector to each encryption process, this not only enhances the encrypted data's resistance to attacks but also effectively prevents the leakage of ciphertext structure due to duplicate data. This encryption strategy exhibits high unpredictability and replay resistance, ensuring content integrity and access control during document transmission, storage, or forwarding, preventing the leakage of sensitive information through unauthorized nodes or man-in-the-middle attacks. Furthermore, this encryption method provides structured ciphertext support for subsequent decryption and approval operations, enabling block-by-block recovery of the original text at the decryption end, improving the fault tolerance and stability of decryption.

[0012] Optionally, the approval scenario data of the second intranet mobile terminal is determined based on the federal behavior prediction model, and the second intranet mobile terminal is a direct document flow node of the first intranet mobile terminal, specifically including: obtaining the approval characteristics of the second intranet mobile terminal, the approval characteristics including the current time, geographic location and current activity of the user; inputting the approval characteristics into the federal behavior prediction model to obtain the approval response probability and the average approval time; and determining the approval scenario data based on the approval response probability and the average approval time.

[0013] By employing the aforementioned technical solution, a federated behavior prediction model is used to determine the processing method for approval scenario data. This method leverages the multiple advantages of contextual awareness, individual behavior modeling, and privacy protection, effectively improving intelligent decision-making and execution efficiency in the document circulation process. This method first collects approval characteristics from mobile devices in real time, including key contextual information such as the current time, location, and user activity. These characteristics not only reflect the user's accessibility and work status, but also provide a dynamic behavioral basis for subsequent decision-making. The system then feeds these characteristics into the federated behavior prediction model. By integrating the historical behavior patterns of multiple user devices within the model, the model accurately predicts the approval response probability and expected processing time for the current node without exposing the original data, thereby achieving a quantitative assessment of node availability and response efficiency. This model utilizes a federated learning framework, preserving the generalization capabilities of distributed data training while maintaining the privacy and security of localized data computation, thus avoiding the data leakage risks associated with centralized behavior modeling. After obtaining the response probability and average processing time, the system uses them as approval scenario data to further assess the current node's suitability for receiving document tasks, forming a measurable and explainable intelligent screening mechanism.

[0014] Optionally, if it is determined that the approval scenario data of the second intranet mobile terminal does not meet the preset conditions, then determining the third intranet mobile terminal specifically includes: judging whether the approval scenario data is consistent with the preset scenario, and the preset scenario includes within working hours, in the company, and the user's idle time period; if it is determined that any one of the scenarios in the approval scenario data is inconsistent with the preset scenario, then obtaining a list of all available terminals under the same approval link as the first intranet mobile terminal; according to the available terminal list, traversing and filtering to obtain the third intranet mobile terminal.

[0015] By implementing this technical solution and building a flexible, highly fault-tolerant approval path replacement mechanism, we effectively address process bottlenecks in traditional mobile office systems caused by node unavailability or delayed approval responses, significantly improving the continuity and stability of document flow. This method rapidly adjusts when detecting that the approval scenario data from a second intranet mobile terminal does not match the pre-set ideal processing scenario, preventing documents from being stranded on nodes with insufficient response capacity or temporary unavailability. The defined pre-set scenario conditions, such as "within working hours," "within the company's geographic area," and "user's idle time period," all have clear office semantics and detectability, accurately reflecting the user's actual availability. If any scenario is determined to be unsatisfactory, the system immediately triggers the redundant link mechanism, obtaining a complete list of all potentially available nodes from the same approval path as the first intranet mobile terminal. By traversing and intelligently filtering these available nodes, the system quickly selects the optimal third intranet mobile terminal as an alternative processing node, ensuring uninterrupted and non-repeated document processing and maintaining the efficiency of the approval process.

[0016] Optionally, inputting the approval features into the federal behavior prediction model to obtain the approval response probability and the average approval time specifically includes: using the federal behavior prediction model, comparing the approval features according to preset dimensions to obtain comparison results, the preset dimensions including user historical behavior features, context environment features, user real-time status features, and node collaboration features; using the federal behavior prediction model to perform forward calculation and result decoding on the approval features to obtain the approval response probability and the average approval time.

[0017] By adopting the above technical solution, through refined modeling and intelligent comparison of approval features across multiple preset dimensions, a federated behavioral prediction model is used to quantitatively assess approval responsiveness. This not only significantly improves the accuracy and contextual adaptability of prediction results, but also enhances the system's intelligent decision-making capabilities in dynamic office environments. Specifically, the method first categorizes and compares approval features according to multiple preset behavioral and environmental dimensions. These dimensions include historical user behavior characteristics (such as previous approval frequency and response time), contextual environmental characteristics (such as network environment, device status, and geographic location), real-time user status characteristics (such as whether the user is actively using the system or whether Do Not Disturb mode is enabled), and node collaboration characteristics (such as the task coordination and load relationship between the node and other nodes). This multi-dimensional information fusion analysis can more comprehensively reflect the current node's responsiveness and feasibility for document processing tasks, effectively avoiding bias or misjudgment caused by single-metric judgment.

[0018] Optionally, the method further includes: obtaining a custom approval process sent by a user device; determining a custom intranet mobile terminal according to the custom approval process; and performing document circulation processing on the document to be approved according to the custom intranet mobile terminal.

[0019] By adopting the above technical solution and introducing a user-defined approval process mechanism, users are given the ability to actively configure the document flow path in an intranet environment, significantly enhancing the system's flexibility, personalized adaptability, and controllability of internal organizational management. Traditional document approval processes usually use fixed paths or system-preset rules for flow. Although this facilitates unified management, it is often difficult to respond flexibly when faced with different types of documents, temporary organizational structure adjustments, or changes in the priority of specific matters, resulting in low approval efficiency or unreasonable paths. By allowing user devices to actively send customized approval processes, the system can dynamically generate exclusive approval channels based on user-specified nodes, sequences, or concurrent structures, effectively meeting the differentiated flow requirements in specific business scenarios.

[0020] In a second aspect of the present application, an intelligent processing system for document circulation data of an intranet mobile terminal is provided, the system comprising an acquisition module and a processing module, wherein the acquisition module is used to acquire the document to be approved from the first intranet mobile terminal; the processing module is used to encrypt the document to be approved to obtain an encrypted document; the processing module is also used to determine the approval scenario data of the second intranet mobile terminal based on the federal behavior prediction model, the second intranet mobile terminal being the direct document circulation node of the first intranet mobile terminal; the processing module is also used to determine a third intranet mobile terminal if it is determined that the approval scenario data of the second intranet mobile terminal does not meet the preset conditions, the third intranet mobile terminal being the available document circulation node of the first intranet mobile terminal; the processing module is also used to send the encrypted document to the third intranet mobile terminal for decryption and approval by the third intranet mobile terminal.

[0021] In a third aspect of the present application, an electronic device is provided, which includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory so that the electronic device performs the method described above.

[0022] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores instructions. When the instructions are executed, the method described above is executed.

[0023] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: By introducing a federated behavior prediction model, a system dynamically and intelligently determines document flow paths, significantly improving the efficiency and reliability of document approval in mobile office environments. This method first encrypts documents for approval, ensuring data security during transmission and minimizing the risk of leaks. Second, the system not only forwards documents based on a fixed process, but also proactively acquires approval scenario data from a second intranet mobile client. Leveraging user behavior models trained within a federated learning framework, it accurately predicts whether that node has the ability to respond promptly, thus preventing documents from being stranded at inefficient or unavailable nodes. If the response conditions of a node fall below a preset threshold, the system adjusts the flow path in real time, automatically identifying a third intranet mobile client as a new available node and enabling intelligent bypass of the document. This mechanism effectively addresses the rigidity of approval paths, delayed responses, and reliance on manual judgment in traditional systems, offering greater process flexibility and intelligence, thereby improving the efficiency of document flow data processing on intranet mobile clients. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 A flowchart of a method for intelligently processing document circulation data on an intranet mobile terminal provided in an embodiment of the present application; Figure 2 Another flowchart of a method for intelligently processing document circulation data on an intranet mobile terminal provided by an embodiment of the present application; Figure 3 A schematic diagram of a module of an intranet mobile terminal document circulation data intelligent processing system provided in an embodiment of the present application; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0025] Explanation of the reference numerals: 31, acquisition module; 32, processing module; 41, processor; 42, communication bus; 43, user interface; 44, network interface; 45, memory. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

[0027] In the description of the embodiments of this application, words such as "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "for example" or "for instance" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "for example" or "for instance" is intended to present the relevant concepts in a concrete manner.

[0028] In the description of the embodiments of the present application, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0029] With the continuous evolution of mobile Internet technology, more and more organizations are gradually migrating the receipt, circulation, approval and archiving of internal documents to mobile terminals to achieve flexible processing of office business and cross-time and space collaboration, thereby significantly improving overall operational efficiency.

[0030] However, in practice, the current document circulation process still relies heavily on manual operations and subjective judgment, lacking systematic data collection and automatic processing capabilities. This often leads to problems such as delayed document delivery, process interruptions, or duplicate submissions, seriously restricting the improvement of approval efficiency. At the same time, existing mobile office platforms generally lack the ability to dynamically perceive and intelligently analyze user behavior characteristics, device operating status, and actual approval scenarios. They are unable to make adaptive circulation decisions based on node availability or environmental changes, which easily causes approval tasks to be concentrated on terminals with insufficient response capabilities, thereby causing process backlogs and efficiency bottlenecks. Therefore, the existing methods still have significant deficiencies in the efficiency of processing mobile document circulation data in an intranet environment.

[0031] In order to solve the above technical problems, this application provides an intelligent processing method for document flow data on an intranet mobile terminal, referring to Figure 1 , Figure 1 This is a flow chart of a method for intelligently processing document circulation data on an intranet mobile terminal provided in an embodiment of the present application. The method is applied to a server and includes steps S110 to S150, which are as follows: S110: Obtain the official document to be approved on the first intranet mobile terminal.

[0032] Specifically, throughout the document circulation process, when a mobile terminal (the "first intranet mobile terminal") contains pending approval documents, the backend server proactively establishes communication with the terminal and pulls the identification or content of these pending approval documents to the server via a secure channel (such as an intranet VPN or HTTPS interface). This allows the server to centrally monitor the status of approval tasks across all mobile terminals, enabling subsequent centralized information aggregation, process scheduling, and intelligent decision-making, improving process visibility and controllability.

[0033] For example, suppose Manager Li has a "Department Budget Adjustment Request" marked as "Awaiting Approval" on his phone. This task is stored in the phone's local cache. When the server triggers a scheduled synchronization operation or receives a status report from Manager Li, it calls an interface on Manager Li's phone to pull the approval document's DocID, title, submission time, and other information from the company's approval management platform. The server can then perform unified encryption, metadata analysis, task assignment, or intelligent scheduling on this document, ensuring that no documents are missed or duplicated, further automating and intelligentizing the subsequent approval process.

[0034] In one possible implementation, obtaining the official documents awaiting approval from the first intranet mobile terminal specifically includes: reading the official document entry with the awaiting approval tag from the local database or cache of the first intranet mobile terminal; querying the local index service based on the unique identifier in the official document entry to obtain metadata, the metadata including the official document title, source department, and creation time; and determining the official document awaiting approval based on the official document title, source department, and creation time.

[0035] Specifically, first, the mobile terminal will mark each file awaiting approval with a "pending approval" label in the local database or cache. When the system needs to obtain these files, it will directly read all the document entry information marked with this label from the local storage; then, the system will use the unique identifier carried in the entry (such as the document number or hash value) to query the index service on the same terminal to obtain the metadata corresponding to the document, including the title of the document, the department that initiated the document, and the creation time of the document and other key information; finally, the system will make a comprehensive judgment on these metadata to confirm whether it is the target document that currently needs to be approved, thereby completing the "search-verify-lock" process of the document awaiting approval.

[0036] For example, Mr. Zhang's mobile phone cache contains multiple documents, only two of which are marked "pending approval." When the backend or client triggers the "retrieve pending approval" action, the system first retrieves these two entries, obtaining their internal unique numbers, "DOC20250512A" and "DOC20250513B," respectively. The indexing service on Mr. Zhang's phone then takes these numbers and returns their metadata, such as "Q2 Project Budget Application, Finance Department, 2025-05-12 09:30" and "Employee Training Plan, Human Resources Department, 2025-05-13 14:45." Based on this metadata, the system accurately identifies the two documents requiring approval, laying a solid foundation for subsequent encryption, intelligent routing, and approval operations.

[0037] S120: Encrypt the document to be approved to obtain an encrypted document.

[0038] Specifically, after receiving the official document for approval uploaded or synchronized from the mobile terminal, the backend server will encrypt the original document to generate an "encrypted official document" file that can only be decrypted and viewed by authorized nodes. Specifically, the server will first select or generate a symmetric encryption key based on the system security policy or session information, and then split the entire official document file into several data blocks in a certain way, encrypt them block by block using the key, and append a randomized initialization vector to each block, and finally aggregate all the encrypted data blocks into a complete encrypted file package. In this way, even if the official document is intercepted during network transmission or storage, only meaningless ciphertext can be seen, thereby effectively preventing unauthorized access and information leakage.

[0039] For example, suppose the Finance Department's "Q2 Project Budget Application.docx" is marked as pending approval on Zhang Gong's mobile phone. The server then pulls the document and performs encryption. The system generates an AES-256 symmetric key, divides the original document into several MB-sized data blocks, encrypts each of them, and assembles them into the "Q2 Budget Application.enc" file. Metadata such as the key identifier, algorithm version, and initialization vector used for this encryption is attached to the file header. From then on, no matter how the encrypted file is forwarded to subsequent approval nodes via the intranet message bus, only terminals holding the corresponding decryption key can restore the original document. This not only ensures the confidentiality of the document during its circulation, but also preserves the necessary security traces for subsequent controlled decryption and auditing.

[0040] In one possible implementation, an official document to be approved is encrypted to obtain an encrypted official document, specifically including: determining a symmetric encryption key based on the official document to be approved; dividing the official document to be approved to obtain multiple data blocks; reading binary data by data block, and encrypting each read binary data in blocks using the symmetric encryption key, and appending a random initialization vector to obtain an encrypted official document.

[0041] Specifically, first, the system will obtain or generate a symmetric encryption key based on the content of the official document to be approved or the associated session information. This key will also be securely called by the authorized node in the subsequent decryption link; then, the server will divide the official document file into multiple data blocks according to a predetermined size standard (for example, 1MB or less per block). This block technology can not only execute encryption operations in parallel to improve efficiency, but also reduce single memory usage; then, the system reads the binary content of each data block in turn and encrypts it using a symmetric key. In order to avoid the same data block generating the same ciphertext, each encryption operation will also be attached with a randomly generated initialization vector (IV), which can effectively resist replay attacks and pattern analysis attacks; finally, all encrypted data blocks and their corresponding initialization vectors are aggregated and packaged to form a complete "encrypted official document" file.

[0042] For example, suppose the Human Resources Department uploads a document for approval titled "Employee Training Plan.pdf." Upon receiving the document, the server first selects an AES-256 symmetric key, "Key-HR-2025," through its internal key management module. The system then divides the PDF into four 512KB blocks, reading the binary data from each. When encrypting the first block, the system generates a random IV1 for it and encrypts it using "Key-HR-2025," producing ciphertext block C1. Similarly, for the remaining three blocks, IV2, IV3, and IV4 are generated, producing ciphertext blocks C2, C3, and C4. Finally, the server combines IV1–IV4 and C1–C4 into the file "Employee Training Plan.enc" according to a predefined packet format, recording the algorithm version and key identifier used for this encryption in the file header. This block-by-block encryption and the addition of a random initialization vector prevent an attacker from recovering the original text without knowing the key, effectively ensuring the data security of official documents in mobile office environments.

[0043] S130. Determine the approval scenario data of the second intranet mobile terminal according to the federated behavior prediction model, where the second intranet mobile terminal is a direct document transfer node of the first intranet mobile terminal.

[0044] Specifically, during the document circulation process, the backend server utilizes a behavior prediction model pre-trained through federated learning to conduct a real-time availability assessment of each potential downstream approval node (i.e., the direct transferee of the first intranet mobile terminal). This assessment then generates "approval scenario data" for each node—including its current responsiveness indicator and environmental status. Specifically, the server collects the approval characteristics of the second node, such as the current time, geographic location, and schedule, and feeds these characteristics into the federated behavior prediction model. The model then outputs the node's approval response probability and estimated approval duration under the current circumstances. These quantitative results then form the node's approval scenario data, enabling subsequent determination of its suitability for receiving and processing new document tasks.

[0045] For example, suppose the first intranet mobile device (Engineer Zhang's phone) needs to transfer a budget approval document to his direct subordinate, Li Si. The server first collects information from Li Si's phone, including the current time (10:30 AM on a weekday), location (office), and schedule status (available), and inputs this information into the federated behavior prediction model. Combining Li Si's previous approval records with his organization's behavioral data, the model predicts Li Si's current "approval response probability" of 0.87 and "average approval time" of 1.2 hours. These two values constitute Li Si's approval scenario data. Based on this assessment, the system determines Li Si's strong approval capabilities at this point and decides whether to send the document to him for processing or, if conditions are not met, to bypass the document by selecting another node.

[0046] In one possible implementation, based on the federal behavior prediction model, the approval scenario data of the second intranet mobile terminal is determined, and the second intranet mobile terminal is the direct document flow node of the first intranet mobile terminal. Specifically, the method includes: obtaining the approval characteristics of the second intranet mobile terminal, and the approval characteristics include the current time, geographic location, and current activity of the user; inputting the approval characteristics into the federal behavior prediction model to obtain the approval response probability and the average approval time; and determining the approval scenario data based on the approval response probability and the average approval time.

[0047] Specifically, the server first collects information from the second intranet mobile terminal in real time, representing the approval scenario. This information, called "approval features," primarily includes three aspects: the current time (e.g., morning, afternoon, or non-working hours), used to determine whether the node is within regular working hours; the geographic location (e.g., office, conference room, or outing location), reflecting the user's physical accessibility; and the user's current activity (e.g., in a meeting, focused on work, or taking a break), to assess their immediate processing capabilities. These features comprehensively characterize the target approver's availability and serve as input vectors to a behavior prediction model pre-trained through federated learning.

[0048] Within the model, these approval features are compared and calculated across multiple dimensions, generating two key metrics: "Approval Response Probability" and "Average Approval Time." The response probability indicates the likelihood that a node will quickly respond to an approval request under the current circumstances, while the average approval time predicts how long it would take the node to complete an approval under similar conditions. The server aggregates these two quantitative results to form complete "approval scenario data" for that node, which is used for subsequent decision-making, determining whether to send the file directly to the node or trigger a bypass mechanism.

[0049] For example, suppose Mr. Zhang's phone is transferring a budget report to his direct subordinate, Mr. Li. The system detects the current time (3:00 PM), location ("on a business trip"), and user activity ("riding a vehicle") from Mr. Li's phone and inputs these features into a behavioral prediction model. Combining Mr. Li's past approval habits and status data, the model calculates a 0.65 probability of response and an average approval time of 2.3 hours. These two values together constitute Mr. Li's current approval scenario data, which the system then uses to determine whether to assign the task to Mr. Li or select a more appropriate approval node to expedite the process.

[0050] S140: If it is determined that the approval scenario data of the second intranet mobile terminal does not meet the preset conditions, a third intranet mobile terminal is determined, and the third intranet mobile terminal is an available document flow node of the first intranet mobile terminal.

[0051] Specifically, after the server evaluates the approval scenario data of the second intranet mobile terminal using a federated behavior prediction model, if it finds that the node does not meet pre-defined availability conditions (e.g., outside of work hours, outside the company, or the user is busy), the system will not continue to send the document to that node and instead initiate a backup node selection process. During this process, the system first selects a list of "available nodes" that are currently online and have matching permissions from all potential nodes in the same approval chain as the first intranet mobile terminal. These nodes are then scored and ranked based on historical approval efficiency, real-time load, and other criteria. Finally, the third intranet mobile terminal with the highest score is selected as the actual transfer target, ensuring that the document can continue to efficiently advance between available nodes.

[0052] In one possible implementation, if it is determined that the approval scenario data of the second intranet mobile terminal does not meet the preset conditions, then a third intranet mobile terminal is determined, specifically including: judging whether the approval scenario data is consistent with the preset scenario, the preset scenario includes within working hours, in the company, and the user's idle time period; if it is determined that any one of the scenarios in the approval scenario data is inconsistent with the preset scenario, then obtaining a list of all available terminals under the same approval link as the first intranet mobile terminal; according to the list of available terminals, traversing and filtering to obtain the third intranet mobile terminal.

[0053] Specifically, to ensure the rapid and efficient flow of official documents, the server rigorously compares the approval scenario data from the second intranet mobile terminal with predefined ideal processing conditions. These "preset scenarios" typically encompass three dimensions: "within working hours," ensuring that tasks aren't sent after hours or during breaks; "within the company's boundaries," ensuring that users can immediately access intranet or private network services; and "users' idle time periods," ensuring that they're not preoccupied with meetings, calls, or breaks, preventing timely responses. If the server detects that the second node doesn't meet any of these criteria (for example, if it's outside working hours or the user is currently in a meeting), it immediately initiates the next step in the process, selecting an available node, to prevent the task from stalling due to being assigned to an unavailable node.

[0054] After initiating the bypass mechanism, the server first selects a "list of available nodes" from all potential approval nodes in the same approval chain as the first intranet mobile terminal. These nodes are currently online, have the appropriate approval authority, and haven't reached their maximum load limit. The system then traverses and scores each candidate node in the list according to a predetermined priority strategy, which may include factors such as the node's historical approval speed, current backlog, and close collaboration with the initiator. Ultimately, the node with the highest score and best suited to real-time requirements is selected as the third intranet mobile terminal, ensuring uninterrupted document flow and consistent processing at the optimal node.

[0055] For example, suppose Mr. Zhang (the first intranet mobile client) initially intended to forward the "Annual Audit Report" to Mr. Li (the second node). However, the server discovered that Mr. Li's current time was 7 PM, exceeding the "Within Working Hours" condition, and his device was in "Do Not Disturb" mode, meaning it did not meet the "User Idle" condition. Therefore, the report was not sent to Mr. Li. Next, the server screened Wang Wu, Zhao Liu, and Sun Qi, all of whom were in the same approval process, to select only two candidates: Wang Wu and Sun Qi, who were online and had within the limit on their pending tasks. The server then calculated their scores based on their average past approval time and their frequency of collaboration with Mr. Zhang. Finally, Wang Wu was selected as the third intranet mobile client and the "Annual Audit Report" was sent to him for decryption and approval, thus avoiding task delays at Mr. Li's node and ensuring approval efficiency.

[0056] S150: Send the encrypted official document to the third intranet mobile terminal for decryption and approval by the third intranet mobile terminal.

[0057] Specifically, the server will efficiently push the encrypted official document from the server side to the selected third intranet mobile terminal through a secure channel, so that the node can complete the decryption locally and carry out the approval operation. Specifically, the server will package the "encrypted official document" together with the necessary process identification, signature summary and timestamp and other metadata into a complete transmission package, and then reliably deliver the transmission package to the mobile terminal of the third node through the intranet dedicated message bus, VPN channel or HTTPS interface. In order to ensure the integrity and legality of the transmission process, the server will also digitally sign the transmission package. The receiving end can only perform subsequent decryption operations after verifying the signature locally. At the same time, the server will record a "sent" log and continuously listen to the receiving end's confirmation receipt to ensure that the official document can be retried in the event of network jitter or interruption.

[0058] For example, after Wang Wu was selected as the third intranet mobile terminal, the server packaged the "Q2 Budget Application.enc" file along with the process ID, the reason for the previous bypass trigger, and the server signature, and pushed it to Wang Wu's mobile app through the company's intranet message queue. After Wang Wu received the notification on his phone, he clicked on the message to view the transmission details. The system first verified the server signature and verified the integrity of the data, then automatically called the local security module to decrypt the encrypted file block by block using the pre-negotiated symmetric key and initialization vector, and finally presented the original and complete "Q2 Budget Application" document on the approval interface. After that, Wang Wu can directly annotate, approve, or forward the document on the mobile terminal. The entire process ensures the confidentiality of the file and the continuity of the process, while taking into account the reliability and auditability of the transmission.

[0059] In one possible implementation, the approval features are input into a federated behavior prediction model to obtain the approval response probability and the average approval time, specifically including: using the federated behavior prediction model, comparing the approval features according to preset dimensions to obtain comparison results, where the preset dimensions include user historical behavior features, contextual environment features, user real-time status features, and node collaboration features; and using the federated behavior prediction model to perform forward calculations on the approval features and decode the results to obtain the approval response probability and the average approval time.

[0060] Specifically, the server uses a federated behavior prediction model to conduct a "dimensionalized" comparative analysis of different types of approval features, ensuring that the collected multi-source information can accurately reflect the approval capabilities and availability of the target node. Specifically, the server will first classify the approval features according to four preset dimensions: user historical behavior characteristics: such as the average approval time, approval frequency, and historical delay rate of the person for the same type of documents in the past; contextual environment characteristics: such as the current network environment, terminal location (office, outing, conference room, etc.) and device connection status; user real-time status characteristics: such as whether the user is currently in a call, meeting, or "Do Not Disturb" mode, as well as the device battery level or server notification settings; node collaboration characteristics: such as the closeness of collaboration with the initiator, the number of times they have participated in the process together in the past, and the current length of the to-do queue.

[0061] During model processing, the features in each dimension are matched and compared with the behavioral patterns trained in the model to assess which factors are most significantly influencing the node at that moment. For example, if a person has historically taken an average of one hour to complete the same type of approval and is currently experiencing high load, the model will assign higher weights to the "historical duration" and "real-time load" dimensions to more accurately reflect their current processing capacity. After completing the cross-dimensional comparison, the model performs forward inference on the concatenated feature vectors and maps the hidden layer outputs to two key metrics: Approval Response Probability, which indicates the likelihood that the node will quickly respond to approval requests given the current feature combination (e.g., 0.72, indicating a 72% probability of initiating processing within a short period of time); and Average Approval Duration, which predicts the average time it will take for the node to complete the approval task (e.g., 1.8 hours). After inference, the server performs the necessary inverse transformation on the probability value to ensure it falls within the range of 0 to 1 and denormalizes or rescales the duration value to restore it to real time units. Ultimately, these two quantitative results together constitute the approval scenario data for the node, which is used for subsequent process routing or bypass decisions.

[0062] For example, let's assume the server processes Wang Wu's approval profile: historical behavior shows he takes an average of 1.2 hours to process similar documents. His current environment is "office Wi-Fi," his real-time status is "meeting ended and device battery is 80%," and his collaboration profile is "good collaboration with the initiator over the past five processes, with only two items in the pending queue." After comparing these four dimensions, the model predicts a 0.81 probability of Wang Wu's approval response (an 81% probability of a quick approval start) and an average approval time of 1.5 hours. This data becomes crucial for deciding whether to send the document directly to Wang Wu.

[0063] In one possible implementation, refer to Figure 2 , Figure 2Another flow chart of a method for intelligently processing document circulation data on an intranet mobile terminal provided in an embodiment of the present application includes steps S210 to S230, and the above steps are as follows: S210, obtaining a custom approval process sent by a user device; S220, determining a custom intranet mobile terminal based on the custom approval process; S230, performing document circulation processing on the document to be approved according to the custom intranet mobile terminal.

[0064] Specifically, the server first receives and parses the "custom approval process" uploaded from the user's device. This can be the order of approval nodes manually added and adjusted by the user in the mobile interface, or a list of personnel or departments quickly selected based on a template. After parsing, the server will locate the corresponding "custom intranet mobile terminal" in the intranet based on each node identifier in the custom process (such as the approver account, department code, or role label), that is, the mobile terminal device actually participating in the approval. Finally, the server will push the documents to be approved to these custom nodes sequentially or in parallel according to the process sequence, ensuring that the files are encrypted, distributed, decrypted, and approved according to the user's preset path.

[0065] For example, suppose Project Leader Zhang initiates a market research report. This report must first be reviewed by Financial Manager Li Si, then by Legal Advisor Wang Wu, and finally by General Manager Zhao Liu for final approval. Zhang customizes the approval process on the mobile interface, selecting Li Si, Wang Wu, and Zhao Liu as approvers. Upon receiving this customized process, the server identifies the mobile devices (such as phones or tablets) of Li Si, Wang Wu, and Zhao Liu on the intranet, encrypts the report, and pushes it first to Li Si's device. After Li Si completes the review and confirms it, the server automatically forwards the report to Wang Wu according to the process, and so on, until Zhao Liu's final review. This allows users to fully understand the approval process, without being restricted by server defaults or pre-set backend rules. This allows for a truly visual and customized approval process.

[0066] This application also provides an intranet mobile terminal document circulation data intelligent processing system, refer to Figure 3 , Figure 3A module schematic diagram of an intelligent processing system for document circulation data of an intranet mobile terminal provided in an embodiment of the present application, wherein the system is a server, and the server includes an acquisition module 31 and a processing module 32, wherein the acquisition module 31 acquires the document to be approved of the first intranet mobile terminal; the processing module 32 encrypts the document to be approved to obtain an encrypted document; the processing module 32 determines the approval scenario data of the second intranet mobile terminal based on the federal behavior prediction model, and the second intranet mobile terminal is the direct document circulation node of the first intranet mobile terminal; if the processing module 32 determines that the approval scenario data of the second intranet mobile terminal does not meet the preset conditions, then it determines a third intranet mobile terminal, and the third intranet mobile terminal is the available document circulation node of the first intranet mobile terminal; the processing module 32 sends the encrypted document to the third intranet mobile terminal for decryption and approval by the third intranet mobile terminal.

[0067] In one possible implementation, the acquisition module 31 acquires the official documents to be approved from the first intranet mobile terminal, specifically including: the processing module 32 reads the official document entry with the pending approval label from the local database or cache of the first intranet mobile terminal; the processing module 32 queries the local index service based on the unique identifier in the official document entry to obtain metadata, the metadata including the official document title, source department and creation time; the processing module 32 determines the official document to be approved based on the official document title, source department and creation time.

[0068] In one possible implementation, the processing module 32 encrypts the document to be approved to obtain an encrypted document, specifically including: the processing module 32 determines the symmetric encryption key based on the document to be approved; the processing module 32 divides the document to be approved to obtain multiple data blocks; the processing module 32 reads binary data according to the data blocks, and encrypts each binary data read in blocks using the symmetric encryption key, and appends a random initialization vector to obtain an encrypted document.

[0069] In one possible implementation, the processing module 32 determines the approval scenario data of the second intranet mobile terminal based on the federal behavior prediction model. The second intranet mobile terminal is the direct document flow node of the first intranet mobile terminal. Specifically, the processing module 32 obtains the approval characteristics of the second intranet mobile terminal, and the approval characteristics include the current time, geographic location, and current activity of the user; the processing module 32 inputs the approval characteristics into the federal behavior prediction model to obtain the approval response probability and the average approval time; the processing module 32 determines the approval scenario data based on the approval response probability and the average approval time.

[0070] In one possible implementation, if the processing module 32 determines that the approval scenario data of the second intranet mobile terminal does not meet the preset conditions, it determines the third intranet mobile terminal, specifically including: the processing module 32 determines whether the approval scenario data is consistent with the preset scenario, and the preset scenario includes within working hours, in the company, and the user's idle time period; if the processing module 32 determines that any scenario in the approval scenario data is inconsistent with the preset scenario, it obtains a list of all available terminals under the same approval link as the first intranet mobile terminal; the processing module 32 traverses and filters the available terminal list to obtain the third intranet mobile terminal.

[0071] In one possible implementation, the processing module 32 inputs the approval features into the federal behavior prediction model to obtain the approval response probability and the average approval time, specifically including: the processing module 32 uses the federal behavior prediction model to compare the approval features according to preset dimensions to obtain comparison results, and the preset dimensions include user historical behavior features, context environment features, user real-time status features, and node collaboration features; the processing module 32 uses the federal behavior prediction model to perform forward calculation and result decoding on the approval features to obtain the approval response probability and the average approval time.

[0072] In a possible implementation, the acquisition module 31 acquires the custom approval process sent by the user device; the processing module 32 determines the custom intranet mobile terminal according to the custom approval process; and the processing module 32 performs document flow processing on the approval document according to the custom intranet mobile terminal.

[0073] It should be noted that the above embodiments provide devices that implement their functions using only the division of the above functional modules as examples. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0074] This application also provides an electronic device, referring to Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include: at least one processor 41, at least one network interface 44, a user interface 43, a memory 45, and at least one communication bus 42.

[0075] The communication bus 42 is used to realize the connection and communication between these components.

[0076] The user interface 43 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 43 may also include a standard wired interface and a wireless interface.

[0077] The network interface 44 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0078] The processor 41 may include one or more processing cores. Using various interfaces and circuits, the processor 41 connects to various components within the server. It executes instructions, programs, code sets, or instruction sets stored in the memory 45, as well as accesses data stored in the memory 45, to perform various server functions and process data. Optionally, the processor 41 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 41 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing content displayed on the display screen; and the modem handles wireless communications. It is understood that the modem may also be implemented as a separate chip, rather than integrated into the processor 41.

[0079] Among them, the memory 45 may include a random access memory (RAM) or a read-only memory (Read-Only Memory). Optionally, the memory 45 includes a non-transitory computer-readable storage medium. The memory 45 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 45 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 45 may also be optionally at least one storage device located away from the aforementioned processor 41. As Figure 4 As shown, the memory 45 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an application program for an intelligent processing method for document circulation data on an intranet mobile terminal.

[0080] exist Figure 4 In the electronic device shown, the user interface 43 is mainly used to provide an input interface for the user and obtain data input by the user; and the processor 41 can be used to call an application program stored in the memory 45 for an intelligent processing method for intranet mobile document circulation data. When executed by one or more processors, the electronic device executes one or more methods as in the above-mentioned embodiments.

[0081] It should be noted that for the aforementioned method embodiments, for simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for this application.

[0082] The present application also provides a computer-readable storage medium storing instructions, which, when executed by one or more processors, enable an electronic device to execute one or more of the methods described in the above embodiments.

[0083] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0084] In the several embodiments provided in this application, it should be understood that the disclosed devices can be implemented in other ways. For example, the device embodiments described above are merely schematic, such as the division of units, which is only a logical function division. 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. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some service interface, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0085] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0086] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0087] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the method of this application. The aforementioned memory includes various media that can store program code, such as USB flash drives, mobile hard drives, magnetic disks, or optical disks.

[0088] The above is only an exemplary embodiment of the present disclosure and cannot be used to limit the scope of the present disclosure. That is, any equivalent changes and modifications made according to the teachings of the present disclosure are still within the scope of the present disclosure. After considering the disclosure of the specification and practice, those skilled in the art will easily think of other embodiments of the present disclosure. This application is intended to cover any variation, use or adaptive change of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary technical means in the art that are not recorded in the present disclosure. The description and examples are to be regarded as exemplary only, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. An intelligent processing method for document circulation data on an intranet mobile terminal, characterized in that: The method comprises: Obtain documents awaiting approval from the First Intranet mobile terminal; encrypting the official document to be approved to obtain an encrypted official document; Determining approval scenario data for a second intranet mobile terminal based on the federated behavior prediction model, where the second intranet mobile terminal is a direct document transfer node for the first intranet mobile terminal; If it is determined that the approval scenario data of the second intranet mobile terminal does not meet the preset conditions, a third intranet mobile terminal is determined, and the third intranet mobile terminal is an available document flow node for the first intranet mobile terminal; The encrypted document is sent to the third intranet mobile terminal for decryption and approval by the third intranet mobile terminal.

2. The method for intelligently processing document circulation data on an intranet mobile terminal according to claim 1 is characterized in that: The obtaining of the pending official document from the first intranet mobile terminal specifically includes: Reading the document entry with the pending approval tag from the local database or cache of the first intranet mobile terminal; According to the unique identifier in the document entry, query the local index service to obtain metadata, the metadata including the document title, source department, and creation time; The document to be approved is determined based on the document title, source department and creation time.

3. The method for intelligently processing document circulation data on an intranet mobile terminal according to claim 1 is characterized in that: The step of encrypting the document to be approved to obtain an encrypted document specifically includes: Determine a symmetric encryption key based on the official document to be approved; Dividing the official document to be approved into multiple data blocks; The binary data is read according to the data blocks, and each of the read binary data is encrypted block by block using the symmetric encryption key, and a random initialization vector is added to obtain the encrypted document.

4. The method for intelligently processing document circulation data on an intranet mobile terminal according to claim 1, characterized in that: The step of determining the approval scenario data of the second intranet mobile terminal according to the federated behavior prediction model, wherein the second intranet mobile terminal is a direct document transfer node of the first intranet mobile terminal, specifically includes: Obtaining approval features of the second intranet mobile terminal, the approval features including current time, geographic location, and current activity of the user; Inputting the approval features into the federal behavior prediction model to obtain the approval response probability and the average approval time; The approval scenario data is determined based on the approval response probability and the average approval time.

5. The method for intelligently processing document circulation data on an intranet mobile terminal according to claim 1 is characterized in that: If it is determined that the approval scenario data of the second intranet mobile terminal does not meet the preset condition, determining a third intranet mobile terminal specifically includes: Determine whether the approval scenario data is consistent with preset scenarios, where the preset scenarios include working hours, at the company, and the user's idle time period; If it is determined that any scenario in the approval scenario data is inconsistent with the preset scenario, obtaining a list of all available terminals in the same approval link as the first intranet mobile terminal; According to the available terminal list, the third intranet mobile terminal is obtained by traversing and screening.

6. The method for intelligently processing document circulation data on an intranet mobile terminal according to claim 4 is characterized in that: Inputting the approval features into the federated behavior prediction model to obtain the approval response probability and the average approval time specifically includes: By using the federated behavior prediction model, the approval features are compared according to preset dimensions to obtain comparison results, wherein the preset dimensions include user historical behavior features, context environment features, user real-time status features, and node collaboration features; The federal behavior prediction model is used to perform forward calculation and result decoding on the approval features to obtain the approval response probability and the average approval time.

7. The method for intelligently processing document circulation data on an intranet mobile terminal according to claim 1, characterized in that: The method further comprises: Get the custom approval process sent by the user's device; Determine the customized intranet mobile terminal according to the customized approval process; The document to be approved is processed through document circulation according to the customized intranet mobile terminal.

8. An intelligent processing system for document circulation data on an intranet mobile terminal, characterized in that: The system comprises an acquisition module (31) and a processing module (32), wherein: The acquisition module (31) is used to acquire the official documents to be approved on the first intranet mobile terminal; The processing module (32) is used to encrypt the official document to be approved to obtain an encrypted official document; The processing module (32) is further configured to determine the approval scenario data of the second intranet mobile terminal based on the federated behavior prediction model, wherein the second intranet mobile terminal is a direct document transfer node of the first intranet mobile terminal; The processing module (32) is further configured to determine a third intranet mobile terminal if it is determined that the approval scenario data of the second intranet mobile terminal does not meet a preset condition, wherein the third intranet mobile terminal is an available document transfer node of the first intranet mobile terminal; The processing module (32) is further configured to send the encrypted official document to the third intranet mobile terminal for decryption and approval by the third intranet mobile terminal.

9. An electronic device, characterized in that: The electronic device comprises a processor (41), a memory (45), a user interface (43) and a network interface (44), wherein the memory (45) is used to store instructions, the user interface (43) and the network interface (44) are both used to communicate with other devices, and the processor (41) is used to execute the instructions stored in the memory (45) so that the electronic device executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, and when the instructions are executed, the method according to any one of claims 1 to 7 is performed.

Images