Anti-counterfeiting method based on unforgeable anti-counterfeiting check after first code scanning binding of user unique identification

Abstract

The application discloses a kind of based on the first code scanning binding of user unique identification tamper-proof check method, belong to anti-counterfeit check technical field.The method obtains anti-counterfeit code and user original identity certificate, generates anonymous binding identification after checking valid;Unbound time realizes first binding by atomic condition writing, and generates event chain digest, check certificate;When meeting preset anchor point generation condition, generate evidence anchor point;Binding time carries out signature verification, anonymous identification comparison and event chain digest continuity check, and additional query log after checking pass;Abnormal time records result, generates review evidence package, and generates or updates review task after exception deduplication, merging, frequency limiting.This scheme combines lock mechanism, digital signature and trusted evidence, realizes first binding unique, subsequent log can be checked and tampering can be found.

Description

Technical Field

[0001] This invention relates to the field of anti-counterfeiting verification technology, and in particular to an anti-counterfeiting verification method based on a user's unique identifier that cannot be tampered with after the initial scan and binding. Background Technology

[0002] Anti-counterfeiting technology is widely used in product packaging, electronic products, and tickets to verify product authenticity and prevent counterfeiting. Common anti-counterfeiting methods include: anti-counterfeiting labels (such as laser holographic labels and color-changing ink), anti-counterfeiting query codes (such as scratch-off digital anti-counterfeiting codes), and QR code anti-counterfeiting. Among these, QR code-based anti-counterfeiting methods are gradually becoming the mainstream solution due to their advantages such as large information capacity, convenient scanning, and low cost. Users can scan the anti-counterfeiting QR code on the product using common scanning tools such as WeChat and Alipay to be redirected to a verification page to obtain authenticity information.

[0003] However, existing QR code-based anti-counterfeiting solutions have significant flaws. Some existing QR code anti-counterfeiting solutions only verify the anti-counterfeiting code itself, or although they record the user information of the person scanning the code, they lack atomic confirmation of the initial binding event, chain-based evidence storage, and anomaly verification mechanisms, allowing the anti-counterfeiting code to be repeatedly scanned and verified by multiple people. This leads to the following technical problems: First, it's impossible to confirm the true first-time verification user. After a genuine product is initially scanned and verified, the anti-counterfeiting code can still be used by others. When subsequent users scan it again, the system usually only accumulates the number of queries, failing to reliably distinguish between the first-time verification user and subsequent users. This weakens the uniqueness of the "one item, one code" verification. Secondly, there is a risk of backend data tampering. Although some systems attempt to record the first user to scan the code, the binding relationship is usually only stored in the business database. System administrators or personnel with database privileges have the motivation and ability to modify the binding relationship, making the final basis for anti-counterfeiting verification unreliable.

[0004] Third, there is a concurrent binding conflict. When multiple users scan the same unbound anti-counterfeiting code at the same time, the system may cause multiple requests to think that they are binding for the first time due to the processing order, or incorrectly record non-first users as first-time binding users, making the subject of the first binding unclear.

[0005] Fourth, there is a risk of user privacy leakage and identity forgery. Directly storing users' unique identifiers such as OpenID, mobile phone number, and client instance identifier will lead to the exposure of sensitive user information once the database is leaked. At the same time, these plaintext identifiers can be easily intercepted and forged by malicious users to bypass verification.

[0006] Fifth, the lack of anomaly verification and log auditing mechanisms means that when inconsistencies occur in the business database records, blockchain evidence digests, or system logs corresponding to the anti-counterfeiting code, the existing system cannot automatically identify and initiate a reliable verification process to determine whether data tampering, concurrent conflicts, or system anomalies have occurred, thus casting doubt on the reliability of the anti-counterfeiting conclusions.

[0007] In addition, existing anti-counterfeiting verification schemes based on QR codes or one-item-one-code mostly focus on judging the validity of anti-counterfeiting codes, retaining scanning records, or counting the number of queries. They lack a collaborative processing mechanism that runs through the entire process from the initial binding to subsequent verification, such as concurrent preemption during the initial scanning and binding process, confirmation of the binding subject, continuous verification of subsequent query logs, and verifiable discovery of data tampering in the background.

[0008] Therefore, there is an urgent need in this field for an anti-counterfeiting verification method that can initially bind the anti-counterfeiting code to the user's anonymous binding identifier, and ensure that the binding relationship is non-transferable and tampering can be verified after the initial scanning and binding, so as to reduce the risk of the anti-counterfeiting code being reused, misused, and the inability to detect tampering with the background data.

[0009] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0010] The purpose of this invention is to provide an anti-counterfeiting verification method that enables the initial binding of an anti-counterfeiting code with a user's anonymous binding identifier, and after the initial code scanning and binding, the binding relationship and subsequent anti-counterfeiting query log tampering behavior can be verified and detected, and the binding relationship cannot be transferred.

[0011] This invention also provides an anti-counterfeiting verification system based on a user's unique identifier that is tamper-proof after the initial QR code binding. The system includes an information acquisition module, an anonymous identifier generation module, an initial binding control module, a pending confirmation processing module, a log chain generation module, an atomic submission module, a bound verification module, an evidence storage module, and an exception handling module. Each module works in conjunction to execute the information acquisition, anonymous identifier generation, initial binding control, pending confirmation processing, log chain generation, atomic submission, bound verification, evidence storage anchor point generation, and exception review processing in the aforementioned anti-counterfeiting verification method.

[0012] In this invention, atomic condition writing is used to determine the first binding subject of the same anti-counterfeiting code; event chain summary and verification certificate are used to connect the first binding log and subsequent query logs to a recalculated and verifiable anti-counterfeiting query log chain; and evidence storage anchor is used to solidify the end event chain summary of the preset log interval to an immutable evidence storage medium. The three are connected in sequence to form an interdependent verification link between the uniqueness of the first binding, the continuity of subsequent logs, and the detectability of background tampering.

[0013] The present invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the above-described method. The present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method.

[0014] The "unique user identifier" referred to in this article does not refer to the plaintext identity identifier of the user directly stored in the business database, but rather to the original identity credential of the user returned by the platform authentication, or the anonymous binding identifier formed by irreversibly anonymizing the original identity credential of the user; in this method, the anonymous binding identifier is used for subsequent binding consistency comparison.

[0015] The term "immutable" as used in this article does not mean that business database records are absolutely unmodifiable at the physical level. Rather, it means that once the binding relationship and corresponding logs are formed, any modification that fails to generate a valid event chain summary and verification certificate according to this method, and fails to generate the corresponding evidence anchor point when the preset anchor point generation conditions are met, will not pass subsequent verification or review, and such modification behavior can be verified and detected.

[0016] To achieve the above objectives, the present invention provides the following solution: A method for tamper-proof verification based on a user's unique identifier, ensuring that the initial QR code binding is unalterable, includes the following steps: Step 1: Obtain the anti-counterfeiting code information submitted by the user after scanning the QR code attached to the product and carrying the anti-counterfeiting code parameters, as well as the original identity certificate of the current user returned after platform authentication; Step 2: First verify the validity of the anti-counterfeiting code: Query the anti-counterfeiting code data table to determine whether the anti-counterfeiting code exists and is in a verifiable state; If it does not exist, or is in a void, frozen, or expired state, it is judged as an abnormal anti-counterfeiting code and enters the abnormal handling process. If the anti-counterfeiting code exists and is in a verifiable state, the corresponding enterprise ID is obtained by parsing the anti-counterfeiting code, and then irreversible anonymization processing is performed based on the identifier of the anti-counterfeiting code and the original identity certificate of the current user to generate the current anonymous binding identifier. Step 3: Query the anti-counterfeiting code data table to determine the current status of the anti-counterfeiting code; the current status includes at least one of unbound, bound pending confirmation, or bound.

[0017] Step 4: When the current state is unbound, execute the initial binding process; When the status is "binding pending confirmation", the retry identification and timeout verification process is initiated. When the status is already bound, proceed with the binding verification process.

[0018] Step 41: Update the status of the anti-counterfeiting code to "binding pending confirmation" using atomic conditional write, and set the lock token and lock expiration time to exclusively lock the first binding qualification; if the atomic write fails, reread the current status of the anti-counterfeiting code; when the atomic conditional write succeeds, the system writes the "binding pending confirmation" status, lock token, and lock expiration time into the anti-counterfeiting code data table, and simultaneously writes a "binding pending confirmation" cache record in the cache, determined by the enterprise ID, anti-counterfeiting code, and current anonymous binding identifier. The cache record includes the lock token, lock expiration time, and processing status, and sets a validity period consistent with the lock expiration time; this cache record is only used to identify repeated scanning or retry requests by the same user within the lock validity period and is not used as the basis for formal binding.

[0019] If the current status after rereading is "bound", proceed to step 5, the bound verification process; if the current status is "bound pending confirmation", query the pending confirmation cache record based on the current anonymous binding identifier, and if the cache exists, the lock token matches the lock token in the anti-counterfeiting code data table, and the timeout has not occurred, determine it as a retry request from the same user, allowing the user to wait for the original binding process to complete or return to the processing status of the original binding process; if the cache record does not exist, the lock token is inconsistent, or the timeout has occurred, reread the lock token, lock expiration time, and processing status in the anti-counterfeiting code data table; if it is confirmed that the anti-counterfeiting code is in the process of compensation rollback, cache write failure processing, or lock timeout recycling, return the waiting or retry result; otherwise, proceed to step 6, the exception handling process; if the current status is "invalidated", "frozen", or "expired", proceed to step 6, the exception handling process.

[0020] Step 42: In the pending confirmation state of the binding, generate an anti-counterfeiting query log to be submitted. The anti-counterfeiting query log includes at least the anti-counterfeiting code, query time, query address, current anonymous binding identifier, query type, and event sequence number. The event sequence number is a monotonically increasing sequence number generated in the corresponding anti-counterfeiting query log chain according to the order in which the logs are successfully committed. When adding a new anti-counterfeiting query log for the first time, the system also appends the logs through a sequential append mechanism to ensure that the event sequence number in the corresponding anti-counterfeiting query log chain is monotonically increasing, and that the previous event chain summary referenced by each log is uniquely determined. The system performs a hash calculation based on the business fields preset to participate in the summary calculation in this log and the event chain summary of the previous committed anti-counterfeiting query log to generate the current event chain summary. Among them, the event chain summary of the first log is directly generated by hashing the business fields preset to participate in the summary calculation in this log. Step 43: The server uses its private key to digitally sign the current event chain digest, generating a verification credential; Step 44: Simultaneously commit the anti-counterfeiting query log and the status update of the anti-counterfeiting code in the same database transaction, and update the status of the anti-counterfeiting code from "bound pending confirmation" to "bound", completing the initial binding; In the implementation using a message queue, the message queue is used to sequentially schedule log append requests for the same enterprise, and the actual log writing and anti-counterfeiting code status update are still completed in the same database transaction.

[0021] When a transaction is committed, the system verifies that the lock token held in the current process is consistent with the lock token in the anti-counterfeiting code data table, and that the lock expiration time has not expired. After successful commit, the anti-counterfeiting code status is updated to "bound," and the corresponding bound pending confirmation cache record is deleted or updated. If the lock expires before the transaction is committed, or if it is confirmed that the transaction has not been committed, has been rolled back, or has failed to commit, the system aborts the commit and performs a compensatory rollback based on the same lock token, restoring the anti-counterfeiting code status to "unbound," releasing the lock token, clearing or invalidating the corresponding bound pending confirmation cache record, and proceeding to step 6 for exception handling. Since the first binding of the anti-counterfeiting query log was not successfully persisted, the condition for generating new log quantity anchor points is not triggered based on the non-persistent logs. If the commit failure event belongs to a preset exception event that can determine the enterprise ID and is associated with the corresponding anti-counterfeiting query log chain, then the anchor point condition judgment can be performed according to step 7 or the review process can be initiated.

[0022] Step 5: When the current state is "bound", execute the bound verification process: Step 51: Verification 1: Signature validity verification: The system reads the anti-counterfeiting query log corresponding to the first binding event based on the anti-counterfeiting code, obtains the stored verification credential and event chain digest, and performs digital signature verification on the event chain digest and verification credential using the public key, certificate, or key management module corresponding to the key version. If the verification result fails, the verification is deemed unsuccessful, and the process proceeds to step 6. If the verification passes, the system recalculates the event chain digest corresponding to the log based on the preset business fields currently stored in the first binding log, according to the event chain digest generation rules. If the log is not the first log, the system calculates the event chain digest based on the event chain digest of the previous logged log. If the log is the first log, the system calculates the event chain digest directly based on the preset business fields currently stored in the log. If the recalculated event chain digest is inconsistent with the event chain digest stored in the log, the verification is deemed unsuccessful, and the process proceeds to step 6. If they are consistent, the verification is deemed successful, and the process proceeds to step 52.

[0023] Step 52: Verification 2: Identity Consistency Verification: If Verification 1 passes, compare the current anonymous binding identifier with the anonymous binding identifier stored in the initial binding anti-counterfeiting query log; if they match, proceed to step 53; if they do not match, check if there is an identity change confirmation record that has been reviewed and confirmed and whose verification credentials are valid; if it exists and the current anonymous binding identifier matches the new anonymous binding identifier in the identity change confirmation record, proceed to step 53; if it does not exist or the verification fails, the verification is deemed unsuccessful, and proceed to step 6. Step 53: Verification 3: Event chain summary continuity and evidence anchor point verification: If the bound identity is consistent, the system queries the anti-counterfeiting query log table and evidence anchor point record table corresponding to the enterprise, and takes the most recent anti-counterfeiting query log determined by consistent read or transaction snapshot at the beginning of this verification as the verification endpoint.

[0024] If there is an anchor record in the anchor record table whose end event number is not greater than the verification endpoint event number and whose anchor record status is successful, then the most recent anchor record is selected as the target anchor record. The system recalculates the anchor digest based on the enterprise ID, start event number, end event number, end event chain digest, anchor generation time, and digest algorithm version in the target anchor record, and verifies the anchor digest with the tamper-proof storage medium based on the on-chain transaction hash or trusted evidence. If the anchor summary of the target evidence anchor record passes the verification by the tamper-proof evidence storage medium, then the end event sequence number and the end event chain summary in the target evidence anchor record are read, and the anti-counterfeiting query log corresponding to the end event sequence number is queried. If the event chain summary stored in the log is inconsistent with the end event chain summary, the verification is deemed unsuccessful, and the process proceeds to step 6. If they are consistent, then the end event sequence number and the end event chain summary are used as the starting point for verification. If there is a new, already-implemented anti-counterfeiting query log after the end event sequence number, then the aforementioned end event chain summary is used as the previous event chain summary, and the event chain summary is recalculated from the next log in the order of event sequence number until the verification endpoint. If there is no new, already-implemented anti-counterfeiting query log after the end event sequence number, then the end event chain summary in the target evidence anchor record is directly compared with the event chain summary stored in the verification endpoint log.

[0025] If there is a record of a successfully stored anchor point, but the verification of the anchor point digest based on the on-chain transaction hash or trusted stored certificate fails, then the verification is deemed unsuccessful, and the process proceeds to step 6.

[0026] If there is no evidence anchor record in the evidence anchor record table with an end event number not greater than the verification endpoint event number and an evidence storage status of successful, the system first determines whether the enterprise has ever generated a successfully stored anchor record. If there is a historical successfully stored record, but the local anchor record is missing, the adjacent anchor interval is broken, the evidence storage certificate cannot be matched, or the corresponding anchor summary cannot be verified from the tamper-proof evidence storage medium, then the anchor record is determined to be abnormal and the abnormal handling process in step 6 is entered. Only when it is confirmed that the enterprise has not generated a successfully stored anchor, the event chain summary is recalculated from the first landed anti-counterfeiting query log in the enterprise's anti-counterfeiting query log table, according to the event sequence number, until the verification endpoint.

[0027] In scenarios where the event chain digest needs to be recalculated, the system synchronously reads the verification credentials, signature algorithm version, and key version stored in the recalculation log, and uses the corresponding public key, certificate, or key management module to verify the signature. If any log verification fails, the event chain digest obtained by the final recalculation is inconsistent with the event chain digest stored in the verification endpoint log, or the aforementioned direct comparison is inconsistent, the verification is deemed to have failed, and the process jumps to step 6; otherwise, the verification passes.

[0028] Step 54: If all three checks above pass, the verification is considered successful. Step 55: After successful verification, the system adds a new anti-counterfeiting query log. This log includes at least the anti-counterfeiting code, query time, query address, current anonymous binding identifier, query type, and event sequence number. When adding a new bound query log, the system appends the log using a sequential append mechanism to ensure that the event sequence number in the corresponding anti-counterfeiting query log chain is monotonically increasing, and that the digest of the previous event chain referenced by each log is uniquely determined. The system performs a hash calculation based on the preset business fields for digest calculation in this log and the event chain digest of the previous committed anti-counterfeiting query log to generate the current event chain digest. The server then digitally signs the current event chain digest using its private key to generate a verification credential. Subsequently, the anti-counterfeiting query log, the current event chain digest, and the verification credential are saved to the anti-counterfeiting query log table. If the current bound query log fails to be committed due to version conflicts, queue concurrency, or temporary write failure, the system will first automatically retry according to a preset number of times or a preset time window. During the retry period, no anti-counterfeiting verification failure conclusion is returned to the user, and the anchor point generation condition judgment described in Step 7 is not triggered. If the system still fails to land after automatic retry, record the system error and proceed to step 6, the error handling process.

[0029] In one optional implementation, the sequential appending can be achieved through at least one of the following methods: First, the append request for the anti-counterfeiting query log corresponding to the anti-counterfeiting query log chain is delivered to the same message queue partition, and the consumer sequentially reads the event sequence number and event chain summary of the previous logged record and writes it into the new log; Second, a transaction lock is acquired on the enterprise log cursor record or the previous log record in the database transaction, and the previous event sequence number and the previous event chain summary are read to generate the current log; Third, the enterprise log cursor is updated through optimistic locking or a version number mechanism. If there is a version conflict, the latest event sequence number and event chain summary are reread and the process is retried; Fourth, the unique constraint between the corresponding anti-counterfeiting query log chain and the event sequence number ensures that the log sequence number within the same anti-counterfeiting query log chain is not duplicated. If a conflict occurs, the event sequence number is reallocated and the process is retried. All of the above methods are used to ensure that the event sequence number in the corresponding anti-counterfeiting query log chain is monotonically increasing, and that the previous event chain summary referenced by this log is uniquely determined.

[0030] Step 6: When the anti-counterfeiting code does not exist, the current status is unverifiable, the initial binding process fails, any verification in the already bound verification process fails, or the appending of the anti-counterfeiting query log, the generation of the event chain summary, or the saving of the verification certificate fails after verification, the abnormal query record is saved to the abnormal query master table, a review evidence package is generated, and a review task or review work order is generated or updated to the review system based on the results of abnormal deduplication, merging, frequency limiting, or risk classification. The unverifiable status includes at least one of being invalid, frozen, or expired.

[0031] For abnormal events that can identify the enterprise ID and link it to the corresponding anti-counterfeiting query log chain, after saving the abnormal query record and generating a verification evidence package, the system can asynchronously trigger an event chain summary continuity check or anchor condition judgment for the enterprise. The verification evidence package also includes at least one of the signature algorithm version, key version, or public key certificate identifier used to verify the verification credential. This trigger does not change the processing conclusion of this abnormal query record and does not write the abnormal query record into the enterprise anti-counterfeiting query log table.

[0032] After the system saves the abnormal query records, it can generate an abnormal record summary and write the abnormal record summary into an audit log that is only appended to the audit log, the verification evidence package, or the audit record associated with the corresponding anti-counterfeiting query log chain, so as to detect the situation where the abnormal query records are deleted, modified, or rearranged.

[0033] Step 7: After the initial binding of logs or the successful landing of already bound query logs, the system determines the current anchor point range based on the end event sequence number of the previous evidence anchor record and the current maximum landed event sequence number. If there is no previous evidence anchor record, the system uses the first landed anti-counterfeiting query log of the enterprise as the starting point of the current anchor point range and determines whether the anchor point generation conditions are met. The preset anchor point generation conditions include the number of newly landed anti-counterfeiting query logs reaching a preset number threshold, the time since the last anchor point generation reaching a preset time period threshold, or an event that can determine the enterprise ID and associate it with the corresponding anti-counterfeiting query log. At least one of the preset abnormal events of the chain; if satisfied, a new anchor record is added to the evidence storage anchor record table. The anchor record includes at least the enterprise ID, start event sequence number, end event sequence number, end event chain summary, anchor generation time, and summary algorithm version. The system performs a hash operation on the enterprise ID, start event sequence number, end event sequence number, end event chain summary, anchor generation time, and summary algorithm version in the anchor record to generate an anchor summary, and writes the anchor summary into an immutable evidence storage medium. After successful evidence storage, the on-chain transaction hash or trusted evidence storage certificate is written back to the evidence storage anchor record table. For abnormal events where the enterprise ID can be determined and associated with the corresponding anti-counterfeiting query log chain, the system can use this as a trigger signal to perform anchor point condition judgment or event chain summary continuity check in advance. However, when actually generating evidence anchor points, the system still uses the anti-counterfeiting query log range that the enterprise has successfully implemented as the object, and the event chain summary continuity check of that log range is a prerequisite. For abnormal query records where the enterprise ID cannot be determined or cannot be associated with the corresponding anti-counterfeiting query log chain, they are only saved to the abnormal query master table and enter the review process, and are not used as abnormal events to trigger anchor point generation judgment. If the event chain summary continuity check fails, a normal evidence anchor point is not generated, and the system proceeds to step 6 for abnormal handling. If evidence storage fails, the evidence storage status of the corresponding anchor point record is marked as pending retry or evidence storage failed, and the anchor point summary and the data to be stored are retained and entered into the retry queue.

[0034] Optionally, the original user identity credentials include at least one of the following: user identity credentials (OpenID or UnionID) assigned by the social application open platform, a user's mobile phone number after hashing, a unique device identifier of the mobile device, or an internal account ID assigned by the verification system; the anonymous binding identifier is generated by HMAC or hash with system key, and uses a salt value associated with enterprise ID, anti-counterfeiting code or product batch as one of the input parameters.

[0035] The original user identity credentials are preferentially based on stable user identifiers returned by the same identity provider. When changes in identity provider policies, application migrations, or changes in user authorization scope cause changes to the original user identity credentials obtained this time, and the current anonymous binding identifier is inconsistent with the anonymous binding identifier in the initial binding log, the system will save this query as an abnormal query record in the abnormal query master table and trigger manual review; if the review confirms that it belongs to the same legitimate user, the system will record the review conclusion or review credentials, but will not cover the anonymous binding identifier, event chain summary, and verification credentials in the initial binding log.

[0036] If the identity is verified to belong to the same legitimate user, the system generates an identity change confirmation record. This record includes an anti-counterfeiting code, the original anonymous binding identifier or its summary, the new anonymous binding identifier or its summary, the reason for the identity provider change, verification credentials, generation time, event number, the previous event chain summary, the current event chain summary, the summary algorithm version, the signature algorithm version, and the verification credentials. This record is then used as an anti-counterfeiting query log for the identity change confirmation type and is linked to the anti-counterfeiting query log chain to which the anti-counterfeiting code belongs. An anomaly verification record can store a reference to or a copy of this identity change confirmation record. During subsequent binding verification, if the current anonymous binding identifier is inconsistent with the anonymous binding identifier in the initial binding log, but consistent with the new anonymous binding identifier in the verified and saved identity change confirmation record, and the verification credentials for this identity change confirmation record pass signature verification, and the event chain summary continuity verification between this identity change confirmation record and its previous logged-in anti-counterfeiting query log passes, then the bound identity is considered consistent. This process does not overwrite or delete the anonymous binding identifier, event chain summary, and verification credentials in the initial binding log.

[0037] Optionally, the atomic condition write method is implemented through at least one of the following storage components: a unique index, transaction lock, or optimistic lock in a relational database; a condition update or version number mechanism in a non-relational database; a distributed lock or SETNX command in a caching system; when the lock expiration time corresponding to the binding pending confirmation state has expired or the binding pending confirmation cache record has expired, the system cleans up the lock token and the binding pending confirmation cache record through database condition update, background inspection task, or compensation mechanism, and restores the anti-counterfeiting code status from binding pending confirmation to unbound status.

[0038] Optionally, the preset abnormal events include at least one of the following: scanning by a non-bound user, verification of the voucher signature failure, inconsistent event chain digest, timeout of binding confirmation, concurrent conflict, non-existent anti-counterfeiting code, invalidated anti-counterfeiting code, frozen or expired anti-counterfeiting code; when a certificate storage failure occurs, the system records the certificate storage failure exception, retains the anchor point data to be stored, enters the retry queue, and triggers manual review after the retry failure reaches the threshold. Among these, abnormal events where the enterprise ID cannot be determined or cannot be associated with the corresponding anti-counterfeiting query log chain are only used for exception recording and review, and are not used as abnormal events to trigger anchor point generation judgment.

[0039] The verification credential, along with the corresponding event chain digest, signature algorithm version, and key version, are stored together in the anti-counterfeiting query log table. When verification or review is already bound, the system obtains the corresponding public key, certificate or key management module according to the signature algorithm version and key version, and verifies the signature on the event chain digest and verification certificate. When the signature verification fails, the query will be saved to the abnormal query summary table and a review evidence package will be generated. Public key verification verifies whether the verification credential is a valid signature generated by the system's private key for the event chain digest.

[0040] Optionally, the tamper-proof evidence storage medium includes at least one of the following: a blockchain network, an append-only log system, a write-once, read-many storage system, or a trusted evidence storage service. The tamper-proof evidence storage medium refers to an evidence storage medium in which, under business agreements or system design constraints, the written evidence data cannot be modified or deleted by regular business permissions, or whose modification or deletion behavior can be detected by auditing.

[0041] Optionally, the verification evidence package includes at least: the request information when the anomaly occurred, the calculation process and result of this verification; when the enterprise ID can be determined by this anomaly query, the verification evidence package also includes a snapshot of the anti-counterfeiting query log related to the enterprise; when there is a corresponding evidence anchor record, the verification evidence package also includes the on-chain transaction hash or trusted evidence certificate corresponding to the evidence anchor record; in manual verification or auditing scenarios, the system recalculates the event chain summary of each log in the corresponding interval based on the start event sequence number and end event sequence number in the evidence anchor record, and compares it with the end event chain summary in the evidence anchor record to determine whether the log business fields have been tampered with and to locate the tampered interval.

[0042] Optionally, the anti-counterfeiting query log chain can be established as an enterprise-level log chain based on the enterprise ID dimension, or as an intra-enterprise partitioned log chain based on at least one combination of enterprise ID and product batch, product series, anti-counterfeiting code segment, business tenant, or activity ID dimensions. Different enterprise-level log chains or intra-enterprise partitioned log chains respectively maintain event sequence numbers, summaries of the previous event chain, and evidence anchor point records. Binding verification, event chain summary recalculation, and anchor point generation are performed on the anti-counterfeiting query log chain to which the corresponding anti-counterfeiting code belongs.

[0043] Optionally, the event chain summary is generated as follows: The business fields pre-selected for summary calculation in this anti-counterfeiting query log are hashed with the event chain summary of the previous anti-counterfeiting query log to obtain the current event chain summary; the first anti-counterfeiting query log does not concatenate the previous event chain summary, but directly hashes the business fields pre-selected for summary calculation in this anti-counterfeiting query log. The pre-selected business fields for summary calculation include at least the anti-counterfeiting code, query time, current anonymous binding identifier, and event sequence number, and may include one or more of the query address and query type; the first binding log and the already bound query log use the same set of fields for summary calculation, and the log type is distinguished by the query type field; for fields that do not exist or are not applicable in a certain business scenario, the system writes a pre-selected null value or a fixed placeholder value before participating in the summary calculation; the order, encoding format, and null value rules of the fields participating in the summary calculation are determined by the summary algorithm version. The event sequence number is determined by the log cursor, monotonically increasing sequence, or equivalent sequential append mechanism of the corresponding anti-counterfeiting query log chain when the log is successfully committed. Database auto-incrementing IDs can only be used as one of the implementation methods for event sequence numbers, and must be consistent with the successful commit order of anti-counterfeiting query logs within the same anti-counterfeiting query log chain. Unused empty numbers due to transaction rollback or unused pre-allocated sequence numbers are not considered discontinuous anti-counterfeiting query log chains or discontinuous adjacent evidence storage anchor point intervals. Discontinuous anti-counterfeiting query log chains refer to situations where the event sequence numbers or event chain summaries corresponding to successfully committed logs cannot be continuously connected according to the successful log commit order. Discontinuous adjacent evidence storage anchor point intervals refer to situations where the start and end event sequence numbers corresponding to adjacent evidence storage anchor point records cannot continuously cover the successfully committed log intervals of the corresponding anti-counterfeiting query log chain.

[0044] Optionally, the method further includes: in the state of pending binding confirmation, if a valid pending binding confirmation cache record is found based on the current anonymous binding identifier, and the lock token in the cache record is consistent with the lock token in the anti-counterfeiting code data table, then the repeated scanning request is allowed to wait for the original binding process to complete or return to the processing status of the original binding process, and the first binding log is not generated repeatedly; if no valid cache record is found, the cache record has expired, or the lock token is inconsistent, then the lock token, lock expiration time, and processing status in the anti-counterfeiting code data table are reread; if it is confirmed that it is in the process of compensation rollback, cache write failure processing, or lock timeout recycling processing, then the waiting or retry result is returned; otherwise, the binding is rejected and an abnormal record is generated; different users scanning the code are directly rejected and an abnormal record is triggered.

[0045] Optionally, the irreversible anonymization process uses a salt value associated with the enterprise ID, anti-counterfeiting code, or product batch, as well as a system key maintained by the key management module, and records the anonymization algorithm version, salt value identifier, and key version. During subsequent verification and comparison, the system recalculates the current anonymity binding identifier based on the salt value associated with the anti-counterfeiting code, the algorithm version, and the key version, and supports calling historical key versions for backtracking matching in key rotation scenarios. The system key used for irreversible anonymization is configured hierarchically according to at least one dimension of enterprise, brand, or business tenant, and a key version is set.

[0046] Optionally, the sequential append mechanism includes at least one of the following: a message queue partitioned by enterprise ID, a database transaction lock, an optimistic lock, an enterprise log cursor, a distributed sequence number service, a single-threaded consumer, and a unique constraint between the enterprise ID or the identifier of the enterprise's internal partitioned log chain and the event sequence number.

[0047] Optionally, the enterprise-level anti-counterfeiting query log chain can be further divided into enterprise-internal partition log chains according to at least one combination of enterprise ID and product batch, product series, anti-counterfeiting code segment, business tenant or activity ID; each enterprise-internal partition log chain maintains the event sequence number, the summary of the previous event chain and the evidence anchor record, and still belongs to the anti-counterfeiting query log chain of the corresponding enterprise.

[0048] Compared with the prior art, the present invention has the following beneficial effects: This invention uses atomic condition writing and a token locking mechanism to ensure that only one user can successfully complete the initial binding in high-concurrency scenarios. This effectively reduces the race condition problem caused by multiple requests scanning the same anti-counterfeiting code at the same time, making the subject of the initial binding clear and verifiable.

[0049] This invention generates an event chain summary for each successfully logged anti-counterfeiting query log, and uses the server's private key to digitally sign the event chain summary to generate a verification credential. Any log tampering that fails to obtain a valid signature and consistent evidence storage will disrupt the continuity of the event chain or the signature and anchor point verification results, thereby ensuring the authenticity and integrity of the bound records.

[0050] This invention generates anchor summary based on the end-of-event summary and anchor interval information according to preset conditions, and writes the anchor summary into an immutable evidence storage medium such as blockchain and trusted evidence storage service. Even if the log data in the business database is tampered with, the system can still detect the corresponding tampering risk and help locate the tampered interval through anchor point verification, post-anchor log recalculation, and complete anchor interval recalculation during daily incremental verification, event chain recalculation, or manual review / auditing. This significantly reduces the risk of not being able to detect tampering of backend data.

[0051] This invention performs irreversible anonymization processing on the user's original identity credentials, storing only an irreversible anonymous binding identifier in the system. Even if the database is leaked, the user's real identity information cannot be obtained. At the same time, combined with the platform's authentication mechanism, it reduces the risk of bypassing verification after identity credentials are forged.

[0052] In this invention, each successfully logged anti-counterfeiting query log is connected to a recalculated and verifiable event chain. The system ensures that the log content and log order can be verified through event chain summaries and verification credentials. Furthermore, the system solidifies the end event chain summary of a specified log interval into an immutable evidence storage medium through phased evidence storage anchors, thereby enabling the detection of subsequent deletion, insertion, rearrangement, or tampering of logs in the background.

[0053] This invention automatically captures verification failure events, generates a verification evidence package containing request information, calculation process and results, and includes relevant log snapshots and evidence certificates when it can be associated with enterprise ID or evidence anchor records. It also supports closed-loop manual verification, providing a strong guarantee for the final reliability of anti-counterfeiting conclusions.

[0054] Once the anonymization algorithm parameters and their version information are used to generate the anonymous binding identifier, they should remain traceable throughout the anti-counterfeiting code's lifecycle and must not be changed without a record. If key rotation is required, the system retains historical key versions and attempts to calculate using the current version and historical versions in turn when comparing the anonymous identifier. If either match is successful, the identity is considered consistent.

[0055] By using evidence anchors, the full event chain recalculation is transformed into incremental verification starting from the most recent trusted checkpoint. This reduces the computational load of each verification in scenarios involving massive anti-counterfeiting query logs, while retaining the ability to fully recalculate the anchor interval in review or audit scenarios, thus balancing verification efficiency and tamper detection capabilities.

[0056] This invention does not simply use atomic condition writing, event chain digests, digital signatures, and evidence anchors in parallel. Instead, it forms an interdependent trusted chain during the initial binding and subsequent verification of the same anti-counterfeiting code: atomic condition writing first ensures the uniqueness of the initial binding qualification of the same anti-counterfeiting code, preventing multiple scanning requests from simultaneously obtaining the initial binding identity; the initial binding log and subsequent query logs are then connected to the anti-counterfeiting query log chain to which the anti-counterfeiting code belongs through event chain digests and verification credentials, enabling the binding subject, query order, and log business fields to be recalculated and verified; evidence anchors further solidify the phased end event chain digest to an immutable evidence storage medium, allowing subsequent modifications, deletions, insertions, or rearrangements of logs in the background to be detected through anchor verification and event chain recalculation. Therefore, a single lock mechanism can only solve the problem of concurrent initial binding but cannot detect subsequent data tampering, a single event chain lacks external trusted solidification evidence, and a single evidence storage mechanism cannot guarantee the uniqueness of the initial binding subject; this invention, through the synergistic cooperation of the above technical means, simultaneously solves the problems of initial binding uniqueness, subsequent log continuity, and verifiable detection of background tampering.

[0057] In summary, this invention reduces the risk of anti-counterfeiting codes being reused, misused, and tampered with, and significantly improves the security, credibility, and user experience of the anti-counterfeiting system. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 This is a schematic diagram of the anti-counterfeiting verification method based on the user's unique identifier, which is tamper-proof after the first scan and binding. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] Example 1: The following is in conjunction with the appendix Figure 1 The present invention will be further described in detail below. This embodiment is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention.

[0062] This embodiment uses the establishment of an anti-counterfeiting query log chain based on the enterprise ID as an example for illustration; in other embodiments, the anti-counterfeiting query log chain can also be established as an internal enterprise partition log chain based on at least one combination dimension of enterprise ID and product batch, product series, anti-counterfeiting code segment, business tenant or activity ID.

[0063] This embodiment relies on the implementation of a one-item-one-code anti-counterfeiting system for commercial goods. The system deploys application layer services, a business database (MySQL), a distributed cache Redis, a key management service, and a blockchain evidence storage node (an immutable evidence storage medium). It is designed for end consumers using WeChat / Alipay QR code scanning. Software developers in this field can deploy and implement the system completely by following the steps below. The overall process corresponds to Figure 1 in the accompanying drawings of the specification.

[0064] S1. Initial System Configuration: Basic parameter configuration: Preset log quantity threshold of 500 entries, anchor generation cycle of 24 hours, and binding lock expiration time uniformly configured to 15 minutes; pre-configure server-side RSA asymmetric keys, with private keys managed by the key management module, hardware security module, or trusted execution environment and set to be non-exportable, and public keys used for signature verification; configure independent salt value identifiers and key versions according to the registered enterprises, with the corresponding system keys maintained by the key management module, and the anonymization algorithm selected is HMAC-SHA256.

[0065] The preset quantity threshold and preset time period threshold can be configured by the system according to business needs. The 500 items and 24 hours in this embodiment are just examples.

[0066] Data table initialization: The system creates an anti-counterfeiting code data table, an anti-counterfeiting query log table maintained by enterprise level, an abnormal query summary table, and a proof anchor point record table. Each enterprise corresponds to an independent anti-counterfeiting query log table or an equivalent enterprise-level log sub-table. The abnormal query summary table is used to uniformly store abnormal query records. For abnormal records where the enterprise ID can be determined, the enterprise ID is written, or an enterprise association field uniquely mapped to the enterprise ID is written. For abnormal records where the enterprise ID cannot be determined, the anti-counterfeiting code, request information, and abnormal reason are retained, but they do not participate in the anti-counterfeiting query log chain and anchor point interval calculation. The proof anchor point record table records fields such as enterprise ID, start event sequence number, end event sequence number, end event chain summary, anchor point generation time, summary algorithm version, anchor point summary, proof status, on-chain transaction hash, or trusted proof certificate. Redis enables an expiration eviction policy to store bound pending confirmation cache.

[0067] S2, Step 1: Obtain QR code scanning parameter information: Consumers use WeChat to scan the QR code on the outer packaging of a product, which contains anti-counterfeiting parameters. The front end redirects to the anti-counterfeiting service interface, where the system parses the parameters carried in the QR code and extracts the product's anti-counterfeiting code. Simultaneously, after completing authentication with the WeChat Open Platform, the system obtains the user's OpenID returned by the WeChat Open Platform, thus completing the reception of two types of information.

[0068] S3, Step 2: Validation of anti-counterfeiting code + generation of anonymous binding identifier.

[0069] The server queries the anti-counterfeiting code data table to verify that the received anti-counterfeiting code exists and is in a verifiable state. If the anti-counterfeiting code does not exist: proceed directly to step 6, exception handling, and mark the illegal anti-counterfeiting code; If the anti-counterfeiting code exists but is invalid, frozen, or expired, proceed directly to step 6 for exception handling and mark it as an unverifiable anti-counterfeiting code. If the anti-counterfeiting code is genuine and verifiable: the system queries or parses the corresponding enterprise ID based on the anti-counterfeiting code, and uses the enterprise ID, anti-counterfeiting code number, user OpenID and the salt value identifier corresponding to the enterprise as input fields, calls the system key maintained by the key management module, and generates the current anonymous binding identifier based on HMAC-SHA256. The original OpenID is not stored on the ground.

[0070] S4, Step 3: Check the current status of the anti-counterfeiting code: Query the status field of the anti-counterfeiting code in the anti-counterfeiting code data table. The statuses are divided into unbound, bound pending confirmation, bound, invalid, frozen or expired, etc. The branch flow is as follows: Unbound → enter the first binding (step 4); Bound pending confirmation → perform lock token, cache and timeout verification; Bound → enter the bound verification (step 5); Invalid, frozen or expired status directly enter step 6 exception handling.

[0071] First branch: Anti-counterfeiting code not bound, proceed to step 4 for the first binding process.

[0072] Step 41: Atomic conditional write locking, dual-path storage in database and cache: Atomic conditional writes are implemented using MySQL optimistic locking: SQL conditional update is executed, and the anti-counterfeiting code status is changed to bound pending confirmation only when the original status is unbound. A random 32-bit string is generated as the lock token, and the lock expiration time is set to the current time + 15 minutes.

[0073] Atomic write failure scenario: Reread the real-time status of the anti-counterfeiting code; After rereading, the status is "bound": Proceed to step 5 for bound verification. After rereading, the status is "Binding Pending Confirmation": Query the Redis "Binding Pending Confirmation" cache using "Enterprise ID + Anti-counterfeiting Code + Current Anonymous Binding Identifier" as the key; If the status after rereading is another unverifiable status: proceed to step 6 for exception handling.

[0074] If the cache exists, the cached lock token matches the database, and the expiration time has not expired: if the same user is repeatedly retries scanning the code, wait for the original binding process to complete or return to the processing status of the original binding process, and do not generate the first binding log repeatedly; when returning the waiting result, the system sets a single waiting timeout, a maximum number of retries, or a backoff interval. If the original binding process processing status is not obtained after exceeding the threshold, the system returns a busy or later retry result, and records the temporary query status, and does not directly determine that the scanning of the code by a non-bound user has failed or that the anti-counterfeiting verification has failed; If the cache does not exist, the token is mismatched, or it has expired, the system rereads the lock token, lock expiration time, and processing status from the anti-counterfeiting code data table. If it is confirmed that it is in the process of compensation rollback, cache write failure processing, or lock timeout recycling, it returns a waiting or retry result and does not generate a new first binding log. Otherwise, it is judged as a concurrent conflict, non-bound user scanning, or abnormal scanning, and enters the abnormal handling process in step 6.

[0075] Successful atomic write scenario: 1. Anti-counterfeiting code data table is stored locally: it is bound to the pending confirmation status, the lock token, and the lock expiration time; 2. Redis write binding pending confirmation cache: The cache fields include lock token, lock expiration time, and processing status. The cache validity period is consistent with the lock expiration time of 15 minutes. The cache is only used to identify repeated scanning by the same user within the validity period and is not used as the basis for formal binding to take effect.

[0076] If the Redis write to the pending confirmation cache fails, the system will perform a compensation rollback based on the current lock token, clear the pending confirmation status, lock token and lock expiration time in the database, and record this request as a system exception or enter the retry process.

[0077] During the compensation rollback execution, the system verifies the current lock token and anti-counterfeiting code status through database condition updates or transaction methods. When a concurrent request reads a binding pending confirmation status but does not find a valid binding pending confirmation cache record, it first rereads the lock token, lock expiration time, and processing status from the anti-counterfeiting code data table. If it is confirmed that the anti-counterfeiting code is in the process of compensation rollback or cache write failure processing, it returns a waiting or retry result and does not directly determine it as a concurrent conflict or abnormal code scanning.

[0078] Step 42: Generate anti-counterfeiting query logs and event chain summaries.

[0079] 1. Added anti-counterfeiting query log: Fields include anti-counterfeiting code, current server query time, user IP query address, current anonymous binding identifier, query type, event sequence number, signature algorithm version, and key version; when adding a new anti-counterfeiting query log for the first time, the system will deliver the log append request to the same message queue partition according to the enterprise ID, or combine database transaction locks, optimistic locks, and unique event sequence number constraints to perform sequential appending, ensuring that the event sequence number in the enterprise's anti-counterfeiting query log table is monotonically increasing, and that the digest of the previous event chain referenced by this log is uniquely determined; 2. Event chain summary generation rules: The first anti-counterfeiting query log in the enterprise's anti-counterfeiting query log table: SHA256 hash is performed on the business fields that are preset to participate in the summary calculation in this log to generate the first event chain summary; the first log does not concatenate the previous summary.

[0080] Non-first log: The business fields that are preset to participate in the summary calculation in this log are concatenated with the event chain summary stored in the previous log and then hashed again to generate the current event chain summary.

[0081] Step 43: Sign the private key to generate a verification credential.

[0082] The key management module is invoked to retrieve the system private key based on the current signature algorithm version and key version. An RSA signature is then performed on the current event chain digest generated in step 42 to generate a verification credential. The verification credential, signature algorithm version, and key version are then synchronously stored in this anti-counterfeiting query log.

[0083] Step 44: Transaction commit, lock validity check, state change.

[0084] The newly added anti-counterfeiting query log and the anti-counterfeiting code status change will be encapsulated into the same database transaction: Pre-transaction verification: The lock token held in the current process is consistent with the lock token stored in the database, and the lock has not expired. The transaction is allowed to be committed only if both conditions are met; if either condition is not met, the commit is directly aborted and the compensation rollback and exception handling process is entered. Submission successful: The anti-counterfeit code status has been updated from "Bound but not confirmed" to "Bound". The corresponding "Bound but not confirmed" cache in Redis has been deleted, completing the first binding of the anti-counterfeit code. If a lock expires before a transaction is committed, or if it is confirmed that the transaction has not been committed, has been rolled back, or has failed to commit, the system aborts the commit and performs a compensatory rollback based on the same lock token. This restores the anti-counterfeiting code status to an unbound state, releases the lock token, clears the corresponding binding confirmation cache, and proceeds to step 6 for exception handling. Since the initial anti-counterfeiting query log binding was not successfully persisted, the system does not trigger a new log quantity anchor point generation condition based on this unsuccessful log posting. If the commit failure event is a preset exception event that can determine the enterprise ID and is associated with the corresponding anti-counterfeiting query log chain, then step 7 can be used to perform anchor point condition judgment or proceed to the review process.

[0085] For anti-counterfeit codes that remain in the pending confirmation state for an extended period due to service anomalies, network anomalies, or task interruptions, the background inspection task will perform timeout recycling based on the lock expiration time, restoring their state to unbound and clearing the corresponding lock token and cache records.

[0086] The system can also set up offline reconciliation tasks to periodically check the consistency between the anti-counterfeiting code status, anti-counterfeiting query logs, bound pending confirmation cache records, and event chain summaries. When it is found that the anti-counterfeiting code has been in the bound pending confirmation state for a long time, the log has not been successfully committed, or the cache record has expired, it will automatically recover or mark the abnormality based on the lock expiration time, the existence of the log, and the transaction commit result, and generate a review record.

[0087] Second branch: Anti-counterfeiting code is already bound, proceed to step 5 for three-layer verification process.

[0088] Step 51: Verification 1: Signature Validity Verification Retrieve the first-time binding anti-counterfeiting query log corresponding to the first binding based on the anti-counterfeiting code, and extract the verification credential and first-time binding event chain digest stored in the log; use the public key, certificate or key management module corresponding to the key version of the log to verify the event chain digest and verification credential; if the verification fails, the verification fails and the process jumps to step 6. If the signature verification passes, the event chain summary corresponding to the log is recalculated according to the event chain summary generation rules: if the log is the first anti-counterfeiting query log of the enterprise, the event chain summary is recalculated based on the preset business fields currently stored in the log; if the log is not the first anti-counterfeiting query log of the enterprise, the event chain summary is recalculated based on the preset business fields currently stored in the log and the event chain summary of the previous landed anti-counterfeiting query log; if the recalculated event chain summary is inconsistent with the event chain summary stored in the log, the verification is deemed to have failed, and the process proceeds to step 6; if they are consistent, verification one is deemed to have passed, and the process proceeds to verification two.

[0089] Step 52: Verification 2: Identity Binding Consistency Verification Compare the current anonymous binding identifier generated by this scan with the anonymous binding identifier stored in the initial binding anti-counterfeiting query log: Inconsistent identifiers: The system first checks whether there is an identity change confirmation record that has been manually reviewed and confirmed and whose verification credentials are valid; if it exists and the current anonymous binding identifier is consistent with the new anonymous binding identifier in the record, then verification two passes and proceeds to verification three; if it does not exist or the verification fails, it is treated as an abnormal situation where a non-bound user scans a code or identity credential changes are pending review, the verification fails and proceeds to step 6, the abnormal handling process. The identifiers are completely consistent: Verification 2 passes, proceed to Verification 3.

[0090] Step 53: Verification 3: Event chain summary continuity and evidence anchor point verification.

[0091] The system queries the anti-counterfeiting query log table and the evidence storage anchor record table corresponding to the enterprise, and uses the most recent anti-counterfeiting query log that has been committed and determined by consistent read or transaction snapshot at the start of this verification as the verification endpoint.

[0092] If the anchor record table contains an anchor record whose end event number is not greater than the verification endpoint event number and whose anchor record status is successful, then the most recent anchor record is selected as the target anchor record. The system recalculates the anchor digest based on the enterprise ID, start event number, end event number, end event chain summary, anchor generation time, and digest algorithm version in the target anchor record, and verifies the anchor digest against the tamper-proof storage medium based on the on-chain transaction hash or trusted evidence. If the anchor digest verification passes, the system queries the anti-counterfeiting query log corresponding to the end event number of the target anchor record and compares the event chain summary stored in the anti-counterfeiting query log with the end event chain summary. If they do not match, the verification fails, and the process proceeds to step 6. If they match, the end event number and the end event chain summary are used as the starting point for verification. If a new, already-implemented anti-counterfeiting query log exists after the ending event number, the aforementioned end event chain summary is used as the previous event chain summary, and the event chain summary is recalculated from the next log in the order of event numbers until the verification endpoint; if no new, already-implemented anti-counterfeiting query log exists after the ending event number, the end event chain summary in the target evidence anchor record is directly compared with the event chain summary stored in the verification endpoint log.

[0093] If there is a record of a successfully stored anchor point, but the verification of the anchor point digest based on the on-chain transaction hash or trusted stored certificate fails, then the verification is deemed unsuccessful, and the process proceeds to step 6.

[0094] If there is no evidence anchor record in the evidence anchor record table with an end event sequence number not greater than the verification endpoint event sequence number and an evidence storage status of successful, the system first determines whether the enterprise has ever generated a successfully stored anchor record. If there is a historical successfully stored record, but the local anchor record is missing, the adjacent anchor interval is broken, the evidence storage certificate cannot be matched, or the corresponding anchor summary cannot be verified from the tamper-proof evidence storage medium, then it is determined that the anchor record is abnormal and enters the abnormal handling process in step 6. The historical successfully stored record can be determined by the evidence storage index associated with the enterprise ID, anchor sequence number, on-chain transaction hash, or trusted evidence storage certificate in the tamper-proof evidence storage medium, or by independent audit logs and anchor generation flow records.

[0095] Only if it is confirmed that the enterprise has not yet generated a successful evidence storage anchor point, will the event chain summary be recalculated starting from the first successfully stored anti-counterfeiting query log in the enterprise's anti-counterfeiting query log table, in the order of event number, until the verification endpoint.

[0096] In scenarios where the event chain digest needs to be recalculated, the system synchronously reads the verification credentials, signature algorithm version, and key version stored in the recalculation log, and uses the corresponding public key, certificate, or key management module to verify the signature. If any log verification fails, the event chain digest obtained by the final recalculation is inconsistent with the event chain digest stored in the verification endpoint log, or the aforementioned direct comparison is inconsistent, the verification is deemed to have failed, and the process jumps to step 6; otherwise, the verification passes.

[0097] Step 54: Verification result determination.

[0098] Verification 1, Verification 2, and Verification 3 have all passed the checks, and this anti-counterfeiting verification is legally successful. Step 55: After successful verification, the system adds a new anti-counterfeiting query log entry, writing the anti-counterfeiting code, query time, query address, current anonymous binding identifier, query type, and event sequence number. The system performs a hash calculation based on the preset business fields for summary calculation in this log entry and the event chain summary of the previous committed anti-counterfeiting query log entry, generating the current event chain summary. After generating the verification credential, it is saved to the anti-counterfeiting query log table. In this embodiment, the system submits the request to append the bound query log to the same message queue partition according to the enterprise ID. The consumer reads the event sequence number and event chain summary of the previous committed log entry sequentially and writes the business fields of this log entry, the new event sequence number, the current event chain summary, and the verification credential into the same database transaction. If the bound query log entry fails to be committed due to version conflict, queue concurrency, or temporary write failure, the system first performs automatic retry according to a preset number of times or a preset time window. During the retry, no anti-counterfeiting verification failure conclusion is returned to the user, and the anchor point generation condition judgment described in step 7 is not triggered. If the automatic retry still fails to commit, a system exception is recorded, and the exception handling process in step 6 is entered. After the query logs have been successfully bound and stored, the system will also perform the anchor point generation condition judgment described in step 7.

[0099] Optional additional services in this embodiment: After the binding verification is passed and the anti-counterfeiting query log is successfully appended, the system generates a business processing record based on the anti-counterfeiting code, the current anonymous binding identifier, and the business activity ID, and triggers the distribution of points or displays product traceability information according to the business processing record; wherein, the same anti-counterfeiting code generates only one points distribution record under the same business activity.

[0100] Step 6: Unified exception handling process across the entire chain.

[0101] If the anti-counterfeiting code is missing or in an unverifiable state in step 2, the initial binding process fails or there is a concurrency conflict in step 4, any layer of verification fails in step 5, or if the anti-counterfeiting query log appending, event chain summary generation, or verification credential saving fails in step 55, the following will be executed uniformly: 1. Store all information about this anomaly in the anomaly query master table; 2. Automatically package and generate a verification evidence package: The verification evidence package includes at least the request information when the anomaly occurred, the calculation process and result of this verification; when the enterprise ID can be determined by this anomaly query, the verification evidence package also includes a snapshot of the anti-counterfeiting query log related to the enterprise; when there is a corresponding evidence anchor record, the verification evidence package also includes the on-chain transaction hash or trusted evidence certificate corresponding to the evidence anchor record. For repeated abnormal queries with the same anti-counterfeiting code, the same anomaly type, the same source address, the same device fingerprint, or within the same time window, the system can perform deduplication, merging, frequency limiting, or risk classification processing; a new manual review work order is generated only when the number of anomalies, risk score, or scope of impact reaches a preset threshold, and abnormal queries that do not reach the threshold are only appended to existing abnormal records or review evidence packages.

[0102] 3. When the number of anomalies, risk scores, or scope of impact reach a preset threshold and a new manual review work order is generated, the work order is pushed to the backend management terminal to initiate the manual review process. Reviewers determine whether the anomaly is due to fraudulent scanning, data tampering, or a system anomaly based on the evidence package. In manual review or audit scenarios, the system can recalculate the event chain summary of each log within the specified interval based on the start and end event numbers in the evidence anchor record, and compare it with the end event chain summary in the same anchor record to help determine whether the log business fields within the anchor interval have been tampered with and to pinpoint the tampered interval.

[0103] Step 7: Anchor point generation condition judgment and evidence storage anchor point writing.

[0104] When the cumulative number of newly added anti-counterfeiting query logs of the same enterprise since the last evidence storage anchor point record reaches 500, or when the time since the last anchor point generation of the enterprise is 24 hours, the system determines that the regular anchor point judgment conditions have been met. When a pre-defined abnormal event occurs that can identify the enterprise ID and link it to the corresponding anti-counterfeiting query log chain, the system can perform anchor point condition judgment or event chain summary continuity check in advance, but will not include the abnormal query record in the enterprise's anti-counterfeiting query log range. When actually generating evidence anchor points, the system still uses the anti-counterfeiting query log range that the enterprise has successfully implemented as the object, and the success of the event chain summary continuity check of that log range is a prerequisite; if the enterprise ID cannot be determined or cannot be linked to the corresponding anti-counterfeiting query log chain, it will only be saved to the abnormal query master table and enter the review process, without triggering the anchor point generation condition judgment; if the enterprise does not have a previous evidence anchor point record, the implementation time of the enterprise's first unanchored log will be used as the starting time of the anchor point generation cycle. The system determines the start and end event numbers of the current anchor interval using a consistent read or transaction method. If there is no previous evidence-based anchor record, the event number of the first logged anti-counterfeiting query log of the enterprise is used as the start event number of the current anchor interval. If there is a previous evidence-based anchor record, the log after the end event number of the previous evidence-based anchor record is used as the start event number of the current anchor interval. The system uses the largest logged event number read when the current anchor is generated as the end event number, and after the end event number is determined, subsequent logs are not included in the current anchor interval. If no new implemented anti-counterfeiting query logs exist within the specified interval, no new anchor record is added; only the triggered event is recorded. If the triggering reason is an abnormal event, the review process begins. If new implemented anti-counterfeiting query logs exist within the specified interval, an anchor record is added to the anchor record table. The anchor record includes fields such as Enterprise ID, Start Event Sequence Number, End Event Sequence Number, End Event Chain Summary, Anchor Generation Time, Summary Algorithm Version, Anchor Summary, Evidence Storage Status, and On-Chain Transaction Hash or Trusted Evidence Storage Certificate. The system performs hash operations on the Enterprise ID, Start Event Sequence Number, End Event Sequence Number, End Event Chain Summary, Anchor Generation Time, and Summary Algorithm Version in the anchor record to generate an anchor summary, which is then written to the blockchain or trusted evidence storage service. After successful evidence storage, the system writes the on-chain transaction hash or trusted evidence storage certificate back to the anchor record table. If the anchor point summary has been submitted to the immutable evidence storage medium but the on-chain transaction hash or trusted evidence storage certificate has not yet been successfully written back to the anchor point record table, the system marks the anchor point record as pending confirmation or pending write-back, and performs an idempotent query on the immutable evidence storage medium using the anchor point unique identifier, anchor point summary, enterprise ID, and event sequence number range. If the corresponding evidence storage record is found, the on-chain transaction hash or trusted evidence storage certificate is written back and updated to successful evidence storage; if the corresponding evidence storage record is not found, it enters the retry queue. If evidence storage fails, the evidence storage status of the anchor point record is marked as pending retry or evidence storage failed, the anchor point summary and pending evidence storage data are retained, and it enters the retry queue; manual review is triggered after the retry failure threshold is reached.

[0105] Implementation results: When multiple users scan the same unbound anti-counterfeiting code simultaneously during high concurrency, only the first request that successfully acquires the database lock will enter the initial binding process. Other user requests will be judged as concurrent conflicts or abnormal scanning. If the same user scans the code repeatedly within the lock's validity period, the original binding process will be returned according to the binding pending confirmation cache record. One item, one code, unique first binding. For the initial binding logs, incremental logs after the anchor point involved in this verification, or if the evidence anchor point records or evidence certificates are tampered with, inconsistencies will occur in the signature verification, event chain summary recalculation, evidence anchor point record verification, or end event chain summary comparison in step 5; for other historical log business fields within the anchored interval that have been tampered with, the system can discover and assist in locating the tampered interval through anchor interval recalculation in manual review or audit scenarios. The system never stores users' plaintext phone numbers or WeChat OpenIDs; it only stores irreversible anonymous identifiers, thus mitigating the risk of user privacy leaks.

[0106] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for anti-counterfeiting verification based on a user's unique identifier, ensuring that the initial QR code binding is tamper-proof, characterized in that... include: Obtain the anti-counterfeiting code information submitted by the user after scanning the QR code attached to the product and carrying anti-counterfeiting code parameters, as well as the original identity certificate of the current user returned after platform authentication; Verify that the anti-counterfeiting code exists and is in a verifiable state. If it exists and is in a verifiable state, then parse the corresponding enterprise ID according to the anti-counterfeiting code and generate the current anonymous binding identifier based on the anti-counterfeiting code and the current user's original identity certificate. When the anti-counterfeiting code is in an unbound state, the anti-counterfeiting code is updated to a bound pending confirmation state through atomic conditional writing, and a lock token and lock expiration time are written to exclusively reserve the first binding qualification; When the anti-counterfeiting code is in the binding pending confirmation state, the return of the waiting result, retry result or abnormal query record is determined based on the lock token, the lock expiration time, the processing status corresponding to the binding pending confirmation state, the current anonymous binding identifier and the corresponding temporary status record. If the lock token is valid and has not expired, an initial binding anti-counterfeiting query log is generated. The initial binding anti-counterfeiting query log includes at least log information for identifying the anti-counterfeiting code, the binding subject, the log type, and the log order. The log order is represented by an event sequence number, which is a monotonically increasing sequence number determined in the order in which the anti-counterfeiting code is successfully logged within the anti-counterfeiting query log chain. If a previous anti-counterfeiting query log exists, the current event chain summary is generated based on the preset business fields of this log and the previous event chain summary; if no previous anti-counterfeiting query log exists, the current event chain summary is generated directly based on the preset business fields of this log. Using the server's private key, or by invoking a controlled private key in a key management module, hardware security module, or trusted execution environment, digitally sign the current event chain digest to generate a verification credential. The initial binding anti-counterfeiting query log and the status change of the anti-counterfeiting code are submitted synchronously in the same atomic commit process; if the atomic commit is successful, the anti-counterfeiting code is updated to the bound state; if the lock is detected to have expired before the atomic commit, or the atomic commit fails and it is confirmed that the initial binding anti-counterfeiting query log has not been successfully committed, the anti-counterfeiting code status is rolled back to the unbound state, the lock token is released, and the corresponding binding pending confirmation cache record is cleared or invalidated. When the anti-counterfeiting code is in a bound state, the anti-counterfeiting query log chain to which the anti-counterfeiting code belongs is verified. This verification includes verifying the signature of the verification credential, comparing the anonymous binding identifier, and verifying the continuity of the event chain summary. The event chain summary continuity verification includes recalculating the event chain summary based on preset business fields of the already logged anti-counterfeiting query logs and comparing it with the event chain summary stored in the corresponding anti-counterfeiting query log. The comparison of the anonymous binding identifier includes: comparing the current anonymous binding identifier with the anonymous binding identifier stored in the first-time binding anti-counterfeiting query log. The process involves comparing the two; if they are inconsistent and there exists an identity change confirmation record used to record the correspondence between the original anonymous binding identifier and the new anonymous binding identifier and has been verified, then the current anonymous binding identifier is compared with the new anonymous binding identifier in the identity change confirmation record; if the current anonymous binding identifier is consistent with the anonymous binding identifier stored in the first binding anti-counterfeiting query log, or consistent with the new anonymous binding identifier in the identity change confirmation record, then the anonymous binding identifier comparison is determined to be successful; if there is a usable evidence storage anchor record, the evidence storage anchor record is used as a trusted checkpoint for recalculation verification and comparison; After the verification is successful, the anti-counterfeiting query log is appended and the corresponding event sequence number, new event chain summary and verification certificate are generated; When the anti-counterfeiting query log is successfully logged and the preset anchor point generation conditions are met, a summary of the evidence storage anchor point is generated and written to an immutable evidence storage medium independent of the business database. If the anti-counterfeiting code does not exist or is in an unverifiable state, or if the verification of the voucher fails, the anonymous binding identifier comparison fails, the event chain summary continuity verification fails, or the evidence storage anchor verification fails, an abnormal query record is generated and the abnormal handling process is initiated. The term "immutable" means that after the binding relationship and the corresponding anti-counterfeiting query log are formed, any modification that fails to generate a legitimate event chain summary and verification certificate in accordance with the method described in this claim, and fails to generate a corresponding evidence anchor point when the preset anchor point generation conditions are met, will not pass subsequent verification or review, and such modification behavior can be verified and detected.

2. The anti-counterfeiting verification method based on the user's unique identifier for initial QR code binding that cannot be tampered with afterward, as described in claim 1, is characterized in that... The original user identity credentials include at least one of the following: user identity credentials returned after authentication by a third-party platform or verification system, authenticated mobile phone number digest, trusted device identifier, or internal account ID assigned by the verification system; The anonymous binding identifier is generated via HMAC or a hash with a system key, and uses the salt value associated with the enterprise ID, anti-counterfeiting code, or product batch as one of the input parameters. The irreversible anonymization process uses the salt value associated with the enterprise ID, anti-counterfeiting code, or product batch, the system key maintained by the key management module, and records the anonymization algorithm version, salt value identifier, and key version. During subsequent verification and comparison, the system recalculates the current anonymous binding identifier based on the salt value associated with the anti-counterfeiting code, the algorithm version, and the key version, and supports calling historical key versions for backtracking matching in key rotation scenarios.

3. The anti-counterfeiting verification method based on the user's unique identifier for initial QR code binding that cannot be tampered with afterward, as described in claim 1, is characterized in that... The atomic conditional write method is implemented through at least one of the following storage components: a unique index, transaction lock, or optimistic lock in a relational database; a conditional update or version number mechanism in a non-relational database; or a distributed lock or SETNX command in a caching system. When the lock expiration time corresponding to the pending confirmation state has expired, or the pending confirmation cache record has expired, the system cleans up the lock token and the pending confirmation cache record through database condition updates, cache expiration, background inspection tasks, or compensation mechanisms. If the initial binding log is not successfully persisted, the anti-counterfeiting code status is restored from pending confirmation to unbound. The validity period of the pending confirmation cache record is consistent with the lock expiration time. After the lock expires, the system cleans up the corresponding cache record or invalidates it. The atomic condition writing is based on the status field and lock token field in the anti-counterfeiting code data table as the final judgment basis. The caching system is only used for retry identification and temporary status query. If a valid binding confirmation cache record is found based on the current anonymous binding identifier, and the lock token in the cache record is consistent with the lock token in the anti-counterfeiting code data table, then the repeated scanning request is allowed to wait for the original binding process to complete or return to the processing status of the original binding process, and the first binding log will not be generated again. If no valid cache record is found, the cache record has expired, or the lock token is inconsistent, the lock token, lock expiration time, and processing status in the anti-counterfeiting code data table will be reread. If it is confirmed that the process is in the process of compensation rollback, cache write failure processing, or lock timeout recycling, the result of waiting or retry will be returned. Otherwise, the binding will be refused and an abnormal record will be generated. Different users will be directly rejected when scanning the code and an abnormal record will be triggered.

4. The anti-counterfeiting verification method based on the user's unique identifier for initial QR code binding that cannot be tampered with afterward, as described in claim 1, is characterized in that... The preset anchor point generation conditions include at least one of the following: the number of newly added and implemented anti-counterfeiting query logs since the previous evidence storage anchor point reaches a preset number threshold, the time since the last anchor point generation reaches a preset time period threshold, or a preset abnormal event occurs that can determine the enterprise ID and associate it with the corresponding anti-counterfeiting query log chain. The preset abnormal events include at least one of the following: non-bound user scanning code, verification certificate signature failure, inconsistent event chain digest, binding confirmation timeout, concurrent conflict, anti-counterfeiting code not existing, anti-counterfeiting code invalidated, frozen or expired. Anomalies where the enterprise ID cannot be determined or cannot be associated with the corresponding anti-counterfeiting query log chain are only used for anomaly recording and manual review, and are not used as anomalies that trigger the judgment of anchor point generation conditions. The immutable evidence storage medium includes at least one of a blockchain network, an append-only log system, a write-once-read-many storage system, or a trusted evidence storage service, used to ensure that the written evidence storage data cannot be modified or deleted by regular business permissions, or that such modification or deletion can be detected by audit. The evidence storage anchor point is associated with the same anti-counterfeiting query log chain and is used to write the end event chain summary of the anti-counterfeiting query log chain within a preset range into the tamper-proof evidence storage medium.

5. The anti-counterfeiting verification method based on the user's unique identifier for initial QR code binding that cannot be tampered with afterward, as described in claim 1, is characterized in that... The event chain summary is generated as follows: The business fields pre-selected for summary calculation in this anti-counterfeiting query log are hashed with the event chain summary of the previous anti-counterfeiting query log to obtain the current event chain summary. The pre-selected business fields for summary calculation include at least the anti-counterfeiting code, query time, current anonymous binding identifier, and event sequence number, and may include one or more of the query address and query type. The first-time binding log and already bound query logs use the same set of fields for summary calculation, and the log type is distinguished by the query type field. For fields that do not exist or are not applicable in a certain business scenario, the system writes a pre-selected null value or a fixed placeholder value before participating in the summary calculation. The order, encoding format, and null value rules of the fields participating in the summary calculation are determined by the summary algorithm version. The first anti-counterfeiting query log does not concatenate the previous event chain summary. The event sequence number is determined by the log cursor, monotonically increasing sequence, or equivalent sequential append mechanism of the corresponding anti-counterfeiting query log chain when the log is successfully submitted. Database auto-incrementing IDs can only be used as one of the implementation methods for event sequence numbers, and should... Ensure that the order of successful submissions of anti-counterfeiting query logs within the same anti-counterfeiting query log chain is consistent. Unused empty numbers resulting from transaction rollback or unused pre-allocated sequence numbers are not considered discontinuous in the anti-counterfeiting query log chain or discontinuous in adjacent evidence anchor point intervals. Discontinuous anti-counterfeiting query log chain refers to the inability of successfully committed event numbers or event chain summaries to be continuously connected according to the order of successful log commits. Discontinuous adjacent evidence anchor point intervals refer to the inability of the start and end event numbers corresponding to adjacent evidence anchor point records to continuously cover the successfully committed log intervals of the corresponding anti-counterfeiting query log chain. The anti-counterfeiting query log chain is an enterprise-level log chain established by enterprise ID, or an enterprise-internal partitioned log chain established by at least one combination of enterprise ID and product batch, product series, anti-counterfeiting code segment, business tenant, or activity ID. Each anti-counterfeiting query log chain maintains an event number, a summary of the previous event chain, and evidence anchor point records. The binding verification, event chain summary recalculation, and anchor point generation are performed on the anti-counterfeiting query log chain to which the corresponding anti-counterfeiting code belongs.

6. The anti-counterfeiting verification method based on the user's unique identifier for initial QR code binding that cannot be tampered with afterward, as described in claim 1, is characterized in that... The method further includes generating a verification evidence package, which at least includes the request information when the anomaly occurred, the calculation process and result of this verification; when the enterprise ID can be determined by this anomaly query, the verification evidence package also includes a snapshot of the anti-counterfeiting query log related to the enterprise; when a corresponding evidence storage anchor record exists, the verification evidence package also includes the on-chain transaction hash or trusted evidence storage certificate corresponding to the evidence storage anchor record; the verification evidence package also includes at least one of the signature algorithm version, key version or public key certificate identifier used to verify the verification certificate; the private key used by the server to generate the verification certificate is hosted by the key management module, hardware security module or trusted execution environment and is set to be non-exportable; the server calls the key management module, hardware security module or trusted execution environment to sign the event chain digest to generate the verification certificate; after the system saves the anomaly query record, it generates an anomaly record digest and writes the anomaly record digest into an audit log that is only appended, the verification evidence package or the audit record associated with the corresponding anti-counterfeiting query log chain, to detect the situation where the anomaly query record is deleted, modified or rearranged.

7. The anti-counterfeiting verification method based on the user's unique identifier for initial QR code binding that cannot be tampered with afterward, as described in claim 1, is characterized in that... When the current anonymous binding identifier is inconsistent with the anonymous binding identifier stored in the initial binding anti-counterfeiting query log, and is confirmed to belong to the same legitimate user after verification, the system generates an identity change confirmation record. The identity change confirmation record includes an anti-counterfeiting code, the original anonymous binding identifier or its summary, the new anonymous binding identifier or its summary, the reason for the identity provider change, the verification certificate, the generation time, the event sequence number, the previous event chain summary, the current event chain summary, the summary algorithm version, the signature algorithm version, and the verification certificate. It is also connected to the anti-counterfeiting query log chain to which the anti-counterfeiting code belongs as an anti-counterfeiting query log of the identity change confirmation type. In subsequent binding verifications, if the current anonymous binding identifier is consistent with the new anonymous binding identifier in the identity change confirmation record, and the verification certificate of the identity change confirmation record passes the signature verification, and the event chain summary continuity verification between the identity change confirmation record and its previous landed anti-counterfeiting query log passes the verification, then the bound identity is considered consistent.

8. A counterfeit-proof verification system based on a user's unique identifier that cannot be tampered with after the initial scan and binding, characterized in that, include: The system comprises an information acquisition module, an anonymous identifier generation module, an initial binding control module, a pending confirmation processing module, a log chain generation module, an atomic submission module, an already bound verification module, an evidence storage module, and an exception handling module; the system is used to execute the anti-counterfeiting verification method based on the user's unique identifier, which is tamper-proof after the initial QR code binding, as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the anti-counterfeiting verification method based on the user's unique identifier after the first scan binding, which is tamper-proof.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the anti-counterfeiting verification method based on the user's unique identifier that is tamper-proof after the first scan binding, as described in any one of claims 1 to 7.

Images