Micro-application-based communication fault repair management and control method, mobile terminal and cloud

Abstract

The application discloses a kind of communication fault rush repair management and control method, mobile terminal and cloud based on micro application, it is related to communication network operation and management technical field.The method is applied to mobile terminal, comprising: obtaining data, initializing local process state control module and incremental count information;In the condition of no network or weak network, control local process state control module to execute process first flow to the current flow conversion node, update incremental count information, generate local operation record;Acquire the rush repair field data corresponding to the current flow conversion node, generate and compress data packet;Calculate tamper-proof check code, and encapsulate as local supplement transmission data packet, write in the pending synchronization queue of mobile terminal;When monitoring network recovery, local supplement transmission data packet is pushed out according to the order in pending synchronization queue and receives confirmation receipt.The application reduces the process out-of-control risk caused by the disconnection between local operation and cloud state, reduces the transmission burden of on-site evidence uploading in weak network environment.

Description

Technical Field

[0001] This invention relates to the field of communication network operation and maintenance and mobile information management technology, specifically to a communication fault repair and control method based on micro-applications, a mobile terminal, and a cloud platform. Background Technology

[0002] Digital management and control of communication fault repair processes is a common method in the field of communication operation and maintenance for on-site work order transfer, evidence collection and status synchronization. It is usually achieved by accessing the cloud business system through mobile terminals, realizing repair order processing, node transfer, on-site signature, photo upload and closed-loop management of the process. It can also uniformly record the business status and on-site data during the repair process, and has the characteristics of clear process and centralized management.

[0003] As communication network coverage expands and on-site repair environments become more complex, communication fault repair is gradually expanding from areas where network conditions meet preset communication bandwidth thresholds to scenarios involving base station power outages, link interruptions, or weak / no network coverage. However, existing methods for real-time digital processing of on-site repair tasks are still limited by network connectivity, leading to delays in process flow, difficulty in uploading on-site evidence, inconsistencies between local operations and cloud status, difficulty in verifying retransmitted data, and limitations in task closure. Summary of the Invention

[0004] This invention addresses the current problems of untimely workflow transitions in on-site emergency repair tasks, difficulty in uploading on-site evidence, inconsistencies between local operations and cloud status, difficulty in verifying retransmitted data, and limited task closure. It provides a communication fault repair management method based on micro-applications, connecting mobile terminals and the cloud. This method enables timely workflow transitions, reduces the risk of workflow loss of control caused by the disconnect between local operations and cloud status, and lowers the transmission burden of uploading on-site evidence in weak network environments.

[0005] Firstly, a communication fault repair and management method based on micro-applications is provided, the method being applied to a mobile terminal, including:

[0006] Acquire and locally cache basic data of emergency repair orders, offline temporary vouchers, preset permission policies and initial vector clock information, and initialize the local process status control module and incremental counting information of the mobile terminal. The initial vector clock information is used to provide a unified counting starting point for local operations, and the incremental counting information includes cloud operation counts and mobile terminal operation counts.

[0007] In the absence of network or weak network conditions, offline authentication is performed based on the offline temporary certificate. If the authentication is successful, the local process status control module is controlled to execute the process flow to the current flow node within the pre-authorized node set limited by the preset permission policy based on the emergency repair order basic data and the initial vector clock information, update the incremental count information, and generate local operation records.

[0008] Acquire the emergency repair site data corresponding to the current flow node, perform classification and compression on different types of data in the emergency repair site data, and generate a compressed data package bound to the local operation record;

[0009] Based on the local operation record, the updated incremental count information, and the compressed data packet, calculate the anti-tampering verification code, and encapsulate the local operation record, the updated incremental count information, the compressed data packet, and the anti-tampering verification code into a local retransmission data packet, and write it into the synchronization queue of the mobile terminal;

[0010] When network recovery is detected, the local retransmission data packets are pushed out in the order of the synchronization queue and an acknowledgment is received to update the local process status control module.

[0011] In some embodiments, upon successful authentication, the local process status control module, based on the emergency repair order data and the initial vector clock information, executes the process pre-flow to the current flow node within the pre-authorized node set defined by the preset permission policy, updates the incremental count information, and generates a local operation record, including:

[0012] Record the operation type and timestamp when the local process status control module performs node-first flow;

[0013] The mobile terminal operation count in the incremental count information is incremented to obtain the updated incremental count information;

[0014] The local operation record is generated by combining the operation type, the identifier of the current flow node, the updated incremental count information, and the timestamp.

[0015] In some embodiments, the process involves acquiring emergency repair site data corresponding to the current transfer node, performing classification and compression on different types of data in the emergency repair site data, and generating a compressed data package bound to the local operation record, including:

[0016] According to the data collection rules corresponding to the current flow node, emergency repair site data is collected, including: pressure sensing signature data and on-site recorded photos;

[0017] Obtain the discrete sampling point sequence of the pressure-sensing signature data, extract the trajectory inflection points, and convert them into curve description instructions;

[0018] The on-site photographs are divided into target repair areas, and image data packets are generated by using different compression strategies for the foreground and background areas.

[0019] The curve description instruction is fused with the image data packet to generate the compressed data packet.

[0020] In some embodiments, obtaining a discrete sampling point sequence of the pressure-sensing signature data, extracting trajectory inflection points, and converting them into curve description instructions includes:

[0021] Feature values ​​are extracted based on the discrete curvature and pressure gradient of each sampling point in the discrete sampling point sequence;

[0022] Based on the historical signature trajectory feature values ​​stored locally in advance, the threshold for determining the inflection point of handwriting is determined.

[0023] Sampling points whose feature values ​​are not less than the handwriting inflection point determination threshold are marked as trajectory inflection points and converted into the curve description instructions according to preset rules.

[0024] In some embodiments, the on-site photographs are divided into repair target areas, and image data packets are generated by applying different compression strategies to the divided foreground and background areas, including:

[0025] The pre-set on-site image analysis program is used to extract the target area for emergency repair from the on-site photos and output the zoning marking information;

[0026] Based on the partitioning information, the on-site recorded photos are divided into the foreground region and the background region;

[0027] Lossless coding is performed on the foreground region to generate foreground data, and lossy coding is performed on the background region to generate background data. The quality factor of the lossy coding is dynamically determined based on the current physical channel bandwidth, a preset bandwidth threshold, a conventional quality factor, and a preset adjustment coefficient, and is truncated to a preset highest quality boundary.

[0028] The foreground data and the background data are fused to generate the image data packet.

[0029] In some embodiments, receiving a returned confirmation receipt to update the local process status control module includes:

[0030] Parse the confirmation receipt to obtain the latest cloud confirmation status;

[0031] Remove the local retransmission data packet corresponding to the confirmation receipt from the synchronization queue;

[0032] Based on the latest cloud confirmation status, update the local process status control module to the corresponding status;

[0033] If the confirmation receipt is not received within the preset time, the local retransmission data packet is retained and retransmitted according to the breakpoint position in the synchronization queue.

[0034] In some embodiments, the method further includes: receiving a conflict exception receipt, wherein the conflict exception receipt includes a repair order identifier, the current cloud confirmation status and a conflict result code, and retaining the corresponding local retransmission data packet in a queue.

[0035] Secondly, a communication fault repair and management method based on micro-applications is provided, the method being applied in the cloud, including:

[0036] Receive local retransmission data packets, wherein the local retransmission data packets include: local operation records, incremental count information, compressed data packets, and anti-tampering verification codes;

[0037] Based on the local operation record, incremental count information, and compressed data packet, a new anti-tampering verification code is calculated, and the new anti-tampering verification code is compared with the anti-tampering verification code in the local retransmission data packet to obtain the comparison result.

[0038] If the comparison result shows that the new anti-tampering verification code is consistent with the anti-tampering verification code in the local retransmission data packet, the incremental count information in the local retransmission data packet is extracted and compared with the vector clock currently saved in the cloud. The currently saved vector clock is the latest count status of the mobile terminal that has been confirmed in the cloud microservice business table of the emergency repair order.

[0039] If the mobile operation count in the incremental count information is greater than the mobile operation count in the vector clock currently stored in the cloud, and the cloud operation count in the incremental count information is not less than the cloud operation count in the vector clock currently stored in the cloud, the process is accepted and processed first; otherwise, the process is rejected and a conflict exception receipt is generated.

[0040] After the acceptance process has been completed, the corresponding business table of the cloud microservice and the vector clock currently stored in the cloud are updated, the compressed data packet is archived, and a confirmation receipt is returned.

[0041] Thirdly, a mobile terminal is provided, the mobile terminal including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method described above.

[0042] Fourthly, a cloud computing platform is provided, which includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the methods described above.

[0043] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0044] 1. By pre-acquiring and locally caching basic data of emergency repair orders, offline temporary credentials, pre-set permission policies, and initial vector clock information including cloud operation counts and mobile operation counts on the mobile device, a local process advancement foundation for weak network or no network conditions is established. This enables emergency repair personnel to complete the process flow within the pre-authorized node set even in scenarios such as base station power outages and link interruptions, thereby solving the problem that the existing method cannot flow the process nodes in a timely manner due to network connectivity limitations.

[0045] 2. By combining offline authentication, local process status control module and incremental counting information update mechanism, operation type, node identifier, timestamp and counting status can be uniformly recorded in offline state, forming local operation record that can be used for subsequent timing judgment and status merging, thereby reducing the risk of process loss of control caused by the disconnect between local operation and cloud status;

[0046] 3. By extracting trajectory inflection points from pressure-sensing signature data and converting them into curve description instructions, and by dividing the target area for emergency repairs into on-site photos and applying different compression strategies to the foreground and background areas, key evidence such as signature trajectories, pen stroke features, and faulty equipment are preserved. At the same time, the lossy coding quality factor of the background area is dynamically adjusted according to the physical channel bandwidth, thereby reducing the transmission burden of uploading on-site evidence in weak network environments and solving the problem of difficulty in uploading on-site evidence in a timely manner. Attached Figure Description

[0047] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention 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.

[0048] Figure 1 This is a flowchart of a digital management and control method for communication fault repair process based on micro-applications according to an embodiment of the present invention.

[0049] Figure 2 This is a flowchart of a digital management and control method for communication fault repair process based on micro-applications according to an embodiment of the present invention.

[0050] Figure 3 This is a schematic diagram of the structure of a mobile terminal according to an embodiment of the present invention.

[0051] Figure 4 This is a schematic diagram of a cloud structure according to an embodiment of the present invention. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0053] On the one hand, this invention provides a digital management and control method for communication fault repair process based on micro-applications, which is applied to mobile terminals. Figure 1 This is a flowchart illustrating a digital management and control method for communication fault repair processes based on micro-applications, according to an embodiment of the present invention. (Reference) Figure 1 This digital management and control method for communication fault repair process based on micro-applications is applied to mobile terminals and includes steps S110 to S150.

[0054] In S110, basic data of emergency repair order, offline temporary voucher, preset permission policy and initial vector clock information are acquired and cached locally, and the local process status control module and incremental counting information of the mobile terminal are initialized. The initial vector clock information is used to provide a unified counting starting point for local operations, and the incremental counting information includes cloud operation count and mobile terminal operation count.

[0055] This invention applies to mobile devices carried by personnel repairing communication faults. The mobile device can be an industrial handheld terminal, a tablet terminal, or a smartphone with local storage and wireless communication capabilities. The mobile device runs micro-applications internally, while the cloud side consists of a cluster of cloud-based microservices responsible for repair work orders, access control, and workflow management.

[0056] The local process status control module refers to a lightweight process control unit deployed within the mobile device, used to maintain local process progress according to preset rules when the network is unstable. Incremental count information refers to count data stored in the form of a vector clock, which includes at least cloud operation counts and mobile device operation counts, used to determine the validity of the timing during subsequent synchronization.

[0057] Before a repair task begins, the cloud-based microservice sends basic repair order data to the mobile device, provided the network is available. This basic data includes at least a unique identifier for the repair order, a description of the fault, the current process node identifier, and the data collection requirements associated with that node. After receiving this data, the mobile device's processor calls the local database interface to write the basic data to its local cache.

[0058] Along with this basic data, offline temporary credentials, pre-defined permission policies, and initial vector clock information are also issued. The offline temporary credentials are used to prove the identity and validity of the current operator during the offline period, the pre-defined permission policies are used to limit which nodes different roles can advance to in the offline state, and the initial vector clock information is used to provide a unified counting starting point for each subsequent local operation.

[0059] In S120, under no-network or weak-network conditions, offline authentication is performed based on offline temporary credentials. If the authentication is successful, the local process status control module is controlled to execute the process flow to the current flow node within the pre-authorized node set limited by the preset permission policy based on the emergency repair order basic data and the initial vector clock information, update the incremental count information, and generate a local operation record.

[0060] When a mobile device detects that the current physical channel is in a weak network or no network condition, the micro-application no longer initiates a real-time authentication request to the cloud microservice. Instead, the mobile device's local authentication program verifies the offline temporary credentials and preset permission policies. Offline authentication refers to the process where the mobile device completes token validity checks, role matching checks, and node permission scope checks locally.

[0061] When the preconditions are met, namely, the offline temporary certificate is still available and the current user role falls within the set of roles allowed by the pre-defined permission policy, the local process status control module will allow the current emergency repair task to be transferred from the existing node to the next node in the pre-authorized node set; if the conditions are not met, the original node will remain unchanged and no data to be synchronized will be generated.

[0062] During the local process status control module's execution node transition, the mobile device records the operation type and timestamp of this action. The operation type includes business actions such as status transition or data temporary storage, and the timestamp is provided by the mobile device's system clock within the current collection period.

[0063] In some embodiments, the steps of controlling the local process status control module to execute the process first flow to the current flow node, update the incremental count information, and generate a local operation record within the pre-authorized node set limited by the preset permission policy include: S121 to S123.

[0064] In S121, the operation type and timestamp are recorded when the local process status control module performs node-first flow.

[0065] In S122, the mobile terminal operation count in the incremental count information is incremented to obtain the updated incremental count information.

[0066] In S123, the operation type, the identifier of the current flow node, the incremental count information, and the timestamp are combined to generate a local operation record.

[0067] In S130, the emergency repair site data corresponding to the current flow node is obtained, and different types of data in the emergency repair site data are classified and compressed to generate a compressed data packet bound to the local operation record.

[0068] After generating a local operation log, the mobile device collects on-site repair data according to the data collection rules corresponding to the current workflow node. This on-site repair data consists of objective data generated by on-site equipment and operations, and includes at least: electronic signatures, on-site photos, or other evidence data corresponding to the repair node. Specifically, on-site repair data may include pressure-sensor signature data and on-site recorded photos.

[0069] The mobile device performs classification and compression on the collected data, generating compressed data packages that are individually bound to local operation records. Each node advancement corresponds to one instance of evidence retention; when the cloud microservice subsequently accepts the state of a node, it needs to simultaneously accept the data corresponding to that node.

[0070] In some embodiments, the step of performing classified compression on emergency repair site data to generate a compressed data packet bound to the local operation record includes: S131 to S133.

[0071] In S131, the discrete sampling point sequence of the pressure sensing signature data is obtained, the trajectory inflection points are extracted and converted into curve description instructions.

[0072] Specifically, the steps of acquiring a discrete sampling point sequence of pressure-sensitive signature data, extracting trajectory inflection points, and converting them into curve description instructions include: extracting feature values ​​based on the discrete curvature and pressure gradient of each sampling point in the discrete sampling point sequence; determining a handwriting inflection point determination threshold based on pre-stored historical signature trajectory feature values; marking sampling points with feature values ​​not less than the handwriting inflection point determination threshold as trajectory inflection points, and converting them into curve description instructions according to preset rules. The preset rules are used to transform scattered coordinate points and physical features (such as curvature and pressure) into compact data (e.g., direction code sequences, virtual stroke features, or parameterized equations) that can be efficiently stored, transmitted, and rendered by a computer.

[0073] In S132, the on-site recorded photos are divided into target areas for emergency repair, and different compression strategies are used to generate image data packets for the divided foreground and background areas.

[0074] Specifically, the steps for dividing on-site recorded photos into repair target areas and generating image data packets using different compression strategies for the divided foreground and background areas include: extracting the repair target areas from the on-site recorded photos using a pre-set on-site image analysis program and outputting partition marking information; dividing the on-site recorded photos into foreground and background areas based on the partition marking information; performing lossless encoding on the foreground area to generate foreground data and lossy encoding on the background area to generate background data, wherein the quality factor of the lossy encoding is dynamically adjusted according to the currently detected physical channel bandwidth; and fusing the foreground and background data to generate image data packets. The quality factor of the lossy encoding is dynamically determined based on the current physical channel bandwidth, a preset bandwidth threshold, a conventional quality factor, and a preset adjustment coefficient, and is truncated to a preset highest quality boundary.

[0075] In S133, the curve description instruction is fused with the image data packet to generate a compressed data packet. For example, the original image data packet can be decomposed into "key features (curve instructions)" and "background / residual information"; the generated curve fitting coefficients are entropy encoded to convert them into a bitstream with an extremely low bit rate; the encoded curve instruction bitstream is fused with necessary auxiliary information and residual image data, and encapsulated into a unified compressed data frame for transmission.

[0076] In S140, the anti-tampering verification code is calculated based on the local operation record, the updated incremental count information, and the compressed data packet. The local operation record, the updated incremental count information, the compressed data packet, and the anti-tampering verification code are then encapsulated into a local retransmission data packet and written into the synchronization queue of the mobile terminal.

[0077] After generating the compressed data packet, the mobile device uses the local operation record, incremental count information, and the compressed data packet as input to calculate a tamper-proof checksum using a relevant algorithm (e.g., a cryptographic hash algorithm). The tamper-proof checksum demonstrates that no splitting, replacement, or rewriting of content has occurred between the local operation, the increment count, and the on-site data.

[0078] Specifically, the steps for calculating the anti-tampering check code based on local operation records, incremental count information, and compressed data packets include: S141 to S143.

[0079] In S141, the unique identifier of the emergency repair order is extracted from the basic data of the emergency repair order in the local cache.

[0080] In S142, the timestamp, incremental count information, compressed data packet, and unique identifier of the emergency repair order in the local operation record are fused together.

[0081] In S143, a hash calculation is performed on the merged data to generate a tamper-proof check code, and the tamper-proof check code is embedded in the header of the compressed data packet.

[0082] The mobile device encapsulates local operation records, incremental count information, compressed data packets, and tamper-proof verification codes into a local retransmission data packet, and writes it to the synchronization queue in the order of its generation. This synchronization queue is stored in the mobile device's local database or file queue, and its order is consistent with the order of actual local business actions.

[0083] In S150, when network recovery is detected, local retransmission data packets are pushed out according to the order in the synchronization queue, and an acknowledgment is received to update the local process status control module. The cloud microservice performs status merging and data archiving based on tamper-proof checksums and incremental count information, and receives the returned acknowledgment.

[0084] During subsequent operation, the mobile device continuously monitors the physical channel status through a network monitoring component. Physical channel recovery here refers to the mobile device detecting that the current network has reached a point where a stable data connection can be established. Upon detecting this condition, the background synchronization program retrieves the local retransmission data packets one by one from the synchronization queue and pushes them to the cloud microservice.

[0085] State merging refers to the process by which a cloud-based microservice, upon receiving supplementary data from a mobile device, determines whether the local process can be merged into the current business state of the cloud-based microservice. Data archiving refers to saving the signature and photo corresponding to the current business state to the cloud-based business storage after state merging is successful. Confirmation receipt refers to the processing result data returned by the cloud-based microservice to the mobile device, which includes at least the repair order identifier, the latest confirmation status, and the processing result corresponding to the current local supplementary data packet.

[0086] The cloud-based microservice verifies, merges, and archives each locally transmitted data packet before returning a confirmation receipt. Upon receiving this confirmation receipt, the mobile device updates its local process status control module to ensure consistency between the locally stored process status and the cloud-confirmed status. This approach allows the mobile device to complete limited process progression and evidence collection even during emergency repairs due to base station power outages or link interruptions. Once the network is restored, data can be synchronized uniformly, preventing process blockages and data loss.

[0087] If, upon arrival at the fault location, the on-site network is insufficient for real-time data upload, the mobile device first uses cached repair order data and offline temporary credentials to complete local authentication. Once authentication is successful, the local process status control module allows the personnel to progress from the current repair node to the status entry node, simultaneously generating a local operation record with node identifier, timestamp, and vector count. Afterward, a signature and photo are collected, and these data are packaged with the operation record. Once the on-site connection is restored, the mobile device sequentially sends the local retransmission data packet. The cloud microservice verifies the data and returns a confirmation result, updating the local process status accordingly. This ensures that on-site operations are not interrupted by network outages.

[0088] Specifically, the steps of receiving the returned confirmation receipt to update the local process status control module include: S151 to S154.

[0089] In S151, the confirmation receipt is parsed to obtain the latest cloud confirmation status.

[0090] In S152, the local retransmission data packet corresponding to the acknowledgment receipt is deleted from the synchronization queue.

[0091] In S153, the local process status control module is updated to the corresponding status based on the latest cloud confirmation status.

[0092] In S154, if no acknowledgment is received within a preset time, the local retransmission data packet is retained and retransmitted according to the breakpoint position in the synchronization queue.

[0093] The following description illustrates the process of data collection, compression, and verification at the emergency repair site. Pressure-sensing signature data refers to the coordinate, pressure, and sampling time data continuously collected during the signing process using a mobile touchscreen or electromagnetic handwriting device. On-site recorded photos refer to on-site image files captured by a mobile camera. Categorized compression refers to using different data reduction methods for the signature trajectory and photo content, preserving the original features of the parts requiring fidelity while reducing the size of parts that can have reduced accuracy according to current channel conditions.

[0094] Once the local process status control module completes the initial flow of a certain node, the mobile terminal initiates the signature acquisition component and image acquisition component according to the data acquisition requirements of that node. The signature acquisition component continuously reads the discrete sampling point sequence output by the touch layer. Each sampling point includes at least the horizontal coordinate, vertical coordinate, pressure value, and sampling time. The image acquisition component calls the mobile terminal's camera to acquire on-site photos, and the obtained photo data is in the form of a pixel matrix. Both types of data originate from the actual operations at the emergency repair site, and therefore belong to objective evidence data directly corresponding to the business process.

[0095] For pressure-sensitive signature data, the mobile device obtains a discrete sampling point sequence, which contains multiple sampling points. Each sampling point is represented by the spatial coordinates of the pen tip on the touch surface. and , indicating the corresponding pen pressure value and the sampling time Composition, in which, It is a positive integer, representing the sampling point number in the discrete sampling point sequence.

[0096] The mobile processor performs differential calculations on adjacent sampling points, first calculating the discrete curvature of each sampling point, and then calculating the pressure gradient. Specifically, the process of calculating the discrete curvature and pressure gradient of each sampling point involves using the spatial coordinates of three consecutive adjacent sampling points and calculating the reciprocal of the radius of the circumcircle formed by these three points to obtain the discrete curvature of that sampling point. Simultaneously, the pressure gradient of the corresponding sampling point is obtained by calculating the ratio of the difference in pressure values ​​between two adjacent sampling points to the time difference. The discrete curvature reflects the degree of handwriting transitions, while the pressure gradient reflects the changes in pressure during the pause and lift of the pen.

[0097] In signature processing, key points where discrete curvature and pressure gradient exceed preset thresholds are crucial for handwriting recognition. Uploading all original sampling points would exceed the preset bandwidth capacity, potentially leading to duplicate transmissions in weak network conditions. After obtaining the discrete curvature and pressure gradient of each sampling point, the mobile device performs extreme value transformation normalization on these two sets of data to obtain normalized curvature and pressure gradient values. To avoid zero data ranges during extreme value transformation normalization (e.g., a constant pen pressure causing the maximum value to equal the minimum value, resulting in a zero denominator and program crash), the system adds a preset constant bias term greater than zero to the denominator of the normalization formula. The extreme value transformation normalization formula is as follows:

[0098] ; (1)

[0099] in, This is the original discrete curvature or pressure gradient data. and These are the minimum and maximum values ​​of the corresponding data set, respectively. The normalized curvature value or pressure gradient value. This is a constant bias term with a value of 10^-6 and its dimensions are the same as... The dimensions are kept consistent.

[0100] Next, the discrete curvature and pressure gradient data are multiplied and summed according to preset weight parameters to form the feature value of each sampling point. Preferably, the curvature weight is greater than the pressure gradient weight, so as to preferentially retain the pen stroke turning feature, while the pressure change is used as an auxiliary feature in the judgment.

[0101] The mobile device reads the feature value set of historical signature trajectories from the local historical signature cache, calculates the statistical average of the set, and then multiplies the statistical average by a preset floating coefficient to obtain the handwriting inflection point determination threshold. For example, the calculation of feature values ​​and the inflection point determination process can be deduced using a quantitative example.

[0102] Assuming the original discrete curvature of a sampling point, after extreme value normalization, is 0.8, and the original pressure gradient, after extreme value normalization, is 0.5, with a preset curvature weight parameter of 0.6 and a pressure gradient weight parameter of 0.4, then the calculated characteristic value of this sampling point is... .

[0103] If the statistical average of the feature value set of historical signature trajectories read from the local historical signature cache is 0.5, and the preset fluctuation coefficient is 1.2, then the handwriting inflection point determination threshold is... Since the feature value of the current sampling point is 0.68, which is not less than the judgment threshold of 0.6, it is marked as a trajectory inflection point.

[0104] The judgment threshold is dynamically adapted to the distribution of existing signature features in the local system, thereby avoiding the extraction of too many or too few key points due to differences in sampling accuracy of different mobile devices or differences in writing pressure of different operators. When the feature value of a certain sampling point is not less than the handwriting inflection point judgment threshold, the mobile device marks the sampling point as a trajectory inflection point. After marking, the extracted trajectory inflection point sequence is converted into curve description instructions according to the preset curve generation rules. The preset curve generation rules specifically include: using the extracted adjacent trajectory inflection points as control points, using Bézier curve or B-spline curve algorithms to generate smooth connection curves, and extracting the corresponding control point coordinates and curve order as curve description instructions.

[0105] Curve description instructions can be a vectorized curve instruction set used to reconstruct the signature trajectory. Essentially, it uses simplified control points to represent the complete signature shape, thereby compressing the original high-density sampling point data into smaller vector data. This preserves both the signature trajectory and pen stroke characteristics while reducing transmission volume.

[0106] For on-site photos, the mobile app uses a pre-built on-site image analysis program to divide the photos into target repair areas. These target repair areas refer to image regions directly related to the repair work, such as the faulty equipment itself, broken sections, nameplate areas, or other parts that need to be clearly seen during subsequent review.

[0107] The image analysis program outputs partitioning information based on image semantic segmentation. This semantic segmentation employs a deep learning-based fully convolutional neural network, a U-shaped network model, or a mask-based region convolutional neural network model to classify and identify regions point-by-point in the recorded photos. The partitioning information can be represented as mask data corresponding to the pixel matrix of the original photo. Based on this partitioning information, the mobile device divides the recorded photos into foreground and background regions. The foreground region carries key visual content related to the emergency repair, while the background region mainly contains environmental information.

[0108] After region segmentation, the mobile device performs lossless encoding on the foreground region to generate foreground data, and lossy encoding on the background region to generate background data. Foreground regions must clearly identify details during review, and lossy compression is avoided. Background regions only serve as supplementary environmental descriptions, and file size can be reduced while maintaining recognizability. For lossy encoding of the background region, the mobile device does not use a fixed quality factor, but dynamically adjusts it based on the currently detected physical channel bandwidth. The mobile device's network monitoring component first identifies the current communication network standard, and then reads the preset bandwidth threshold, minimum quality factor, and regular quality factor matching that network standard from the local parameter table.

[0109] Calculate the ratio of the current physical channel bandwidth to the bandwidth threshold, and multiply this ratio by a preset adjustment coefficient to obtain the bandwidth attenuation term; then multiply the regular quality factor by the bandwidth attenuation term to obtain the dynamic quality factor; take the maximum value between the lowest quality factor and the dynamic quality factor as the quality factor for lossy coding of the background region.

[0110] After adopting the above calculation method, when the current physical channel bandwidth is lower than the first preset bandwidth threshold, the dynamic quality factor decreases, the background area compression degree increases, and the generated background data volume is smaller; when the current physical channel bandwidth is higher than the second preset bandwidth threshold, the dynamic quality factor increases, and more image details are retained in the background area.

[0111] When the actual system is deployed, in order to avoid the physical channel bandwidth exceeding the preset normal range and causing the calculated quality factor to overflow the upper limit of the standard image coding specification, the system will apply the default upper limit truncation strategy when executing this logic. That is, after finally determining the quality factor of lossy coding, it will determine whether it exceeds the system's preset highest quality boundary, such as 100 in the Joint Image Experts Group coding standard. If it exceeds, it will be forcibly truncated.

[0112] In one specific embodiment, the standard quality factor is set to 80, the minimum quality factor to 30, the bandwidth threshold to 2 Mbps, and the adjustment coefficient to 0.8. When the probe bandwidth is 1 Mbps, the ratio is 0.5, the bandwidth attenuation term is 0.4, and the dynamic quality factor is... Taking the maximum of 32 and 30, the final quality factor is 32. If the probe bandwidth suddenly increases to 4Mbps, the ratio is 2, the bandwidth attenuation term is 1.6, and the dynamic quality factor is... If the value exceeds 100, the applied quality factor of 100 will be truncated.

[0113] This clarifies the specific execution logic of dynamic encoding mapping, ensuring successful data transmission in weak network environments while constraining parameter boundaries when network bandwidth exceeds a second preset bandwidth threshold. Since lossless encoding is consistently used in the foreground region, even high compression ratios in the background region do not affect the viewing of critical repair evidence. The mobile device fuses the foreground and background data to generate an image data packet.

[0114] After signature processing and image processing are completed, the mobile device merges the curve description command with the image data packet to form a compressed data packet bound to the local operation record. This fusion refers to writing the signature payload, image payload, and associated identifier corresponding to the local operation record into a unified data packet structure according to predetermined fields. This allows the cloud microservice to clearly identify which set of signature and photo data corresponds to a particular node transfer, rather than treating the signature file and photo file as independent, scattered files.

[0115] After generating the compressed data packet, the mobile device needs to calculate the tamper-proof verification code. To do this, the mobile device's processor first extracts the unique identifier of the emergency repair order from the locally cached basic data. It then merges the timestamp, incremental count information, compressed data packet, and the unique identifier of the emergency repair order from the local operation record. This merging is done by concatenating the fields in a fixed order to form a data string to be verified, ensuring that the same business content receives the same hash input in the same order. Next, a hash calculation is performed on the merged data to generate the tamper-proof verification code. Specifically, the hash calculation uses the SHA-256 cryptographic hash algorithm to ensure that the generated tamper-proof verification code has a fixed-length output and strong collision resistance. This tamper-proof verification code is then embedded in the header of the compressed data packet. With this setup, if any item in the local operation record, vector count, signature payload, or image payload changes before or after synchronization, the verification result recalculated by the cloud microservice will be different, thus detecting data corruption or unauthorized modification.

[0116] In a field application, after repair personnel complete the repair, they need to sign for confirmation and take photos of the fault location. The mobile device first collects the signature trajectory and extracts key inflection points, converting the entire trajectory into a fixed-length, compressed curve description command. The taken photos are divided into the faulty equipment area and the environmental area; the former retains clear details, while the latter is compressed according to the current network conditions. Combining local operation records and vector clocks, a tamper-proof verification code is generated and packaged. The resulting data packet retains the core evidence needed for post-event verification while reducing the upload burden under weak network conditions.

[0117] on the other hand, Figure 2 This is a flowchart illustrating a digital management method for communication fault repair based on micro-applications according to an embodiment of the present invention. After network recovery, the cloud microservice receives the locally transmitted data packet and completes status judgment, while the mobile terminal corrects its local status based on the receipt. The cloud microservice performs status merging and data archiving based on the tamper-proof checksum and incremental count information. (Reference) Figure 2 The method includes the following steps: S210 to S240.

[0118] In S210, a local retransmission data packet is received, which includes: local operation record, incremental count information, compressed data packet, and anti-tampering verification code.

[0119] Once the physical channel is restored, the mobile device pushes local retransmission data packets according to the synchronization queue order. After the cloud microservice receives one of the local retransmission data packets, the verification program first reads the anti-tampering verification code in its packet header, and then recalculates the anti-tampering verification code in the local operation record, incremental count information, compressed data packet, and emergency repair order unique identifier in the local retransmission data packet according to the same field order as the mobile device.

[0120] If the recalculated anti-tampering check code matches the anti-tampering check code carried in the packet header, it means that the fields of the local retransmitted data packet have not changed during storage and transmission, and the next step of status judgment can be performed; if the two do not match, it means that the data packet is damaged or its content has changed, the cloud microservice will not accept the process to proceed, and can return a conflict exception receipt or retransmission prompt, so that the mobile terminal can continue to retain the data packet.

[0121] In S220, a new anti-tampering check code is calculated based on the local operation record, incremental count information, and compressed data packet, and the new anti-tampering check code is compared with the anti-tampering check code in the local retransmission data packet to obtain the comparison result.

[0122] After successful verification, the cloud microservice extracts the incremental count information from the locally transmitted data packet and compares it with the vector clock currently stored in the cloud. The vector clock currently stored in the cloud refers to the latest mobile terminal count status that has been confirmed in the cloud microservice's business table for this repair order.

[0123] In S230, if the comparison result shows that the new anti-tampering verification code is consistent with the anti-tampering verification code in the local retransmission data packet, the incremental count information in the local retransmission data packet is extracted and compared with the vector clock currently saved in the cloud. The currently saved vector clock is the latest count status of the mobile terminal that has been confirmed in the cloud microservice business table of the emergency repair order.

[0124] In S240, when the mobile operation count in the incremental count information is greater than the mobile operation count in the vector clock currently stored in the cloud, and the cloud operation count in the incremental count information is not less than the cloud operation count in the vector clock currently stored in the cloud, the process is accepted for priority flow; otherwise, the process is rejected for priority flow and a conflict exception receipt is generated.

[0125] The cloud-based microservices process data according to the following logic: If the mobile operation count in the locally retransmitted data packet is greater than the mobile operation count in the currently stored vector clock in the cloud, and the cloud operation count in the locally retransmitted data packet is not less than the cloud operation count in the currently stored vector clock, then the timing is considered valid. This rule means that the retransmission represents one or more valid local operations added by the mobile device based on the known cloud microservice state, without any forking based on historically lagging cloud states. If this condition is not met, it is considered a timing conflict.

[0126] In S250, after the acceptance process has been completed, the business table corresponding to the cloud microservice and the vector clock currently stored in the cloud are updated, the compressed data packet is archived, and a confirmation receipt is returned.

[0127] When the timing is deemed valid, the cloud microservice accepts the process from the local operation record and proceeds with it. Specifically, the cloud microservice updates the process status field in the corresponding business table based on the node identifier in the local operation record, and simultaneously writes the accepted count information back to the currently stored vector clock storage area in the cloud. Afterward, the compressed data package is archived to the file storage location associated with the repair order, and the correspondence between the compressed data package and the process node is recorded in the business association table. This processing order—first confirming the status is valid, then archiving the evidence data—avoids situations where the process status has not been accepted but the evidence file has already been separately stored. After completing the above processing, the cloud microservice generates a confirmation receipt and returns it to the mobile device.

[0128] When a timing conflict is detected, the cloud microservice refuses to proceed with the process and generates a conflict exception receipt. This receipt may include a repair order identifier, the current cloud confirmation status, and a conflict result code, allowing the mobile device to know that the local retransmission data packet has not been accepted. In this case, the cloud microservice does not advance the process corresponding to the local retransmission data packet into the business table, nor does it update the mobile device's local status according to the normal confirmation method. This prevents data forks caused by concurrent operations on multiple terminals or by the mobile device continuing to advance the process with an outdated state after a long period of offline operation.

[0129] After receiving the confirmation receipt from the cloud microservice, the mobile device parses the receipt content to obtain the latest cloud confirmation status. It then searches the synchronization queue for the local retransmission data packet corresponding to that receipt and removes it from the queue. This deletion action only applies to locally retransmission data packets that have already been confirmed; other unconfirmed locally retransmission data packets remain in the queue.

[0130] If the timing conflict is caused by network jitter, meaning the cloud microservice has successfully processed a local retransmission data packet but the acknowledgment sent to the mobile device is lost, causing the mobile device to time out and re-push the local retransmission data packet to the cloud microservice, then because the vector clock currently stored in the cloud has been updated in the previous processing, the mobile device operation count carried in the retransmitted local retransmission data packet will be exactly equal to, rather than greater than, the count currently stored in the cloud. This triggers the aforementioned conflict determination rule and returns a conflict exception acknowledgment.

[0131] To resolve this distributed state synchronization anomaly, when the mobile app parses a conflict exception receipt and finds that the latest cloud confirmation status is already at or has exceeded the flow node corresponding to the local retransmission data packet, it treats this as an implicit confirmation and safely removes the local retransmission data packet from the synchronization queue. Based on the latest cloud confirmation status, the mobile app updates the local process state control module to the corresponding status, ensuring that the local display and subsequent operations are consistent with the cloud confirmation status.

[0132] If the mobile device does not receive an acknowledgment within a preset time, the currently transmitted local data packet is not deleted but instead retained in the synchronization queue. The background synchronization program determines the range of unacknowledged data packets based on the breakpoint position in the synchronization queue and then pushes the unacknowledged local data packets back to the cloud microservice. The breakpoint position here refers to the boundary between the most recently acknowledged and unacknowledged data packets in the synchronization queue. This approach avoids situations where some data packets have been sent but not yet acknowledged due to link fluctuations during network recovery, thus reducing redundant processing and state loss.

[0133] In a typical scenario, the mobile device continuously generates multiple local retransmission data packets and uploads them sequentially after network recovery. The cloud microservice verifies and checks the timing of the previous local retransmission data packet, confirms the legality of its corresponding node's progress, updates the business table, and sends back the confirmation result. Upon receiving this confirmation, the mobile device deletes the corresponding queue entry and updates its local status to the cloud confirmation status. If a subsequent local retransmission data packet conflicts due to an outdated cloud baseline counter, the cloud microservice returns a conflict exception receipt. The mobile device does not consider this entry complete but retains the data for later processing. This ensures that the mobile device and cloud microservice confirm each item in a unified order during the synchronization process after network recovery, reducing inconsistencies in status.

[0134] Through the above processing, local business records, signature evidence, and photo evidence generated by the mobile device under offline conditions can be verified item by item, their timing determined, and confirmed and written back by the cloud microservice after the network is restored. The local process status control module only updates the status based on the confirmation receipt, avoiding the assumption that the cloud microservice will necessarily accept the operation simply because it has been performed locally. This ensures that the digital management and control of the emergency repair process still has the characteristics of being verifiable, traceable, and recoverable even in weak network environments.

[0135] This invention can achieve the following technical effects: (1. By pre-acquiring and locally caching basic data of emergency repair orders, offline temporary credentials, pre-set permission policies, and initial vector clock information including cloud operation counts and mobile terminal operation counts, a local process advancement foundation for weak network or no network working conditions is established, enabling emergency repair personnel to complete the process flow in the pre-authorized node set even in scenarios such as base station power failure and link interruption, thereby solving the problem that the existing method cannot flow the process nodes in a timely manner due to network connectivity limitations;

[0136] (2. By combining offline authentication, local process status control module and incremental counting information update mechanism, operation type, node identifier, timestamp and counting status can be uniformly recorded in offline state, forming local operation record that can be used for subsequent timing judgment and status merging, thereby reducing the risk of process loss of control caused by the disconnect between local operation and cloud status;

[0137] (3. By extracting trajectory inflection points from pressure-sensing signature data and converting them into curve description instructions, dividing the target area for emergency repairs from the on-site recorded photos, and applying different compression strategies to the foreground and background areas, key evidence content such as signature trajectory, pen stroke features, and faulty equipment is preserved. At the same time, the lossy coding quality factor of the background area is dynamically adjusted according to the physical channel bandwidth, thereby reducing the transmission burden of uploading on-site evidence in weak network environments and solving the problem of difficulty in uploading on-site evidence in a timely manner.

[0138] In the case of implementing the functions of the integrated modules described above in hardware, this embodiment of the invention provides another structure for the electronic device involved in the above embodiments. Figure 3 This is a schematic diagram of the structure of a mobile terminal according to an embodiment of the present invention. Figure 4 This is a schematic diagram of a cloud structure according to an embodiment of the present invention. (Reference) Figure 3 and Figure 4 Both the mobile and cloud-based systems include: at least one processor; and at least one memory. The at least one memory is coupled to the at least one processor and stores instructions for execution by the at least one processor, which, when executed by the at least one processor, implement the methods described above.

[0139] A processor can be a set of logic blocks, modules, and circuits that implement or execute the various exemplary logic blocks, modules, and circuits described in connection with embodiments of the present invention. The processor can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in connection with embodiments of the present invention. A processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc.

[0140] The memory may be read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto.

[0141] In one implementation, the memory can exist independently of the processor. The memory can be connected to the processor via a bus and used to store instructions or program code. When the processor calls and executes the instructions or program code stored in the memory, it can implement the method provided in the embodiments of the present invention. In another implementation, the memory can also be integrated with the processor.

[0142] On the other hand, the present invention also provides a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing computer program instructions that, when executed on a computer, cause the computer to perform the method as described in any of the above embodiments.

[0143] Exemplary examples show that the aforementioned computer-readable storage media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical discs (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, sticks, or key drives, etc.). The various computer-readable storage media described in this invention may represent one or more devices and / or other machine-readable storage media for storing information. The term "machine-readable storage medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0144] This invention provides a computer program that, when run on a computer, causes the computer to perform the method of any of the above embodiments.

[0145] This invention provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the method of any of the above embodiments.

[0146] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A communication fault repair and management method based on micro-applications, characterized in that, The method is applied to mobile devices and includes: Acquire and locally cache basic data of emergency repair orders, offline temporary vouchers, preset permission policies and initial vector clock information, and initialize the local process status control module and incremental counting information of the mobile terminal. The initial vector clock information is used to provide a unified counting starting point for local operations, and the incremental counting information includes cloud operation counts and mobile terminal operation counts. In the absence of network or weak network conditions, offline authentication is performed based on the offline temporary certificate. If the authentication is successful, the local process status control module is controlled to execute the process flow to the current flow node within the pre-authorized node set limited by the preset permission policy based on the emergency repair order basic data and the initial vector clock information, update the incremental count information, and generate local operation records. Acquire the emergency repair site data corresponding to the current flow node, perform classification and compression on different types of data in the emergency repair site data, and generate a compressed data package bound to the local operation record; Based on the local operation record, the updated incremental count information, and the compressed data packet, calculate the anti-tampering verification code, and encapsulate the local operation record, the updated incremental count information, the compressed data packet, and the anti-tampering verification code into a local retransmission data packet, and write it into the synchronization queue of the mobile terminal; When network recovery is detected, the local retransmission data packets are pushed out in the order of the synchronization queue and an acknowledgment is received to update the local process status control module.

2. The method according to claim 1, characterized in that, Upon successful authentication, the local process status control module, based on the emergency repair order data and the initial vector clock information, executes the process flow to the current flow node within the pre-authorized node set defined by the preset permission policy, updates the incremental count information, and generates a local operation record, including: Record the operation type and timestamp when the local process status control module performs node-first flow; The mobile terminal operation count in the incremental count information is incremented to obtain the updated incremental count information; The local operation record is generated by combining the operation type, the identifier of the current flow node, the updated incremental count information, and the timestamp.

3. The method according to claim 1 or 2, characterized in that, Acquire the emergency repair site data corresponding to the current flow node, perform classification and compression on different types of data in the emergency repair site data, and generate a compressed data package bound to the local operation record, including: According to the data collection rules corresponding to the current flow node, emergency repair site data is collected, including: pressure sensing signature data and on-site recorded photos; Obtain the discrete sampling point sequence of the pressure-sensing signature data, extract the trajectory inflection points, and convert them into curve description instructions; The on-site photographs are divided into target repair areas, and image data packets are generated by using different compression strategies for the foreground and background areas. The curve description instruction is fused with the image data packet to generate the compressed data packet.

4. The method according to claim 3, characterized in that, Obtaining the discrete sampling point sequence of the pressure-sensing signature data, extracting trajectory inflection points, and converting them into curve description instructions includes: Feature values ​​are extracted based on the discrete curvature and pressure gradient of each sampling point in the discrete sampling point sequence; Based on the historical signature trajectory feature values ​​stored locally in advance, the threshold for determining the inflection point of handwriting is determined. Sampling points whose feature values ​​are not less than the handwriting inflection point determination threshold are marked as trajectory inflection points and converted into the curve description instructions according to preset rules.

5. The method according to claim 3, characterized in that, The on-site photographs are divided into repair target areas, and image data packets are generated by applying different compression strategies to the divided foreground and background areas, including: The pre-set on-site image analysis program is used to extract the target area for emergency repair from the on-site photos and output the zoning marking information; Based on the partitioning information, the on-site recorded photos are divided into the foreground region and the background region; Lossless coding is performed on the foreground region to generate foreground data, and lossy coding is performed on the background region to generate background data. The quality factor of the lossy coding is dynamically determined based on the current physical channel bandwidth, a preset bandwidth threshold, a conventional quality factor, and a preset adjustment coefficient, and is truncated to a preset highest quality boundary. The foreground data and the background data are fused to generate the image data packet.

6. The method according to claim 1, characterized in that, Receiving the returned confirmation receipt to update the local process status control module includes: Parse the confirmation receipt to obtain the latest cloud confirmation status; Remove the local retransmission data packet corresponding to the confirmation receipt from the synchronization queue; Based on the latest cloud confirmation status, update the local process status control module to the corresponding status; If the confirmation receipt is not received within the preset time, the local retransmission data packet is retained and retransmitted according to the breakpoint position in the synchronization queue.

7. The method according to claim 1, characterized in that, The method further includes: receiving a conflict exception receipt, wherein the conflict exception receipt includes a repair order identifier, the current cloud confirmation status and the conflict result code, and retaining the corresponding local retransmission data packet in a queue.

8. A communication fault repair and management method based on micro-applications, characterized in that, The method is applied in the cloud and includes: Receive local retransmission data packets, wherein the local retransmission data packets include: local operation records, incremental count information, compressed data packets, and anti-tampering verification codes; Based on the local operation record, incremental count information, and compressed data packet, a new anti-tampering verification code is calculated, and the new anti-tampering verification code is compared with the anti-tampering verification code in the local retransmission data packet to obtain the comparison result. If the comparison result shows that the new anti-tampering verification code is consistent with the anti-tampering verification code in the local retransmission data packet, the incremental count information in the local retransmission data packet is extracted and compared with the vector clock currently saved in the cloud. The currently saved vector clock is the latest count status of the mobile terminal that has been confirmed in the cloud microservice business table of the emergency repair order. If the mobile operation count in the incremental count information is greater than the mobile operation count in the vector clock currently stored in the cloud, and the cloud operation count in the incremental count information is not less than the cloud operation count in the vector clock currently stored in the cloud, the process is accepted and processed first; otherwise, the process is rejected and a conflict exception receipt is generated. After the acceptance process has been completed, the corresponding business table of the cloud microservice and the vector clock currently stored in the cloud are updated, the compressed data packet is archived, and a confirmation receipt is returned.

9. A mobile terminal, characterized in that, The mobile device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A cloud platform, characterized in that, The cloud includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method of claim 8.

Images