A two-dimensional code dual-mode binding management method and system based on space code dynamic weighting

Abstract

The application discloses a two-dimensional code double-mode binding management method and system based on space code dynamic weighting. A two-dimensional code containing only a unique identifier ID is generated and stored in a code pool. The server establishes an offline occupation record with an occupation valid period for the idle two-dimensional code according to a job task or entity label batch, and issues offline authorization data. The two-dimensional code with an effective offline occupation record is excluded during online pre-binding; the mobile terminal records the to-be-synchronized binding data of the two-dimensional code and business information when offline, and synchronizes the binding data and occupation credentials after restoring the network connection. The server checks the occupation credentials, offline occupation record, task or batch association relationship and two-dimensional code state, and uses the unique identifier ID and expected state as the update condition to write the business information association and update the two-dimensional code state in the database transaction or consistency processing flow, so as to reduce the risk of repeated allocation, repeated binding and state conflict when the online and offline code pools are shared.

Description

Technical Field

[0001] This invention relates to the field of digital management technology, and in particular to a dual-mode binding management method and system for QR codes based on dynamic weighting of empty codes. Background Technology

[0002] With the widespread application of QR codes in product identification, asset management, production and construction, and commodity circulation, QR codes have gradually expanded from a simple information display carrier to a digital entry point connecting physical objects with server-side business data.

[0003] According to publicly released information, the National QR Code Integrated Service Platform has opened enterprise registration and improved the verifiability of QR code-related entities and product information through mechanisms such as filing, testing, and information inquiry. On December 31, 2025, GB / T 46881—2025, "General Requirements for Digital Supply Chain Traceability System," was officially released and implemented. In June 2026, the Ministry of Housing and Urban-Rural Development and the National Data Administration jointly issued a notice clarifying the comprehensive establishment of a unified code system for building construction.

[0004] Some existing QR code applications have already directly encoded product identification, batch information, production date, serial number, or other business data into the QR code graphic data during the QR code generation or label production stage. These types of QR codes can directly retrieve the encoded data upon scanning. However, in application scenarios where business information requires restricted access, subsequent adjustments, or delayed binding, this may lead to issues such as premature exposure of business data, needing to recreate the QR code, or difficulty adapting to the "affix code first, then create file" workflow.

[0005] In addition, some QR code management systems are mainly designed around QR code generation, parsing, and business information query. When QR code generation, label printing, on-site posting, and business information binding are performed by different personnel or different systems, there is a lack of collaborative management mechanisms for personnel permissions, QR code lifecycle status, and resource conflicts between online pre-binding and offline operations.

[0006] Some existing systems have the following problems: QR codes are bound to specific business content when they are generated, making it difficult to adapt to the on-site operation mode of blank codes leaving the factory and affixing them before assigning them; the security internal control and personnel access management mechanisms are not perfect; the QR code lifecycle status is relatively simple; there is no management mechanism to isolate internal production codes from external product codes; when online pre-binding and offline operations share the same code pool, it is easy for QR codes to be repeatedly allocated or binding status conflicts to occur. Summary of the Invention

[0007] This invention aims to provide a dual-mode binding management method and system for QR codes based on dynamic weighting of empty codes, in order to solve the problems that when online pre-binding and offline physical binding share the same code pool, QR codes already allocated to offline mobile terminals may be selected again by online services, and that duplicate binding or state conflicts may occur after the offline assignment operation resumes network connection.

[0008] The term "empty code" in this invention refers to a QR code graphic data that contains only a unique identifier (ID) for querying QR code records, without directly containing product name, batch number, location, construction record, maintenance record, or other business information. This business information is stored on the server and associated with the QR code through the unique identifier (ID).

[0009] The dynamic authorization mentioned in this invention refers to the process by which, after a QR code is generated, the server establishes a unique identifier ID for the QR code and associates it with the business information of the target object based on actual business needs, thereby enabling the QR code to obtain the corresponding business information query or function access capabilities.

[0010] According to a first aspect of the present invention, a dual-mode binding management method for QR codes based on dynamic weighting of empty codes is provided, comprising: Generate a QR code containing only a unique identifier (ID) and store it in the code pool; Set the QR codes in the code pool to be in an idle / unused, posted but unassigned, bound and effective, or invalid and archived state; For idle QR codes, online pre-binding mode and offline physical binding mode are provided; Before the offline physical binding operation begins, the server selects a QR code from the available QR codes based on the task identifier or the batch identifier of the physical QR code label, establishes an offline occupancy record with an occupancy validity period for the selected QR code, and sends offline authorization data to the mobile terminal. When establishing offline occupancy records and executing online pre-binding, the server treats the QR code records as a common concurrency control object. Through database locks, version number condition updates, or uniqueness constraints, the same QR code cannot be occupied by online pre-binding and offline jobs at the same time. In the online pre-binding mode, the server excludes QR codes with valid offline occupancy records and associates the selected QR code with the business information of the target object. In the offline physical binding mode, when the mobile device is offline, only the QR code corresponding to the offline authorization data is allowed to be assigned business information. After the network is restored, the assigned data and the occupancy certificate will be synchronized to the server. The server verifies the occupancy certificate, offline occupancy record, account and device, batch association of job task or entity QR code label and QR code status, and decides whether to accept the binding based on the verification results; The server uses a unique identifier ID and the expected state before the update as the update conditions, writes the business information associated record and updates the QR code status in the same database transaction; if the verification fails or the update conditions are not met, the binding is rejected.

[0011] Offline occupancy records are independent of QR code status settings. Creating, using, releasing, or expiring offline occupancy records does not require adding to the QR code's lifecycle status. During offline operations, the QR code can remain idle and unused on the server side, but because a valid offline occupancy record exists, it cannot be pre-bound and selected again online.

[0012] In some implementations, offline authorization data includes offline operation expiration time and synchronization expiration time. The offline operation expiration time limits the mobile device from generating new offline assignment operations, while the synchronization expiration time limits completed offline assignment operations from being uploaded to the server. The expiration of the offline operation expiration time does not immediately invalidate the offline occupancy record; the record remains valid at least until the synchronization expiration time to prevent the QR code from being reallocated while waiting for synchronization.

[0013] In some implementations, the mobile device generates a unique request identifier for each offline assignment operation. The server sets a uniqueness constraint on the request identifier and associates and saves the request identifier with the request data digest to prevent the same operation from being executed multiple times due to network retries or duplicate submissions.

[0014] In some implementations, the mobile device determines whether the offline operation has exceeded the maximum valid duration based on a local monotonic timer. The local system time and monotonic timer information serve as auxiliary verification information and do not constitute the sole basis for the server to determine the actual occurrence time of the offline operation. When the monotonic timer status is lost, time information is contradictory, or integrity verification fails, the mobile device does not directly confirm the new offline assignment operation.

[0015] In some implementations, in response to a request for reassignment of a defaced QR code, the server determines a new QR code that is idle and unused and has no valid offline occupancy record based on the candidate new QR codes submitted by the mobile terminal. In the same database transaction, the server transfers or re-associates the business information corresponding to the original QR code to the new QR code, updates the new QR code to a bound and effective state, updates the original QR code to an invalid and sealed state, and establishes a new and old QR code replacement association record.

[0016] The process of transferring or reassigning the business information corresponding to the original QR code to the new QR code includes invalidating the valid business information association corresponding to the original QR code and establishing a valid association between the new QR code and the business information, or updating the QR code identifier in the original business information association record from the original QR code's unique identifier ID to the new QR code's unique identifier ID. After the damaged QR code is reassigned, the original QR code no longer retains a valid business information association that can be used for normal business access.

[0017] In some implementations, internal production codes and external product codes are separated by code pools, business data, and access permissions. External product codes include Code A, which provides a public parsing entry point, and Code B, which is hidden and contains only a unique identifier (ID). The server records whether Code B has completed its initial verification through a separate verification status field, without mixing the initial verification status with the QR code's lifecycle status.

[0018] According to a second aspect of the present invention, a dual-mode QR code binding management system based on dynamic weighting of empty codes is provided, comprising a mobile terminal, a server, and a code pool database. When the mobile terminal and the server execute their respective programs, they cooperate to complete the above-described method.

[0019] According to a third aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0020] Compared with the prior art, the present invention has at least the following beneficial effects: By setting offline occupancy records outside the QR code lifecycle state, QR codes already allocated to mobile devices can be excluded from the online pre-bound set of optional QR codes, thereby coordinating the use of the same code pool by online and offline operations.

[0021] By associating occupancy credentials with QR codes, personnel, devices, tasks, or tag batches, the scope of use of offline authorized data can be restricted.

[0022] By controlling QR code state migration through database locks, version numbers, or conditional updates, the risk of duplicate binding and state overwriting can be reduced when multiple requests operate on the same QR code simultaneously.

[0023] Idempotent processing can be achieved by requesting a unique identifier and requesting a data digest, which can reduce duplicate execution caused by repeated synchronization.

[0024] By storing business information on the server, the QR code graphic data only stores a unique identifier ID, allowing the corresponding business information to be updated without recreating the QR code.

[0025] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and drawings.

[0026] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art are briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0028] Figure 1 This is a diagram illustrating the overall structure of the QR code dual-mode binding management system in this embodiment of the invention. Figure 2 This is a schematic diagram illustrating the four-state lifecycle and offline occupancy relationship of a QR code in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the dual-mode binding and online / offline QR code resource collaboration in an embodiment of the present invention. Figure 4 This is a diagram illustrating the multi-role permission isolation and batch operation dual-person review structure in an embodiment of the present invention. Figure 5 This is a flowchart of personnel registration and QR code scanning permission verification in an embodiment of the present invention; Figure 6 This is a flowchart illustrating the QR code validity period management and damaged code reassignment process in an embodiment of the present invention. Figure 7 This is a flowchart illustrating the offline authorization, disconnected network assignment, and network recovery synchronization verification process in an embodiment of the present invention. Figure 8 This is a diagram illustrating the internal production code, external product code, and data access isolation structure in an embodiment of the present invention. Figure 9 This is a flowchart illustrating the unique identifier ID generation, parsing, and query process in an embodiment of the present invention. Figure 10 This is a diagram illustrating the interface structure between the administrative supervision platform and the multi-level supervision platform in this embodiment of the invention. Detailed Implementation

[0029] The embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the following embodiments are used to illustrate the technical solutions of the present invention, and not to limit the scope of protection of the present invention. Where there is no conflict, the technical features of the different embodiments described below can be combined with each other.

[0030] like Figure 1 As shown, the QR code dual-mode binding management system includes a mobile terminal, a server terminal, and a code pool database.

[0031] Mobile devices can be smartphones, tablets, handheld scanning terminals, or other devices with QR code scanning, data input, local storage, and network communication capabilities.

[0032] The server-side can include functions such as identifier generation, code pool management, dual-mode binding, offline job control, permission verification, and identifier resolution. These functions can be deployed on the same server, multiple servers, or microservice nodes.

[0033] The code pool database is used to store QR code records, entity QR code label batch records, job task records, offline occupancy records, business information association records, personnel registration records, and synchronization request processing records.

[0034] The QR code record can include a unique identifier ID, generation batch, QR code status, creation time, idle expiration time, business information association identifier, version number, and last update time.

[0035] Offline occupancy records can include an offline occupancy record identifier, a unique identifier ID, an account identifier, a unique device identifier, a job task identifier or a physical QR code label batch identifier, a server issuance time, an offline operation expiration time, a synchronization expiration time, an effective occupancy expiration time, an occupancy status, and an occupancy certificate summary.

[0036] The occupancy status of offline occupancy records can include valid, used, expired, and released. This occupancy status is used to control whether the QR code can be pre-bound online or selected by other offline tasks, and does not constitute a fifth lifecycle status of the QR code.

[0037] If a task ends early and the mobile device confirms that a QR code for offline assignment operations to be synchronized has not yet been generated, the mobile device can submit an offline occupancy release request to the server.

[0038] The server verifies the login authentication credentials, occupancy credentials, account, device and task or batch association, and after confirming that the corresponding offline occupancy record is still valid, updates the offline occupancy record to the released state.

[0039] After the mobile device receives a successful release result, it deletes or deactivates the corresponding local offline authorization data. Once the offline occupancy record is updated to a released state, the original offline authorization data no longer qualifies for direct synchronization binding. When the mobile device submits assignment data based on the original offline authorization data again, the server refuses to automatically execute the binding and transfers it to the conflict handling or manual verification process according to business rules.

[0040] When the validity period of an offline occupancy record expires, the server will update any offline occupancy records that are still valid to an expired state.

[0041] After the offline occupancy record is updated to an expired status, the server combines the corresponding job task status, the batch distribution of physical QR code labels, and on-site usage confirmation information to determine whether the corresponding physical QR code label has been used.

[0042] If it can be confirmed that the physical QR code label has not been used and the QR code is still in an idle and unused state, the QR code can be re-participated in subsequent allocations.

[0043] If it cannot be confirmed that the physical QR code label has not been used, the server uses the unique identifier ID and the idle and unused status as the update conditions to update the QR code to the invalid and sealed status, and retains the corresponding task, batch and offline occupancy records for manual verification.

[0044] When the condition update affects zero records, the server re-queries the current status of the QR code, without overwriting any existing valid binding relationships or other subsequent states of the QR code.

[0045] Synchronization request processing records may include a unique request identifier, a request data summary, processing status, processing result, first reception time, and last update time.

[0046] The term "same database transaction" as used in this manual refers to write operations that can be guaranteed to be atomically committed or rolled back by the same transaction management mechanism. When related data is physically deployed in different databases, distributed transactions, transaction messages, or other consistency mechanisms can also be used; the final binding success result will not be returned to the mobile device until the related data reaches a consistent state.

[0047] like Figure 2 and Figure 9 As shown, the server generates candidate unique identifiers (IDs) according to the preset identifier generation rules and writes the candidate unique identifiers (IDs) into the code pool database.

[0048] The code pool database sets a unique constraint on the unique identifier ID field. When a uniqueness conflict occurs during writing, the server regenerates a candidate unique identifier ID and writes it again until the uniqueness check is passed.

[0049] For internal production management scenarios, the unique identifier ID only needs to be able to uniquely distinguish QR code records in the corresponding code pool. For B codes used for external product verification, the unique identifier ID is preferably generated using cryptographically secure random numbers. The random information can be no less than 96 bits, preferably 128 bits, to reduce the possibility of being sequentially enumerated or predictably manipulated.

[0050] The server sets the following status for the QR code: The idle and unused state indicates that the QR code has been generated, but has not yet been effectively bound to business information; The "posted but not assigned a value" status indicates that the QR code has been posted or the server has received confirmation of posting, but the business information binding has not yet been completed. The "bound and effective" status indicates that the QR code has been effectively associated with the target object's business information; The "invalidated and sealed" status indicates that the QR code is no longer allowed to be bound to new business information due to expiration, replacement, invalidation by management personnel, or other reasons.

[0051] A QR code status update requires at least a unique identifier ID and the expected state before the update. For example, when updating a QR code from an idle and unused state to an posted but unassigned state, the update conditions must include at least that the unique identifier ID equals the target unique identifier ID and that the current state is an idle and unused state.

[0052] When a condition update affects one record, the update is considered successful. When it affects zero records, the server further queries the QR code records to distinguish between situations such as the QR code not existing, the QR code status having changed, or a concurrent conflict occurring.

[0053] After the QR code is created or printed, you can create a batch of physical QR code labels according to the printing task, distribution slip, or other label collection.

[0054] Each physical QR code label batch identifier corresponds to one or more unique identifier IDs.

[0055] When the server creates a job task, it can associate the job task identifier with the batch identifier of the physical QR code label, the on-site operator's account identifier, and the unique identifier of the mobile device.

[0056] For example, the server creates a task T001 and associates the tag batch B001, the on-site worker account U001, and the mobile device D001 with the task T001. When the server sends offline authorization data to the mobile device, it only selects the QR code from the QR codes corresponding to tag batch B001.

[0057] The unique device identifier is a registration identifier used to distinguish mobile devices within the scope of this system's management; it does not need to be a permanent hardware serial number. When a device is replaced or reset, the device association can be updated after re-registration.

[0058] like Figure 3 and Figure 7As shown, when the mobile device has a network connection, it sends an offline authorization data retrieval request to the server. The request includes at least one of the following: account identifier, device unique identifier, login authentication credential, and job task identifier and entity QR code label batch identifier.

[0059] The server first verifies the validity of the login authentication credentials, queries the permission bits stored on the server based on the account identifier, and verifies the device registration relationship and the association between the account, device and task or batch.

[0060] After successful verification, select a QR code from those that meet the following conditions: The QR code belongs to the corresponding task or batch of physical QR code labels; The QR code is in an idle and unused state; There are no valid offline usage records for the QR code.

[0061] The server uses QR code records as concurrency control objects. In one implementation, the server locks candidate QR code records in a database transaction, and after reconfirming their status and offline occupancy, establishes an offline occupancy record.

[0062] In another implementation, the QR code record includes a version number. The server performs an update based on a unique identifier ID, an idle / unused status, and the current version number, and increments the version number upon successful update; if the version number does not meet the conditions, the current QR code is discarded or a new QR code is selected.

[0063] The update of the version number condition, the reconfirmation of the QR code status and offline usage, and the creation of the offline usage record are all executed within the same database transaction. If any step fails, the server rolls back the transaction and does not send the corresponding QR code offline authorization data to the mobile device.

[0064] The server can also use database uniqueness constraints or conditional update mechanisms to ensure that the same unique identifier ID corresponds to only one valid offline occupancy record at any given time.

[0065] When establishing an offline occupancy record, the QR code's lifecycle status can remain idle and unused. Online pre-binding queries both the QR code's status and the offline occupancy record when selecting a QR code, thus avoiding the selection of QR codes already occupied by offline jobs.

[0066] The server generates an occupancy certificate based on the unique identifier ID, account identifier, device unique identifier, job task identifier or entity QR code label batch identifier, server issuance time, offline operation expiration time, synchronization expiration time, occupancy validity expiration time, and random number.

[0067] For example: Voucher data = Unique ID + Account ID + Device Unique ID + Task or Batch ID + Server Issuance Time + Offline Operation Expiration Time + Synchronization Expiration Time + Valid Expiration Time + Random Number; Credential authentication data = HMAC-SHA256(credential authentication key, credential data); Voucher occupancy = Voucher data + Voucher authentication data.

[0068] The "+" sign above indicates byte sequence concatenation according to a preset field order and structured encoding format, and does not represent mathematical addition. The length, character encoding, and time format of each field are pre-defined to ensure that the voucher data can be uniquely parsed.

[0069] The authentication key used to generate the credential is stored on the server and is not sent to the mobile device. The credential is mainly used by the server to verify the source and integrity of the credential after the mobile device regains network access.

[0070] Offline authorization data may include a unique identifier ID, occupancy certificate, account identifier, device unique identifier, task or batch identifier, server issuance time, offline operation expiration time, synchronization expiration time, occupancy validity expiration time, maximum validity duration, and integrity verification information.

[0071] Integrity verification information is used to enable mobile devices to detect abnormal modifications to offline authorized data when offline. Preferably, the server generates a digital signature for preset fields in the offline authorized data using a signing private key, and the mobile device verifies the digital signature using a pre-saved corresponding public key. If the digital signature verification fails, the mobile device refuses to use the offline authorized data to generate new offline assignment operations.

[0072] The preset fields include at least a unique identifier ID, account identifier, device unique identifier, job task identifier or entity QR code label batch identifier, server issuance time, offline operation expiration time, synchronization expiration time, valid expiration time, maximum valid duration, and occupancy certificate or occupancy certificate summary.

[0073] The server performs structured encoding on the preset fields according to the preset field order, character encoding, field length, null value representation, and time format, and generates a digital signature from the encoded byte sequence or its digest. The mobile device reconstructs the data to be verified according to the same structured encoding rules.

[0074] The occupancy certificate is used for online verification by the server, while the digital signature is used for offline verification by the mobile device; the two serve different purposes.

[0075] In the online pre-binding mode, the backend system requests the server to assign a QR code based on the target object's business information.

[0076] The server selects a QR code from those that are idle and unused and have no valid offline occupancy records. After obtaining processing permissions for the QR code record, it reconfirms its status and occupancy.

[0077] After confirmation, the server writes the association record between the unique identifier ID and the target object's business information in the same database transaction, and updates the QR code from an idle and unused state to a bound and effective state.

[0078] QR code status updates must be based on at least a unique identifier ID and an idle / unused status. If the update affects zero records, the server will roll back the associated record writes, allow a different QR code to be selected, or return a resource conflict warning.

[0079] When the mobile device can communicate with the server, the on-site operator scans the QR code that has been posted or is about to be posted, and sends a unique identifier ID, account identifier, device unique identifier, login authentication credential and task identifier to the server; when the mobile device has offline authorization data corresponding to the unique identifier ID stored locally, it also sends the corresponding occupancy credential to the server.

[0080] The server verifies login authentication credentials, device registration relationships, permissions, and task associations, and uses the corresponding QR code record as a concurrency control object, performing conditional updates by locking the QR code record or based on the version number of the QR code record.

[0081] After obtaining the processing permission for the QR code record, the server queries the QR code status and valid offline occupancy records again.

[0082] When no valid offline occupancy record exists for the QR code, the server allows continued online binding. When a valid offline occupancy record exists, execution is allowed only if the account, device, and task corresponding to the offline occupancy record match the current operation, and the occupancy credential verification passes. If the valid offline occupancy record belongs to another account, device, or task, the server rejects the current binding operation.

[0083] When network binding is allowed to continue, the server updates the QR code to an "affixed but unassigned" state and increments the version number, using the unique identifier ID, the idle / unused state, and the version number corresponding to when processing permissions were obtained as update conditions. If the condition update affects zero records, the server rejects the current operation and queries the QR code status again.

[0084] When the server updates the QR code to a posted but unassigned state, it simultaneously records the account identifier, device unique identifier, job task identifier or physical QR code label batch identifier, and posting confirmation time corresponding to this posting confirmation. This information can be stored in the QR code record, status change log, or posting confirmation data for subsequent business information binding and offline synchronization verification.

[0085] After on-site personnel enter or select business information, the mobile device sends the bound data to the server. The server writes the business information association record in the same database transaction, and updates the QR code to a bound and effective state using the unique identifier ID and the posted but unassigned status as update conditions.

[0086] After on-site personnel enter or select business information, the mobile device sends the binding data to the server. The server verifies that the batch of QR code tags corresponding to the posted but unassigned state matches the current binding request. Then, it writes the business information association record in the same database transaction and updates the QR code to the bound and effective state using the unique identifier ID and the posted but unassigned state as the update conditions.

[0087] When the current network binding uses a valid offline occupancy record consistent with the current operation, the server updates the corresponding offline occupancy record to the used state in the database transaction; if any operation in the database transaction fails, the server rolls back the writing of the business information association record, the update of the QR code from the posted but unassigned state to the bound and effective state, and the update of the offline occupancy record, while the offline occupancy record remains in its original state.

[0088] After entering an area without network access, the mobile device scans a QR code to obtain a unique identifier ID and queries the locally stored offline authorization data.

[0089] Mobile devices should perform at least the following checks: Whether the unique identifier ID belongs to local offline authorized data; Are the account identifier and the device unique identifier consistent? Are the task or batch relationships consistent? Did the integrity check pass? Determine whether the local monotonic timer is still within the timeframe that allows new offline assignment operations to be generated.

[0090] After the inspection is passed, the mobile terminal allows on-site personnel to enter business information and generates a unique request identifier for the offline assignment operation.

[0091] The mobile device stores a unique identifier ID, business information binding data, account identifier, device unique identifier, task or batch identifier, occupancy certificate, request unique identifier, operation time recorded by the mobile device, local monotonic timer start point, monotonic timer value when the offline assignment operation occurs or the elapsed time calculated from the local monotonic timer start point, and data packet version number.

[0092] When the same offline assignment operation is repeatedly synchronized, the unique identifier of the request remains unchanged.

[0093] The offline authorization data issued by the server includes the offline operation expiration time, the synchronization expiration time, and the maximum valid duration.

[0094] The offline operation expiration time limits the deadline for the mobile device to generate a new offline assignment operation. The synchronization expiration time limits the deadline for submitted completed offline assignment operations to the server.

[0095] The validity period of offline occupancy records does not expire earlier than the synchronization expiration time. When the offline operation expiration time expires, the mobile device stops generating new offline assignment operations, but the server continues to exclude the corresponding QR code from the set of online pre-bound optional QR codes until synchronization is successful, offline occupancy is released, or the validity period of occupancy expires.

[0096] When the mobile device receives offline authorized data, it records the local monotonic timer start point and determines whether the maximum valid duration has been exceeded based on the elapsed time. The local monotonic timer is a timing mechanism that does not automatically roll back the time when the user adjusts the system calendar.

[0097] The system time and monotonic timing information recorded by the mobile device are mainly used to help determine whether the operation time is reasonable, and are not used as absolute proof for the server to determine the actual operation time.

[0098] When the original monotonic timing state is lost due to device restart, application data clearing, or other reasons, the mobile device will no longer generate new offline assignment operations that can automatically complete the binding based on the original offline authorization data; operations that were completed and saved before the timing state was lost can be submitted to the server for further verification after connecting to the network.

[0099] After the mobile device restores its network connection, it will synchronize the offline assigned data, occupancy certificate, request unique identifier, account identifier, device unique identifier, and login authentication certificate to the server.

[0100] The server first performs an idempotency check based on the unique identifier of the request.

[0101] The server performs structured encoding on the unique identifier ID, business information binding data, account, device, task or batch identifier, occupancy credential summary, and data packet version number according to the preset field order, character encoding, null value representation method, and numerical format. It then uses SHA-256 or a digest algorithm with equivalent security strength to generate a request data digest from the encoded byte sequence.

[0102] When the server receives a synchronization request, it attempts to create a synchronization request processing record in the database transaction with the unique identifier of the request as the unique key.

[0103] If no submitted record with the same unique request identifier exists, the creation is successful, and the server continues to execute the corresponding binding process.

[0104] When concurrent transactions with the same unique identifier exist, the database waits for the concurrent transactions to end based on the uniqueness constraint. After the concurrent transaction is rolled back, the current request can create a synchronous request processing record and continue processing; after the concurrent transaction is committed, the current request will not create a new synchronous request processing record due to the uniqueness constraint conflict, but will read the already committed processing record.

[0105] When the request data digest in the existing processing record matches the current request data digest, the server returns the existing processing result; when the request data digest in the existing processing record does not match the current request data digest, the server rejects the current request and records the request unique identifier conflict.

[0106] For requests that successfully create a synchronization request processing record for the first time, the creation of the synchronization request processing record, the update of the QR code status, the writing of the business information association record, the update of the offline occupancy record, and the writing of the synchronization processing result are all executed within the same database transaction. If any step fails or the processing process is abnormally interrupted before the transaction is committed, the entire transaction is rolled back.

[0107] For the first received synchronization request, the server performs at least the following checks: Verify the validity of login authentication credentials, and verify the account identifier, device unique identifier, permission bits, and their association with the job task or entity QR code label batch; Verify the integrity of offline authorization data and check if the verification information is correct; Verify that the authentication data of the occupancy certificate is correct; Verify that the unique identifier ID, account identifier, device unique identifier, job task identifier or entity QR code label batch identifier and each time field in the occupancy certificate are consistent with the offline occupancy record stored on the server. Verify that the current server time has not exceeded the synchronization expiration time; Verify whether the elapsed duration of the monotonic timer stored in the offline assignment data is non-negative and does not exceed the maximum valid duration, and combine the server issuance time and the operation time recorded by the mobile terminal to determine whether there are obvious contradictions in the relevant time information; Verify whether the QR code is in an idle and unused state, or whether it is in a state of being posted but not assigned a value corresponding to the current account, device, job task, or physical QR code label batch; Verify whether the unique identifier ID is associated with the job task or the batch of entity QR code label.

[0108] The operation time and monotonic timing information recorded on the mobile device serve as auxiliary evidence for the server to determine the reasonableness of the operation time, but do not constitute absolute proof of the actual occurrence time of the offline assignment operation. When the monotonic timing elapses beyond the maximum valid duration, the relevant time information is obviously contradictory, or the monotonic timing information is missing, the server will not automatically perform the binding, but will transfer the corresponding operation to the conflict handling or manual verification process.

[0109] After the relevant validations pass, the server performs the following operations within the same database transaction: When the QR code is in an idle and unused state, the unique identifier ID and the idle and unused state are used as update conditions to update the QR code to the posted but unassigned state. When the QR code is already in the posted but unassigned state, based on the associated information recorded during the posting confirmation, verify that the account, device, job task, or entity QR code label batch corresponding to the state is consistent with the current synchronization request, and keep the state unchanged. Write the association record between the QR code and business information; The QR code is updated to a bound and effective state based on its unique identifier ID and the fact that it has been posted but not yet assigned a value. Update the offline occupancy record to the used status and update the synchronous request processing record to the processed status.

[0110] A posted but unassigned state can be a persistent state or an intermediate state within the same transaction. The migration process can be saved through a state change log.

[0111] If any verification fails or any condition update affects zero records, the server will reject the binding and transfer the operation to the conflict handling process, without overwriting the existing valid business information associations of the QR code.

[0112] like Figure 4 and Figure 5 As shown, the system can be configured with code pool administrator, print administrator, field operation personnel, backend data administrator, and read-only query personnel.

[0113] The code pool administrator is responsible for QR code generation, invalidation, and code pool management; the printing administrator is responsible for physical label production; on-site operators are responsible for scanning codes and submitting bound data; the back-end data administrator is responsible for business information maintenance and exception handling; and read-only query personnel can only query data within their authorized scope.

[0114] The server pre-configures conflicting role combinations and prohibits the same account from simultaneously obtaining role permissions that enable independent completion of the entire process of QR code generation, printing, business information binding, and cancellation. When an account's role changes, the server re-verifies the aforementioned role combinations; if permission conflicts exist, the server refuses to save the corresponding role configuration.

[0115] Batch generation and batch cancellation operations can be reviewed by two people. After the first code pool administrator initiates the operation, the second code pool administrator reviews it within a preset time limit. The server executes the operation after confirming that the two correspond to different personnel registration identifiers.

[0116] The server uses the account, device, and permissions in the filing data as the reliable basis, while the information uploaded by the mobile device is only used as information to be verified.

[0117] like Figure 6 As shown, an idle validity period is set for QR codes that are in an idle and unused state.

[0118] When a QR code exceeds its idle validity period, remains idle and unused, and has no valid offline usage record, the server updates it to an invalid and archived state.

[0119] If a QR code exceeds its idle validity period but still has a valid offline occupancy record, it will not be invalidated temporarily. It will be re-evaluated after the offline occupancy record is updated to show that it has been used, expired, or released.

[0120] If a valid QR code is damaged, on-site workers or managers should submit an application to reassign the damaged code.

[0121] After approval, the mobile device scans the candidate new QR code and submits the new QR code's unique identifier ID, the original QR code's unique identifier ID, and the application identifier for reassigning damaged QR codes to the server.

[0122] Server-side verification: Applications for reassigning damaged codes remain valid; The original QR code remains in a bound and active state; The new QR code is currently idle and unused. The new QR code does not have any valid offline usage records.

[0123] The server uses the original QR code record and the new QR code record as concurrency control objects in the database transaction, and verifies the status of the original QR code and the new QR code and the offline usage of the new QR code again.

[0124] The status update of the new QR code is processed based on the new QR code's unique identifier ID, its idle and unused status, and the absence of any valid offline occupancy records; the status update of the original QR code is processed based on the original QR code's unique identifier ID and its already bound and effective status.

[0125] After successful verification, the server, within the same database transaction, transfers or re-associates the business information corresponding to the original QR code to the new QR code, updates the new QR code to a bound and effective state, updates the original QR code to an invalid and archived state, and establishes a record for replacing the old and new QR codes.

[0126] If any processing condition is not met, any condition update affects zero records, or any write operation fails, the server rolls back the transaction and returns a code-switching failure message. After the old and new QR codes are successfully switched, the new QR code label is then affixed to the original business object.

[0127] like Figure 8 and Figure 9 As shown, internal production codes and external product codes can be configured with mutually isolated code pools, business data, access permissions, and validity period rules.

[0128] Internal production codes are used for internal production, construction, equipment, or asset management within an enterprise. Mobile devices or dedicated terminals used to scan these codes are pre-configured with an internal parsing service entry point and include the corresponding QR code application system information in the parsing request.

[0129] External product codes include Code A and Code B. Code A includes a public resolution service entry point, allowing users to access verification functions on web pages, mini-programs, or applications. Code B is hidden by a scratch-off coating, packaging layer, or other structure; the graphic data of Code B only includes a unique identifier ID.

[0130] After the terminal scans code A to access the public parsing service, it then scans or enters the unique identifier ID of code B. The server then queries the QR code record corresponding to code B, the business information association record, and the verification status.

[0131] The QR code B has separate lifecycle status and verification status settings. The verification status includes at least two states: initial verification not completed and initial verification completed.

[0132] When code B is in a bound and effective state and the verification status is "first verification not completed", the server uses the unique identifier ID, the bound and effective state, and the "first verification not completed" status as update conditions to update the verification status to "first verification completed", and writes the first verification time and verification result in the same database transaction.

[0133] When the query finds that code B is in a bound and effective state and the verification status is "first verification completed", the server will not generate the first verification result again, but will return a prompt message indicating that the first verification has been completed and the first verification time.

[0134] When the corresponding B code is not found, the B code has not yet been associated with valid business information, or the B code's QR code lifecycle status is not in the bound and effective state, the server will not return the result of successful initial verification or completion of initial verification, but will return the prompt information corresponding to the corresponding exception reason.

[0135] The initial verification result indicates that the B code is being recorded and verified by the server for the first time, and does not constitute absolute proof of the authenticity of the product on its own.

[0136] Taking the coding of components at a construction site as an example, the server pre-generates 500 QR codes containing only unique identifiers (IDs) and creates physical QR code labels, establishing label batch B001.

[0137] The server creates a task T001 and associates task T001 with the tag batch B001, the on-site operator account U001, and the mobile device D001.

[0138] The mobile device requests offline authorization data for task T001 while connected to the internet. In this embodiment, 100 QR codes are requested at a time.

[0139] The server selects 100 QR codes from tag batch B001 that are idle and unused and have no valid offline occupancy records, and creates offline occupancy records for them in the database transaction.

[0140] The server issuance time is recorded as t0, the offline operation expiration time is set to 24 hours after t0, the synchronization expiration time and the valid expiration time are set to 48 hours after t0, and the maximum valid duration is set to 24 hours.

[0141] After the offline occupancy record is established, the above 100 QR codes will not be selected for online pre-binding before the expiration of the occupancy validity period.

[0142] On-site workers scan QR codes and enter component type, installation location, and construction records in areas without network access. The mobile device generates a unique request identifier for each operation and saves offline assignment data.

[0143] For example, if an operation is completed 20 hours after t0, which is within the maximum valid duration of 24 hours, the mobile device is allowed to save it. When the mobile device regains network connectivity 30 hours after t0, although the offline operation expiration time has passed, it has not yet exceeded the synchronization expiration time, so the operation can be submitted.

[0144] The server verifies the unique identifier of the request, the request data digest, the occupancy certificate, the offline occupancy record, the account, the device, the task and tag batch association, and the QR code status.

[0145] The server also verifies that the monotonic timer saved by the operation has elapsed for 20 hours, which does not exceed the maximum valid duration of 24 hours, and confirms that there are no obvious contradictions in the relevant time information.

[0146] After successful verification, the server writes the association between the QR code and the component business information in the same transaction, updates the QR code to the bound and effective state, updates the offline occupancy record to the used state, and records the synchronization processing result.

[0147] When scanning an unassigned QR code on a mobile device after the offline operation expiration time, a new offline assignment operation with direct synchronization binding qualification will no longer be generated. Instead, the operator can be prompted to reconnect to the network and re-obtain authorization.

[0148] If synchronization is not completed by the expiration time and the expiration deadline, the server will update the offline occupancy record that is still valid to an expired state.

[0149] For QR codes that can be confirmed as not yet used on-site and still in an idle and unused state based on task records and tag batch distribution, the server can re-enlist them in subsequent allocations; if it cannot be confirmed that the physical QR code tag is not yet used, the server will update the QR code to an invalid and sealed state using the unique identifier ID and idle and unused state as update conditions; if the condition update fails, the server will query the current status of the QR code again, without overwriting the already formed valid binding relationship.

[0150] Data submitted by mobile devices after the synchronization expiration time will not be directly bound, but will instead enter the conflict handling or manual verification process.

[0151] In one embodiment, the system also includes establishing an independent administrative supervision platform to achieve: automatic reporting of supervision data to supervision platforms at all levels according to preset rules; receiving and executing inspection and recall instructions issued by regulatory departments; generating special statistical reports that meet regulatory requirements; real-time synchronization of abnormal data to the supervision end; and support for multi-level supervision platform integration (national, provincial, municipal, and county levels).

[0152] When a QR code is generated, business information is bound, a QR code is invalidated, a damaged QR code is replaced, a product is verified for the first time, or an abnormal scanning event occurs, the enterprise business system generates corresponding regulatory data. This regulatory data includes at least one of the following: enterprise identifier, unique QR code ID, business object identifier, product or component category, batch information, QR code status, event type, event occurrence time, and abnormal information.

[0153] The administrative supervision platform performs field conversion and format validation on the regulatory data generated by the enterprise's business systems according to the data format specified by the target supervision platform. For example, it converts product names, component types, or status names used internally by the enterprise into product codes, component category codes, or status codes specified by the supervision platform.

[0154] After the format verification is passed, the administrative supervision platform sends the supervision data to the corresponding supervision platform through the data interface provided by the supervision platform, and records the sending time, sending result and the receipt information returned by the supervision platform.

[0155] When data transmission fails or the regulatory platform fails to return results within a preset time, the administrative regulatory platform saves the data that has not been successfully reported and resends it at preset time intervals. When the preset number of retries is reached and the data still fails, the corresponding data is transferred to manual processing and an anomaly alert is sent to the management personnel.

[0156] The administrative supervision platform is also used to receive inspection instructions, recall instructions, or data correction instructions issued by the supervision platform. Upon receiving a supervision instruction, the administrative supervision platform verifies the identity of the supervision platform, the instruction identifier, and the instruction content, and generates corresponding inspection tasks, recall tasks, or data correction tasks based on the supervision instruction.

[0157] After the enterprise completes the corresponding task, the administrative supervision platform will send the task processing result, processing time and processing status to the supervision platform that issued the supervision instruction, and save the supervision instruction, execution process and processing result for subsequent query and audit.

[0158] For example, in water network engineering construction, blank codes are generated for key engineering components such as dams, tunnels, and aqueducts, and affixed to the surface of the components. During construction, construction records, material sources, and supervision information are dynamically linked by scanning the codes using mobile devices. Inspection personnel scan the codes to record the project's operational status and report potential hazards. Equipment such as pumps and gates are managed with codes, ensuring full traceability from installation, operation, maintenance to scrapping. In underground pipeline network inspections, offline code scanning and recording are supported, with automatic synchronization upon network connection.

[0159] For example, unique empty code IDs are assigned to core power equipment such as transformers and transmission towers to establish "one item, one code" electronic files; inspection personnel scan codes to record equipment operating status, test data, and maintenance history; distributed photovoltaic, charging piles and other new energy facilities scan codes to view operating data and maintenance records; and construction units such as tower foundations are coded during construction to achieve traceability of project progress and quality.

[0160] For example, assigning unique empty code IDs to computing power nodes and devices such as data centers and servers enables unified identification management of computing power resources; assigning identifiers to computing power tasks or data streams allows for tracking their scheduling paths and supports the refined operation of the national integrated computing power network.

[0161] For example, codes are assigned to communication infrastructure such as 5G base stations, optical cables, and communication pipelines to bind their location, ownership, and construction information; inspection personnel scan the codes to record equipment status and maintenance history; and physical network resources are digitized to support precise operation and maintenance and network optimization.

[0162] For example, each manhole cover, valve well, and pipe section is assigned a unique empty code ID, which is then bound to electronic archive information such as material, specifications, pipe diameter, GPS coordinates, ownership unit, and construction records, achieving "one code per well, one file per pipe"; inspection personnel scan the code to record the status (normal / damaged / missing) and upload photos; during emergency repairs, repair personnel scan the code to instantly obtain key information such as pipe diameter, valve location, and upstream and downstream relationships; offline scanning and recording of underground pipelines is supported, and automatic synchronization occurs after network connection; the entire process from construction to maintenance is traceable.

[0163] For example, assigning empty codes to logistics units such as parcels, pallets, and transport vehicles enables end-to-end tracking; scanning codes in warehouse management allows for quick entry and exit from warehouses, inventory checks, and shelving; scanning codes in the transportation process records the trajectory; and in multimodal transport, a unified code is used to connect road, rail, waterway, and air transport to achieve end-to-end traceability.

[0164] For example, after QR code Q001 is bound to building component C001 for business information, the enterprise business system generates regulatory data containing the unique QR code identifier ID, component type, construction project, binding time, and binding status. The administrative supervision platform converts the data according to the data format specified by the municipal supervision platform and sends the converted regulatory data to the municipal supervision platform.

[0165] Upon successful receipt, the municipal-level regulatory platform returns a regulatory receipt, which is then stored in the administrative regulatory platform. If the initial transmission fails, the administrative regulatory platform resends the document after a preset time. When the municipal-level regulatory platform subsequently issues inspection instructions for the component, the administrative regulatory platform generates an inspection task based on the instructions and returns the inspection results to the municipal-level regulatory platform upon completion.

[0166] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A dual-mode binding management method for QR codes based on dynamic weighting of empty codes, characterized in that, include: Generate a QR code that contains only a unique identifier ID and no business information, and store the QR code in a code pool; For idle QR codes in the code pool, an online pre-binding mode and an offline physical binding mode are provided; The server selects an idle QR code based on the task identifier or the batch identifier of the entity QR code label, establishes an offline occupancy record corresponding to the QR code and with an occupancy validity period, and sends offline authorization data containing the unique identifier ID and occupancy certificate to the mobile terminal. The same unique identifier ID corresponds to only one valid offline occupancy record at any given time. In the online pre-binding mode, the server selects a QR code from those that are idle and unused and have no valid offline occupancy records, and associates the selected QR code with the business information of the target object. In the offline physical binding mode, when the mobile terminal is offline, the business information is assigned to the corresponding QR code according to the offline authorization data, and the assigned data and occupancy certificate are synchronized to the server after the network is restored. The server verifies the occupancy certificate, offline occupancy record, batch association relationship of job task or entity QR code label and QR code status, and uses the unique identifier ID and the expected status before the update as the update conditions. In the same database transaction or consistency processing flow, the association relationship between the QR code and business information is written and the QR code status is updated. If the verification fails or the update conditions are not met, the binding is rejected.

2. The method according to claim 1, characterized in that, The server generates candidate unique identifiers (IDs) according to preset identifier generation rules and writes the candidate unique identifiers (IDs) into the code pool database. The code pool database sets a unique constraint on the unique identifier ID field. When the candidate unique identifier ID already exists, the server regenerates the candidate unique identifier ID until it passes the uniqueness check. The unique identifier ID of the QR code used for external product verification includes no less than 96 bits of random information.

3. The method according to claim 1, characterized in that, Establish a multi-role permission isolation mechanism that includes code pool administrators, printing administrators, on-site operators, back-end data administrators, and read-only query personnel, so that no single account can independently complete the entire chain of operations of QR code generation, printing, business information binding, and cancellation. After the first code pool administrator initiates a batch generation or batch invalidation operation, the server executes the corresponding operation when it receives a review and confirmation instruction from the second code pool administrator, who has a different registration identifier than the first code pool administrator.

4. The method according to claim 1, characterized in that, The server establishes a record of filing data, including account identifier, device unique identifier, and permission bits; When a mobile device requests offline authorization data, performs online binding, or synchronizes data assignment, it sends an account identifier, a unique device identifier, and login authentication credentials to the server. The server verifies the login authentication credentials, device registration relationship, permission bits and account, and the association between the device and the work task or entity QR code label batch; The occupancy certificate is associated with a unique identifier ID, account identifier, device unique identifier, job task identifier or physical QR code label batch identifier and occupancy validity period.

5. The method according to claim 1, characterized in that, Set a status field for the QR code. The status field includes an idle and unused status, an posted but unassigned status, a bound and effective status, and an invalid and sealed status. The offline occupancy record is set independently of the status field. For QR codes that have exceeded their idle validity period, are still in an idle and unused state, and have no valid offline occupancy records, update them to an invalid and sealed state; In response to a request for reassignment of a defaced QR code that has already been bound and activated, the server determines a new QR code from among the candidate new QR codes submitted by the mobile client. The new QR code is in an idle and unused state and has no valid offline occupancy record. The processing conditions are that the new QR code is in an idle and unused state and has no valid offline occupancy record, and that the original QR code is in a bound and activated state. In the same database transaction, the business information of the original QR code is transferred or re-associated to the new QR code, the new QR code is updated to a bound and activated state, the original QR code is updated to an invalid and sealed state, and a replacement association record is established between the new QR code and the original QR code.

6. The method according to claim 1, characterized in that, The QR code includes an internal production code and a B code in the external product code. The internal production code and the B code correspond to mutually isolated code pools, business data, and access permissions, respectively. The external product code also includes an A code set in conjunction with the B code. The A code includes a public resolution service entry point, and the B code is hidden and contains only a unique identifier ID. The server sets a verification status field for the B code. When the B code is in a bound and effective state and the verification status is in the state of incomplete first verification, the unique identifier ID, the bound and effective state, and the incomplete first verification status are used as update conditions. In the same database transaction, the verification status is updated to the state of completed first verification and written to the first verification record. When the update is successful, return the initial verification result; when the verification status of the B code is already in the initial verification completed state or when a verification request for the B code is received again, return a prompt message indicating that the initial verification has been completed. If the B code is not found, if the B code is not associated with valid business information, or if the B code is not in a bound and effective state, the corresponding verification error message will be returned.

7. The method according to claim 1, characterized in that, The mobile device generates a unique request identifier for each offline assignment operation and keeps the unique request identifier unchanged when repeatedly synchronizing the same offline assignment operation. The server associates and stores the unique request identifier with the request data digest, and sets a uniqueness constraint on the unique request identifier. When the same unique request identifier is received again, the server returns the previous processing result if the request data digest is the same, and refuses to process the request if the request data digest is different. The offline authorization data includes server issuance time, offline operation expiration time, synchronization expiration time, maximum validity period and integrity verification information. The validity period of the offline occupancy record is not earlier than the synchronization expiration time. The mobile device determines whether it is still within the time range that allows new offline assignment operations based on the local monotonic timer. If the monotonic timer state is lost, the maximum valid duration is exceeded, or the integrity check fails, the new offline assignment operation is not directly confirmed.

8. The method according to claim 1, characterized in that, When the server establishes offline occupancy records, performs online pre-binding, or performs on-site binding, it uses the corresponding QR code record as a common concurrency control object. The server locks the QR code record in the same database transaction, or performs a conditional update based on the version number of the QR code record, and after obtaining processing permission, confirms again that the QR code is in an idle and unused state and that there is no valid offline occupied record that conflicts with the current operation; If the QR code record has been locked by other operations, the version number does not meet the update conditions, or a valid offline occupied record that conflicts with the current operation already exists, the server will roll back the current operation or select another QR code.

9. A dual-mode QR code binding management system based on dynamic weighting of empty codes, characterized in that, This includes mobile devices, server-side components, and a code pool database. The mobile device includes a first processor and a first memory, wherein the first memory stores the mobile device program; The server includes a second processor and a second memory, wherein the second memory stores the server program; When the mobile application and the server application are executed by the first processor and the second processor respectively, the mobile application, the server application, and the code pool database cooperate with each other to perform the method described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by at least one processor, it enables the mobile terminal, the server terminal, and the code pool database to cooperate with each other to implement the method described in any one of claims 1 to 8.

Images