A digital copyright layered right confirmation method and system

Abstract

The application relates to the technical field of digital copyright management and blockchain evidence storage, and discloses a digital copyright hierarchical right confirmation method and system. The method comprises the following steps: feature extraction, cross-modal alignment and feature fusion are performed on effective modal data of digital content to generate a content feature identifier; a mutual exclusion lock is acquired by taking the content feature identifier as a locking object, and right ownership operation pre-checking is performed based on a directed acyclic graph ownership graph; after the pre-checking is passed, a domain event with an incremental target serial number is generated, sequence continuity and concurrent time sequence checking are performed through a consensus network; the ownership graph and the serial number are updated based on the domain event that passes the checking; the graph nodes and the directed edges are periodically determined and sequenced to generate a linear byte data block sequence, a Merkle tree root hash is generated according to the linear byte data block sequence, and the Merkle tree root hash is submitted to a blockchain through an anchor transaction for evidence storage and solidification. The application can improve the concurrent consistency and the right ownership state evidence credibility in the dynamic right confirmation process of digital copyright.

Description

Technical Field

[0001] This invention relates to the fields of digital copyright management and blockchain evidence preservation technology, and more specifically, to a method and system for tiered digital copyright confirmation. Background Technology

[0002] With the development of the digital content industry, the amount of digital content, including text, images, audio, video, and combinations of multiple modalities, is constantly increasing. The dissemination and use of digital content often involves various operations such as content adaptation, copyright transfer, licensing, and derivative creation, resulting in a continuously changing and multi-layered ownership status. Therefore, how to effectively identify digital content and accurately record and reliably document ownership changes throughout its lifecycle has become a crucial issue that needs to be addressed in digital copyright management.

[0003] In existing digital copyright confirmation and notarization schemes, one type of technology typically generates content identifiers based on the cryptographic hash values ​​of digital content and records the hash values ​​or corresponding ownership information on the blockchain. However, cryptographic hashes mainly reflect the integrity of digital files at the bit level. When digital content undergoes format conversion, partial editing, mixing, or adaptation, its hash value usually changes entirely, making it difficult to use the original hash identifiers to uniformly represent and manage semantically related digital content. Furthermore, ownership records based on single-hash notarization typically focus on the state solidification at a specific point in time, failing to directly reflect the complete dynamic evolution process of digital content after multiple ownership transfers, licensing, and authorization operations.

[0004] Another type of technology uses blockchain smart contracts to record the ownership status and changes of digital copyrights, enabling dynamic management of ownership information to some extent. However, when the nodes, rights holders, ownership relationships, and frequent ownership changes corresponding to digital content are all updated directly through on-chain transactions, it consumes significant on-chain storage and transaction processing resources and is limited by the throughput capacity of the blockchain network, making it difficult to balance the processing efficiency of high-frequency ownership operations with the need for reliable evidence storage of ownership data. Existing technologies have also not fully resolved the issues of ownership status competition and inconsistent event processing order that may arise when the same digital content receives multiple concurrent ownership operation requests within a short period of time.

[0005] In view of this, a method and system for tiered digital copyright confirmation is proposed. Summary of the Invention

[0006] This application proposes a method and system for tiered digital copyright confirmation to solve one of the aforementioned technical problems.

[0007] The technical solution adopted in this application is as follows:

[0008] In a first aspect, embodiments of this application provide a method for tiered digital copyright confirmation, executed by a copyright management device, including:

[0009] Upon receiving a request for ownership operation, the system extracts features and performs cross-modal alignment on the valid modal data of the digital content to be processed, and fuses the obtained modal features to generate a content feature identifier for the digital content to be processed.

[0010] Using the content feature identifier as the locking object, a preemption request is initiated to the distributed lock component. After acquiring the mutex lock, the status of the ownership node corresponding to the content feature identifier in the directed acyclic graph ownership graph is read, and the ownership operation request is pre-checked and verified.

[0011] After the pre-inspection verification is passed, the currently confirmed change sequence number corresponding to the content feature identifier in the directed acyclic graph ownership graph is read, a target sequence number that is incremented relative to the currently confirmed change sequence number is generated, the ownership operation request, the content feature identifier and the target sequence number are encapsulated into a target domain event, and the target domain event is sent to the consensus network after the mutex lock is released.

[0012] The consensus network is used to verify the continuity between the target sequence number and the currently confirmed change sequence number, and to perform time-series verification on concurrent target domain events to determine the target domain events that pass the verification.

[0013] Obtain the target domain events that have passed the verification, update the nodes and directed edges in the directed acyclic graph ownership graph according to the event type of the target domain events, and update the currently confirmed change sequence number;

[0014] According to a preset period, the nodes and directed edges in the directed acyclic graph ownership graph are sorted and serialized according to a preset deterministic sorting rule to generate a linear byte data block sequence.

[0015] A Merkel root hash is generated based on the linear byte data block sequence, and the anchored transaction containing the Merkel root hash is submitted to the blockchain node for storage and solidification.

[0016] Preferably, feature extraction and cross-modal alignment are performed on the effective modal data of the digital content to be processed, and the obtained modal features are fused, including:

[0017] Extract the modal data contained in the digital content to be processed, and detect the validity of each modal data respectively;

[0018] Feature extraction is performed on each of the detected valid modal data, and the extracted modal features are mapped to a unified semantic space;

[0019] The core content modality is determined based on the content type corresponding to the digital content to be processed, and the feature weights corresponding to each effective modality are calculated.

[0020] When the core modality of the content belongs to a valid modality, the feature weights of each valid modality are adjusted according to the preset core modality weight constraints.

[0021] When the core modality is a failed modality and at least one other valid modality still exists, the core modality weight constraint is not executed, and the feature weights are redistributed among the remaining valid modalities.

[0022] The corresponding modal features are fused according to the adjusted or reassigned feature weights to generate the content feature identifier.

[0023] Preferably, when the ownership operation request is an ownership transfer request, the step of reading the ownership node status corresponding to the content feature identifier in the directed acyclic graph ownership map and performing a pre-check verification of the ownership operation request includes:

[0024] Query the directed acyclic graph ownership map to obtain the current rights holder node and dispute status marker associated with the content feature identifier;

[0025] Determine whether the current right holder corresponding to the current right holder node is consistent with the requester of the ownership transfer request, and determine whether the dispute status marker indicates that the digital content to be processed does not have a pending confirmation status or a dispute status;

[0026] When the current rights holder is the same as the requester and there is no pending confirmation or dispute status, the pre-check verification is deemed successful.

[0027] Otherwise, the ownership transfer request is rejected and the mutex is released.

[0028] Preferably, the consensus network verifies the continuity between the target sequence number and the currently confirmed change sequence number, and performs time-series verification on concurrent target domain events, including:

[0029] Obtain the content feature identifier and target sequence number corresponding to the target domain event, and obtain the currently confirmed change sequence number corresponding to the content feature identifier;

[0030] Determine whether the target sequence number is equal to the currently confirmed change sequence number plus one, and only allow target domain events that satisfy this continuity relationship to pass the sequence number verification;

[0031] When there are multiple concurrent target domain events with the same content feature identifier and the same target sequence number, the priority event is determined according to the order in which the consensus master node receives each target domain event.

[0032] The priority events are confirmed through consensus, and after the priority events are confirmed through consensus, their target sequence number is determined as the updated currently confirmed change sequence number, and other concurrent target domain events that do not meet the updated sequence continuity relationship are rejected.

[0033] Preferably, updating the nodes and directed edges in the directed acyclic graph ownership graph according to the event type of the target domain event includes:

[0034] Identify the event type of the target domain events that pass the verification;

[0035] When the target domain event is an ownership transfer event, a target rights holder node is created or determined in the directed acyclic graph ownership graph, and a directed edge for ownership relationship between the digital content node and the target rights holder node is established or updated.

[0036] When the target domain event is a licensing event, an licensing protocol node is created, and a directed edge establishing the licensing relationship between the digital content node and the licensed entity node is established.

[0037] When the target domain event is a historical correction event, the compensation update logic is triggered to logically correct the historical erroneous ownership status in the directed acyclic graph ownership map.

[0038] Preferably, the logical correction of historical erroneous ownership states in the directed acyclic graph ownership map includes:

[0039] The historical event to be corrected is determined based on the parent event pointer carried by the historical correction event, and the historical error node and original edge relationship corresponding to the historical event are located in the directed acyclic graph ownership graph.

[0040] The historical error nodes and their original edge relationships are retained. An offset node is added to the directed acyclic graph ownership graph to represent the compensation operation, and a directed edge is established between the offset node and the historical error node to represent the offset relationship.

[0041] The validity status of the historical error nodes and / or their corresponding original edge relationships in the query view layer is updated from the current valid status to the compensated status, so that the system filters out nodes and / or directed edges in the compensated status when responding to regular ownership query requests, and retains their queryability during historical audits or ownership backtracking.

[0042] Preferably, the nodes and directed edges in the directed acyclic graph ownership graph are sorted and serialized according to a preset deterministic sorting rule, including:

[0043] Get the set of nodes and the set of directed edges corresponding to the current anchoring period;

[0044] For the node set, the nodes are sorted in ascending order according to the parent event identifier that triggered the corresponding node in the metadata of each node. The node fields corresponding to each node are extracted in the order of the preset node fields. The node attribute fields are then serialized after being arranged in lexicographical order of the attribute keys to obtain the node serialized data.

[0045] For the set of directed edges, the parent event identifier bound to the starting node of each directed edge is used as the first sorting key, and the parent event identifier bound to the ending node is used as the second sorting key for ascending sorting. When the first sorting key and the second sorting key are the same, the creation time of the directed edge is used as the third sorting key for sorting.

[0046] The directed edge fields corresponding to each directed edge are extracted sequentially according to the preset directed edge field order, and the relation attribute fields are arranged in lexicographical order of attribute keys and then serialized to obtain the directed edge serialized data.

[0047] The node serialized data and the directed edge serialized data are sequentially concatenated according to a preset concatenation order to generate the linear byte data block sequence.

[0048] Preferably, a Merkle root hash is generated based on the linear byte data block sequence, and the anchored transaction containing the Merkle root hash is submitted to the blockchain node for notarization and solidification, including:

[0049] The linear byte data block sequence is divided into multiple ordered data blocks according to a preset data block partitioning rule;

[0050] Calculate the hash value of each data block separately, and use each hash value as a leaf node of the Merkle tree. Perform paired hash operations on adjacent nodes and recursively layer by layer until a unique Merkle tree root hash is obtained.

[0051] Obtain the graph version number and snapshot timestamp corresponding to the current graph snapshot, and encapsulate the Merkle root hash, the graph version number, and the snapshot timestamp into the anchor transaction;

[0052] The anchoring transaction is submitted to the blockchain node for recording, and the graph version number is updated after successful anchoring.

[0053] Preferably, after detecting the validity of each modal data separately, the method further includes:

[0054] When the digital content to be processed contains multiple modal data, and some modal data are invalid but at least one valid modal data exists, the content feature identifier is generated based on the remaining valid modal data, and the modal missing identifier corresponding to the invalid modal data is recorded.

[0055] When all modal data of the digital content to be processed are invalid, or when the digital content to be processed is a single modal content and its unique modal data is invalid, the generation process of the content feature identifier is terminated, and an error feedback message carrying modal failure information is generated.

[0056] Secondly, embodiments of this application provide a digital copyright hierarchical confirmation system to implement the method described in any of the above-mentioned embodiments, comprising:

[0057] The feature identifier generation module is used to receive ownership operation requests, extract features and perform cross-modal alignment on the effective modal data of the digital content to be processed, and fuse the obtained modal features to generate the content feature identifier of the digital content to be processed.

[0058] The pre-detection locking module is used to initiate a preemption request to the distributed lock component with the content feature identifier as the locking object. After acquiring the mutex lock, it reads the status of the ownership node corresponding to the content feature identifier in the directed acyclic graph ownership graph and performs pre-detection verification on the ownership operation request.

[0059] The event orchestration module is used to read the currently confirmed change sequence number corresponding to the content feature identifier in the directed acyclic graph ownership graph after the pre-inspection verification is passed, generate a target sequence number that is incremented relative to the currently confirmed change sequence number, encapsulate the ownership operation request, the content feature identifier and the target sequence number into a target domain event, and send the target domain event to the consensus network after releasing the mutex lock;

[0060] The consensus verification module is used to verify the continuity relationship between the target sequence number and the currently confirmed change sequence number through the consensus network, and to perform time-series verification on concurrent target domain events to determine the target domain events that pass the verification.

[0061] The graph update module is used to obtain the target domain events that have passed the verification, update the nodes and directed edges in the directed acyclic graph ownership graph according to the event type of the target domain events, and update the currently confirmed change sequence number.

[0062] The graph serialization module is used to sort and serialize the nodes and directed edges in the directed acyclic graph ownership graph according to a preset period and a preset deterministic sorting rule to generate a linear byte data block sequence.

[0063] The on-chain anchoring module is used to generate a Merkle root hash based on the linear byte data block sequence, and submit the anchoring transaction containing the Merkle root hash to the blockchain node for storage and solidification.

[0064] This application discloses a method and system for hierarchical digital copyright confirmation. The method extracts features from the effective modal data of the digital content to be processed, performs cross-modal alignment and feature fusion to generate content feature identifiers for associating digital content with ownership information, improving the unified representation and ownership association capabilities of digital content in different modalities. Using the content feature identifiers as locking objects, distributed mutual exclusion control and ownership status pre-detection are implemented. Combined with incremental target sequence numbers and consensus network execution of sequence continuity and concurrent event timing verification, the possibility of ownership status conflicts and inconsistent event order caused by concurrent ownership operations can be reduced. By dynamically updating the nodes and directed edges in the directed acyclic graph ownership graph based on the verified target domain events, digital copyright confirmation is achieved. The system continuously updates and dynamically traces ownership relationships; furthermore, by deterministically sorting and serializing the directed acyclic graph ownership graph, the graph state is converted into a linear byte data block sequence and a Merkle root hash is generated, enabling the same graph state to form a stable cryptographic commitment; finally, the anchored transaction containing the Merkle root hash is submitted to the blockchain node for evidence preservation and solidification. This reduces the storage and processing overhead caused by frequent on-chain uploading of complete ownership details data, while ensuring the integrity, verifiability, and credibility of off-chain dynamic ownership data, thereby improving the processing efficiency, consistency, and reliability of the digital copyright confirmation system in complex, multimodal, and high-concurrency ownership management scenarios. Attached Figure Description

[0065] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0066] Figure 1 A flowchart illustrating a method for tiered digital copyright confirmation provided in an embodiment of the present invention;

[0067] Figure 2 This is a schematic diagram of a digital copyright hierarchical rights confirmation system provided in an embodiment of the present invention. Detailed Implementation

[0068] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0069] like Figure 1 As shown in some embodiments of this application, this embodiment provides a method for tiered digital copyright confirmation. Specifically, the method includes the following steps:

[0070] Step S101: Receive ownership operation request, extract features and perform cross-modal alignment on the effective modal data of the digital content to be processed, and fuse the obtained modal features to generate the content feature identifier of the digital content to be processed.

[0071] Specifically, the ownership management device receives an ownership operation request and determines the corresponding digital content to be processed based on the request. The ownership operation request triggers the ownership processing flow for the digital content and can be initiated by a user terminal, a business platform, or other devices communicatively connected to the ownership management device. The digital content to be processed is the digitized content object targeted by this ownership operation.

[0072] The digital content to be processed may include data in one or more modalities. The modality represents the information-carrying format of the digital content, and may include at least one of text, image, audio, and video modalities. For digital content composed of multiple information-carrying formats, it may contain multiple modal data. For example, a digital music piece may simultaneously contain audio data, lyrics text data, and cover image data; a video piece may simultaneously contain video frame data, audio data, and subtitle text data.

[0073] After determining the digital content to be processed, feature extraction is performed on the effective modal data that can participate in content feature generation. Feature extraction is used to convert the original digital content of the corresponding modality into modal features that can characterize the content features of that modality. Different types of modal data can be extracted using feature extraction methods adapted to their data format to obtain corresponding modal features. For example, for text modal data, the extracted modal features can be used to characterize the semantic information contained in the text; for image or video frame modal data, the extracted modal features can be used to characterize the visual content information contained therein; and for audio modal data, the extracted modal features can be used to characterize the acoustic or semantic information of the audio content.

[0074] In one specific implementation, corresponding feature extraction branches are set up for different modalities. For the text modality, the text is segmented, truncated, or padded before being input into the text encoder to obtain text feature vectors. For the image modality, the image is scaled to a preset size and normalized before being input into the visual encoder to obtain visual feature vectors. For the video modality, video frames are extracted at preset time intervals, and the visual features of each video frame are extracted separately, and then the features of each video frame are temporally aggregated. For the audio modality, the audio is resampled and amplitude normalized before being input into the audio encoder to obtain audio feature vectors. As an example, the visual encoder can be ViT-B / 16, the text encoder can be BERT-base, and the audio encoder can be PANNs-CNN14 or MusicCNN.

[0075] The feature dimensions output by each modality encoder can differ. The system inputs each modality's features into independent linear projection layers, mapping them to 512-dimensional intermediate feature vectors. Layer normalization and L2 normalization are then performed to obtain aligned feature vectors in a unified semantic space. The linear projection layers and cross-modal alignment layers can utilize visual-text, visual-audio, and text-audio paired samples for comparative learning, reducing the distance between semantically related features in the unified semantic space and increasing the distance between semantically unrelated features. During inference, each effective modality outputs a 512-dimensional aligned feature vector.

[0076] For multiple valid modalities, the 512-dimensional alignment features corresponding to each modality are input into the weight calculation layer to obtain the corresponding original weight scores. Softmax normalization is then performed within the set of valid modalities to ensure the sum of the weights of all valid modalities is 1. The core modality is identified based on the content type tag determined during digital content upload. When the core modality weight is below 0.5, it is adjusted to 0.5, and the remaining weights are renormalized within the remaining weight range according to their original proportions. When the core modality fails, renormalization is only performed among the remaining valid modalities. Finally, each alignment feature is multiplied by its corresponding weight, summed, and the fusion result is normalized to obtain the content feature vector, which is then used to generate the content feature identifier.

[0077] Since different modal data have different data structures and feature representations, the modal features extracted from each modality may reside in different feature spaces, making direct unified processing difficult. Therefore, cross-modal alignment processing is performed on the obtained modal features, transforming or mapping the modal features corresponding to different modalities to a feature space with a unified feature representation foundation. This allows features from different modalities to undergo subsequent fusion processing within a unified representation system.

[0078] Cross-modal alignment can be understood as establishing feature correspondences between different modal features, enabling modal features from different data formats such as text, images, audio, or video to have unified or comparable feature representations. The features obtained after cross-modal alignment can be called aligned modal features. Further, the aligned modal features are fused to integrate the content information contained in different effective modal data, obtaining fused features used to represent the digital content to be processed as a whole. The purpose of feature fusion is to avoid relying solely on single modal information to represent digital content, allowing the content information contained in different modalities to jointly participate in the feature representation of the digital content to be processed.

[0079] When the digital content to be processed has only one valid modal data participating in the processing, features representing the digital content can be generated based on the modal features corresponding to that valid modal data. When the digital content to be processed has multiple valid modal data participating in the processing, the multiple modal features can be fused, and a content feature identifier for the digital content to be processed can be generated based on the fusion result. The content feature identifier is a digital feature representation generated based on the content features of the digital content to be processed itself, used to represent and associate the corresponding digital content in subsequent ownership processing. The content feature identifier can be represented using feature vectors or other data structures that can record fused features, and its specific data dimensions and storage format can be set according to actual application requirements.

[0080] Through the above processing, the digital content to be processed in different data formats is converted into a unified content feature identifier, thereby providing a unified content association basis for subsequent processing such as ownership status pre-inspection, domain event generation, and ownership map update for the digital content to be processed.

[0081] For example, suppose a user initiates a rights management request for a digital music work, which includes the song audio, lyrics text, and cover art.

[0082] Upon receiving an ownership operation request, the ownership management device identifies the digital music work as the digital content to be processed and acquires the audio modal data, text modal data, and image modal data that can participate in the current processing. Feature extraction is then performed on each of these different modal data. Specifically, feature extraction is performed on the song audio to obtain the corresponding audio modal features, on the lyrics text to obtain the corresponding text modal features, and on the cover image to obtain the corresponding image modal features.

[0083] Since audio modal features, text modal features, and image modal features originate from different types of data and their feature representations differ, cross-modal alignment is further performed on these features to map features corresponding to different modalities to a feature space that can be processed uniformly. After completing the cross-modal alignment, the obtained modal features are fused so that the generated fused features can comprehensively reflect the audio, text, and image content of the digital music work, and corresponding content feature identifiers are generated based on the fusion result.

[0084] Therefore, when performing ownership operations on the digital music work in the future, the content feature identifier can be used to establish a connection between the current ownership operation and the subsequently generated ownership data and the corresponding digital content, without having to rely directly on the original file form of the digital content for subsequent ownership processing.

[0085] For example, when the digital content to be processed is a video work, features can be extracted from the video frame data and audio data involved in the processing of the video work to obtain the corresponding visual modal features and audio modal features. After cross-modal alignment and feature fusion, a content feature identifier used to represent the video work as a whole is generated.

[0086] Step S102: Using the content feature identifier as the locking object, initiate a preemption request to the distributed lock component. After acquiring the mutex lock, read the status of the ownership node corresponding to the content feature identifier in the directed acyclic graph ownership graph, and perform pre-check verification on the ownership operation request.

[0087] Specifically, after generating the content feature identifier corresponding to the digital content to be processed in step S101, the ownership management device uses this content feature identifier as the locking object to distinguish different digital contents and initiates a preemption request to the distributed lock component to request the mutually exclusive processing permission for the currently pending digital content. The distributed lock component is used to coordinate the access and processing of the ownership status corresponding to the same digital content by multiple concurrent ownership operation requests. The distributed lock component can be composed of distributed key-value storage nodes that support atomic condition writes and lease mechanisms. The system uses the index value of the content feature identifier as the lock key and the unique request identifier of the current ownership operation request as the lock value, and obtains the mutex lock through atomic condition writes. The mutex lock has a lease validity period to avoid long-term lock occupation due to processing node abnormalities; when releasing the mutex lock, the release operation is only performed if the lock value matches the current request identifier. When multiple ownership operation requests target different content feature identifiers, each ownership operation request can acquire the corresponding mutex lock and execute subsequent processing independently. When multiple ownership operation requests target the same content feature identifier at the same time, locking the content feature identifier allows one ownership operation request to acquire the corresponding mutex lock and perform ownership status reading and pre-check verification during the mutex lock holding period, thereby avoiding multiple concurrent requests from generating subsequent events based on the same ownership status at the same time.

[0088] Using content feature identifiers as locking objects means establishing a correspondence between content feature identifiers and distributed locks, enabling ownership operation requests initiated for the same content feature identifier to compete for the same mutex lock. This allows concurrency control to be limited to the specific digital content, without needing to lock the entire ownership management system or all digital copyright data. This reduces interference between different digital content processing while providing mutual exclusion control for concurrent ownership operations corresponding to the same digital content.

[0089] After successfully acquiring a mutex lock, the ownership management device accesses the directed acyclic graph (DAG) ownership graph during the mutex lock's protection period. Based on content feature identifiers, it determines the ownership node corresponding to the digital content to be processed and then reads the currently recorded ownership node status. The DAG ownership graph is used to store digital content and related ownership information in a graph structure. Nodes can represent digital content, rights holders, or other copyright management-related objects, and directed edges between nodes represent corresponding ownership relationships. The DAG ownership graph is constructed using an event projection method. The system is configured to only append confirmed domain event logs, and the event projector reads domain events sequentially according to the order of confirmed change sequence numbers. For the first content registration event, the event projector creates a digital content node using the content feature identifier as a unique index, creates or determines an initial rights holder node using the rights holder identifier as a unique index, establishes a directed edge from the digital content node to the initial rights holder node, and initializes the currently confirmed change sequence number to a preset initial value. For subsequent ownership transfers, licensing and authorization, and historical correction events, the event projector creates or determines the corresponding nodes according to the event type, and establishes new directed edges or updates the validity status of relationships according to the preset relationship types.

[0090] Digital content nodes can record content feature identifiers, parent event identifiers, currently confirmed change sequence numbers, pending confirmation status, and disputed status; rights holder nodes can record rights holder identifiers; directed edges of ownership relationships can record relationship type, validity status, creation event identifier, and creation time. For derivation relationships between content nodes, before establishing a directed edge, it is checked whether a path from the terminating node to the starting node already exists; if so, the edge is rejected to avoid forming directed cycles.

[0091] Content feature identifiers are used to establish the correspondence between the digital content to be processed and the corresponding ownership data in the graph. Therefore, the ownership management device can use the content feature identifier as a query basis to locate the corresponding ownership node in the directed acyclic graph ownership graph and obtain the current status of the ownership node related to the digital content. Specifically, the ownership management device uses the content feature identifier as a unique index to query the digital content node, reads the currently confirmed change sequence number, pending confirmation status, and dispute status recorded by the digital content node, and queries the directed edge of the ownership relationship connected to the digital content node with a currently valid status. It then locates the current rights holder node along the directed edge and reads the rights subject identifier recorded by the current rights holder node. The status field of the digital content node, the currently valid directed edge of the ownership relationship, and the current rights holder node together form the ownership node status used in this pre-inspection.

[0092] The ownership node status can be understood as the ownership status data formed by the directed acyclic graph ownership graph for the corresponding digital content at the current moment. It is used to reflect the current data status of the digital content to be processed, which is available for ownership operation judgment. Its specific data content can be set according to the ownership operation type and actual application scenario.

[0093] After obtaining the ownership node status, the ownership management device performs pre-check verification on the currently received ownership operation requests based on that ownership node status. Pre-check verification is mainly used to determine whether the current ownership operation request matches the current ownership status recorded in the graph, and whether the current ownership status meets the conditions for continuing the ownership operation, before formally generating the target domain event and submitting it to subsequent consensus processing. For ownership transfer requests, the system reads the requester's identity identifier obtained after authentication, compares the requester's identity identifier with the rights holder's identity identifier recorded in the current rights holder node, and determines the pending confirmation status and dispute status respectively. When the requester's identity identifier matches the current rights holder's identity identifier, the pending confirmation status is "no pending confirmation matters," and the dispute status is "normal," the pre-check verification is considered successful; when any condition is not met, the pre-check verification is considered unsuccessful, an error message corresponding to the failure condition is returned, and the mutex lock is released. If the pre-check verification passes, it means that the current ownership operation request can continue to enter the subsequent domain event generation process based on the currently read ownership node status; if the pre-check verification fails, the subsequent processing of the current ownership operation request can be terminated to avoid generating invalid or conflicting domain events based on ownership status that does not meet the processing conditions.

[0094] Since the reading of the ownership node state and the pre-check verification are completed after successfully acquiring the mutex lock, during this pre-check verification, other concurrent ownership operations targeting the same content feature identifier can be prevented from simultaneously entering the same critical processing procedure. Therefore, before the actual generation of the domain event, a distributed lock is used to control the mutual exclusion of concurrent operations corresponding to the same digital content, and then the current ownership node state in the directed acyclic graph ownership graph is used to perform pre-check verification, thus forming a pre-control mechanism for ownership operation requests.

[0095] It should be noted that the distributed lock in this step is mainly used to control concurrent ownership operation requests targeting the same content feature identifier from entering the ownership status pre-check process. It does not mean that the mutex lock is held continuously throughout the entire digital copyright confirmation process. The mutex lock can be released after the corresponding critical processing is completed to reduce the locking duration and minimize the impact of concurrency control on the efficiency of other ownership operation processing.

[0096] By using the above method, ownership operation requests can be pre-verified based on the current valid ownership graph state before the target domain event is generated. This reduces the situation where multiple concurrent requests generate conflicting events based on the same historical ownership state, and provides a relatively consistent state basis for subsequent domain event orchestration and consensus verification.

[0097] For example, suppose that digital content A has generated a corresponding content feature identifier CDV-A through step S101, and the ownership management device receives an ownership operation request for digital content A.

[0098] The ownership management device first initiates a preemption request to the distributed lock component, using CDV-A as the locking object. Assuming that no other ownership operation is currently holding the mutex lock corresponding to CDV-A, the ownership operation request successfully acquires the mutex lock.

[0099] After acquiring the mutex lock, the ownership management device accesses the directed acyclic graph ownership map using CDV-A as the query basis. It locates the ownership node corresponding to the digital content A in the graph and reads the currently recorded ownership node status. Subsequently, based on the read current ownership node status, it performs a pre-check verification on the current ownership operation request to determine whether the request can continue to be executed based on the current ownership status.

[0100] If the pre-inspection verification results indicate that the current ownership operation request meets the conditions for continued processing, the ownership management device will allow the request to enter the subsequent processing flow to further generate the target domain event corresponding to this ownership operation.

[0101] In another concurrent scenario, clients B and C initiate ownership operation requests for the same digital content A at approximately the same time. Since the digital content corresponding to the two requests has the same content feature identifier CDV-A, both requests need to compete for the same mutex lock corresponding to CDV-A.

[0102] Assuming client B's ownership operation request acquires the mutex lock first, this request can read the current ownership node state corresponding to digital content A and complete the pre-check verification during the locking period. Meanwhile, client C's request cannot enter the ownership state pre-check process protected by the mutex lock simultaneously with client B's request. Instead, it needs to wait for subsequent acquisition of the mutex lock or execution of its request according to the distributed lock component's processing mechanism.

[0103] After the ownership operation corresponding to client B completes the critical processing of this stage and releases the mutex lock, the ownership operation request corresponding to client C can reacquire the mutex lock and re-perform pre-check verification based on the ownership node state recorded in the directed acyclic graph ownership graph at this time. In this way, different concurrent ownership operation requests are judged according to the ownership node state corresponding to their actual entry into the processing stage, which can reduce the situation where multiple requests read the same historical state at the same time and execute subsequent ownership processing accordingly.

[0104] For example, when two ownership operation requests target digital content A and digital content B respectively, since the two digital contents correspond to different content feature identifiers CDV-A and CDV-B, different mutex locks can be requested using CDV-A and CDV-B as the locking objects respectively. In the absence of other conflicting conditions, the two ownership operation requests can respectively perform ownership node state reading and pre-check verification for their respective digital contents, without blocking the processing of the other digital content because one digital content is undergoing ownership processing.

[0105] Therefore, this step uses content feature identifiers as the locking granularity of the distributed lock to limit concurrency control to the specific digital content level. After obtaining mutual exclusion processing rights, it performs pre-check verification based on the current ownership node state in the directed acyclic graph ownership graph. This ensures that different digital contents can be processed in parallel while coordinating concurrent ownership operations on the same digital content in advance, providing a state consistency basis for the orderly generation of subsequent target domain events.

[0106] Step S103: After the pre-inspection verification is passed, read the currently confirmed change sequence number corresponding to the content feature identifier in the directed acyclic graph ownership graph, generate a target sequence number that is incremented relative to the currently confirmed change sequence number, encapsulate the ownership operation request, the content feature identifier and the target sequence number into a target domain event, and send the target domain event to the consensus network after releasing the mutex lock.

[0107] Specifically, once the pre-check verification in step S102 passes, it indicates that the current ownership operation request meets the conditions for continued processing. At this time, the ownership management device accesses the directed acyclic graph ownership map based on content feature identifiers and reads the currently confirmed change sequence number of the corresponding digital content. The currently confirmed change sequence number is used to characterize the progress of the ownership change of the corresponding digital content that has been confirmed, and it can increment with the confirmation of valid ownership change events. After reading the currently confirmed change sequence number, the ownership management device generates the target sequence number corresponding to this ownership operation according to a preset incrementing rule, so that the ownership change to be processed is sequentially connected to the confirmed ownership change.

[0108] Subsequently, the ownership operation request, the content feature identifier generated in step S101, and the target sequence number are associated and encapsulated to generate a target domain event. A target domain event includes at least an event identifier, event type, content feature identifier, requester entity identifier, target rights holder identifier or authorized entity identifier, ownership operation parameters, target sequence number, parent event pointer, event generation timestamp, ownership operation request summary, and requester digital signature. Specifically, for general sequence change events, the parent event pointer points to the previous confirmed domain event for the corresponding digital content; for historical correction events, the parent event pointer points to the historical domain event to be corrected. The ownership operation request characterizes the ownership operation to be performed, the content feature identifier determines the digital content corresponding to the domain event, and the target sequence number characterizes the order of the domain event in the ownership change sequence of the corresponding digital content. Through the association of the above information, each target domain event can simultaneously correspond to specific digital content, a specific ownership operation, and the corresponding change order.

[0109] After the target domain event is encapsulated, the ownership management device releases the mutex lock acquired in step S102, allowing subsequent ownership operation requests targeting the same content feature identifier to enter the corresponding processing flow. By releasing the mutex lock promptly after event encapsulation, the lock holding time can be shortened, reducing the impact of distributed locks on the system's concurrent processing capabilities.

[0110] After releasing the mutex lock, the target domain event is sent to the consensus network, which then performs subsequent verification and confirmation. In one specific implementation, the consensus network is a permissioned Byzantine fault-tolerant consensus network, consisting of multiple pre-registered authorized verification nodes. Each verification node is configured with a node identifier, communication address, authentication certificate, and signature public key, and establishes a connection through an authenticated communication channel. If the number of abnormal nodes the network can tolerate is f, then at least 3f+1 verification nodes can be configured. A master node is determined in each consensus view, with the remaining nodes serving as backup nodes. The master node can be determined according to the current view number and a preset node order. When the master node fails, a new master node is determined through view switching.

[0111] Upon receiving a target domain event, the master node verifies the event signature and event digest, assigns consensus sequence numbers to the event according to the order of receipt, and then broadcasts a pre-preparation message containing the event digest, consensus sequence number, and view number to the backup nodes. The backup nodes verify the event signature, content feature identifier, target sequence number, currently confirmed change sequence number, and event digest. When the target sequence number equals the currently confirmed change sequence number plus one, a preparation message is sent. After receiving a preset number of preparation messages with consistent content, a commit message is sent. When a node receives at least 2f+1 valid commit messages for the same event digest, the same view number, and the same consensus sequence number, the target domain event is considered to have passed consensus confirmation.

[0112] For multiple concurrent events targeting the same content feature and carrying the same target sequence number, the event with the earlier consensus sequence number assigned by the master node is confirmed first. After confirmation, its target sequence number serves as the new sequence judgment criterion, and the remaining events are rejected because they no longer satisfy the sequence continuity relationship. Thus, step S103 completes the conversion from "pre-inspected ownership operation requests" to "domain events with clear content association and change order," and provides a data foundation for subsequent consensus network execution of event continuity and concurrent conflict verification through the target sequence number.

[0113] For example, suppose the content feature identifier corresponding to digital content A is CDV-A, and its currently confirmed change sequence number recorded in the directed acyclic graph ownership map is 5. After a certain ownership operation request for digital content A passes the pre-inspection verification in step S102, the ownership management device reads the sequence number and generates a target sequence number 6 according to the incrementing rule.

[0114] Subsequently, the ownership operation request, CDV-A, and target sequence number 6 are associated and encapsulated as a target domain event. Thus, this target domain event clearly indicates that: this event pertains to digital content A, and after the previous 5 confirmed ownership changes for this digital content, it participates in subsequent processing as the next ownership change event to be confirmed.

[0115] After the target domain event is encapsulated, the mutex lock corresponding to CDV-A is released, and the target domain event is sent to the consensus network. The consensus network can then further verify whether the event meets the continuous change requirement based on the target sequence number 6 carried by the event and the current ownership status of the corresponding digital content.

[0116] In this way, ownership changes for the same digital content can have a clear sequence, while avoiding prolonged use of mutex locks after the necessary information encapsulation of domain events has been completed, thus balancing ownership change sequence control with system concurrency efficiency.

[0117] Step S104: Verify the continuity relationship between the target sequence number and the currently confirmed change sequence number through the consensus network, and perform time-series verification on concurrent target domain events to determine the target domain events that pass the verification.

[0118] Specifically, after receiving a target domain event, the consensus network determines the corresponding digital content based on the content feature identifier carried in the event, obtains the currently confirmed change sequence number of the digital content, and compares the target sequence number carried by the target domain event with the currently confirmed change sequence number to determine whether the two satisfy a preset continuous increasing relationship.

[0119] When the target sequence number can form a continuous relationship with the currently confirmed change sequence number, it indicates that the target domain event can be connected to the currently confirmed ownership change in sequence and can continue to participate in subsequent verification; when the target sequence number does not satisfy the continuous relationship with the currently confirmed change sequence number, it indicates that the event may be a duplicate event, an expired event, or a non-continuous event, and it will not be determined as a target domain event that passes verification.

[0120] Furthermore, when the consensus network receives multiple concurrent target domain events targeting the same content feature identifier, it performs a time sequence check on each target domain event to determine the order in which each event enters the consensus processing. For concurrent events with competing relationships, the priority target domain event can be determined based on the order in which the consensus network receives the events, and the validity of the event can be judged by combining the sequence number continuity.

[0121] After sequence continuity and temporal sequence verification, the consensus network identifies the verified target domain events from the target domain events to be verified, which are then used to drive the state update of the subsequent directed acyclic graph ownership graph. By performing the above verification before events enter the graph update stage, multiple conflicting events concerning the same digital content can be further prevented from being simultaneously recognized as valid events, thereby maintaining the sequential consistency among ownership change events.

[0122] For example, digital content A has a currently confirmed change sequence number of 5 in the directed acyclic graph ownership graph. The consensus network receives a target domain event A for digital content A, which carries a target sequence number of 6. Since the target sequence number 6 can be continuously connected to the currently confirmed change sequence number 5, event A passes the sequence continuity check and can continue to proceed with subsequent consensus processing.

[0123] If another target domain event received by the consensus network carries target sequence number 5 or 7, then the target sequence number cannot directly form a next-order continuity relationship with the currently confirmed change sequence number 5. Therefore, it can be determined that the event does not meet the current sequence continuity requirement.

[0124] In a concurrent scenario, suppose the consensus network receives two events, A and B, targeting the same digital content A within a short period, both carrying a target sequence number 6. The consensus network then performs a timing check based on the order in which the two events are received, for example, confirming the earlier received event A as the priority event. Once event A passes the check, its corresponding sequence number becomes the basis for determining subsequent ownership changes for that digital content. Event B, however, no longer satisfies the updated sequence continuity and cannot be considered a valid ownership change event.

[0125] Therefore, by jointly verifying the continuity of sequence numbers and the timing of concurrent events, a consensus layer verification mechanism can be further formed on the basis of the pre-concurrency control of distributed locks, so that the target domain events that finally enter the ownership graph update stage have a clear and consistent processing order.

[0126] Step S105: Obtain the target domain events that have passed the verification, update the nodes and directed edges in the directed acyclic graph ownership graph according to the event type of the target domain events, and update the currently confirmed change sequence number.

[0127] Specifically, after completing the sequence continuity verification and timing verification of the target domain events in step S104, the ownership management device obtains the target domain events that have passed the verification and parses the event types and related ownership operation information carried therein.

[0128] Event type is used to characterize the specific change category corresponding to this ownership operation. Since different types of ownership operations will cause different ownership state changes, the corresponding graph update method is determined based on the event type, and the nodes and / or directed edges in the directed acyclic graph ownership graph are updated. For example, when the ownership subject of digital content corresponding to a target domain event changes, new ownership subject nodes can be created or determined accordingly, and the ownership relationships associated with the digital content nodes can be adjusted; when a target domain event corresponds to a new licensing relationship, nodes or directed edges corresponding to the licensing relationship can be added to the graph.

[0129] The directed acyclic graph (DAG) ownership graph records ownership-related objects such as digital content and rights holders through nodes, and records ownership relationships between objects through directed edges. Target domain events serve as the data basis for driving changes in the graph's state, enabling the graph to be continuously updated with confirmed ownership operations, thus forming a dynamic ownership state corresponding to the process of digital content ownership changes.

[0130] After updating nodes and directed edges, the target sequence number carried by the target domain event is used as the new currently confirmed change sequence number, or the corresponding sequence state is updated based on the target sequence number. The updated sequence number is used to represent the latest ownership change progress that has been confirmed and updated in the graph, and serves as the basis for determining the sequence continuity of subsequent target domain events.

[0131] By linking domain event confirmation, graph status update, and change sequence number update, the ownership status in the directed acyclic graph ownership graph can be kept in correspondence with the confirmed domain events, providing a consistent data foundation for subsequent ownership operation processing and ownership status tracing.

[0132] For example, suppose the currently confirmed change sequence number corresponding to digital content A is 5, and the consensus network confirms that target domain event A with target sequence number 6 has passed verification. After the ownership management device obtains event A, it determines the change in ownership of the digital content A corresponding to this operation based on the event type recorded in the event.

[0133] Subsequently, the directed acyclic graph ownership map is updated based on the ownership operation information carried by event A. For example, the nodes related to digital content A and their corresponding rights holder nodes are identified in the graph, and the directed edges between them are updated according to the current ownership change, so that the updated graph can reflect the current effective ownership relationships of digital content A.

[0134] After the map update is complete, the currently confirmed change sequence number corresponding to digital content A will be updated from 5 to 6. Thereafter, any subsequent target domain event arising from digital content A will be based on the updated sequence number 6 for continuity assessment.

[0135] Thus, through the continuous processing of "verified domain events - ownership map update - change sequence number update", the ownership status in the map is kept synchronized with the confirmed ownership changes, and the latest status basis is provided for the orderly processing of subsequent ownership events.

[0136] Step S106: According to a preset period, the nodes and directed edges in the directed acyclic graph ownership graph are sorted and serialized according to a preset deterministic sorting rule to generate a linear byte data block sequence.

[0137] Specifically, during the continuous updating of ownership status in the directed acyclic graph (DAG) ownership graph, the ownership management device triggers graph data processing according to a pre-set time period, extracting nodes and directed edges that currently require evidence preservation and solidification. The set of nodes and directed edges corresponding to the current anchoring period refers to all nodes and directed edges stored in the DAG ownership graph at the snapshot timestamp, including currently valid nodes, expired nodes, compensated nodes, and their validity status fields. Filtering of some historical data in the query view does not affect its inclusion in the complete graph snapshot.

[0138] Because the weighted graph of a directed acyclic graph (DAG) is a non-linear graph structure composed of nodes and directed edges, the return order of nodes and directed edges in the same graph state may differ in different reading processes. If subsequent hash calculations are performed directly based on unsorted graph data, even if the actual weighted states represented by the graph are the same, different calculation results may occur due to different data arrangement orders. Therefore, it is necessary to sort the nodes and directed edges to be processed according to a preset deterministic sorting rule, so that the same graph state can obtain consistent data arrangement results under the same sorting rule.

[0139] After sorting, each node and directed edge is converted into byte data with a defined data format according to the preset serialization rules, and then organized in a defined order, thereby transforming the original non-linear graph structure into a linearly arranged data form, forming a linear byte data block sequence.

[0140] The preset period can be set according to the data update frequency of the ownership graph and the evidence storage requirements; the deterministic sorting rule is used to ensure that the same graph state can obtain the same data arrangement order; serialization is used to convert the structured data corresponding to nodes and directed edges into byte form that can participate in subsequent cryptographic calculations. Through the above processing, a stable and repeatable data input can be provided for the subsequent generation of Merkle root hash based on linear byte data block sequences.

[0141] For example, suppose a directed acyclic graph ownership graph has been dynamically updated over a period of time. In the current evidence storage period, multiple digital content nodes, rights holder nodes, and directed edges representing ownership relationships need to be processed.

[0142] When the preset period is reached, the ownership management device obtains the nodes and directed edges that need to be stored for evidence. Assuming that the node order obtained when reading the same graph state twice is inconsistent due to different internal storage or query orders in the graph database, directly performing hash processing according to the reading order may lead to different calculation results.

[0143] To avoid the above situation, the ownership management device first rearranges the nodes and directed edges according to a preset deterministic sorting rule, ensuring that the same set of nodes and directed edges always forms a consistent arrangement order. Subsequently, the sorted node data and directed edge data are serialized according to a unified data format and organized sequentially into a linear byte data block sequence.

[0144] Therefore, even if the original return order of the directed acyclic graph ownership map differs when it is read on different devices or at different times, as long as its actual ownership status remains unchanged, consistent linear data results can be obtained after the same deterministic sorting and serialization process, thus ensuring that the subsequent Merkle root hash calculation has a stable data foundation.

[0145] Step S107: Generate a Merkle root hash based on the linear byte data block sequence, and submit the anchored transaction containing the Merkle root hash to the blockchain node for storage and solidification.

[0146] Specifically, after obtaining the linear byte data block sequence in step S106, each data block is hashed, and Merkle tree is constructed by combining and calculating the hash values ​​corresponding to each data block layer by layer, and finally the Merkle tree root hash that can represent the current state of the graph to be stored is obtained.

[0147] Since Merkle root hashes are calculated step-by-step from a linear sequence of byte data blocks, the final generated Merkle root hash will change accordingly when the corresponding node data, directed edge data, or data arrangement changes. Therefore, Merkle root hashes can be used as a cryptographic commitment to the current state of a directed acyclic graph (DAG) ownership graph without having to directly write all node and directed edge data in the graph to the blockchain.

[0148] After obtaining the Merkle root hash, it is encapsulated as core evidence data to form an anchor transaction, which is then submitted to the blockchain node. Once the blockchain node confirms and records the anchor transaction, the Merkle root hash forms evidence information with a corresponding on-chain record. The ownership management device signs the anchor transaction and submits it to the blockchain node. After completing transaction verification and block recording, the blockchain node returns a transaction receipt containing the transaction identifier, block identifier, and execution status. The system only increments the current graph version number when the transaction receipt indicates successful execution of the anchor transaction. If the transaction submission fails, the transaction execution fails, or no successful receipt is received within a preset time, the original graph version number remains unchanged, and the anchor transaction is resubmitted according to the original version number to avoid inconsistencies between the off-chain version number and the on-chain anchor record.

[0149] When it is necessary to verify the off-chain ownership graph data later, the corresponding hash calculation can be re-performed based on the data to be verified, and then correlated with the Merkle root hash recorded in the blockchain for verification. By storing detailed ownership data off-chain and fixing the graph state cryptographic commitment on-chain, the data storage and transaction processing burden caused by directly uploading a large number of ownership nodes and relationship data to the blockchain can be reduced, while the blockchain record provides a basis for integrity verification of the off-chain ownership state.

[0150] For example, suppose that at the end of a certain evidence storage period, step S106 has converted the directed acyclic graph ownership map data that needs to be stored into data blocks A, B, C and D arranged in sequence.

[0151] The ownership management device calculates the hash value corresponding to each data block, then combines adjacent hash values ​​to obtain the hash value of the next layer, and continues to calculate layer by layer until a unique Merkle root hash R is obtained. This root hash R is used to represent the overall ownership graph state corresponding to this notarization.

[0152] Subsequently, the root hash R is encapsulated into the anchor transaction and submitted to the blockchain node. Once the anchor transaction is confirmed and recorded by the blockchain, the notarization and solidification of the ownership graph state is completed.

[0153] If a node or directed edge in the off-chain graph is abnormally modified, the hash result recalculated based on the modified data will be inconsistent with the root hash R anchored on-chain. This indicates a change in off-chain ownership data. Therefore, without writing the entire ownership graph to the blockchain, reliable evidence storage and subsequent integrity verification of the corresponding graph state can be achieved.

[0154] In some embodiments of this application, to address the problems of difficulty in directly fusing different modal features, the potential weakening of core content features by non-core modalities, and insufficient stability in content feature identifier generation when some modalities fail, the stability of the content feature identifier generation process and its adaptability to different types of multimodal digital content are improved. The step of extracting features and performing cross-modal alignment on the effective modal data of the digital content to be processed, and fusing the obtained modal features, includes:

[0155] Extract the modal data contained in the digital content to be processed, and detect the validity of each modal data respectively;

[0156] Feature extraction is performed on each of the detected valid modal data, and the extracted modal features are mapped to a unified semantic space;

[0157] The core content modality is determined based on the content type corresponding to the digital content to be processed, and the feature weights corresponding to each effective modality are calculated.

[0158] When the core modality of the content belongs to a valid modality, the feature weights of each valid modality are adjusted according to the preset core modality weight constraints.

[0159] When the core modality is a failed modality and at least one other valid modality still exists, the core modality weight constraint is not executed, and the feature weights are redistributed among the remaining valid modalities.

[0160] The corresponding modal features are fused according to the adjusted or reassigned feature weights to generate the content feature identifier.

[0161] As described above, the modal data contained in the digital content to be processed are first extracted, and the validity of each modal data is then checked. Modal data here refers to the different information carriers that constitute the digital content, which can include visual, audio, and text data. For example, for music content containing audio, cover art, and lyrics, the audio modality, visual modality, and text modality can be extracted separately. Modal validity detection is used to determine whether the corresponding modality can normally participate in subsequent feature extraction and fusion processing; modalities that cannot be normally read, parsed, or for which valid features cannot be obtained can be identified as invalid modalities and will no longer participate in the current fusion process.

[0162] For modal data that is detected as valid, corresponding modal features are obtained using feature extraction methods adapted to their data types. Since the original features of different modalities may differ in data structure, dimensionality, or semantic representation, cross-modal alignment is further performed on the features to map them to a unified semantic space. For example, visual features, audio features, and text features can be converted into feature vectors of the same dimension, enabling the features corresponding to different modalities to be compared and fused on a unified data representation basis. In one implementation, each modality can be mapped to a 512-dimensional aligned feature vector.

[0163] After obtaining the alignment features corresponding to each valid modality, the core content modality is determined based on the content type of the digital content to be processed. The core content modality refers to the modality that has the primary content representation function for the current type of digital content. For example, for music content, the audio modality can be determined as the core modality; for painting or photography content, the visual modality can be determined as the core modality; for literary content, the text modality can be determined as the core modality; and for video content, the visual modality corresponding to the video frames can be determined as the core modality. By pre-establishing the correspondence between content types and core modalities, the determination of the core modality can have a clear data basis.

[0164] Further, the feature weights corresponding to each effective modality are calculated separately. The feature weights are used to represent the degree of participation of the corresponding modal features in the final fusion result. In one implementation, the corresponding attention weights can be calculated based on the alignment features corresponding to each modality, and the modal weights can be normalized so that the sum of the weights of each effective modality participating in the fusion is 1.

[0165] When the core content modality is a valid modality, the feature weights of each valid modality are adjusted according to a preset core modality weight constraint to ensure that the core modality has a corresponding representational weight during the fusion process. For example, the minimum weight corresponding to the core modality can be set to 0.5; if the calculated core modality weight has reached or exceeded 0.5, the original weight is maintained; if it is lower than 0.5, the core modality weight is adjusted to 0.5, and the remaining weights are redistributed among the other valid modalities. This prevents the core modality, which plays a major role in representing digital content, from being weakened by other auxiliary modalities during feature fusion due to its low weight.

[0166] When the core modality of the content is a failed modality, but at least one other valid modality still exists, since the core modality can no longer provide effective features for fusion, the weight constraints set for that core modality are no longer applied. Instead, feature weights are recalculated or reassigned only for the remaining valid modalities to ensure that their weights meet the current fusion requirements. For example, if the audio modality in music content is abnormal, but the cover image and lyrics can still be extracted normally, downgraded fusion can be performed based on the visual and text modalities, without requiring the audio modality to meet the original core modality weight constraints.

[0167] Finally, based on the adjusted or reallocated feature weights, the modal features corresponding to each effective modality are fused. Specifically, the modal features are weighted and combined according to their respective weights to obtain fused features that can comprehensively represent the digital content to be processed, and content feature identifiers are further generated based on these fused features. Thus, for digital content where all modalities are normal, other modal information can be comprehensively utilized while highlighting the core modality; for digital content where some modalities are ineffective, the remaining effective modalities can be used to continue feature fusion, thereby balancing the relevance of content feature representation with the stability of the generation process.

[0168] In some embodiments of this application, to address issues such as unauthorized entities initiating ownership transfers and digital content continuing to be transferred even when it is in a pending or disputed state, when the ownership operation request is an ownership transfer request, the step of reading the ownership node status corresponding to the content feature identifier in the directed acyclic graph ownership map and performing a pre-check verification of the ownership operation request includes:

[0169] Query the directed acyclic graph ownership map to obtain the current rights holder node and dispute status marker associated with the content feature identifier;

[0170] Determine whether the current right holder corresponding to the current right holder node is consistent with the requester of the ownership transfer request, and determine whether the dispute status marker indicates that the digital content to be processed does not have a pending confirmation status or a dispute status;

[0171] When the current rights holder is the same as the requester and there is no pending confirmation or dispute status, the pre-check verification is deemed successful.

[0172] Otherwise, the ownership transfer request is rejected and the mutex is released.

[0173] As described above, when the received ownership operation request is an ownership transfer request, and a mutex lock has been successfully obtained based on the content feature identifier, the directed acyclic graph ownership map is accessed using the content feature identifier as a query condition to locate the content node associated with the digital content to be processed and its current ownership relationship, thereby determining the corresponding current rights holder node. Simultaneously, the dispute status marker associated with the digital content is read to determine whether the current ownership status is in a state where a normal ownership transfer can be carried out. The current rights holder node represents the rights holder determined according to the current valid ownership relationship; the dispute status marker reflects whether the corresponding digital content has any ownership changes that have not yet been confirmed, or whether there are any ongoing ownership disputes. By simultaneously reading the current rights holder information and the status marker, pre-checks can be performed from two aspects: the qualification of the operating entity and the current ownership status.

[0174] Subsequently, the current rights holder corresponding to the current rights holder node is compared with the requester of the ownership transfer request. When the two match, it indicates that the entity initiating this ownership transfer request matches the current rights holder recorded in the graph; if the two do not match, it indicates that the requester is not a rights holder currently recorded, and the current request does not meet the conditions for continuing to execute this ownership transfer.

[0175] After determining the consistency of the subject matter, the system further assesses whether the digital content to be processed is in a pending confirmation or disputed state based on the dispute status marker. A pending confirmation state indicates that there are still ownership issues related to the digital content that have not yet been confirmed; a disputed state indicates that the current ownership relationship is in dispute and no definitive resolution has been reached. If either of these states exists, to avoid further ownership transfers while the ownership status is still unstable, the pre-verification is deemed to have failed.

[0176] The pre-verification is only considered successful if the current rights holder and the requester of the ownership transfer request are the same, and the digital content to be processed is not in a pending confirmation or disputed state. This allows the ownership transfer request to proceed to the subsequent target sequence number generation and domain event encapsulation process. For example, the content feature identifier corresponding to digital content A is associated with the current rights holder, A. When A initiates an ownership transfer request to transfer digital content A to B, the system obtains a mutex lock, queries the ownership map, confirms that the current rights holder is still A, and that digital content A is not currently in a pending confirmation or disputed state; in this case, the pre-verification is considered successful. If the query finds that the current rights holder has changed to another entity, or that digital content A is currently in an ownership disputed state, the ownership transfer request is rejected.

[0177] If the pre-check fails, no further target domain events corresponding to this ownership transfer request will be generated, and the acquired mutex lock will be released, allowing subsequent requests to continue competing for the locked object. If necessary, feedback information corresponding to the reason for the pre-check failure can also be returned to the request initiator.

[0178] Through the aforementioned pre-screening mechanism, a preliminary filtering can be performed based on the current state of the off-chain ownership graph before the ownership transfer event is formed, so that requests that obviously do not meet the transfer conditions will exit the processing flow as early as possible. Together with the subsequent sequence continuity and concurrent timing verification of the consensus network, it constitutes a layered control over the ownership transfer operation.

[0179] In some embodiments of this application, to address the potential issues of conflicting change order, duplicate confirmations, or continued execution based on expired states when multiple ownership change events for the same digital content concurrently enter the consensus network within a short period, the consensus network verifies the continuity between the target sequence number and the currently confirmed change sequence number, and performs time-series verification on concurrent target domain events, including:

[0180] Obtain the content feature identifier and target sequence number corresponding to the target domain event, and obtain the currently confirmed change sequence number corresponding to the content feature identifier;

[0181] Determine whether the target sequence number is equal to the currently confirmed change sequence number plus one, and only allow target domain events that satisfy this continuity relationship to pass the sequence number verification;

[0182] When there are multiple concurrent target domain events with the same content feature identifier and the same target sequence number, the priority event is determined according to the order in which the consensus master node receives each target domain event.

[0183] The priority events are confirmed through consensus, and after the priority events are confirmed through consensus, their target sequence number is determined as the updated currently confirmed change sequence number, and other concurrent target domain events that do not meet the updated sequence continuity relationship are rejected.

[0184] As described above, after receiving a target domain event, the consensus network first parses the content feature identifier and target sequence number carried in the event. The content feature identifier is used to determine the specific digital content corresponding to the event, and the target sequence number is used to represent the target order of this ownership change within the sequence of digital content ownership changes.

[0185] Subsequently, the currently confirmed change sequence number of the corresponding digital content is obtained based on the content feature identifier, and the target sequence number is compared with the currently confirmed change sequence number. Only when the target sequence number is equal to the currently confirmed change sequence number plus one is the target domain event considered to be continuous with the current ownership change state and can pass the sequence number verification. If the target sequence number is less than or equal to the currently confirmed change sequence number, it indicates that the event may be a duplicate event or an event generated based on an old state; if the target sequence number is greater than the currently confirmed change sequence number plus one, it indicates that there are gaps or jumps in the event sequence, and therefore neither is considered a currently confirmed valid event. For example, if the currently confirmed change sequence number of a digital content is 5, then under normal circumstances, the target sequence number carried by the next target domain event should be 6. Events with a target sequence number of 6 satisfy the continuity relationship and can proceed to subsequent consensus confirmation; events with target sequence numbers of 5 or 7 do not meet the current continuity requirement.

[0186] Furthermore, when the consensus network simultaneously or within a short period of time receives multiple concurrent target domain events targeting the same content feature identifier and having the same target sequence number, it indicates that these events are all generated based on the same current ownership state and are competing for the same change order. In this case, the priority event is determined according to the order in which the consensus master node actually receives each target domain event, and the event that enters the consensus processing flow first is taken as the priority confirmation object.

[0187] Consensus confirmation is performed on priority events. Once an event is confirmed through consensus, its target sequence number is set as the new currently confirmed change sequence number. At this point, when other concurrent events with the same target sequence number undergo continuity checks, their target sequence numbers are no longer equal to the updated currently confirmed change sequence number plus one. Therefore, the sequence continuity relationship is no longer satisfied, and they are rejected from entering the valid ownership change process. For example, digital content A has a currently confirmed change sequence number of 5. Target domain events A and B both carry a target sequence number of 6 and enter the consensus network sequentially. If the master node receives event A first, it determines event A as the priority event and performs consensus confirmation. After event A is successfully confirmed, the currently confirmed change sequence number of digital content A is updated to 6. At this time, event B still carries a target sequence number of 6, which no longer forms a "plus one" continuity relationship with the updated currently confirmed change sequence number; therefore, event B is rejected.

[0188] Through the above processing, ownership changes of the same digital content can be confirmed sequentially according to a defined sequence. When multiple conflicting events compete for the same change order, only one event is allowed to become a valid event, thereby avoiding multiple concurrent ownership operations from changing the same ownership state at the same time and ensuring the consistency of the subsequent directed acyclic graph ownership map update process.

[0189] In some embodiments of this application, to further define the driving update method of the directed acyclic graph (DAG) ownership graph by target domain events, so that different types of ownership changes can be processed according to the corresponding graph update logic, updating the nodes and directed edges in the DAG ownership graph according to the event type of the target domain event includes:

[0190] Identify the event type of the target domain events that pass the verification;

[0191] When the target domain event is an ownership transfer event, a target rights holder node is created or determined in the directed acyclic graph ownership graph, and a directed edge for ownership relationship between the digital content node and the target rights holder node is established or updated.

[0192] When the target domain event is a licensing event, an licensing protocol node is created, and a directed edge establishing the licensing relationship between the digital content node and the licensed entity node is established.

[0193] When the target domain event is a historical correction event, the compensation update logic is triggered to logically correct the historical erroneous ownership status in the directed acyclic graph ownership map.

[0194] As described above, after a target domain event passes consensus verification, the event type recorded in the event is first read, and the graph update logic corresponding to this ownership operation is determined based on the event type. The target domain event can carry content feature identifiers, ownership operation information, and subject information related to this change, enabling the event to establish a correspondence with the corresponding digital content nodes and other associated nodes in the directed acyclic graph ownership graph.

[0195] When the target domain event is a rights transfer event, it indicates a change in the rights holder corresponding to the digital content. At this time, based on the target rights holder information recorded in the event, the corresponding rights holder node is searched in the directed acyclic graph (DAG) rights graph. If the node does not yet exist, it is created; if it already exists, it is directly identified. Subsequently, based on the results of this rights transfer, directed edges establishing or updating the rights relationship between the digital content node and the target rights holder node are established, ensuring the updated graph reflects the rights relationship between the digital content and the current rights holder. For example, when digital content is transferred from rights holder A to rights holder B, the node corresponding to rights holder B can be determined based on the verified rights transfer event, and the "belonging" relationship corresponding to the digital content node can be updated, ensuring the graph reflects the results of this rights transfer.

[0196] When a target domain event is a licensing event, it indicates that the relevant rights to the digital content have been licensed to a specific entity. In this case, a corresponding licensing agreement node is created based on the licensing information recorded in the event. This node records the agreement or licensing matters formed in this license and identifies the node corresponding to the licensee. Based on this, directed edges establishing licensing relationships are established between digital content nodes and licensee nodes, enabling the graph to record the licensing relationships formed between digital content and licensees. Licensing agreement nodes can also be associated with corresponding digital content nodes and licensee nodes to represent the specific ownership relationships corresponding to this license.

[0197] When a target domain event is a historical correction event, it indicates that there are erroneous states in the recorded historical ownership status that need to be corrected. In this case, instead of directly deleting or overwriting the original historical nodes and their relationships, a compensation update logic is triggered. This involves adding graph data corresponding to the correction operation to logically offset or correct the original erroneous ownership status, ensuring that subsequent queries can obtain the corrected and valid ownership results, while preserving the original erroneous status and the subsequent correction process. For example, if a digital content was incorrectly recorded as belonging to right holder D, and it is later confirmed that the actual right holder should be A, a compensation update can be triggered through a historical correction event. This adds the corresponding compensation relationship while preserving the original erroneous ownership record, and redirects the current valid ownership status back to the correct right holder A. Thus, the corrected current status can be obtained in regular ownership queries, while the erroneous status and its subsequent correction process can still be viewed during historical audits or ownership retrospectives, achieving complete preservation of ownership history.

[0198] In this way, different types of target domain events drive the corresponding graph update operations, enabling the directed acyclic graph ownership graph to continuously form a graph structure corresponding to the current effective ownership status while preserving the historical ownership change process.

[0199] In some embodiments of this application, to address the problem that directly deleting or overwriting historical ownership data would disrupt the ownership evolution chain and affect subsequent auditing and tracing, logical correction is performed on the historical erroneous ownership states in the directed acyclic graph ownership map, including:

[0200] The historical event to be corrected is determined based on the parent event pointer carried by the historical correction event, and the historical error node and original edge relationship corresponding to the historical event are located in the directed acyclic graph ownership graph.

[0201] The historical error nodes and their original edge relationships are retained. An offset node is added to the directed acyclic graph ownership graph to represent the compensation operation, and a directed edge is established between the offset node and the historical error node to represent the offset relationship.

[0202] The validity status of the historical error nodes and / or their corresponding original edge relationships in the query view layer is updated from the current valid status to the compensated status, so that the system filters out nodes and / or directed edges in the compensated status when responding to regular ownership query requests, and retains their queryability during historical audits or ownership backtracking.

[0203] As described above, when a target domain event is identified as a historical correction event, the parent event pointer carried by the historical correction event is first parsed. The parent event pointer points to the historical event targeted by this correction operation. Based on this pointer, the historical event to be corrected can be identified in the existing event records, and further, the historical error nodes formed or affected by this historical event and their corresponding original edge relationships can be located in the directed acyclic graph ownership graph. For example, if a historical ownership transfer event incorrectly changed the rights holder of digital content from A to D, the erroneous ownership transfer event can be located based on the parent event pointer carried by the historical correction event, and the relevant nodes representing the erroneous rights holder D in the graph, as well as the directed edges of the original ownership relationship formed between the digital content nodes and D, can be further identified.

[0204] After identifying historical erroneous nodes and existing edge relationships, instead of directly deleting the historical erroneous nodes or physically removing the existing edge relationships, this historical data is preserved in the directed acyclic graph (DAG) ownership graph. Simultaneously, a new offset node is added to represent the current compensation operation, and directed edges are established between the offset node and the historical erroneous node to indicate that the original historical ownership state has been corrected by the subsequent compensation operation. Depending on the actual correction content, the corrected effective ownership state can also be recorded through corresponding graph relationships. This approach ensures that the original erroneous ownership record remains as a historical fact in the graph, while the addition of an offset node records the correction action itself, thus forming a correlation between the "original erroneous event" and the "compensation correction event."

[0205] Furthermore, to prevent compensated historical error states from continuing to be presented as current valid ownership states, a validity status is set for historical error nodes and / or their corresponding original edge relationships at the query view layer. Initially, the corresponding node or directed edge can be in the current valid state; when the corresponding historical error state is compensated and corrected, its validity status is updated to the compensated state.

[0206] When responding to a regular ownership query request, the query view filters historical erroneous nodes and / or directed edges that are in a compensated state based on the validity status, so that the returned query results only reflect the currently valid ownership status. For example, in the scenario above where A was mistakenly changed to D and subsequently corrected, the regular query results will no longer display D as the current rights holder, but will return the corrected valid ownership information.

[0207] For historical audits or ownership retrospective requests, historical data in compensated states is not hidden. Historical error nodes, original edge relationships, and subsequently added offsetting nodes and relationships can be queried simultaneously to restore the complete ownership change process. Therefore, without compromising the integrity of historical data, the current valid ownership status can be distinguished from historically invalidated states, allowing regular business queries and historical audits to obtain data results appropriate to their respective purposes.

[0208] In some embodiments of this application, to address the problem that graph data itself is a non-linear structure, and the reading order of nodes and edges, as well as the output order of attribute fields, may change due to different database query processes, resulting in different byte data being generated for the same graph state, the nodes and directed edges in the directed acyclic graph ownership graph are sorted and serialized according to a preset deterministic sorting rule, including:

[0209] Get the set of nodes and the set of directed edges corresponding to the current anchoring period;

[0210] For the node set, the nodes are sorted in ascending order according to the parent event identifier that triggered the corresponding node in the metadata of each node. The node fields corresponding to each node are extracted in the order of the preset node fields. The node attribute fields are then serialized after being arranged in lexicographical order of the attribute keys to obtain the node serialized data.

[0211] For the set of directed edges, the parent event identifier bound to the starting node of each directed edge is used as the first sorting key, and the parent event identifier bound to the ending node is used as the second sorting key for ascending sorting. When the first sorting key and the second sorting key are the same, the creation time of the directed edge is used as the third sorting key for sorting.

[0212] The directed edge fields corresponding to each directed edge are extracted sequentially according to the preset directed edge field order, and the relation attribute fields are arranged in lexicographical order of attribute keys and then serialized to obtain the directed edge serialized data.

[0213] The node serialized data and the directed edge serialized data are sequentially concatenated according to a preset concatenation order to generate the linear byte data block sequence.

[0214] As described above, when the preset anchoring period is reached, the node set and directed edge set corresponding to the current anchoring period are first obtained. The node set contains various graph nodes that need to be included in the anchoring process, and the directed edge set contains the ownership, authorization, and derivation relationships formed between these nodes. By extracting the node set and directed edge set separately, independent deterministic sorting and serialization processes can be performed according to their respective data structures.

[0215] For a set of nodes, the parent event identifier recorded in the metadata of each node is read. This parent event identifier represents the domain event that triggered the corresponding node and can serve as a deterministic sorting criterion when ranking nodes. Nodes are sorted in ascending order according to the size of their corresponding parent event identifiers, ensuring that graphs with the same set of nodes maintain a consistent node arrangement order during each serialization process.

[0216] After the nodes are sorted, the fields required for serialization are extracted sequentially for each node according to a pre-determined order. For example, node type, node identifier, parent event identifier, content feature data associated with the node, and other node attributes can be extracted sequentially. For attribute fields within a node, since the order of different attributes during storage or retrieval may vary, the attributes are further arranged lexicographically by their keys, and then serialized according to a unified data format. Thus, each node is converted into corresponding node byte data according to the same field order and attribute arrangement rules, and the sorted node byte data is then organized sequentially to form the node serialized data.

[0217] For a set of directed edges, since each directed edge connects a start node and a stop node, it is first sorted in ascending order using the parent event identifier bound to the start node as the first sorting key, and then in ascending order using the parent event identifier bound to the stop node as the second sorting key. This establishes a unified edge arrangement rule based on the definite order of events corresponding to the nodes at both ends of the directed edge. When two or more directed edges have the same first and second sorting keys, they are further sorted using the creation time of the directed edge as the third sorting key, thus solving the problem of not being able to uniquely determine the arrangement order when there are multiple directed edges with the same start and stop nodes. Through this multi-level sorting, the set of directed edges can form a stable and definite arrangement.

[0218] After sorting the directed edges, the fields corresponding to each directed edge are extracted sequentially according to the preset order of the directed edge fields, such as relation type, start node identifier, end node identifier, and relation attributes. For relation attribute fields, they are also arranged in lexicographical order of attribute keys, and then serialized according to a unified data format to obtain the byte data corresponding to each directed edge, and the serialized data of the directed edges is formed sequentially according to the sorting results.

[0219] Finally, the node serialized data and directed edge serialized data are concatenated in a pre-defined concatenation order. For example, the serialized byte data corresponding to all nodes can be arranged first, and then the serialized byte data corresponding to all directed edges can be arranged, thereby converting the original non-linear graph structure composed of nodes and directed edges into a linear byte data block sequence with a fixed order.

[0220] For the same directed acyclic graph (DAG) with weighted graphs, even if the original return order of nodes and directed edges read from the graph database differs twice, as long as the node content and edge relationships remain unchanged, the same linear byte data block sequence can still be obtained after processing according to the parent event identifier sorting, multi-level edge sorting, fixed field order, and attribute key lexicographical order. This eliminates the uncertainty of the database read order and attribute arrangement order, providing a definite data input for the stable generation of the subsequent Merkle root hash.

[0221] In some embodiments of this application, to address the issue that the large volume of complete ownership map data and direct writing to the blockchain would increase the burden on on-chain storage and transaction processing, a Merkle root hash is generated based on the linear byte data block sequence, and the anchored transaction containing the Merkle root hash is submitted to the blockchain node for evidence preservation and solidification, including:

[0222] The linear byte data block sequence is divided into multiple ordered data blocks according to a preset data block partitioning rule;

[0223] Calculate the hash value of each data block separately, and use each hash value as a leaf node of the Merkle tree. Perform paired hash operations on adjacent nodes and recursively layer by layer until a unique Merkle tree root hash is obtained.

[0224] Obtain the graph version number and snapshot timestamp corresponding to the current graph snapshot, and encapsulate the Merkle root hash, the graph version number, and the snapshot timestamp into the anchor transaction;

[0225] The anchoring transaction is submitted to the blockchain node for recording, and the graph version number is updated after successful anchoring.

[0226] As described above, after the deterministic sorting and serialization of the directed acyclic graph (DAG) ownership graph are completed, linear byte data arranged in a fixed order is obtained. This linear byte data is then divided into multiple data blocks with a definite sequential order according to a preset data block partitioning rule. The data block partitioning rule can be based on a preset fixed data length, or it can be based on the serialized data units corresponding to nodes or directed edges, as long as the same partitioning rule can form the same data block sequence for the same graph state. In one embodiment, the serialized byte data corresponding to the complete graph snapshot can be divided into multiple ordered data blocks arranged sequentially according to a fixed block size.

[0227] After the data blocks are partitioned, the hash value corresponding to each data block is calculated, and the hash value of each data block is used as the leaf node of the Merkle tree. The hash calculation can use a preset cryptographic hash algorithm, such as SHA-256. Then, the hash values ​​corresponding to adjacent leaf nodes are paired and combined, and the combined result is hashed again to obtain the hash value of the node in the next layer. This pairing hashing operation is performed layer by layer in the same way until a unique Merkle tree root hash is finally obtained. For cases where the number of nodes in a certain layer is odd, a pre-defined processing rule can be used, such as copying the last node before pairing, to ensure that the construction rules of the Merkle tree remain consistent across different anchoring processes.

[0228] Since the Merkle root hash is calculated layer by layer from all ordered data blocks corresponding to the current graph snapshot, any change in the node data, directed edge data, or their corresponding attributes included in this snapshot will result in a corresponding change in the recalculated root hash. Furthermore, for the same graph state, a consistent Merkle root hash can be obtained by using the same deterministic sorting, serialization, and data block partitioning rules. Therefore, this root hash can serve as a cryptographic commitment to the overall state of the current graph snapshot.

[0229] After obtaining the Merkle root hash, the graph version number and snapshot timestamp corresponding to the current graph snapshot are further obtained. The graph version number is used to distinguish graph snapshots corresponding to different anchoring periods and can use an incrementally maintained version identifier. The snapshot timestamp records the time information corresponding to the generation or anchoring process of the current graph snapshot. The Merkle root hash, graph version number, and snapshot timestamp are associated and encapsulated to form the anchoring transaction corresponding to the current graph snapshot. Through the graph version number and snapshot timestamp, a correspondence between on-chain anchoring records and specific off-chain graph snapshots can be established, facilitating subsequent location of the corresponding historical graph state according to version or time.

[0230] Subsequently, the generated anchor transaction is submitted to the blockchain node, which records the anchor transaction according to the corresponding transaction processing mechanism. After the anchor transaction is successfully written to the blockchain, the on-chain notarization and solidification of the Merkle root hash corresponding to the current graph snapshot is completed, and the graph version number is updated so that the updated version number can be used to identify the next graph snapshot.

[0231] For example, if the version number of the current graph snapshot to be anchored is 10, after completing deterministic serialization and Merkle tree calculation, the root hash R10 is obtained, and the current snapshot timestamp T10 is recorded. Then, R10, version number 10, and timestamp T10 can be encapsulated into an anchoring transaction and submitted to the blockchain node. After successful anchoring, the graph version number maintained by the system is updated to 11. When generating the next graph snapshot, version number 11 is used as the corresponding version identifier. In this way, each on-chain anchoring record can form a clear correspondence with off-chain graph snapshots at different points in time. When it is necessary to verify the state of a certain historical graph, the Merkle tree root hash of the corresponding snapshot can be recalculated and compared with the on-chain anchoring result of the corresponding version to determine whether the graph snapshot data is consistent with the state at the time of anchoring.

[0232] In some embodiments of this application, to address the issues that directly terminating the entire processing flow would reduce system applicability when some modalities in multimodal digital content cannot participate in content feature identifier generation due to missing data, abnormal format, or feature extraction failure, and that continuing to generate content feature identifiers when all valid features are missing might lead to distorted results, the following steps are added after separately detecting the validity of each modality's data:

[0233] When the digital content to be processed contains multiple modal data, and some modal data are invalid but at least one valid modal data exists, the content feature identifier is generated based on the remaining valid modal data, and the modal missing identifier corresponding to the invalid modal data is recorded.

[0234] When all modal data of the digital content to be processed are invalid, or when the digital content to be processed is a single modal content and its unique modal data is invalid, the generation process of the content feature identifier is terminated, and an error feedback message carrying modal failure information is generated.

[0235] As described above, after detecting the validity of each modal data in the digital content to be processed, the generation method of subsequent content feature identifiers is determined based on the validity detection results.

[0236] When the digital content to be processed contains multiple modalities, and only some modalities are invalid while at least one valid modality remains, the content feature identifier generation process is not terminated. Instead, the invalid modalities are excluded from subsequent feature extraction or feature fusion processes, and feature extraction, cross-modal alignment, and feature fusion are continued based on the remaining valid modalities. Specifically, for multiple remaining valid modalities, features corresponding to these valid modalities can be fused; when only one valid modality remains, content feature identifiers can continue to be generated based on the features corresponding to that valid modality.

[0237] Simultaneously, a modality missing identifier is recorded for the failed modal data. This identifier indicates that the corresponding modal data was not used during the generation of the content feature identifier. It can be associated with and saved in conjunction with the generated content feature identifier or its corresponding processing record for future identification of whether the content feature identifier was generated under partial modality missing conditions. It should be noted that the modality missing identifier is primarily used to record modality anomalies and does not indicate that the failed modality participated in the feature fusion process. For example, for music content composed of audio, cover image, and lyrics, if the cover image cannot obtain valid visual features due to file corruption, but the audio and lyrics are valid, the visual modality can be marked as missing. Feature alignment and fusion can then be performed based on the valid audio and text modalities to generate the corresponding content feature identifier.

[0238] When all modal data of the digital content to be processed is detected as invalid, the content feature identifier generation process is terminated because there is no modal data that can effectively represent the current digital content. Subsequent feature extraction, feature fusion, and content feature identifier output operations are no longer performed. Similarly, when the digital content to be processed is unimodal and the only modal data is invalid, the content feature identifier generation process is also terminated because there are no other valid modalities that can be used to replace or supplement it. For example, for a photographic work containing only one image, if the image file is corrupted and valid visual features cannot be obtained, the corresponding content feature identifier will not be generated.

[0239] Upon terminating the generation process, an error feedback message carrying modal failure information is generated. The modal failure information can be used to indicate the modal type of the anomaly and the corresponding failure status, so that the request initiator or subsequent processing module can know the reason for the failure of this content feature generation and perform re-upload, data repair, or other anomaly handling accordingly.

[0240] Through the above processing, the system has the ability to degrade when some modalities are unavailable but still retain valid content information, and stops generating content feature identifiers when there is a lack of any valid modal information, thereby preventing data without valid feature basis from entering the subsequent ownership pre-inspection, domain event generation and ownership map update process.

[0241] Compared with existing technologies, this application discloses a method for hierarchical digital copyright confirmation. This method extracts features, aligns across modalities, and fuses features from the effective modal data of the digital content to be processed, generating content feature identifiers for associating digital content with ownership information. This improves the unified representation and ownership association capabilities of digital content in different modalities. Using the content feature identifiers as locking objects, distributed mutual exclusion control and ownership status pre-detection are implemented. Combined with incremental target sequence numbers and consensus network-based sequence continuity and concurrent event timing verification, the possibility of ownership status conflicts and inconsistent event order caused by concurrent ownership operations can be reduced. Furthermore, the directed acyclic graph ownership graph is dynamically updated based on the verified target domain events. The nodes and directed edges in the spectrum enable continuous updating and dynamic tracing of digital copyright ownership relationships. Furthermore, by deterministically sorting and serializing the directed acyclic graph ownership graph, the graph state is converted into a linear byte data block sequence and a Merkle root hash is generated, allowing the same graph state to form a stable cryptographic commitment. Finally, the anchored transaction containing the Merkle root hash is submitted to the blockchain node for evidence preservation and solidification. This reduces the storage and processing overhead caused by frequent on-chain uploading of complete ownership details while ensuring the integrity, verifiability, and credibility of off-chain dynamic ownership data. This improves the processing efficiency, consistency, and reliability of the digital copyright confirmation system in complex, multimodal, and high-concurrency ownership management scenarios.

[0242] Based on the same inventive concept as the methods described above, this application also proposes a digital copyright hierarchical rights confirmation system, such as... Figure 2 The diagram shown is a structural schematic of a digital copyright hierarchical rights confirmation system, which includes:

[0243] The feature identifier generation module is used to receive ownership operation requests, extract features and perform cross-modal alignment on the effective modal data of the digital content to be processed, and fuse the obtained modal features to generate the content feature identifier of the digital content to be processed.

[0244] The pre-detection locking module is used to initiate a preemption request to the distributed lock component with the content feature identifier as the locking object. After acquiring the mutex lock, it reads the status of the ownership node corresponding to the content feature identifier in the directed acyclic graph ownership graph and performs pre-detection verification on the ownership operation request.

[0245] The event orchestration module is used to read the currently confirmed change sequence number corresponding to the content feature identifier in the directed acyclic graph ownership graph after the pre-inspection verification is passed, generate a target sequence number that is incremented relative to the currently confirmed change sequence number, encapsulate the ownership operation request, the content feature identifier and the target sequence number into a target domain event, and send the target domain event to the consensus network after releasing the mutex lock;

[0246] The consensus verification module is used to verify the continuity relationship between the target sequence number and the currently confirmed change sequence number through the consensus network, and to perform time-series verification on concurrent target domain events to determine the target domain events that pass the verification.

[0247] The graph update module is used to obtain the target domain events that have passed the verification, update the nodes and directed edges in the directed acyclic graph ownership graph according to the event type of the target domain events, and update the currently confirmed change sequence number.

[0248] The graph serialization module is used to sort and serialize the nodes and directed edges in the directed acyclic graph ownership graph according to a preset period and a preset deterministic sorting rule to generate a linear byte data block sequence.

[0249] The on-chain anchoring module is used to generate a Merkle root hash based on the linear byte data block sequence, and submit the anchoring transaction containing the Merkle root hash to the blockchain node for storage and solidification.

[0250] As described above, this embodiment also provides a digital copyright hierarchical rights confirmation system, which can be deployed on a server, a server cluster, or a distributed processing environment consisting of multiple computing nodes. The system includes a feature identifier generation module, a pre-detection locking module, an event orchestration module, a consensus verification module, a graph update module, a graph serialization module, and an on-chain anchoring module. Each module can transmit information sequentially according to the data processing flow, or it can be distributed across different computing devices as needed, completing data interaction via a network.

[0251] The feature identifier generation module receives ownership operation requests and determines the corresponding digital content to be processed. For valid modal data within the digital content that can participate in processing, corresponding features are extracted. Cross-modal alignment transforms the features corresponding to different modalities into a unified feature space. The obtained modal features are then fused to generate a content feature identifier representing the digital content. This content feature identifier serves as the basis for associating subsequent ownership events with the digital content, enabling different ownership operations on the same digital content to be linked to corresponding content features.

[0252] The pre-detection locking module, upon obtaining a content feature identifier, initiates a preemption request to the distributed lock component using that identifier as the locking object. After successfully acquiring the corresponding mutex lock, it accesses the directed acyclic graph (DAG) ownership graph based on the content feature identifier, reads the ownership node status corresponding to the current digital content, and performs pre-detection verification on the received ownership operation requests based on the current ownership node status. By using the content feature identifier as the locking granularity, multiple concurrent ownership requests for the same digital content can be restricted from entering the critical processing simultaneously, while allowing requests for different digital content to be processed separately.

[0253] The event orchestration module, after a rights operation request passes pre-verification, reads the corresponding currently confirmed change sequence number from the directed acyclic graph (DAG) rights graph based on the content feature identifier, and generates a target sequence number that increments relative to that sequence number. Subsequently, the rights operation request, content feature identifier, and target sequence number are associated and encapsulated to form a target domain event. After the target domain event is generated, the previously acquired mutex lock is released, and the target domain event is sent to the consensus network for further processing. This module transforms externally submitted rights operations into standardized events with clear digital content relationships and change sequences, enabling subsequent rights status changes to be processed and traced based on these events.

[0254] The consensus verification module is used to verify the validity of target domain events entering the consensus network. On one hand, it determines whether an event meets the continuous change requirement based on the relationship between the target sequence number carried by the target domain event and the currently confirmed change sequence number of the corresponding digital content. On the other hand, when multiple target domain events targeting the same content feature compete concurrently, a time-series verification is performed on these events to determine which target domain events can pass the verification. Through the pre-control of distributed locks and the sequence and time-series verification in the consensus network, a multi-layered consistency control mechanism can be formed for concurrent ownership operations.

[0255] The graph update module is used to acquire target domain events that have passed consensus verification, identify the event types corresponding to the target domain events, and update the nodes and directed edges in the directed acyclic graph (DAG) ownership graph according to the ownership changes represented by the events, ensuring that the graph state is consistent with the confirmed ownership changes. Simultaneously, the corresponding target sequence number is updated to the currently confirmed change sequence number, providing a new state benchmark for the sequential verification of subsequent ownership events. By updating the ownership graph in an event-driven manner, continuously generated ownership changes can be transformed into dynamic state changes in the off-chain graph.

[0256] The graph serialization module reads nodes and directed edges from a directed acyclic graph (DAG) that need to participate in the current anchoring process at a preset period, and sorts them according to a preset deterministic sorting rule. After sorting, the originally non-linear graph data is converted into a linear sequence of byte data blocks with a definite arrangement order, following a unified field organization and serialization rule. Through deterministic sorting and serialization, the impact of different reading orders of the graph database on subsequent hash calculation results can be reduced, enabling stable data input for the same graph state.

[0257] The on-chain anchoring module is used to construct a Merkle tree based on the linear byte data block sequence generated by the graph serialization module, obtain the corresponding Merkle tree root hash, and then encapsulate the Merkle tree root hash into the anchoring transaction and submit it to the blockchain node for recording. In this way, complete ownership details and high-frequency updates can be retained in the off-chain directed acyclic graph ownership graph, while cryptographic commitments that can represent the state of the corresponding graph are written into the blockchain, realizing the combination of off-chain ownership data management and on-chain trusted evidence storage.

[0258] Through the collaborative processing of the above modules, the system can sequentially complete the generation of digital content feature identifiers, pre-detection of concurrent ownership operations, orchestration and consensus verification of domain events, dynamic updating of ownership graphs, and deterministic serialization and on-chain anchoring of graph states, thereby forming a complete processing chain from digital content identification and dynamic ownership change management to ownership status storage and solidification.

[0259] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0260] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0261] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0262] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0263] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for digital copyright layered rights management, characterized by, Performed by the ownership management equipment, the method includes: Upon receiving a request for ownership operation, the system extracts features and performs cross-modal alignment on the valid modal data of the digital content to be processed, and fuses the obtained modal features to generate a content feature identifier for the digital content to be processed. Using the content feature identifier as the locking object, a preemption request is initiated to the distributed lock component. After acquiring the mutex lock, the status of the ownership node corresponding to the content feature identifier in the directed acyclic graph ownership graph is read, and the ownership operation request is pre-checked and verified. After the pre-inspection verification is passed, the currently confirmed change sequence number corresponding to the content feature identifier in the directed acyclic graph ownership graph is read, a target sequence number that is incremented relative to the currently confirmed change sequence number is generated, the ownership operation request, the content feature identifier and the target sequence number are encapsulated into a target domain event, and the target domain event is sent to the consensus network after the mutex lock is released. The consensus network is used to verify the continuity between the target sequence number and the currently confirmed change sequence number, and to perform time-series verification on concurrent target domain events to determine the target domain events that pass the verification. Obtain the target domain events that have passed the verification, update the nodes and directed edges in the directed acyclic graph ownership graph according to the event type of the target domain events, and update the currently confirmed change sequence number; According to a preset period, the nodes and directed edges in the directed acyclic graph ownership graph are sorted and serialized according to a preset deterministic sorting rule to generate a linear byte data block sequence. A Merkel root hash is generated based on the linear byte data block sequence, and the anchored transaction containing the Merkel root hash is submitted to the blockchain node for storage and solidification.

2. The method of claim 1, wherein, The process of extracting features and performing cross-modal alignment on the effective modal data of the digital content to be processed, and fusing the obtained modal features, includes: Extract the modal data contained in the digital content to be processed, and detect the validity of each modal data respectively; Feature extraction is performed on each of the detected valid modal data, and the extracted modal features are mapped to a unified semantic space; The core content modality is determined based on the content type corresponding to the digital content to be processed, and the feature weights corresponding to each effective modality are calculated. When the core modality of the content belongs to a valid modality, the feature weights of each valid modality are adjusted according to the preset core modality weight constraints. When the core modality is a failed modality and at least one other valid modality still exists, the core modality weight constraint is not executed, and the feature weights are redistributed among the remaining valid modalities. The corresponding modal features are fused according to the adjusted or reassigned feature weights to generate the content feature identifier.

3. The method of claim 1, wherein, When the ownership operation request is an ownership transfer request, the step of reading the ownership node status corresponding to the content feature identifier in the directed acyclic graph ownership map and performing a pre-check verification of the ownership operation request includes: Query the directed acyclic graph ownership map to obtain the current rights holder node and dispute status marker associated with the content feature identifier; Determine whether the current right holder corresponding to the current right holder node is consistent with the requester of the ownership transfer request, and determine whether the dispute status marker indicates that the digital content to be processed does not have a pending confirmation status or a dispute status; When the current rights holder is the same as the requester and there is no pending confirmation or dispute status, the pre-check verification is deemed successful. Otherwise, the ownership transfer request is rejected and the mutex is released.

4. The method as described in claim 1, characterized in that, The consensus network is used to verify the continuity between the target sequence number and the currently confirmed change sequence number, and to perform time-series verification on concurrent target domain events, including: Obtain the content feature identifier and target sequence number corresponding to the target domain event, and obtain the currently confirmed change sequence number corresponding to the content feature identifier; Determine whether the target sequence number is equal to the currently confirmed change sequence number plus one, and only allow target domain events that satisfy this continuity relationship to pass the sequence number verification; When there are multiple concurrent target domain events with the same content feature identifier and the same target sequence number, the priority event is determined according to the order in which the consensus master node receives each target domain event. The priority events are confirmed through consensus, and after the priority events are confirmed through consensus, their target sequence number is determined as the updated currently confirmed change sequence number, and other concurrent target domain events that do not meet the updated sequence continuity relationship are rejected.

5. The method as described in claim 1, characterized in that, Updating the nodes and directed edges in the directed acyclic graph (DAG) ownership graph based on the event type of the target domain event includes: Identify the event type of the target domain events that pass the verification; When the target domain event is an ownership transfer event, a target rights holder node is created or determined in the directed acyclic graph ownership graph, and a directed edge for ownership relationship between the digital content node and the target rights holder node is established or updated. When the target domain event is a licensing event, an licensing protocol node is created, and a directed edge establishing the licensing relationship between the digital content node and the licensed entity node is established. When the target domain event is a historical correction event, the compensation update logic is triggered to logically correct the historical erroneous ownership status in the directed acyclic graph ownership map.

6. The method as described in claim 5, characterized in that, Logical correction is performed on historical erroneous ownership states in the directed acyclic graph ownership map, including: The historical event to be corrected is determined based on the parent event pointer carried by the historical correction event, and the historical error node and original edge relationship corresponding to the historical event are located in the directed acyclic graph ownership graph. The historical error nodes and their original edge relationships are retained. An offset node is added to the directed acyclic graph ownership graph to represent the compensation operation, and a directed edge is established between the offset node and the historical error node to represent the offset relationship. The validity status of the historical error nodes and / or their corresponding original edge relationships in the query view layer is updated from the current valid status to the compensated status, so that the system filters out nodes and / or directed edges in the compensated status when responding to regular ownership query requests, and retains their queryability during historical audits or ownership backtracking.

7. The method as described in claim 1, characterized in that, The nodes and directed edges in the directed acyclic graph (DAG) ownership graph are sorted and serialized according to a preset deterministic sorting rule, including: Get the set of nodes and the set of directed edges corresponding to the current anchoring period; For the node set, the nodes are sorted in ascending order according to the parent event identifier that triggered the corresponding node in the metadata of each node. The node fields corresponding to each node are extracted in the order of the preset node fields. The node attribute fields are then serialized after being arranged in lexicographical order of the attribute keys to obtain the node serialized data. For the set of directed edges, the parent event identifier bound to the starting node of each directed edge is used as the first sorting key, and the parent event identifier bound to the ending node is used as the second sorting key for ascending sorting. When the first sorting key and the second sorting key are the same, the creation time of the directed edge is used as the third sorting key for sorting. The directed edge fields corresponding to each directed edge are extracted sequentially according to the preset directed edge field order, and the relation attribute fields are arranged in lexicographical order of attribute keys and then serialized to obtain the directed edge serialized data. The node serialized data and the directed edge serialized data are sequentially concatenated according to a preset concatenation order to generate the linear byte data block sequence.

8. The method as described in claim 1, characterized in that, A Merkle root hash is generated based on the linear byte data block sequence, and the anchored transaction containing the Merkle root hash is submitted to the blockchain node for notarization and solidification, including: The linear byte data block sequence is divided into multiple ordered data blocks according to a preset data block partitioning rule; Calculate the hash value of each data block separately, and use each hash value as a leaf node of the Merkle tree. Perform paired hash operations on adjacent nodes and recursively layer by layer until a unique Merkle tree root hash is obtained. Obtain the graph version number and snapshot timestamp corresponding to the current graph snapshot, and encapsulate the Merkle root hash, the graph version number, and the snapshot timestamp into the anchor transaction; The anchoring transaction is submitted to the blockchain node for recording, and the graph version number is updated after successful anchoring.

9. The method as described in claim 2, characterized in that, After verifying the validity of each modal data separately, the following steps are also included: When the digital content to be processed contains multiple modal data, and some modal data are invalid but at least one valid modal data exists, the content feature identifier is generated based on the remaining valid modal data, and the modal missing identifier corresponding to the invalid modal data is recorded. When all modal data of the digital content to be processed are invalid, or when the digital content to be processed is a single modal content and its unique modal data is invalid, the generation process of the content feature identifier is terminated, and an error feedback message carrying modal failure information is generated.

10. A digital copyright hierarchical rights confirmation system, used to perform the method as described in any one of claims 1 to 9, characterized in that, The system includes: The feature identifier generation module is used to receive ownership operation requests, extract features and perform cross-modal alignment on the effective modal data of the digital content to be processed, and fuse the obtained modal features to generate the content feature identifier of the digital content to be processed. The pre-detection locking module is used to initiate a preemption request to the distributed lock component with the content feature identifier as the locking object. After acquiring the mutex lock, it reads the status of the ownership node corresponding to the content feature identifier in the directed acyclic graph ownership graph and performs pre-detection verification on the ownership operation request. The event orchestration module is used to read the currently confirmed change sequence number corresponding to the content feature identifier in the directed acyclic graph ownership graph after the pre-inspection verification is passed, generate a target sequence number that is incremented relative to the currently confirmed change sequence number, encapsulate the ownership operation request, the content feature identifier and the target sequence number into a target domain event, and send the target domain event to the consensus network after releasing the mutex lock; The consensus verification module is used to verify the continuity relationship between the target sequence number and the currently confirmed change sequence number through the consensus network, and to perform time-series verification on concurrent target domain events to determine the target domain events that pass the verification. The graph update module is used to obtain the target domain events that have passed the verification, update the nodes and directed edges in the directed acyclic graph ownership graph according to the event type of the target domain events, and update the currently confirmed change sequence number. The graph serialization module is used to sort and serialize the nodes and directed edges in the directed acyclic graph ownership graph according to a preset period and a preset deterministic sorting rule to generate a linear byte data block sequence. The on-chain anchoring module is used to generate a Merkle root hash based on the linear byte data block sequence, and submit the anchoring transaction containing the Merkle root hash to the blockchain node for storage and solidification.

Images