Blockchain-based digital asset trusted archiving method, system and application

Abstract

The application discloses a blockchain-based digital asset trusted record method and system and application, and the method comprises the following steps: when receiving a digital asset trusted record application, obtaining information such as to-be-recorded digital assets, subject information, asset business type, right type, authorized use conditions, income distribution rules and supervision tags, and then generating a digital asset business identifier according to the information; then, multi-modal content features are extracted and similarity comparison is performed to obtain a right conflict identification result; then, a trusted record business file and a business file commitment value are generated, and then a digital right account is constructed; when collecting registration, authorization, transaction, cancellation, cross-platform mutual recognition and other business events, the events are verified by a multi-level oracle; then, the right state is updated and a settlement voucher is generated, and a key abstract is written into a blockchain; finally, a trusted record report is output according to the query permission; and the application improves the credibility of digital asset ownership management, right transfer, cancellation settlement, cross-platform mutual recognition and supervision audit.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology, digital asset ownership verification and cultural tourism digitization, and in particular to a blockchain-based trusted digital asset storage method, system and application. Background Technology

[0002] With the development of the digital economy, blockchain, digital collectibles, digital tickets, digital membership benefits, and data assets, an increasing number of digital contents and rights need to complete ownership registration, authorized transfer, rights verification, revenue settlement, and regulatory verification across multiple entities, platforms, and scenarios. Especially in fields such as cultural tourism, public culture, digital content trading, and data element circulation, digital assets are no longer just static files, but rather carry multiple business attributes such as usage rights, display rights, sublicensing rights, revenue distribution rights, verification rights, and cross-platform mutual recognition rights.

[0003] In existing technologies, trusted notarization of digital assets typically involves writing the digital asset hash, NFT number, transaction hash, or notarization timestamp into the blockchain to prove that a digital asset existed at a specific point in time and has not been tampered with. While this approach can improve data tamper resistance to some extent, it still has significant shortcomings in actual digital asset operation and management scenarios, including: (1) Existing evidence storage solutions mostly focus on the asset ontology hash, lacking management of the business attributes of digital assets. For digital tickets, membership rights, digital collectibles, data assets, and authorized usage certificates, what truly needs to be managed is not only the document ontology, but also the rights holder, rights type, authorization scope, usage conditions, number of rights, validity period, number of transfers, and revenue distribution rules. Simply putting the document hash on the blockchain is insufficient to support the subsequent authorization, revocation, transaction, settlement, and regulatory verification of digital assets.

[0004] (2) Existing methods for confirming ownership and preserving digital assets are insufficient in identifying content variations of digital assets. Digital assets may be trimmed, compressed, transcoded, partially modified, converted in format, rewritten, or authorized for adaptation during dissemination and operation. Traditional hash-based evidence preservation methods can only identify completely identical files and cannot effectively identify digital asset variations with similar content, semantics, or structure. This can easily lead to problems such as duplicate registration, malicious rewriting to evade detection, and difficulty in distinguishing authorized variations.

[0005] (3) Existing solutions lack a status management mechanism around digital equity accounts. Digital assets undergo continuous business events during actual use, such as registration, authorization, display, trading, transfer, leasing, write-off, freezing, revocation, revenue confirmation, and settlement. If the system only records the final transaction results without dynamically updating the total equity amount, currently available equity, authorized equity, written-off equity, settled equity, and frozen equity, it will be difficult to prevent duplicate write-offs, over-authorization, cross-platform reuse, and settlement errors.

[0006] (4) Existing cross-platform digital asset transfer schemes often rely on independent registration and management by each platform. The inconsistent account systems, asset identification, rights status and settlement rules between different platforms can easily lead to problems such as duplicate registration, asynchronous status, inconsistent authorization scope, lack of settlement basis and difficulty in regulatory penetration when digital assets are transferred between multiple platforms.

[0007] (5) Existing blockchain evidence storage systems typically lack multi-source trusted collection and verification mechanisms for business events. Events such as the write-off, display, payment, transfer, and cross-platform use of digital assets mostly occur in off-chain business systems. If event data is submitted by only a single platform, problems such as unreliable data sources, event delays, duplicate submissions, manual tampering, and single points of failure are likely to occur, thereby affecting the accuracy of rights status updates and revenue settlement.

[0008] (6) Existing evidence storage reports typically only display on-chain hashes, transaction numbers, or timestamps, making it difficult to output differentiated reports based on different query subjects. Rights holders, platform operators, users, and regulators have different information priorities. Rights holders focus on authorization and benefits, users on the status of their rights and the results of write-offs, platforms on transactions and settlements, and regulators on events and abnormal risks throughout the entire lifecycle. Existing solutions are insufficient to meet the needs of trusted evidence storage queries and audits across multiple roles, permissions, and dimensions.

[0009] Therefore, there is an urgent need to provide a blockchain-based trusted digital asset notarization method and system that enables unified data processing for digital asset ownership registration, authorization management, rights transfer, write-off control, revenue settlement, cross-platform mutual recognition, and regulatory auditing. This would solve the problems of existing digital asset notarization solutions, such as weak business attributes, difficulty in managing rights status, difficulty in cross-platform mutual recognition, insufficient settlement basis, and / or incomplete regulatory verification. Summary of the Invention

[0010] In view of this, the purpose of this invention is to propose a blockchain-based trusted digital asset notarization method, system and application, which aims to solve the problems of weak business attributes, difficulty in managing rights status, difficulty in cross-platform mutual recognition, insufficient settlement basis and / or incomplete regulatory verification in existing digital asset notarization schemes.

[0011] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows: A blockchain-based trusted notarization method for digital assets, comprising: S1. Receive a digital asset trusted notarization application, obtain the digital asset to be notarized and its corresponding feature information; perform business classification processing on the digital asset to be notarized, and generate a digital asset business identifier to represent the ownership, authorization and / or circulation relationship of the digital asset in a specific business scenario. S2. Multimodal content feature extraction is performed on the digital asset to be certified, a content fingerprint is generated, and the content fingerprint is compared with the index of certified assets to obtain the ownership conflict identification result. S3. Based on the digital asset business identifier, the ownership conflict identification result and / or the feature information, generate a digital asset trusted evidence storage business file, and generate a business file commitment value and a digital rights account according to the digital asset trusted evidence storage business file; S4. Collect the business events of the digital asset to be certified, encapsulate the business events into business event credentials; verify the business event credentials through a multi-level oracle, and generate a business event confirmation credential. S5. Based on the business event confirmation certificate and the preset status flow rules, update the status of the digital rights account, and generate a rights status root based on the updated status; S6. When the business event involves transactions, authorized use, rights write-off, cross-platform use or revenue confirmation, a settlement voucher is generated according to the revenue distribution rules and the updated rights status. S7. Write the digital asset business identifier, business file commitment value, rights status root and / or settlement voucher summary into the blockchain; S8. In response to a trusted evidence storage query request, output a trusted evidence storage report based on the permissions of the querying subject.

[0012] As one possible implementation, further, in step S1 of this solution, the feature information includes submitting entity information, rights holder information, asset business type, rights type, authorized use conditions, revenue distribution rules, regulatory labels, ownership statement information and / or off-chain evidence materials and their indexes.

[0013] As a possible implementation method, further, in step S1 of this solution, the asset business types include content-type digital assets, equity-type digital assets, ticket-type digital assets, data-type digital assets, membership-type digital assets, authorized use-type digital assets, settlement-revenue-type digital assets, and / or cross-platform mutual recognition-type digital assets; the rights types include ownership, usage rights, display rights, sublicensing rights, revenue distribution rights, write-off rights, cross-platform mutual recognition rights, and / or data usage rights.

[0014] As a possible implementation, further, in step S1 of this solution, the digital assets to be certified are classified according to the asset business type and rights type to generate a digital asset business identifier that represents the ownership, authorization and transfer relationship of the digital assets in a specific business scenario.

[0015] The digital asset business identifier is generated based on the digital asset content identifier, asset business type code, rights type code, submitting entity identifier, and registration timestamp, so that the digital asset business identifier is simultaneously associated with the digital asset ontology, business type, rights type, and submitting entity.

[0016] As a possible implementation, further, in step S7 of this scheme, the regulatory label and the index summary of off-chain evidence materials are also written into the blockchain.

[0017] As a possible implementation method, further, in this solution S8, the trusted evidence storage report includes at least one of the following: ownership registration information, authorized use information, rights transfer information, write-off information, settlement information, cross-platform mutual recognition information, and regulatory audit information.

[0018] As a preferred implementation method, step S2 of this solution preferably includes the following: When the digital asset to be certified is a text-based asset, keyword features, semantic embedding features, and paragraph structure features are extracted. When the digital asset to be certified is an image asset, perceptual hash features, local texture features, and main target features are extracted. When the digital asset to be certified is an audio or video asset, audio spectrum features, keyframe features, and temporal action features are extracted. When the digital asset to be certified is a three-dimensional model asset, extract topological structure features, point cloud distribution features, and texture mapping features; When the digital asset to be certified is a composite digital asset, the content features of different modalities are fused to generate a composite content fingerprint.

[0019] As a preferred implementation method, preferably, in step S2 of this solution, the similarity comparison includes content consistency comparison, semantic similarity comparison, and / or variant similarity comparison; When the similarity comparison result exceeds the first threshold and no valid authorization certificate is detected, a suspected duplicate registration identifier is generated; When the similarity comparison result is between the second threshold and the first threshold and a valid authorization certificate is detected, an authorization variant identifier is generated; When the similarity comparison result is lower than the second threshold and the ownership declaration information meets the integrity condition, an independent registration identifier is generated.

[0020] As a preferred implementation method, in step S3 of this solution, a trusted digital asset evidence storage business file is generated based on the digital asset business identifier, rights holder information, submitting entity information, ownership statement information, authorized use conditions, revenue distribution rules, regulatory label, ownership conflict identification results and / or off-chain evidence material index, and a business file commitment value is generated based on the trusted digital asset evidence storage business file.

[0021] As a preferred implementation method, in step S3 of this solution, the digital rights account is used to record the total amount of rights corresponding to the digital asset to be certified, the currently available rights, the authorized rights, the cancelled rights, the settled rights, the frozen rights, the validity period, the number of times it can be transferred, and / or the platform that can be used.

[0022] As a preferred implementation method, in step S3 of this solution, the digital rights account updates the currently available rights in the following manner:

[0023] in, Indicates the first Current available rights following this business event Indicates the currently available equity following the previous business event. This indicates the newly added rights and benefits. This indicates the rights being transferred out. This indicates the write-off or use of rights. This indicates that the rights and interests have been frozen.

[0024] As a preferred implementation method, in step S4 of this solution, business events of the digital asset to be certified are collected during the registration, authorization, display, transaction, transfer, lease, write-off, cross-platform mutual recognition, revenue confirmation, settlement, freezing or revocation process, and the business events are encapsulated into business event certificates.

[0025] As a preferred implementation method, step S4 of this solution preferably includes event source verification, subject authority verification, equity balance verification, authorization scope verification, time window verification, and / or duplicate write-off verification.

[0026] As a preferred implementation method, in step S4 of this scheme, the multi-level oracle includes a physical acquisition layer, a service verification layer, and a consensus confirmation layer.

[0027] The physical acquisition layer is used to collect business event data from the platform business system, scenic area POS system, ticketing system, payment system, user terminal, IoT device, third-party application system and regulatory interface; The business verification layer is used to perform format verification, identity verification, equity balance verification, authorization scope verification, time window verification, and duplicate cancellation verification on the business event data. The consensus confirmation layer is used to confirm the consistency of business event data submitted by multiple data sources, and to generate the business event confirmation certificate after the consistency confirmation is successful.

[0028] As a preferred implementation method, in step S5 of this solution, the status of rights is updated in the following manner:

[0029] in, Indicates the first The status of rights and interests following this business event. Indicates the previous rights status. Indicates the type of business event. This indicates the result of the business rule validation. Indicates regulatory control conditions, This represents the state transition function.

[0030] As a preferred implementation method, in step S6 of this solution, the settlement voucher is generated in the following manner: Calculate the settlement amount based on the equity unit price, equity quantity, settlement adjustment factor, and deduction amount corresponding to the business event:

[0031] in, Indicates the first The settlement amount corresponding to each business event This indicates the unit price of equity or the settlement benchmark value. Indicates the quantity of rights, This represents the settlement adjustment factor. This indicates the amount deducted for refunds, discounts, breach of contract deductions, or platform service fees. Then, the distribution amount for each participating entity is calculated according to the profit distribution rules:

[0032] in, Indicates the first The participating entities in the first Allocation amount in each business event Indicates the first The profit distribution ratio corresponding to each participating entity.

[0033] As a preferred implementation method, the method described in this solution further includes a cross-platform rights recognition step, which includes: A unified mutual recognition identifier is generated based on the digital asset business identifier, business file commitment value, rights status, and currently available rights. After receiving the cross-platform mutual recognition request, the target platform verifies the business file commitment value, rights status, current available rights, settlement status and regulatory control status of the source platform. When the verification is successful, the target platform generates a mutual recognition certificate, and based on the mutual recognition certificate, allows the rights and interests corresponding to the digital asset to be stored to be displayed, used, cancelled, or settled on the target platform.

[0034] Based on the above, this solution also proposes a blockchain-based trusted digital asset storage system, which includes: The business access module is used to receive applications for trusted digital asset notarization, obtain the digital assets to be notarized, submit the subject information, the rights holder information, the asset business type, the rights type, the authorized use conditions, the revenue distribution rules, and the regulatory labels; The information identification module is used to perform business classification processing on the digital assets to be registered and generate digital asset business identifiers. The content verification module is used to extract multimodal content features from the digital asset to be certified, generate a content fingerprint, and compare it with the index of certified assets to obtain the ownership conflict identification result. The document generation module is used to generate digital asset trusted evidence storage business documents and business document commitment values; The account generation module is used to generate digital equity accounts and record the total amount of equity, currently available equity, authorized equity, cancelled equity, settled equity, frozen equity, validity period, number of transfers, and available platforms; The trusted acquisition module is used to collect business events of digital assets during their lifecycle and encapsulate them into business event credentials; A multi-level oracle verification module is used to verify the business event credentials and generate business event confirmation credentials; The rights status transition module is used to update the rights status of the digital rights account according to the business event confirmation certificate and the preset status transition rules, and generate the rights status root. The integrated settlement module is used to generate settlement vouchers based on business events, equity status, and revenue distribution rules. The on-chain evidence storage module is used to write digital asset business identifiers, business file commitment values, equity status roots, settlement voucher summaries, regulatory tags, and off-chain evidence material index summaries into the blockchain; The trusted report generation module is used to output a trusted evidence preservation report based on the permissions of the query subject.

[0035] Based on the above, the blockchain-based trusted evidence storage method for digital assets described in this solution can be applied to digital collections in scenic areas, digital tickets, digital membership rights, public cultural digital resources, digital cultural and creative works, data assets, digital content authorization records, cross-platform mutual recognition of rights and / or settlement or regulatory audit of digital asset revenue.

[0036] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art: This solution simultaneously acquires asset business type, rights type, authorized usage conditions, revenue distribution rules, and regulatory labels during the digital asset registration stage, and generates a digital asset business identifier. This transforms digital assets from being stored solely as file hashes or NFT numbers into business data objects that can be registered, authorized, transferred, rescinded, settled, and regulated, thereby enhancing the adaptability of digital asset storage to actual business management scenarios.

[0037] This solution also performs content verification on text, images, audio and video, 3D models and composite digital assets through multimodal content feature extraction and similarity comparison. It can identify duplicate registrations, authorized variants and suspected ownership conflicts, reduce problems such as malicious rewriting, duplicate authorization and variant content bypassing review, and improve the accuracy of digital asset registration and authorization management.

[0038] This solution further constructs a trusted digital asset evidence storage business archive, which uniformly encapsulates the rights holder, submitting entity, ownership statement, authorized use conditions, revenue distribution rules, regulatory labels, ownership conflict identification results, and off-chain evidence material index, and generates a business archive commitment value which is written to the blockchain. This expands the evidence storage content from a single document existence proof to a complete business relationship proof, which is beneficial for subsequent ownership verification, authorization review, transaction flow, and regulatory audit.

[0039] This solution also records the total amount of rights, currently available rights, authorized rights, written-off rights, settled rights, and frozen rights through digital rights accounts, and dynamically updates the rights status based on business events. This effectively prevents digital assets from being over-authorized, repeatedly written off, repeatedly settled, or continuing to circulate while frozen, thereby improving the accuracy and security of digital asset business management.

[0040] In addition, this solution uses a multi-level oracle to verify the source of off-chain business events, the subject's permissions, the equity balance, the scope of authorization, the time window, and the duplicate write-off. This reduces the risk of a single business system submitting false, delayed, or duplicate events, and makes the digital asset status update and settlement processing more reliable.

[0041] This solution can also unify the processing of business events such as registration, authorization, display, transaction, transfer, lease, write-off, cross-platform mutual recognition, revenue confirmation, settlement, freezing and revocation through the rules of rights status transfer, so that the status changes of digital assets throughout the entire life cycle have continuity and traceability, which facilitates the post-event verification by platform operators, rights holders and regulators.

[0042] In terms of settlement, this solution uses an integrated settlement module to generate settlement vouchers based on business events, rights status, and revenue distribution rules, and writes the settlement voucher summary to the blockchain. This provides verifiable settlement evidence for scenarios such as multi-entity collaborative creation, digital content licensing, scenic area rights verification, cross-platform use, and data asset access, reducing revenue distribution disputes.

[0043] This solution, through a unified mutual recognition identifier and a cross-platform rights mutual recognition mechanism, allows digital asset rights to be displayed, used, cancelled, or settled only after the target platform verifies the source platform's business file commitment value, rights status, currently available rights, settlement status, and regulatory control status. This reduces the risks of duplicate registration, inconsistent status, and repeated use of rights across platforms.

[0044] In terms of information retrieval, this solution generates differentiated and reliable evidence reports based on the query subject's permissions, enabling users, rights holders, platform operators, and regulators to obtain ownership registration information, authorized use information, rights transfer information, write-off information, settlement information, cross-platform mutual recognition information, and regulatory audit information that match their permissions, thereby improving the usability of digital asset evidence results and regulatory penetration capabilities. Attached Figure Description

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

[0046] Figure 1 This is a simplified implementation flowchart of the blockchain-based trusted evidence storage method for digital assets in this solution; Figure 2 This is a simplified diagram showing the connection of the unit modules of the blockchain-based trusted digital asset storage system in this solution. Detailed Implementation

[0047] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] like Figure 1 As shown in the figure, this embodiment proposes a blockchain-based trusted evidence storage method for digital assets, which includes: S1. Receive a digital asset trusted notarization application, obtain the digital asset to be notarized and its corresponding feature information; perform business classification processing on the digital asset to be notarized, and generate a digital asset business identifier to represent the ownership, authorization and / or circulation relationship of the digital asset in a specific business scenario. S2. Multimodal content feature extraction is performed on the digital asset to be certified, a content fingerprint is generated, and the content fingerprint is compared with the index of certified assets to obtain the ownership conflict identification result. S3. Based on the digital asset business identifier, the ownership conflict identification result and / or the feature information, generate a digital asset trusted evidence storage business file, and generate a business file commitment value and a digital rights account according to the digital asset trusted evidence storage business file; S4. Collect the business events of the digital asset to be certified, encapsulate the business events into business event credentials; verify the business event credentials through a multi-level oracle, and generate a business event confirmation credential. S5. Based on the business event confirmation certificate and the preset status flow rules, update the status of the digital rights account, and generate a rights status root based on the updated status; S6. When the business event involves transactions, authorized use, rights write-off, cross-platform use or revenue confirmation, a settlement voucher is generated according to the revenue distribution rules and the updated rights status. S7. Write the digital asset business identifier, business file commitment value, rights status root and / or settlement voucher summary into the blockchain; S8. In response to a trusted evidence storage query request, output a trusted evidence storage report based on the permissions of the querying subject.

[0049] In existing digital asset notarization, only digital files or file hashes are typically accepted. There is a lack of simultaneous collection of the business attributes, rights attributes, revenue attributes, and regulatory attributes of digital assets. This makes it impossible to accurately determine which ownership management, authorized use, rights write-off, revenue settlement, or regulatory audit rules apply to the digital asset.

[0050] As one possible implementation, further, in step S1 of this solution, the feature information includes submitting entity information, rights holder information, asset business type, rights type, authorized use conditions, revenue distribution rules, regulatory labels, ownership statement information and / or off-chain evidence materials and their indexes.

[0051] The asset business types include content-based digital assets, equity-based digital assets, ticket-based digital assets, data-based digital assets, membership-based digital assets, authorized-use digital assets, settlement-revenue-based digital assets, and / or cross-platform mutual recognition digital assets; the rights types include ownership, usage rights, display rights, sublicensing rights, revenue distribution rights, write-off rights, cross-platform mutual recognition rights, and / or data usage rights.

[0052] In step S1 of this solution, information such as the digital asset ontology and subject information, rights information, authorization conditions, revenue rules and regulatory labels are collected in a unified manner at the evidence entry stage, so that subsequent steps can be processed around the "digital asset business management object" rather than a single file.

[0053] As an example of implementation, step S1 of this solution, during data reception and acquisition, may include the following sub-steps: Upon receiving a request for trusted digital asset notarization, the following basic data (feature information) will be obtained: The digital assets to be deposited are denoted as follows: It can be images, text, audio, video, 3D models, digital tickets, digital membership benefits, datasets, digital cultural and creative works, or a combination thereof.

[0054] It also obtains: the submitting entity information. Information of the rights holder Asset Business Types Types of rights Authorization Terms of Use Profit distribution rules Regulatory labels Collection of off-chain evidence materials .

[0055] Among them, submitting entity information Used to identify who filed the evidence preservation application; information of the rights holder. This is used to identify who claims rights to the digital asset, and may further include ownership statement information; asset business type. This is used to indicate whether the digital asset belongs to the category of content, rights, tickets, data, membership, authorized use, settlement-revenue, or cross-platform recognition; Rights type Used to represent the ownership, right of use, right of display, right of sublicense, right of profit distribution, right of write-off, or right of data use of the digital asset.

[0056] By performing format normalization, field integrity checks, subject identity verification, and timestamp marking on the above data, a standardized application data package is formed, defined as follows:

[0057] in, This indicates a normalized request data packet. This indicates a trusted timestamp generated when the system receives the application.

[0058] To facilitate the generation of basic content identifiers for subsequent business identifiers, this solution further calculates digital asset content identifiers, which include:

[0059] in, Indicates the content identifier of digital assets; The hash value representing the ontology of the digital asset to be certified; This refers to the basic metadata of the assets extracted from the application data, including asset name, asset format, asset size, creation time, and source platform. The hash value representing the underlying metadata of the asset; Indicates the received timestamp; This represents the random disturbance factor generated by the system; Indicates field concatenation; This represents a hash function.

[0060] Under the reasoning logic of this formula, if only... As an asset identifier, the same document might be mistakenly identified as the same evidence object in different business scenarios; therefore, the following is introduced: , and This allows the asset content identifier to not only be associated with the asset itself, but also to distinguish between different application batches and different business registration contexts.

[0061] This sub-step outputs: Normalized request data packet Digital asset content identifier .

[0062] Because the same digital asset may have different legal and commercial attributes in different business scenarios. For example, the same scenic spot image can be issued as a digital collectible, used as licensed material, or as part of a membership certificate. If the system manages it solely based on file hashes or asset numbers, it cannot distinguish its ownership, authorization, and transfer relationships in different business scenarios.

[0063] Therefore, step S1 of this solution also binds the digital asset ontology with the asset business type, rights type and subject information to form a digital asset business identifier applicable to business management, rights transfer and settlement verification.

[0064] As a possible implementation, further, in step S1 of this solution, the digital assets to be certified are classified according to the asset business type and rights type to generate a digital asset business identifier that represents the ownership, authorization and transfer relationship of the digital assets in a specific business scenario.

[0065] The digital asset business identifier is generated based on the digital asset content identifier, asset business type code, rights type code, submitting entity identifier, and registration timestamp, so that the digital asset business identifier is simultaneously associated with the digital asset ontology, business type, rights type, and submitting entity.

[0066] As an example of implementation, step S1 of this solution may also include the following sub-steps: The normalized application data packet output from the aforementioned sub-steps Information obtained from it includes: Then, the submitting entity information... and rights holder information Perform identity digest processing to obtain the submitter's identifier. Rights holder identification They are defined as follows:

[0067]

[0068] in, This represents a hash function.

[0069] Subsequently, the system generates a digital asset business identifier:

[0070] in, Indicates the identity of digital asset business; Indicates the content identifier of digital assets; Indicates the asset business type code; Indicates the type of right encoding; Indicates the identifier of the submitting entity; Indicates the identity of the rights holder; Indicates the registration timestamp.

[0071] Under the reasoning logic of this formula, trusted digital asset notarization is not simply proving the existence of a document, but rather proving that the document forms a business management object under a specific business type, specific rights type, and specific subject relationship. Therefore, and A common input hash function can make It also expresses the combined relationship between asset content, business scenario, rights attributes, subject relationship, and registration time.

[0072] For example, the same The corresponding digital images, in Generate a digital collectible when issuing it. ,exist Generate another one when "Licensing Material Use" This avoids confusion between different business relationships.

[0073] The information output by this sub-step includes: , ;in, It will serve as the main index for subsequent content verification, business file generation, equity account generation, and on-chain evidence storage.

[0074] Traditional hash-based evidence storage can only recognize completely identical digital files. Once a digital asset is cropped, compressed, transcoded, partially modified, formatted, filtered, or used for secondary creation, the file hash changes, making it difficult for the system to identify its similarity to existing assets. This can easily lead to problems such as duplicate registration, malicious rewriting to circumvent review, and difficulty in distinguishing between authorized and infringing variants.

[0075] Therefore, step S2 of this solution identifies the similarity and variants of digital assets at the content level before the registration of evidence, providing data basis for ownership conflict judgment, authorization review and business file generation.

[0076] As a preferred implementation method, step S2 of this solution preferably includes the following: When the digital asset to be certified is a text-based asset, keyword features, semantic embedding features, and paragraph structure features are extracted. When the digital asset to be certified is an image asset, perceptual hash features, local texture features, and main target features are extracted. When the digital asset to be certified is an audio or video asset, audio spectrum features, keyframe features, and temporal action features are extracted. When the digital asset to be certified is a three-dimensional model asset, extract topological structure features, point cloud distribution features, and texture mapping features; When the digital asset to be certified is a composite digital asset, the content features of different modalities are fused to generate a composite content fingerprint.

[0077] As a preferred implementation method, preferably, in step S2 of this solution, the similarity comparison includes content consistency comparison, semantic similarity comparison, and / or variant similarity comparison; When the similarity comparison result exceeds the first threshold and no valid authorization certificate is detected, a suspected duplicate registration identifier is generated; When the similarity comparison result is between the second threshold and the first threshold and a valid authorization certificate is detected, an authorization variant identifier is generated; When the similarity comparison result is lower than the second threshold and the ownership declaration information meets the integrity condition, an independent registration identifier is generated.

[0078] As an example of implementation, step S2 of this solution may include the following sub-steps: Based on the digital assets to be deposited in step S1 and digital asset business identifier Then, call the corresponding multimodal feature extraction model.

[0079] like For text-based assets, extract keyword features, semantic embedding features, and paragraph structure features; like For image assets, extract perceptual hash features, local texture features, and main target features; like For audio and video assets, extract audio spectrum features, keyframe features, and temporal action features; like For 3D model assets, extract topological features, point cloud distribution features, and texture mapping features; like For composite assets, different modal characteristics are integrated.

[0080] Let the extracted multimodal feature set be:

[0081] in, Represents the set of multimodal features of the digital asset to be certified; Define Indicates the first The first mode or the first Class features, i.e. Indicates the first The first mode or the first Class features; Indicates the number of features.

[0082] The multimodal feature set is normalized and fused to generate a content fingerprint. The function is defined as follows:

[0083] in, Represents a content fingerprint; This represents a feature normalization function, used to map features of different modalities and scales to a unified representation space; This represents a hash function.

[0084] To determine the relationship between the digital asset and existing assets, this solution can retrieve a set of candidate assets from the existing asset index, defined as follows:

[0085] in, Represents the set of candidate assets with proven documentation, defined as follows: Indicates the first One candidate asset that has been certified. Indicates the number of candidate assets.

[0086] For each candidate asset The three types of similarity are calculated, and their definitions are as follows:

[0087] in, Indicates the digital assets to be registered and the first Overall similarity among candidate assets; Indicates content consistency similarity, used to reflect the degree of consistency between file content or core visual, text, and audio structures; Indicates semantic similarity, used to reflect the degree of closeness in meaning, theme, or object of expression; Indicates variant similarity, used to reflect the degree of similarity of stable features that are retained after cropping, transcoding, rewriting, or secondary creation; , , Let the weighting coefficients satisfy: .

[0088] Based on the reasoning logic of the aforementioned comprehensive similarity formula, a single similarity index is insufficient to cover various digital asset formats. Content consistency similarity is suitable for identifying complete or near-complete copies, semantic similarity is suitable for identifying text rewriting or content with similar themes, and variant similarity is suitable for identifying derivative content that has undergone technical processing. Therefore, a weighted fusion method is used to obtain the comprehensive similarity.

[0089] Take the maximum overall similarity:

[0090] And generate ownership conflict identification results. It satisfies the following conditions: when Furthermore, if no valid authorization certificate is detected, a suspected duplicate registration flag is generated; when Upon detecting a valid authorization certificate, an authorization variant identifier is generated; when Furthermore, an independent registration identifier is generated when the ownership declaration information meets the completeness requirements.

[0091] in, This indicates the threshold for determining duplicate registrations. This indicates the threshold for determining authorized variants, and .

[0092] Step S2 of this solution outputs: Content fingerprint Maximum overall similarity Ownership conflict identification results .

[0093] Existing blockchain evidence storage often only records asset hashes, timestamps, or NFT numbers, lacking a structured organization of rights holders, authorization conditions, revenue rules, regulatory labels, conflict identification results, and evidentiary materials. This results in a lack of unified basis for subsequent authorization reviews, rights transfers, revenue settlements, or regulatory audits.

[0094] Therefore, step S3 of this solution organizes the ownership, authorization, revenue, regulatory relationships, and content verification results of digital assets into a unified business file and forms a commitment value that can be verified on the blockchain.

[0095] As a preferred implementation method, in step S3 of this solution, a trusted digital asset evidence storage business file is generated based on the digital asset business identifier, rights holder information, submitting entity information, ownership statement information, authorized use conditions, revenue distribution rules, regulatory label, ownership conflict identification results and / or off-chain evidence material index, and a business file commitment value is generated based on the trusted digital asset evidence storage business file.

[0096] As a preferred implementation method, in step S3 of this solution, the digital rights account is used to record the total amount of rights corresponding to the digital asset to be certified, the currently available rights, the authorized rights, the cancelled rights, the settled rights, the frozen rights, the validity period, the number of times it can be transferred, and / or the platform that can be used.

[0097] As a preferred implementation method, in step S3 of this solution, the digital rights account updates the currently available rights in the following manner:

[0098] in, Indicates the first Current available rights following this business event Indicates the currently available equity following the previous business event. This indicates the newly added rights and benefits. This indicates the rights being transferred out. This indicates the write-off or use of rights. This indicates that the rights and interests have been frozen.

[0099] As an example of implementation, step S3 of this solution may include the following sub-steps: Based on the output of step S1 , ; and the fingerprint output in step S2 Maximum overall similarity Ownership conflict identification results and from the application data packet in step S1 Obtain from: , , , .

[0100] Based on the above, a trusted digital asset evidence storage business archive is constructed, defined as follows:

[0101] in, This represents a file representing a trusted digital asset storage service. This represents the index of off-chain evidence materials, which is composed of a collection of off-chain evidence materials. It is generated after being encrypted and stored; the remaining parameters follow the definitions above.

[0102] To reduce on-chain storage pressure and ensure the verifiability of file content, this solution does not directly write the entire business file to the blockchain. Instead, it calculates the commitment value of the business file, which is defined as follows:

[0103] in, Indicates the value committed to the business file; This indicates a summary of the authorized usage conditions; This represents a summary of the profit distribution rules; This indicates a summary of the regulatory label.

[0104] Under the reasoning logic of this formula, the business file includes not only business identifiers, subject relationships, content fingerprints, and conflict identification results, but also authorization, revenue, and regulatory rules. By uniformly generating a commitment value from these key fields, subsequent querying parties can verify whether the file has been tampered with without exposing the complete content of the business file.

[0105] Sub-step output: Asset Trusted Evidence Preservation Business File Business file commitment value .

[0106] in, This serves as the business basis for subsequent generation of digital rights accounts, status transitions, and settlement processing; It will be written into the blockchain later.

[0107] Because digital assets undergo various business events such as authorization, trading, transfer, leasing, write-off, freezing, and settlement during subsequent operations, if only static evidence records are maintained without establishing equity accounts, it is impossible to accurately record the total amount of equity, available equity, authorized equity, written-off equity, settled equity, and frozen equity. This can easily lead to problems such as over-authorization, duplicate write-offs, duplicate settlements, or continued circulation after freezing.

[0108] Therefore, step S3 of this solution also generates a dynamically updatable digital rights account based on the trusted evidence storage business archive, so that digital assets are transformed from static evidence storage objects into manageable, revocable, and settleable rights objects.

[0109] As an example of implementation, step S3 of this solution may also include the following sub-steps: Receive the digital asset trusted evidence storage business file output from the aforementioned sub-steps. To obtain asset business types Types of rights Authorization Terms of Use Profit distribution rules and regulatory labels .

[0110] According to asset business type and types of rights Determine the type of digital rights account. For example, if If the asset is a digital ticket, the account type is a redeemable equity account; if For authorized use of digital assets, the account type is an authorized rights account; if If the asset is a digital asset that can be settled and generates revenue, the account type is a revenue settlement rights account; if BT is a cross-platform recognized digital asset, the account type is a mutual recognition rights account.

[0111] When generating a digital equity account, the function is defined as follows:

[0112] in, Indicates the initial digital equity account; Indicates the identity of digital asset business; Indicates the initial total amount of equity; Indicates the initial available rights; Indicates the initially granted rights; This indicates that the rights have been initially written off or used. Indicates the initial settled equity; Indicates the initial freezing of rights; Indicates a validity period limitation; This indicates a limit on the number of times the item can be transferred. This indicates that platform restrictions may apply.

[0113] When initializing an account, the settings are generally as follows:

[0114] Since accounts are typically not authorized, cancelled, or frozen in their initial state, the default behavior is as follows: , ,

[0115] thereby:

[0116] If the asset is already in a pre-authorized, pre-frozen, or pre-cancelled state at the time of registration, the system will initialize it according to the existing records in the business file.

[0117] Subsequent account updates will use the following unified formula:

[0118] in, Indicates the first Current available rights following this business event; Indicates the currently available rights following the previous business event; This indicates the newly added rights and benefits; This indicates the rights being transferred out; This indicates the write-off or use of rights; This indicates that the rights and interests have been frozen.

[0119] Under the reasoning logic of this formula, the current available equity of a digital equity account should be equal to the available equity at the previous moment, plus the newly added equity, minus the amount of equity reduction caused by transfers, usage, and freezing, thereby ensuring that every business event can be reflected in the changes in the account balance.

[0120] Step-by-step output: Initial Digital Equity Account .

[0121] Among them, digital rights accounts This will serve as the balance basis for business event collection and business event verification in subsequent steps.

[0122] In actual use, business events involving digital assets typically occur off-chain, such as ticketing system verification, POS system payments, user terminal displays, third-party platform authorization, and payment system settlements. If these events are not collected and recorded in a unified and structured manner, it becomes impossible to determine the authenticity of changes in asset status, and it also fails to provide a basis for settlement and regulation.

[0123] Therefore, step S4 of this solution converts off-chain business events of digital assets in the processes of registration, authorization, transaction, write-off, settlement and cross-platform mutual recognition into business event credentials in a unified format.

[0124] As a preferred implementation method, in step S4 of this solution, business events of the digital asset to be certified are collected during the registration, authorization, display, transaction, transfer, lease, write-off, cross-platform mutual recognition, revenue confirmation, settlement, freezing or revocation process, and the business events are encapsulated into business event certificates.

[0125] As a preferred implementation method, step S4 of this solution preferably includes event source verification, subject authority verification, equity balance verification, authorization scope verification, time window verification, and / or duplicate write-off verification.

[0126] As a preferred implementation method, in step S4 of this scheme, the multi-level oracle includes a physical acquisition layer, a service verification layer, and a consensus confirmation layer.

[0127] The physical acquisition layer is used to collect business event data from the platform business system, scenic area POS system, ticketing system, payment system, user terminal, IoT device, third-party application system and regulatory interface; The business verification layer is used to perform format verification, identity verification, equity balance verification, authorization scope verification, time window verification, and duplicate cancellation verification on the business event data. The consensus confirmation layer is used to confirm the consistency of business event data submitted by multiple data sources, and to generate the business event confirmation certificate after the consistency confirmation is successful.

[0128] As an example of implementation, step S4 of this solution may include the following sub-steps: Digital equity account generated in step S3 Continuous monitoring and digital asset business identification Related business events.

[0129] Business events include registration events, authorization events, display events, transaction events, transfer events, lease events, write-off events, cross-platform mutual recognition events, revenue confirmation events, settlement events, freeze events, and / or revocation events.

[0130] For the For each business event, the system collects the following information: business identifier. Event Type Operating entity Event object Number of rights involved Event amount or settlement benchmark value Time of the incident Event source system Source system signature .

[0131] This plan will be the first Each business event is encapsulated into a business event credential, which is defined as follows:

[0132] in, Indicates the first Business event voucher.

[0133] To ensure the continuity between business events and the digital rights account in step S3, this solution can require... In Must be with digital rights account In If the results are consistent, the event will not proceed to the subsequent verification process.

[0134] This scheme also generates event sequence numbers, defined as: .

[0135] in, Indicates the first The sequence number of each event; This indicates the sequence number of the previous event. Using the event sequence number, the system can ensure that the order of event processing for the same digital asset business object is traceable.

[0136] Sub-step output: Step 1 The sequence number of the events , No. Each business event is encapsulated into a business event credential. .

[0137] Among them, business event credentials This will serve as the input for subsequent multi-level oracle verification steps.

[0138] Because off-chain business events may be submitted by a single platform system, there are risks such as unreliable sources, duplicate submissions, unauthorized operations, excessive write-offs, exceeding the authorized scope, and time mismatches. If these events are used to update equity status and settlement without verification, it can easily lead to errors in asset status and profit distribution.

[0139] Therefore, step S4 of this solution also performs multi-source trusted verification on off-chain business events to ensure that the business events entering the equity status transfer and settlement process are genuine, compliant and not reused.

[0140] As an example of implementation, step S4 of this solution may also include the following sub-steps: Receive the business event credentials output by the aforementioned sub-steps. Verification is performed through a multi-level oracle.

[0141] A multi-level oracle includes a physical acquisition layer, a business verification layer, and a consensus confirmation layer.

[0142] The physical data acquisition layer collects data from platform business systems, scenic area POS systems, ticketing systems, payment systems, user terminals, IoT devices, third-party application systems, and regulatory interfaces. Corresponding auxiliary event data.

[0143] Business verification layer Six types of verifications are performed, including: event source verification; subject authority verification; equity balance verification; authorization scope verification; time window verification; and duplicate write-off verification.

[0144] Each type of verification outputs a binary result, defined as:

[0145] in, This indicates the result of the event source verification. This indicates the result of the entity's permission verification. This indicates the result of the equity balance verification. This indicates the result of the authorization scope verification. Indicates the time window verification result; This indicates the result of duplicate verification. A value of 1 indicates success, and a value of 0 indicates failure.

[0146] If the business requirement is that all mandatory conditions must be met, then the validity of the event is determined as follows:

[0147] in, Indicates the first The validity result of each business event. When all validation items are 1... ,otherwise .

[0148] Under the reasoning logic of this product formula, for high-risk business events such as equity write-offs and transaction settlements, failure of any mandatory verification will result in the event not being confirmed. Therefore, the logic of satisfying all conditions simultaneously is expressed in product form.

[0149] If certain event types allow for differences in non-mandatory conditions, this solution can employ a weighted scoring method:

[0150] in, Indicates the event verification score; Indicates the first The weight of the item verification, and ; Indicates the first Item verification result. If If so, the event passes the validation; This indicates the event confirmation threshold.

[0151] The consensus confirmation layer performs consistency confirmation on the same business event submitted by multiple data sources and generates a summary of the oracle confirmation results. Summary of Business Rule Validation Results And generate a business event confirmation voucher:

[0152] in, Indicates the first Confirmation voucher for each business event; Represents a business event credential; This represents a summary of the confirmation results from the multi-source oracle. This represents a summary of the business rule validation results; Indicates the event timestamp.

[0153] Sub-step output: Step 1 Confirmation voucher for each business event Summary of Business Rule Validation Results , No. Validity results of individual business events .

[0154] in, and This will serve as the input for the transfer of rights status in subsequent steps.

[0155] Digital assets have different states under different business events. For example, tickets can change from "inactive" to "activated" or "redeemed", and authorized rights can change from "pending authorization" to "authorized" or "revoked". If the system lacks a unified state transition mechanism, different platforms may have inconsistent states for the same asset, leading to duplicate redemptions, unauthorized use, or settlement errors.

[0156] Therefore, step S5 of this scheme updates the digital rights account in a standardized manner based on the confirmed business events, and forms a rights state root that can be verified on the chain.

[0157] As a preferred implementation method, in step S5 of this solution, the status of rights is updated in the following manner:

[0158] in, Indicates the first The status of rights and interests following this business event. Indicates the previous rights status. Indicates the type of business event. This indicates the result of the business rule validation. Indicates regulatory control conditions, This represents the state transition function.

[0159] As an example of implementation, step S5 of this solution may include the following sub-steps: Receive the business event confirmation certificate output from the aforementioned steps. Business rule verification results and the validity results of the event .

[0160] like If not, the rights status update will not be performed, and an exception event record will be generated. Then obtain the current digital rights account. and the previous rights status .

[0161] Perform state updates based on the state transition function:

[0162] in, Indicates the first The status of rights and interests following this business event; Indicates the previous rights status; Indicates the type of business event; This indicates the result of the business rule validation. Indicates regulatory control conditions; This represents the state transition function.

[0163] Under the reasoning logic of this formula, the status of digital rights is not only determined by the event type, but also affected by the business rule verification results and regulatory control conditions. For example, when the event type is "cancellation" and the verification is passed and the regulatory status is normal, the status can be changed to "cancelled"; however, if the regulatory status is frozen, even if the cancellation event itself is in the correct format, it cannot be changed to "cancelled".

[0164] As an example, in this scheme, the state transition function can be defined using a piecewise function, which is expressed as:

[0165] in, Indicates the first The status of rights and interests following this business event; Indicates the first The previous equity status of this business event; Indicates the type of business event; This indicates the result of the business rule validation. Indicates regulatory control conditions; This indicates the control revocation flag. A value of 1 indicates that the revocation was triggered by the regulator or the rights holder, while a value of 0 indicates that there was no revocation instruction and the revocation logic was not triggered. This indicates a freeze control flag. A value of 1 indicates that a freeze has been triggered by regulatory, platform risk control, or rights holder actions. A value of 0 indicates that there is no freeze order and no forced freeze is blocked. Indicates a thawing event; This indicates the previous valid state before entering the frozen state; Indicates that the status has been revoked; This indicates that the device is frozen. Indicates a pending review status; Indicates the validity of the event; This function represents the condition for validating state transitions. This represents the state mapping function under the business type BT, which determines the next state based on the previous state and the event type. When its value is 1, it indicates that the flow path is valid and the flow premise is met. When its value is 0, it indicates that the flow path is invalid and the flow premise is not met.

[0166] Under the definition of the above piecewise function, regulatory revocation and freezing have the highest priority; if there is no regulatory enforcement, the business event is only allowed to enter the next business state if it is verified by the oracle and the state transition path is valid; otherwise, it enters the pending review state.

[0167] In this scheme, the state transition validity judgment function Used to determine the current state under a specific business type (BT). Allow event responses Its specific function can be defined as follows:

[0168] in, This represents the set of legal state transitions corresponding to the business type BT; This represents a state transition pair consisting of the previous state and the current event type.

[0169] When a state transition matches a transition relationship in the set of valid state transitions, then .

[0170] If a business event does not belong to the set of valid transfers, for example, if a "reverted status" triggers a "reverted event" again, then: .

[0171] In this scheme, the state mapping function Used to determine the next state when a transition is valid, its basic definition is:

[0172] Right now, In this solution, a state transition mapping table can be pre-built, listing different digital asset state mappings, and then corresponding relationship mappings can be performed.

[0173] In summary, the state transition function in this scheme is used to implement the following logic: When a regulatory control condition indicates that the control has been revoked, the output will show a revoked status. When the regulatory control condition indicates a freeze and the current event is not an unfreeze event, output "Frozen" status. When a business event fails to pass the multi-level oracle verification, a pending review status is output. When the previous state and the current business event do not belong to the preset legal state transition set, the state to be reviewed is output. When a business event passes the validation and the state transition is valid, the next equity state is output according to the state mapping function corresponding to the business type.

[0174] This ensures that all business events related to the registration, authorization, trading, write-off, settlement, freezing, and revocation of digital assets are executed within a legally valid path, preventing duplicate write-offs, over-authorization, continued circulation after freezing, and invalid settlements.

[0175] Additionally, this solution can update the currently available equity based on the equity account update formula:

[0176] in, Indicates the first Current available rights following this business event; Indicates the currently available rights following the previous business event; This indicates the newly added rights and benefits; This indicates the rights being transferred out; This indicates the write-off or use of rights; This indicates that the rights and interests have been frozen.

[0177] Further generate the root state of equity:

[0178] in, Indicates the first The root of the equity status after the next business event; Indicates the root of the previous equity state; Indicates the identity of digital asset business; Indicates the current status of rights and interests; Indicates currently available rights; This represents a confirmation document for a business event. Indicates the event timestamp.

[0179] Under the reasoning logic of this state root formula, each state update depends on the previous state root, thus forming a chain-like state structure. Any alteration to a historical state or event credential will lead to inconsistencies in subsequent state roots, thereby achieving continuous traceability of changes in equity status.

[0180] This step outputs: Digital Equity Account Rights and interests status Currently available rights Root of rights and interests .

[0181] in, , , This will serve as the input for subsequent steps in the fusion settlement. This will serve as a key field for on-chain evidence storage in subsequent steps.

[0182] Digital assets often involve the distribution of profits among multiple parties after transactions, authorized use, rights write-offs, cross-platform use, or revenue confirmation. If settlement relies solely on internal platform records, issues such as opaque settlement amounts, discrepancies between rights write-offs and revenue confirmations, and disputes over distribution among multiple parties can easily arise.

[0183] Therefore, step S6 of this solution generates a traceable and verifiable digital asset settlement certificate based on the confirmed business events, the updated equity status, and the preset revenue distribution rules.

[0184] As a preferred implementation method, in step S6 of this solution, the settlement voucher is generated in the following manner: Calculate the settlement amount based on the equity unit price, equity quantity, settlement adjustment factor, and deduction amount corresponding to the business event:

[0185] in, Indicates the first The settlement amount corresponding to each business event This indicates the unit price of equity or the settlement benchmark value. Indicates the quantity of rights, This represents the settlement adjustment factor. This indicates the amount deducted for refunds, discounts, breach of contract deductions, or platform service fees. Then, the distribution amount for each participating entity is calculated according to the profit distribution rules:

[0186] in, Indicates the first The participating entities in the first Allocation amount in each business event Indicates the first The profit distribution ratio corresponding to each participating entity.

[0187] As an example of implementation, step S6 of this solution may include the following sub-steps: By determining the type of business event after the aforementioned steps Does it fall under a settlement trigger type? Settlement trigger types include transactions, authorized use, rights verification, cross-platform use, and revenue confirmation.

[0188] If the business event type If the event is not triggered by a settlement event, no settlement voucher will be generated. If it is triggered by a settlement event, the following data will be retrieved: business event voucher. Digital rights account Current status of rights and interests Number of rights Profit distribution rules .

[0189] First calculate the... The settlement amount corresponding to each business event:

[0190] in, Indicates the first The settlement amount corresponding to each business event; Indicates the unit price of equity or the settlement benchmark value; This indicates the number of rights involved in the business event, to avoid conflict with the currently available rights from the aforementioned steps. Confusion, used here Indicates the number of events; This represents the settlement adjustment coefficient, used to reflect discounts, membership levels, channel weight, cross-platform adjustments, or activity coefficients. This indicates the amount deducted for refunds, breach of contract deductions, platform service fee deductions, abnormal compensation, or other deductions.

[0191] Under the reasoning logic of this formula, the settlement amount is usually equal to the unit price of the rights multiplied by the actual number of rights incurred, and then adjusted according to the business scenario, and deducted items such as refunds, discounts or service fees.

[0192] If there are multiple participants, the system calculates the amount allocated to each participant according to the profit distribution ratio:

[0193] in, Indicates the first The participating entities in the first The allocated amount in each business event; Indicates the first The profit distribution ratio of each participating entity.

[0194] To ensure the integrity of the allocation, this plan requires:

[0195] in, This indicates the number of entities participating in the distribution of profits.

[0196] The settlement voucher is then generated as follows:

[0197] in, Indicates the first Settlement vouchers corresponding to each business event.

[0198] Further generate settlement voucher summaries:

[0199] in, This represents a summary of the settlement document, which will be used for on-chain evidence storage in subsequent steps.

[0200] This step outputs: Settlement voucher Summary of Settlement Vouchers .

[0201] Among them, settlement voucher summary Will be related to the root of rights and interests It will be written into the blockchain as well.

[0202] Since the complete business files, off-chain evidence materials, original business event texts and settlement details are large in volume, putting them all on the blockchain would lead to high storage costs, high privacy risks and low processing efficiency; if they are only stored off-chain, it is difficult to guarantee tamper-proof and verifiability.

[0203] Therefore, step S7 of this solution, while taking into account on-chain trustworthiness, off-chain privacy, and storage efficiency, writes the key verification summary of the digital asset trusted storage process into the blockchain.

[0204] Furthermore, in step S7 of this solution, regulatory labels and index summaries of off-chain evidence materials will also be written into the blockchain.

[0205] As an example of implementation, step S7 of this solution may include the following sub-steps: In step S7 of this solution, the received data includes: digital asset business identifier. Business file commitment value ; Equity status root Summary of Settlement Voucher Regulatory labels Index of Off-Chain Evidence .

[0206] The on-chain evidence storage records generated by this scheme include:

[0207] in, Indicates the first On-chain evidence storage records; This indicates a summary of the regulatory label; This represents an index summary of off-chain evidence materials; This indicates the timestamp of this on-chain write.

[0208] This scheme further generates on-chain record hashes:

[0209] in, This represents the hash of a record on the chain.

[0210] When multiple digital assets or multiple business events exist in the same batch, the system can construct batch storage stubs from the hashes of multiple on-chain records:

[0211] in, This indicates that the certificate stubs are stored in batches. to This represents the hashes of multiple on-chain records within the same batch; Indicates the number of records in the batch; This represents the Merkle root calculation function.

[0212] Under the reasoning logic of this formula, the evidence records of multiple business events or multiple digital assets can be compressed into a batch root and put on the chain through the Merkle root, which not only reduces the on-chain storage and transaction costs, but also verifies whether a single record belongs to the batch through the Merkle path.

[0213] The plan will or Write to the blockchain and receive the transaction hash returned by the blockchain. Block height and on-chain timestamps .

[0214] Different entities have varying needs for reliable evidence of digital assets. Users focus on the availability and redemption of rights, rights holders focus on authorization and revenue settlement, platforms focus on transaction flow and abnormal risks, and regulators focus on full lifecycle records and compliance. If the system outputs a uniform report, it will either be insufficiently informative or leak unnecessary data.

[0215] Therefore, step S8 of this solution outputs a differentiated and credible evidence report based on the query subject's permissions, enabling on-chain summaries, off-chain evidence, rights status, settlement records, and regulatory information to be verified and disclosed in a tiered manner.

[0216] As a possible implementation method, further, in this solution S8, the trusted evidence storage report includes at least one of the following: ownership registration information, authorized use information, rights transfer information, write-off information, settlement information, cross-platform mutual recognition information, and regulatory audit information.

[0217] As an example of implementation, step S8 of this solution may include the following sub-steps: The function to receive trusted evidence storage query requests is defined as follows:

[0218] in, Indicates a query request; This indicates the digital asset business identifier being queried; Indicates the identifier of the query subject; Indicates the role of the query subject; Indicate the purpose of the query; Indicates the query time.

[0219] The set of accessible fields is determined based on the query subject's role and regulatory label, and is defined as follows:

[0220] in, Indicates the set of fields that are allowed to be accessed; This represents the permission matching function; Indicates the role of the query subject; Indicate the purpose of the query; Indicates regulatory label.

[0221] If the query subject is a regular user, then This can include the status of rights, available rights, write-off records, and validity period; if the querying entity is a rights holder, then... This can include authorization records, revenue settlement records, and transfer records; if the querying entity is the platform, then... This can include transaction records, write-off records, settlement anomalies, and cross-platform mutual recognition status; if the querying entity is a regulator, then... This can include full lifecycle business events, on-chain evidence records, abnormal risk records, and regulatory audit information.

[0222] Then read from the chain corresponding , , , , and It also retrieves the corresponding business files, business event vouchers, settlement vouchers, and evidence materials from the off-chain storage system.

[0223] To ensure that the report data has not been tampered with, this solution performs the following verification:

[0224] like:

[0225] This indicates that the business file is consistent with the on-chain commitment value.

[0226] The system also recalculates the root of the stake state:

[0227] like:

[0228] This indicates that the stake state chain is consistent with the records on the chain.

[0229] The system also recalculates the settlement voucher summary:

[0230] like:

[0231] This indicates that the settlement document is consistent with the on-chain summary.

[0232] The system generates a report of reliable verification results based on the above verification results:

[0233] in, This indicates the report's credibility verification score; This indicates an indicator function that takes the value 1 if the condition within the parentheses is true, and 0 otherwise. , , Let represent the weight coefficients, and satisfy: .

[0234] Based on the reasoning logic of this formula, a credible evidence report should at least verify the consistency of three key objects: business files, rights status, and settlement vouchers. Therefore, a weighted average is used to form a report credibility verification score.

[0235] Ultimately, this solution is based on the set of access fields. Output a trusted evidence storage report, which includes at least one of the following: ownership registration information; authorized use information; rights transfer information; write-off information; settlement information; cross-platform mutual recognition information; regulatory audit information; on-chain transaction hash; block height; report trust verification score; and abnormal risk warning.

[0236] Output of this step: .

[0237] in, This indicates a final, credible evidence report.

[0238] In addition to the above, as a preferred implementation method, the method described in this solution may further include a cross-platform rights recognition step, which includes: A unified mutual recognition identifier is generated based on the digital asset business identifier, business file commitment value, rights status, and currently available rights. After receiving the cross-platform mutual recognition request, the target platform verifies the business file commitment value, rights status, current available rights, settlement status and regulatory control status of the source platform. When the verification is successful, the target platform generates a mutual recognition certificate, and based on the mutual recognition certificate, allows the rights and interests corresponding to the digital asset to be stored to be displayed, used, cancelled, or settled on the target platform.

[0239] Based on the above, the blockchain-based trusted evidence storage method for digital assets described in this solution can be applied to digital collections in scenic areas, digital tickets, digital membership rights, public cultural digital resources, digital cultural and creative works, data assets, digital content authorization records, cross-platform mutual recognition of rights and / or settlement or regulatory audit of digital asset revenue.

[0240] Combination Figure 2 As shown above, this solution also proposes a blockchain-based trusted digital asset notarization system, which includes: The business access module is used to receive applications for trusted digital asset notarization, obtain the digital assets to be notarized, submit the subject information, the rights holder information, the asset business type, the rights type, the authorized use conditions, the revenue distribution rules, and the regulatory labels; The information identification module is used to perform business classification processing on the digital assets to be registered and generate digital asset business identifiers. The content verification module is used to extract multimodal content features from the digital asset to be certified, generate a content fingerprint, and compare it with the index of certified assets to obtain the ownership conflict identification result. The document generation module is used to generate digital asset trusted evidence storage business documents and business document commitment values; The account generation module is used to generate digital equity accounts and record the total amount of equity, currently available equity, authorized equity, cancelled equity, settled equity, frozen equity, validity period, number of transfers, and available platforms; The trusted acquisition module is used to collect business events of digital assets during their lifecycle and encapsulate them into business event credentials; A multi-level oracle verification module is used to verify the business event credentials and generate business event confirmation credentials; The rights status transition module is used to update the rights status of the digital rights account according to the business event confirmation certificate and the preset status transition rules, and generate the rights status root. The integrated settlement module is used to generate settlement vouchers based on business events, equity status, and revenue distribution rules. The on-chain evidence storage module is used to write digital asset business identifiers, business file commitment values, equity status roots, settlement voucher summaries, regulatory tags, and off-chain evidence material index summaries into the blockchain; The trusted report generation module is used to output a trusted evidence preservation report based on the permissions of the query subject.

[0241] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0242] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0243] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A blockchain-based trusted evidence storage method for digital assets, characterized in that, It includes: S1. Receive a digital asset trusted notarization application and obtain the digital asset to be notarized and its corresponding characteristic information; The digital assets to be certified are classified into business categories to generate digital asset business identifiers that represent the ownership, authorization and / or transfer relationships of digital assets in specific business scenarios. S2. Multimodal content feature extraction is performed on the digital asset to be certified, a content fingerprint is generated, and the content fingerprint is compared with the index of certified assets to obtain the ownership conflict identification result. S3. Based on the digital asset business identifier, the ownership conflict identification result and / or the feature information, generate a digital asset trusted evidence storage business file, and generate a business file commitment value and a digital rights account according to the digital asset trusted evidence storage business file; S4. Collect the business events of the digital asset to be certified, encapsulate the business events into business event credentials; verify the business event credentials through a multi-level oracle, and generate a business event confirmation credential. S5. Based on the business event confirmation certificate and the preset status flow rules, update the status of the digital rights account, and generate a rights status root based on the updated status; S6. When the business event involves transactions, authorized use, rights write-off, cross-platform use or revenue confirmation, a settlement voucher is generated according to the revenue distribution rules and the updated rights status. S7. Write the digital asset business identifier, business file commitment value, rights status root and / or settlement voucher summary into the blockchain; S8. In response to a trusted evidence storage query request, output a trusted evidence storage report based on the permissions of the querying subject.

2. The blockchain-based trusted evidence storage method for digital assets as described in claim 1, characterized in that, In step S1, the feature information includes submitting entity information, rights holder information, asset business type, rights type, authorized use conditions, revenue distribution rules, regulatory labels, ownership statement information and / or off-chain evidence material index; In step S1, the asset business types include content-based digital assets, equity-based digital assets, ticket-based digital assets, data-based digital assets, membership-based digital assets, authorized-use digital assets, settlement-revenue-based digital assets, and / or cross-platform mutually recognized digital assets. The types of rights include ownership, right of use, right of display, right of sublicense, right of profit distribution, right of write-off, right of cross-platform mutual recognition, and / or right of data use; In step S1, the digital assets to be certified are classified according to the asset business type and right type to generate a digital asset business identifier that represents the ownership, authorization and circulation relationship of the digital assets in a specific business scenario. The digital asset business identifier is generated based on the digital asset content identifier, asset business type code, rights type code, submitting entity identifier, and registration timestamp, so that the digital asset business identifier is simultaneously associated with the digital asset ontology, business type, rights type, and submitting entity. In step S7, regulatory labels and index summaries of off-chain evidence materials are also written into the blockchain; In S8, the trusted evidence storage report includes at least one of the following: ownership registration information, authorized use information, rights transfer information, write-off information, settlement information, cross-platform mutual recognition information, and regulatory audit information.

3. The blockchain-based trusted evidence storage method for digital assets as described in claim 2, characterized in that, In step S2, the multimodal content feature extraction includes: When the digital asset to be certified is a text-based asset, keyword features, semantic embedding features, and paragraph structure features are extracted. When the digital asset to be certified is an image asset, perceptual hash features, local texture features, and main target features are extracted. When the digital asset to be certified is an audio or video asset, audio spectrum features, keyframe features, and temporal action features are extracted. When the digital asset to be certified is a three-dimensional model asset, extract topological structure features, point cloud distribution features, and texture mapping features; When the digital asset to be certified is a composite digital asset, the content features of different modalities are fused to generate a composite content fingerprint; In step S2, the similarity comparison includes content consistency comparison, semantic similarity comparison, and / or variant similarity comparison; When the similarity comparison result exceeds the first threshold and no valid authorization certificate is detected, a suspected duplicate registration identifier is generated; When the similarity comparison result is between the second threshold and the first threshold and a valid authorization certificate is detected, an authorization variant identifier is generated; When the similarity comparison result is lower than the second threshold and the ownership declaration information meets the integrity condition, an independent registration identifier is generated.

4. The blockchain-based trusted evidence storage method for digital assets as described in claim 2, characterized in that, In step S3, a digital asset trusted evidence storage business file is generated based on the digital asset business identifier, rights holder information, submitting entity information, ownership statement information, authorized use conditions, revenue distribution rules, regulatory label, ownership conflict identification results and / or off-chain evidence material index, and a business file commitment value is generated based on the digital asset trusted evidence storage business file. In step S3, the digital rights account is used to record the total amount of rights corresponding to the digital asset to be certified, the currently available rights, the authorized rights, the cancelled rights, the settled rights, the frozen rights, the validity period, the number of times it can be transferred, and / or the platform that can be used; In step S3, the digital rights account updates its currently available rights in the following manner: in, Indicates the first Current available rights following this business event Indicates the currently available equity following the previous business event. This indicates the newly added rights and benefits. This indicates the rights being transferred out. This indicates the write-off or use of rights. This indicates that the rights and interests have been frozen.

5. The blockchain-based trusted evidence storage method for digital assets as described in claim 2, characterized in that, In step S4, business events of the digital asset to be certified are collected during the registration, authorization, display, transaction, transfer, lease, write-off, cross-platform mutual recognition, revenue confirmation, settlement, freezing or revocation process, and the business events are encapsulated into business event certificates. In step S4, the verification includes event source verification, subject authority verification, equity balance verification, authorization scope verification, time window verification and / or duplicate write-off verification; In step S4, the multi-level oracle includes a physical acquisition layer, a business verification layer, and a consensus confirmation layer; The physical acquisition layer is used to collect business event data from the platform's business system, scenic area POS system, ticketing system, payment system, user terminals, IoT devices, third-party application systems, and regulatory interfaces. The business verification layer is used to perform format verification, identity verification, equity balance verification, authorization scope verification, time window verification, and duplicate cancellation verification on the business event data. The consensus confirmation layer is used to confirm the consistency of business event data submitted by multiple data sources, and to generate the business event confirmation certificate after the consistency confirmation is successful.

6. The blockchain-based trusted evidence storage method for digital assets as described in claim 5, characterized in that, In step S5, the rights status is updated as follows: in, Indicates the first The status of rights and interests following this business event. Indicates the previous rights status. Indicates the type of business event. This indicates the result of the business rule validation. Indicates regulatory control conditions, This represents the state transition function.

7. The blockchain-based trusted evidence storage method for digital assets as described in claim 2, characterized in that, In step S6, the settlement voucher is generated in the following manner: Calculate the settlement amount based on the equity unit price, equity quantity, settlement adjustment factor, and deduction amount corresponding to the business event: in, Indicates the first The settlement amount corresponding to each business event This indicates the unit price of equity or the settlement benchmark value. Indicates the quantity of rights, This represents the settlement adjustment factor. This indicates the amount deducted for refunds, discounts, breach of contract deductions, or platform service fees. Then, the distribution amount for each participating entity is calculated according to the profit distribution rules: in, Indicates the first The participating entities in the first Allocation amount in each business event Indicates the first The profit distribution ratio corresponding to each participating entity.

8. The blockchain-based trusted evidence storage method for digital assets as described in any one of claims 2 to 7, characterized in that, The method also includes a cross-platform rights recognition step, which includes: A unified mutual recognition identifier is generated based on the digital asset business identifier, business file commitment value, rights status, and currently available rights. After receiving the cross-platform mutual recognition request, the target platform verifies the business file commitment value, rights status, current available rights, settlement status and regulatory control status of the source platform. When the verification is successful, the target platform generates a mutual recognition certificate, and based on the mutual recognition certificate, allows the rights and interests corresponding to the digital asset to be stored to be displayed, used, cancelled, or settled on the target platform.

9. A blockchain-based trusted digital asset storage system, characterized in that, It includes: The business access module is used to receive applications for trusted digital asset notarization, obtain the digital assets to be notarized, submit the subject information, the rights holder information, the asset business type, the rights type, the authorized use conditions, the revenue distribution rules, and the regulatory labels; The information identification module is used to perform business classification processing on the digital assets to be registered and generate digital asset business identifiers. The content verification module is used to extract multimodal content features from the digital asset to be certified, generate a content fingerprint, and compare it with the index of certified assets to obtain the ownership conflict identification result. The document generation module is used to generate digital asset trusted evidence storage business documents and business document commitment values; The account generation module is used to generate digital equity accounts and record the total amount of equity, currently available equity, authorized equity, cancelled equity, settled equity, frozen equity, validity period, number of transfers, and available platforms; The trusted acquisition module is used to collect business events of digital assets during their lifecycle and encapsulate them into business event credentials; A multi-level oracle verification module is used to verify the business event credentials and generate business event confirmation credentials; The rights status transition module is used to update the rights status of the digital rights account according to the business event confirmation certificate and the preset status transition rules, and generate the rights status root. The integrated settlement module is used to generate settlement vouchers based on business events, equity status, and revenue distribution rules. The on-chain evidence storage module is used to write digital asset business identifiers, business file commitment values, equity status roots, settlement voucher summaries, regulatory tags, and off-chain evidence material index summaries into the blockchain; The trusted report generation module is used to output a trusted evidence preservation report based on the permissions of the query subject.

10. The application of the blockchain-based trusted digital asset storage method as described in any one of claims 1 to 8 in the management or auditing of digital collections, digital tickets, digital membership rights, public cultural digital resources, digital cultural and creative works, data assets, digital content authorization records, cross-platform mutual recognition of rights and / or digital asset revenue settlement or supervision.

Images