Digital work copyright-based evidence storage method, equipment and medium

Abstract

The invention discloses a digital work copyright-based evidence storage method and device and a medium. The method comprises the following steps: obtaining a to-be-stored file set of a current creation node and carrying out hash calculation to obtain file entity hash; based on the at least one file entity hash, generating a content hash through a Merkel tree algorithm; determining the content hash, the father node pointer and the timestamp as version metadata; performing hash calculation on the version metadata to generate version snapshot hash, and associating the version snapshot hash with the version metadata to generate a version object; performing credible timestamp authentication on the version object to obtain a version timestamp voucher, and performing associative storage on the version object and the version timestamp voucher to serve as a version node in the version pedigree diagram; and on the basis of all version objects from the initial version node to the final version node in the version pedigree diagram and the version timestamp vouchers associated with the version objects, generating a copyright evidence storage certificate corresponding to the target drama. The right confirmation difficulty can be reduced.

Description

Technical Field

[0001] This application relates to the field of electronic evidence collection technology, and in particular to a method, device, apparatus, medium and product for storing evidence based on the copyright of digital works. Background Technology

[0002] Currently, the digital content industry is developing rapidly. Short dramas, animated series, and other new audiovisual works, with their short production cycles, fast dissemination, and high user engagement, have become important growth points in the online audiovisual field. However, the industrialized and procedural nature of their creation process also presents unprecedented challenges to copyright protection. The value of a drama lies not only in the final product but also in its complete creative chain and multi-version iteration process, from script, storyboard, design drafts, shooting materials to post-production editing. This process generates massive amounts of heterogeneous and highly interconnected electronic data. Effectively securing and preserving this core creative data is crucial for clarifying creative facts, confirming ownership, preventing infringement risks, and providing effective judicial evidence in potential subsequent disputes.

[0003] In related technologies, the means of proving copyright for such digital works include: Traditional copyright registration requires creators to submit application forms, work samples, and identification documents to the copyright administration department. After review, they receive a paper or electronic copyright registration certificate. While this method has high legal authority, the process is cumbersome and time-consuming, making it unsuitable for the rapid iteration and instant release of short dramas and comics. Furthermore, it primarily certifies the static result of a completed work, limiting its scope.

[0004] Third-party online authentication can include services such as trusted timestamps, blockchain notarization, and online notarization. Although these methods are relatively quick, they can only authenticate the existence of isolated, static, single electronic documents. This results in a limited scope of authentication, an inability to effectively guarantee the integrity and relevance of the content, and increases the difficulty of establishing ownership. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, device, apparatus, medium, and product for preserving evidence of digital works copyright, which can solve at least one of the above-mentioned technical problems.

[0006] In a first aspect, embodiments of this application provide a method for evidence preservation based on the copyright of digital works. The method includes: during the creation process of a target drama, in response to an evidence preservation instruction triggered by a user at the current creation node, obtaining a set of files to be preserved related to the target drama under the current creation node, and performing hash calculations on at least one file to be preserved in the set to obtain at least one corresponding file entity hash; based on the at least one file entity hash, generating a content hash corresponding to the current creation node using a Merkle tree algorithm, wherein the content hash is used to verify the integrity of the set of files to be preserved constituting all files to be preserved under the current creation node; and determining the obtained content hash, parent node pointer, and timestamp corresponding to the current creation node as the current creation node's... The version metadata of the creation node is generated, where the parent node pointer points to the previous creation node and its corresponding version object. A hash calculation is performed on the version metadata to generate a version snapshot hash for the current creation node. This hash is then associated with the version metadata to generate a version object for the current creation node. A trusted timestamp authentication is performed on the version object to obtain a version timestamp credential. This credential is then associated with the version object and stored as a version node in the version hierarchy. Based on all version objects from the initial version node to the final version node in the version hierarchy, and the version timestamp credentials associated with each version object, a copyright certificate corresponding to the target drama is generated.

[0007] Secondly, embodiments of this application provide a device for storing digital works copyright. The device includes: a first hash module, used during the creation process of a target drama, in response to a user-triggered storage instruction at the current creation node, to obtain a set of files to be stored related to the target drama under the current creation node, and to perform hash calculations on at least one file in the set to be stored to obtain at least one corresponding file entity hash; a second hash module, used to generate a content hash corresponding to the current creation node based on the at least one file entity hash using a Merkle tree algorithm, wherein the content hash is used to verify the integrity of the set of files to be stored constituting all files to be stored under the current creation node; and a determination module, used to determine the obtained content hash, parent node pointer, and timestamp corresponding to the current creation node as the current... The system comprises the following modules: a version metadata module for the creation node, a parent node pointer pointing to the previous creation node and its corresponding version object; a third hash module for hashing the version metadata to generate a version snapshot hash for the current creation node, and associating the version snapshot hash with the version metadata to generate a version object for the current creation node; an authentication module for performing trusted timestamp authentication on the version object of the current creation node to obtain a version timestamp credential, and storing the version object of the current creation node and the version timestamp credential together as a version node in the version hierarchy; and a generation module for generating a copyright certificate corresponding to the target drama based on all version objects from the initial version node to the final version node in the version hierarchy, and the version timestamp credential associated with each version object.

[0008] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the steps of the method for evidence preservation based on digital work copyright as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the method for evidence preservation based on digital work copyright as described in the first aspect.

[0010] Fifthly, embodiments of this application provide a computer program product stored in a non-volatile storage medium, which, when executed by a processor, implements the steps of the method for evidence preservation based on digital work copyright as described in the first aspect.

[0011] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the steps of the method for evidence preservation based on digital work copyright as described in the first aspect.

[0012] This application provides a method, device, apparatus, medium, and product for storing copyright information of digital works. When responding to a storage instruction, instead of simply hashing a single file or an unordered set, it first obtains the set of all related files to be stored under the current node and generates corresponding file entity hashes. Then, it uses a Merkle tree algorithm to generate a content hash that uniquely represents the complete work content of that node, ensuring that the integrity of all files within that node as a whole can be verified. Subsequently, this content hash, along with a pointer to the parent node pointing to the previous node and a timestamp, is encapsulated into version metadata, and a corresponding version snapshot hash is generated to form a version object, realizing the traceability of ordered links and inheritance relationships between different creation nodes. By independently authenticating each version object with its timestamp and associating all authenticated version nodes in pointer order, the resulting copyright storage certificate logically constitutes a complete version genealogy from the initial creation node to the final version node. Therefore, the certificate provided in this application not only proves the existence of the final film at a certain point in time, but also records all key versions of the work from the initial conception to the final completion and its complete content composition in an immutable manner. It can provide a complete and credible record and authentication of the dynamic and structured creative process and its multi-version evolution process, thereby achieving credible evidence of the entire dynamic creative process, improving the credibility of the copyright certificate, and reducing the difficulty of confirming rights. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0014] Figure 1 This is a flowchart illustrating a method for preserving evidence of digital works copyright provided in an embodiment of this application; Figure 2 This is an exemplary schematic diagram of a digital work copyright-based evidence preservation process provided in an embodiment of this application; Figure 3 This is an exemplary schematic diagram of a digital work copyright-based evidence preservation process provided in another embodiment of this application; Figure 4 This is a schematic diagram of a digital work copyright preservation device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] The principles and spirit of this application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided to make the principles and spirit of this application clearer and more thorough, enabling those skilled in the art to better understand and implement the principles and spirit of this application. The exemplary embodiments provided herein are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments described herein without inventive effort are within the scope of protection of this application.

[0016] In this document, terms such as first, second, and third are used only to distinguish one entity (or operation) from another entity (or operation), and are not intended to require or imply any order or relationship between these entities (or operations).

[0017] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first specifically explains the problems existing in the related technologies: While existing electronic evidence preservation schemes address the "when it exists" question, they preserve isolated, static, single files. For short dramas and animated series, packaging all files for the entire project and calculating a unified hash value means that any minor modification will cause the hash value to change completely, making it impossible to trace version evolution. Preserving each file separately severs the logical connections between files, making it impossible to prove that they collectively constitute a specific version of the script. Essentially, existing online authentication technologies are limited, providing only file-level snapshots and failing to meet the needs of preserving the complete creative genealogy from script to finished product in an industrialized process. They cannot structurally record which file components each version contains, nor can they reflect the inheritance and evolutionary relationships between different creative nodes, such as the final script, the initial cut, and the revised version.

[0018] Based on this, the rights status of intermediate results during the creative process is ambiguous, and the authenticity and completeness of version iterations are difficult to prove. A holistic chain of ownership evidence with temporal sequence and logical connection, spanning the entire creative lifecycle, cannot be formed. Therefore, it is deficient in proving the complete creative process and continuity of ownership, and cannot comprehensively and effectively preserve the copyright of digital works, leading to difficulties in confirming rights in judicial practice. Consequently, the relevant technologies lack a copyright preservation method that can adapt to a procedural creative model and reliably record and authenticate the complete and structured evolutionary history of a script from initial conception to final production.

[0019] Based on this, this application provides a method for preserving evidence of copyright of digital works, which can solve at least one of the above-mentioned technical problems.

[0020] The following description, in conjunction with the accompanying drawings, details the method for preserving evidence based on digital works copyright provided in this application through specific embodiments and application scenarios.

[0021] Figure 1 This is a flowchart illustrating a method for preserving evidence based on the copyright of digital works according to an embodiment of this application. The entity executing this method for preserving evidence based on the copyright of digital works can be an evidence preservation system.

[0022] The following example illustrates the method for preserving evidence based on the copyright of digital works, using a device for preserving evidence based on the copyright of digital works as the implementing entity. It should be noted that the aforementioned implementing entity and application scenario do not constitute a limitation on this application.

[0023] like Figure 1 As shown, the method for preserving evidence based on the copyright of digital works provided in this application embodiment may include steps 110-160.

[0024] Step 110: During the creation process of the target drama, in response to the evidence storage instruction triggered by the user at the current creation node, obtain the set of files to be stored related to the target drama under the current creation node, and perform hash calculation on at least one file to be stored in the set of files to be stored to obtain the corresponding at least one file entity hash. Step 120: Based on at least one file entity hash, generate the content hash corresponding to the current creation node using the Merkle tree algorithm; Step 130: The content hash, parent node pointer, and timestamp corresponding to the current creation node are obtained and determined as the version metadata of the current creation node. Step 140: Perform hash calculation on the version metadata to generate the version snapshot hash of the current creation node, and associate the version snapshot hash of the current creation node with the version metadata to generate the version object of the current creation node. Step 150: Perform trusted timestamp authentication on the version object of the current creation node to obtain a version timestamp certificate, and associate and store the version object of the current creation node with the version timestamp certificate as a version node in the version genealogy graph. Step 160: Based on all version objects from the initial version node to the final version node in the version genealogy diagram, and the version timestamp credentials associated with each version object, generate a copyright certificate corresponding to the target drama.

[0025] The copyright notation method for digital works provided in this application does not simply hash a single file or an unordered set when responding to a notation instruction. Instead, it first obtains the set of all related files to be notified under the current node and generates a corresponding file entity hash. Then, it uses a Merkle tree algorithm to generate a content hash that uniquely represents the complete work content of the node, ensuring that the integrity of all files within the node as a whole can be verified. Subsequently, the content hash, along with a pointer to the parent node pointing to the previous node and a timestamp, is encapsulated into version metadata, and a corresponding version snapshot hash is generated to form a version object. This achieves traceable ordered links and inheritance relationships between different creation nodes. By independently authenticating each version object with its timestamp and associating all authenticated version nodes in pointer order, the resulting copyright notation certificate logically constitutes a complete version genealogy from the initial creation node to the final version node. Therefore, the certificate provided in this application not only proves the existence of the final film at a certain point in time, but also records all key versions of the work from the initial conception to the final completion and its complete content composition in an immutable manner. It can provide a complete and credible record and authentication of the dynamic and structured creative process and its multi-version evolution, thereby enhancing the credibility of the copyright certificate and reducing the difficulty of confirming rights.

[0026] The specific implementation of the above steps will be described in detail below with reference to specific embodiments.

[0027] In step 110, during the creation process of the target drama, in response to the evidence preservation instruction triggered by the user at the current creation node, the set of files to be preserved related to the target drama under the current creation node is obtained, and at least one file to be preserved in the set of files to be preserved is hashed to obtain the corresponding at least one file entity hash.

[0028] In step 110, the target drama, as the object requiring copyright registration, is such as a short drama, comic series, short video series, or other digital content work with multiple version iterations. The creation process can include the entire process of the target drama from conception and creation to the final film, typically including stages such as script, storyboard, original artwork (comic series), filming, rough cut, fine cut, special effects, and final film. The creation node can be a key node in the creation process, such as "script V1.0 finalized," "storyboard completed," "rough cut," "fine cut," "special effects compositing version V2.1," and "final film." The files to be registered can be relevant electronic files from the creation process of the target drama, such as storyboard files, original material files, video editing project files, special effects project files, and final rendered video files, etc. This application does not specifically limit this. The set of files to be registered can include the collection of all files to be registered that constitute this version of the target drama at the current creation node. For example, in the "Rough Cut" node, the collection can include: the final script document, all storyboard files, original shooting video footage, editing project files, and the edited and composited rough cut, etc.

[0029] Specifically, the evidence preservation system can include a client and a server. When a version that a user considers important is completed, the user can manually trigger the evidence preservation operation on the client's evidence preservation interface, generate an evidence preservation instruction for the current creation node, and send it to the server. The server receives the instruction, automatically scans and locates all files associated with the current project (target script), forming a set of files to be preserved. Then, the system traverses the files in the set, performs a cryptographic hash operation on each file to be preserved, obtains a fixed-length string, and generates a series of file entity hashes.

[0030] It should be noted that the collection of documents to be preserved may include discarded documents, such as ideas, drafts, revisions, or cut-out segments that were not used in the final product.

[0031] Therefore, when work 1 and work 2 are highly similar, if the author of work 1 can provide a complete chain of intermediate versions, especially unique discarded files with timestamps earlier than work 2, it can be highly probable that these are two independent creative activities, rather than plagiarism. Furthermore, the rights holder can demonstrate how specific elements in their work went through multiple intermediate versions, from nothing to something, gradually becoming more detailed, such as the evolution of a character's personality or the derivation of a core logic. Such supporting documents effectively demonstrate the creative process of the work, which is key to distinguishing it from plagiarism and copying, and also key to differentiating it from traditional full-chain copyright schemes, further increasing the credibility of copyright certificates.

[0032] In step 120, based on at least one file entity hash, the content hash corresponding to the current creation node is generated using the Merkle tree algorithm.

[0033] In step 120, the content hash is the root node hash "tree_snapshot" generated by the Merkle tree algorithm. It is recursively calculated from the hash values ​​of all lower-level nodes and can characterize the complete content state of the entire collection of files to be certified at the time of certification. Therefore, the content hash can be used as the digital fingerprint of all created content (file collection) under the current creation node to verify the integrity of the collection of files to be certified composed of all files to be certified under the current creation node.

[0034] According to an embodiment of this application, optionally, step 120 above, based on at least one file entity hash, generates the content hash corresponding to the current creation node using the Merkle tree algorithm, which may specifically include: taking at least one file entity hash as a leaf node, merging the hashes of each pair to generate an upper-level intermediate hash, and recursively executing this process until a unique root hash is generated; and using the root hash as the content hash corresponding to the current creation node.

[0035] In this Merkle tree structure, leaf nodes are the lowest-level nodes. Upper-level intermediate hashes are generated during the Merkle tree construction process by merging the hash values ​​of two child nodes (which can be leaf nodes or other intermediate nodes) and then performing a hash calculation; these new hashes exist as higher-level nodes. The root hash is the top-level, unique node hash in the Merkle tree structure, recursively calculated from the hash values ​​of all lower-level nodes, and here serves as the content hash representing the integrity of the entire file collection.

[0036] Specifically, all file entity hashes obtained under the current creation node are used as leaf nodes. If the number of leaf nodes is odd, the value of the last leaf node can be copied to make it even. Then, the leaf nodes are paired up, and each pair of hash values ​​is concatenated. The concatenated result is then hashed to generate the first-level upper-level intermediate hash. Next, these intermediate hash values ​​are paired up again, and the above hash merging process is repeated to generate higher-level intermediate hashes. This process is repeated recursively until only one hash value remains, which is the root hash and is used as the content hash of that node.

[0037] In this embodiment, by using file entity hashes as leaf nodes and recursively merging hashes to generate a root hash, a content hash representing the integrity of the entire collection of files to be certified under the current creation node can be generated efficiently and reliably. This ensures that any modification to the file content will result in a change in the file entity hash, which will ultimately be passed to the root hash. Therefore, the content hash can sensitively reflect the integrity status of the collection, providing a solid foundation for integrity verification in subsequent version management.

[0038] In step 130, the content hash, parent node pointer, and timestamp corresponding to the current creation node are obtained and determined as the version metadata of the current creation node.

[0039] In step 130, the version metadata describes the attributes of the current creation node version and its position in the version history. This metadata may include a content hash "version_id", a parent node pointer "parent_id", and a timestamp "timestamp". The timestamp records the exact time the evidence storage operation occurred, typically obtained from a trusted time source. The parent node pointer points to the previous creation node and its corresponding version object. The parent node pointer can be a snapshot hash of the previous creation node's version. For the first creation node (initial version), its parent node pointer can be null.

[0040] In step 140, a hash calculation is performed on the version metadata to generate the version snapshot hash of the current creation node, and the version snapshot hash of the current creation node is associated with the version metadata to generate the version object of the current creation node.

[0041] In step 140, the content hash, parent node pointer, and timestamp in the version metadata are concatenated according to a preset format to generate a data block to be hashed, and the hash calculation is performed on the data block to be hashed. The result is determined as the version snapshot hash of the current creation node.

[0042] Next, a structured data object is generated, which contains at least the following fields: version snapshot hash field, content hash field, parent node pointer field, and timestamp field. The version snapshot hash, content hash, parent node pointer, and timestamp of the current creation node are filled into the corresponding fields of the structured data object to obtain the version object of the current creation node.

[0043] According to an embodiment of this application, optionally, the aforementioned version metadata may also include a creator identifier. The step 140 above, which performs hash calculation on the version metadata to generate a version snapshot hash of the current creation node, may specifically include: concatenating the content hash, parent node pointer, timestamp, and creator identifier in the version metadata according to a preset format to generate a data block to be hashed; performing hash calculation on the data block to be hashed, and determining the result as the version snapshot hash of the current creation node.

[0044] The creator identifier is information used to uniquely identify the creator of the current creation node, such as a user ID or digital signature. Preset formats include specific string concatenation orders and JSON serialization formats, used for subsequent hash calculations.

[0045] Thus, by incorporating the creator's identifier into the version metadata and participating in the calculation of the version snapshot hash, the generated version object is not only bound to the content and time, but also strongly associated with the creator's identity. Based on this, the successful verification of the version snapshot hash indirectly proves that the version was submitted by a specific creator at the claimed time, effectively preventing internal personnel from misusing accounts to tamper with the content, enhancing the strength of copyright ownership proof, and strengthening the traceability and non-repudiation capabilities of version information.

[0046] As a concrete example, such as Figure 2 As shown, the three-layer hash structure provided in this application includes, from bottom to top: the first layer is the file entity hash, the second layer is the content hash / Merkel root, and the third layer is the version snapshot hash.

[0047] In the first-level file entity hashing, the system calculates the hash value of each independent physical file related to the target script under the current creation node, obtaining the corresponding file entity hash. For example, the hash value Hash_A is calculated for the script file (script.doc), Hash_B and Hash_C are calculated for the video footage files (video clip 1.mp4 and video clip 2.mp4), and Hash_D is calculated for the project file (project file.prproj). These file entity hashes serve as the basis for subsequent calculations, uniquely identifying and verifying the integrity of the corresponding files.

[0048] In the second-level content hashing, the system uses all file entity hashes (Hash_A, Hash_B, Hash_C, Hash_D) from the first level as leaf nodes and aggregates them using a Merkle Tree algorithm. Specifically, leaf nodes are paired up and hashed to generate intermediate hashes, and this process is recursively executed until a unique root hash is generated. This root hash is defined as the content hash (Merkle tree root tree_snapshot) corresponding to the current creation node. This content hash serves as the integrity fingerprint of the entire set of files to be authenticated under the current node, verifying the overall state of all files in the set.

[0049] In the third-level version snapshot hash, the system constructs a version object. This version object, acting as a metadata container, integrates at least the following key information: a pointer to the parent node of the previous version object (parent_id), a timestamp recording the current operation time, author / operator information identifying the operator, and a content hash (tree_snapshot) obtained from the second level. Subsequently, the system performs a hash calculation on all the content of this version object (content hash, parent node pointer, time, and author information). This calculation follows the formula: SnapshotHash = Hash(content hash + parent_id + time + author), and the resulting hash value is the version snapshot hash (snapshot hash version_id). This snapshot hash immutably binds the content data to the version evolution logic (parent-child relationship, time, author), uniquely identifying the specific version object.

[0050] Thus, this application ensures the authenticity of a single file through file entity hashing, ensures the integrity of a file collection under a certain version through content hashing, and finally solidifies the integrity of the file collection and the metadata (inheritance relationship, time, responsible person) of version evolution into a version object that can be independently verified and has legal evidentiary effect through version snapshot hashing.

[0051] According to an embodiment of this application, optionally, the version metadata also includes change description information; the change description information is used to record the changes made by the current creation node to the previous creation node pointed to by its parent node pointer on the set of files to be stored.

[0052] The change description information is used to record, in text or structured data form, a summary or description of the changes that have occurred on the set of files to be stored compared to the previous creation node pointed to by its parent node pointer. For example, it may include which files have been added, deleted, or modified, or a brief description of modifications to the script, shots, etc.

[0053] In this embodiment, introducing change description information enriches the content of version metadata, providing a structured change log for version evolution history. Thus, when viewing the version family tree, not only can the completeness of each version's content be verified, but the differences and iteration logic between versions can also be intuitively understood, facilitating subsequent auditing, collaboration, and communication, and enriching the semantic layer of version management.

[0054] In step 150, the version object of the current creation node is authenticated with a trusted timestamp to obtain a version timestamp certificate, and the version object of the current creation node is associated with and stored with the version timestamp certificate as a version node in the version genealogy graph.

[0055] In step 150, the version timestamp certificate is a cryptographic proof file for the version object returned by a trusted timestamp service; the version genealogy can be composed of multiple version nodes linked together by parent node pointers, used to represent all historical evolution paths of the target play from the initial version to the final version, and each version node is a version object that has been timestamp certified.

[0056] Specifically, the server sends the version object generated under the current creation node to a trusted timestamp service provider, receives the signed version timestamp certificate returned by the provider, and associates and stores the certificate with the version object in a database or blockchain. At this point, an immutable version node with legally recognized time stamp is created and can be connected to historical version nodes through its parent node pointer.

[0057] Step 160 involves generating a copyright certificate corresponding to the target drama based on all version objects from the initial version node to the final version node in the version genealogy diagram, as well as the version timestamp credentials associated with each version object.

[0058] In step 160, the copyright certificate may include a hash chain consisting of version snapshot hashes of each version object in the version genealogy diagram, and version timestamp credentials associated with each version object. Based on this, the copyright certificate can be a final electronic certificate that comprehensively proves the entire creative process of the target drama and the evolutionary relationship of each version. It is not only proof of the final version, but also a verifiable evidence package containing a complete creative genealogy.

[0059] Specifically, once creation is complete and the user triggers final certificate storage, the system traverses the entire version genealogy, starting from the initial version node and following the parent node pointers, collecting version objects and their corresponding version timestamp credentials for all intermediate and final version nodes. The system organizes this data according to chronological order and version relationships, and can selectively perform overall or key information, such as version snapshot hashes and timestamps, re-hash operations, and trusted timestamp authentication, ultimately generating a structured copyright certificate.

[0060] For example, such as Figure 3 As shown, each version node is connected sequentially through the "parent_id" pointer, demonstrating the complete creative evolution path from the initial version node "Version V1: Creative Draft" to the final version node "Version V4: Final Film".

[0061] It should be noted that each user's notarization operation at each creation node triggers a notarization instruction, thereby generating a version node under that creation node. That is, there can be multiple intermediate version nodes between the initial version node and the final version. Each intermediate version node is tightly linked to the preceding and following nodes via cryptographic hashing, and each intermediate version node can serve as a notary point on the creation timeline of the target script. Based on this, any attempt to tamper with a historical version afterwards will invalidate the hash value of the entire subsequent chain. Therefore, this application can ensure the authenticity and integrity of the creation history through multiple intermediate version nodes.

[0062] Optionally, the certificate can be presented in formats such as PDF and JSON, and display the name of the target play, the author, the content hash of each key version, the storage time, and a complete version evolution diagram, providing a verifiable electronic evidence chain for the entire creative process of the play's copyright.

[0063] As a concrete example, short drama Y was pirated, and the plaintiff (using this system) and the defendant faced off in court. The plaintiff presented evidence: a "holographic creation certificate"; the judge scanned the code to verify it: the system interface not only displayed "verification passed," but also popped up a "creation timeline view," which could contain the following information: 2023-01-01: Script V1.0 created (Timestamp A: Timestamp Authentication Time\Hash A); 2023-01-15: Script V2.0 Modification (Timestamp B: Timestamp Authentication Time\Hash B); 2023-02-01: Uploaded 500 original materials (timestamp C: timestamp verification time\hash C); 2023-03-01: Editing Project V1.0 (Timestamp D: Timestamp Authentication Time\Hash D); 2023-03-10: Final cut (timestamp E: timestamp authentication time\hash E).

[0064] During the court hearing, the plaintiff triggered the system to perform real-time verification of the version's evidence data by clicking the "Script V1.0" node in the timeline view, and directly displayed the corresponding original draft file; the timestamp authentication of each node could mutually verify the authenticity of the version iteration and clarify the sequence of each creative stage.

[0065] In contrast, the defendant could only submit the finished MP4 file of the short drama in question, and could not provide any evidence data corresponding to the creation process with timestamps and hash value authentication, nor could it build a traceable chain of the creation process.

[0066] Based on this, the court held that the plaintiff's chain of evidence formed by this system possessed temporal continuity, data immutability, and traceability of version iterations, constituting complete and exclusive proof of creative ownership. Therefore, the plaintiff's claimed copyright rights were established, and the court ruled in favor of the plaintiff.

[0067] According to an embodiment of this application, optionally, step 160 above, based on all version objects from the initial version node to the final version node in the version hierarchy diagram, and the version timestamp credentials associated with each version object, generates a copyright certificate corresponding to the target drama. This step may specifically include: determining the initial version node and the final version node from the version hierarchy diagram, and extracting the content hash from the version object corresponding to the final version node as the final work hash; extracting the version snapshot hash of each version object in the version node sequence from the initial version node to the final version node, and arranging them according to the order of the version node sequence to generate a hash chain; and generating a copyright certificate containing the final work hash, the hash chain, and the version timestamp credentials.

[0068] In this context, the version node sequence refers to an ordered list of nodes in the version hierarchy graph, from the initial version node to the final version node, connected by parent node pointers. The list contains multiple intermediate version nodes between the initial version node and the final version.

[0069] Specifically, the system first locates the initial version node (whose parent node pointer is null) and the final version node in the version hierarchy graph. It extracts the content hash from the version object of the final version node, using it as the final work hash. Then, starting from the initial node, the system traverses the entire sequence of version nodes, extracting the version snapshot hash corresponding to each node in turn, and arranging them in the traversal order to generate a hash linked list. Finally, the final work hash, the hash linked list, and the version timestamp credentials associated with each version node retrieved from storage are encapsulated together, such as in a JSON or XML file of a specific format, or by generating a PDF report, to obtain the final copyright certificate.

[0070] For example, continue to refer to Figure 3 The complete creative process of the target drama was solidified into a version genealogy chart containing four version nodes.

[0071] Initial version node (version V1): Its version name is "Creative Draft". The version object corresponding to this node contains its unique snapshot hash V1, and a content hash representing the overall fingerprint of the initial script document under this version: Script V1. The parent node pointer of this node is null (parent: null), indicating that it is the starting point of the entire creation process.

[0072] Intermediate version node (Version V2): Its version name is "Final Script". The version object corresponding to this node contains the snapshot hash V2 and the updated content hash, which is obtained based on Script V2. Its parent node pointer explicitly points to the snapshot hash V1, establishing a derivation relationship from V2 to V1, proving that Version V2 was modified based on the creative draft of Version V1.

[0073] Intermediate Version Node (Version V3): Its version name is "Shot Footage". The version object corresponding to this node contains a snapshot hash V3 and a content hash representing the overall fingerprint of the file set under this version (such as the final script and the original video footage package obtained during filming). This content hash is obtained based on script V2 and the footage package. Its parent node pointer points to snapshot hash V2, indicating that the shot footage was created based on the final script version.

[0074] Final Version Node (Version V4): Its version name is "Final Footage". The version object corresponding to this node contains the snapshot hash V4 and a content hash representing the overall fingerprint of all files in the final delivered complete series project. This content hash is derived from the complete project. Its parent node pointer points to the snapshot hash V3, indicating that the final footage is edited and rendered based on the footage version.

[0075] Based on the aforementioned version genealogy diagram, the system executes the certificate generation steps as follows: First, from the version object corresponding to the final version node (version V4), the "Content Hash: Complete Project" is extracted as the final work hash for sovereignty claims. Next, the system extracts the version snapshot hashes (i.e., snapshot hash V1, snapshot hash V2, snapshot hash V3, and snapshot hash V4) of each version object in the version node sequence from version V1 to version V4, and arranges them in their evolutionary order to generate a complete hash chain, serving as evidence of the work's creation process. Finally, the system encapsulates the "Sovereignty Claim: Final Work Hash," the aforementioned hash chain, and the version timestamp credentials associated with each version object to generate the holographic genealogy certificate shown on the left side of the diagram.

[0076] This embodiment illustrates how to interconnect multiple key versions (including intermediate revisions) generated during the creation of a play using cryptographic hashes and pointers to construct an immutable creative genealogy, ultimately generating a holographic genealogy certificate that not only declares the final ownership of the work but also fully demonstrates the creative evolution process. All version nodes in the diagram, along with their contained hash and pointer information, form the core data foundation for the legal evidentiary value of this certificate.

[0077] In this embodiment, by extracting the final work hash and constructing a hash chain, and encapsulating it together with the version timestamp certificate, the generated copyright certificate not only provides proof of the integrity of the final work but also contains verifiable clues to the entire creation history. Thus, after obtaining this certificate, any party can verify the integrity of the final work through the final work hash and, through the hash chain and version timestamp certificate, effectively verify the authenticity and continuity of the entire version evolution process.

[0078] Optionally, according to an embodiment of this application, the above-mentioned generation of a copyright certificate containing a final work hash, a hash chain, and timestamp credentials for each version may include: generating a lightweight topological digest representing the node connection relationship of the version genealogy based on the version snapshot hash and parent node pointer in each version object; and encapsulating the final work hash, hash chain, timestamp credentials for each version, and lightweight topological digest to generate a copyright certificate.

[0079] Specifically, the lightweight topology digest is a data structure used to efficiently represent the node connections in the version genealogy graph. It can be a set of mappings between each version snapshot hash and its corresponding parent node pointer, thus describing the parent-child link structure of the versions. When generating a copyright certificate, the system traverses all version nodes, extracts the version snapshot hash of each node and its parent node pointer (pointing to the version snapshot hash of the parent node), and generates a list of pairing relationships between child hashes and parent hashes. This list can be the lightweight topology digest. Subsequently, the system encapsulates the final work hash, hash list, timestamp credentials for each version, and this lightweight topology digest together into the copyright certificate.

[0080] In the embodiments of this application, the lightweight topology digest records the correspondence between the version snapshot hash and the parent node pointer in a compact form. The introduction of the lightweight topology digest into the copyright certificate enables the verifier to quickly verify the logical continuity of the version node sequence without accessing complete external data, which simplifies the verification process in offline or resource-constrained environments and improves verification efficiency and convenience.

[0081] According to embodiments of this application, optionally, after generating the copyright certificate as described above, the method may further include: in response to a visual verification request for the copyright certificate, parsing and loading a lightweight topology digest; generating and displaying a visual graphical interface for a version genealogy based on the lightweight topology digest; in response to interactive operations on graphical elements representing target version nodes on the visual graphical interface, obtaining and displaying the version object corresponding to the target version node, and obtaining and displaying a preview of the content of at least a portion of the files to be certified from an external system based on the version snapshot hash corresponding to the target version node.

[0082] Specifically, when a user initiates a visual verification request, such as opening a certificate viewer and clicking the verification button, the system parses the lightweight topology digest in the certificate and uses a graphics library to draw a visual graphical interface of the version hierarchy on the screen based on node and link relationship data. When the user clicks on the graphical element representing a specific version node (target version node) on the interface, the system first retrieves and displays the basic information of its version object from the local certificate cache or parsing results based on the version snapshot hash corresponding to that node. Simultaneously, it can further use this hash value as an index to request some or all of the files to be stored associated with that version from an external content addressing storage system and generate a content preview to display to the user.

[0083] In this embodiment, a visual graphical interface is generated by parsing a lightweight topology digest, and an interactive preview of the content of a specific version node is provided, thus enabling intuitive verification of copyright certificates. In this way, users can not only understand complex version evolution relationships through a graphical interface, but also directly view a preview of the actual file content stored under a specific version, establishing an intuitive connection between the abstract hash value and the specific creative content, effectively enhancing the user experience and credibility of the verification process.

[0084] According to embodiments of this application, optionally, after generating the copyright certificate, the method further includes verifying the copyright certificate. The verification process may include: parsing the copyright certificate to obtain a lightweight topology digest, a hash chain, and timestamp credentials for each version; verifying the logical continuity of the version node sequence represented by the hash chain based on the correspondence between the snapshot hashes of each version in the lightweight topology digest and the parent node pointers; and verifying the temporal continuity of the version node sequence based on the timestamp credentials for each version. By verifying the logical continuity of the hash chain and the temporal continuity of the version timestamp credentials, the rationality of the creation history claimed by the copyright certificate in terms of logical relationships and timeline is systematically verified. This effectively prevents the version history from being tampered with and ensures the credibility of the entire certificate chain.

[0085] Specifically, logical continuity can be confirmed by verifying whether the order of version nodes recorded in the hash chain is consistent with the parent-child link relationship between nodes described in the lightweight topology digest, i.e., whether the version evolution path conforms to the logical inheritance relationship; and temporal continuity can be confirmed by verifying whether the timestamps corresponding to each version node in the version node sequence, which are proved by the version timestamp certificate, maintain a strictly increasing order from front to back, i.e., whether the version evolution is reasonable in time.

[0086] Logical continuity verification: Based on the mapping relationship between the version snapshot hashes recorded in the lightweight topology digest and their corresponding parent node pointers, the system verifies whether the sequence of version nodes represented by the hash chain constitutes a continuous and consistent link path. This verification ensures that the version history has not been tampered with, such as by inserting fake versions that do not belong to the lineage or disrupting the original version inheritance relationship.

[0087] Time sequence continuity verification: The system sequentially reads the version timestamp credentials corresponding to each version node in the hash chain and parses out the authoritative timestamp. It verifies whether the timestamp of each version in the chain is later than the timestamp of its preceding version. If the timestamp sequence is strictly increasing, it proves that the time sequence is continuous.

[0088] In this embodiment, by systematically verifying the continuity and consistency of the creative history represented by the copyright certificate in terms of logical relationships and timeline, malicious modifications to the version history order or timeline, such as inserting fake versions or disrupting the version order, can be effectively identified. This ensures that the creative history recorded in the version genealogy is authentic, reliable, and tamper-proof. This verification mechanism strengthens the credibility of the copyright certificate as evidence, effectively prevents the version history from being tampered with, and ensures the credibility of the entire evidence preservation chain.

[0089] According to an embodiment of this application, optionally, the verification process further includes: in response to a verification request for a specific version node in the version node sequence, obtaining the version snapshot hash corresponding to the specific version node from the copyright certificate; based on the version snapshot hash, obtaining the corresponding version object and version timestamp credential from an external content addressing storage system; verifying the consistency between the obtained version object and the parent node relationship recorded in the lightweight topology digest, and verifying the consistency between the obtained version timestamp credential and the corresponding credential sealed in the copyright certificate.

[0090] Specifically, when a verifier wishes to perform more in-depth verification of a specific version node in the version node sequence, the system retrieves the version snapshot hash corresponding to that node from the copyright certificate. Then, using this hash value as the key, it sends a request to an external content-addressed storage system to obtain the complete version object data stored there, along with its associated version timestamp credential. Next, the system compares the parent node pointer information contained in the retrieved external version object with the parent node information of that node recorded in the lightweight topology digest of the certificate to verify consistency. Simultaneously, it also compares the version timestamp credential obtained from the external system with the corresponding credential sealed in the certificate to ensure consistency.

[0091] In this embodiment, a distributed and enhanced verification mechanism is provided by using version snapshot hashes as indexes to retrieve complete version objects and version timestamp credentials from an external content-addressed storage system for independent verification. This allows verifiers to directly access external trusted data without relying on abbreviated information encapsulated in certificates, improving the reliability and flexibility of verification and making it suitable for high-assurance audit scenarios.

[0092] According to an embodiment of this application, optionally, the above-mentioned verification of the logical continuity of the version node sequence represented by the hash chain based on the correspondence between each version snapshot hash and the parent node pointer in the lightweight topology digest may specifically include: selecting two adjacent version snapshot hashes sequentially from the hash chain to obtain the first version snapshot hash and the second version snapshot hash; searching for the record corresponding to the first version snapshot hash in the lightweight topology digest; and verifying whether the parent node pointer contained in the record points to the second version snapshot hash.

[0093] Specifically, a pair of adjacent version snapshot hashes, such as Hash_A and Hash_B, are retrieved sequentially from the hash chain, with Hash_A preceding Hash_B in the chain. The record corresponding to Hash_B is searched in the lightweight topology digest, and it is verified whether the parent node pointer recorded in that record points to Hash_A. If all adjacent node pairs satisfy this condition, it proves that the sequence of the hash chain is consistent with the parent-child linking relationship of the genealogy, demonstrating logical continuity.

[0094] In this embodiment of the application, by sequentially checking the parent-child pointer relationship of adjacent hash values ​​in the hash chain, the linking relationship of the version node sequence can be confirmed efficiently and accurately. This verification process is simple and effective, and can enhance the reliability and efficiency of the copyright certificate verification process.

[0095] Corresponding to the method embodiments of this application, this application also provides a device for storing evidence based on the copyright of digital works.

[0096] Figure 4 This is a schematic diagram of a digital work copyright preservation device provided in an embodiment of this application. Figure 4 As shown, the digital work copyright-based evidence storage device 400 may include: a first hash module 410, a second hash module 420, a determination module 430, a third hash module 440, an authentication module 450, and a generation module 460.

[0097] The system comprises the following modules: The first hash module, during the creation of the target drama, responds to a user's authentication command triggered at the current creation node, retrieves a set of files related to the target drama to be authenticated under the current creation node, and performs hash calculations on at least one file in the set to obtain at least one corresponding file entity hash. The second hash module, based on at least one file entity hash, generates a content hash corresponding to the current creation node using a Merkle tree algorithm. This content hash is used to verify the integrity of the set of files to be authenticated, which comprises all files under the current creation node. The determination module uses the obtained content hash, parent node pointer, and timestamp corresponding to the current creation node as the version metadata of the current creation node. The point pointer is used to point to the previous creation node and its corresponding version object; the third hash module is used to perform hash calculation on the version metadata, generate the version snapshot hash of the current creation node, and associate the version snapshot hash of the current creation node with the version metadata to generate the version object of the current creation node; the authentication module is used to perform trusted timestamp authentication on the version object of the current creation node, obtain the version timestamp certificate, and associate and store the version object of the current creation node with the version timestamp certificate as a version node in the version genealogy; the generation module is used to generate a copyright certificate corresponding to the target drama based on all version objects from the initial version node to the final version node in the version genealogy, and the version timestamp certificates associated with each version object.

[0098] The digital work copyright preservation device provided in this application does not perform simple hashing on a single file or an unordered set when responding to a preservation command. Instead, it first obtains the set of all related files to be preserved under the current node and generates corresponding file entity hashes. Then, it generates a content hash that uniquely represents the complete work content of the node using a Merkle tree algorithm, ensuring that the integrity of all files within the node as a whole can be verified. Subsequently, the content hash, along with a pointer to the parent node pointing to the previous node and a timestamp, is encapsulated into version metadata, and a corresponding version snapshot hash is generated to form a version object, realizing the traceability of ordered links and inheritance relationships between different creation nodes. By performing independent timestamp authentication on each version object and associating all authenticated version nodes in pointer order, the final generated copyright preservation certificate logically constitutes a complete version genealogy from the initial creation node to the final version node. Therefore, the certificate provided in this application not only proves the existence of the final film at a certain point in time, but also records all key versions of the work from the initial conception to the final completion and its complete content composition in an immutable manner. It can provide a complete and credible record and authentication of the dynamic and structured creative process and its multi-version evolution process, thereby achieving credible evidence of the entire dynamic creative process, improving the credibility of the copyright certificate, and reducing the difficulty of confirming rights.

[0099] In some embodiments, the second hash module is specifically used to: take at least one file entity hash as a leaf node, merge the hashes of each pair to generate an upper-level intermediate hash, and recursively execute this process until a unique root hash is generated; and use the root hash as the content hash corresponding to the current author node.

[0100] In some embodiments, the third hash module is specifically used to: concatenate the content hash, parent node pointer, timestamp, and creator identifier in the version metadata according to a preset format to generate a data block to be hashed; perform hash calculation on the data block to be hashed, and determine the result as the version snapshot hash of the current creator node.

[0101] In some embodiments, the version metadata also includes change description information; the change description information is used to record the changes made by the current author node to the previous author node pointed to by its parent node pointer on the set of files to be stored.

[0102] In some embodiments, the generation module includes: an extraction unit, configured to determine the initial version node and the final version node from the version genealogy diagram, and extract the content hash from the version object corresponding to the final version node as the final work hash; an extraction unit, configured to extract the version snapshot hash of each version object in the version node sequence from the initial version node to the final version node, and arrange them in the order of the version node sequence to generate a hash chain; and a generation unit, configured to generate a copyright certificate containing the final work hash, the hash chain, and the timestamp credentials of each version.

[0103] In some embodiments, the generation unit is specifically used to: generate a lightweight topological summary representing the node connection relationship of the version genealogy based on the version snapshot hash and parent node pointer in each version object; and encapsulate the final work hash, hash chain, timestamp credentials of each version, and lightweight topological summary to generate a copyright certificate.

[0104] In some embodiments, the system further includes: a loading module, configured to parse and load a lightweight topology digest in response to a visual verification request for the copyright certificate after it has been generated; a generation module, configured to generate and display a visual graphical interface for a version genealogy diagram based on the lightweight topology digest; and a display module, configured to obtain and display the version object corresponding to the target version node in response to interactive operations on the graphical elements representing the target version node on the visual graphical interface, and to obtain and display a preview of the content of at least a portion of the files to be stored from an external system based on the version snapshot hash corresponding to the target version node.

[0105] In some embodiments, a verification module is further included, which is used to verify the copyright certificate after it is generated. The verification process includes: parsing the copyright certificate to obtain a lightweight topology digest, a hash chain, and timestamp credentials for each version; verifying the logical continuity of the version node sequence represented by the hash chain based on the correspondence between the snapshot hashes of each version in the lightweight topology digest and the parent node pointers; and verifying the temporal continuity of the version node sequence based on the timestamp credentials for each version.

[0106] In some embodiments, the verification process further includes: in response to a verification request for a specific version node in the version node sequence, obtaining the version snapshot hash corresponding to the specific version node from the copyright certificate; based on the version snapshot hash, obtaining the corresponding version object and version timestamp credential from an external content addressing storage system; verifying the consistency between the obtained version object and the parent node relationship recorded in the lightweight topology digest, and verifying the consistency between the obtained version timestamp credential and the corresponding credential sealed in the copyright certificate.

[0107] In some embodiments, the verification module is specifically used to: select two adjacent version snapshot hashes sequentially from the hash chain to obtain the first version snapshot hash and the second version snapshot hash; search for the record corresponding to the first version snapshot hash in the lightweight topology digest; and verify whether the parent node pointer contained in the record points to the second version snapshot hash.

[0108] The digital work copyright-based evidence storage device provided in this application embodiment can achieve... Figure 1-3 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0109] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0110] like Figure 5 As shown, the electronic device 500 includes a memory 501, a processor 502, and a computer program stored in the memory 501 and executable on the processor 502.

[0111] In one example, the processor 502 described above may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0112] Memory 501 may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method for proving copyright of digital works according to the embodiments of the first aspect of this application.

[0113] The processor 502 runs a computer program corresponding to the executable program code stored in the memory 501 to implement the digital work copyright-based evidence preservation method in the first aspect embodiment above.

[0114] In some examples, the electronic device 500 may also include a communication interface 503 and a bus 510. For example, Figure 5 As shown, the memory 501, processor 502, and communication interface 503 are connected through bus 510 and complete communication with each other.

[0115] The communication interface 503 is mainly used to enable communication between various modules, systems, units, and / or devices in the embodiments of this application. Input devices and / or output devices can also be connected through the communication interface 503.

[0116] Bus 510 includes hardware, software, or both, that couples components of electronic device 500 together. For example, and not limitingly, bus 510 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0117] The electronic device provided in this application embodiment is capable of achieving Figure 1-3 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0118] In conjunction with the digital work copyright-based evidence preservation methods described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any step in the above method embodiments.

[0119] In conjunction with the digital work copyright-based evidence preservation methods described in the above embodiments, this application embodiment can provide a computer program product for implementation. This (computer) program product is stored in a non-volatile storage medium, and when executed by at least one processor, it implements any of the steps in the above method embodiments.

[0120] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0121] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0122] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0123] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0124] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or systems. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0125] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, systems (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing system to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing system, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0126] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for evidence preservation based on the copyright of digital works, characterized in that, The method includes: During the creation process of the target drama, in response to the evidence storage instruction triggered by the user at the current creation node, the set of files to be stored related to the target drama under the current creation node is obtained, and at least one file to be stored in the set of files to be stored is hashed to obtain at least one corresponding file entity hash. Based on the at least one file entity hash, a content hash corresponding to the current creation node is generated using the Merkle tree algorithm, wherein the content hash is used to verify the integrity of the set of files to be certified, which consists of all files to be certified under the current creation node; The obtained content hash, parent node pointer, and timestamp corresponding to the current creation node are determined as the version metadata of the current creation node, wherein the parent node pointer is used to point to the previous creation node and its corresponding version object; The version metadata is hashed to generate the version snapshot hash of the current creation node, and the version snapshot hash of the current creation node is associated with the version metadata to generate the version object of the current creation node. The version object of the current creation node is authenticated with a trusted timestamp to obtain a version timestamp certificate. The version object of the current creation node is then associated with and stored with the version timestamp certificate as a version node in the version genealogy graph. Based on all version objects from the initial version node to the final version node in the version genealogy diagram, and the version timestamp credentials associated with each version object, a copyright certificate corresponding to the target drama is generated.

2. The method according to claim 1, characterized in that, Based on the hash of at least one file entity, a content hash corresponding to the current creation node is generated using the Merkle tree algorithm, including: The hash of at least one file entity is used as a leaf node, and the hashes of each pair are merged to generate an intermediate hash of the next higher level. This process is then recursively executed until a unique root hash is generated. The root hash is used as the content hash corresponding to the current creation node.

3. The method according to claim 1, characterized in that, The version metadata also includes a creator identifier. A hash calculation is performed on the version metadata to generate a version snapshot hash for the current creation node, including: The content hash, parent node pointer, timestamp, and creator identifier in the version metadata are concatenated according to a preset format to generate a data block to be hashed; The data block to be hashed is hashed, and the result is determined as the version snapshot hash of the current authoring node.

4. The method according to claim 1 or 3, characterized in that, The version metadata also includes change description information; The change description information is used to record the changes made by the current creation node to the previous creation node pointed to by its parent node pointer in the set of files to be stored.

5. The method according to claim 1, characterized in that, Based on all version objects from the initial version node to the final version node in the version hierarchy diagram, and the version timestamp credentials associated with each version object, a copyright certificate corresponding to the target drama is generated, including: The initial version node and the final version node are determined from the version genealogy diagram, and the content hash is extracted from the version object corresponding to the final version node as the final work hash. Extract the version snapshot hash of each version object in the version node sequence from the initial version node to the final version node, and arrange them in the order of the version node sequence to generate a hash chain list; Generate the copyright certificate containing the final work hash, the hash chain, and timestamp credentials for each version.

6. The method according to claim 5, characterized in that, Generate the copyright certificate containing the final work hash, the hash chain, and timestamp credentials for each version, including: Based on the version snapshot hash and parent node pointer in each version object, a lightweight topology summary representing the node connection relationship of the version genealogy graph is generated. The final work hash, the hash chain, the timestamp credentials of each version, and the lightweight topology digest are encapsulated to generate the copyright certificate.

7. The method according to claim 6, characterized in that, After generating the copyright certificate, the process also includes: In response to a visual verification request for the copyright certificate, the lightweight topology digest is parsed and loaded. Based on the lightweight topology summary, a visual graphical interface is generated and displayed to show the version genealogy diagram; In response to interactive operations on the graphical elements representing the target version node on the visual graphical interface, the version object corresponding to the target version node is obtained and displayed, and the content preview of at least a portion of the associated files to be stored is obtained from the external system based on the version snapshot hash corresponding to the target version node.

8. The method according to claim 6, characterized in that, After generating the copyright certificate, the process also includes verifying the copyright certificate, wherein the verification process includes: Parse the copyright certificate to obtain a lightweight topology digest, hash chain, and timestamp credentials for each version; Based on the correspondence between the version snapshot hashes and parent node pointers in the lightweight topology digest, the logical continuity of the version node sequence represented by the hash chain is verified. Based on the timestamp credentials of each version, verify the temporal continuity of the version node sequence.

9. The method according to claim 8, characterized in that, The verification process also includes: In response to a verification request for a specific version node in the version node sequence, the version snapshot hash corresponding to the specific version node is obtained from the copyright certificate. Based on the version snapshot hash, obtain the corresponding version object and version timestamp credential from the external content-addressed storage system; Verify the consistency between the obtained version object and the parent node relationship recorded in the lightweight topology digest, and verify the consistency between the obtained version timestamp certificate and the corresponding certificate sealed in the copyright certificate.

10. The method according to claim 9, characterized in that, Based on the correspondence between the version snapshot hashes and parent node pointers in the lightweight topology digest, the logical continuity of the version node sequence represented by the hash chain is verified, including: By sequentially selecting two adjacent version snapshot hashes from the hash chain, we obtain the first version snapshot hash and the second version snapshot hash. In the lightweight topology summary, find the record corresponding to the first version snapshot hash; Verify that the parent node pointer contained in the record points to the second version snapshot hash.

11. An electronic device, characterized in that, The electronic device includes a processor and a memory storing computer program instructions; when the electronic device executes the computer program instructions, it implements the method as described in any one of claims 1-10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1-10.

Images