Blockchain-driven data asset digitalization filing management method and system

Abstract

The present application relates to big data management technical field, specifically to alliance chain driven data asset digitization filing management method and system, including the following steps: extracting filing elements, proof materials and version information from filing application, establishing filing evidence association structure and generating filing version, determining responsibility domain and evidence path according to filing evidence association structure, generating hierarchical abstract and filing commitment package according to responsibility domain, generating sub-domain verification task according to alliance chain node responsibility domain mapping, receiving verification credentials, determining filing status according to credential integrity, version consistency and element conflict, writing filing commitment package, verification credentials and filing status into alliance chain, forming difference element set after receiving change application, determining affected responsibility domain and re-verifying. The present application makes node verification results correspond to content by associating filing elements, proof materials and responsibility domain, retains unaffected responsibility domain credentials and reduces repeated verification.

Description

Technical Field

[0001] This invention relates to the field of big data management technology, and in particular to a method and system for digital filing and management of data assets driven by consortium blockchain. Background Technology

[0002] The field of big data management technology involves technologies for the unified organization, management and utilization of massive amounts of data. It mainly revolves around the standardized application of data in the processes of collection, storage, processing, circulation and management, and ensures the orderly management of data resources in each business link by establishing corresponding data management mechanisms.

[0003] Among them, the data asset digital filing management method refers to a management method established for data asset filing business, which is used to register, review, maintain and manage relevant information in the data asset filing process, so that the data asset filing business can be processed in accordance with established rules.

[0004] Current data asset registration relies heavily on centralized platforms for registering and reviewing application materials. Registration elements and supporting documents are stored separately, and the relationships between materials and their versions are identified manually. The responsibilities of different review entities do not correspond to the specific registration content, and the review conclusions are difficult to link to specific elements and document versions. After changes to the registration content, all materials need to be re-verified. When the conclusions of multiple review entities are inconsistent, it is difficult to locate the source of the conflict. The registration results stored on the central platform are not sufficiently linked to the review process, which limits the traceability of registration responsibilities and the determination of the scope of changes. Summary of the Invention

[0005] The purpose of this invention is to provide a data asset digital filing management method and system driven by a consortium blockchain. By establishing the association between filing elements, supporting materials, and version information, the filing content is assigned to corresponding nodes for verification according to responsibility domains, and the filing status is determined based on the verification credentials. This establishes a corresponding relationship between the filing materials, the verification responsibility, the filing version, and the filing status. Simultaneously, when the filing content changes, the affected responsibility domain is identified and a partial re-verification is performed. This addresses the problems of unclear material associations, difficulty in corresponding node verification responsibilities to specific filing content, insufficient connection between filing status and verification results, and duplicate verification caused by partial changes during the data asset filing process.

[0006] To achieve the above objectives, this invention provides a consortium blockchain-driven method for digital filing and management of data assets, comprising the following steps: Extract filing elements and supporting materials from the filing application, read version information, establish a filing evidence association structure based on the reference relationship between the filing elements and the supporting materials, and generate a filing version based on the version information.

[0007] The responsibility domain is determined and the evidence path is extracted based on the record evidence association structure. A hierarchical summary is generated according to the responsibility domain. The hierarchical summary, the evidence path, and the record version constitute the record commitment package.

[0008] According to the consortium blockchain node responsibility domain mapping, the filing elements, the evidence path, the hierarchical summary, and the filing version are used to generate a domain-specific verification task, and the domain-specific verification task is sent to the corresponding node.

[0009] The system receives the verification credentials generated by the node for the domain verification task. When the necessary responsibility domain credentials are complete, the versions are consistent, and there are no element conflicts, a formal filing status is generated. When the necessary responsibility domain credentials are incomplete, a correction status is generated. When there are element conflicts, a conflict handling status is generated.

[0010] Write the filing commitment package, the verification certificate, and the filing status into the consortium blockchain.

[0011] Upon receiving a change request, the previous and subsequent versions of the filing elements are compared to obtain a set of differing elements. Based on the set of differing elements and the filing evidence association structure, the affected responsibility domains are determined. The affected responsibility domains are re-verified, and the certificates of the unaffected responsibility domains are retained.

[0012] Furthermore, when obtaining the filing elements, the supporting documents, and the version information, the filing object template is read from the preset storage space, the filing elements are extracted from the filing application according to the element fields in the filing object template, the supporting documents are associated with the corresponding filing elements according to the reference identifier of the supporting documents in the filing application, and the version information is read according to the material identifier and submission batch of the supporting documents.

[0013] Furthermore, when establishing the filing evidence association structure and generating the filing version, the filing element is used as the index item, and the supporting supporting materials for the filing element is used as the evidence item. The reference identifier and the version information are written into the association record between the index item and the evidence item. The filing version is generated based on the version information of each supporting material in the same submission batch, and the filing version is written into the filing evidence association structure.

[0014] Furthermore, when determining the domain of responsibility and extracting the evidence path, the mapping relationship between the filing element and the domain of responsibility is read from the preset storage space, each filing element is matched with the mapping relationship to obtain the domain of responsibility corresponding to each filing element, and the supporting materials, the citation relationship and the version information associated with each filing element are extracted sequentially from the filing evidence association structure, and the evidence path is formed according to the association order.

[0015] Furthermore, when generating the hierarchical summary and forming the filing commitment package, the filing elements are grouped according to the responsibility domains. Each group of filing elements corresponding to the responsibility domain is taken as a summary layer. The filing elements, supporting materials, evidence paths, and version information in the summary layer are summarized. The summary results of each summary layer are associated according to the responsibility domains to obtain the hierarchical summary. The hierarchical summary, the evidence path, and the filing version are associated and encapsulated according to the same filing application to obtain the filing commitment package.

[0016] Furthermore, when generating the domain-specific verification task and sending it to the node, the node responsibility domain mapping between the consortium blockchain node and the responsibility domain is read from the consortium blockchain configuration data. The responsibility domain is matched with the node responsibility domain mapping to determine the node responsible for verifying each responsibility domain. The filing elements, the evidence path, the hierarchical summary, and the filing version are associated and encapsulated according to each responsibility domain. The association and encapsulation results are bound to the corresponding node to obtain the domain-specific verification task. The domain-specific verification task is then sent to the corresponding node.

[0017] Further, the node extracts the filing element, the evidence path, the hierarchical summary, and the filing version from the received domain-specific verification task, obtains the corresponding supporting materials according to the evidence path, and regenerates the verification summary based on the supporting materials. When the verification summary matches the hierarchical summary and the version of the supporting materials matches the filing version, a verification pass conclusion is generated; otherwise, a verification fail conclusion is generated. The node identifier, the responsibility domain, the filing version, and the verification conclusion are associated and encapsulated to obtain the verification credential. The verification credentials generated by each node are summarized. When all necessary responsibility domains have a verification pass conclusion, each verification credential corresponds to the same filing version, and the same filing element does not have different verification conclusions, the formal filing status is determined. When the necessary responsibility domain lacks a verification pass conclusion, the correction status is determined. When the same filing element has different verification conclusions, the conflict handling status is determined.

[0018] Further, when writing the filing commitment package, the verification credential, and the filing status to the consortium blockchain, the filing commitment package, each verification credential corresponding to the filing version, and the filing status are associated and encapsulated into a filing write request according to the filing version. The filing write request is submitted to the consortium blockchain. It is verified whether the filing version corresponding to each verification credential is consistent with the filing version in the filing commitment package, and whether the filing status corresponds to the verification conclusion in each verification credential. When the filing versions are consistent and the filing status corresponds to the verification conclusion, the filing write request is written to the consortium blockchain. When the filing versions are inconsistent or the filing status does not correspond to the verification conclusion, the filing write request is rejected, and the writing result is associated with the filing version to obtain an on-chain filing record.

[0019] Further, upon receiving the change request, the changed filing elements and version information are extracted from the change request, and the filing elements corresponding to the current filing version are read from the preset storage space. The filing elements before and after the change are compared item by item. When at least one of the element content, associated supporting materials, or version information is inconsistent, the corresponding filing element is identified as a differing element. When all items are consistent, the corresponding filing element is identified as an unaffected element. The differing elements are then aggregated to obtain the differing element set. The filing evidence association structure is queried based on the differing element set to determine the responsibility domain associated with each differing element, and the affected responsibility domains are aggregated. The domain verification task is regenerated for the affected responsibility domains. The re-verification certificate generated by the corresponding node is received. If the filing element corresponding to the original verification certificate belongs to the unaffected element, the original verification certificate is retained; otherwise, the original verification certificate is invalidated. The re-verification certificate is associated with the retained original verification certificate to obtain the changed verification certificate set.

[0020] The present invention also provides a consortium blockchain-driven digital filing management system for data assets, used to implement the above-mentioned consortium blockchain-driven digital filing management method for data assets. The system includes a filing reconstruction module, a task orchestration module, a certificate processing module, a status control module, a change processing module, and a consortium link port.

[0021] The filing reconstruction module extracts the filing elements, supporting materials, and version information from the filing application, establishes the filing evidence association structure based on the reference relationship between the filing elements and the supporting materials, and generates the filing version based on the version information.

[0022] The task orchestration module determines the responsibility domain and the evidence path from the filing evidence association structure, generates the hierarchical summary according to the responsibility domain, and the filing commitment package is composed of the evidence path, the hierarchical summary and the filing version. The module generates the domain-specific verification task by mapping the filing elements and the filing commitment package according to the node responsibility domain, and sends it to the node.

[0023] The credential processing module receives the verification credential generated by the node for the domain verification task.

[0024] The status control module generates the formal filing status when the responsibility domain credentials are complete, the versions are consistent, and there are no conflicts of the elements; otherwise, it generates the correction status or the conflict handling status.

[0025] The change processing module determines the affected responsibility domain according to the version differences of the filing elements and the filing evidence association structure, and controls the task orchestration module to re-execute the verification of the affected responsibility domain.

[0026] The consortium link port writes the filing commitment package, the verification certificate, and the filing status into the consortium blockchain.

[0027] Compared with the prior art, the advantages and positive effects of the present invention are as follows: This invention establishes a filing evidence association structure based on the citation relationship between filing elements and supporting materials, and generates filing versions based on version information, thus ensuring a correspondence between filing content, supporting materials, and version relationships. It determines responsibility domains and evidence paths based on the filing evidence association structure, generates hierarchical summaries and filing commitment packages by responsibility domain, and then allocates domain-specific verification tasks based on the responsibility domain mapping of consortium blockchain nodes, ensuring that verification credentials correspond to specific filing elements, responsibility domains, and filing versions. The filing status is determined based on whether necessary responsibility domain credentials are complete, whether versions are consistent, and whether element conclusions conflict. Affected responsibility domains are identified through a set of differing elements; only affected responsibility domains are re-verified while unaffected responsibility domain credentials are retained, reducing redundant verification. Attached Figure Description

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

[0029] Figure 1 Flowchart of a data asset digital filing and management method driven by consortium blockchain; Figure 2Generate a data flow diagram for the relationship between the evidence and the commitment package for filing; Figure 3 The interaction diagram between the domain verification task and the node verification; Figure 4 Diagram illustrating the re-verification process for writes and changes in a consortium blockchain; Figure 5 A diagram showing the module relationships of a blockchain-driven data asset digitization filing and management system. Detailed Implementation

[0030] The following describes the data asset digitization filing management method and system driven by consortium blockchain, in conjunction with the technical solutions and accompanying drawings described in this invention. The following embodiments illustrate the association between filing elements, supporting materials, and version information after a filing application enters the processing flow, as well as the data flow relationships between the filing evidence association structure, filing version, responsibility domain, evidence path, hierarchical summary, filing commitment package, domain verification task, verification certificate, and filing status.

[0031] A filing application refers to a data set submitted to the data asset filing process, containing the content to be filed and corresponding supporting documents. Filing elements are the filing content extracted from the filing application according to the element fields of the filing object template. Supporting documents are the materials used to support the corresponding filing elements. Version information is the material version content read based on the material identifier and submission batch of the supporting documents.

[0032] The filing evidence association structure records the citation relationships between filing elements and supporting documents, and carries the citation identifier, version information, and filing version. The responsibility domain indicates the scope of verification responsibility corresponding to the filing element. The evidence path represents the data path starting from the filing element and sequentially associated with the supporting documents, citation relationships, and version information according to the filing evidence association structure.

[0033] A hierarchical summary represents a collection of summary results obtained by grouping the filing elements according to their responsibility domains and then summarizing the corresponding filing elements, supporting materials, evidence paths, and version information. A filing commitment package consists of hierarchical summaries, evidence paths, and filing versions associated with the same filing application.

[0034] The domain-based verification task is a task formed by associating and encapsulating the filing elements, evidence paths, hierarchical summaries, and filing versions according to the responsibility domains of the consortium blockchain nodes, and binding them to the corresponding nodes. The verification credential is data obtained by associating and encapsulating the node identifier, responsibility domain, filing version, and verification conclusion after the node completes the verification according to the domain-based verification task. Filing status includes formal filing status, correction status, and conflict resolution status.

[0035] The consortium blockchain node responsibility domain mapping is used to represent the correspondence between consortium blockchain nodes and responsibility domains. A node is a consortium blockchain node that undertakes the corresponding responsibility domain verification task according to the consortium blockchain node responsibility domain mapping. Pre-configured storage space is used to store the mapping relationship between the filing object template, filing elements, and responsibility domains, as well as the filing elements corresponding to the current filing version. Consortium blockchain configuration data is used to record the node responsibility domain mapping between consortium blockchain nodes and responsibility domains.

[0036] This implementation divides the method flow into five main steps, where S1 is used to form the filing evidence association structure and filing version, S2 is used to form the responsibility domain, evidence path, hierarchical summary and filing commitment package, S3 is used to generate and send the domain verification task, S4 is used to generate verification certificate and determine the filing status, and S5 is used to execute consortium blockchain writing and complete the identification of difference elements, determination of affected responsibility domain and local re-verification when a change application is received.

[0037] Figure 1 Used to illustrate the overall process from S1 to S5 Figure 2 This is used to illustrate the relationship between the evidence structure, the filing version, and the filing commitment package. Figure 3 This describes the node interaction relationship between the domain verification task and the verification credential. Figure 4 This is used to explain the processing relationship of partial re-verification after writing and modification in the consortium blockchain. Figure 5 Used to illustrate the module collaboration and data transfer relationships in the system.

[0038] Example 1 Please see Figures 1 to 4 This embodiment provides a consortium blockchain-driven method for digital filing management of data assets. In this embodiment, the filing application serves as the process input. First, a filing evidence association structure and a filing version are formed. Then, based on the filing evidence association structure, responsibility domains, evidence paths, hierarchical summaries, and filing commitment packages are formed. Subsequently, the domain-specific verification tasks are sent to the corresponding nodes, and the filing status is determined based on the verification credentials returned by the nodes. The filing commitment package, verification credentials, and filing status are written to the consortium blockchain after consistency verification. When a change application is received, the affected responsibility domains are determined based on the differences between the filing elements. Only the affected responsibility domains are re-verified, while credentials for unaffected responsibility domains are retained.

[0039] S1 extracts filing elements and supporting materials from the filing application, reads version information, establishes a filing evidence association structure based on the reference relationship between filing elements and supporting materials, and generates a filing version based on the version information.

[0040] S1 takes a filing application as input. The filing application includes filing content describing the data asset to be filed and supporting supporting documents. After the filing application enters the processing flow, a filing object template is read from the pre-built storage space. The filing object template contains element fields corresponding to the data asset filing content, and each element field is used to limit the filing content that needs to be extracted from the filing application.

[0041] S111: Read the filing object template from the pre-set storage space, and traverse the filing applications according to the element fields in the filing object template. When there is content in the filing application that corresponds to the element field, extract the corresponding content as a filing element, and retain the corresponding position and reference object of the filing element in the filing application.

[0042] If the content in the filing application does not correspond to any element field, the corresponding content will not be considered as a filing element in this filing process. All filing elements extracted from the element fields together form the filing element set corresponding to the current filing application. This filing element set is used to subsequently establish the filing evidence association structure, determine the responsibility domain, generate hierarchical summaries, form domain-specific verification tasks, and perform version difference comparisons.

[0043] S112, Identify the reference identifiers of supporting documents in the filing application. Reference identifiers indicate the citation relationship between supporting documents and corresponding filing elements. Based on the reference identifiers, each supporting document is associated with its corresponding filing element, thereby enabling a single filing element to point to the supporting documents used to support it, and allowing each supporting document to retain the citation relationship with its corresponding filing element.

[0044] The correlation processing does not change the original content of the supporting documents, but rather creates a corresponding record between the filing elements and the supporting documents. This corresponding record serves as input for establishing the correlation structure of the filing evidence, enabling subsequent determination of the domain of responsibility, extraction of evidence paths, and node verification to locate the corresponding supporting documents according to the filing elements.

[0045] S113. Retrieve version information based on the material identifier and submission batch of each supporting document. The material identifier is used to distinguish different supporting documents, and the submission batch is used to distinguish the set of materials submitted in this filing application. The retrieved version information is associated with the corresponding supporting document, and further associated with the corresponding filing element through the reference identifier, to obtain the filing element, supporting document, and version information.

[0046] S121, using the filing element as the index item and the supporting documentation for the filing element as the evidence item, writes the citation identifier and version information into the association record between the index item and the evidence item. A single index item is used to locate a single filing element, a single evidence item is used to locate the supporting documentation for the corresponding filing element, and the association record is used to store the citation relationship and version relationship between the two.

[0047] When a filing element corresponds to multiple supporting documents, evidence items corresponding to the multiple supporting documents are set up under the same index item, and the corresponding reference identifier and version information are written between each evidence item and the index item.

[0048] When a supporting document is referenced by multiple filing elements, evidence entries pointing to the supporting document are created under multiple index items, so that each filing element can locate the supporting document along the corresponding associated record.

[0049] S122, the index items, evidence items, and corresponding related records are collected according to the filing application to form a filing evidence association structure. The filing evidence association structure is bounded by the filing application and internally stores the association relationships between each filing element, corresponding supporting materials, citation identifiers, and version information.

[0050] Once the evidence association structure is formed, subsequent processing can start from the filing elements and locate the corresponding supporting materials and version information along the associated records.

[0051] S123, generate a filing version based on the version information of each supporting document within the same submission batch. The filing version is used to identify the overall version status of all filing elements and supporting documents under the same submission batch.

[0052] After generating the filing version, the filing version is written into the filing evidence association structure, so that the filing elements, supporting materials, citation relationships and version information in the filing evidence association structure correspond to the filing version.

[0053] The output of S1 includes filing elements, supporting documents, version information, filing evidence association structure, and filing version. By checking whether the supporting documents, citation identifiers, and version information corresponding to each filing element can be located in the filing evidence association structure, and by checking whether the filing version corresponds to the supporting documents in the same submission batch, it can be confirmed whether the data generated by S1 can proceed to subsequent processing.

[0054] S2. Determine the responsibility domain and extract the evidence path based on the association structure of the filing evidence, and generate a hierarchical summary according to the responsibility domain. The hierarchical summary, evidence path and filing version constitute the filing commitment package.

[0055] S2 takes the filing evidence association structure, filing elements, supporting materials, version information, and filing version output by S1 as input. S2 first determines the responsibility domain corresponding to each filing element based on the mapping relationship between the filing elements and the responsibility domain, then extracts the evidence path along the filing evidence association structure, and generates a hierarchical summary with the responsibility domain as the group boundary.

[0056] S211, Read the mapping relationship between filing elements and responsibility domains from the preset storage space. The mapping relationship is used to record the correspondence between element fields and responsibility domains in the filing object template. Match the element fields corresponding to each filing element with the mapping relationship. When a corresponding responsibility domain exists in the mapping relationship, the matched responsibility domain is determined as the responsibility domain of the corresponding filing element.

[0057] After matching, each filing element that enters the subsequent verification process has a corresponding responsibility domain. The responsibility domain is used to specify which node within which responsibility scope should verify the corresponding filing element, and is used to generate the summary layer and domain-specific verification tasks.

[0058] S212, starting with each filing element, read the index item corresponding to the filing element in the filing evidence association structure, and then locate the evidence item, supporting materials, citation relationship and version information in sequence along the association record from the index item.

[0059] The evidence path is composed of the filing elements, supporting materials, citation relationships, and version information, arranged in the order of association from index items to evidence items.

[0060] When a filing element corresponds to multiple supporting documents, the evidence path includes related branches leading from the same filing element to each of the multiple supporting documents. When multiple filing elements reference the same supporting document, each filing element forms its own evidence path containing corresponding citation relationships.

[0061] Through the evidence path, subsequent nodes can locate the supporting supporting materials for the filing elements from the filing elements to be verified, and determine the version information corresponding to the supporting materials.

[0062] S213, associate the responsibility domain corresponding to each filing element with the evidence path, so that the responsibility domain not only corresponds to the filing element, but also to the supporting supporting materials and version information of the filing element, thus obtaining the responsibility domain and evidence path.

[0063] S221, group the filing elements according to the responsibility domain, group filing elements corresponding to the same responsibility domain into the same filing element group, and treat each filing element group corresponding to the responsibility domain as a summary layer. Each summary layer contains the filing elements within the corresponding responsibility domain, as well as the supporting materials and version information located by the evidence path corresponding to each filing element.

[0064] S222: For each summary layer, the filing elements, supporting materials, evidence paths, and version information are summarized within the same processing scope. The input boundaries for summary processing are determined by the responsibility domain, ensuring that a single summary result corresponds only to the filing elements and corresponding supporting materials and version relationships within that single responsibility domain.

[0065] After each summarizing layer completes its summarizing process, it generates a summary result. The summary result of each summarizing layer is then associated with its corresponding responsibility domain. Finally, the summary results corresponding to each responsibility domain are aggregated to obtain a hierarchical summary. The hierarchical summary preserves the correspondence between the summary results and the responsibility domains, enabling nodes to locate the summary result corresponding to their own responsibility domain from the hierarchical summary.

[0066] S223, associating and encapsulating the hierarchical summary, evidence path, and filing version according to the same filing application. This associative encapsulation uses the filing application as a common object, ensuring that the summary results of each responsibility domain in the hierarchical summary, the evidence path, and the filing version all belong to the same filing process, resulting in a filing commitment package.

[0067] The filing commitment package serves as a common data object for subsequent node verification and consortium blockchain writing. The evidence path indicates the association between supporting materials and filing elements, the hierarchical summary provides a summary comparison object at the responsibility domain level, and the filing version limits the overall version corresponding to this verification and writing.

[0068] The completeness of S2's output can be verified by checking whether the filing commitment package simultaneously includes a hierarchical summary, evidence path, and filing version, and by checking whether the three correspond to the same filing application.

[0069] S3, based on the responsibility domain mapping of the consortium blockchain nodes, generates domain-specific verification tasks by mapping the filing elements, evidence paths, hierarchical summaries, and filing versions, and sends them to the nodes.

[0070] S3 takes the responsibility domain, evidence path, hierarchical summary, and filing commitment package output by S2, as well as the filing elements and filing version output by S1, as input. S3 determines the correspondence between responsibility domains and nodes through consortium blockchain configuration data, and then encapsulates and sends the domain-specific verification task according to the responsibility domain.

[0071] S311, Read the node responsibility domain mapping between consortium blockchain nodes and responsibility domains from the consortium blockchain configuration data. The node responsibility domain mapping records the responsibility domain that each node undertakes for verification. Match each responsibility domain determined in S2 above with the node responsibility domain mapping. When a responsibility domain has a corresponding node in the node responsibility domain mapping, determine the corresponding node as the node responsible for verifying the responsibility domain.

[0072] By matching, a task sending relationship is established between the responsibility domain and the node. The task sending relationship is used to determine the receiving node for each domain verification task.

[0073] S312, for each responsibility domain, select the filing elements belonging to the responsibility domain from the filing element set, select the path content corresponding to the filing elements from the evidence path, select the summary result corresponding to the responsibility domain from the hierarchical summary, and read the filing version.

[0074] The filing elements, evidence paths, corresponding summary results in the hierarchical summary, and filing version are associated and encapsulated to form task content corresponding to a single responsibility domain.

[0075] The task content is bound to the node responsible for verifying the corresponding domain. This binding ensures that the task content simultaneously has a clearly defined processing object, verification basis, summary comparison object, version boundary, and receiving node, resulting in a domain-specific verification task.

[0076] S313, each domain verification task is sent to the bound node. The sending direction of the domain verification task is determined by the node's responsibility domain mapping, and a single node receives the domain verification task corresponding to the responsibility domain undertaken by the node.

[0077] After receiving a domain-specific verification task, the node can extract the filing elements to be verified, the corresponding evidence path, the responsibility domain summary result, and the filing version from the domain-specific verification task.

[0078] Once all domain verification tasks have been sent to their corresponding nodes, the domain verification tasks received by each node are obtained. By verifying the correspondence between the responsibility domain in the domain verification task and the receiving node in the node responsibility domain mapping, and by verifying whether the filing elements, evidence paths, hierarchical summaries, and filing versions in the task content belong to the same filing application, the task sending relationship formed by S3 can be confirmed.

[0079] S4, the receiving node generates the verification certificate for the domain verification task. When the necessary responsibility domain certificates are complete, the versions are consistent and there are no element conflicts, a formal filing status is generated; otherwise, a correction status or conflict handling status is generated.

[0080] S4 uses the domain verification task received by each node as the node-side input and the verification credentials returned by the node as the input for the filing status determination process. The necessary responsibility domains are the set of responsibility domains determined based on the mapping relationship between the filing elements and responsibility domains in the current filing application.

[0081] S411, each node extracts the filing elements, evidence path, summary results of the corresponding responsibility domain in the hierarchical summary, and filing version from the received domain-specific verification task. The node locates the supporting materials corresponding to the filing elements to be verified according to the evidence path and reads the version of the supporting materials.

[0082] Each node reprocesses the filing elements, supporting materials, evidence paths, and version information within its responsibility domain according to the processing scope used when forming the corresponding summary layer, generating a verification summary. The verification summary has the same data range as the summary results of the corresponding responsibility domain in the hierarchical summary.

[0083] S412, compare the verification summary with the summary result of the corresponding responsibility domain in the hierarchical summary, and compare the version of the supporting materials with the filing version. When the verification summary matches the corresponding summary result, and the version of the supporting materials matches the filing version, a verification pass conclusion is generated.

[0084] When the verification summary is inconsistent with the corresponding summary result, or the version of the supporting materials is inconsistent with the filing version, a verification failure conclusion is generated. Verification success and verification failure conclusions are different verification results; the node determines one of the verification conclusions based on the comparison results of the two.

[0085] S413, associate and encapsulate the node identifier of the node performing the verification, the responsibility domain undertaken by the node, the filing version in the domain verification task, and the generated verification conclusion to obtain the verification certificate.

[0086] The node identifier in the verification certificate is used to identify the verification subject, the responsibility domain is used to determine the verification scope, the filing version is used to determine the version to which the verification object belongs, and the verification conclusion is used to participate in the filing status determination.

[0087] S421, Summarize the verification credentials generated by each node, and compare the responsibility domains in the verification credentials with the necessary responsibility domains corresponding to the current filing application. When each necessary responsibility domain has a corresponding verification credential, and each verification credential for each necessary responsibility domain contains a verification pass conclusion, it is determined that the necessary responsibility domain credentials are complete.

[0088] When at least one necessary responsibility domain lacks a verification certificate, or when the verification certificate corresponding to a necessary responsibility domain contains a verification failure conclusion, it is determined that the necessary responsibility domain lacks a verification success conclusion, and a correction status is generated.

[0089] S422, provided that all necessary responsibility domain credentials are complete, compare the filing version in each verification credential. If each verification credential corresponds to the same filing version, and the filing version matches the filing version in the filing commitment package, then the versions are determined to be identical.

[0090] When at least one verification certificate corresponds to a filing version that is different from other verification certificates or different from the filing version in the filing commitment package, a formal filing status will not be generated, and the corresponding filing content will be included in the correction status.

[0091] S423, summarize the verification conclusions related to the filing elements according to the filing elements, and compare the verification conclusions corresponding to the same filing element. When the verification conclusions corresponding to the same filing element are consistent, it is determined that there are no different verification conclusions for the filing elements.

[0092] When the same filing element corresponds to both a pass and a fail verification result, an element conflict is determined, and a conflict resolution status is generated.

[0093] When all necessary responsibility domains have passed verification conclusions, each verification certificate corresponds to the same filing version, and there are no different verification conclusions for the same filing element, the formal filing status is determined. When necessary responsibility domains lack passing verification conclusions or the filing versions are inconsistent, the rectification status is determined. When the same filing element has different verification conclusions, the conflict resolution status is determined, and the filing status is obtained.

[0094] The output of S4 is the verification credentials generated by each node and the filing status determined based on the verification credentials. By checking whether the formal filing status simultaneously satisfies the requirements of complete necessary responsibility domain credentials, consistent versions, and no element conflicts, checking whether the correction status corresponds to a necessary responsibility domain lacking a verification pass conclusion or having inconsistent versions, and checking whether the conflict handling status corresponds to different verification conclusions for the same filing element, the correspondence between the filing status and the node verification results can be verified.

[0095] S5 writes the filing commitment package, verification certificate, and filing status into the consortium blockchain. When a change application is received, it compares the previous and current versions of the filing elements to obtain a set of differences in elements. Based on the set of differences in elements and the filing evidence association structure, it determines the affected responsibility domain, re-verifies the affected responsibility domain, and retains the certificates of the unaffected responsibility domain.

[0096] S5 includes consortium blockchain write processing and partial re-verification processing after changes. The consortium blockchain write processing takes the filing commitment package generated in S2 and the verification certificate and filing status generated in S4 as inputs. The partial re-verification processing is triggered when a change request corresponding to the filed version is received.

[0097] S511, according to the filing version, associates and encapsulates the filing commitment package, each verification credential corresponding to the filing version, and the filing status to form a filing write request. The filing write request uses the filing version as the association basis, so that the filing commitment package, verification credential, and filing status in the filing write request all correspond to the same version.

[0098] S512, submit the filing request to the consortium blockchain. After receiving the filing request, the consortium blockchain verifies whether the filing version corresponding to each verification credential is consistent with the filing version in the filing commitment package. After completing the version verification, it further verifies whether the filing status corresponds to the verification conclusion in each verification credential.

[0099] When the filing status is formal filing status, the necessary responsibility domain verification credentials in the filing write request should be complete, each verification credential should correspond to the same filing version, and there should be no different verification conclusions corresponding to the same filing element.

[0100] When the filing status is in the rectification stage, the verification certificate summary results show instances where necessary responsibility fields lack verification pass conclusions or where filing versions are inconsistent. When the filing status is in the conflict handling stage, the verification certificate summary results show instances where the same filing element corresponds to different verification conclusions.

[0101] S513 When the filing version corresponding to each verification certificate is consistent with the filing version in the filing commitment package, and the filing status corresponds to the verification conclusion in the verification certificate, the filing write request is written to the consortium blockchain.

[0102] The write request is rejected if at least one verification credential corresponds to a filing version that is inconsistent with the filing version in the filing commitment package, or if the filing status does not correspond to the verification conclusion in the verification credential. The write rejection result is used to prevent data with inconsistent version relationships or whose status does not correspond to the verification conclusion from forming on-chain filing records.

[0103] S514 associates the write result with the filing version. When the filing write request is completed, the write result is used to indicate that the filing commitment package, verification certificate, and filing status have been formed into on-chain records according to the corresponding filing version.

[0104] When a write request for a record filing is rejected, the write result indicates that the current write request has not resulted in a corresponding on-chain record. The write result of a completed write is then associated with the record filing version to obtain the on-chain record filing.

[0105] The on-chain filing records maintain the correspondence between the filing commitment package, verification certificate, filing status, and filing version. By reading the on-chain filing records and verifying the filing version, verification certificate, and filing status, it is possible to verify whether the data written to the consortium blockchain originates from the same filing process.

[0106] S521: When a change request is received, the changed filing elements and version information are extracted from the change request, and the filing elements corresponding to the current filing version are read from the preset storage space.

[0107] The modified filing elements are matched with the filing elements corresponding to the current filing version according to the same element fields, so that the filing elements before and after the same element field can be compared item by item.

[0108] S522, compare each filing element before and after the change. This comparison includes comparing the element content, supporting documentation associated with the filing element, and version information. If at least one of the element content, associated supporting documentation, or version information is inconsistent, the corresponding filing element is identified as the differing element.

[0109] When the content, associated supporting documents, and version information of the same element field are all consistent, the corresponding filing element will be identified as an unaffected element. Difference elements and unaffected elements are mutually exclusive; the same filing element will be classified into one of them in the same change comparison.

[0110] Summarize all discrepancy elements to obtain a discrepancy element set. The discrepancy element set serves as input to determine the affected responsibility domains, while the unaffected elements serve as input to determine whether the original verification documents can be retained.

[0111] S523, query the filing evidence association structure based on the set of difference elements. Using each difference element as an index, locate the corresponding supporting materials, citation relationships, and responsibility domains in the filing evidence association structure, and determine the responsibility domain associated with each difference element.

[0112] Summarize the responsibility domains associated with each difference element to obtain the affected responsibility domains. The affected responsibility domains are used to define the scope of re-validation. Responsibility domains not associated with any difference element are not included in the affected responsibility domains.

[0113] S524, regenerate the domain verification task for the affected responsibility domain. The regeneration process follows the node responsibility domain mapping between responsibility domains and nodes, associates and encapsulates the filing elements, evidence paths, hierarchical summaries, and filing versions corresponding to the affected responsibility domain, and sends the association and encapsulation results to the corresponding nodes.

[0114] The corresponding node performs verification based on the regenerated domain verification task and returns a re-verification certificate. The re-verification certificate is used to replace the original verification certificate in the affected responsibility domain that no longer corresponds to the changed filing content.

[0115] S525 matches the filing elements corresponding to each original verification certificate with the unaffected elements. If the filing element corresponding to the original verification certificate is an unaffected element, the original verification certificate is retained.

[0116] When the filing element corresponding to the original verification certificate is not an unaffected element, the original verification certificate becomes invalid. Invalidation prevents the original verification certificate related to the differing element from participating in the post-change filing status determination. Retention ensures that unchanged filing elements do not need to undergo repeated verification within the same responsibility domain.

[0117] S526, the re-verification documents are associated with the retained original verification documents according to the changed filing elements and responsibility domains to obtain the changed verification document set. In the changed verification document set, the affected responsibility domains correspond to the re-verification documents, and the unaffected responsibility domains correspond to the retained original verification documents.

[0118] By checking whether the set of differences in elements contains filing elements whose content, related supporting materials, or version information have changed, checking whether the affected responsibility domain can be determined by the difference in elements along the filing evidence association structure, and checking whether the set of changed verification certificates consists of re-verification certificates and original verification certificates that meet the retention conditions, the partial re-verification results in S5 can be verified.

[0119] Through S1 to S5, the filing elements, supporting materials, and version information in the filing application first form a filing evidence association structure with citation and version relationships, and then form evidence paths, hierarchical summaries, and filing commitment packages according to the responsibility domain.

[0120] Domain-specific verification tasks are sent to nodes according to the node responsibility domain mapping. The verification credentials returned by the nodes are used to determine the filing status. Before being written to the consortium blockchain, the correspondence between the filing version and status is checked. When changes occur, the scope of re-verification is limited by the set of difference elements and the filing evidence association structure, and a revised set of verification credentials is formed.

[0121] Example 2 Please see Figure 5 This embodiment provides a data asset digital filing management system driven by a consortium blockchain. The difference between this embodiment and Embodiment 1 is that this embodiment uses module collaboration and data transfer relationships to carry out the method flow of Embodiment 1. The system includes a filing reconstruction module, a task orchestration module, a certificate processing module, a status control module, a change processing module, and a consortium link interface.

[0122] The filing reconstruction module receives filing applications and extracts filing elements, supporting documents, and version information from them. Based on the reference relationships between filing elements and supporting documents, the module establishes a filing evidence association structure and generates a filing version based on the version information.

[0123] The filing reconstruction module generates a filing evidence association structure that includes filing elements, supporting documents, citation relationships, version information, and the relationships between filing versions. The filing reconstruction module then outputs the filing elements, supporting documents, version information, filing evidence association structure, and filing versions to the task orchestration module.

[0124] The task orchestration module receives the filing elements, filing evidence association structure, and filing version output by the filing reconstruction module, determines the responsibility domain from the filing evidence association structure, and extracts the evidence path.

[0125] The task orchestration module groups the filing elements according to responsibility domains, and performs summary processing on the filing elements, supporting materials, evidence paths and version information corresponding to each responsibility domain to generate hierarchical summaries.

[0126] The task orchestration module associates evidence paths, hierarchical summaries, and filing versions according to the same filing application, forming a filing commitment package. The task orchestration module further reads the node responsibility domain mapping, matches responsibility domains with nodes, and associates and encapsulates the filing elements and corresponding content in the filing commitment package into domain-specific verification tasks according to the responsibility domains.

[0127] The task orchestration module sends each domain verification task to the corresponding node. Upon receiving a domain verification task, the node verifies the filing elements, evidence path, hierarchical summary, and filing version within the task and generates a verification certificate. The verification certificate is then sent by the node to the certificate processing module.

[0128] The credential processing module receives verification credentials generated by nodes for domain-specific verification tasks and aggregates the verification credentials returned by each node according to the filing application and filing version. The credential processing module outputs the aggregated verification credentials to the status control module and simultaneously outputs the verification credentials to the alliance connection port.

[0129] The status control module receives the verification credentials output by the credential processing module, checks whether all necessary responsibility domains have a verification pass conclusion, checks whether each verification credential corresponds to the same filing version, and checks whether there are different verification conclusions for the same filing element.

[0130] When all necessary responsibility domains have passed verification, each verification certificate corresponds to the same filing version, and the same filing element does not have different verification conclusions, the status control module generates a formal filing status.

[0131] When a necessary responsibility domain lacks a verification pass conclusion or the filing version is inconsistent, the status control module generates a correction status. When the same filing element has different verification conclusions, the status control module generates a conflict resolution status.

[0132] The status control module outputs the generated filing status to the consortium connection port. The task orchestration module outputs the filing commitment package to the consortium connection port. The credential processing module outputs the verification credential to the consortium connection port.

[0133] The consortium link interface encapsulates the filing commitment package, verification certificate, and filing status into a filing write request according to the filing version, and submits the filing write request to the consortium blockchain.

[0134] The alliance link interface verifies whether the filing version corresponding to each verification certificate is consistent with the filing version in the filing commitment package, and verifies whether the filing status corresponds to the verification conclusion in each verification certificate.

[0135] When the filing version is consistent and the filing status corresponds to the verification conclusion, the consortium link port will write the filing request to the consortium blockchain. When the filing version is inconsistent or the filing status does not correspond to the verification conclusion, the consortium link port will refuse to write the filing request.

[0136] The alliance link will associate the written results with the filing version to form an on-chain filing record.

[0137] The change processing module receives change requests and extracts the revised filing elements and version information from them. The module then reads the filing elements corresponding to the current filing version and compares each element before and after the change.

[0138] When at least one of the following elements—content, associated supporting documents, or version information—is inconsistent, the change processing module will identify the corresponding filing element as a differing element. When all elements are consistent, the change processing module will identify the corresponding filing element as an unaffected element.

[0139] The change processing module summarizes the discrepancies to obtain a set of discrepancies. Based on this set of discrepancies, the module queries the relationship structure of the filing evidence, determines the responsibility domains associated with the discrepancies, and summarizes them to obtain the affected responsibility domains.

[0140] The change processing module sends the affected responsibility domains to the task orchestration module and controls the task orchestration module to regenerate the domain verification tasks for the affected responsibility domains.

[0141] The task orchestration module sends the regenerated domain verification task to the corresponding node, and the voucher processing module receives the re-verification voucher generated by the corresponding node.

[0142] The change processing module determines whether to retain the original verification certificate or invalidate it based on whether the filing element corresponding to the original verification certificate belongs to an unaffected element. It then associates the re-verification certificate with the retained original verification certificate to obtain the set of changed verification certificates.

[0143] The system forms a complete processing chain through data transfer between modules. The filing reconstruction module outputs the filing evidence association structure and filing version; the task orchestration module outputs the filing commitment package and domain-specific verification tasks; nodes output verification credentials; the credential processing module summarizes the verification credentials; the status control module outputs the filing status; the consortium link port outputs the on-chain filing records; and the change processing module outputs the affected responsibility domains and the set of changed verification credentials.

[0144] The above embodiments illustrate the formation and calling relationships between filing applications, filing elements, supporting materials, version information, filing evidence association structure, filing version, responsibility domain, evidence path, hierarchical summary, filing commitment package, domain verification task, node, verification certificate, filing status, difference element set, and affected responsibility domain.

[0145] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A data asset digital filing and management method driven by consortium blockchain, characterized in that, Includes the following steps: Extract filing elements and supporting materials from the filing application, read version information, establish a filing evidence association structure based on the reference relationship between the filing elements and the supporting materials, and generate a filing version based on the version information; Based on the aforementioned recordation evidence association structure, the responsibility domain is determined and the evidence path is extracted. A hierarchical summary is generated according to the responsibility domain, and the hierarchical summary, the evidence path, and the recordation version constitute the recordation commitment package. Based on the responsibility domain mapping of the consortium blockchain node, the filing elements, the evidence path, the hierarchical summary, and the filing version are used to generate a domain-specific verification task and send it to the node; Receive the verification credentials generated by the node for the domain verification task. When the necessary responsibility domain credentials are complete, the versions are consistent and there are no element conflicts, a formal filing status is generated; otherwise, a correction status or conflict handling status is generated. Write the filing commitment package, the verification certificate, and the filing status into the consortium blockchain; Upon receiving a change request, the different versions of the filing elements are compared to obtain a set of differences. The affected responsibility domains are determined based on the set of differences and the filing evidence association structure. The affected responsibility domains are re-verified, and the certificates of the unaffected responsibility domains are retained.

2. The data asset digitization filing and management method driven by consortium blockchain according to claim 1, characterized in that, The process of obtaining the filing elements, the supporting documents, and the version information is as follows: Read the filing object template from the pre-set storage space, and extract the filing elements from the filing application according to the element fields in the filing object template; Based on the reference identifier of the supporting documents in the filing application, the supporting documents are associated with the corresponding filing element, and the version information is read based on the material identifier and submission batch of the supporting documents to obtain the filing element, the supporting documents, and the version information.

3. The data asset digitization filing and management method driven by consortium blockchain according to claim 2, characterized in that, The process of establishing the aforementioned record-filing evidence association structure and generating the record-filing version is as follows: Using the filing element as an index item and the supporting documentation for the filing element as evidence item, the reference identifier and the version information are written into the association record between the index item and the evidence item; The filing version is generated based on the version information of each of the supporting documents in the same batch of submissions, and the filing version is written into the filing evidence association structure to obtain the filing evidence association structure and the filing version.

4. The data asset digitization filing and management method driven by consortium blockchain according to claim 1, characterized in that, The process of determining the domain of responsibility and extracting the evidence path is as follows: The mapping relationship between the filing elements and the responsibility domains is read from the preset storage space, and each filing element is matched with the mapping relationship to obtain the responsibility domain corresponding to each filing element; Starting with each of the filing elements, the supporting materials, citation relationships, and version information associated with each of the filing elements are extracted sequentially from the filing evidence association structure, and the evidence path is formed according to the association order to obtain the responsibility domain and the evidence path.

5. The data asset digitization filing and management method driven by consortium blockchain according to claim 4, characterized in that, The process of generating the hierarchical summary and forming the filing commitment package is as follows: The filing elements are grouped according to the responsibility domains, and each group of filing elements corresponding to the responsibility domain is used as a summary layer. The filing elements, supporting materials, evidence paths and version information in the summary layer are summarized. The summary results of each summary layer are associated according to the responsibility domain to obtain the hierarchical summary; The hierarchical summary, the evidence path, and the filing version are associated and packaged according to the same filing application to obtain the filing commitment package.

6. The data asset digital filing and management method driven by consortium blockchain according to claim 1, characterized in that, The process of generating the domain verification task and sending it to the node is as follows: Read the node responsibility domain mapping between consortium blockchain nodes and responsibility domains from the consortium blockchain configuration data, match the responsibility domains with the node responsibility domain mappings, and determine the node responsible for verifying each responsibility domain; The filing elements, evidence paths, hierarchical summaries, and filing versions are associated and encapsulated according to each of the responsibility domains, and the association and encapsulation results are bound to the corresponding nodes to obtain the domain-specific verification task. The domain verification task is sent to the corresponding node, and the domain verification task is received by each node.

7. The data asset digital filing and management method driven by consortium blockchain according to claim 6, characterized in that, The process of generating the verification certificate and determining the filing status is as follows: Each node extracts the filing elements, the evidence path, the hierarchical summary, and the filing version from the received domain verification task, obtains the corresponding supporting materials according to the evidence path, and regenerates the verification summary based on the supporting materials; When the verification summary is consistent with the hierarchical summary and the version of the supporting materials is consistent with the filing version, a verification pass conclusion is generated; otherwise, a verification fail conclusion is generated. The node identifier, the responsibility domain, the filing version, and the verification conclusion are associated and encapsulated to obtain the verification credential. The verification credentials generated by each node are summarized. When all necessary responsibility domains have a verification pass conclusion, each verification credential corresponds to the same filing version, and there are no different verification conclusions for the same filing element, the formal filing status is determined. When a necessary responsibility domain lacks a verification pass conclusion, the correction status is determined. When there are different verification conclusions for the same filing element, the conflict handling status is determined, and the filing status is obtained.

8. The data asset digital filing and management method driven by consortium blockchain according to claim 1, characterized in that, The process of writing the filing commitment package, the verification certificate, and the filing status into the consortium blockchain is as follows: According to the filing version, the filing commitment package, each verification credential corresponding to the filing version, and the filing status are associated and encapsulated into a filing write request; The filing request is submitted to the consortium blockchain, and it is verified whether the filing version corresponding to each verification certificate is consistent with the filing version in the filing commitment package, and whether the filing status corresponds to the verification conclusion in each verification certificate. When the filing version is consistent and the filing status corresponds to the verification conclusion, the filing write request is written to the consortium blockchain; when the filing version is inconsistent or the filing status does not correspond to the verification conclusion, the filing write request is rejected. The write result is associated with the filing version to obtain the on-chain filing record.

9. The data asset digitization filing and management method driven by consortium blockchain according to claim 1, characterized in that, The process of forming the set of differences, determining the affected responsibility domains, and completing the re-verification is as follows: Extract the changed filing elements and version information from the change application, and read the filing elements corresponding to the current filing version from the preset storage space; Compare the filing elements before and after the change item by item. When at least one of the element content, the associated supporting materials or version information is inconsistent, the corresponding filing element is determined as the difference element. When all items are consistent, the corresponding filing element is determined as the unaffected element. The difference elements are summarized to obtain the difference element set. Based on the set of differences, query the filing evidence association structure to determine the responsibility domain associated with each difference element, and summarize to obtain the affected responsibility domain; Regenerate the domain verification task for the affected responsibility domain, receive the re-verification certificate generated by the corresponding node, retain the original verification certificate when the filing element corresponding to the original verification certificate belongs to the unaffected element, otherwise make the original verification certificate invalid. The re-verification credentials are associated with the retained original verification credentials to obtain the modified set of verification credentials.

10. A data asset digital filing and management system driven by a consortium blockchain, characterized in that: The system is used to implement the blockchain-driven data asset digital filing management method according to any one of claims 1-9, the system comprising: The filing reconstruction module extracts filing elements, supporting materials, and version information from the filing application, establishes a filing evidence association structure based on the citation relationship between the filing elements and the supporting materials, and generates a filing version based on the version information. The task orchestration module determines the responsibility domain and evidence path from the filing evidence association structure, generates a hierarchical summary according to the responsibility domain, and the filing commitment package is composed of the evidence path, the hierarchical summary and the filing version. The module generates a domain-specific verification task by mapping the filing elements and the filing commitment package according to the node responsibility domain and sends it to the node. The credential processing module receives the verification credential generated by the node for the domain verification task; The status control module generates a formal filing status when the responsibility domain credentials are complete, the versions are consistent, and there are no element conflicts; otherwise, it generates a correction status or a conflict handling status. The change processing module determines the affected responsibility domains based on the version differences of the filing elements and the association structure of the filing evidence, and controls the task scheduling module to recalibrate the affected responsibility domains. The consortium link interface writes the filing commitment package, the verification certificate, and the filing status into the consortium blockchain.

Images