A data closed loop synchronization method, system and storage medium

Abstract

The application provides a data closed loop synchronization method, system and storage medium, and relates to the technical field of informatization in the construction industry. The method comprises the following steps: when the terminal is in a network environment, receiving and caching offline data content issued by a server; when the terminal is in a non-network or weak network environment, receiving operation input related to a work process and generating an operation log, the operation log containing work operation content and a time validity identifier of offline work operation; after the terminal network is restored, uploading the operation log and other work data to the server based on a preset rule; initiating a verification processing request to the server, so that the server verifies the operation log, and completes subsequent business processing based on the operation log that passes the verification. Through the collaborative mechanism of the terminal and the server, the application can reduce the risk of data loss, fraud and business interruption caused by unstable network, and realize stable closed loop operation of the construction site business.

Description

Technical Field

[0001] This invention relates to the field of information technology in the construction industry, and in particular to a data closed-loop synchronization method, system, and storage medium. Background Technology

[0002] Existing construction management systems typically rely on real-time network communication for data synchronization, such as reporting inspection data, material warehousing, and construction task flow. However, at construction sites, due to factors such as steel structure obstructions, underground working spaces (such as deep foundation pits and tunnels), and remote geographical locations, the site environment is often in a state of no network or weak network. How to achieve data synchronization in the absence of a network or under weak network conditions is an urgent problem to be solved.

[0003] Therefore, it is necessary to provide a data synchronization method that can intelligently predict offline needs, ensure the authenticity of offline data, and improve the data synchronization efficiency in environments without or with weak networks. Summary of the Invention

[0004] The invention includes a data closed-loop synchronization method executed by a terminal, comprising: when the terminal is in a network environment, receiving and caching offline data content sent by a server; when the terminal is in a network-free or weak network environment, receiving operation input related to the job process and generating an operation log, the operation log containing job operation content and time validity identifiers of offline job operations; when the terminal's network is restored, uploading the operation log and other job data to the server based on preset rules; initiating a verification processing request to the server, causing the server to verify the operation log, and completing subsequent business processing based on the verified operation log.

[0005] The invention includes a data closed-loop synchronization method, which is executed by a server and includes: when the terminal is in a network environment, sending offline data content; when the terminal's network is restored, receiving operation logs and other job data uploaded by the terminal based on preset rules; receiving a verification processing request initiated by the terminal, verifying the operation logs, and completing subsequent business processing based on the verified operation logs.

[0006] The invention includes a data closed-loop synchronization system, comprising: a caching module configured to receive and cache offline data content sent by a server when the terminal is in a network environment; a generation module configured to receive operation input related to the job process and generate an operation log when the terminal is in a network-free or weak network environment, the operation log including job operation content and time validity identifier; an uploading module configured to upload the operation log and other job data to the server based on preset rules after the terminal's network is restored; and a verification module configured to initiate a verification processing request to the server, enabling the server to verify the operation log and complete subsequent business processing based on the verified operation log.

[0007] The invention includes a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions from the storage medium, the computer executes a data closed-loop synchronization method.

[0008] Beneficial effects: Through the collaborative mechanism between the terminal and the server, offline data content can be prepared in advance, reliable offline operation records can be kept, and orderly synchronization can be achieved after the network is restored in environments with no network or weak network. This reduces the risk of data loss, falsification, and business interruption caused by network instability, and enables stable closed-loop operation of construction site business. Attached Figure Description

[0009] The present invention will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting, and in these embodiments, the same reference numerals denote the same structures, wherein:

[0010] Figure 1 This is a schematic diagram illustrating an application scenario of a data closed-loop synchronization system according to some embodiments of the present invention;

[0011] Figure 2 This is an exemplary block diagram of a data closed-loop synchronization system according to some embodiments of the present invention;

[0012] Figure 3 This is an exemplary flowchart of a data closed-loop synchronization method according to some embodiments of the present invention;

[0013] Figure 4 This is an exemplary flowchart illustrating the generation of time validity identifiers according to some embodiments of the present invention;

[0014] Figure 5 This is an exemplary schematic diagram illustrating the formation of a trusted operation record according to some embodiments of the present invention. Detailed Implementation

[0015] The accompanying drawings used in the description of the embodiments will be briefly introduced below. The drawings do not represent all embodiments.

[0016] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0017] Unless the context clearly indicates an exception, words such as "a," "an," "a kind," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0018] This invention uses flowcharts to illustrate the operations performed by the system according to embodiments of the invention. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0019] Figure 1 This is a schematic diagram illustrating an application scenario of a data closed-loop synchronization system according to some embodiments of the present invention.

[0020] like Figure 1 As shown, the application scenario 100 of the data closed-loop synchronization system may include a server 110, a network 120, a storage device 130, and a terminal 140.

[0021] Server 110 can be used to manage resources and process data and / or information from at least one component of the system or an external data source (e.g., a cloud data center). In some embodiments, server 110 can be a single server or a group of servers. The server group can be centralized or distributed (e.g., server 110 can be a distributed system), and can be dedicated or simultaneously provided by other devices or systems. In some embodiments, server 110 can be regional or remote. In some embodiments, server 110 can be implemented on a cloud platform or provided virtually. By way of example only, a cloud platform can include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-tiered cloud, etc., or any combination thereof.

[0022] In some embodiments, such as Figure 1 As shown, server 110 includes processor 112.

[0023] Processor 112 can process data and / or information obtained from other devices or system components. Based on this data, information, and / or processing results, the processor can execute program instructions to perform one or more functions described in this application. In some embodiments, processor 112 may include one or more sub-processing devices (e.g., a single-core processing device or a multi-core multi-chip processing device). By way of example only, processor 112 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), an application-specific instruction processor (ASIP), a graphics processing unit (GPU), a physical processor (PPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a microcontroller unit, a reduced instruction set computer (RISC), a microprocessor, or any combination thereof.

[0024] Network 120 can connect the various components of the system and / or connect the system to external resources. Network 120 enables communication between the components and with other parts outside the system, facilitating the exchange of data and / or information. In some embodiments, network 120 can be any one or more of a wired network or a wireless network. For example, network 120 may include a cable network, fiber optic network, telecommunications network, Internet, local area network (LAN), wide area network (WAN), wireless local area network (WLAN), metropolitan area network (MAN), public switched telephone network (PSTN), Bluetooth network, near field communication (NFC), device bus, device wiring, cable connection, etc., or any combination thereof.

[0025] Storage device 130 can be used to store data and / or instructions. Storage device 130 may include one or more storage components, each of which may be a separate device or part of another device. In some embodiments, storage device 130 may include random access memory (RAM), read-only memory (ROM), mass storage, removable memory, volatile read-write memory, etc., or any combination thereof. Exemplarily, mass storage may include a hard disk, optical disk, solid-state drive, etc. In some embodiments, storage device 130 may be implemented on a cloud platform.

[0026] Terminal 140 refers to a mobile computing device used to perform tasks and conduct data processing and interaction. For example, a terminal includes a smartphone, tablet computer, and a computing module embedded in a smart helmet or smart bracelet. In some embodiments, the user terminal 140 may be used by one or more users, including users directly using the service and other related users. In some embodiments, the user terminal 140 may be one or any combination of other devices with input and / or output functions, such as mobile device 140-1, tablet computer 140-2, laptop computer 140-3, and desktop computer 140-4.

[0027] Figure 2 This is an exemplary block diagram of a data closed-loop synchronization system according to some embodiments of the present invention. In some embodiments, the data closed-loop synchronization system 200 may include a caching module 210, a generation module 220, an upload module 230, and a verification module 240.

[0028] The caching module 210 refers to a module used for caching offline data content. In some embodiments, the caching module 210 is configured to receive and cache offline data content sent by the server when the terminal is in a network environment.

[0029] The generation module 220 refers to the module used to generate operation logs. In some embodiments, the generation module 220 is configured to receive operation inputs related to the job process and generate operation logs when the terminal is in a network-free or weak network environment.

[0030] Upload module 230 refers to a module used for uploading operation logs. In some embodiments, upload module 230 is configured to upload operation logs and other job data to the server based on preset rules after the terminal network is restored.

[0031] The verification module 240 is a module used to verify the operation logs. In some embodiments, the verification module is configured to send a verification processing request to the server, so that the server verifies the operation logs and completes subsequent business processing based on the verified operation logs.

[0032] For more information on the cache module 210, generation module 220, upload module 230, and verification module 240, please refer to [link to relevant documentation]. Figure 3-5 The corresponding description.

[0033] It should be noted that the above description of the data closed-loop synchronization system and its modules is for ease of description only and should not be construed as limiting the invention to the scope of the embodiments described. It is understood that those skilled in the art, after understanding the principle of the system, may arbitrarily combine the various modules or construct subsystems connected to other modules without departing from this principle. In some embodiments, Figure 2 The cache module 210, generation module 220, upload module 230, and verification module 240 disclosed herein can be different modules within a single system, or a single module can implement the functions of two or more of the aforementioned modules. For example, the modules can share a single storage module, or each module can have its own separate storage module. Such variations are all within the scope of protection of this invention.

[0034] Figure 3 This is an exemplary flowchart of a data closed-loop synchronization method according to some embodiments of the present invention. In some embodiments, process 300 can be executed by terminal 140. Figure 3 As shown, process 300 may include the following steps.

[0035] Step 310: When the terminal is in a network environment, it receives and caches offline data content sent by the server. A network environment refers to a state where the network connection quality between the terminal and the server meets the set conditions, sufficient to support real-time, stable data synchronization and interaction. For example, a network environment includes a cellular network environment, a Wi-Fi network environment, or a local area network environment. Network connection quality refers to the network communication capability comprehensively characterized by a set of key performance indicators. For example, network connection quality includes signal strength, network latency, connection reliability, and available bandwidth. Set conditions refer to a pre-configured set of judgment thresholds for key performance indicators, used to automatically trigger the switching of the working mode. For example, taking a Wi-Fi network environment, the set conditions include: signal strength higher than -65 dBm, network latency lower than 100 ms, data packet loss rate lower than 1%, and downlink bandwidth higher than 2 Mbps and uplink bandwidth higher than 512 Kbps. Among these, the data packet loss rate refers to the percentage of data packets lost during network transmission out of the total number of data packets sent. The data packet loss rate is a key indicator for measuring network connection reliability. Available bandwidth includes downlink bandwidth and uplink bandwidth. Downlink bandwidth refers to the download bandwidth from the server to the terminal in a network. Uplink bandwidth refers to the upload bandwidth from the terminal to the server in a network.

[0036] In some embodiments, a terminal can determine whether it is in a network environment in various ways. For example, the terminal can periodically send heartbeat packets or network probe requests (such as ping, Transmission Control Protocol (TCP) handshake) to the server and determine network connectivity based on whether it receives a response from the server. Another example is that the terminal can call the network status application programming interface (API) provided by the operating system to obtain the current connection status, such as whether it is connected to a Wi-Fi network, cellular network, etc. When the set conditions are met, the terminal is considered to be in a network environment.

[0037] Offline data content refers to the set of data needed to guide or support workers in independently completing tasks in environments without or with weak network coverage. For example, offline data content includes construction task information, drawings or Building Information Modeling (BIM) data slices corresponding to the construction area, process standards, and historical collaboration records or rectification information related to the task.

[0038] In some embodiments, the server can proactively push offline data content to the terminal upon receiving a check-in operation (such as facial recognition check-in or location-based check-in) performed by the operator. The terminal receives the offline data content pushed by the server via a network protocol (such as HTTP / HTTPS or other custom protocols). In some embodiments, the server can also distribute offline data content in various other ways. For example, the terminal can periodically send requests to the server to obtain the latest offline data content.

[0039] In some embodiments, after receiving offline data content, the terminal stores the offline data content in a local storage medium. For example, the terminal can store the received offline data content in a local database (such as an SQLite database), a local file system, or a secure private storage area. The cached offline data content can be directly accessed when the terminal is in a network-free or weak network environment to support operators in independently completing tasks. In some embodiments, the caching method can also be other methods. For example, the terminal can encrypt the data before storage, or use a combination of memory caching and persistent storage.

[0040] In some embodiments, the terminal determines the offline data content through the server based on the attendance information of the operators, task allocation information, and work area information.

[0041] Attendance information refers to information used to indicate whether an employee is qualified to work on a given day and the scope of their work time. For example, attendance information includes clock-in / out results, shift type, and valid work time period. Shift type refers to a pre-arranged work period template with defined specific work time rules for the employee. For example, shift types include standard day shift, night shift, and early shift. Valid work time period refers to the legal time interval during which the employee is permitted to work, ultimately determined based on shift type and possible dynamic adjustments (such as shift changes or overtime application approvals).

[0042] Task assignment information refers to data used to instruct operators on the tasks they need to perform. For example, task assignment information includes task type (such as installation, inspection, maintenance), task number, the process to which the task belongs (its position in the process flow), and task status (such as pending, in progress, paused).

[0043] Work area information refers to information related to the spatial location of the construction site, used to characterize the physical area where the task occurs. For example, work area information includes building, floor, construction section, or underground or above-ground area identification.

[0044] In some embodiments, offline data content may include at least one of the following: task information corresponding to the operator's task for the day, drawing data associated with the work area, process standard data, and historical collaborative record data.

[0045] Workers refer to individual workers authorized to participate in on-site operations during construction or production projects. A daily task refers to one or more construction or production work units pre-planned and assigned to workers within a calendar day's work cycle (00:00 to 24:00). Task information refers to a structured set of data describing the specific content, requirements, and attributes of the daily task. Task information is the aforementioned task allocation information. A work area refers to a physical space within a construction site or production area uniquely defined by three-dimensional spatial coordinates or logical identifiers (such as floor numbers, section codes, and grid numbers). Drawing data refers to engineering or design drawing files and their metadata stored digitally, strictly corresponding to the work area. Process standard data refers to a set of standardized work instructions and quality control standards corresponding to the process to which the daily task belongs. Historical collaborative data refers to a set of work process records for completed tasks that have a process logical or spatial relationship with the current task before the execution of the daily task.

[0046] In some embodiments, the terminal can determine the offline data content through a server using various methods based on the attendance information of the operators, task allocation information, and work area information.

[0047] In some embodiments, when a terminal determines offline data content based on attendance information through a server, it receives the attendance information of the workers and analyzes it to determine whether the workers are qualified to work that day and their valid working time range. For example, the server can determine whether the workers have entered a workable state and are within legal working hours based on the clock-in results and shift type in the attendance information. Only when attendance verification is successful will the server continue the offline data content determination process to ensure the compliance of data distribution. For another example, the server can verify the workers' identities and shift arrangements based on attendance information, generating offline data content only for workers scheduled for that day and who have arrived at their posts. In some embodiments, attendance information can be determined in various ways; for example, in addition to analyzing clock-in results, it can also be combined with data from access control systems, positioning systems, etc., for a comprehensive judgment.

[0048] In some embodiments, when the server determines the offline data content based on task allocation information, it determines the task information, process standard data, and historical collaboration record data corresponding to the task based on the task allocation information of the operators for that day. For example, the server retrieves the construction tasks assigned to the operators for that day from the task allocation system, determines the task type, the process to which each task belongs, and the task status for each task, and filters the task description data directly related to the construction task as task information. At the same time, based on the process to which the task belongs, the server retrieves the corresponding process standard data from the standard library. In addition, the server also queries historical collaboration record data that has a sequential dependency relationship or collaboration record with the construction task. Here, the task allocation system refers to a management system independent of the server, used for planning, scheduling, and managing work activities at the construction site or in the production process. The standard library refers to a database containing the correspondence between processes and process standard sequences.

[0049] In some embodiments, when the server determines offline data content based on work area information, it determines the specific physical area where the task occurs based on the work area information included in the construction task, and selects drawing data associated with that area accordingly. For example, the server selects only two-dimensional or three-dimensional drawing data corresponding to the work area (e.g., a specific floor, area, or construction section) from the drawing database, and filters out drawings from other irrelevant areas to ensure the accuracy and relevance of the issued drawing data. For another example, when the work area information indicates "Northeast corner of the 4th floor of Building D," the server sends a query request to the building information modeling platform to obtain structural drawings, installation drawings, and building elevation drawings for that specific area. In some embodiments, the drawing data associated with the work area can also be determined in other ways, such as using the spatial analysis function of a geographic information system (GIS) to automatically extract and crop relevant drawings from a large-scale drawing dataset based on the geographic coordinates or boundaries of the work area.

[0050] In some embodiments of the present invention, offline data content is accurately determined based on worker attendance information, task allocation information, and work area information. This enables personalized customization and on-demand distribution of offline data packets, significantly improving the relevance and accuracy of offline data, avoiding the transmission and storage of redundant data, and effectively reducing data transmission bandwidth and storage overhead. Simultaneously, providing necessary data only to workers who meet attendance requirements and have task assignments enhances data security and improves the efficiency of workers obtaining effective information, thereby optimizing the overall work process.

[0051] Step 320: When the terminal is in a network-free or weak network environment, it receives operation inputs related to the operation process and generates an operation log.

[0052] In some embodiments, when generating operation logs, the terminal also generates a time validity identifier for offline job operations. The time validity identifier is a pre-authorized, anti-counterfeiting credential used by the server to endorse the time of local operations in an offline environment. In some embodiments, the terminal can generate the time validity identifier based on an offline time validity token. For more information on this section, please refer to [link to relevant documentation]. Figure 4 The corresponding description.

[0053] A network-less or weak network environment refers to a situation where the network connection quality between the terminal and the server cannot meet the set conditions, and is insufficient to support real-time, stable data synchronization and interaction. For example, places with network-less or weak network environments include basements, tunnels, deep foundation pits, and areas with dense steel structures.

[0054] Operational input refers to the input actions performed by operators through terminals that are related to their work activities. For example, operational input includes task completion confirmation, work time entry, work status change, and on-site information recording (such as text and selection options).

[0055] In some embodiments, the terminal receives operational input related to the work process through its human-machine interface. For example, this input may be clicking the "Task Completed" button on a touchscreen to confirm task completion, or entering text information to record the on-site situation. Another example is that workers fill in work hour data, modify the work status (e.g., change from "In Progress" to "Paused"), or enter material usage information through selection options on the terminal. All of these inputs are recognized and received by the terminal.

[0056] The terminal in this invention can receive operation input in various ways, including but not limited to touch screen input, physical button input, voice input, gesture input, or QR code input.

[0057] An operation log is a structured data unit that records the operations performed by workers, used to fully preserve work behavior in an offline environment. In some embodiments, the operation log includes the content of the operation and a time validity identifier for the offline operation.

[0058] In some embodiments, the operation log includes job operation content and a time validity identifier for offline job operations. Job operation content refers to the data portion of the operation log that specifically describes a complete job operation and its direct results. For example, job operation content includes operation type and difference data. Operation type refers to a classification identifier for the business actions performed by the operator on the terminal. Job operations include task completion, data modification, and work record submission. Difference data refers to the business data content that changes compared to the pre-operation state, directly caused by this operation. Difference data includes changes such as the task status changing from in progress to completed, the number of completed tasks, and the work duration. Offline job operations refer to business actions performed on the terminal for its daily tasks in an environment with no network or weak network, and recorded by the terminal in the form of an operation log. A time validity identifier is an identifier used to indicate or prove that an operation occurred within a specific allowed offline time range, in order to verify the legality of the operation.

[0059] In some embodiments, when the terminal receives an operation input, it parses the input and generates job operation content. For example, if it receives a "task completion confirmation" input, the terminal sets the "operation type" to "task completed" and records the change from "in progress" to "completed" as "difference data." As another example, when a worker fills in work hour information, the terminal recognizes this action as "work hour submission" and records the specific work hour data as "difference data" in the operation log. Job operation content can be stored and represented in various ways, such as JSON, XML, or database structures.

[0060] Step 330: After the terminal network is restored, upload the operation log and other job data to the server based on preset rules.

[0061] Network recovery refers to the state in which a terminal regains the ability to communicate stably with a server. For example, a terminal can achieve network recovery when it moves from an environment with no or weak network to an environment with network, or when the fault that caused the network connection interruption is resolved.

[0062] In some embodiments, the terminal determines whether the network has been restored by periodically checking the network connectivity status. For example, the terminal application can attempt to send a heartbeat packet or request a connection to the server; if a response is successfully received and the connection is stable, the network is considered to have been restored. In some embodiments, the terminal can also listen for network status change notifications provided by the operating system; when the network changes from disconnected to available, it can recognize that the network has been restored. In some embodiments, the determination of network restoration can also be achieved through various other methods. For example, the terminal can detect WiFi signal strength or mobile data connection status to determine network restoration.

[0063] Preset rules refer to strategies used to set different synchronization priorities for different types of data. For example, preset rules may include setting data related to attendance, work records, and task status (including operation logs) as high priority, while setting large volumes of data such as pictures and videos taken at the construction site as low priority.

[0064] In some embodiments, when network recovery is detected, the terminal first prioritizes the locally stored data to be uploaded according to preset rules, and then uploads operation logs and other job data according to priority. For example, the terminal will prioritize identifying and uploading high-priority data such as operation logs and attendance records to ensure timely synchronization of core business information. In some embodiments, preset rules can also guide the terminal to adopt different upload strategies for different types of data, such as uploading high-priority data immediately, while scheduling low-priority large-volume data for background upload. In some embodiments, preset rules can be configured and applied in various ways. For example, the upload priority of data can be dynamically adjusted based on dimensions such as data type, data size, and business importance.

[0065] In some embodiments, the terminal uploads data by establishing a secure communication channel with the server. For example, the terminal can use the HTTPS protocol to send operation logs and job data in encrypted form to the server's API interface. To improve efficiency, data can be transmitted in batches or chunks. In some embodiments, the terminal can also use, for example, a message queue-based mechanism to upload data, where the upload module retrieves messages from the queue and sends them to the server.

[0066] In some embodiments, the preset rules include: prioritizing the uploading of critical business data containing witness information; and treating large volumes of data as low-priority data for delayed uploading or resuming interrupted uploads.

[0067] Witness information refers to third-party electronic credentials generated by a witnessing terminal through on-site verification of operation logs related to offline operations. Critical business data refers to business data that is essential for maintaining the core functions, status, or continuity of a business. For example, critical business data includes data directly related to attendance, work records, or task status.

[0068] In some embodiments, prioritizing the upload of critical business data containing witnessing information means that the terminal identifies critical business data with witnessing information and assigns it a higher upload priority. For example, the system can determine whether data contains witnessing information by parsing metadata or association identifiers in the data packet, and critical business data can be pre-identified based on its source or data type. After identification, the system will place it in a priority position in the upload queue. Alternatively, the system can allocate higher network bandwidth or utilize a dedicated communication channel for critical business data to accelerate upload. In some embodiments, prioritizing upload can also be achieved in various other ways. For example, the system can dynamically adjust the upload strategy based on the importance of the data, or reserve dedicated network resources to ensure the timely upload of critical data.

[0069] Low-priority data refers to data that is large in volume and has little impact on real-time settlement. For example, low-priority data may include high-resolution images or videos taken at construction sites. Large-volume data refers to non-urgent data files in the data set to be uploaded to the server whose individual size exceeds a preset threshold, or whose expected transmission time will affect the timeliness of critical business data. The preset threshold can be set based on actual needs.

[0070] In some embodiments, treating large-volume data as low-priority data for delayed upload or interrupted resume refers to the system identifying files that meet the characteristics of large-volume data and adopting a non-instant upload strategy. For example, the system determines whether a file is large-volume data by comparing its size with a preset threshold (e.g., 10 MB, 50 MB). When determined to be large-volume data, the terminal marks it as low-priority and can postpone the upload operation until a period of low system load or network bandwidth, such as at night. Furthermore, the terminal supports interrupted resume functionality. For example, when an upload is interrupted, the terminal can record the position of successfully uploaded data segments and resume transmission from the point of interruption after the network is restored. In some embodiments, the processing of large-volume data can also include various methods such as using compression algorithms to reduce file size and uploading in chunks to optimize transmission efficiency. For example, the terminal can first compress the large-volume data and then upload it in chunks, thereby further reducing network resource consumption and improving upload speed.

[0071] In some embodiments of this invention, by prioritizing the uploading of critical business data containing witnessing information, the continuity of core business processes and the timeliness of data are ensured, improving the accuracy of business decisions and meeting the verification requirements for the authenticity of operations. Simultaneously, treating large volumes of data as low-priority data for delayed uploading or breakpoint resumption effectively avoids network congestion, ensures the smooth transmission of critical data, and improves the success rate and resource utilization efficiency of large-volume data uploads through the breakpoint resumption mechanism, thereby optimizing the overall data upload experience and system operational stability.

[0072] Step 340: Send a verification request to the server to verify the operation log and complete subsequent business processing based on the verified operation log.

[0073] A verification request is a request initiated by the server to verify the operation logs and perform corresponding processing based on the verification results.

[0074] In some embodiments, the terminal initiates a verification request to the server. For example, the terminal application sends a verification request to the server when the user clicks the "Submit" button, or when data synchronization is automatically triggered at a preset time interval. In some embodiments, initiating a verification request can also be achieved through various other communication protocols and data transmission methods, such as sending operation logs to the server via TCP / IP connection, message queue service, etc.

[0075] In some embodiments, the server performs verification processing on the operation logs. Verification processing refers to the process by which the server performs legality verification on the operation logs. For example, verification processing includes verifying the time validity identifier in the operation logs, verifying data integrity, and verifying witness information. In some embodiments, after receiving a verification processing request, the server performs legality verification on the operation logs. For example, the server can verify the legality of the offline validity token contained in the operation logs, and determine whether the local time recorded in the operation logs is within the valid time range based on the fixed timestamp and valid time range in the offline validity token, to prevent forged operation times. Another example is that the server can perform P2P witness signature verification on the operation logs to verify the signature validity and witness permissions, ensuring the authenticity of the operation. In some embodiments, verification processing can also be performed in various ways. For example, data integrity verification can be performed on the operation logs to ensure that the data has not been tampered with; another example is that a rule-based expert system can be used for abnormal behavior detection.

[0076] In some embodiments, subsequent business processing is completed based on the verified operation logs. Subsequent business processing refers to the various business operations performed by the server based on the operation logs after verification. For example, subsequent business processing includes task status updates, work record statistics, and salary calculations. In some embodiments, after the operation logs are verified, the server executes corresponding business logic based on the content of the operation logs. For example, the server can update the status of the corresponding task in the database, changing it from "in progress" to "completed," or update the task's percentage progress. Another example is that the server can perform accurate work record statistics and salary calculations based on the verified operation logs. In some embodiments, subsequent business processing can also be completed in various ways. For example, in addition to directly updating the database, the processing results can be sent to other microservice modules via message queues, or external APIs can be called to complete complex business collaborations, such as automatically generating reports or triggering notifications.

[0077] In some embodiments, the terminal can determine salary information based on attendance information and trusted operation records through the server; and receive salary information sent by the server.

[0078] A trusted operation log is a record that contains operation-related information and witness information used to verify the operation, and can be used for subsequent verification. For more information on trusted operation logs, please refer to [link to relevant documentation]. Figure 5 The corresponding description.

[0079] Salary information refers to information used to represent the compensation that workers receive for the work they perform. For example, salary information may include basic salary, performance bonuses, overtime pay, etc., or it may be specifically reflected in compensation calculated based on working hours and workload.

[0080] In some embodiments, the terminal can determine salary information through a server using attendance information and trusted operation records in various ways. For example, the server can summarize the effective working hours and / or the amount of tasks completed by the workers based on their attendance information and trusted operation records, and determine the base salary by multiplying the preset hourly rate by the effective working hours. Another example is that the server can calculate task compensation based on the unit price of different tasks and the number of tasks completed by the workers, and include this as part of the salary information. Yet another example is that the server can also integrate overtime records or performance information from the attendance information into the salary calculation to generate complete salary information.

[0081] In some embodiments of the present invention, the server accurately determines the salary information of operators based on attendance information and verified trusted operation records, ensuring the fairness and accuracy of salary calculation. Simultaneously, by distributing salary information to operators' terminals, information transparency and acquisition efficiency are improved, manual verification errors are reduced, and the salary management process is optimized, thereby enhancing overall work efficiency and operator satisfaction.

[0082] In some embodiments of this invention, offline data is cached when the terminal has a network connection, ensuring the continuity of operations in environments without a network or with a weak network. Operation logs containing time-validation identifiers are generated while offline, reliably recording user actions and effectively preventing data loss and falsification risks. After the network is restored, data is uploaded based on preset rules and undergoes rigorous verification by the server, ensuring the authenticity of offline data and business compliance. This closed-loop mechanism significantly reduces the risk of business interruption due to network instability, improves data reliability, and enables stable and efficient operation of business in scenarios such as construction sites.

[0083] Figure 4 This is an exemplary flowchart illustrating the generation of a time validity identifier according to some embodiments of the present invention. In some embodiments, process 400 may be executed by terminal 140. Process 400 may include the following steps.

[0084] Step 410: When the terminal is in a network environment, it receives the attendance information of the operators and uploads it to the server. For more information on operators and attendance information, please refer to [link to relevant documentation]. Figure 3 The corresponding description.

[0085] In some embodiments, receiving worker attendance information can be achieved through an attendance application on a terminal. For example, workers log into the attendance management system using a terminal (such as a smartphone or tablet) or a fixed workstation terminal to clock in. The attendance management system records information such as clock-in time, clock-in location, and worker identity, forming initial attendance data, which is then received.

[0086] Step 420: Send a verification request to the server to verify the attendance information.

[0087] A verification request is a request used to enable the server to verify attendance information. For example, a verification request can be an API call, data packet, or message containing the attendance information to be verified.

[0088] In some embodiments, a terminal can initiate a verification request by sending an API request containing attendance information to be verified to the server. This API request can be a RESTful API call, where the attendance information is encapsulated in JSON or XML format in the request body and transmitted via HTTP / HTTPS. In some embodiments, the terminal can also encapsulate the attendance information to be verified into a message and publish it to a message queue service (such as Kafka or RabbitMQ), where the server subscribes to and consumes the message, thereby initiating a verification request. This message may contain key information such as employee identification credentials, clock-in timestamps, and geographic location data for server verification.

[0089] In some embodiments, upon receiving a verification request, the server first extracts the worker's identity identifier (e.g., user ID, employee number) and attendance event details (e.g., clock-in time, GPS coordinates) from the attendance information. The server can then query the user database or authentication service to verify the legitimacy and validity of the identity identifier. For example, the server can check whether the worker is currently employed, whether they are disabled, or whether their authentication information has expired.

[0090] In some embodiments, the server can verify attendance behavior according to preset work rules, including: checking whether the clock-in time is within the allowed shift time window, checking whether the clock-in location is located in the designated work area (via geofencing technology), or checking whether the number of clock-ins within a day meets the requirements. If the verification result shows that the worker's identity is legitimate and the attendance behavior complies with the work rules for the day, the verification is successful. The preset work rules can be set according to actual needs.

[0091] Step 430: In response to successful attendance information verification, receive the offline validity token and offline data content issued by the server. For a description of the offline data content, please refer to [link to relevant documentation]. Figure 3 And its corresponding content.

[0092] An offline validity token is data used to define the valid time range for offline job operations. The offline validity token is bound to a corresponding terminal and can be used to verify the validity of job times recorded locally on the terminal in environments without a network or with a weak network. In some embodiments, the offline validity token includes the valid time range for offline job operations. The valid time range refers to the time boundary within which a professional's offline job operations are permitted. For example, the valid time range is 08:00-18:00 of the current day. In some embodiments, the offline validity token includes a fixed timestamp. The fixed timestamp refers to the time point given by the server when the operator begins work. For example, the fixed timestamp is 08:00 of the current day.

[0093] In some embodiments, when there is a network environment, the server generates a fixed timestamp and valid time range for the operator based on the attendance information, which serves as an offline validity token.

[0094] In some embodiments, in a network environment, after the server confirms that the attendance information has been verified, it sends the offline validity token to the terminal through various means.

[0095] For example, a server can send an encrypted offline validity token to a terminal via the HTTPS protocol. After receiving the data packet, the terminal will decrypt it and verify its data integrity.

[0096] For example, after successful verification, the terminal requests an offline validity token from the server through a specific API interface. The server responds to this request and returns the token to the terminal as part of the data payload.

[0097] In some embodiments, offline time-limited tokens may also be transmitted via other secure transport protocols, such as using RPC calls or message queues, to ensure the timeliness and security of the tokens.

[0098] Step 440: When the terminal is in a network-free or weak network environment, generate a time validity identifier based on the offline validity token and limit the valid time range of the offline job operation.

[0099] In some embodiments, when performing an offline job operation, the terminal obtains the current local time. The terminal parses the offline validity token and extracts the preset valid time range for allowed offline jobs. The terminal compares the current local time with this valid time range. If the current local time falls within the valid time range, the terminal allows the generation of a time validity identifier. For example, when a worker records a work time of 10:30 using the terminal, the terminal verifies whether this time falls within the "08:00-18:00" valid time range specified by the offline validity token. If it falls within the valid time range, the generation of an operation log is allowed.

[0100] In some embodiments, the generation of the time validity identifier is based on the validity verification of the offline job operation time (e.g., the current local time). In some embodiments, after confirming the validity of the offline job operation time, the terminal binds or integrates key information (e.g., fixed timestamp, valid time range) from the offline time validity token with the current local time of the offline job operation to form a data structure, which serves as the time validity identifier for subsequent legality verification. For example, the terminal encapsulates the local work recording time, fixed timestamp, and valid time range together and performs digital signature to ensure its integrity and authenticity, thereby forming the time validity identifier.

[0101] In some embodiments, the time validity identifier can also be generated in various other ways. For example, the terminal can concatenate or serialize data fields such as the current local time, the ID of the offline validity token, the fixed timestamp, and the business operation type, and then use a preset hash function to generate a unique hash value as the time validity identifier. Alternatively, after the local time passes verification, the terminal can select a predefined "validity flag" from the offline validity token and associate it with the local operation time to form a concise time validity identifier.

[0102] In some embodiments, the offline time-limited token includes a root token and a sub-token. The root token contains a fixed timestamp, a valid time range, and time slicing information. The terminal can receive the root token issued by the server and start the trusted timing module; generate a sub-token based on the time slicing information in the root token and the cumulative duration of the trusted timing module; and perform local verification based on the root token and the sub-token when generating operation logs.

[0103] A root token is a static, offline time authorization credential issued by the server, containing time sharding rules. The root token defines the validity of time, determines the minimum granularity of time sharding, and serves as the basis for generating sub-tokens and performing local verification. In some embodiments, the root token includes a fixed timestamp, a valid time range, and time sharding information.

[0104] Time sharding information refers to data used to divide a valid time range into a series of continuous, fixed-duration minimum time units. Time sharding information includes shard duration, shard identification rules, and sharding calculation criteria. The shard duration refers to the fixed length of each minimum time unit (e.g., 30 minutes). The shard identification rules are the rules or preset sequences used to generate unique identifiers (e.g., S1, S2, ...) for each divided time shard. The sharding calculation criteria specify that the starting point of the sharding is a fixed timestamp and is performed in a linear, continuous manner. As an example, the server can divide the valid time range into several fixed time shards, such as one shard every 30 minutes (T0-T0+30, T0+30-T0+60, etc., where T0 is a fixed timestamp), with each time shard corresponding to a unique identifier (e.g., S1, S2, etc.), and encrypt this information and write it into the root token to define the smallest granularity of the job time.

[0105] In some embodiments, the terminal receives a root token issued by the server via a network connection. For example, the server generates a root token containing a fixed timestamp, a valid time range, and time-slicing information according to preset generation rules, and sends it to the terminal via secure methods such as encrypted transmission. Alternatively, the terminal can obtain the root token from the server via HTTP / HTTPS or a specific application-layer protocol and store it in a local secure storage area. In some embodiments, the root token can also be received via various other communication methods, including but not limited to short-range communication such as Bluetooth and NFC, or transmission via offline media such as a USB flash drive. The preset generation rules can be set based on actual needs.

[0106] A trusted timing module is a module that provides time independently of the local system time and accurately calculates the passage of time. It calculates the cumulative duration relative to a fixed timestamp, unaffected by changes to the local time. For example, a trusted timing module can be a hardware timestamp unit or a secure timing software module based on a preset encryption algorithm. The preset encryption algorithm can be configured according to actual needs.

[0107] In some embodiments, upon receiving the root token, the terminal initiates a trusted timing module decoupled from the terminal's system time. The trusted timing module operates on a millisecond-level auto-incrementing count and calculates the cumulative duration relative to a fixed timestamp in the root token, ensuring that the timing is unaffected by local time modifications.

[0108] In some embodiments, the terminal can generate a sub-token based on the time slicing information in the root token and the cumulative duration of the trusted timing module.

[0109] For example, the terminal continuously monitors the cumulative duration of the trusted timing module. When the cumulative duration enters the next preset time slice (for example, if time slice information defines each time slice as 30 minutes, when ΔT changes from 29 minutes to 30 minutes, it means entering the next time slice), the terminal triggers the generation of a sub-token. The newly generated sub-token embeds the identifier of the current time slice (e.g., S2) and the corresponding cumulative duration (e.g., 30 minutes). Alternatively, the generation of sub-tokens can proceed chronologically, forming a chain structure of "root token → S1 sub-token → S2 sub-token → ... → Sn sub-token," where the generation of each sub-token strictly depends on the cumulative duration calculated by the trusted timing module.

[0110] In some embodiments, local verification is performed based on the root token and child tokens when generating operation logs.

[0111] In some embodiments, when the terminal generates an operation log, it does not rely on the local system time. Instead, it associates the operation log with the currently active sub-token (or the most recently generated sub-token) and associates the time validity identifier with both the root token and the currently generated sub-token. As an example, during local verification, the terminal checks whether the time recorded in the operation log matches the time slice identifier and cumulative duration represented by the currently active sub-token, and whether the sub-token is within the valid time range defined by the root token. For instance, if the local time is tampered with, the terminal will find that the sub-token corresponding to the tampered time has not yet been generated, thus refusing to bind the operation to the ungenerated sub-token and only allowing binding to the generated sub-token, locking the work time to the real time. If the recorded time does not match the generated sub-token, the terminal verification fails, and the operation is marked as pending review. In some embodiments, the local verification mechanism can also be implemented in various ways, such as introducing digital signature technology to sign the sub-token and operation log, or combining it with other authentication methods. Besides marking as pending review, the handling of verification failures can also include rejecting the operation, triggering an alarm, and uploading an anomaly report.

[0112] In some embodiments of this invention, an offline time-validation token mechanism decouples time validity verification from local system time, effectively preventing the impact of local time tampering on the authenticity of operation logs. By using the time sharding information of the root token and the cumulative duration of the trusted timing module, sub-tokens are accurately generated and locally verified, ensuring that the time of operation records in offline mode cannot be tampered with, significantly improving data credibility and business compliance.

[0113] In some embodiments, the sub-token includes job behavior characteristics. The terminal can also activate the sensor acquisition module to collect sensor information when the trusted timing module is activated; generate job behavior characteristics based on the sensor information; and verify the authenticity of the job based on the job behavior characteristics and the job operation content in the operation log.

[0114] A sensor module refers to a hardware or software module in a terminal used to sense and collect various types of information. Examples of sensor modules include accelerometer modules, gyroscope modules, camera modules, microphone modules, GPS modules, fingerprint recognition modules, ambient light sensor modules, and proximity sensor modules.

[0115] Sensor information refers to data used to reflect the physical activity status of workers. For example, sensor information includes acceleration information, angular velocity information, posture change information, displacement or gait characteristics, and equipment holding or wearing status information.

[0116] In some embodiments, the activation of the sensor acquisition module to acquire sensor information can be triggered by the trusted timing module through software instructions or application programming interface (API) calls. For example, when the trusted timing module is activated, it can send a start command to the terminal's operating system or sensor management service, thereby activating the required sensors and initiating data acquisition.

[0117] For example, in some embodiments, the sensor acquisition module can be activated and information can be collected by a hardware interrupt or a specific event (e.g., the device detects that a person is wearing the device or has entered a specific work area).

[0118] Job behavior characteristics refer to data used to describe or reflect the physical activity patterns, intensity, or state characteristics of a worker when performing a specific task. For example, job behavior characteristics may include effective movement duration, intensity range distribution, number of posture changes, and the presence of prolonged static states. Effective movement duration refers to the continuous or cumulative time period during which a worker is determined to be in a preset job movement pattern and whose movement intensity exceeds a preset threshold, based on sensor data from their mobile terminal or wearable device (such as accelerometers or gyroscopes). The preset job movement pattern and preset threshold can be set based on actual needs. Intensity range distribution refers to the data set that quantifies the worker's movement intensity during work into multiple discrete levels (such as low, medium, and high) and statistically analyzes the proportion or frequency distribution of time spent at different intensity levels. The number of posture changes refers to the cumulative count of state switching events that occur during work when the spatial orientation of the worker's main body parts (such as the torso) meets a preset angle change threshold. The preset angle change threshold can be set based on actual needs. A prolonged static state refers to a risky situation where the terminal does not detect any effective human movement signals within an alarm duration threshold and the device is in a wearing state. The alarm duration threshold refers to a preset time length, such as 30 minutes. The alarm duration threshold can be set based on actual needs.

[0119] In some embodiments, the terminal can generate work behavior characteristics based on sensor information in various ways. For example, the terminal can identify continuous or cumulative time periods in sensor data that conform to a preset work movement pattern and whose movement intensity exceeds a preset threshold as the effective movement duration. Another example is that the terminal can quantify the worker's movement intensity (e.g., based on specific indicators of acceleration or angular velocity) into multiple discrete levels and statistically analyze the proportion or frequency of time spent at each level as the movement intensity range distribution. Yet another example is that the terminal can analyze gyroscope or accelerometer data to detect switching events in the spatial orientation of the worker's main body parts (such as the torso) that meet a preset angle change threshold, and accumulate these events as the posture change count. Furthermore, if the terminal does not detect any effective human movement signal within an alarm duration threshold and the device is being worn, it determines that a prolonged static state exists. In some embodiments, work behavior characteristics can be generated using various algorithms, including but not limited to statistical analysis methods, signal processing methods, and machine learning models. For example, high-level semantic features can be automatically extracted from time-series sensor data as work behavior characteristics by constructing a recurrent neural network (RNN) or convolutional neural network (CNN) model.

[0120] In some embodiments, the terminal can verify the authenticity of a job based on job behavior characteristics and job operation content in the operation log. In some embodiments, verifying job authenticity includes: First, the terminal obtains the specific job type (e.g., plastering, rebar tying) and corresponding job duration based on the job operation content recorded in the operation log. Second, it retrieves reference job behavior characteristics that match the job type and job duration from the terminal's local database or cache. The reference characteristics can be preset standard templates reflecting typical behavioral patterns of a specific job. Then, the previously generated actual job behavior characteristics are compared with the obtained reference job behavior characteristics. For example, various similarity evaluation algorithms, such as cosine similarity, Euclidean distance, or Dynamic Time Warping (DTW), can be used to quantify the degree of matching between the actual behavior characteristics and the reference behavior characteristics. In some embodiments, if the similarity after comparison is higher than a preset authenticity threshold, the job is determined to be authentic; conversely, if the similarity is lower than the preset authenticity threshold, the job is marked for manual review. For example, the preset authenticity threshold can be set to 0.8, indicating that the actual behavior and the reference behavior must have at least 80% similarity to be considered authentic. The preset authenticity threshold can be set based on actual needs. For example, when the job operation content in the operation log corresponds to multiple time slices, the system can comprehensively verify the job behavior characteristics of the corresponding multiple sub-tokens. By weighted averaging or fusing the job behavior characteristics of these slices, a more comprehensive set of actual job behavior characteristics is formed, which is then compared with the corresponding reference characteristics. In some embodiments, job authenticity verification can also be achieved through various models or algorithms. For example, in addition to machine learning models (such as support vector machines, decision trees, and other classification models), rule-based expert systems, fuzzy logic reasoning, or anomaly detection algorithms can also be used for judgment.

[0121] In some embodiments of this invention, sensor information is collected when the trusted timing module is activated, and work behavior characteristics are generated based on this information. The authenticity of the work is then verified by combining this information with the work operation content in the operation log, thus achieving real-time and objective supervision of the work process. This method compares the actual physical activity data of the workers with preset standards, significantly improving the authenticity and credibility of work records and effectively reducing the risk of false reporting or non-standard operations. Compared to the traditional method that relies solely on manual recording, the verification accuracy is improved by approximately 25%, while reducing the review workload by approximately 30%, providing more reliable data support for work management.

[0122] In some embodiments of this invention, by receiving and verifying the attendance information of workers through a server, an offline validity token is issued upon successful verification. A time validity identifier is then generated based on this token, effectively ensuring the legality and authenticity of workers' work time when performing offline work in a network-free environment. This solution overcomes the risks of traditional offline work time being difficult to trace and tamper with, significantly improving the reliability and accuracy of attendance and work time management, and is particularly suitable for work scenarios with unstable or no network access.

[0123] It should be noted that the above descriptions of processes 300 and 400 are merely illustrative and do not limit the scope of the invention. Those skilled in the art can make various modifications and changes to processes 300 and 400 under the guidance of this invention. However, these modifications and changes are still within the scope of this invention.

[0124] Figure 5 This is an exemplary schematic diagram illustrating the formation of a trusted operation record according to some embodiments of the present invention.

[0125] In some embodiments, when the terminal is in a network-free or weak network environment, in response to the job operation corresponding to operation input 501 involving time settlement transaction 502, at least one witness terminal's witnessing information 504 on the operation log is obtained via near-field communication 503; based on the operation log 505 and the witnessing information 504, a trusted operation record 506 is formed. For more information on network-free or weak network environments, operation inputs, operation logs, etc., please refer to [link to relevant documentation]. Figure 3 The corresponding description.

[0126] Time settlement transactions refer to operational actions or events related to the settlement of wages or other forms of compensation. For example, time settlement transactions include time confirmation, time record submission, and other work completion operations directly related to payroll settlement.

[0127] Near-field communication (NFC) refers to a communication method that allows data exchange without relying on an external network and under physically close proximity conditions.

[0128] In some embodiments, the near-field communication method includes at least one of Bluetooth, near-field communication, wireless LAN direct connection, and ultrasonic communication.

[0129] Witnessing terminals are terminals located at the work site and used to verify the actions of workers on-site. For example, witnessing terminals include team leader terminals and worker terminals.

[0130] In some embodiments, witness information includes signature information or verification information generated by at least one witness terminal from the operation log.

[0131] Signature information refers to information used to verify the source, integrity, or authenticity of data.

[0132] Verification information refers to information used to verify the authenticity of an operation.

[0133] In some embodiments, the witness terminal can generate signature information for the operation log.

[0134] For example, the witness terminal can first perform a hash operation on the operation log to obtain the hash value of the operation log. Then, the witness terminal uses its private key to encrypt the hash value, thereby generating signature information.

[0135] In other embodiments, the witness terminal can directly use a digital signature algorithm (e.g., RSA, Elliptic Curve Digital Signature Algorithm ECDSA, etc.) to sign the operation log or its digest and generate signature information.

[0136] In some embodiments, the witness terminal can generate verification information from the operation log. For example, the witness terminal can perform a hash operation on the operation log to obtain a hash value of the operation log, and use this hash value as the verification information. Alternatively, the witness terminal can calculate a checksum for the operation log, such as a Cyclic Redundancy Check (CRC) code or a simple checksum, as the verification information. In other embodiments, the witness terminal can utilize the Hash Message Authentication Code (HMAC) algorithm, using a pre-shared key to perform a hash operation on the operation log to generate a message authentication code as the verification information. In some embodiments, the verification information can also be generated using various other data integrity verification methods. For example, more complex Error Correcting Codes (ECCs) or other cryptographic hash functions can be used to generate the verification information.

[0137] In some embodiments, the witnessing information further includes a time validity identifier for at least one witnessing terminal. The terminal can determine time consistency via a server based on the time validity identifiers of at least one witnessing terminal and the terminal's time validity identifier.

[0138] At least one witness terminal's time validity identifier is obtained in the same way as the terminal's time validity identifier, as described above.

[0139] Time consistency refers to the technical state in which, in a network-free or weak network environment, when two or more mobile terminals (such as a terminal and a witness terminal) need to perform business collaboration (such as a witnessing operation), they determine whether the time base followed by these terminals is within the same acceptable error range by comparing the current absolute time range derived from the offline time validity tokens they hold.

[0140] In some embodiments, the server receives and parses the time validity identifiers of the terminal and at least one witness terminal. Based on the fixed timestamp, time sharding information, and sub-token number contained in the root token of each terminal, the server deduces the current absolute time range of that terminal. For example, if the fixed timestamp of the root token is T0, the time sharding period is Δt, and the sub-token number is N, then the server can deduce that the current time range of the terminal is [T0+N]. Δt,T0+(N+1) (Δt). After obtaining the current time ranges of both the terminal and the witness terminal, the server compares these derived time ranges to determine whether they overlap or fall within a preset error range. If the time ranges overlap, or the difference between them is less than a preset threshold, time consistency can be determined.

[0141] For example, the server can calculate the midpoint of the current time range for each terminal. If the maximum difference between the midpoints of the time ranges of all terminals (including the terminal and at least one witness terminal) is less than a preset time consistency threshold, the server can determine that there is time consistency among these terminals. In some embodiments, the methods for determining time consistency may also include, but are not limited to, analyzing the distribution of time validity identifiers through statistical methods, such as calculating the variance or standard deviation of the time range, or making a judgment through a rule-based reasoning system.

[0142] In some embodiments of this invention, the time validity identifier of the witnessing terminal is included in the witnessing information, and the server determines time consistency based on the time validity identifiers of the terminal and the witnessing terminal. This solution effectively solves the problem of potentially large deviations in terminal time bases in environments without network or with weak network. This ensures that the time of terminals participating in business collaboration is synchronized within an acceptable error range, significantly improving the accuracy, reliability, and security of offline business collaborations such as witnessing operations. This solution effectively avoids potential operational errors and data conflicts caused by time asynchrony, improving the robustness of the system.

[0143] In some embodiments, the terminal may indicate the corresponding operation log as pending review status in response to not obtaining witness information within a preset time; and the server may submit the operation log in the pending review status to the verification process after the network is restored.

[0144] A preset time refers to a pre-defined period of time, such as 30 minutes. The preset time can be set based on actual needs.

[0145] The "pending review" status indicates that the operation log has failed the automatic trusted verification and requires further manual or system verification.

[0146] A verification process refers to a procedure or series of steps for verifying, checking, and processing information or data. For example, when a server receives an operation log in a pending review status, it submits it to the verification process for verification and processing, thereby preventing the operation log from directly participating in automatic settlement.

[0147] In some embodiments of this invention, by introducing a pending verification status and verification process, unverified operation logs can be isolated when witness information is missing and network failure occurs. This effectively prevents them from directly participating in critical business processes such as automated settlement, avoiding data errors or inconsistencies. After network recovery, these logs are specifically submitted for manual or system verification, significantly improving system reliability, data accuracy, and business processing security, while reducing potential operational risks.

[0148] In some embodiments of this invention, when the terminal is in a network-free or weak network environment, witnessing information is obtained through near-field communication when time settlement transactions are involved, and a reliable operation record is formed accordingly. This enables critical time settlement operations to be effectively and reliably recorded even under poor network conditions, avoiding business interruption or data loss due to network outages. The witnessing mechanism significantly enhances the authenticity and non-repudiation of operation records, effectively preventing false declarations and potential labor disputes, and improving data integrity and settlement efficiency.

[0149] The basic concepts have been described above. It is clear that the detailed disclosure above is merely illustrative and does not constitute a limitation of the present invention. Although not explicitly stated herein, various modifications, improvements, and corrections may be made to the present invention by those skilled in the art. Such modifications, improvements, and corrections are suggested in this invention and therefore remain within the spirit and scope of the exemplary embodiments of the present invention.

[0150] Furthermore, this invention uses specific terms to describe embodiments of the invention. For example, "some embodiments" refers to a particular feature, structure, or characteristic associated with at least one embodiment of the invention. Additionally, certain features, structures, or characteristics in one or more embodiments of the invention can be appropriately combined.

Claims

1. A data closed-loop synchronization method, characterized in that, The method is executed by a terminal and includes: When the terminal is in a network environment, it receives and caches offline data content sent by the server; When the terminal is in a network-free or weak network environment, it receives operation input related to the job process and generates an operation log. The operation log includes the job operation content and a time validity identifier. The time validity identifier includes the result of validating the offline job operation time. The process of receiving operation inputs related to the job process and generating operation logs includes: When the terminal is in a network environment, it receives the attendance information of the operators and uploads it to the server; A verification request is sent to the server, enabling the server to verify the attendance information; In response to the successful verification of the attendance information, the system receives the offline validity token and the offline data content issued by the server. When the terminal is in the environment with no network or weak network, the time validity identifier is generated based on the offline validity token, and the effective time range of the offline operation is limited; The offline validity token includes a root token and sub-tokens. The root token contains a fixed timestamp, a valid time range, and time slicing information. Receiving the offline validity token issued by the server includes: Receive the root token issued by the server and start the trusted timing module; Based on the time slicing information in the root token and the cumulative duration of the trusted timing module, the sub-token is generated. The sub-token includes job behavior characteristics, including effective movement duration, action intensity range distribution, number of posture changes, and / or whether there is a long period of stillness. When generating the operation log, local verification is performed based on the root token and the child token, including: Start the sensor acquisition module to collect sensor information; Based on the sensor information, the operational behavior characteristics are generated; The authenticity of the job is verified based on the job behavior characteristics and the job operation content in the operation log; Once the terminal network is restored, the operation log and other job data are uploaded to the server based on preset rules. A verification request is sent to the server, which then verifies the operation log and completes subsequent business processing based on the verified operation log.

2. The method according to claim 1, characterized in that, The process of receiving and caching offline data content sent by the server includes: The offline data content is determined through the server based on the attendance information, task allocation information, and work area information of the operators; wherein, the offline data content includes at least one of the following: task information corresponding to the operator's task for the day, drawing data associated with the work area, process standard data, and historical collaboration record data.

3. The method according to claim 1, characterized in that, The verification processing request includes verification of witness information, and the method includes: When the terminal is in the environment with no network or weak network, In response to the operation operation corresponding to the operation input involving time settlement transactions, at least one witness terminal obtains the witness information of the operation log through near-field communication and forms a trusted operation record.

4. The method according to claim 3, characterized in that, The near-field communication method includes at least one of Bluetooth, near-field communication, wireless LAN direct connection, and ultrasonic communication; the witnessing information includes signature information or verification information generated by the at least one witnessing terminal from the operation log.

5. The method according to claim 3, characterized in that, The step of obtaining witness information from at least one witness terminal regarding the operation log includes: If the witness information is not obtained within a preset time, the corresponding operation log will be marked as pending review. After the network is restored, the server submits the operation log of the pending verification status to the verification process.

6. The method according to claim 1, characterized in that, The preset rules include: prioritizing the uploading of key business data containing witness information; and treating large volumes of data as low-priority data for delayed uploading or resuming interrupted uploads.

7. The method according to claim 1, characterized in that, The method further includes: Salary information is determined based on attendance information and trusted operation records through the server. Receive the salary information sent by the server.

8. A data closed-loop synchronization method, characterized in that, The method is executed by the server and includes: When the terminal is in a network environment, it receives attendance information sent by the terminal. In response to receiving a verification request from the terminal, the attendance information is verified. In response to the successful verification of the attendance information, an offline validity token and offline data content are issued so that the terminal can generate an operation log based on the offline validity token in a network-free or weak network environment. The offline validity token includes a root token, which contains a fixed timestamp, a valid time range, and time slicing information. The operation log contains job operation content and a time validity identifier, which includes the result of validating the offline job operation time. When the terminal network is restored, the system receives the operation log and other job data uploaded by the terminal based on preset rules. The time validity identifier in the operation log is determined by local verification based on the root token and a sub-token generated by the trusted timing module in the terminal when the operation log is generated. The sub-token includes job behavior characteristics, such as effective movement duration, movement intensity range distribution, number of posture changes, and / or the presence of prolonged static states. These job behavior characteristics are generated based on sensor information acquired by the sensor acquisition module in the terminal. The local verification is performed based on the job characteristics and the job operation content in the operation log. The system receives a verification request initiated by the terminal, verifies the operation log, and completes subsequent business processing based on the verified operation log.

9. A data closed-loop synchronization system, characterized in that, The system includes: The caching module is configured to receive and cache offline data content sent by the server when the terminal is in a network environment; The generation module is configured to receive operation input related to the job process and generate an operation log when the terminal is in a network-free or weak network environment. The operation log includes job operation content and time validity identifier, and the time validity identifier includes the result of validating the offline job operation time. The process of receiving operation inputs related to the job process and generating operation logs includes: When the terminal is in a network environment, it receives the attendance information of the operators and uploads it to the server; A verification request is sent to the server, enabling the server to verify the attendance information; In response to the successful verification of the attendance information, the system receives the offline validity token and the offline data content issued by the server. When the terminal is in the environment with no network or weak network, the time validity identifier is generated based on the offline validity token, and the effective time range of the offline operation is limited; The offline validity token includes a root token and sub-tokens. The root token contains a fixed timestamp, a valid time range, and time slicing information. Receiving the offline validity token issued by the server includes: Receive the root token issued by the server and start the trusted timing module; Based on the time slicing information in the root token and the cumulative duration of the trusted timing module, the sub-token is generated. The sub-token includes job behavior characteristics, including effective movement duration, action intensity range distribution, number of posture changes, and / or whether there is a long period of stillness. When generating the operation log, local verification is performed based on the root token and the child token, including: Start the sensor acquisition module to collect sensor information; Based on the sensor information, the operational behavior characteristics are generated; The authenticity of the job is verified based on the job behavior characteristics and the job operation content in the operation log; The upload module is configured to upload the operation log and other job data to the server based on preset rules after the terminal network is restored. The verification module is configured to send a verification processing request to the server, so that the server can verify the operation log and complete subsequent business processing based on the verified operation log.

10. A computer-readable storage medium, characterized in that, The storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-7.

Images