Metadata registration and retrieval, providing method and device for ai audiovisual training data

Abstract

This application discloses a method and apparatus for registering, retrieving, and providing metadata for AI audiovisual training data. The data center-side method includes: receiving and registering a registration request from a metadata owner, registering their identity information, retrieval interface address, and metadata template information; receiving a query retrieval request from a metadata requester based on the metadata template; filtering registered records according to the retrieval request, accessing the retrieval interface of a matching metadata owner, receiving the returned metadata set information, and returning it to the metadata requester. The metadata owner-side method includes: storing metadata locally based on a unified metadata template; receiving a query retrieval request sent by the data center, filtering local metadata, and returning the matching metadata set information. The metadata template includes a Merkle tree structure, a root node hash value field, and an AIGC identifier field. The integrity and trustworthiness of the metadata are ensured through Merkle tree verification and blockchain anchoring.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence training data management technology, and in particular to a method and apparatus for registering, retrieving, and providing metadata for AI audiovisual training data. Background Technology

[0002] With the rapid development of large-scale modeling technology, the broadcasting and audiovisual industry faces a demand for massive amounts of high-quality AI training data. The quality, traceability, and compliance of AI training data directly affect the performance and credibility of artificial intelligence models. In AI training data trading scenarios, there are two main participants: metadata providers (sellers) and metadata demanders, typically model trainers (buyers). Metadata providers possess a large amount of metadata resources for audiovisual programs and wish to trade this data; model trainers need to acquire training data metadata that meets specific requirements for the training and optimization of AI models.

[0003] However, the current trading of metadata for AI training data faces numerous technical challenges. First, different metadata providers use inconsistent methods for tagging metadata, with different institutions employing different metadata standards and field definitions, resulting in significant differences in the semantics and format of the metadata. Second, model trainers have varying needs for metadata; different training tasks have different requirements for data quality, content type, and technical parameters. Due to the lack of a unified metadata standard and evaluation system, it is difficult to establish an effective matching mechanism between metadata providers and model trainers, hindering unified evaluation and retrieval.

[0004] In existing technologies, centralized data exchange models require institutions to upload their data to a centralized platform for unified storage, management, and distribution. Under this model, data needs to be physically migrated to a central node, and the original institutions lose direct control over their data. Centralized storage of copyright-sensitive audiovisual content can easily lead to leakage risks, and real-time synchronization between the central copy and the institution's local data is difficult. This model sacrifices the data provider's data sovereignty and fails to meet the stringent data security and privacy protection requirements of the broadcasting industry.

[0005] The federated search model allows institutions to retain local data storage and achieve cross-database retrieval through protocols. However, different institutions use different metadata standards, requiring complex query translation and format mapping, resulting in metadata template heterogeneity issues. This model lacks a mechanism for reviewing metadata quality, making it impossible to guarantee the compliance of training data and preventing AIGC content from being mixed into the training set. Furthermore, this model cannot track the entire data lifecycle from collection and annotation to use, making it difficult to meet the traceability requirements of relevant national laws and regulations regarding the source of training data.

[0006] Existing AIGC tagging technologies specify the tagging requirements for AIGC content, but they are mainly static, recording only basic information such as "whether it was generated by AIGC," lacking dynamic correlation with the training data usage scenarios. This technology lacks cryptographic mechanisms such as Merkle trees, making it unable to verify the integrity of content fragments and vulnerable to partial tampering for model attacks. Tagging data is typically stored centrally or scattered across files, failing to support cross-institutional training data retrieval needs.

[0007] In summary, existing technologies suffer from the following problems: inconsistent metadata tagging methods, with different standards adopted by various institutions leading to semantic and format differences; a lack of a neutral third-party unified registration and retrieval mechanism, hindering standardized metadata retrieval across institutions; centralized architectures sacrifice data sovereignty, while federated search models suffer from metadata template heterogeneity and lack governance mechanisms; a lack of metadata integrity verification mechanisms fails to prevent data tampering or contamination; and the lack of mandatory labeling for AIGC content makes it difficult to prevent recursive contamination from "training AI with AI-generated content." Therefore, a new technical solution is needed to achieve standardized metadata retrieval across institutions while maintaining the physical distribution of data. This solution should unify metadata standards and provide retrieval services through a neutral third-party mechanism, establish a metadata integrity verification mechanism, and achieve a balance between data sovereignty protection and interoperability. Summary of the Invention

[0008] The purpose of this application is to provide a method, apparatus, and system for registering and retrieving metadata of AI audiovisual training data, so as to solve some or all of the following technical problems existing in the prior art: (1) The metadata tagging method is not uniform, and different institutions use different standards, which makes it impossible to conduct unified evaluation and retrieval; (2) The lack of a neutral third-party unified registration and retrieval mechanism makes it impossible to achieve standardized metadata retrieval across institutions; (3) Centralized architecture sacrifices data sovereignty, and data providers lose control over the data; (4) The lack of a verification mechanism for the integrity of metadata makes it impossible to prevent data from being tampered with; (5) The lack of AIGC content identification makes it difficult to prevent AIGC from polluting the training data.

[0009] (6) No independent Merkle tree was constructed for each program, making it impossible to achieve accurate segment-level verification; (7) The application does not employ a dual-blockchain anchoring model of program root on-chain and batch root, thus failing to provide judicial-grade evidence preservation. To achieve one of the above objectives, this application adopts the following technical solution: Firstly, this application provides a method for registering and retrieving metadata for AI audiovisual training data. The method is executed by a data center and includes the following steps: receiving a registration request from a metadata owner and registering the metadata owner, wherein the registration information includes the metadata owner's identity information, metadata retrieval interface address information, and metadata template information, forming a corresponding registration record; receiving a query and retrieval request from a metadata requester, wherein the query and retrieval request includes retrieval request information formulated by the metadata requester based on the definitions of various fields specified in the metadata template, so as to filter metadata based on the retrieval request information in the query and retrieval steps; executing the query and retrieval, filtering the registration records according to the retrieval request information formulated by the metadata requester, filtering out metadata owners that match the retrieval request information, accessing the retrieval interface address of the matching metadata owner, further receiving a set of metadata information that matches the information filtered and returned by the metadata owner according to the retrieval request information formulated by the metadata requester, and returning the set of information to the metadata requester.

[0010] By adopting a "centralized registration + distributed storage" architecture, the system achieves physically immobile data and logically unified retrieval. The metadata owner retains ownership and storage control of the data, which is always stored locally, eliminating the need for physical migration to a data center and avoiding loss of data sovereignty and compliance risks. Simultaneously, a unified metadata template ensures semantic consistency during cross-organizational retrieval, resolving the issue of inconsistent metadata tagging methods. The data center, acting as a neutral third party, provides registration and retrieval routing services, enabling standardized metadata retrieval across organizations.

[0011] Furthermore, the metadata template includes fields for storing the complete Merkle tree structure and the root node hash value. The Merkle tree is constructed independently for each individual audiovisual program, segmenting the program content into spatiotemporal slices. The hash value of each slice is calculated and used as a leaf node. If the number of segments is not a power of 2, the last leaf is copied to pad to 2^2. log2N Construct the program-level Merkle tree from bottom to top and calculate the hash value of the program-level Merkle root node; The method further includes: performing fragment-level integrity verification on the metadata corresponding to the set information returned by the query retrieval step based on the Merkle tree and the root node hash value. The fragment-level integrity verification includes: obtaining the hash value of the target fragment and the path nodes from the fragment to the Merkle root; calculating the hash layer by layer upward along the path, using the left node hash first and the right node hash last; comparing the final hash value with the Merkle root, and if they match, the verification is successful.

[0012] The Merkle tree verification mechanism enables fragment-level integrity verification. Any tampering with a content fragment will cause a change in the fragment's hash value, which in turn causes a change in the hash values ​​of all parent nodes from the leaf node to the root node, ultimately resulting in a change in the Merkle root hash value. By comparing the Merkle root hash value, the verifier can quickly detect whether metadata has been tampered with, preventing poisoning attacks and data pollution, and ensuring the credibility of AI training data.

[0013] Furthermore, the metadata template includes a seven-dimensional metadata structure: basic information, technical parameters, content semantics, visual features, audio features, copyright / pedigree / AIGC identifier, and distributed registration and retrieval information; wherein the AIGC identifier is used to record whether the corresponding metadata is AIGC and / or the degree of AI participation.

[0014] By mandating the inclusion of AIGC identifiers in the metadata template, mandatory identification of AIGC content is achieved. Metadata requesters can filter training data that meets the requirements based on AIGC identifiers, avoiding recursive pollution of "training AI with AI-generated content" and improving the quality and credibility of training data.

[0015] Secondly, this application provides a method for providing metadata for AI audiovisual training data. The method is performed by the metadata owner and includes the following steps: storing metadata in a local metadata database, wherein the metadata is defined and marked based on a specific metadata template; receiving all or part of a query retrieval request sent by a data center through a predetermined retrieval interface, wherein the query retrieval request includes retrieval request information formulated by the metadata requester based on the definitions of various fields specified in the metadata template; filtering the metadata in the metadata database; and returning the metadata set information that matches the retrieval request information to the data center.

[0016] Metadata owners tag and store metadata locally according to a unified metadata template, without needing to upload the data to a data center, thus preserving ownership and control of the data. When the data center sends a query request, the metadata owner only needs to filter matching metadata locally and return the metadata set information, enabling cross-organizational retrieval while keeping the data physically immobile.

[0017] Furthermore, the method also includes: a program-level Merkle tree construction step, which involves slicing a single audiovisual program into segments according to spatiotemporal dimensions, calculating the hash value of each segment as a leaf node, and copying the last leaf node to pad to 2^2 if the number of segments is not a power of 2. log2N The program-level Merkle tree is constructed from bottom to top, and the program-level Merkle root hash value is calculated. The metadata template contains fields for storing the complete structure of the Merkle tree and the hash value of the root node. All metadata of the audiovisual training data records the complete structure of the Merkle tree and the hash value of the root node of the audiovisual training data, so that the metadata requester or data center can perform fragment-level integrity verification of the metadata.

[0018] The metadata owner constructs a program-level Merkle tree locally, dividing the audiovisual training data into segments by time or scene, calculating the hash value of each segment as a leaf node, and building the Merkle tree from bottom to top. The complete structure of the Merkle tree and the hash value of the root node are recorded in the metadata, providing a basis for verification for metadata requesters or data centers, ensuring the integrity and reliability of the data.

[0019] Furthermore, the method also includes: a blockchain dual-anchoring step, in which the Merkle root of a single program is written into a first blockchain evidence storage platform to obtain an evidence identifier; the first blockchain evidence storage platform packages multiple programs into batch Merkle trees in a predetermined manner, and writes the hash value of the root node of the batch Merkle tree into a second blockchain evidence storage platform to form judicial-grade evidence storage, so that the metadata requester or data center can verify the metadata through the first and / or second blockchain evidence storage platforms.

[0020] By employing a dual-anchoring mechanism on the blockchain, the hash value of the Merkle tree root node is calculated layer by layer and written to multiple blockchain evidence storage platforms. Leveraging the immutability of blockchain, this provides legally valid proof of the existence of training data, supporting judicial evidence in data transaction disputes. The blockchain anchoring mechanism provides a foundation of trust for training data transactions, promoting the healthy development of the data element market.

[0021] Thirdly, this application provides a metadata registration and retrieval device for AI audiovisual training data. The device is deployed in a data center and includes: a registration module for receiving registration requests from metadata owners and registering them. The registration information includes the metadata owner's identity information, metadata retrieval interface address information, and metadata template information, forming corresponding registration records; a request receiving module for receiving query and retrieval requests from metadata requesters. These requests include retrieval request information defined by the metadata requester based on the definitions of various fields specified in the metadata template; a query and retrieval module for filtering registration records according to the retrieval request information defined by the metadata requester, filtering out metadata owners that match the retrieval request information, accessing the retrieval interface address of the matching metadata owner, receiving metadata set information returned by the metadata owner that matches the retrieval request information, and returning this set information to the metadata requester; and an intelligent routing module for filtering unqualified data based on institutional support dimensions, node online status, training applicability, and AIGC tags.

[0022] Furthermore, the metadata template includes fields for storing the complete Merkle tree structure and the root node hash value. The Merkle tree is constructed independently for each individual audiovisual program, segmenting the program content into spatiotemporal slices. The hash value of each slice is calculated and used as a leaf node. If the number of slices is not a power of 2, the last leaf is copied to pad to 2^2. log2N The device is obtained by constructing a program-level Merkle tree from bottom to top and calculating the hash value of the root node. The device also includes a verification module, which is used to perform fragment-level integrity verification on the metadata corresponding to the metadata set information returned by the query and retrieval module based on the Merkle tree and the hash value of the root node. The fragment-level integrity verification includes: obtaining the hash value of the target fragment and the path nodes from the fragment to the Merkle root; calculating the hash layer by layer upward along the path, using the left node hash first and the right node hash last in the calculation; comparing the final hash value with the Merkle root, and if they match, the verification is successful.

[0023] Furthermore, the metadata template includes a seven-dimensional metadata structure: basic information, technical parameters, content semantics, visual features, audio features, copyright / pedigree / AIGC identifier, and distributed registration and retrieval information; wherein the AIGC identifier is used to record whether the corresponding metadata is AIGC and / or the degree of AI participation.

[0024] Fourthly, this application provides a metadata provision device for AI audiovisual training data. The device is deployed on the metadata owner side and includes: a storage module for storing metadata in a local metadata database, wherein the metadata is defined and marked based on a specific metadata template; and a response module for receiving a query retrieval request sent by a data center via a pre-determined retrieval interface, wherein the query retrieval request includes retrieval request information formulated by the metadata requester based on the definitions of various fields specified in the metadata template, filtering the metadata in the metadata database, and returning the metadata set information matching the retrieval request information to the data center.

[0025] Furthermore, the device also includes: a program-level Merkle tree construction module, which segments a single audiovisual program into segments according to spatiotemporal dimensions, calculates the hash value of each segment as a leaf node, and if the number of segments is not a power of 2, copies the last leaf node to pad to 2^2. log2N The program-level Merkle tree is constructed from bottom to top, and the program-level Merkle root hash value is calculated. The metadata template includes fields for storing the complete structure of the Merkle tree and the hash value of the root node. All metadata of the audiovisual training data records the complete structure of the Merkle tree and the hash value of the root node of the audiovisual training data, so that the metadata requester or data center can perform fragment-level integrity verification of the metadata.

[0026] Furthermore, the device also includes: a blockchain dual-anchor module, which writes the Merkle root of a single program into a first blockchain evidence storage platform to obtain an evidence identifier; the first blockchain evidence storage platform packages multiple programs into batch Merkle trees in a predetermined manner, and writes the hash value of the root node of the batch Merkle tree into a second blockchain evidence storage platform to form judicial-grade evidence storage, so that the metadata requester or data center can verify the metadata through the first and / or second blockchain evidence storage platforms.

[0027] Compared with the prior art, this application has the following beneficial effects: (1) Balancing data sovereignty and interoperability. Through the architecture of "centralized registration + distributed storage", the metadata owner retains ownership and storage control of the data. The data is always stored locally and does not need to be physically migrated to the data center, thus avoiding loss of data sovereignty and compliance risks. At the same time, through a unified metadata template, semantic consistency is ensured when searching across institutions, realizing the retrieval of data while keeping it physically still and logically unified.

[0028] (2) Achieve standardized metadata retrieval across organizations. The data center, as a neutral third party, provides registration and retrieval routing services, unifies metadata standards, and distributes retrieval requests and aggregates results. Metadata owners mark data according to a unified metadata template, and metadata requesters formulate retrieval requests based on unified field definitions, thus achieving standardized metadata retrieval across organizations and solving the problem of inconsistent metadata marking methods.

[0029] (3) Provide a metadata fragment-level integrity verification mechanism. Through Merkle tree verification and blockchain anchoring, an immutable link for metadata is established. Any tampering with a content fragment will cause a change in the Merkle root hash value. The verifier can quickly detect whether the metadata has been tampered with, prevent poisoning attacks and data pollution, and ensure the credibility of AI training data.

[0030] (4) Mandatory AIGC labeling prevents recursive pollution. By mandating the inclusion of AIGC labels in the metadata template, mandatory labeling of AIGC content is achieved. Metadata requesters can filter training data that meets the requirements based on AIGC labels, avoiding recursive pollution of "training AI with AI-generated content" and improving the quality of training data.

[0031] (5) Supporting judicial-level data ownership confirmation. Through a dual-blockchain anchoring mechanism, the hash value of the Merkle tree root node is calculated layer by layer and written to multiple blockchain evidence storage platforms, providing legally valid proof of existence for training data, supporting judicial evidence in data transaction disputes, and promoting the healthy development of the data element market. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the architecture of the AI ​​audiovisual training data metadata registration and retrieval system provided in the embodiments of this application.

[0033] Figure 2 This is a flowchart illustrating the data center-side metadata registration and retrieval method provided in this application embodiment.

[0034] Figure 3 This is a flowchart illustrating the method for providing metadata on the owner's side in an embodiment of this application.

[0035] Figure 4 This is a schematic diagram of the Merkle tree construction process provided in an embodiment of this application. Detailed Implementation

[0036] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0037] It should be understood that in the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. In this embodiment, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" can explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "multiple" means two or more.

[0038] It should be noted that the technical terms in the following embodiments are defined as follows: Metadata owner refers to the organization or individual that owns the audiovisual training data metadata resources, usually broadcasting institutions, content producers, etc.; Data center refers to the organization that provides metadata registration and retrieval services as a neutral third party, responsible for maintaining registration records and executing retrieval routes; Metadata demander refers to the organization or individual that needs to obtain training data metadata, usually AI model trainers, research institutions, etc.; Metadata template refers to the standard specification that defines the metadata structure and fields, specifying the various fields that metadata should include and their definitions; Merkle tree refers to a cryptographic verification tree structure used to verify data integrity; AIGC refers to artificial intelligence generated content.

[0039] Example 1 like Figure 1 As shown in the figure, this embodiment provides an AI audiovisual training data metadata registration, retrieval and metadata provision system, which includes three main participants: data center, metadata owner and metadata requester.

[0040] The metadata registration and retrieval device 102 for AI audiovisual training data is deployed in a data center. The data center, acting as a neutral third party, provides metadata registration and retrieval services using cloud or industry alliance servers. The data center includes a registration module 1021, a request receiving module 1022, a query retrieval module 1023, and a verification module 1024. The registration module 1021 receives registration requests from metadata owners, stores the metadata owner's identity information, metadata retrieval interface address information, and metadata template information, and forms registration records. The metadata owner's identity information can be identified using a unified social credit code, organization name, contact information, etc. The metadata retrieval interface address information is the URL address of the query service interface provided by the metadata owner, through which the data center communicates with the metadata owner. The metadata template information includes the metadata template version used by the metadata owner, a list of supported fields, etc. Registration records are stored in a structured data format, such as JSON or XML, to facilitate subsequent retrieval and matching. The request receiving module 1022 receives query retrieval requests for metadata from metadata requesters 103 and parses the retrieval request information in the requests. The query and retrieval module 1023 is used to filter registration records based on the retrieval request information, find the metadata owner that matches the retrieval request information, access the retrieval interface address of the matching metadata owner, receive the metadata set information returned by the metadata owner, and return the set information to the metadata requester. The intelligent routing module 1025 is used to filter unqualified data based on the institution's support dimension, node online status, training applicability, and AIGC tags. In a further embodiment, the device also includes a verification module 1024 used to verify the metadata corresponding to the returned metadata set information based on the Merkle tree and the root node hash value, ensuring the integrity and reliability of the metadata.

[0041] The metadata providing device 101 for AI audiovisual training data is deployed locally on the metadata owner's side. The metadata owner, such as broadcasting organizations or content producers, is responsible for tagging and storing metadata according to a unified metadata template and responding to query and retrieval requests from the data center. The device includes a storage module 1011 and a response module 1012; in further embodiments, it may also include a Merkle tree construction module 1013 and a blockchain dual-anchoring module 1014. The storage module 1011 stores metadata in a local metadata database, where the metadata is defined and tagged based on a specific metadata template. The local metadata database can be stored using a system-level database (such as MySQL or PostgreSQL) or a document-level database (such as MongoDB or Elasticsearch). The response module 1012 receives query and retrieval requests sent by the data center through a pre-defined retrieval interface, filters the metadata in the metadata database, and returns a set of metadata matching the retrieval request information to the data center. The retrieval interface can be implemented using, for example, a RESTful API, supporting HTTP POST requests. In a further embodiment, the device further includes a program-level Merkle tree construction module 1013, which segments a single audiovisual program into segments according to spatiotemporal dimensions, calculates the hash value of each segment as a leaf node, and if the number of segments is not a power of 2, copies the last leaf node to pad to 2^2. log2N The program-level Merkle tree is constructed from bottom to top, and the hash value of the program-level Merkle root is calculated. The metadata template includes fields for storing the complete structure of the Merkle tree and the hash value of the root node. It also includes a blockchain dual-anchoring module 1014 for writing the Merkle root of a single program to a first blockchain evidence storage platform to obtain an evidence identifier. The first blockchain evidence storage platform packages multiple programs into batch Merkle trees according to a predetermined method, and writes the hash value of the root node of the batch Merkle tree to a second blockchain evidence storage platform, forming judicial-grade evidence storage. This allows metadata requesters or data centers to verify the metadata through the first and / or second blockchain evidence storage platforms. The first blockchain evidence storage platform can be an enterprise, industry, or regional blockchain evidence storage platform, and the second blockchain evidence storage platform can be a blockchain evidence storage platform with judicial verification capabilities, such as the Tianping Chain or the Netcom Law Chain.

[0042] Metadata requester 103, representing AI model training providers or research institutions, is responsible for submitting query requests to the data center to obtain metadata sets that meet their requirements. Based on their own training task needs, the metadata requester formulates its query request information according to the definitions of each field specified in the metadata template. The query request information may include filtering conditions such as content type, quality requirements, technical parameters, and AIGC identifiers. The metadata requester submits its query request through the query interface provided by the data center and receives the metadata set information returned by the data center. The metadata requester can verify the metadata based on the Merkle tree and the root node hash value to ensure the integrity and reliability of the metadata.

[0043] like Figure 2 As shown, this embodiment provides a method for metadata registration and retrieval on the data center side, including the following steps: S201: Receive the registration request from the metadata owner and register the metadata owner.

[0044] The data center's registration module receives registration requests submitted by metadata owners. These requests include the metadata owner's identity information, metadata retrieval interface address information, and metadata template information. The metadata owner's identity information includes the Unified Social Credit Code, organization name, contact person, contact number, and email address. The metadata retrieval interface address information includes the interface URL, authentication method (e.g., API key, OAuth token), and supported request methods (e.g., POST, GET). The metadata template information includes the metadata template version number, a list of supported fields, field data types, and field constraints.

[0045] In one embodiment, the metadata template includes a seven-dimensional metadata structure: basic information, technical parameters, content semantics, visual features, audio features, copyright / pedigree / AIGC identifier, and distributed registration and retrieval information; wherein the AIGC identifier is used to record whether the corresponding metadata is AIGC and / or the degree of AI participation.

[0046] The registration module verifies registration requests, checking the authenticity and legality of the metadata owner's identity information, verifying the accessibility of the metadata retrieval interface address, and checking the completeness and standardization of the metadata template information. Upon successful verification, the registration module generates a unique registration identifier (such as a UUID), stores the registration information in the registration record database, and forms the corresponding registration record. The registration record is stored in a structured data format and includes the following fields: registration identifier, metadata owner's identity information, metadata retrieval interface address information, metadata template information, registration time, and registration status (such as registered or deregistered).

[0047] For example, a broadcasting organization A submits a registration request to the data center, providing its unified social credit code "91110000XXXXXXXXXX", organization name "XX Broadcasting Station", search interface address "https: / / api.broadcaster-a.com / metadata / search", and metadata template version "v1.0". The data center verifies that organization A's identity information is authentic and valid, the search interface address is accessible, and the metadata template information is complete and standardized, generates a registration identifier "owner-001", and stores the registration information in the registration record database.

[0048] S202: Receive metadata query and retrieval requests from metadata requesters.

[0049] The data center's request receiving module receives query and retrieval requests submitted by metadata requesters. These requests include retrieval information defined by the metadata requester based on the fields specified in the metadata template. The retrieval request information may include the following filtering conditions: content type (e.g., news, documentary, variety show), quality requirements (e.g., resolution, encoding format, frame rate), technical parameters (e.g., duration, file size), AIGC identifier (e.g., whether it is AIGC, degree of AI participation), copyright information (e.g., copyright owner, licensing method), etc.

[0050] The request receiving module parses the query request, extracts the various filter conditions from the request information, and verifies the legality and validity of the filter conditions. Once verification is successful, the request receiving module forwards the query request information to the query module for processing.

[0051] For example, an AI model training provider, B, submits a query request to the data center, requesting metadata for content type "news," resolution "1920x1080," and AIGC identifier "no." The request receiving module parses the query request, extracts the filtering conditions: content type = "news," resolution = "1920x1080," and AIGC identifier = "no," verifies the validity of the filtering conditions, and then transmits the retrieval request information to the query module.

[0052] S203: Execute queries and retrievals, filter matching metadata owners, and access their retrieval interfaces.

[0053] The data center's query and retrieval module filters registration records based on the retrieval request information specified by the metadata requester. The filtering process includes the following steps: First, the query and retrieval module reads the registration records of all registered metadata owners from the registration record database. Second, based on the filtering conditions in the retrieval request information, the module performs preliminary screening of the registration records, excluding metadata owners that clearly do not meet the criteria. For example, it excludes metadata owners whose retrieval interface is inaccessible or who are offline, or whose retrieval request requires the content type to be "news," thus excluding metadata owners whose metadata template does not support the "content type" field or whose field value does not contain "news."

[0054] After filtering out the metadata owners that match the retrieval request information, the query retrieval module accesses the retrieval interface address of the matching metadata owners. The access process includes the following steps: First, the query and retrieval module constructs a query request based on the retrieval interface address information of the metadata owner. The query request uses the HTTP POST method, and the request body contains all or part of the filtering conditions for the retrieval request information. The query request can be encoded in JSON or XML format.

[0055] Secondly, the query and retrieval module sends a query request to the metadata owner's retrieval interface. The query request may include authentication information (such as API keys or OAuth tokens) to verify the identity and permissions of the data center.

[0056] Then, the query retrieval module receives the query response returned by the metadata owner. The query response contains a set of metadata information that the metadata owner has filtered and returned based on the retrieval request information, matching that information. The metadata set information may include the metadata's identifier, title, content type, quality parameters, technical parameters, AIGC identifier, copyright information, Merkle tree root node hash value, etc.

[0057] Finally, the query and retrieval module aggregates and organizes the received metadata sets. If multiple metadata owners return metadata sets, the query and retrieval module merges these pieces of information, removes duplicates, and sorts them according to certain sorting rules (such as quality rating and relevance score).

[0058] For example, the query and retrieval module, based on the retrieval request information (content type = "news", resolution = "1920x1080", AIGC identifier = "no"), filters out metadata owner A and metadata owner C from the registration record database. The query and retrieval module sends a query request to metadata owner A's retrieval interface "https: / / api.broadcaster-a.com / metadata / search", with the request body containing the filtering conditions. Metadata owner A returns 300 metadata records that meet the conditions. The query and retrieval module sends a query request to metadata owner C's retrieval interface "https: / / api.broadcaster-c.com / metadata / search", and metadata owner C returns 200 metadata records that meet the conditions. The query and retrieval module aggregates and organizes these 500 metadata records, sorts them according to quality rating, and generates the final metadata set information.

[0059] S204: Return the metadata collection information to the metadata requester.

[0060] The query and retrieval module returns the aggregated and organized metadata set to the metadata requester. The returned metadata set can be encoded in JSON or XML format and includes detailed metadata information and source identifiers. After receiving the metadata set, the metadata requester can further filter and use it according to their needs.

[0061] For example, the query and retrieval module returns a metadata set containing 500 metadata records to metadata requester B. Metadata requester B receives the metadata set, views the details of each metadata record, and selects 300 metadata records for AI model training.

[0062] Subsequently, optionally, S105 may also be included: verifying the metadata based on the Merkle tree and the root node hash value.

[0063] The data center's verification module or metadata requester can verify the metadata based on the Merkle tree and root node hash value contained in the metadata set information, ensuring the integrity and trustworthiness of the metadata. The verification process includes the following steps: First, the verification module extracts the complete Merkle tree structure and the root node hash value from the metadata collection information. The complete Merkle tree structure includes the hash values ​​of all leaf nodes, the hash values ​​of intermediate nodes, and the hash value of the root node.

[0064] Secondly, the verification module recalculates the Merkle tree based on the audiovisual training data corresponding to the metadata. The recalculation process includes dividing the audiovisual training data into segments using the same slicing method, calculating the hash value of each segment as a leaf node, and recursively calculating the hash value of the parent node from bottom to top until the root node hash value is generated.

[0065] The verification module then compares the recalculated root node hash value with the root node hash value recorded in the metadata. If they match, it means the audiovisual training data corresponding to the metadata has not been tampered with, and the verification passes. If they do not match, it means the audiovisual training data corresponding to the metadata has been tampered with or the metadata record is incorrect, and the verification fails.

[0066] For fragment-level verification, the verification module can obtain the fingerprint hash of the target fragment and the path nodes from the fragment to the Merkle root. It calculates the current hash upwards along the path. If the current node is a right child node, it concatenates the hash value of the sibling node with the current hash value before performing the hash calculation. If it is a left child node, it concatenates the current hash value with the hash value of the sibling node before performing the hash calculation. That is, the calculation adopts the order of left node hash first and right node hash last. The final hash value is compared with the Merkle root. If they match, the verification is successful.

[0067] For example, metadata requester B verifies 300 selected metadata entries. For the first metadata entry, requester B extracts the Merkle tree root node hash value "a1b2c3d4e5f6...", recalculates the Merkle tree based on the corresponding audiovisual training data, and obtains the root node hash value "a1b2c3d4e5f6...". The two hash values ​​match, so the verification passes. For the second metadata entry, the recalculated root node hash value does not match the recorded root node hash value, so the verification fails, and requester B abandons the use of this metadata entry.

[0068] like Figure 3 As shown, this embodiment provides a method for providing metadata on the metadata owner's side, including the following steps: S301: Store metadata in the local metadata database.

[0069] The metadata owner's storage module stores metadata in a local metadata database. Metadata is defined and marked based on a specific metadata template. The metadata template specifies the various fields that metadata should include and their definitions, including basic information fields (such as identifier, title, duration, creation date), technical parameter fields (such as resolution, encoding format, frame rate, bit rate), content semantic fields (such as content type, scene, characters, subtitles), copyright fields (such as copyright owner, licensing method, AIGC identifier fields (such as whether it is AIGC, degree of AI participation), Merkle tree fields (such as the complete structure of the Merkle tree, root node hash value), blockchain anchoring fields (such as blockchain evidence certificates)), audio features, visual features, and registration and retrieval information fields (used to record metadata owner information and query retrieval interface information), etc.

[0070] The metadata owner tags the local audiovisual training data according to the field definitions in the metadata template, populating the values ​​of each field. The tagging process can be manual, automatic, or semi-automatic. Manual tagging involves professionals manually filling in metadata fields based on the content and characteristics of the audiovisual training data. Automatic tagging utilizes technologies such as computer vision and natural language processing to automatically extract features from the audiovisual training data and populate the metadata fields. Semi-automatic tagging combines manual and automatic tagging; the automatic tagging system first generates preliminary metadata, which is then manually reviewed and corrected.

[0071] After tagging is complete, the storage module stores the metadata in a local metadata database. The local metadata database can be a relational database (such as MySQL or PostgreSQL) or a document-oriented database (such as MongoDB or Elasticsearch). The metadata is stored in a structured data format for easy retrieval and querying later.

[0072] For example, metadata owner A tags a news video, populating the metadata fields: Identifier = "video-001", Title = "Earthquake occurred in XX region", Duration = "120 seconds", Resolution = "1920x1080", Encoding Format = "H.264", Content Type = "News", AIGC Identifier = "No". The storage module stores this metadata in the local metadata database.

[0073] S302: Receive query and retrieval requests sent by the data center.

[0074] The metadata owner's response module receives query requests sent by the data center via a pre-defined retrieval interface. This retrieval interface can be implemented using a RESTful API and supports receiving query requests via HTTP POST. The query request includes retrieval request information specified by the metadata requester based on the definitions of each field defined in the metadata template.

[0075] The response module parses the received query request and extracts various filtering conditions from the request information. These filtering conditions may include content type, quality requirements, technical parameters, AIGC identifier, copyright information, etc. The response module verifies the legality and validity of the filtering conditions, ensuring that they conform to the field definitions in the metadata template.

[0076] For example, the search interface "https: / / api.broadcaster-a.com / metadata / search" of metadata owner A receives a query request from the data center. The request body includes filter conditions: content type = "news", resolution = "1920x1080", and AIGC identifier = "no". The response module parses the query request, extracts the filter conditions, and verifies that the filter conditions are valid.

[0077] S303: Filter local metadata and return the matching metadata set information.

[0078] The response module filters metadata in the local metadata database based on the filtering criteria in the retrieval request information. The filtering process includes the following steps: First, the response module reads all metadata records from the local metadata database. Second, the response module compares each metadata record against the filtering criteria to determine if it meets the requirements. The comparison rules can include exact matching, range matching, and fuzzy matching. For example, the content type field uses exact matching, the duration field uses range matching, and the title field uses fuzzy matching.

[0079] Then, the response module filters out the metadata records that meet the filtering criteria and generates metadata collection information. The metadata collection information contains detailed information about the metadata, such as identifier, title, content type, quality parameters, technical parameters, AIGC identifier, copyright information, and Merkle tree root node hash value.

[0080] Finally, the response module returns the metadata collection information to the data center. The returned metadata collection information is encoded in a format such as JSON or XML and returned to the data center via an HTTP response.

[0081] For example, the response module filters 300 metadata records that meet the filtering criteria (content type = "news", resolution = "1920x1080", AIGC identifier = "no") from the local metadata database. The response module generates metadata set information, which contains detailed information about these 300 metadata records, encodes the metadata set information in JSON format, and returns it to the data center via HTTP response.

[0082] In a further embodiment, step S301 further includes: step S3011 constructing a program-level Merkle tree and calculating the root node hash value.

[0083] The program-level Merkle tree building module for metadata owners is used to segment individual audiovisual programs spatiotemporally. For each segment, its hash value is calculated and used as a leaf node. If the number of segments is not a power of 2, the last leaf node is copied to pad to 2^2. log2N The program-level Merkle tree is constructed from bottom to top, and the program-level Merkle root hash value is calculated. The Merkle tree construction process is as follows: Figure 4 As shown, it includes the following steps: First, the program-level Merkle tree construction module segments individual audiovisual programs according to fixed durations or scene boundaries. Fixed-duration segmentation divides the audiovisual training data into segments every 3 minutes or 5 minutes. Scene boundary segmentation segments the data based on camera cuts or scene changes. The purpose of segmentation is to break down large files into smaller segments, facilitating hash value calculation and Merkle tree construction.

[0084] Secondly, the program-level Merkle tree construction module calculates the hash value of each slice segment, which serves as the leaf node of the Merkle tree. The hash value can be calculated using, for example, the SM3 hash algorithm. SM3 is a national cryptographic algorithm issued by the State Cryptography Administration, offering higher security and meeting national security requirements. The hash values ​​of the N leaf nodes are calculated as Hash(S001), Hash(S002), ..., Hash(S_N).

[0085] Then, the Merkle tree building module recursively calculates the hash value of the parent node from bottom to top until the root node hash value is generated. If the number of segments N is not a power of 2, the last leaf is copied to pad to a power of 2 leaf nodes. The parent node hash value is obtained by performing an SM3 hash calculation by concatenating the hash values ​​of the left and right child nodes. Specifically, for the j-th node at level i, its hash value is calculated as: Hash(Node_i_j) = SM3(Hash(Node_{i-1}_{2j}) || Hash(Node_{i-1}_{2j+1})), where || represents the hash value concatenation operation.

[0086] Finally, the program-level Merkle tree building module generates the hash value of the root node of the Merkle tree, i.e., the Merkle root. The Merkle root is the hash value of the top-level node of the entire Merkle tree, representing the integrity fingerprint of the entire audiovisual program.

[0087] For example, metadata owner A segments a 15-minute news video into 5 segments, each 3 minutes long, numbered S001 to S005. The Merkle tree building module calculates the SM3 hash value of each segment, resulting in the hash values ​​of 5 leaf nodes: Hash(S001), Hash(S002), Hash(S003), Hash(S004), and Hash(S005). Since the number of segments, 5, is not a power of 2, the last leaf node Hash(S005) is copied to S006, S007, and S008, making a total of 8 leaf nodes. The Merkle tree building module recursively calculates the hash values ​​of the parent nodes from bottom to top, generating the root node hash value MerkleRoot of the Merkle tree.

[0088] After S3011, proceed to step S3012: record the complete Merkle tree structure and root node hash value in the metadata.

[0089] The metadata template contains fields for storing the complete Merkle tree structure and the root node hash value. All metadata for this audiovisual training data records the complete Merkle tree structure and root node hash value of the audiovisual training data, allowing metadata requesters or data centers to perform fragment-level integrity verification of the metadata.

[0090] The complete Merkle tree structure includes the hash values ​​of all leaf nodes, intermediate nodes, and the root node. The complete Merkle tree structure can be encoded in JSON or XML format and stored in the Merkle tree field of the metadata. The root node hash value is stored separately in the root node hash value field of the metadata for easy access and verification.

[0091] For example, metadata owner A records the complete Merkle tree structure of the news video and the hash value of the root node in the metadata. The Merkle tree field of the metadata contains the hash values ​​of all leaf nodes and intermediate nodes, and the root node hash value field stores the value of MerkleRoot.

[0092] After S3012, proceed to step S3013: write the hash value of the Merkle tree root node into the first blockchain storage platform.

[0093] The metadata owner's blockchain dual-anchor module writes the Merkle tree root node hash value corresponding to the audiovisual training data into a first blockchain evidence storage platform to obtain evidence identification. The first blockchain evidence storage platform packages multiple programs into batch Merkle trees according to a predetermined method, such as a fixed time period, and writes the batch Merkle tree root node hash value into a second blockchain evidence storage platform, forming judicial-grade evidence storage. This allows the metadata requester or data center to verify the metadata through the first and / or second blockchain evidence storage platforms. The first blockchain evidence storage platform can be an enterprise, industry, or regional blockchain evidence storage platform, and the second blockchain evidence storage platform can be a blockchain evidence storage platform with judicial verification capabilities, such as the Tianping Chain or the Netcom Legal Chain.

[0094] The blockchain dual-anchoring process includes the following steps: First, the blockchain dual-anchor module calls the interface of the blockchain evidence storage platform to submit an evidence storage application. The evidence storage application includes the business type (such as "ai_training_data"), content fingerprint (i.e., the hash value of the root node of the Merkle tree), and extended information (such as metadata identifier and metadata owner identifier).

[0095] Secondly, after receiving the evidence storage application, the First Blockchain Evidence Storage Platform performs identity verification and data validation, verifying the applicant's digital signature and the format of the Merkle root hash value. Once the verification is successful, the First Blockchain Evidence Storage Platform writes the evidence storage record to the blockchain, generating a unique evidence storage credential (such as EvidenceID).

[0096] Then, the first blockchain-based evidence storage platform returns the evidence storage certificate to the metadata owner. The metadata owner then stores the evidence storage certificate in the blockchain anchor field of the metadata.

[0097] Finally, the first blockchain evidence storage platform periodically calculates the batch Merkler root hash and stores it on the second blockchain evidence storage platform (such as the Beijing Internet Court's Tianping Chain or the Guangzhou Internet Court's Wangtong Fa Chain). After confirmation by the second blockchain evidence storage platform, the anchoring information is populated into the blockchain anchoring field of the metadata, including the batch transaction hash, Merkle verification path, and batch index.

[0098] The timing flow of the three-party interaction in this embodiment is as follows.

[0099] Sequence 1: The metadata owner submits a registration request to the data center, the data center registers the data and returns a confirmation of successful registration.

[0100] Sequence 2: The metadata owner marks and stores metadata locally according to the metadata template, constructs a Merkle tree and calculates the root node hash value, records the Merkle tree information in the metadata, and writes the Merkle root hash value into the blockchain evidence storage platform.

[0101] Time Sequence 3: The metadata requester submits a query request to the data center, which includes retrieval request information based on the metadata template.

[0102] Timeline 4: The data center filters the registration records based on the retrieval request information and finds the matching metadata owner.

[0103] Timeline 5: The data center sends a query request to the retrieval interface of the matching metadata owner.

[0104] Sequence 6: The metadata owner receives the query request, filters the metadata in the local metadata database, and returns the matching metadata set information to the data center.

[0105] Sequence 7: The data center aggregates and organizes metadata collection information and returns the results to the metadata requester.

[0106] Sequence 8: The metadata requester or data center verifies the metadata based on the Merkle tree and the root node hash value to ensure the integrity and trustworthiness of the metadata.

[0107] Sequence 9: Metadata requesters can query the storage records of the Merkle root hash value through the blockchain storage platform to verify the existence and immutability of the metadata.

[0108] Example 2 The difference from Example 1 is that this example focuses on explaining the specific structure of the metadata template and the application of the AIGC identifier.

[0109] Metadata templates define the fields that metadata should include and their definitions, forming the foundation for cross-organizational standardized metadata retrieval. Metadata templates include the following main fields: (1) Basic Information Fields: Asset ID, Title, Duration, Creation Date, Modification Date, Description, etc. The Asset ID field uses UUID format to uniquely identify a metadata record globally. The Title field is the name or title of the audiovisual training data. The Duration field is the duration of the audiovisual training data, in seconds. The Creation Date and Modification Date fields record the creation and modification times of the metadata. The Description field is a brief description of the audiovisual training data.

[0110] (2) Technical Parameter Fields: Resolution, Codec, Frame Rate, Bitrate, File Size, Color Space, etc. The resolution field specifies the resolution of the audiovisual training data, such as "1920x1080", "3840x2160", etc. The codec field specifies the encoding format of the audiovisual training data, such as "H.264", "H.265", "VP9", etc. The frame rate field specifies the frame rate of the audiovisual training data, such as "25fps", "30fps", "60fps", etc. The bitrate field specifies the bitrate of the audiovisual training data, in Mbps. The file size field specifies the file size of the audiovisual training data, in MB or GB. The color space field specifies the color space of the audiovisual training data, such as "sRGB", "Rec.709", "Rec.2020", etc.

[0111] (3) Content semantic fields: content type, scene, character, subtitle, keywords, sentiment, etc. The content type field describes the type of audiovisual training data, such as "news," "documentary," "variety show," "movie," "TV series," etc. The scene field describes the scenes appearing in the audiovisual training data, such as "indoor," "outdoor," "city," "countryside," etc. The character field describes the characters appearing in the audiovisual training data, such as "host," "guest," "actor," etc. The subtitle field contains the subtitle content of the audiovisual training data. The keyword field contains the keyword tags of the audiovisual training data. The sentiment field describes the emotional tendency of the audiovisual training data, such as "positive," "negative," "neutral," etc.

[0112] (4) Copyright Information Fields: Copyright Owner (copyright_owner), License Type (license_type), Usage Restrictions (usage_restrictions), Copyright Statement (copyright_statement), etc. The Copyright Owner field displays the name or identifier of the copyright owner of the audiovisual training data. The License Type field specifies the license type for the audiovisual training data, such as "Public Domain," "Creative Commons License," or "Commercial License." The Usage Restrictions field describes the restrictions on the use of the audiovisual training data. The Copyright Statement field contains the copyright statement text for the audiovisual training data.

[0113] (5) AIGC Identifier Fields: Whether it is AIGC (is_aigc), AI Participation Level (ai_participation_level), Generation Method (generation_method), Training Suitability (training_suitable), Quality Rating (quality_rating), etc. The Whether it is AIGC field indicates whether the audiovisual training data is AI-generated content, with values ​​of "yes" or "no". The AI ​​Participation Level field describes the degree of AI participation in the content generation process, with values ​​of "fully generated", "partially generated", "assisted generation", "not involved", etc. The Generation Method field describes the specific method used by AI to generate content, such as "text to video", "image to video", "speech synthesis", "virtual anchor", etc. The Training Suitability field indicates whether the audiovisual training data is suitable for AI model training, with values ​​of "suitable", "unsuitable", "conditionally suitable", "unknown", etc. The Quality Rating field rates the quality of the audiovisual training data, with values ​​of "A", "B", "C", "D", etc., taking into account factors such as Merkle integrity verification level, content quality, and annotation accuracy.

[0114] (6) Merkle Tree Fields: The complete Merkle tree structure (merkle_tree), root node hash (merkle_root), number of leaf nodes (leaves_count), and tree depth (tree_depth) are all represented. The complete Merkle tree structure field stores the hash values ​​of all nodes in the Merkle tree. The root node hash field stores the hash value of the root node of the Merkle tree. The number of leaf nodes field represents the number of leaf nodes in the Merkle tree. The tree depth field represents the depth of the Merkle tree.

[0115] (7) Blockchain Dual Anchor Fields: Evidence ID, Blockchain Type, Blockchain Transaction Hash, and Judicial Anchor Information. The Evidence ID field stores the identifier of the evidence ID returned by the blockchain evidence platform. The Blockchain Type field identifies the type of blockchain used, such as "consortium blockchain" or "public blockchain." The Blockchain Transaction Hash field stores the hash value of the blockchain transaction. The Judicial Anchor Information field stores relevant information about the judicial chain anchor, including batch transaction hash, Merkle verification path, and batch index.

[0116] The AIGC identifier plays a crucial role in the metadata template, recording whether the corresponding metadata is AIGC and / or the degree of AI participation. By mandating the inclusion of the AIGC identifier, mandatory identification of AIGC content is achieved, avoiding recursive pollution from "training AI with AI-generated content."

[0117] For example, a content creator uses AI technology to generate a video of a virtual anchor delivering news. When tagging metadata, the "AIGC" field is set to "Yes," the "AI Participation Level" field is set to "Partially Generated" (because the news content is real news, only the anchor is virtual), and the "Generation Method" field is set to "Virtual Anchor." Based on content quality and annotation accuracy, the "Training Applicability" field is set to "Conditionally Suitable" (suitable for training AI models related to virtual anchors, but not suitable for training AI models in real news scenarios), and the "Quality Rating" field is set to "B."

[0118] When submitting a query request, metadata requesters can filter based on AIGC identifiers. For example, an AI model trainer might want to obtain entirely real news videos for training purposes. They can set a filter condition in their query request: "AIGC: No". The data center then filters registration records and metadata based on this condition, returning only news video metadata not generated by AIGC, thus preventing AIGC content from being mixed into the training set.

[0119] On the other hand, if an AI model trainer wants to obtain training data related to virtual anchors, they can set filter conditions in the search request: AIGC="Yes" and generation method="virtual anchor". The data center filters and returns metadata related to virtual anchors based on these conditions to meet the needs of specific training tasks.

[0120] By mandating the identification of AIGC content and flexibly filtering it, effective management and control of AIGC content have been achieved, improving the quality and credibility of AI training data.

[0121] Example 3 The difference from Example 1 is that this example focuses on explaining the technical details of Merkle tree verification and blockchain anchoring.

[0122] Merkle tree verification is a key technology for ensuring the integrity and trustworthiness of metadata. Merkle trees construct a tree structure using cryptographic hash functions; any tampering with a content fragment will cause a change in the Merkle root hash value, thus enabling rapid detection.

[0123] The Merkle tree construction process is as follows: Figure 4 As shown, the detailed steps are as follows: Step 1: Segmentation. The audiovisual training data is segmented into segments based on fixed duration or scene boundaries. Fixed duration segmentation is suitable for longer audiovisual training data, segmenting at fixed time intervals (e.g., 3 minutes, 5 minutes). Scene boundary segmentation is suitable for audiovisual training data with significant scene changes, segmenting based on shot transitions or scene changes. The granularity of segmentation can be adjusted according to actual needs; finer granularity results in higher verification accuracy but also higher computational overhead.

[0124] Step 2: Calculate the hash value of the leaf nodes. Calculate the hash value of each slice segment separately, which will be used as the leaf node of the Merkle tree. The hash value can be calculated using, for example, the SM3 hash algorithm. SM3 is a national cryptographic algorithm issued by the State Cryptography Administration, with a 256-bit output length, providing higher security and meeting national security requirements. The calculation formula is: Hash(S_i) = SM3(content_segment_i), where content_segment_i represents the original content data of the i-th slice segment.

[0125] Step 3: Pad the leaf nodes. If the number of slice segments N is not a power of 2, the last leaf node needs to be copied to pad to a power of 2 leaf nodes. This is to ensure the balance and integrity of the Merkle tree. For example, if N=5, then 2^2 = 4, which is less than 5, and 2^3 = 8, which is greater than 5, so padding to 8 leaf nodes is necessary. Copy the last leaf node Hash(S_N) to S_{N+1}, S_{N+2}, ..., S_{2^k}, where k is the smallest integer satisfying 2^k>= N.

[0126] Step 4: Recursively calculate the hash value of the parent node. The hash value of the parent node is calculated recursively from bottom to top until the root node hash value is generated. For the j-th node at level i, its hash value is calculated using the formula: Hash(Node_i_j) = SM3(Hash(Node_{i-1}_{2j}) || Hash(Node_{i-1}_{2j+1})), where || represents the hash value concatenation operation. The recursive calculation process starts from the leaf level (level 0) and proceeds upwards layer by layer until the root node level (level k).

[0127] Step 5: Generate the Merkle root. The hash value of the root node of the Merkle tree is the Merkle root, representing the integrity fingerprint of the entire audiovisual training data. The Merkle root has the following property: any tampering with a content segment will cause the hash value of that segment to change, which in turn will cause the hash values ​​of all parent nodes from that leaf node to the root node to change, ultimately resulting in a change in the Merkle root hash value. Therefore, by comparing the Merkle root hash value, it is possible to quickly detect whether the content has been tampered with.

[0128] The Merkle tree validation process includes the following steps: Step 1: Extract Merkle tree information. Extract the complete Merkle tree structure and root node hash value from the metadata. The complete Merkle tree structure includes the hash values ​​of all leaf nodes, intermediate nodes, and the root node.

[0129] Step 2: Recalculate the Merkle tree. Based on the audiovisual training data corresponding to the metadata, recalculate the Merkle tree. The recalculation process follows the same slicing method, hash algorithm, and calculation rules as the construction process.

[0130] Step 3: Compare the Merkle root. Compare the recalculated root node hash value with the root node hash value recorded in the metadata. If they match, it means the audiovisual training data corresponding to the metadata has not been tampered with, and the verification passes. If they do not match, it means the audiovisual training data corresponding to the metadata has been tampered with or the metadata record is incorrect, and the verification fails.

[0131] For fragment-level verification, the verifier obtains the fingerprint hash of the target fragment and the path nodes from that fragment to the Merkle root, and calculates the current hash upwards along the path. Specifically, the initial Current is equal to the fingerprint hash of the target fragment. For each node on the path, if the current node is the right child, the hash value of the sibling node is concatenated with the current hash value and then an SM3 hash is calculated, i.e., Current = SM3(Sibling || Current); if the current node is the left child, the current hash value is concatenated with the hash value of the sibling node and then an SM3 hash is calculated, i.e., Current = SM3(Current ||Sibling). This calculation is recursively performed upwards until the root node is reached. The final Current value is compared with the Merkle root. If they match, the verification passes, indicating that the target fragment has not been tampered with; if they do not match, the verification fails, indicating that the target fragment has been tampered with.

[0132] For example, the verifier performs segment-level verification on the third segment (S003) of a 15-minute news video. The fingerprint hash (S003) and Merkle path information of S003 are obtained from the metadata. The Merkle path includes the sibling node hash (S004), the sibling node Node0 of parent node Node1, and the sibling node Node5 of Node4. The verification process is as follows: Initially, Current = Hash (S003); S003 is the left child node, so Current = SM3(Current || Hash (S004)) is calculated, resulting in Node1; Node1 is the right child node, so Current = SM3(Node0 || Current) is calculated, resulting in Node4; Node4 is the left child node, so Current = SM3(Current || Node5) is calculated, resulting in Node6 (i.e., the Merkle root). The final Current value is compared with the Merkle root recorded in the metadata; if they match, the verification passes.

[0133] Blockchain anchoring is a key technology for providing legally binding proof of ownership for training data. By writing the hash value of the Merkle tree root node into a blockchain evidence storage platform, the immutability of blockchain is utilized to provide legally valid proof of the existence of training data.

[0134] The blockchain anchoring process includes the following detailed steps: Step 1: Submit a notarization application. The metadata owner calls the interface of the First Blockchain Notarization Platform to submit a notarization application. The notarization application includes the following information: business type (e.g., "ai_training_data", identifying the type of notarization business), content fingerprint (i.e., the hash value of the root node of the Merkle tree, serving as the integrity fingerprint of the audiovisual training data), extended information (e.g., metadata identifier, metadata owner identifier, creation time, etc.), and digital signature (using the metadata owner's private key to digitally sign the notarization application, ensuring the authenticity and immutability of the application).

[0135] Step 2: Identity Verification and Data Validation. After receiving the notarization application, the First Blockchain Notarization Platform performs identity verification and data validation. Identity verification includes verifying the applicant's digital signature to confirm the applicant's identity and permissions. Data validation includes verifying whether the format of the Merkle root hash value conforms to the output format of the SM3 hash algorithm (256-bit hexadecimal string) and verifying the integrity and legality of the extended information.

[0136] Step 3: Write to the First Blockchain. After successful verification, the First Blockchain Evidence Preservation Platform writes the evidence preservation record to the blockchain. The evidence preservation record includes the business type, content fingerprint, extended information, applicant identifier, and preservation time. The First Blockchain Evidence Preservation Platform generates a unique evidence preservation credential (such as EvidenceID) as a globally unique identifier for the evidence preservation record. After the evidence preservation record is written to the First Blockchain, the immutability of the blockchain ensures the authenticity and permanence of the evidence preservation record.

[0137] Step 4: Return the evidence certificate. The first blockchain evidence platform returns the evidence certificate to the metadata owner. The metadata owner stores the evidence certificate in the blockchain anchor field of the metadata as proof that the audiovisual training data has been blockchain-preserved.

[0138] Step 5: Anchoring to the Second Blockchain Evidence Storage Platform. The first blockchain evidence storage platform periodically anchors the batch root hash to the second blockchain evidence storage platform (such as the Beijing Internet Court's Tianping Chain or the Guangzhou Internet Court's Wangtong Fa Chain). Specifically, the first blockchain evidence storage platform collects all evidence records within a certain time period (e.g., 10 minutes), extracts the Merkle root hash of each evidence record, and constructs a batch Merkle tree. The leaf nodes of the batch Merkle tree are the Merkle root hashes of each evidence record. The hash values ​​of parent nodes are recursively calculated from bottom to top until the batch root hash is reached. The first blockchain evidence storage platform submits the batch root hash to the second blockchain evidence storage platform for judicial anchoring. After receiving the anchoring request, the second blockchain evidence storage platform writes the batch root hash into a block, generating a batch transaction hash (BatchTxHash) and a batch index (BatchIndex).

[0139] Step 6: Backfill the blockchain judicial anchor information. After confirmation by the second blockchain evidence storage platform, the blockchain anchor information is backfilled into the blockchain anchor field of the metadata. The second blockchain anchor information includes the following: judicial chain type (such as "Beijing_Tianping" or "Hangzhou_Tianping", identifying the judicial chain used), batch transaction hash (BatchTxHash, the transaction hash of the judicial chain block), Merkle verification path (MerklePath, the verification path from the Merkle root of the evidence storage record to the batch root), and batch index (BatchIndex, the index position of the evidence storage record in the batch).

[0140] The blockchain verification process includes the following steps: Step 1: Parse the evidence certificate. The verifier extracts the evidence certificate (EvidenceID) from the blockchain anchor field of the metadata.

[0141] Step 2: Query the blockchain evidence storage platform. The verifier queries the blockchain evidence storage platform based on the evidence storage certificate to obtain the corresponding evidence storage record. The evidence storage record includes the storage time, applicant identifier, Merkle root hash (PrimaryHash), and extended information.

[0142] Step 3: Compare the Merkle root hash. The verifier compares the Merkle root hash (PrimaryHash) on the blockchain with the locally calculated Merkle root hash. If they match, it means the local Merkle root hash matches the on-chain record, the data has not been tampered with, and the verification passes. If they do not match, it means the local data has been modified or the evidence record is incorrect, and the verification fails.

[0143] Step 4: Verify Judicial Anchoring Information. The verifier extracts judicial anchoring information from the blockchain anchoring field of the metadata, including the judicial chain type, batch transaction hash, Merkle verification path, and batch index. The verifier connects to the corresponding judicial chain node based on the judicial chain type. The verifier queries the judicial chain based on the batch transaction hash to obtain the batch root hash and batch block information for that batch. The verifier verifies the Merkle verification path to confirm that the Merkle root of the evidence record is indeed in a specific batch of the judicial chain. Specifically, the current hash is calculated upwards along the Merkle verification path, with the initial Current equal to the local Merkle root hash. Based on the sibling and parent node information in the Merkle verification path, the parent node hash value is recursively calculated until the batch root hash is obtained. The calculated batch root hash is compared with the batch root hash on the second blockchain evidence storage platform. If they match, the verification passes, indicating that the evidence record is indeed anchored to a specific batch of the judicial chain and has judicial validity. If they do not match, the verification fails, indicating that the Merkle verification path data is incorrect or the judicial chain anchoring record has been tampered with.

[0144] Through blockchain anchoring and verification processes, judicial-level ownership confirmation of training data is achieved. The first blockchain evidence storage platform, as a consortium blockchain, is jointly maintained by industry or regional alliance members, possessing high credibility and immutability. The second blockchain evidence storage platform, as a blockchain recognized by the Internet Court, has legal validity, and its anchored records can serve as valid evidence in judicial proceedings. This dual-chain anchoring mechanism ensures both the industry-wide credibility of the evidence storage records and their judicial validity. In the event of data transaction disputes, the verification process can prove the existence, integrity, and original state of the data, providing strong technical support for judicial evidence. The blockchain anchoring mechanism provides a foundation of trust for training data transactions, promoting the healthy development of the data element market.

[0145] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0146] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for metadata registration and retrieval of AI audiovisual training data, wherein the method is executed by a data center and includes the following steps: The system receives registration requests from metadata owners and registers them. The registration information includes the metadata owner's identity information, metadata retrieval interface address information, and metadata template information, and forms corresponding registration records. Receive metadata request from metadata requester. The query request includes retrieval request information formulated by the metadata requester based on the definition of each field specified in the metadata template, so as to filter the metadata based on the retrieval request information in the query and retrieval steps. The system performs queries and retrievals. Based on the retrieval request information specified by the metadata requester, it filters the registration records, identifies the metadata owners that match the retrieval request information, accesses the retrieval interface address of the matching metadata owners, and further receives the metadata set information that matches the information filtered and returned by the metadata owners based on the retrieval request information specified by the metadata requester. The system then returns this set of information to the metadata requester.

2. The method according to claim 1, wherein the metadata template includes fields for storing the complete structure of the Merkle tree and the hash value of the root node, the Merkle tree is constructed independently for a single audiovisual program, the program content is segmented into spatiotemporal slices, and the hash value of each slice is calculated as a leaf node; if the number of slices is not a power of 2, the last leaf is copied to pad to 2^2. log2N The method is obtained by constructing a program-level Merkle tree from bottom to top and calculating the hash value of the program-level Merkle root node; the method also includes: Based on the Merkle tree and the root node hash value, perform fragment-level integrity verification on the metadata corresponding to the set information returned by the query retrieval step; The fragment-level integrity verification includes: obtaining the hash value of the target fragment and the path nodes from the fragment to the Merkle root; Calculate the hash layer by layer upwards along the path, using the left node hash first and the right node hash last; compare the final hash value with the Merkle root, and if they match, the verification is successful.

3. The method according to claim 1, wherein the metadata template includes a seven-dimensional metadata structure: basic information, technical parameters, content semantics, visual features, audio features, copyright / pedigree / AIGC identifier, and distributed registration and retrieval information; The AIGC identifier is used to record whether the corresponding metadata is AIGC and / or the degree of AI participation.

4. A method for providing metadata for AI audiovisual training data, the method being performed by the metadata owner, comprising the following steps: Metadata is stored in a local metadata database, and the metadata is defined and tagged based on a specific metadata template; The system receives all or part of the query and retrieval requests sent by the data center through a pre-determined retrieval interface. The query and retrieval requests include retrieval request information formulated by the metadata requester based on the definitions of various fields specified in the metadata template. The system filters the metadata in the metadata database and returns the metadata set information that matches the retrieval request information to the data center.

5. The method according to claim 4, further comprising: The steps for constructing a program-level Merkle tree are as follows: A single audiovisual program is spatiotemporally sliced; the hash value of each slice is calculated and used as a leaf node; if the number of segments is not a power of 2, the last leaf node is copied to pad to 2^2. log2N The program-level Merkle tree is constructed from bottom to top and the program-level Merkle root hash value is calculated. The metadata template contains fields for storing the complete structure of the Merkle tree and the root node hash value. All metadata of the audiovisual training data is recorded, including the complete Merkle tree structure and root node hash value of the audiovisual training data, so that metadata requesters or data centers can perform fragment-level integrity verification of the metadata.

6. The method according to claim 5, further comprising: The blockchain dual-anchoring process involves writing the Merkle root of a single program into the first blockchain evidence storage platform to obtain evidence identification. The first blockchain evidence storage platform packages multiple programs into batch Merkle trees according to a predetermined method, and writes the hash value of the root node of the batch Merkle tree into the second blockchain evidence storage platform to form judicial-grade evidence storage, so that the metadata requester or data center can verify the metadata through the first and / or second blockchain evidence storage platforms.

7. A metadata registration and retrieval device for AI audiovisual training data, characterized in that, The device is deployed in a data center and includes: The registration module is used to receive registration requests from metadata owners and register them. The registration information includes the metadata owner's identity information, metadata retrieval interface address information, and metadata template information, and forms corresponding registration records. The request receiving module is used to receive query and retrieval requests for metadata from metadata requesters. The query and retrieval requests include retrieval request information formulated by the metadata requester based on the definitions of each field specified in the metadata template. The query and retrieval module is used to filter registration records based on the retrieval request information specified by the metadata requester, filter out the metadata owners that match the retrieval request information, access the retrieval interface address of the matching metadata owners, receive the metadata set information that matches the retrieval request information returned by the metadata owners, and return the set information to the metadata requester. The intelligent routing module is used to filter out unqualified data based on the institution's supported dimensions, node online status, training applicability, and AIGC labels.

8. The apparatus of claim 7, wherein, The metadata template includes fields for storing the complete Merkle tree structure and the root node hash value. The Merkle tree is constructed independently for each individual audiovisual program, dividing the program content into spatiotemporal slices. The hash value of each slice is calculated and used as a leaf node. If the number of slices is not a power of 2, the last leaf node is copied to pad to 2^2. log2N It is obtained by constructing a program-level Merkle tree from the bottom up and calculating the hash value of the root node; The device further includes a verification module, used to perform fragment-level integrity verification on the metadata corresponding to the metadata set information returned by the query retrieval module based on the Merkle tree and the root node hash value. The fragment-level integrity verification includes: obtaining the hash value of the target fragment and the path nodes from the fragment to the Merkle root; calculating the hash layer by layer upward along the path, using the left node hash first and the right node hash last in the calculation; comparing the final hash value with the Merkle root, and if they match, the verification is successful.

9. The apparatus according to claim 7, characterized in that, The metadata template includes a seven-dimensional metadata structure: basic information, technical parameters, content semantics, visual features, audio features, copyright / pedigree / AIGC identifier, and distributed registration and retrieval information; wherein the AIGC identifier is used to record whether the corresponding metadata is AIGC and / or the degree of AI participation. 10.A metadata providing apparatus for AI audiovisual training data, characterized by comprising: The device is deployed on the metadata owner's side and includes: The storage module is used to store metadata in a local metadata database, the metadata being defined and tagged based on a specific metadata template; The response module is used to receive query requests sent by the data center through a pre-determined retrieval interface. The query request includes retrieval request information formulated by the metadata requester based on the definitions of various fields specified in the metadata template. The response module filters the metadata in the metadata database and returns the metadata set information that matches the retrieval request information to the data center.

11. The apparatus of claim 10, wherein, The device further includes: The program-level Merkle tree construction module is used to segment a single audiovisual program spatiotemporally. For each segment, its hash value is calculated and used as a leaf node. If the number of segments is not a power of 2, the last leaf node is copied to pad to 2^2. log2N The program-level Merkle tree is constructed from bottom to top, and the program-level Merkle root hash value is calculated. The metadata template contains fields for storing the complete structure of the Merkle tree and the hash value of the root node. All metadata of the audiovisual training data records the complete structure of the Merkle tree and the hash value of the root node of the audiovisual training data, so that the metadata requester or data center can perform fragment-level integrity verification of the metadata.

12. The apparatus of claim 11, wherein, The device further includes: The blockchain dual-anchor module writes the Merkle root of a single program into the first blockchain evidence storage platform to obtain evidence identification; the first blockchain evidence storage platform packages multiple programs into batch Merkle trees according to a predetermined method, and writes the hash value of the root node of the batch Merkle tree into the second blockchain evidence storage platform to form judicial-grade evidence storage, so that the metadata requester or data center can verify the metadata through the first and / or second blockchain evidence storage platforms.

Images