A digital copyright authentication method

Abstract

The application provides a digital copyright right confirmation method, relates to the technical field of digital copyright right confirmation and blockchain storage, and comprises the following steps: obtaining right confirmation information and rule data of a digital copyright to be confirmed, and generating structured compliance data through AI semantic processing; compiling a non-deterministic compliance evaluation result into deterministic decision logic based on rule mapping data, and determining a process state by combining a confidence degree through an on-chain state machine; and writing a decision track, a compilation track and a state conversion log into a Merkle tree and a blockchain in association, so as to realize continuous determination, associated storage, history tracing and integrity verification of a right confirmation process.

Description

Technical Field

[0001] This application belongs to the field of digital copyright confirmation and blockchain evidence storage technology, specifically involving a method for digital copyright confirmation. Background Technology

[0002] As the scale of online creation, dissemination, and trading of digital content continues to expand, digital copyright registration is gradually shifting from traditional offline registration to electronic and online methods. The registration process typically involves reviewing information such as the issuing entity's qualifications, copyright ownership, scope of authorization, and potential conflicts of rights. A traceable electronic record of the review process and results is created to facilitate subsequent verification of the basis for registration and the processing procedures.

[0003] In existing technologies, one type of solution involves a centralized copyright registration agency receiving works and related supporting materials, and generating copyright registration results after review. Another type of solution involves writing the hash value of the work file or contract file into the blockchain, using on-chain records to prove that specific data existed at the corresponding point in time. Some other solutions combine electronic signatures, electronic contracts, and artificial intelligence processing to conduct compliance analysis or value assessment of qualification materials and copyright information, and electronically store the corresponding review results or reports.

[0004] However, in the process of digital copyright confirmation using artificial intelligence, the review results typically include non-deterministic judgments such as risk level, ownership clarity, and confidence level. Existing evidence preservation methods tend to focus on preserving the final conclusion, resulting in a weak correlation between the review conclusion and the materials, rules, and processing procedures on which it is based. When there are incomplete materials or unclear rule matching results, the confirmation process may be transferred to manual processing or interrupted, making it difficult to maintain a continuous correspondence between data and status generated at different processing stages. Furthermore, when the review rules or processing procedures are revised, the specific processing basis corresponding to historical confirmation results also presents difficulties in verification and reproduction. Summary of the Invention

[0005] This application provides a method for confirming digital copyright to solve the aforementioned technical problems.

[0006] The technical solution adopted in this application is as follows: This application provides a method for digital copyright confirmation, characterized in that it is executed by a confirmation processing device connected to a blockchain network, and the method includes: Obtain the rights confirmation information corresponding to the digital copyright to be confirmed and the rule data applicable to the current rights confirmation process, and initialize the Merkle tree corresponding to the current rights confirmation process; AI semantic processing is performed on the rights confirmation information and rule data to generate structured compliance data, which includes compliance assessment results, confidence information, and decision trajectory data corresponding to the compliance assessment results. Based on the rule data, the nondeterministic compliance assessment results in the structured compliance data are compiled into deterministic rules to obtain deterministic judgment logic that can be executed by the on-chain state machine, and compilation trajectory data corresponding to the deterministic rule compilation is generated. The on-chain state machine is invoked to determine the current rights confirmation process state based on the execution result of the deterministic judgment logic and the confidence information, and the progress of the current rights confirmation process is controlled according to the process state. Based on the decision trajectory data, compilation trajectory data, and process status, a state transition log is generated. The hash of the state transition log is added to the Merkle tree as a leaf node to update the Merkle root. In the same chain state transition transaction, the state data corresponding to the process status, the log data or log summary corresponding to the state transition log, and the updated Merkle root are synchronously written to form an association and evidence record between the process status and the corresponding decision trajectory data and compilation trajectory data.

[0007] According to one embodiment of this application, the rights confirmation information includes issuer qualification information and digital copyright information associated with the current rights confirmation process, and the rule data includes an audit rule base and rule mapping data corresponding to the audit rule base; The AI ​​semantic processing of the rights confirmation information and rule data includes: Based on the review rule base, semantic retrieval and rule matching are performed on the issuer qualification information and digital copyright information to determine the rule references and material references corresponding to the matters to be reviewed; Based on the rule references, material references, and corresponding rule matching results, the compliance assessment results, confidence information, and decision trajectory data are generated, and the compliance assessment results, confidence information, and decision trajectory data are associated to form the structured compliance data; The rule mapping data is used to perform the deterministic rule compilation on the structured compliance data.

[0008] According to one embodiment of this application, the decision trajectory data includes rule references, material references, rule hit results, intermediate judgment results, and corresponding confidence information that are respectively associated with the compliance assessment results; According to the process of generating the compliance assessment results, the rule references, material references, rule hit results and intermediate judgment results are sequentially associated to form a structured decision trajectory associated with the corresponding compliance assessment results.

[0009] According to one embodiment of this application, the rule mapping data includes a mapping relationship between compliance assessment items and data types, operational relationships, judgment criteria, criticality, priority, repairability, and status impact; The step of performing deterministic rule compilation on the non-deterministic compliance assessment results in the structured compliance data based on the rule data includes: Determine the target mapping relationship from the rule mapping data to each compliance assessment item in the structured compliance data; Based on the data types, operational relationships, and judgment criteria in the target mapping relationship, the corresponding compliance assessment items are converted into judgment predicates; The decision predicates are organized based on their criticality and priority to generate the deterministic decision logic; The conversion relationship between the structured compliance data, the rule mapping data used, and the generated deterministic judgment logic is recorded to form the compilation trajectory data.

[0010] According to one embodiment of this application, the determination criteria include a determination threshold for the compliance assessment item and a state boundary for the confidence information; The rule data also includes threshold configurations with configuration versions, and the threshold configurations are respectively associated with digital rights types and review rule base versions; Based on the digital copyright type to be confirmed and the version of the review rule base applicable to the current confirmation process, the judgment threshold and state boundary corresponding to the current confirmation process are determined from the threshold configuration, and the adopted threshold configuration version is associated with the compilation trajectory data and recorded.

[0011] According to one embodiment of this application, the process states corresponding to the on-chain state machine include a fully passed state, a conditionally passed state, and a failed state. The process status of the current rights confirmation process, determined based on the execution result of the deterministic judgment logic and the confidence information, includes: The criticality and repairability of each decision predicate are determined based on the rule mapping data, and the decision predicates are divided into critical decision predicates and non-critical decision predicates based on the criticality. When both the key determination predicate and the non-key determination predicate satisfy their corresponding determination conditions, and there are no undetermined determination predicates, and the confidence information reaches the state boundary corresponding to the fully passed state, the current rights confirmation process is determined to be in the fully passed state. If there are no irreparable key judgment predicates that do not meet the judgment conditions, and the confidence information reaches the state boundary corresponding to the condition pass state, then if there are repairable but undetermined key judgment predicates, key judgment predicates that do not meet the judgment conditions but are repairable, or non-key judgment predicates that do not meet the judgment conditions or are undetermined, or if both the key judgment predicates and the non-key judgment predicates meet the corresponding judgment conditions and the confidence information does not reach the state boundary corresponding to the fully pass state, then the current rights confirmation process is determined to be in the condition pass state. When the confidence information does not reach the state boundary corresponding to the condition pass state, or when there is an irreparable key judgment predicate that does not meet the judgment condition, or when there is an irreparable and undetermined key judgment predicate, the current rights confirmation process is determined to be in the non-pass state. The fully passed state and the conditionally passed state are used to control the current rights confirmation process to continue, while the failed state is used to control the current rights confirmation process to terminate.

[0012] According to one embodiment of this application, when the current rights confirmation process is in the condition passed state, a condition list is generated based on at least one of the following: repairable undetermined key judgment predicates, key judgment predicates that do not meet the judgment conditions but are repairable, non-key judgment predicates that do not meet the judgment conditions or are undetermined, and confidence information that reaches the state boundary corresponding to the condition passed state but does not reach the state boundary corresponding to the fully passed state. The evidence storage data corresponding to the condition list is added to the Merkle tree, and the current rights confirmation process is controlled to continue to advance. In response to receiving supplementary confirmation information corresponding to the condition list, the confirmation information corresponding to the current confirmation process is updated based on the supplementary confirmation information, and the AI ​​semantic processing, deterministic rule compilation and process status determination are re-executed based on the updated confirmation information to obtain the updated process status. A new state transition log is generated based on the updated process state and appended to the Merkle tree, so that the new state transition log and the state transition log corresponding to the condition form a state branch that is related before and after.

[0013] According to one embodiment of this application, after each determination of the current rights confirmation process status, a status transition log is generated based on the previous process status, the current process status, the reference information of the structured compliance data that triggered this status determination in the Merkle tree, and the execution result of the deterministic determination logic. The hash value corresponding to the state transition log is added to the Merkle tree as a leaf node, and the updated Merkle root is determined based on the Merkle tree after the leaf node is added; Write the state data corresponding to the current process state, the log data corresponding to the state transition log, and the updated Merkle root in the same on-chain state transition transaction. If any write operation in the on-chain state transition transaction fails, all write operations in the on-chain state transition transaction are rolled back.

[0014] According to one embodiment of this application, the compilation trajectory data further includes a compiler version identifier and a rule mapping data version identifier used to perform the deterministic rule compilation; Version registration data is generated for different versions of compiler and rule mapping data. The version registration data is used to associate the corresponding version identifier, content hash, storage location index and effective time, and the version registration data is written into the blockchain network. When verifying the historical rights confirmation process, the corresponding compiler version identifier and rule mapping data version identifier are determined based on the compilation trajectory data of the historical rights confirmation process. The historical compiler and historical rule mapping data are obtained based on the corresponding version registration data and their content hashes are verified. Based on the verified historical compiler and historical rule mapping data, the structured compliance data corresponding to the historical rights confirmation process is recompiled using deterministic rules. The regenerated deterministic judgment result is compared with the evidence storage result of the historical rights confirmation process.

[0015] According to one embodiment of this application, after the current rights confirmation process is completed, the target Merkle root of the Merkle tree corresponding to the current rights confirmation process and the leaf node corresponding to the evidence storage data to be verified are obtained, and a Merkle proof path from the leaf node to the target Merkle root is generated according to the position of the leaf node in the Merkle tree. The Merkle proof path includes sibling node hashes and node position information used to determine the hash calculation relationship from the leaf node to the target Merkle root; When verifying the evidence data to be verified, the leaf node hash is determined based on the evidence data to be verified, and the verification Merkle root is calculated level by level according to the Merkle proof path. The verification Merkle root is then compared with the target Merkle root.

[0016] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows: This application uses AI semantic processing on the rights confirmation information and rule data corresponding to the digital copyright to be confirmed, generating structured compliance data including compliance assessment results, confidence information, and decision trajectory data. Then, the non-deterministic compliance assessment results are compiled into deterministic rules to form deterministic judgment logic that can be executed by an on-chain state machine. The process status is determined based on the execution result of the deterministic judgment logic and the confidence information. At the same time, the decision trajectory data, compilation trajectory data, and process status are linked and stored in a Merkle tree, so that the AI ​​processing results can be traced along the data chain of "input data - compliance assessment - deterministic compilation - status determination - on-chain storage", thereby improving the data consistency and verifiability between different processing stages in the digital copyright confirmation process.

[0017] This application performs semantic retrieval and rule matching between the issuer's qualification information, digital copyright information and the review rule base, and establishes a connection between rule references, material references, rule hit results, intermediate judgment results and confidence information and the corresponding compliance assessment results. This ensures that each compliance assessment result has a clear data source and rule basis, avoiding the problem of only saving the final AI conclusion and making it difficult to restore the processing basis. This allows subsequent verification to locate the corresponding input materials and review rules along the decision trajectory.

[0018] This application establishes a mapping relationship between compliance assessment items and data types, operational relationships, judgment benchmarks, criticality, priority, repairability, and state impact through rule mapping data. It then converts nondeterministic compliance assessment results into judgment predicates according to the mapping relationship, and generates deterministic judgment logic based on the criticality and priority of each judgment predicate. This can convert AI outputs in the form of continuous numerical values, probabilities, or scores into on-chain judgment conditions with clear execution boundaries, so that subsequent state judgments are based on a unified and repeatable deterministic logic.

[0019] This application determines the corresponding judgment threshold and status boundary based on the type of digital copyright to be confirmed and the currently applicable review rule base version, and associates the threshold configuration version with the compilation trajectory data. This allows the judgment benchmark to match the specific copyright type and review rule version, while avoiding subsequent rule updates from overwriting the judgment conditions used in historical rights confirmation. This enables the current processing results and historical processing results to be interpreted and verified according to their respective applicable configuration versions.

[0020] This application uses an on-chain state machine to classify the current rights confirmation process into three states: fully passed, conditionally passed, and failed, based on the criticality, repairability, execution result, and confidence level of the decision predicates. This allows the entire rights confirmation process to be terminated directly when there are repairable critical decision items, undetermined or unmet non-critical decision items, or when all decision predicates meet the conditions but the confidence level has not yet reached the state boundary corresponding to the fully passed state. In particular, the conditionally passed state can continue to perform allowed subsequent processing while retaining matters to be corrected or reviewed, thereby maintaining the continuity of state transitions and evidence storage data during the rights confirmation process.

[0021] In the condition-passed state, this application generates a condition list based on the judgment predicates that are not determined or do not meet the conditions and / or the confidence information of the state boundary corresponding to the fully passed state. After receiving supplementary confirmation information, it re-executes AI semantic processing, deterministic rule compilation and process state determination, and continues to append the updated state transition data to the original Merkle tree. This allows the state before correction or review, the supplementary materials and the state after re-judgment to form a state branch with sequential correlation, rather than directly overwriting the original review result, thereby completely preserving the evolution process of the confirmation state as the correction or review data changes.

[0022] This application generates a state transition log after each state determination and writes the current state data, the state transition log, and the updated Merkle root into the same on-chain state transition transaction. If any write operation fails, all writes in the transaction are revoked. This can avoid the situation where the process state has been updated but the corresponding state log or Merkle root has not been updated synchronously, thus maintaining transaction-level consistency between the on-chain state and the decision trajectory.

[0023] This application records the compiler version and rule mapping data version in the compilation trajectory data, and establishes the association between version identifier, content hash, storage location index and effective time respectively. During historical verification, the historical compiler and historical rule mapping data are obtained and verified based on the version registration data. Then, the deterministic rule compilation is re-executed using historical structured compliance data. This can reproduce the actual processing environment and judgment logic used in historical rights confirmation, so that subsequent rule or program upgrades do not affect the traceability of the basis for processing existing rights confirmation results.

[0024] This application generates a Merkle proof path, including sibling node hashes and node position information, based on the leaf node position corresponding to the evidence data to be verified. The Merkle root is then recalculated and verified level by level according to the path, and compared with the target Merkle root. This allows verification of the inclusion relationship and integrity between the target evidence data and the corresponding Merkle tree without re-acquiring all the data in the entire rights confirmation process. At the same time, by retaining different Merkle root versions, historical evidence data can still be verified based on the corresponding historical root after new rights confirmation or transaction data is added later. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating the method provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of this application will be described in detail below with reference to specific embodiments. However, it should be understood that the following description is only intended to enable those skilled in the art to understand this application more clearly and completely, and is not intended to limit the scope of protection of this application. Unless otherwise specified, the following embodiments and technical features of each embodiment can be combined with each other.

[0027] In the detailed description below, for ease of explanation, the digital copyright confirmation data, rule data, deterministic rule compilation, on-chain state transitions, and Merkle tree evidence preservation process involved in this application are described in detail. Those skilled in the art should understand that one or more embodiments may be implemented by omitting some non-essential implementation details without departing from the core technical concept of this application.

[0028] The terms “comprising”, “including”, etc., as used herein are used to indicate the presence of the described features, steps, data, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, data, operations, and / or components.

[0029] The "current rights confirmation process" used here can be understood as a complete processing instance for a digital copyright to be confirmed, starting from process creation, through rights confirmation information collection, AI semantic processing, deterministic rule compilation, on-chain state determination, and evidence storage, until the process ends. Different digital copyrights can establish corresponding rights confirmation processes, and each rights confirmation process can have a corresponding process identifier so that various types of data generated by the rights confirmation process can be associated according to the process identifier.

[0030] The term "rights confirmation information" as used herein refers to information related to the review and confirmation process of digital copyrights to be confirmed. In some embodiments, rights confirmation information may include publisher qualification information, digital copyright information, copyright ownership materials, and signing information related to the current rights confirmation process. Rights confirmation information is not limited to a fixed set of fields, as long as it can serve as input for AI semantic processing and be used to obtain the corresponding compliance assessment results.

[0031] The "rule data" used here represents the audit rules adopted in the current rights confirmation process and the data used to convert AI output into deterministic judgment logic. Rule data may include an audit rule base, rule mapping data, and threshold configurations related to rule judgment. Specifically, the audit rule base may include digitized laws and regulations, audit standards, and corresponding rules; the rule mapping data defines the conversion relationship between compliance assessment items and judgment predicates in structured compliance data.

[0032] The “structured compliance data” used herein refers to a data set formed by processing qualification information, copyright information, and matching rule data using AI semantics, which can be directly read by subsequent deterministic rule compilers. In one implementation, structured compliance data can be represented using compliance rule vectors (CRVs), but this application does not limit the use of specific names, specific file formats, or fixed numbers of fields.

[0033] The "decision trajectory data" used here does not refer to the hidden reasoning process that is not accessible within the AI ​​model, but rather to the processing records that are explicitly generated by the system during AI semantic processing and can be saved and verified. For example, decision trajectory data may include cited rules, cited materials, rule hit results, intermediate judgment results, evaluation conclusions, and corresponding confidence information. By saving these explicit processing records, a traceable data relationship can be established between the compliance assessment results and the data on which those compliance assessment results were based.

[0034] The "deterministic rule compilation" used here refers to the process of converting the non-deterministic compliance assessment results output by AI semantic processing into deterministic decision logic that can be executed by the on-chain state machine, according to the rule mapping data. The non-deterministic compliance assessment results can be represented as continuous numerical values, probability values, confidence levels, risk scores, clarity scores, or other assessment results that require rule interpretation to obtain a definite state; the deterministic decision logic can be represented as Boolean decision predicates and logical relationships formed by multiple decision predicates.

[0035] The "on-chain state machine" used here is used to determine the current status of the rights confirmation process based on the execution result of the deterministic judgment logic and the confidence information. In a specific embodiment, the on-chain state machine can be a three-state confidence state machine, which includes at least a fully passed state, a conditionally passed state, and a failed state.

[0036] It should be noted that the "fully passed status, conditionally passed status, and failed status" mentioned in this application mainly refer to the three judgment statuses output during the compliance judgment stage. The actual rights confirmation process may also include process initialization, agreement signing completion, structured compliance data generation completion, compilation completion, value assessment completion, contract signing completion, and certificate generation completion, among other process stage markers. These process stage markers are used to indicate which processing step the current rights confirmation process has reached, and belong to a different dimension of data from the three compliance judgment statuses; therefore, the two should not be confused.

[0037] For example, the current process can simultaneously have a process stage identifier of "deterministic compilation completed" and a compliance judgment status of "condition passed"; after the correction is completed, the process stage can still continue to advance, while the compliance judgment status can be updated from the condition passed status to the fully passed status or the failed status.

[0038] The "Merkle tree" used here is employed for cryptographic aggregation of data generated at different stages of the current rights confirmation process. The data to be notified can use its own hash value or the hash value of the notified data formed from that data as the leaf nodes of the Merkle tree, and the Merkle root is obtained through hierarchical hash calculation. Therefore, the leaf nodes, Merkle proof paths, and the Merkle root can be used to verify whether the corresponding notified data belongs to the data set corresponding to the current rights confirmation process.

[0039] Furthermore, some embodiments of this application employ a data storage method that combines on-chain and off-chain methods. For large-volume files such as qualification documents, original copyright documents, contract documents, and AI reports, they can be stored in off-chain storage space, while the corresponding content hash, storage location index, or content addressing identifier is stored on-chain. For structured compliant data and value assessment data, the structured full text can be stored off-chain, and its hash value can be stored on-chain. For data used for status confirmation or integrity verification, such as process status codes, status transition log summaries, version registration information, and Merkle roots, they can be directly written to the blockchain or recorded through on-chain events.

[0040] Therefore, unless otherwise specified, the term "data on-chain" as used below can refer to writing the data itself into the blockchain, or it can refer to writing the hash value, data index and / or related summary that can uniquely verify the data content into the blockchain. It does not require writing the full text of a large original file directly into the blockchain.

[0041] The digital copyright confirmation method provided in this application is described in detail below.

[0042] In some embodiments, this application provides a method for digital copyright confirmation. This method can be executed by a confirmation processing device, which is communicatively connected to a blockchain network.

[0043] The rights confirmation processing device can be implemented by a server, server cluster, cloud computing node, or other computing device with data processing and network communication capabilities. This device can invoke AI semantic processing programs and deterministic rule compilers deployed on local or remote computing devices, and can call smart contracts deployed in the blockchain network through the blockchain node interface.

[0044] In one specific embodiment, the digital copyright confirmation environment may further include an issuer terminal, an off-chain data storage device, a rule-based data storage device, and a blockchain network. The issuer terminal is used to submit confirmation information and, when authorization is required, to digitally sign the data to be submitted; the off-chain data storage device is used to store large volumes of original files and structured data; and the blockchain network primarily stores hash data, state data, version data, and Merkle roots for verification.

[0045] From the perspective of the executing entity, the following methods and steps can all be initiated and organized by the rights confirmation processing device. The issuing terminal, AI processing program, deterministic compiler, blockchain smart contract, and off-chain storage device participate in the current rights confirmation process as data sources, called processing units, on-chain execution objects, or data storage objects, respectively, without changing the data processing relationship in this application method where the rights confirmation processing device is the main executing entity.

[0046] like Figure 1 As shown, specifically, the digital copyright confirmation method provided in this application may include steps S110 to S150.

[0047] Step S110: Obtain the rights confirmation information corresponding to the digital copyright to be confirmed and the rule data applicable to the current rights confirmation process, and initialize the Merkle tree corresponding to the current rights confirmation process.

[0048] In this embodiment, after receiving a request for confirmation of rights for a digital copyright to be confirmed, the confirmation processing device can create a current confirmation process for the digital copyright to be confirmed and assign a unique process identifier to the current confirmation process.

[0049] Process identifiers can serve as the basis for linking different processed data within the current rights confirmation process. For example, subsequently generated structured compliance data, compilation trajectory data, state transition logs, Merkle tree versions, and blockchain transaction records can all be associated with this process identifier.

[0050] In some embodiments, when an issuer participates in the digital copyright confirmation process for the first time, they can also complete identity registration first.

[0051] Specifically, asymmetric key pairs can be generated by the issuer's terminal, digital wallet, or key management device. The private key is stored by the issuer's terminal or the corresponding key management device, and the rights confirmation processing device does not need to directly store the issuer's private key. The issuer can generate a corresponding identity identifier based on the key pair, and then perform on-chain notarization after calculating the hash of the data corresponding to the identity identifier.

[0052] For example, the identity identifier can use a decentralized identity identifier (DID). The DID document can record information such as the public key, identity type, and authentication method. Subsequent operations requiring authorization from the issuer can be performed by the issuer's terminal signing data that includes at least a process identifier, a processing step identifier, an input data hash, and a random number (nonce), and the signature can be verified by the corresponding smart contract.

[0053] The nonce is used to distinguish different requests for the same process data, reducing the possibility of duplicate submission of signature data. For processes that need to prevent the same input from being executed repeatedly, an idempotent identifier can be formed based on "process identifier + processing step identifier + input data hash". If the same idempotent identifier is detected to already have a valid processing result, the existing processing result can be returned without generating the same state transition again.

[0054] It should be noted that DID is an optional identity implementation method and is not intended to require this application to adopt a specific identity specification.

[0055] In some embodiments, when the current rights confirmation process is established, the issuer can also sign the digital copyright distribution framework agreement through the issuer's terminal. The rights confirmation processing device acquires the signed agreement data, signature data, and corresponding time information, and forms agreement evidence data.

[0056] Subsequently, the corresponding Merkle tree is initialized for the current rights confirmation process.

[0057] In this embodiment, the Merkle tree is used to progressively aggregate key data requiring evidence storage according to the data generation order of the current rights confirmation process. Each time a new piece of evidence storage data is obtained, it can be normalized and its leaf node hash calculated. This leaf node is then appended to the Merkle tree, and the affected Merkle paths are recalculated based on the newly added leaf node to obtain a new Merkle root.

[0058] As one specific implementation, the data to be added to the Merkle tree is serialized according to the agreed-upon normalized serialization rules and then hashed. For example, the JSON normalization method corresponding to JCS / RFC8785 can be used to serialize structured JSON data to reduce the possibility of different hashes arising from differences in field arrangement or character representation of the same logical data.

[0059] The hash algorithm can be SHA-256, Keccak-256, or other cryptographic hash algorithms that can achieve the corresponding integrity verification function.

[0060] In a specific Merkle tree construction method, a first predefined identifier can be added before the leaf node data, and a second predefined identifier, different from the first predefined identifier, can be added before the internal node data to distinguish between leaf hashes and internal node hashes. For example, the first predefined identifier can be 0x00, and the second predefined identifier can be 0x01.

[0061] For leaf nodes, we can follow these steps: H (First Predetermined Identifier || Normalized Leaf Data) Determine the corresponding leaf hash.

[0062] For the parent node, it can be done as follows: H(Second Predetermined Identifier || Left Child Node Hash || Right Child Node Hash) Determine the parent node hash.

[0063] The symbol “||” represents data concatenation and is not limited to concatenation functions in a specific programming language.

[0064] When the number of leaf nodes is odd, the last leaf node can be copied and paired with that leaf node, or other pre-agreed Merkle tree construction rules that are consistent across the same tree version can be used.

[0065] To differentiate Merkle trees at different stages, we can maintain `treeVersion`, `leafCount`, and `rootVersion` for the Merkle tree. `treeVersion` represents the version of the Merkle tree construction rules, `leafCount` represents the number of leaf nodes currently added, and `rootVersion` distinguishes the different root versions generated after each data append.

[0066] When a new leaf node is added, it is not necessary to recalculate all existing leaf data. Instead, the parent nodes at all levels on the affected path can be recalculated starting from the position of the newly added leaf, and finally a new Merkle root can be obtained.

[0067] Historical Merkle roots can be preserved, so new roots generated after adding new data will not replace the historical evidence state corresponding to the historical roots.

[0068] For example, the data hash corresponding to the initial framework protocol can be added to the Merkle tree as the first type of leaf node in the current rights confirmation process. As subsequent rights confirmation information, structured compliance data, compilation trajectory data, state transition logs, etc., are generated in sequence, the hashes of the corresponding data can continue to be appended as new leaf nodes.

[0069] In one exemplary leaf-type organization method, leaf types can be set according to the process sequence, such as framework agreement data, copyright information, structured compliance data, compilation trajectory data, decision logic deployment data, state transition logs, value assessment data, contract data, and full-process evidence storage data packages. The specific number and types of leaves can be determined based on the actual processing steps executed in the current process.

[0070] To avoid ambiguity when there are correction branches or subsequent transaction append data, each leaf node can simultaneously record the leaf type, step number, leaf index, and corresponding root version, enabling the verifier to determine the position of the leaf node in the corresponding tree version.

[0071] Therefore, the Merkle tree is not just a one-time hash of the final rights confirmation result, but rather it expands gradually along with the rights confirmation process to form a decision trajectory tree that can reflect the data relationships between different processing stages.

[0072] In some embodiments, the rights confirmation information includes issuer qualification information and digital copyright information associated with the current rights confirmation process.

[0073] The issuer's qualification information may include data used to confirm the issuer's identity and eligibility, such as qualification type, qualification name, qualification supporting documents, and identification information associated with the issuer. Digital copyright information may include copyright name, copyright ownership documents, registration documents, distribution information, and other information related to the work to be registered.

[0074] After obtaining the above information, the rights confirmation processing device can establish a link between the issuer's qualification information, digital copyright information and the current rights confirmation process identifier, so as to avoid the misuse of materials from different rights confirmation processes.

[0075] The rule data may include an audit rule base and rule mapping data corresponding to the audit rule base.

[0076] The review rule base can store multiple review rules. Each review rule can be distinguished by a rule identifier and associated with the corresponding rule text, scope of application, version information, and feature representations used for retrieval.

[0077] For example, review rules can be organized according to "rule identifier, rule text, applicable objects, version identifier, and vector index" so that AI semantic processing programs can retrieve the review rules related to the items to be reviewed.

[0078] The rule mapping data is used to convert different compliance assessment items in the structured compliance data into decision predicates that can be executed by the on-chain state machine during the subsequent deterministic rule compilation process.

[0079] Step S120: Perform AI semantic processing on the rights confirmation information and rule data to generate structured compliance data.

[0080] In this embodiment, the structured compliance data includes at least the compliance assessment results, confidence information, and decision trajectory data corresponding to the compliance assessment results.

[0081] The rights confirmation processing device can use the issuer's qualification information, digital copyright information, and the review rule base applicable to the current rights confirmation process as input for AI semantic processing.

[0082] Specifically, information can be extracted from the unstructured materials submitted by the issuer. For example, text materials, image-based qualification documents, and ownership documents can be parsed to form structured fields that can be used for subsequent processing.

[0083] In one specific implementation, for qualification materials in the form of images or scans, text recognition can be performed first, and then named entity recognition, field matching and rule verification can be used to obtain input features related to the current review, such as qualification validity period, authorized region, ownership source chain and publication history.

[0084] Subsequently, based on the matters to be reviewed, rule data related to the current confirmation of rights information is retrieved from the review rule base, and a correspondence is established between the retrieved rules and the corresponding materials.

[0085] In one specific implementation, AI semantic processing can adopt a processing chain of "rule retrieval - rule matching - semantic judgment - result verification".

[0086] First, based on the review features extracted from the rights confirmation information, a semantic search is performed in the review rule base to obtain candidate rules and / or candidate historical reference data related to the review features.

[0087] Next, rule matching is used to determine whether the candidate rule is applicable to the current item to be reviewed.

[0088] Then, the rules, relevant material content, and structured input features that match the current item to be reviewed are input into the AI ​​semantic model to output the corresponding compliance assessment results, intermediate judgment results, and confidence information.

[0089] After the AI ​​semantic model outputs structured results, a field validation program can be used to verify whether required fields exist, whether the field data types meet the predetermined requirements, and whether numeric fields fall within the allowed value range.

[0090] When a required field is detected to be missing or the field type does not meet the requirements, the field can be marked as missing or invalid so that an unknown or invalid status can be generated in the subsequent deterministic compilation stage, instead of directly using the abnormal field as a valid compliance result in the status determination.

[0091] In one specific implementation, the rules in the audit rule base can be represented as a data format of "rule identifier + rule text + feature index". For materials in the rights confirmation information, audit-related information can be obtained through methods such as text parsing, named entity recognition, and rule verification.

[0092] Furthermore, based on the retrieved audit rules and corresponding rights confirmation information, semantic judgment and rule matching are performed to form multiple compliance assessment items.

[0093] For example, compliance assessment results may include one or more of the following: infringement risk assessment results, ownership clarity assessment results, qualification validity assessment results, and rights conflict assessment results.

[0094] It should be understood that the above compliance assessment items are provided as examples for illustrative purposes and do not imply that structured compliance data must include all of the above assessment items simultaneously. In practical applications, the specific assessment items to be generated can be determined based on the type of digital copyright to be verified and the currently used audit rules.

[0095] While generating compliance assessment results, confidence information corresponding to the compliance assessment results can also be generated.

[0096] Confidence information is used to indicate the degree of credibility of the current compliance assessment results.

[0097] In one implementation, the confidence level can be determined based on data such as the model score output by the AI ​​model for the current compliance assessment item, the retrieval similarity between the current audit rules and the input materials, and the coverage of the rules involved in this judgment.

[0098] For example, corresponding weights can be assigned to model score, retrieval similarity, and rule coverage, and the above data can be weighted according to the weights to obtain a confidence score value in the range of 0 to 1. In one example, the weight of model score can be 0.5, the weight of retrieval similarity can be 0.3, and the weight of rule coverage can be 0.2; the above weights can be calibrated according to the model version and the rule base version, and should remain consistent within the same version.

[0099] The weights here can be saved as configuration parameters for the AI ​​semantic processing program and associated with the corresponding model version or rule base version. This application does not limit the specific weight values, as long as the corresponding confidence level can be repeatedly obtained under the same model / configuration version according to the same rules.

[0100] In this way, the confidence information is not random data that is independent of the compliance assessment results, but is formed based on the current model output, rule retrieval and rule coverage, and can continue to be used for subsequent on-chain state boundary judgment.

[0101] Furthermore, AI semantic processing also generates decision trajectory data.

[0102] Decision trajectory data may include rule references, material references, rule hit results, intermediate judgment results, and corresponding confidence information that are associated with the compliance assessment results.

[0103] For example, for an infringement risk assessment result, the following can be recorded: the audit rule identifier, the audited material identifier, the search similarity, the rule hit identifier, the intermediate risk judgment result, and the confidence level corresponding to the judgment.

[0104] For an assessment result on the clarity of ownership, the source of the rules, the source of the materials, and the intermediate processing results can also be recorded in the same way.

[0105] The rights confirmation processing device can establish sequential associations for rule references, material references, rule hit results, and intermediate judgment results according to the process of generating compliance assessment results, so that each compliance assessment result can be traced back to the rules and materials used to generate the result along the association relationship.

[0106] For example, a decision trajectory record can be organized as follows: Rule Identifier — Material Identifier — Search Matching Results — Rule Hit Results — Intermediate Judgment Results — Compliance Assessment Results — Confidence Level

[0107] When a compliance assessment result is formed by multiple rules, multiple rule references and multiple intermediate judgment records can be saved, and a corresponding structured trajectory can be formed through parent-child relationships, sequence numbers, or node association identifiers.

[0108] This stores the actual, persistent data output by the system, rather than requiring access to the invisible neural network inference state within the AI ​​model.

[0109] In some embodiments, the structured compliance data may be represented in the form of a compliance rule vector (CRV).

[0110] For example, CRV can include at least model version information, rule base version information, input feature data, compliance assessment data, confidence data, and decision trajectory data.

[0111] An exemplary CRV may include: modelVersion is used to indicate the model version used to perform this semantic judgment; ruleLibVersion is used to indicate the version of the audit rule library used in this audit. features are used to store the structured input features extracted from the rights confirmation information; compliance is used to store one or more compliance assessment results; confidence is used to store the corresponding confidence level information; reasoningTrace is used to save decision trajectory data generated by the system.

[0112] For example, a record in reasoningTrace can include at least the rule identifier, material identifier, search matching result, rule hit identifier, intermediate judgment result, evaluation conclusion, and corresponding confidence level.

[0113] As an example, for a digital copyright to be confirmed, AI semantic processing yielded an infringement risk value of 0.23, a ownership clarity of 0.95, a qualification validity judgment result of true, and a confidence level of 0.92.

[0114] Meanwhile, the corresponding decision trajectory data stores the rule identifier, material identifier, rule hit status, intermediate judgment nodes, and corresponding confidence levels used to form each of the above evaluation results.

[0115] It should be noted that the values ​​of 0.23, 0.95, and 0.92 mentioned above are only used to illustrate different types of data relationships in structured compliant data and are not intended to limit specific values ​​in actual applications.

[0116] After the structured compliant data is generated, it can be serialized and hashed according to the aforementioned normalization rules. The corresponding hash is then appended as a leaf node of the Merkle tree, and the current Merkle root is updated.

[0117] The full text of structured compliant data can be stored in off-chain storage space and associated with the corresponding Merkle leaf node through content hash and storage location index.

[0118] Therefore, structured compliance data not only serves as input for the subsequent compilation of deterministic rules, but the decision-making basis for its formation can also be associated with the Merkle tree through decision trajectory data.

[0119] Step S130: Based on the rule data, perform deterministic rule compilation on the nondeterministic compliance assessment results in the structured compliance data to obtain deterministic judgment logic that can be executed by the on-chain state machine, and generate compilation trajectory data.

[0120] In this embodiment, the compliance assessment results obtained from AI semantic processing may include continuous numerical values, scores, probabilities, or other data that cannot be directly used as conditions for determining state transitions on the blockchain.

[0121] For example, an infringement risk of 0.23 is a continuous assessment result, and this value does not directly indicate what stage the current rights confirmation process should be in.

[0122] Therefore, this application does not directly use the text conclusions output by AI as input to the state machine, but further compiles deterministic rules based on rule data for the nondeterministic compliance assessment results.

[0123] In some embodiments, the rule mapping data in the rule data includes the mapping relationship between compliance assessment items and data types, operational relationships, judgment criteria, criticality, priority, repairability, and status impact.

[0124] Furthermore, each rule mapping record may include multiple fields from the following: rule ID (ruleId), domain ID, compliance assessment item field ID, data type (dataType), operator, threshold, criticality, predicate template (predicateTemplate), state effect (stateEffect), priority, repairable, and version information.

[0125] The domain identifier is used to distinguish the data to which the rule mapping record applies. For example, it can distinguish between rules for structured compliance data (CRV) and rules for value assessment data (VEV).

[0126] The data type specifies whether the field being processed should be interpreted as a numeric, boolean, text, or other data type.

[0127] Operators are used to determine which deterministic operation among less than, greater than, equal to, logical AND, logical OR, or logical NOT is performed on the input field.

[0128] The threshold is used for comparison with the corresponding numerical compliance assessment item.

[0129] The criticality is used to determine whether the predicate is a key judgment predicate that affects the core status of the current rights confirmation process.

[0130] State influence is used to indicate what effect the corresponding predicate has on subsequent state determination when it is true, false, or undetermined.

[0131] Priority is used to determine the order in which rules are executed when multiple rules apply simultaneously or when conflicts arise.

[0132] Repairability is used to indicate whether a corresponding judgment predicate can be repaired through subsequent supplementary materials, updated data, or other permissible correction processes when the judgment conditions are not met or are uncertain.

[0133] When performing deterministic rule compilation, the target mapping relationship between the rule mapping data and each compliance assessment item in the structured compliance data is first determined from the rule mapping data.

[0134] For example, when there is an infringement risk assessment item in the structured compliance data, the rule corresponding to the infringement risk is determined from the rule mapping data based on the field identifier of the compliance assessment item.

[0135] When there is an ownership clarity assessment item, the rule corresponding to the ownership clarity is determined.

[0136] Subsequently, based on the data types, operational relationships, and judgment criteria in the target mapping relationship, the corresponding compliance assessment items are converted into judgment predicates.

[0137] For example, for risk-related assessment items, the risk value can be compared with the corresponding risk judgment threshold to form a Boolean judgment predicate indicating whether the risk meets the current rights confirmation requirements.

[0138] For clarity-related evaluation items, the clarity value can be compared with the corresponding judgment threshold to form a judgment predicate used to indicate whether the clarity of ownership meets the requirements.

[0139] For qualification validity assessment results that are themselves Boolean, corresponding judgment predicates can be directly formed based on the rule mapping data.

[0140] In this way, the continuous or probabilistic results generated by AI semantic processing are converted into decision predicates with definite outputs.

[0141] In the case of missing input fields, the compiler can encode the result of the judgment as "unknown" to indicate that there is not enough input data to complete the deterministic judgment of the item.

[0142] If a field already exists but its data type is inconsistent with the data type required by the rule mapping, the corresponding result can be encoded as invalid.

[0143] "Unknown" and "invalid" are not Boolean truth values ​​themselves, but rather represent abnormal states indicating that the corresponding decision predicate cannot be executed according to normal data. The subsequent state machine can then determine whether to treat them as either a pass / fail candidate based on the criticality and recoverability of the decision predicate.

[0144] When multiple rules match the same compliance assessment item, the order of rules can be determined first by priority; if the priorities are the same, the processing order can be further determined by criticality; for rules configured as critical and judged as false, veto processing can be performed according to their stateEffect.

[0145] Furthermore, multiple decision predicates are organized according to their criticality and priority to generate deterministic decision logic.

[0146] In one embodiment, multiple judgment predicates marked as key can be combined according to logic and relation to form a comprehensive judgment logic used to characterize whether the current rights confirmation process meets key review requirements.

[0147] For non-critical decision predicates, their execution results can be retained separately so that the on-chain state machine can further distinguish between fully passed states and conditionally passed states.

[0148] In some embodiments, in order to enable the corresponding decision logic to be executed by an on-chain execution environment that does not support floating-point operations, continuous numerical values ​​can also be converted to fixed-point values ​​during the compilation of deterministic rules.

[0149] For example, consecutive values ​​in the range of 0 to 1 can be multiplied by a predetermined factor to obtain integers.

[0150] As an example, when the multiplier is 10000, the infringement risk of 0.23 can be converted to 2300, the threshold of 0.3 can be converted to 3000, the ownership clarity of 0.95 can be converted to 9500, and the confidence level of 0.92 can be converted to 9200.

[0151] The above multiplier is only an example of implementing on-chain integer operations and does not restrict the use of 10000 as the multiplier.

[0152] In one specific implementation, deterministic rule compilation may perform the following processes sequentially: Read the rule mapping record corresponding to the current domain; Sort the rule mapping records according to priority; For each rule mapping record, generate a rule node; Perform type validation and necessary fixed-point conversion based on the data type of the input field; Map the less than, greater than, equal to, and logical AND, logical OR, and logical NOT operations to corresponding expression nodes; Key rule nodes are organized into comprehensive and progressive decision logic according to their corresponding logical relationships, while retaining the independent execution results of non-key rule nodes; An intermediate representation containing the rule nodes and logic nodes is formed; Based on the intermediate representation, a decision function that the on-chain state machine can execute or call is generated; The generated decision function is converted into an executable form supported by the target chain execution environment. For example, the target chain execution environment can be the Ethereum Virtual Machine (EVM), and the executable form can be a Solidity contract or EVM bytecode.

[0153] For example, the intermediate representation can be an Abstract Syntax Tree (AST) or a predefined structured intermediate representation (IR).

[0154] When the three key assessment items are "infringement risk is less than the target risk threshold", "ownership clarity is greater than the target ownership threshold", and "qualification validity is true", a logical AND node can be generated, which connects the three comparison sub-nodes.

[0155] The outputs of logic and nodes can serve as comprehensive progress indicators, while the outputs of each non-critical decision predicate are provided as independent results to the subsequent three-state state machine.

[0156] The input to the on-chain decision function may include at least the fixed-point evaluation value, Boolean evaluation value, and confidence fixed-point value corresponding to the decision predicate, and the output may include at least the comprehensive progressability identifier, confidence level, and execution result corresponding to each decision predicate. During the compilation of the deterministic rule, the criticality, repairability, and state impact corresponding to each decision predicate are encoded into the intermediate representation of the deterministic decision logic or the output of the decision function, so that the on-chain state machine can directly obtain the criticality identifier, repairability identifier, and execution result of each decision predicate after calling the deterministic decision logic; alternatively, the criticality, repairability, and state impact mapping relationship in the rule mapping data can be deployed to the blockchain network along with the deterministic decision logic for use by the on-chain state machine.

[0157] It should be noted that in this application, the deterministic rule compilation stage can output a confidence level or suggested state based on the confidence range, but the final three-state status code of the current rights confirmation process is not written at this stage. The final state of complete pass, conditional pass, or failure is determined uniformly by the subsequent on-chain state machine.

[0158] This approach avoids conflicts that can occur when the off-chain deterministic compiler and the on-chain state machine generate the final state independently.

[0159] Furthermore, compilation trajectory data is also generated during the compilation process of deterministic rules.

[0160] Compilation trajectory data is used to show how input structured compliant data is mapped through specific rules to form deterministic decision logic.

[0161] In some embodiments, compilation trajectory data may record the structured compliant data content or its hash corresponding to the compilation input, the compiler version used, the rule mapping data version, the threshold configuration version, the hash corresponding to the intermediate representation formed, the hash corresponding to the final deterministic judgment logic, compilation time information, and the transaction hash or function address after the judgment logic is deployed.

[0162] The hash of the compilation trajectory data can be calculated as a whole, and the hash of the compilation trajectory data can be added as a new leaf node to the Merkle tree corresponding to the current rights confirmation process.

[0163] When the on-chain state machine needs to execute the deterministic decision logic, the corresponding decision logic can be deployed as an on-chain decision function, or the state machine can call the already deployed general decision contract and input the intermediate representation or compilation result corresponding to this process.

[0164] When using the independent decision function deployment method, the decision function address or decision contract address can be obtained, and the deployment transaction hash can be written into the Merkle tree as the corresponding evidence storage data.

[0165] In this way, when it is necessary to verify the basis for the generation of a certain process state, not only can the decision trajectory corresponding to AI semantic processing be obtained, but also the compilation process of converting AI output into on-chain deterministic judgment logic can be obtained.

[0166] Regarding the determination of judgment criteria In some embodiments, the decision criteria in the rule mapping data include decision thresholds for compliance assessment items and state boundaries for confidence information.

[0167] Unlike using a fixed set of thresholds for all rights confirmation processes, the rule data in this embodiment may also include threshold configurations with configurable versions.

[0168] The threshold configurations are associated with digital rights types and review rule base versions, respectively.

[0169] In one implementation, a threshold configuration table, `threshold_profile`, can be set. Each threshold configuration record includes at least the applicable digital rights management type, the version of the audit rule base, the judgment threshold corresponding to one or more compliance assessment items, the confidence boundary corresponding to the fully passed status, the confidence boundary corresponding to the conditionally passed status, and a configuration version identifier.

[0170] For example, different types of digital copyrights may differ in terms of the complexity of the ownership chain, the scope of authorization, and potential conflicts of rights. Therefore, corresponding risk assessment thresholds, ownership clarity assessment thresholds, and confidence state boundaries can be configured for literary works, musical works, film and television works, software works, or image works respectively.

[0171] Furthermore, when the rules in the audit rule base undergo version changes, a new threshold configuration version can be generated accordingly.

[0172] Before starting the compilation of deterministic rules for the current rights confirmation process, the rights confirmation processing device determines the target threshold configuration corresponding to the current rights confirmation process from multiple threshold configurations, based on the digital copyright type of the digital copyright to be confirmed and the version of the review rule base applicable to the current rights confirmation process.

[0173] When the same digital rights management type has configurations for different versions of the review rule base, select the configuration record that corresponds to the current review rule base version and is in a valid state.

[0174] The version of the audit rule base can be determined based on the creation time of the current rights confirmation process and the effective time of each rule version. For example, you can select the corresponding rule version that was already in effect when the current process was created and has not yet been revoked.

[0175] Subsequently, the decision thresholds used to generate each decision predicate and the state boundaries used for on-chain state determination are determined based on the target threshold configuration.

[0176] As an example, the risk assessment threshold can be set to 0.3, the ownership clarity threshold can be set to 0.9, the complete pass confidence boundary can be set to 0.9, and the conditional pass confidence boundary can be set to 0.6.

[0177] The values ​​mentioned above are for illustrative purposes only. Actual thresholds can be configured according to copyright type, rule version, and current business scenario.

[0178] Threshold configurations can be based on historical case statistics, expert annotations, or pre-configured business rules. When the configuration changes, a new threshold configuration version is generated for the new configuration, and the new version is registered instead of directly overwriting the old version.

[0179] After determining the target threshold configuration, associate and record the version information corresponding to the target threshold configuration with the compilation trajectory data.

[0180] Therefore, for the same compliance assessment result, when the digital copyright type or the applicable review rule version changes, the judgment benchmark corresponding to the specific type and specific rule version can be applied, and the version of the judgment benchmark actually used in the current rights confirmation can be determined by the compilation trajectory.

[0181] In other embodiments, based on the digital copyright type and the version of the review rule base, the threshold configuration can be further determined according to the business scenario of rights confirmation, such as ordinary rights confirmation, fast rights confirmation, high-value issuance, or cross-regional issuance scenarios.

[0182] Step S140: Invoke the on-chain state machine, determine the current process state of the rights confirmation process based on the execution result of the deterministic judgment logic and the confidence information, and control the advancement of the current rights confirmation process according to the process state.

[0183] In this embodiment, the deterministic rule compilation stage is responsible for converting AI output into deterministic judgment logic, but the deterministic rule compilation itself does not directly generate the final process state of the current rights confirmation process.

[0184] In other words, the deterministic rule compilation can output the execution rules of each decision predicate, the comprehensive decision relationship, and the data corresponding to the confidence level, but the final process state is determined by the on-chain state machine based on the execution result of the deterministic decision logic and the confidence level information.

[0185] This avoids inconsistencies that can arise from separate judgments between off-chain compilation and processing and on-chain process states.

[0186] In some embodiments, the deterministic decision logic can be deployed to the blockchain network, or it can be used as a decision function that can be called by the on-chain state machine. The decision function can be deployed as an independent decision contract, and the on-chain state machine can call the decision contract through the contract address, taking the fixed-point evaluation value, the Boolean evaluation value, and the confidence fixed-point value as input.

[0187] After deployment, the corresponding deployment data can be recorded, such as the decision logic identifier, decision function address, or deployment transaction hash, and the corresponding data can be added to the Merkle tree.

[0188] The on-chain state machine calls the deterministic decision logic to obtain the execution results of each decision predicate.

[0189] The on-chain state machine further determines key and non-key decision predicates based on the key identifiers and repairability identifiers carried in the output of the deterministic decision logic, and determines the repairability of each decision predicate.

[0190] Among them, key judgment predicates can be understood as judgment predicates that directly affect whether the current confirmation process can meet the core review conditions; non-key judgment predicates can be understood as judgment predicates that allow improvement through subsequent supplementary materials without affecting the core review conditions.

[0191] In some embodiments, the rule mapping data may also record the repairability of the decision item, the type of supplementable material, and the correction cutoff condition.

[0192] Repairability is used to indicate whether a corresponding unsatisfactory or uncertain judgment result can be repaired through subsequent supplementary materials, updated data, or other permissible corrective processes.

[0193] For example, if qualification materials are temporarily missing or qualification certificates have expired but are allowed to be resubmitted as valid qualifications, the corresponding judgment item can be set as repairable; for rights conflicts that have been determined to exist based on the current ownership materials and cannot be eliminated by supplementary documents, the corresponding judgment item can be set as unrepairable.

[0194] In one specific embodiment, the on-chain state machine includes at least a fully passed state, a conditionally passed state, and a failed state.

[0195] When both key and non-key decision predicates meet the corresponding decision conditions, there are no undetermined decision predicates, and the confidence information reaches the state boundary corresponding to the fully passed state, the current rights confirmation process can be determined as the fully passed state.

[0196] When there are no irreparable and unsatisfactory key judgment predicates, and no irreparable and undetermined key judgment predicates, and the confidence level reaches the state boundary corresponding to the condition-passed state, if there are reparable undetermined key judgment predicates, key judgment predicates that do not meet the judgment conditions but are reparable, or non-key judgment predicates that do not meet the judgment conditions or are undetermined, or both key and non-key judgment predicates meet the corresponding judgment conditions and the confidence level reaches the state boundary corresponding to the condition-passed state but does not reach the state boundary corresponding to the fully passed state, the current rights confirmation process can be determined as the condition-passed state.

[0197] In some embodiments, the condition can also be configured with a maximum number and / or a maximum proportion of non-critical decision predicates that are not satisfied or are undetermined.

[0198] For example, it can be configured so that the number of non-critical decision predicates that do not meet the condition or are "unknown" does not exceed one, or the proportion of non-critical decision predicates does not exceed a predetermined proportion. Both the quantity and proportion mentioned above can be configured as options in the rule data, and are not limited to fixed values.

[0199] When the confidence information does not reach the state boundary corresponding to the conditional pass state, or when there is a key judgment predicate that is irreparable and does not meet the judgment condition, or when there is a key judgment predicate that is irreparable and undetermined, the current rights confirmation process can be determined as a fail state.

[0200] If the key decision predicate is unknown, and the decision item is marked as repairable, the process can enter the condition passed state and form a pending correction item; if the item is marked as unrepairable or the absence of the item makes the current process unable to continue to make decisions according to the current rules, the process can enter the failed state according to the corresponding stateEffect.

[0201] For invalid statuses, the decision to allow resubmission of input data can be determined based on the reason for invalidation. If the data format or data type error can be corrected by resubmitting compliant data, it can be processed as a recoverable issue; otherwise, the status can be determined as non-acceptable according to the corresponding rules.

[0202] It should be noted that the above state boundaries can be determined based on the aforementioned threshold configuration, and do not necessarily have to use fixed values.

[0203] As an example for easy understanding, when the confidence level is 0.92, all key and non-key decision predicates are satisfied and there are no undetermined decision predicates, and 0.92 reaches the state boundary corresponding to the fully passed state, it can be determined as a fully passed state. When there are no irreparable key negative results and the confidence level reaches the state boundary corresponding to the conditional passed state, if there are repairable undetermined key decision predicates, repairable key decision predicates that do not meet the conditions, non-key decision predicates that do not meet the conditions or are undetermined, or all decision predicates meet the conditions but the confidence level has not yet reached the state boundary corresponding to the fully passed state, it can be determined as a conditional passed state. When the confidence level is insufficient or there are irreparable key decision predicates that are false, it can be determined as a failed state.

[0204] The values ​​here are only used to explain the three-state transition logic and do not constitute a restriction on the state boundaries.

[0205] For a fully completed state, the on-chain state machine controls the current rights confirmation process to continue to the subsequent rights confirmation process.

[0206] For conditions met, the on-chain state machine also allows the current rights confirmation process to continue, but records that there are still matters to be corrected in the current process.

[0207] In the event of a failure, the on-chain state machine can terminate the current rights confirmation process while retaining the previously formed decision trajectory data, compilation trajectory data, and corresponding Merkle tree state.

[0208] Therefore, this application does not immediately suspend the entire rights confirmation process when a vague judgment occurs, but rather uses three states—complete approval, conditional approval, and failure—to allow different process control methods to correspond to different levels of certainty in the review results.

[0209] Correction processing in condition pass state In some embodiments, when the current rights confirmation process is determined to be in a condition-passed state, the rights confirmation processing device generates a condition list based on at least one of the following: repairable undetermined key judgment predicates, key judgment predicates that do not meet the judgment conditions but are repairable, non-key judgment predicates that do not meet the judgment conditions or are undetermined, and confidence information that reaches the state boundary corresponding to the condition-passed state but does not reach the state boundary corresponding to the fully passed state.

[0210] The condition list is used to clarify the content that needs to be further supplemented in the current property rights confirmation process.

[0211] For example, a condition list can record the corresponding judgment item to be corrected, the description of the missing condition, the type of material to be supplemented, the supplementation period, the supplementation method, and the rule identifier associated with the judgment item to be corrected.

[0212] For each judgment item to be corrected, its source judgment predicate and corresponding rule mapping record can also be recorded, so that when subsequent supplementary materials arrive, it can be determined which compliance assessment items need to be re-executed.

[0213] After the condition list is generated, it can be normalized and serialized and hashed. The hash can then be added to the Merkle tree corresponding to the current rights confirmation process as part of the state transition log or as an independent leaf node.

[0214] Meanwhile, the on-chain state machine continues to execute subsequent processes that are allowed to be executed based on the conditions and the state control of the current rights confirmation process, without waiting for all the matters to be corrected to be completed. When the conditions are met, the value assessment, contract preparation and certificate generation processes that do not depend on the undetermined or unmet judgment items are allowed to be executed. For processes that depend on the undetermined or unmet judgment items, execution is suspended and recorded in the condition list.

[0215] For example, subsequent value assessments, contract preparations, or certificate generation can proceed, but the "conditions met / pending correction" status can be recorded in the corresponding contract or certificate.

[0216] When the issuer subsequently submits supplementary confirmation information regarding the condition list, the confirmation processing device associates the supplementary confirmation information with the original current confirmation process based on the process identifier and the condition list identifier.

[0217] Subsequently, the confirmation information corresponding to the current confirmation process is updated based on the supplementary confirmation information.

[0218] After the update is completed, instead of directly modifying the final state based on the supplementary materials, the AI ​​semantic processing process affected by the supplementary information is re-executed to generate updated structured compliance data.

[0219] For example, if the supplementary materials only affect the determination of qualification validity, the semantic parsing and rule matching involving at least qualification validity can be re-executed, while retaining the unaffected historical assessment results; in another implementation, the complete step S120 can also be re-executed to regenerate the structured compliance data used in this status determination.

[0220] Then, based on the updated structured compliance data, the deterministic rule compilation is re-executed to obtain new deterministic judgment logic and compilation trajectory data.

[0221] The on-chain state machine further determines the process state based on the new deterministic decision logic execution results and the new confidence information.

[0222] Therefore, the corrected final state still goes through the complete processing chain of "AI semantic processing - deterministic rule compilation - on-chain state determination", rather than the original process state being directly overwritten by manual intervention.

[0223] If the supplementary confirmation information makes the previously undetermined key judgment predicate a condition, and other judgment conditions and confidence levels meet the full pass requirement, then the new process status can be changed from the condition pass status to the full pass status.

[0224] If supplementary confirmation information proves that a certain key judgment predicate does not meet the conditions and cannot be repaired, the new process status can be changed to a failed status.

[0225] For the updated process status obtained from the reassessment, a new state transition log is generated, and the hash of the new state transition log is added as a leaf node to the Merkle tree corresponding to the original current rights confirmation process.

[0226] In this way, the data corresponding to the original condition will not be overwritten, but the original state record will be retained and further formed into a new subsequent state record.

[0227] In some embodiments, a state branch can be formed by establishing a sequential association between the original state and the updated state through the previous state hash, state version number, or reference to the preceding state in the state transition log.

[0228] For example, the new state transition log can store the hash of the previous condition's state transition log as `prevStateHash`, and set the new state log as the next state node. The new state transition log records the hash of the state transition log corresponding to the state through which the condition passed, or the state version number, as `prevStateHash`, so that the new state transition log and the state transition log corresponding to the state through which the condition passed form a sequentially related state branch. In this way, even if other data is subsequently appended to the Merkle tree, the state transition relationship can still be corrected by tracing back level by level according to `prevStateHash`.

[0229] Therefore, even if the current property rights confirmation process undergoes one or more corrections, the process status before and after each correction can be restored according to the state transition sequence.

[0230] Step S150: Generate a state transition log based on the decision trajectory data, compilation trajectory data and process status. Add the hash of the state transition log as a leaf node to the Merkle tree to update the Merkle root. In the same chain state transition transaction, synchronously write the state data corresponding to the process status, the log data or log summary corresponding to the state transition log and the updated Merkle root.

[0231] In some embodiments, after the on-chain state machine determines the current process state of the rights confirmation process, a corresponding state transition log is generated each time.

[0232] If the current state is the first state determination, the previous process state is a null value or a preset initial state; if the current state is not the first state determination, the previous process state is the previously determined process state. The state transition log can be generated based on the previous process state, the current process state, the reference information of the structured compliance data that triggered this state determination in the Merkle tree, and the execution result of the deterministic determination logic.

[0233] In one specific implementation, the state transition log may include: The current rights confirmation process identifier; the previous state hash (for the first state determination, the previous state hash is null or a preset initialization hash); the current process status code; the leaf index or data hash corresponding to the structured compliant data that triggered this state determination; the execution result corresponding to the deterministic determination logic; the compilation trajectory data reference used this time; time information; and the signature reference of this operation.

[0234] Therefore, the current process status can be simultaneously linked to the corresponding structured compliance data, decision trajectory, and compilation trajectory through the status transition log.

[0235] For state transition requests initiated by the issuer, the issuer terminal can use its private key to sign data such as "process identifier + input data hash + nonce", and the on-chain smart contract can verify the signature.

[0236] The state transition log automatically generated by the on-chain state machine after a valid authorization request has been obtained can record msg.sender, smart contract address, and original user signature reference. It is neither necessary nor possible for the smart contract to directly call the issuer's private key.

[0237] After the state transition log is generated, a hash calculation is performed on the state transition log, and the hash corresponding to the state transition log is added to the Merkle tree as a leaf node.

[0238] After adding new leaf nodes, the affected Merkle paths are recalculated according to the Merkle tree construction rules to obtain the updated Merkle root.

[0239] Subsequently, in the same chain state transition transaction, the state data corresponding to the current process state, the log data or log summary corresponding to the state transition log, and the updated Merkle root are synchronously written.

[0240] In one specific implementation, the same state transition transaction can be executed sequentially: First, verify the process identifier, input data hash, authorization signature, and nonce; Second, verify whether the current state allows this state transition to be performed; Third, write the new process status code; Fourth, write to or trigger a state transition log summary or on-chain event; Fifth, write the updated Merkle root; Sixth, update the status version and / or rootVersion corresponding to the current process.

[0241] The above operations can be completed within the same smart contract transaction execution context.

[0242] The “same on-chain state transition transaction” here refers to the state data, state transition log, and Merkle root corresponding to the same indivisible on-chain state transition.

[0243] If any of the above write operations fails, the write operations already executed in the on-chain state transition transaction will be rolled back.

[0244] For example, if the state data has been written but the updated Merkle root fails to be written, the current on-chain state transition transaction is rolled back, so that the process state, state log and Merkle root remain in the state before the transaction was executed.

[0245] If an error occurs while executing a decision predicate off-chain, recalculating the Merkle path, or generating a state transition log, the corresponding on-chain state transition transaction will not be initiated.

[0246] For transactions that need to be resubmitted due to communication interruption, transaction confirmation timeout, etc., the aforementioned idempotency flag can be used to determine whether a valid result already exists for the same input, thereby reducing the possibility of repeated state transitions.

[0247] The above methods can ensure that on-chain status codes, corresponding status logs, and Merkle decision trajectories remain consistent at the transaction level.

[0248] Version tracking of compiler and rule mapping data In some embodiments, the compilation trajectory data also includes a compiler version identifier used when performing deterministic rule compilation and a rule mapping data version identifier.

[0249] This is because audit rules, rule mapping data, or compilers may all be updated as the rule environment changes. The same structured compliance data may lead to different deterministic judgment logic under different rule versions.

[0250] Therefore, version registration data can be generated separately for different versions of compilers and rule mapping data.

[0251] Version registration data can include at least: Version identifier; version type; file name; content addressing identifier; file content hash; storage location index; effective time; previous version identifier; publisher signature; compatibility rule mapping data version; version status.

[0252] The version type can be used to distinguish different version objects such as compiler code, compiled executable data, rule mapping data, and threshold configuration.

[0253] Content addressing identifiers are used to locate the corresponding file based on its content; for example, they can be content addresses generated based on content hashes.

[0254] Version status can be used to indicate at least whether it is valid, obsolete, or revoked.

[0255] One version identifier corresponds to one version registration record; one version registration record corresponds to at least one content hash and its corresponding storage location; the effective time is used to determine when the version becomes applicable to the new rights confirmation process.

[0256] The compiler and rule mapping data can be version-managed separately. When both are upgraded, the version of rule mapping data allowed to be loaded for a given compiler version can be determined by using the compatibility rule mapping data version field.

[0257] Off-chain files can be stored in content-addressable storage systems, version-tagged code repositories, object storage, or other storage systems that can retrieve historical files by version index.

[0258] The blockchain does not need to store complete compiler files and complete rule mapping data. Instead, it can store version registration data such as version identifier, file hash, content addressing identifier, storage location index, and effective time.

[0259] When it is necessary to verify the historical rights confirmation process, the compilation trajectory data corresponding to the historical rights confirmation process is read first.

[0260] Based on the compilation trajectory data, determine the compiler version identifier, rule mapping data version identifier, and threshold configuration version actually used when the historical rights confirmation process was compiling deterministic rules at that time.

[0261] Subsequently, the version registration data on the query chain is obtained based on the version identifier to obtain the corresponding content hash and storage location index.

[0262] Historical compilers and historical rule mapping data are retrieved from off-chain storage devices according to the storage location index.

[0263] After obtaining the data, the content hash of the historical compiler and historical rule mapping data is recalculated and compared with the content hash of the on-chain version registration data record.

[0264] If the hashes match, then verify whether the effective date of the target version covers the creation or review date of the historical rights confirmation process, thereby confirming that the currently obtained file belongs to the version that was applicable at that time.

[0265] If all that is needed is to verify whether the rule version used at the time actually existed and has not been modified, the above-mentioned version location, data acquisition, hash verification, and effective time verification can be completed.

[0266] If it is necessary to further reproduce the deterministic rule compilation results of the historical rights confirmation process, then based on the historical compiler with hash verification, historical rule mapping data and historical threshold configuration, read the structured compliance data that has been stored in the historical rights confirmation process, and re-execute the deterministic rule compilation.

[0267] After obtaining the execution result of the regenerated judgment predicate, the confidence level, or the deterministic judgment logic, the regenerated result is compared with the corresponding result that has been stored in the historical rights confirmation process.

[0268] When the two are consistent, it can be verified that the deterministic compilation process of the historical rights confirmation process can be reproduced in the same version environment.

[0269] Therefore, even if the review rules or deterministic compiler are updated in the future, there is no need to reinterpret the historical rights confirmation process using the new version of the rules. Instead, the rule processing environment of the corresponding version can be restored based on the version information recorded in the historical rights confirmation process.

[0270] Merkle proof path and verification of stored data In some embodiments, when the current rights confirmation process is completed or when verification information needs to be generated for a certain piece of evidence, the target Merkle root corresponding to the current rights confirmation process and the leaf node corresponding to the evidence to be verified are obtained.

[0271] The target Merkle root can be the final Merkle root when the current ownership confirmation process is completed, or it can be the Merkle root corresponding to a certain historical rootVersion.

[0272] Based on the position of the leaf node in the Merkle tree of the corresponding treeVersion and rootVersion, traverse the Merkle tree level by level from the leaf node to the target Merkle root.

[0273] For each level of node, obtain the hash of the sibling node that forms the parent node with the current node, and record whether the sibling node is located to the left or right of the current node.

[0274] This forms the Merkle proof path from the leaf node to the target Merkle root.

[0275] In some embodiments, the Merkle proof path includes at least the sibling node hash and node location information.

[0276] Furthermore, it can also include hashAlg, leafIndex, treeVersion, rootVersion, leafCount, target root hash, and the left and right positions corresponding to each level of siblings.

[0277] For example, each element in siblings can include a sibling hash and a position, where position indicates whether the current sibling is on the left or right side of the node to be computed.

[0278] If only the sibling node hash is stored without storing the left and right directions of the node or the leafIndex of the left and right directions, the verifier may not be able to determine the concatenation order of the hashes at each level. Therefore, this embodiment clarifies the calculation method of each level of parent node by recording node position information or leaf index.

[0279] During verification, the corresponding leaf node hash is first calculated based on the evidence to be verified, following the same normalization and hashing rules as when generating the leaf nodes.

[0280] Then, starting with the leaf node hash, read the first-level sibling node of the Merkle proof path.

[0281] If the sibling node is to the left of the current node, then proceed as follows: H (Second Predetermined Identifier || Sibling Node Hash || Current Node Hash) Calculate the parent node hash; If the sibling node is to the right of the current node, then proceed as follows: H (Second Predetermined Identifier || Current Node Hash || Sibling Node Hash) Calculate the hash of the parent node.

[0282] The obtained parent node hash is used as the new current node, and the calculation is continued by combining it with the next level of sibling nodes until the verified Merkle root is obtained.

[0283] Finally, the verification Merkle root will be compared with the target Merkle root.

[0284] If the two are consistent, it indicates that the leaf node corresponding to the evidence to be verified can belong to the Merkle tree represented by the target Merkle root according to the given Merkle proof path.

[0285] It should be noted that local Merkle Proof calculations can be completed without accessing the centralized server of the rights confirmation processing device.

[0286] However, simply performing a Merkle Proof calculation can only verify that "the data belongs to the given target Merkle root," and cannot prove that the target Merkle root actually exists in a blockchain or has not been revoked.

[0287] Therefore, when it is necessary to further confirm the existence of the target Merkle root chain, the corresponding transaction, block height, or smart contract status can be queried through the blockchain node while connected to the network.

[0288] If it is required to verify the on-chain existence of the target root in a completely offline environment, the corresponding block header, transaction inclusion proof, or trusted chain state snapshot can be carried in advance in the certificate or verification data, but this part belongs to a further extended implementation method.

[0289] Further Implementation Methods for Valuation and Issuance Contracts In some embodiments, digital copyright valuation can continue to be performed after the current rights confirmation process has reached a state where it is allowed to proceed.

[0290] The rights confirmation processing device can acquire market data related to the digital copyright to be confirmed and obtain structured value assessment data through AI semantic processing.

[0291] The market data may include one or more of the following: historical transaction prices, transaction volume, transaction time, transaction platform, audience characteristics, and search popularity for similar digital copyrights.

[0292] Before entering the valuation model, market data can be preprocessed by deduplication, time alignment, and normalization to form a unified data scale for market data from different sources.

[0293] Structured valuation data can be represented as a valuation vector, VEV.

[0294] VEV can include market prospect assessment results, similar data comparison results, creative assessment results, audience analysis results, corresponding confidence levels, and explicit decision trajectory data used to generate these results.

[0295] Similar to structured compliance data, VEV can record the corresponding AI model version and rule base version.

[0296] The nondeterministic evaluation results in VEV can also be mapped to data according to the corresponding rules and compiled by deterministic rules to form a value judgment predicate that can be executed by on-chain logic.

[0297] For example, it is possible to form judgment predicates for determining whether the assessed value has reached the issue price floor and judgment predicates for determining whether the market prospects meet the target conditions.

[0298] Rule mapping data can be distinguished between CRV rules and VEV rules through the domain field.

[0299] The compilation trajectory data corresponding to the value assessment can record at least the input VEV, compiler version, rule mapping data version, and output predicate hash, and add them to the Merkle tree as evidence data.

[0300] Subsequently, a digital copyright distribution contract can be generated based on the digital copyright information and relevant parameters in the current rights confirmation process.

[0301] The issuer can perform digital signatures on contract documents through the issuer's terminal.

[0302] After encapsulating and hashing the signed contract documents, signature data, and time information, the corresponding hash can be stored on the blockchain and added as a new leaf node to the Merkle tree corresponding to the current rights confirmation process.

[0303] Therefore, valuation and contract signing can continue to be incorporated into the same Merkle decision-making trajectory as subsequent steps in the current ownership confirmation process, without the need to rebuild a separate chain of evidence.

[0304] Implementation methods for full-process evidence storage data packages and certificate generation In some embodiments, after the main processing steps of the current rights confirmation process are completed, various data references generated by the current rights confirmation process can be packaged in a predetermined order to form a full-process evidence storage data package.

[0305] The “full-process evidence storage data package” here is the system data encapsulation name, used to summarize data references from different rights confirmation stages, and does not imply that it has specific legal notarization attributes.

[0306] A full-process evidence storage data package can include at least the process identifier flowId, the current leaf node list leafList, the data hash corresponding to each data item dataHash, and the time information timestamp.

[0307] This may include at least one or more of the following: references to framework agreement data, references to digital copyright information, references to structured compliance data, references to compilation trajectory data, references to state transition logs, and references to value assessment and contract data.

[0308] For large original files, it is not necessary to write the entire file directly to the blockchain. Instead, it can be stored in an off-chain encrypted storage space, and its hash and corresponding data index can be recorded in the end-to-end evidence data package.

[0309] After calculating the hash of the entire process evidence storage data packet, the hash is added to the Merkle tree as a new leaf node to form the corresponding final or stage Merkle root.

[0310] It should be noted that Merkle itself is primarily used to prove the integrity and immutability of a given set of leaves in the corresponding tree version.

[0311] If it is necessary to further determine whether the current process is missing any of the processing steps that should be present according to the predetermined rules, you can check the fixed leaf type number, leaf order, process version, leafCount, and state transition log at the same time.

[0312] Subsequently, the corresponding Merkle root can be written into the blockchain network.

[0313] In some embodiments, a digital copyright certificate can be generated based on the Merkle tree of the current rights confirmation process and its on-chain root record.

[0314] The certificate can store the target Merkle root and the Merkle proof path corresponding to the target proof data corresponding to the certificate.

[0315] For example, the following data can be written to the certificate via a QR code or other machine-readable data carrier: Certificate type; hash algorithm identifier; target leaf node hash; leaf node index; treeVersion; rootVersion; sibling node hash and left and right positions; target Merkle root; corresponding block height or transaction hash; smart contract address; chain identifier.

[0316] When performing local integrity verification, the verification program can read the Merkle proof data in the certificate, recalculate the verification Merkle root according to the aforementioned Merkle proof path, and compare it with the target Merkle root in the certificate.

[0317] In addition, the generated certificate file itself can be hashed and used as a certificate fingerprint for on-chain storage.

[0318] In this way, on the one hand, the relationship between the stored data corresponding to the certificate and the Merkle root can be verified based on the Merkle proof carried by the certificate, and on the other hand, the certificate file can be determined to have been modified based on the certificate fingerprint stored on the chain.

[0319] It should be noted that the local or offline Merkle verification referred to in this application means that the recalculation process of the Merkle path does not rely on a centralized server of the rights confirmation processing device.

[0320] If you need to further confirm whether the target Merkle root currently exists on the target blockchain, whether the certificate has been revoked, or whether the current state has changed, you can query the corresponding on-chain status while connected to the internet.

[0321] Therefore, in some embodiments, certificate verification can be divided into two stages: The first stage is local integrity verification, which verifies whether the data corresponding to the certificate has been modified and whether it belongs to the corresponding Merkle tree based on the leaf node hash in the certificate, the Merkle proof path and the target Merkle root. The second stage is network status verification, which is used to query the on-chain evidence of the target Merkle root, the certificate revocation status, and whether an updated version exists.

[0322] Certificate renewal and historical root management In some embodiments, a new Merkle root version can be formed when the ownership information changes, the conditions are corrected through status, or the certificate needs to be updated.

[0323] The new root version does not overwrite the historical root.

[0324] For historical certificates, the rootVersion bound to them when they were generated and the corresponding Merkle proof path can be retained.

[0325] Therefore, new Merkle roots formed after subsequent addition of new evidence data or updates to the ownership status do not affect the integrity verification of historical Merkle roots by historical certificates.

[0326] When an old certificate needs to be revoked, a revocation event corresponding to the old certificate's fingerprint can be recorded on the blockchain. A revocation event can include at least the old certificate's fingerprint, the reason for revocation, and the new certificate's index.

[0327] When generating a new certificate, a new Merkle proof path is generated for the new certificate, and a new rootVersion is bound.

[0328] When verifying old certificates online, their corresponding revocation events can be queried; in implementations that require providing revocation status offline, the corresponding revocation list or status certificate can be carried in advance.

[0329] In this way, while maintaining the verifiability of historical data, the latest process status and the historical process status can each have a clear data version relationship.

[0330] Implementation of follow-up transactions for digital rights In some embodiments, after the initial confirmation of digital rights, subsequent transactions can continue to be linked to the cryptographic traceability structure of the digital rights.

[0331] For example, when a new digital copyright transaction occurs, the rights confirmation processing device obtains the corresponding transaction data.

[0332] Transaction data can include the identities of the transacting parties, the transaction price, the transaction quantity, and the transaction time.

[0333] The transaction data is normalized and hashed.

[0334] The hash corresponding to the transaction data is appended as a new leaf node to the corresponding Merkle tree, forming a new Merkle root version.

[0335] At the same time, record the new rootVersion, leafCount, and corresponding blockchain transaction information.

[0336] Because the historical root version is preserved, each historical certificate or historical transaction record can still be verified against the historical root at the time of its formation, while newly occurring transactions correspond to new Merkle roots and corresponding Merkle proofs.

[0337] In this way, the Merkle evidence preservation mechanism of this application can be extended from the initial rights confirmation stage to the subsequent digital copyright transaction stage.

[0338] A complete processing example To further illustrate the above technical solution, a complete processing example is given below.

[0339] Suppose that the publisher initiates a digital copyright confirmation process for work A.

[0340] First, the rights confirmation processing device establishes the current rights confirmation process F1 and obtains the publisher's qualification information, the digital copyright information corresponding to work A, and the currently effective review rule base R1.

[0341] At the same time, determine the rule mapping data M1 corresponding to the audit rule base R1, and initialize the Merkle tree T1 corresponding to the current rights confirmation process F1.

[0342] T1 records treeVersion as V1, the current leafCount is the initial number of leaves, and a new rootVersion is generated after each append of leaves.

[0343] Subsequently, AI semantic processing was performed on the publisher's qualification information, the digital copyright information of work A, and the review rule base R1.

[0344] AI semantic processing first extracts information on the validity period of qualifications, scope of authorization, and source of ownership from the materials. Then, it retrieves rules related to the ownership, qualifications, and potential conflicts of rights of work A from the review rule base R1 and establishes a connection between the corresponding rules and the materials submitted by the publisher.

[0345] Structured compliant data C1 is generated through rule matching and AI semantic judgment.

[0346] For example, C1 includes an infringement risk assessment result of 0.23, an ownership clarity assessment result of 0.95, a qualification validity result of true, and a confidence level of 0.92.

[0347] The confidence level of 0.92 can be obtained by weighting the current model score, the retrieval similarity with the hit review rules, and the rule coverage according to the preset weights corresponding to the current model version.

[0348] At the same time, for each of the above evaluation results, record the rule reference, material reference, rule hit result and intermediate judgment result to form a decision trajectory D1.

[0349] After C1 is normalized and serialized, its hash is calculated and then added to the Merkle tree T1.

[0350] Then, deterministic rules are compiled for the structured compliance data C1 using the rule mapping data M1.

[0351] M1 records the data type, operational relationship, judgment threshold, criticality, priority, and status impact for each compliance assessment item.

[0352] Based on the work type of work A and the version of the review rule base R1, determine the corresponding threshold configuration P1.

[0353] Based on the judgment criteria in P1, the infringement risk assessment results are converted into risk judgment predicates, the ownership clarity assessment results are converted into ownership judgment predicates, and the qualification validity results are converted into qualification judgment predicates.

[0354] If the target chain execution environment uses integer arithmetic, then 0.23, 0.95, and 0.92 are converted to integer values ​​according to the corresponding fixed-point conversion ratio, and the corresponding thresholds are converted using the same ratio.

[0355] Based on the criticality of the M1 record, the key and non-key decision predicates in the above decision predicates are determined, and the deterministic decision logic L1 is formed according to the rule relationship.

[0356] For example, when all three decision predicates are set as key predicates, they can be logically ANDed and their output can be used as a comprehensive progress indicator.

[0357] Simultaneously, the conversion relationships between structured compliance data C1, rule mapping data M1, threshold configuration P1, intermediate representation, and deterministic judgment logic L1 are recorded to form the compilation trajectory CTrace1.

[0358] CTrace1 also records the compiler version identifier CV1, the rule mapping data version MV1, and the output decision logic hash.

[0359] The on-chain state machine calls L1 and, combined with a confidence level of 0.92, determines the current process state of the rights confirmation process F1.

[0360] If all critical and non-critical decision predicates meet the corresponding conditions, there are no undetermined decision predicates, and 0.92 reaches the state boundary corresponding to the fully passed state in the current threshold configuration P1, then F1 is determined to be in the fully passed state.

[0361] Subsequently, a state transition log SLog1 is generated based on the fully passed state, decision trajectory D1, and compilation trajectory CTrace1.

[0362] SLog1 can store the Merkle leaf index corresponding to C1, the data reference corresponding to CTrace1, the hash of the previous state, and the execution result of L1.

[0363] Add the hash corresponding to SLog1 to the Merkle tree T1 and calculate the new Merkle root RRoot1.

[0364] Subsequently, in the same chain state transition transaction, write the state data corresponding to the fully passed state, the log summary corresponding to SLog1, and RRoot1, and update the state version and rootVersion corresponding to F1.

[0365] If any write operation fails, all writes in this state transition transaction are rolled back.

[0366] As another example, if all decision predicates satisfy the corresponding conditions but the current confidence level only reaches the state boundary corresponding to the condition passed state and not the state boundary corresponding to the fully passed state, or if there are undetermined key decision predicates, repairable key decision predicates that do not satisfy the conditions, or unsatisfied or undetermined non-key decision predicates, and there are no unrepairable and undetermined key decision predicates, and the current confidence level reaches the state boundary corresponding to the condition passed state, then the on-chain state machine will determine F1 as the condition passed state.

[0367] For example, a non-critical ownership auxiliary material cannot be verified, and the corresponding predicate is unknown. However, there is no irreparable and false critical judgment predicate, and the current confidence level has reached the condition passing state boundary.

[0368] The rights confirmation processing device generates a condition list CL1 based on the unknown predicate. CL1 records the missing materials, rule identifiers, supplementation deadlines, and supplementation methods.

[0369] Add the hash corresponding to CL1 to the Merkle tree T1, while allowing F1 to continue executing the permitted subsequent processes.

[0370] When the issuer subsequently submits supplementary material B1 corresponding to CL1, the rights confirmation processing device establishes a connection between B1 and the original rights confirmation data based on F1 and CL1.

[0371] Based on the updated rights confirmation information in B1, the structured compliance data C2 is regenerated, and the deterministic rule compilation is re-executed to obtain the deterministic judgment logic L2.

[0372] The on-chain state machine redetermines the process state based on L2 and generates a new state transition log SLog2.

[0373] SLog2 records the hash corresponding to SLog1 as a reference to the previous state.

[0374] SLog1 is retained, and SLog2 is added to the same Merkle tree as a subsequent state record, thus enabling the reconstruction of the complete process of "condition passed - supplementary materials - re-determination - update state".

[0375] Implementation of the rights confirmation processing device In some embodiments, the rights confirmation processing apparatus for performing the above method may include one or more processors and one or more memories.

[0376] The memory can store programs and data used for performing AI semantic processing, deterministic rule compilation, blockchain interaction, and Merkle tree processing.

[0377] The processor can implement the digital copyright confirmation methods in the foregoing embodiments by executing programs stored in memory.

[0378] For example, when the processor executes the program, it can obtain rights confirmation information and rule data, call the AI ​​semantic processing program to generate structured compliance data, call the deterministic rule compiler to generate deterministic judgment logic, and call the on-chain state machine through the blockchain communication interface.

[0379] Meanwhile, the processor can perform tasks such as appending Merkle leaf nodes, calculating Merkle roots, generating Merkle proof paths, and managing historical root versions.

[0380] The memory may include one or more of volatile memory and non-volatile memory. Non-volatile memory can be used to store programs, rule mapping data, version indexes, and current rights confirmation process context data; volatile memory can be used to store intermediate processing results during program execution.

[0381] The rights confirmation processing device may also include a communication interface for data communication with the issuer terminal, blockchain node, rule data storage device and off-chain data storage device.

[0382] It should be noted that the aforementioned AI semantic processing program, deterministic rule compiler, and Merkle processing program can be deployed on the same computing device or on different computing devices, and can be invoked by the rights confirmation processing device through the corresponding communication interface.

[0383] When the above programs are deployed on different computing devices, each program must at least pass the process identifier corresponding to the current rights confirmation process and the input data or input data reference required for the current processing step, so as to ensure that the data association relationship from rights confirmation information to structured compliant data, from structured compliant data to deterministic judgment logic, and from judgment results to state transition logs is not broken.

[0384] The processing steps described in this application can be implemented by a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the processor can perform the corresponding steps in the digital rights confirmation method described above.

[0385] Those skilled in the art will understand that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit the scope of protection of this application. The above embodiments can be combined, adjusted, or equivalently substituted without departing from the technical concept of this application.

Claims

1. A method for confirming digital copyright, characterized in that, The method, executed by a rights confirmation processing device connected to a blockchain network, includes: Obtain the rights confirmation information corresponding to the digital copyright to be confirmed and the rule data applicable to the current rights confirmation process, and initialize the Merkle tree corresponding to the current rights confirmation process; AI semantic processing is performed on the rights confirmation information and rule data to generate structured compliance data, which includes compliance assessment results, confidence information, and decision trajectory data corresponding to the compliance assessment results. Based on the rule data, the nondeterministic compliance assessment results in the structured compliance data are compiled into deterministic rules to obtain deterministic judgment logic that can be executed by the on-chain state machine, and compilation trajectory data corresponding to the deterministic rule compilation is generated. The on-chain state machine is invoked to determine the current rights confirmation process state based on the execution result of the deterministic judgment logic and the confidence information, and the progress of the current rights confirmation process is controlled according to the process state. Based on the decision trajectory data, compilation trajectory data, and process status, a state transition log is generated. The hash of the state transition log is added to the Merkle tree as a leaf node to update the Merkle root. In the same chain state transition transaction, the state data corresponding to the process status, the log data or log summary corresponding to the state transition log, and the updated Merkle root are synchronously written to form an association and evidence record between the process status and the corresponding decision trajectory data and compilation trajectory data.

2. The digital copyright confirmation method according to claim 1, characterized in that, The rights confirmation information includes the issuer's qualification information and digital copyright information associated with the current rights confirmation process, and the rule data includes an audit rule base and rule mapping data corresponding to the audit rule base; The AI ​​semantic processing of the rights confirmation information and rule data includes: Based on the aforementioned review rule base, semantic retrieval and rule matching are performed on the issuer's qualification information and digital copyright information to determine the rule references and material references corresponding to the matters to be reviewed; Based on the rule references, material references, and corresponding rule matching results, the compliance assessment results, confidence information, and decision trajectory data are generated, and the compliance assessment results, confidence information, and decision trajectory data are associated to form the structured compliance data; The rule mapping data is used to perform the deterministic rule compilation on the structured compliance data.

3. The digital copyright confirmation method according to claim 2, characterized in that, The decision trajectory data includes rule references, material references, rule hit results, intermediate judgment results, and corresponding confidence information that are associated with the compliance assessment results. According to the process of generating the compliance assessment results, the rule references, material references, rule hit results and intermediate judgment results are sequentially associated to form a structured decision trajectory associated with the corresponding compliance assessment results.

4. The digital copyright confirmation method according to claim 3, characterized in that, The rule mapping data includes the mapping relationship between compliance assessment items and data types, operational relationships, judgment criteria, criticality, priority, repairability, and status impact; The step of performing deterministic rule compilation on the non-deterministic compliance assessment results in the structured compliance data based on the rule data includes: Determine the target mapping relationship from the rule mapping data to each compliance assessment item in the structured compliance data; Based on the data types, operational relationships, and judgment criteria in the target mapping relationship, the corresponding compliance assessment items are converted into judgment predicates; The decision predicates are organized based on their criticality and priority to generate the deterministic decision logic; The conversion relationship between the structured compliance data, the rule mapping data used, and the generated deterministic judgment logic is recorded to form the compilation trajectory data.

5. The digital copyright confirmation method according to claim 4, characterized in that, The judgment criteria include the judgment threshold for the compliance assessment item and the state boundary for the confidence information; The rule data also includes threshold configurations with configuration versions, and the threshold configurations are respectively associated with digital rights types and review rule base versions; Based on the digital copyright type to be confirmed and the version of the review rule base applicable to the current confirmation process, the judgment threshold and state boundary corresponding to the current confirmation process are determined from the threshold configuration, and the adopted threshold configuration version is associated with the compilation trajectory data and recorded.

6. The digital copyright confirmation method according to claim 5, characterized in that, The process states corresponding to the on-chain state machine include fully passed state, condition passed state, and failed state. The process status of the current rights confirmation process, determined based on the execution result of the deterministic judgment logic and the confidence information, includes: The criticality and repairability of each decision predicate are determined based on the rule mapping data, and the decision predicates are divided into critical decision predicates and non-critical decision predicates based on the criticality. When both the key determination predicate and the non-key determination predicate satisfy their corresponding determination conditions, and there are no undetermined determination predicates, and the confidence information reaches the state boundary corresponding to the fully passed state, the current rights confirmation process is determined to be in the fully passed state. If there are no irreparable key judgment predicates that do not meet the judgment conditions, and the confidence information reaches the state boundary corresponding to the condition pass state, then if there are repairable but undetermined key judgment predicates, key judgment predicates that do not meet the judgment conditions but are repairable, or non-key judgment predicates that do not meet the judgment conditions or are undetermined, or if both the key judgment predicates and the non-key judgment predicates meet the corresponding judgment conditions and the confidence information reaches the state boundary corresponding to the condition pass state but does not reach the state boundary corresponding to the fully pass state, then the current rights confirmation process is determined to be in the condition pass state. When the confidence information does not reach the state boundary corresponding to the condition pass state, or when there is an irreparable key judgment predicate that does not meet the judgment condition, or when there is an irreparable and undetermined key judgment predicate, the current rights confirmation process is determined to be in the non-pass state. The fully passed state and the conditionally passed state are used to control the current rights confirmation process to continue, while the failed state is used to control the current rights confirmation process to terminate.

7. The digital copyright confirmation method according to claim 6, characterized in that, When the current rights confirmation process is in the condition passed state, a condition list is generated based on at least one of the following: repairable but uncertain key judgment predicates, key judgment predicates that do not meet the judgment conditions but are repairable, non-key judgment predicates that do not meet the judgment conditions or are uncertain, and confidence information that reaches the state boundary corresponding to the condition passed state but does not reach the state boundary corresponding to the fully passed state. The evidence storage data corresponding to the condition list is added to the Merkle tree, and the current rights confirmation process is controlled to continue to advance. In response to receiving supplementary confirmation information corresponding to the condition list, the confirmation information corresponding to the current confirmation process is updated based on the supplementary confirmation information, and the AI ​​semantic processing, deterministic rule compilation and process status determination are re-executed based on the updated confirmation information to obtain the updated process status. A new state transition log is generated based on the updated process state, and the hash of the new state transition log is appended to the Merkle tree as a leaf node, so that the new state transition log and the state transition log corresponding to the condition form a state branch with sequential association.

8. The digital copyright confirmation method according to claim 6, characterized in that, After determining the process status of the current rights confirmation process each time, a state transition log is generated based on the previous process status, the current process status, the reference information of the structured compliance data that triggered this status determination in the Merkle tree, and the execution result of the deterministic determination logic. The hash value corresponding to the state transition log is added to the Merkle tree as a leaf node, and the updated Merkle root is determined based on the Merkle tree after the leaf node is added; Write the state data corresponding to the current process state, the log data corresponding to the state transition log, and the updated Merkle root in the same on-chain state transition transaction. If any write operation in the on-chain state transition transaction fails, all write operations in the on-chain state transition transaction are rolled back.

9. The digital copyright confirmation method according to claim 5, characterized in that, The compilation trajectory data also includes the compiler version identifier and rule mapping data version identifier used to execute the deterministic rule compilation; Version registration data is generated for different versions of compiler and rule mapping data. The version registration data is used to associate the corresponding version identifier, content hash, storage location index and effective time, and the version registration data is written into the blockchain network. When verifying the historical rights confirmation process, the corresponding compiler version identifier and rule mapping data version identifier are determined based on the compilation trajectory data of the historical rights confirmation process. The historical compiler and historical rule mapping data are obtained based on the corresponding version registration data and their content hashes are verified. Based on the verified historical compiler and historical rule mapping data, the structured compliance data corresponding to the historical rights confirmation process is recompiled for deterministic rules. The regenerated deterministic judgment result is compared with the evidence storage result of the historical rights confirmation process.

10. The digital copyright confirmation method according to claim 8, characterized in that, After the current rights confirmation process is completed, the target Merkle root of the Merkle tree corresponding to the current rights confirmation process and the leaf node corresponding to the evidence to be verified are obtained, and a Merkle proof path from the leaf node to the target Merkle root is generated according to the position of the leaf node in the Merkle tree. The Merkle proof path includes sibling node hashes and node position information used to determine the hash calculation relationship from the leaf node to the target Merkle root; When verifying the evidence data to be verified, the leaf node hash is determined based on the evidence data to be verified, and the verification Merkle root is calculated level by level according to the Merkle proof path. The verification Merkle root is then compared with the target Merkle root.

Images