Software copyright management system based on smart contract

Abstract

The invention relates to the technical field of information retrieval, in particular to a software copyright management system based on a smart contract, which comprises a copyright level right confirmation module, an NFT fragmentation evidence storage module, a dynamic right confirmation verification module, a fragment recombination tracking module and a transaction authorization management module. According to the method, copyright data hash mapping is constructed based on a block chain hierarchical right confirmation mode, a software copyright evolution path is defined, evolution integrity is ensured by calculating hierarchical hash values and adopting Merkle tree structure storage and association of copyright information of different hierarchies, right confirmation data is split and stored in a fragmentation evidence storage mode, safety is improved, and storage and retrieval burdens are reduced; a dynamic right confirmation mechanism is combined with hash comparison and public key signature, real-time verification of newly added copyright information is achieved, it is ensured that the copyright inheritance relation is accurate and checkable, hash calculation based on code fragments, code change tracking and derivative copyright confirmation verification are achieved, and an intelligent contract is used for transaction authorization management, transaction matching and rule verification execution and copyright circulation compliance is ensured.

Description

Technical Field

[0001] The present invention relates to the field of information retrieval technology, and in particular to a software copyright management system based on smart contracts. Background Art

[0002] The field of information retrieval technology includes technical means for storing, managing, querying and retrieving large amounts of data, aiming to improve the efficiency of information organization, indexing and retrieval. This technical field involves multiple directions such as database systems, full-text retrieval, data mining, natural language processing, and is widely used in search engines, document management, knowledge graphs and other scenarios. The core content includes building index structures to speed up data search, using query optimization technology to improve retrieval efficiency, applying classification and clustering methods to organize data, and using semantic analysis and machine learning to improve the accuracy of information matching. Systematic technologies in this field also include distributed storage and computing to provide efficient information access capabilities in large-scale data environments.

[0003] Among them, the software copyright management system based on smart contracts refers to a management system that uses smart contract technology to realize the registration, evidence storage, transaction and authorization of software copyrights. This patent subject is aimed at the problem of secure evidence storage and confirmation of software copyrights, and adopts the smart contract mechanism in blockchain technology to store and verify copyright information in a decentralized manner. Specifically, it covers the generation of unique identifiers for software copyrights, hash value calculation to ensure data integrity, copyright information writing strategies based on consensus mechanisms, and automated copyright transactions and authorization rules based on smart contracts. The system uses a distributed ledger to record copyright data to prevent tampering, and combines cryptographic algorithms to realize encrypted storage and secure verification of copyright information.

[0004] The existing technology lacks a hierarchical storage method when confirming software copyrights, and cannot accurately reflect the evolution path of copyrights, resulting in uncertainty in the ownership relationship of different versions. Evidence storage relies on centralized storage, which has limited security and is vulnerable to data tampering. In addition, the storage pressure is high in high-concurrency query scenarios, which affects retrieval efficiency. The confirmation process cannot dynamically track new or changed copyright information, resulting in delayed updates of copyright records, affecting the timeliness and integrity of confirmation. The transaction and authorization links rely on manual review, which has information asymmetry problems, and the lack of automated matching of transaction rules, resulting in low execution efficiency and increased risks of copyright transfer. The lack of refined tracking methods for code changes makes it difficult to implement derivative copyright confirmation, affecting the definition of rights and interests in the process of code reuse and increasing the possibility of copyright disputes. Summary of the invention

[0005] The purpose of the present invention is to solve the shortcomings of the prior art and to propose a software copyright management system based on smart contracts.

[0006] In order to achieve the above-mentioned purpose, the present invention adopts the following technical solution: A software copyright management system based on smart contracts includes: The copyright hierarchical confirmation module obtains basic information, code modules, and version records of software copyrights, divides the levels according to basic copyrights, evolutionary copyrights, and derivative copyrights, calculates hierarchical hash values, synthesizes hash mappings with Merkle trees, calls the parent node hash to compare the current value, generates mapping data, stores distributed networks, associates NFT metadata, and obtains hierarchical confirmation hash mapping data; The NFT sharding notarization module splits the NFT according to the copyright level based on the hierarchical confirmation hash mapping data, calls the sharding notarization process, calculates the sharding hash value, stores the distributed ledger, associates the NFT metadata, and obtains the NFT sharding notarization data; The dynamic title verification module collects newly added shard records based on the NFT shard title confirmation and evidence data, calls hash comparison, determines inheritance based on the upper-layer mapping, calls public key signature verification, generates evidence records, stores blockchain, and obtains title verification and evidence data; The fragment reorganization tracking module is based on the ownership verification and evidence data, collects code modules and API records, calls fragment hash calculation, generates a mapping based on change comparison, stores the blockchain, and obtains fragment ownership tracking data.

[0007] As a further solution of the present invention, the hierarchical title confirmation hash mapping data specifically includes the basic copyright hash, the evolved copyright hash, and the derived copyright hash; the NFT shard title confirmation evidence data specifically includes the NFT shard identifier, the shard evidence record, and the digital asset mapping; the title confirmation verification evidence data specifically includes the hash verification result, the signature authentication certificate, and the on-chain evidence; the fragment title confirmation tracking data specifically includes the fragment mapping code, the code tracking record, and the interface call record.

[0008] As a further solution of the present invention, the copyright level confirmation module includes: The basic copyright extraction submodule obtains basic software copyright information, code modules, and version records, performs code structure analysis on the code modules, calculates code similarity values ​​and change impact factors, selects code snippets that meet the basic copyright characteristics, establishes a basic copyright data set, and obtains basic copyright mapping data; The hierarchical hash calculation submodule calls the basic copyright mapping data, divides the hierarchies according to the basic copyright, the evolved copyright, and the derived copyright, calculates the basic hierarchical factor, the evolved hierarchical factor, and the derived hierarchical factor, and constructs the hierarchical hash data using the formula: ; Obtain the hierarchical hash value through operation, build the Merkle tree hash mapping, call the parent node hash value to compare the current hierarchical hash value, and generate hierarchical mapping data; in, Represents the level hash value, represents the base level factor, represents the evolutionary level factor, represents the derived level factor, is the number of code level groups, α represents the code structure parsing index variable; The title confirmation mapping storage submodule calls the hierarchical mapping data, stores it in the distributed network, parses the NFT metadata associated with the data, calculates the NFT title confirmation hash, and obtains the hierarchical title confirmation hash mapping data.

[0009] As a further solution of the present invention, the NFT sharding evidence storage module includes: The NFT hierarchical matching submodule extracts the hierarchical confirmation hash mapping data based on the NFT copyright hierarchy, matches the confirmation hash values ​​of the differentiated hierarchies, compares the confirmation hash mapping table with the hash data in the NFT evidence record, screens the NFT hierarchical data that meets the confirmation requirements, associates the NFT metadata according to the hierarchical structure, and obtains the NFT hierarchical confirmation mapping data; The sharding hash calculation submodule calls the NFT level confirmation mapping data, performs NFT sharding according to the copyright level, and calculates the hash values ​​of multiple NFT shards after splitting, using the formula: ; Calculate and obtain NFT shard hash data, associate NFT metadata, and generate NFT shard hash mapping data; in, Represents the NFT shard hash data, Represents the hash value of a single NFT shard, Represents the basic ownership hash value, Represents the number of NFT shards, Represents the hash value of the ownership after sharding. Represents the weight coefficient of the property rights confirmation level, Represents the number of title confirmation levels; The distributed storage submodule calls the NFT shard hash mapping data, extracts all NFT shard ownership confirmation and evidence data, compares the distributed ledger evidence node according to the NFT metadata index, stores it in the distributed ledger, and obtains the NFT shard ownership confirmation and evidence data.

[0010] As a further solution of the present invention, the dynamic right confirmation and verification module includes: The shard record collection submodule obtains the NFT shard ownership confirmation and storage data, extracts the newly added shard record, calculates the newly added shard hash value, calls the hash comparison method, compares the hash information in the ownership confirmation and storage data, filters the data that matches the hash value of the newly added shard record, and extracts the corresponding matching shard data; The inheritance determination submodule calls the upper-layer mapping relationship based on the matching shard data, calculates the inheritance relationship between the current shard and the mapped shard, and uses the formula: ; Calculate the shard inheritance coefficient, determine the validity of shard inheritance, and obtain the inheritance result; in, represents the shard inheritance coefficient, Represents the current shard hash value, represents the inherited weight, Represents the weight sum of the upper layer mapping shards, represents the coefficient sum of the upper layer mapping slice, Represents the contribution factor of the previous certificate shard, Represents the number of inheritance of the current shard, is the current number of shards, is the number of mapping shards, The number of shards for previous certificate storage; The title confirmation and evidence generation submodule calls the title confirmation and inheritance result, compares the evidence shard hash value with the public key signature, verifies the integrity of the shard, combines and matches the shard data, generates evidence records, stores the blockchain, and obtains title confirmation and verification evidence data.

[0011] As a further solution of the present invention, the fragment reassembly tracking module includes: The fragment data collection submodule calls the collection code module based on the ownership verification and evidence data, obtains API records and related fragment data, extracts fragment change information, calculates the fragment change difference set, and generates a fragment change data set; The hash map generation submodule calls the fragment change data set, uses fragment hash calculation, performs hash conversion on the fragment data, obtains the hash value matrix, and uses the formula: ; Calculate the hash variability of fragment data and establish the fragment hash mapping relationship; in, Represents the hash variability of the shard data, Representative The fragment is The hash value calculated by times, Represents the average hash value of all shards, It is The verification weight of each shard, is a small positive number, is a very small constant used to avoid the situation where the denominator is zero. Represents the total number of fragments, Represents the index variable of the number of hash calculations; As a further solution of the present invention, the system further includes: The transaction authorization management module collects NFT transaction records based on the fragment confirmation tracking data, calls the contract for comparison, updates the evidence data based on the transaction authorization judgment, generates records, and obtains the authorization management evidence data; The authorization management evidence data specifically includes transaction authorization records, contract verification credentials, and authorization update logs.

[0012] As a further solution of the present invention, the transaction authorization management module includes: The NFT transaction record collection submodule obtains the fragment confirmation tracking data, parses the transaction records, extracts the core data of transaction hash, transaction address, and transaction amount, matches it to the NFT contract address, filters the data that meets the transaction rules, and establishes an NFT transaction record database; The transaction authorization comparison submodule is based on the NFT transaction record database, calls the on-chain smart contract to obtain authorization information, parses the authorized account, authorization time and authorization amount, and performs validity verification using the formula: ; Calculate the authorization verification score, filter the transaction records that meet the conditions, and obtain the transaction authorization judgment result; in, Represents the authorization verification score, Representative The risk factor of a transaction, Represents the corresponding authorization amount, Represents the total number of transactions. represents the system default risk adjustment constant, Represents a dynamic adjustment factor, reflecting recent market volatility, Representative The safety factor of the transaction, Represents the transaction index variable; The evidence data update submodule calls the transaction authorization judgment result, matches the NFT confirmation information of the corresponding transaction, updates the transaction evidence, stores the transaction hash, authorization matching status, and evidence timestamp data, and generates authorization management evidence data.

[0013] Compared with the prior art, the advantages and positive effects of the present invention are: In the present invention, a hash map of copyright data is constructed based on the hierarchical confirmation method of blockchain, making the evolution path of software copyright clearer. By calculating the hierarchical hash value and storing it in a Merkle tree structure, copyright information at different levels can be associated to ensure the integrity of the evolution process. The fragmented evidence storage method splits and stores the confirmation data, making the evidence more secure and reducing the burden of storage and retrieval. The dynamic confirmation mechanism combines hash comparison and public key signature to achieve real-time verification of newly added copyright information and ensure that the inheritance relationship of copyright data is accurate and traceable. Hash calculation based on code fragments can effectively track code changes and make derivative copyright confirmation verifiable. Smart contracts are used for transaction authorization management. Through contracts, transaction matching and rule verification are executed to reduce manual intervention, improve transaction transparency, and ensure the compliance of the copyright transfer process. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a system flow chart of the present invention; Figure 2 This is a flowchart of the copyright level confirmation module of the present invention; Figure 3 This is the flow chart of the NFT sharding evidence storage module of the present invention; Figure 4 This is a flow chart of the dynamic rights confirmation and verification module of the present invention; Figure 5 This is a flow chart of the fragment reassembly tracking module of the present invention; Figure 6 This is a flow chart of the transaction authorization management module of the present invention. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0016] In the description of the present invention, it should be understood that the terms "length", "width", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside" and the like indicate positions or positional relationships based on the positions or positional relationships shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, in the description of the present invention, "multiple" means two or more, unless otherwise clearly and specifically defined.

[0017] Embodiment 1

[0018] See also Figure 1, a software copyright management system based on smart contracts includes: The copyright hierarchical confirmation module obtains basic information, code modules, and version records of software copyrights, divides the levels according to basic copyrights, evolutionary copyrights, and derivative copyrights, calculates hierarchical hash values, synthesizes hash mappings with Merkle trees, calls the parent node hash to compare the current value, generates mapping data, stores distributed networks, associates NFT metadata, and obtains hierarchical confirmation hash mapping data; The NFT sharding notarization module is based on the hierarchical confirmation hash mapping data, splits the NFT according to the copyright level, calls the sharding notarization process, calculates the sharding hash value, stores the distributed ledger, associates the NFT metadata, and obtains the NFT sharding notarization data; The dynamic title verification module is based on the NFT shard title confirmation and evidence data, collects new shard records, calls hash comparison, determines inheritance based on the upper-layer mapping, calls public key signature verification, generates evidence records, stores blockchain, and obtains title verification and evidence data; The fragment reorganization tracking module is based on the ownership verification and evidence data, collects code modules and API records, calls fragment hash calculation, generates mapping based on change comparison, stores blockchain, and obtains fragment ownership tracking data; The transaction authorization management module collects NFT transaction records based on fragment ownership tracking data, calls contract comparison, updates evidence data based on transaction authorization judgment, generates records, and obtains authorization management evidence data.

[0019] The hierarchical title confirmation hash mapping data specifically includes the basic copyright hash, evolved copyright hash, and derived copyright hash. The NFT shard title confirmation evidence data specifically includes the NFT shard identifier, shard evidence record, and digital asset mapping. The title confirmation verification evidence data specifically includes the hash verification result, signature authentication certificate, and on-chain evidence. The fragment title confirmation tracking data specifically includes the fragment mapping code, code tracking record, and interface call record. The authorization management evidence data specifically includes transaction authorization records, contract verification credentials, and authorization update logs.

[0020] See also Figure 2 , the copyright level confirmation module includes: The basic copyright extraction submodule obtains basic software copyright information, code modules, and version records, performs code structure analysis on the code modules, calculates code similarity values ​​and change impact factors, selects code snippets that meet the basic copyright characteristics, establishes a basic copyright data set, and obtains basic copyright mapping data; First, the core copyright information of the software is obtained by parsing the source code of the software, including code modules, version records, etc. In the code parsing process, the code modules are first split according to functional logic. For example, if the software contains functions such as user login, data storage, and interface call, the code structure of the corresponding module is extracted respectively, and the functions, classes, interfaces and other elements in the code module are structurally extracted. Then the code similarity value is calculated. For the calculation of code similarity, it is necessary to compare the character matching degree, function call chain consistency, control flow similarity, etc. of each code fragment. For example, taking the two code fragments A and B as examples, the character matching rate is 80%, the call chain consistency is 75%, and the control flow similarity is 85%. The final similarity value can be calculated by weighted average. For the calculation of the change impact factor, it is necessary to analyze the code modification during the software iteration process, determine the degree of impact, and set the impact weight. For example, if a code snippet is modified three times in five versions, the impact factor can be set to 0.6 (i.e. 3 / 5). For screening code snippets that meet the basic copyright characteristics, certain thresholds can be set, such as code similarity must be greater than 70% and change impact factor must be less than 0.7, to ensure that the selected code snippets can fully represent the core copyright information of the software. Subsequently, a basic copyright data set is constructed, the screened code is structured and stored, and basic copyright mapping data is generated, ultimately obtaining basic data that can be used for subsequent copyright confirmation.

[0021] The hierarchical hash calculation submodule calls the basic copyright mapping data, divides the hierarchies according to the basic copyright, evolved copyright, and derived copyright, calculates the basic hierarchical factors, evolved hierarchical factors, and derived hierarchical factors, and constructs hierarchical hash data using the formula: ; Obtain the hierarchical hash value through operation, build the Merkle tree hash mapping, call the parent node hash value to compare the current hierarchical hash value, and generate hierarchical mapping data; in, Represents the level hash value, represents the base level factor, represents the evolutionary level factor, represents the derived level factor, is the number of code level groups, α represents the code structure parsing index variable; First, we divide the levels into basic copyright, evolutionary copyright, and derivative copyright. In the process of level division, we analyze the stability of the code structure, the degree of functional change, and the evolution process. For example, the basic copyright level mainly includes the unmodified core code, the evolutionary copyright level includes the optimization and adjustment part of the basic code, and the derivative copyright level covers the newly added functional modules based on the original code structure. Then, we calculate the basic level factor, evolutionary level factor, and derivative level factor. Assume that the basic level factor of a code module is is 0.8, the evolutionary level factor is 0.6, the derived level factor is 0.5, then according to the formula: ; When grp=3, the calculation results are as follows: ; Assuming that the calculated values ​​of the three levels are 0.75, 0.85, and 0.78 respectively, the final level hash value is: ; After the hierarchical hash value is calculated, it is used to construct the Merkle tree hash map. The specific method is to first store the hierarchical hash value of each code snippet and calculate the hash value of the adjacent node. For example, assuming that the hash values ​​of two code snippets are 0.793 and 0.812 respectively, the hash value of their parent node can be calculated as: ; Finally, by storing the root hash value of the Merkle tree, the complete hierarchical mapping data can be obtained.

[0022] The title mapping storage submodule calls the hierarchical mapping data, stores it in the distributed network, parses the NFT metadata associated with the data, calculates the NFT title hash, and obtains the hierarchical title hash mapping data.

[0023] First, the hierarchical mapping data is stored in a distributed network, such as IPFS or blockchain storage nodes. The storage process includes steps such as data sharding, shard index generation, and hash verification. For example, the hierarchical mapping data is sharded by 256KB, and each shard generates a unique hash index and is stored in a Merkle tree structure to ensure data integrity. In the process of parsing the NFT metadata associated with the data, the unique identification information of the software copyright, such as the code version number, submission record, developer identity, etc., is extracted, and then the NFT confirmation hash is calculated. The calculation method can be based on the combination of the hierarchical hash value, the timestamp, and the developer's public key. For example: ; Assuming the timestamp is 1700000000, and the developer public key hash is "0xA1B2C3D4", the calculation results are as follows: ; The final NFT ownership hash is obtained and stored in the distributed network for subsequent ownership verification, and finally the hierarchical ownership hash mapping data is obtained.

[0024] Table 1 Example of hierarchical factor calculation

[0025] As shown in Table 1, there are certain differences in the calculation results of the hierarchical factors for different code modules. Ultimately, by comparing the hierarchical hash values ​​of different modules, it can be used to determine the hierarchical relationship of the code in the copyright system.

[0026] See also Figure 3 , the NFT sharding evidence module includes: The NFT hierarchical matching submodule extracts hierarchical rights confirmation hash mapping data based on the NFT copyright hierarchy, matches the rights confirmation hash values ​​of the differentiated hierarchies, compares the rights confirmation hash mapping table with the hash data in the NFT evidence record, screens the NFT hierarchical data that meets the rights confirmation requirements, associates the NFT metadata according to the hierarchical structure, and obtains the NFT hierarchical rights confirmation mapping data; First, extract the NFT confirmation hash mapping data from the NFT storage system. In this process, first retrieve all the NFT copyright data that have been stored, including the confirmation hash value corresponding to each NFT and its storage timestamp, and build a confirmation hash mapping table, which contains the unique identifier of the NFT (such as NFT_ID), the confirmation hash value ( )、Copyright Level( ) and other information, and then compare the ownership hash value of the current NFT data to be matched ( ) and the confirmation hash value in the mapping table, and filter out the NFT-level data that meets the confirmation requirements by traversing and comparing them item by item. For example, if the confirmation hash value of an NFT has a match in the mapping table, and its copyright level If it is consistent with the existing copyright level in the database or is within the permitted range (such as the same or higher level), the NFT data meets the ownership confirmation requirements. Next, the NFT data that meets the ownership confirmation requirements will be organized according to the hierarchical structure so that it can be correctly associated with the NFT metadata. For the NFT hierarchical data that meets the ownership confirmation requirements, its hierarchical ownership confirmation mapping data will be stored for use by the subsequent sharding hash calculation sub-module.

[0027] The sharding hash calculation submodule calls the NFT level confirmation mapping data, shards the NFT according to the copyright level, and calculates the hash value of multiple NFT shards after splitting, using the formula: ; Calculate and obtain NFT shard hash data, associate NFT metadata, and generate NFT shard hash mapping data; in, Represents the NFT shard hash data, Represents the hash value of a single NFT shard, Represents the basic ownership hash value, Represents the number of NFT shards, Represents the hash value of the ownership after sharding. Represents the weight coefficient of the property rights confirmation level, Represents the number of title confirmation levels; For example, suppose an NFT contains copyright information at three different levels, corresponding to the level weights , , , then the NFT can be divided into three shards, and each shard calculates the hash value ( ), and then calculate the NFT shard hash data based on the following formula: ; in, Assume that the hash value is the basic confirmation value. , the hash values ​​of NFT shards are , , , then the calculation is as follows: The first part of the calculation: ; ; The second part of the calculation: ; ; ; ; ; Final NFT shard hash data calculation results: ; The result shows that after the NFT is sharded, the deviation between the hash value of each shard and the basic confirmation hash value is 300, and the square root adjustment value generated after weighting is 27.27, so the final shard hash data is 327.27. This value reflects the hash characteristics of different levels of NFT in the confirmation and evidence storage, indicating that the overall confirmation shard data of the NFT can be adjusted under the influence of the hierarchical weight of the NFT, ensuring that the impact of different hierarchical weights on the NFT confirmation results can be quantified. The numerical result will be used in subsequent evidence storage steps to ensure the consistency and verifiability of the NFT confirmation hash data during the storage process.

[0028] The distributed storage submodule calls the NFT shard hash mapping data, extracts all NFT shard ownership confirmation and evidence data, compares the distributed ledger evidence node according to the NFT metadata index, stores it in the distributed ledger, and obtains the NFT shard ownership confirmation and evidence data.

[0029] First, extract all NFT shard ownership confirmation and storage data, call the NFT metadata index, and match it with the distributed ledger storage node. In this process, each NFT shard hash data will be matched to the most suitable distributed ledger node and stored in the ledger. At the same time, the metadata of the storage will be recorded, including NFT_ID, shard hash value ( )、Evidence timestamp( ) and the storage node ID ( ), as shown in Table 2.

[0030] Table 2 NFT sharding rights confirmation and storage data table

[0031] As shown in Table 2, the shard hash data of each NFT is stored in the corresponding distributed storage node to ensure the integrity and verifiability of the ownership confirmation and evidence data.

[0032] See also Figure 4 , the dynamic rights confirmation and verification module includes: The shard record collection submodule obtains NFT shard ownership confirmation and storage data, extracts new shard records, calculates the new shard hash value, calls the hash comparison method, compares the hash information in the ownership confirmation and storage data, filters the data that matches the new shard record hash value, and extracts the corresponding matching shard data; First, extract the latest shard confirmation data from the data set stored in the blockchain, parse the metadata field of the evidence data, obtain the timestamp, transaction hash and shard unique identifier in the evidence data, extract all new shard records on this basis, and further call the hash function to calculate the hash value of the new shard data. The hash calculation process involves performing byte-level reading on the core fields of the shard data and performing SHA-256 hash operations on it. Assuming that the new shard data contains data blocks , then the steps to calculate the hash value are: Perform SHA-256 calculation to get the hash ,right Calculated , and so on, concatenate all the hash values ​​and calculate the final hash , the calculation formula is as follows: ; The calculated hash value is compared with the hash information in the ownership confirmation evidence data. The comparison method adopts a byte-by-byte comparison method, that is, the hash value in the evidence data is read in turn and compared with each byte of the calculated hash value. If they match, the shard data is considered complete, otherwise the shard data is discarded. After further screening the matching shard data, the storage address, owner information, shard weight and other attributes of the shard data are extracted to complete the shard record collection task.

[0033] The inheritance judgment submodule is based on matching shard data, calling the upper-level mapping relationship, and calculating the inheritance relationship between the current shard and the mapped shard using the formula: ; Calculate the shard inheritance coefficient, determine the validity of shard inheritance, and obtain the inheritance result; in, represents the shard inheritance coefficient, Represents the current shard hash value, represents the inherited weight, Represents the weight sum of the upper layer mapping shards, represents the coefficient sum of the upper layer mapping slice, Represents the contribution factor of the previous certificate shard, Represents the number of inheritance of the current shard, is the current number of shards, is the number of mapping shards, The number of shards for previous certificate storage; Assume that the upper-layer mapping shards involved in the current shard have The inherited weight value set is When calculating the inheritance relationship of the current shard, it is necessary to perform operations based on the inheritance weight and the weight sum of the mapped shards. The specific calculation process is as follows: 1. Calculate the sum of the inheritance weights of the current shard and the mapped shard: ; in, is the hash value of the current shard, is the inherited weight value of the corresponding mapping shard. Assuming that the current shard is associated with two mapping shards, their hash values ​​are , , the inheritance weights are , , the calculation result is: ; 2. Calculate the weight and coefficient sum of the upper mapping shards: ; Assume that the weights of the mapping shards are , , the coefficients and are , , then the calculation result is: ; 3. Calculate the contribution factor of the previous certificate shards: ; Assuming the number of previous certificate shards is 3, their contribution factors are , , , then the calculation result is: ; 4. Calculate the number of inheritances of the current shard , assuming , then the shard inheritance coefficient is finally calculated: ; ; If the inheritance coefficient is greater than the set inheritance threshold (assuming it is 0.5), the inheritance is considered valid, otherwise it is considered invalid. In this case, It is greater than the threshold of 0.5, so the shard inheritance is valid, and the final result of inheritance confirmation is obtained.

[0034] The title confirmation and evidence generation submodule calls the title confirmation inheritance result, compares the evidence shard hash value with the public key signature, verifies the integrity of the shard, combines and matches the shard data, generates evidence records, stores the blockchain, and obtains title confirmation and verification evidence data.

[0035] First, compare the hash value of the evidence shard with the public key signature to verify the integrity of the shard. During the hash value comparison process, perform RSA-2048 digital signature verification on the hash of the evidence shard. The verification method is to decrypt the signature value in the evidence data and compare it with the calculated hash value. If the two match completely, the evidence data is considered complete. If not, the evidence data is invalid and the shard data is discarded. After the verification is completed, combine the matching shard data to generate an evidence record and store it in the blockchain. The storage process involves encryption and chaining of the shard data. AES-256 is used to encrypt the shard data. The encryption process is as follows: 1. Generate a random key ,For example 2. Use AES-256 to shard data To encrypt: ; 3. Generate blockchain transactions, transaction data includes , public key signature, timestamp and other information, and upload them to the chain through smart contracts. After the evidence data is uploaded to the chain, the ownership verification of the evidence data is obtained.

[0036] Table 3 shows the encrypted storage of different evidence shards: Table 3 Evidence Sharding Encryption Storage Table

[0037] As shown in Table 3, after AES-256 encryption, the data size of the evidence shard increases slightly, mainly due to the addition of padding data and signature data.

[0038] Ultimately, all evidence records are stored in the blockchain to ensure the integrity and traceability of the data, and obtain the final ownership verification of the evidence data.

[0039] See also Figure 5 , the fragment reassembly tracking module includes: The fragment data collection submodule verifies the evidence data based on the ownership confirmation, calls the collection code module, obtains API records and related fragment data, extracts fragment change information, calculates the fragment change difference set, and generates a fragment change data set; First, the acquisition code module is called. The main task of this module is to extract API call records from the evidence data and identify the fragmented data associated with it. The specific process is as follows: First, the system locates the corresponding evidence entry through the unique identifier in the evidence data (such as transaction ID, blockchain hash value), then parses the metadata field of the evidence entry, filters out the API call log, and further extracts the involved fragmented data. These fragmented data are usually composed of different data blocks, and their data format can be JSON, XML or structured data in the database table. After the extraction is completed, the system compares the current fragmented data with the historical evidence data and calculates the data changes, including the word For the addition, deletion and modification of segments, for numeric data, the system calculates the range of value changes, and for text data, the changed parts are identified through string matching algorithms. At the same time, the system also calculates the difference set of all changed contents and uses data structures to store change information. For example, for a certain API call, if the original value of data field A is 100 and the current value is 120, the change difference is 20, and if field B is deleted, its deletion status is recorded. Finally, all change information is organized into a fragment change data set, which contains the changes of each data fragment, including the specific content of added, deleted, and modified fields, and stores them in the change tracking database.

[0040] The hash map generation submodule calls the fragment change data set, uses fragment hash calculation, performs hash conversion on the fragment data, and obtains the hash value matrix using the formula: ; Calculate the hash variability of fragment data and establish the fragment hash mapping relationship; in, Represents the hash variability of the shard data, Representative The fragment is The hash value calculated by times, Represents the average hash value of all shards, It is The verification weight of each shard, is a small positive number, is a very small constant used to avoid the situation where the denominator is zero. Represents the total number of fragments, Represents the index variable of the number of hash calculations; The specific execution process is as follows: First, the system reads the data items in the fragment change data set one by one, and calculates the hash value using the SHA-256 or MD5 hash algorithm. Then, the system records the hash value of each fragment in different calculation rounds into the hash value matrix, forming the following structure: Table 4 Hash value records

[0041] in, Representative The fragment is The hash value is calculated for each time. In order to calculate the hash variability of the fragment data, the system uses the formula: ; During the calculation process, the average hash value of the fragment data is first determined , calculated as follows: ; Then calculate the absolute difference between the hash value of each fragment and the mean and multiply it by the corresponding verification weight For example, if there are 3 fragments, their hash values ​​are 0xA3, 0xB2, and 0xC1 (converted to decimal, they are 163, 178, and 193 respectively), then their average value is: ; If the corresponding weights are 1.2, 0.9, and 1.1, respectively, then calculate the hash variability: ; Assumptions ,but: ; ; ; The calculation result reflects the degree of hash variability of data fragments. The larger the value, the greater the data change. Through the calculated variability results, the system establishes a hash mapping relationship and stores it in the database for subsequent comparison.

[0042] The title tracking storage submodule calls the fragment hash mapping relationship, combines the title verification evidence data, compares the evidence blockchain storage status, filters the title fragment tracking parameters, stores the blockchain title data, and obtains the fragment title tracking data.

[0043] The specific operation process is as follows: First, the system retrieves the currently stored hash value from the evidence blockchain, and matches the currently calculated hash value matrix according to the hash mapping relationship. If a fragment hash value does not exist in the blockchain storage state, the fragment is judged to be new data. If it exists but is inconsistent, it is identified as changed data. If it is a complete match, the original state is maintained. After comparison, the system screens the fragment data that needs to be recorded according to the ownership requirements of the evidence data, and records its tracking parameters. For example, the evidence hash value of a fragment data in the blockchain is 0xA3, and the current calculated value is 0xB2, then the change status of the fragment is recorded. At the same time, the fragment ownership tracking data is stored in the blockchain to ensure the integrity of the data.

[0044] See also Figure 6 , the transaction authorization management module includes: The NFT transaction record collection submodule obtains fragment ownership tracking data, parses transaction records, extracts core data such as transaction hash, transaction address, and transaction amount, matches them to the NFT contract address, filters data that meets the transaction rules, and establishes an NFT transaction record database; First, the on-chain fragment ownership tracking data is received, which contains the ownership information of each transaction, including the transaction initiation time, the addresses of both parties to the transaction, the transaction amount, the NFT contract address, etc. Then, the submodule parses the transaction records, deduplicates the transaction hash of each record, and matches the corresponding transaction address according to the transaction hash. After the transaction address is parsed, the sender and receiver addresses are extracted, and the transaction amount is converted to ensure that all transaction amounts are converted to standard units for comparison. The conversion rules of the transaction amount are processed according to the standards of different NFT trading platforms. For example, ETH transactions use 18 decimal places, and the BSC chain uses 8 decimal places. After unified conversion, the transaction data enters the screening stage, which is mainly based on the transaction amount and NFT contract. The validity of the transaction is determined by the matching relationship between the contract address and the address. During the screening process, invalid address transactions are first excluded, such as blacklist addresses and addresses that have been confirmed as abnormal transactions. Secondly, the NFT is queried based on the NFT contract address to see if it belongs to a standardized contract. If it is a non-standard NFT contract, the abnormal status of the transaction is recorded. If it meets the standard contract, it is further matched to see if the transaction amount exceeds the minimum transaction threshold. For example, the minimum threshold for NFT transactions on a certain platform is 0.05ETH. If the transaction amount is 0.03ETH, the transaction is eliminated. Finally, qualified transaction records are entered into the NFT transaction record database. The data fields stored in the database include transaction hash, sender address, receiver address, transaction amount, NFT contract address, transaction time, etc.

[0045] The transaction authorization comparison submodule is based on the NFT transaction record database, calls the on-chain smart contract to obtain authorization information, parses the authorized account, authorization time and authorization amount, and performs validity verification using the formula: ; Calculate the authorization verification score, filter the transaction records that meet the conditions, and obtain the transaction authorization judgment result; in, Represents the authorization verification score, Representative The risk factor of a transaction, Represents the corresponding authorization amount, Represents the total number of transactions. represents the system default risk adjustment constant, Represents a dynamic adjustment factor, reflecting recent market volatility, Representative The safety factor of the transaction, Represents the transaction index variable; First, query the corresponding authorized account according to the transaction hash in the transaction record database, and extract the authorization time and authorization amount. On this basis, compare the authorized account with the transaction parties to determine whether the authorized account belongs to one of the transaction parties. If the authorized account does not match, the transaction authorization is invalid. Next, verify the authorization time to determine whether the authorization time is earlier than the transaction time. If the authorization time is later than the transaction time, it is determined to be invalid authorization. The authorization amount needs to calculate the authorization verification score according to the formula. The formula is as follows: ; The values ​​of each parameter are obtained as follows: Total number of transactions :Get directly from the NFT transaction record database, assuming that the number of transactions processed this time is 5. Transaction risk factor :Calculated based on the historical credit score of the transaction address. If the transaction address has participated in more than 10 transactions in the past 6 months and has no abnormal records, its risk factor is set to 0.1, otherwise the risk factor is set to 0.5. For example, if the first transaction address belongs to a new user, then . Authorization amount :This value is obtained directly from the smart contract. For example, the authorization limit for the first transaction is 2.5ETH. The system default risk adjustment constant : Set to 1.2, this value is obtained based on the analysis of the system's historical transaction data. Dynamic adjustment factor : Reflects market volatility, calculated using the volatility of NFT market trading volume in the past 24 hours. Assuming that the market volatility in the last 24 hours is 0.15, then Transaction security factor :Calculated based on the historical data of the transaction address, if the transaction address has no abnormal records within 6 months, the safety factor is set to 2.0, otherwise it is set to 0.8. For example, if the first transaction address is a new user, then .

[0046] Substitute the above data into the formula for calculation: ; ; ; ; Calculation results , because the value is lower than the authorization threshold set by the system , then the transaction is judged as invalid authorization, and the transaction authorization judgment result is finally obtained.

[0047] The evidence data update submodule calls the transaction authorization judgment result, matches the NFT confirmation information of the corresponding transaction, updates the transaction evidence, stores the transaction hash, authorization matching status, and evidence timestamp data, and generates authorization management evidence data.

[0048] First, match the NFT confirmation information in the transaction record database, obtain the confirmation status of each transaction, and check whether the transaction hash has been recorded. If the transaction hash has been recorded, update the record status, otherwise add a new record. The update of the record data includes writing the transaction hash, authorization matching status and record timestamp. The record timestamp is obtained using the current blockchain time. For example, if a transaction is recorded at 12:30:45 on March 13, 2025, the record timestamp is recorded as 2025-03-13T12:30:45Z. The record data format is shown in the following table: Table 5 Transaction authorization management evidence data table

[0049] As shown in Table 5, the transaction authorization management evidence data table records the correspondence between the transaction hash and the authorization matching status. The evidence data can be used in scenarios such as transaction tracing, compliance auditing, and authorization verification.

[0050] The above are only preferred embodiments of the present invention and are not intended to limit the present invention in other forms. Any technician familiar with the profession may use the technical contents disclosed above to change or modify them into equivalent embodiments with equivalent changes and apply them to other fields. However, any simple modification, equivalent change and modification made to the above embodiments based on the technical essence of the present invention without departing from the technical solution of the present invention still falls within the protection scope of the technical solution of the present invention.

Claims

1. A software copyright management system based on smart contracts, characterized in that: The system comprises: The copyright hierarchical confirmation module obtains basic information, code modules, and version records of software copyrights, divides the levels according to basic copyrights, evolutionary copyrights, and derivative copyrights, calculates hierarchical hash values, synthesizes hash mappings with Merkle trees, calls the parent node hash to compare the current value, generates mapping data, stores distributed networks, associates NFT metadata, and obtains hierarchical confirmation hash mapping data; The NFT sharding notarization module splits the NFT according to the copyright level based on the hierarchical confirmation hash mapping data, calls the sharding notarization process, calculates the sharding hash value, stores the distributed ledger, associates the NFT metadata, and obtains the NFT sharding notarization data; The dynamic title verification module collects newly added shard records based on the NFT shard title confirmation and evidence data, calls hash comparison, determines inheritance based on the upper-layer mapping, calls public key signature verification, generates evidence records, stores blockchain, and obtains title verification and evidence data; The fragment reorganization tracking module is based on the ownership verification and evidence data, collects code modules and API records, calls fragment hash calculation, generates a mapping based on change comparison, stores the blockchain, and obtains fragment ownership tracking data.

2. The software copyright management system based on smart contracts according to claim 1 is characterized in that: The hierarchical title confirmation hash mapping data specifically includes the basic copyright hash, evolved copyright hash, and derived copyright hash; the NFT shard title confirmation evidence data specifically includes the NFT shard identifier, shard evidence record, and digital asset mapping; the title confirmation verification evidence data specifically includes the hash verification result, signature authentication certificate, and on-chain evidence; the fragment title confirmation tracking data specifically includes the fragment mapping code, code tracking record, and interface call record.

3. The software copyright management system based on smart contracts according to claim 2 is characterized in that: The copyright level confirmation module includes: The basic copyright extraction submodule obtains basic software copyright information, code modules, and version records, performs code structure analysis on the code modules, calculates code similarity values ​​and change impact factors, selects code snippets that meet the basic copyright characteristics, establishes a basic copyright data set, and obtains basic copyright mapping data; The hierarchical hash calculation submodule calls the basic copyright mapping data, divides the hierarchies according to the basic copyright, the evolved copyright, and the derived copyright, calculates the basic hierarchical factor, the evolved hierarchical factor, and the derived hierarchical factor, and constructs the hierarchical hash data using the formula: ； Obtain the hierarchical hash value through operation, build the Merkle tree hash mapping, call the parent node hash value to compare the current hierarchical hash value, and generate hierarchical mapping data; in, Represents the level hash value, represents the base level factor, represents the evolutionary level factor, represents the derived level factor, is the number of code level groups, α represents the code structure parsing index variable; The title confirmation mapping storage submodule calls the hierarchical mapping data, stores it in the distributed network, parses the NFT metadata associated with the data, calculates the NFT title confirmation hash, and obtains the hierarchical title confirmation hash mapping data.

4. The software copyright management system based on smart contracts according to claim 3 is characterized in that: The NFT sharding evidence storage module includes: The NFT hierarchical matching submodule extracts the hierarchical confirmation hash mapping data based on the NFT copyright hierarchy, matches the confirmation hash values ​​of the differentiated hierarchies, compares the confirmation hash mapping table with the hash data in the NFT evidence record, screens the NFT hierarchical data that meets the confirmation requirements, associates the NFT metadata according to the hierarchical structure, and obtains the NFT hierarchical confirmation mapping data; The sharding hash calculation submodule calls the NFT level confirmation mapping data, performs NFT sharding according to the copyright level, and calculates the hash values ​​of multiple NFT shards after splitting, using the formula: ； Calculate and obtain NFT shard hash data, associate NFT metadata, and generate NFT shard hash mapping data; in, Represents the NFT shard hash data, Represents the hash value of a single NFT shard, Represents the basic ownership hash value, Represents the number of NFT shards, Represents the hash value of the ownership after sharding. Represents the weight coefficient of the property rights confirmation level, Represents the number of title confirmation levels; The distributed storage submodule calls the NFT shard hash mapping data, extracts all NFT shard ownership confirmation and evidence data, compares the distributed ledger evidence node according to the NFT metadata index, stores it in the distributed ledger, and obtains the NFT shard ownership confirmation and evidence data.

5. The software copyright management system based on smart contracts according to claim 4 is characterized in that: The dynamic rights confirmation and verification module includes: The shard record collection submodule obtains the NFT shard ownership confirmation and storage data, extracts the newly added shard record, calculates the newly added shard hash value, calls the hash comparison method, compares the hash information in the ownership confirmation and storage data, filters the data that matches the hash value of the newly added shard record, and extracts the corresponding matching shard data; The inheritance determination submodule calls the upper-layer mapping relationship based on the matching shard data, calculates the inheritance relationship between the current shard and the mapped shard, and uses the formula: ； Calculate the shard inheritance coefficient, determine the validity of shard inheritance, and obtain the inheritance result; in, represents the shard inheritance coefficient, Represents the current shard hash value, represents the inherited weight, Represents the weight sum of the upper layer mapping shards, represents the coefficient sum of the upper layer mapping slice, Represents the contribution factor of the previous certificate shard, Represents the number of inheritance of the current shard, is the current number of shards, is the number of mapping shards, The number of shards for previous certificate storage; The title confirmation and evidence generation submodule calls the title confirmation and inheritance result, compares the evidence shard hash value with the public key signature, verifies the integrity of the shard, combines and matches the shard data, generates evidence records, stores the blockchain, and obtains title confirmation and verification evidence data.

6. The software copyright management system based on smart contracts according to claim 5 is characterized in that: The fragment reassembly tracking module includes: The fragment data collection submodule calls the collection code module based on the ownership verification and evidence data, obtains API records and related fragment data, extracts fragment change information, calculates the fragment change difference set, and generates a fragment change data set; The hash map generation submodule calls the fragment change data set, uses fragment hash calculation, performs hash conversion on the fragment data, obtains the hash value matrix, and uses the formula: ； Calculate the hash variability of fragment data and establish the fragment hash mapping relationship; in, Represents the hash variability of the shard data, Representative The fragment is The hash value calculated by times, Represents the average hash value of all shards, It is The verification weight of each shard, is a small positive number, is a very small constant used to avoid the situation where the denominator is zero. Represents the total number of fragments, Represents the index variable of the number of hash calculations; The title tracking storage submodule calls the fragment hash mapping relationship, combines the title verification evidence data, compares the evidence blockchain storage status, screens the title fragment tracking parameters, stores the blockchain title data, and obtains the fragment title tracking data.

7. The software copyright management system based on smart contracts according to claim 6 is characterized in that: The system further comprises: The transaction authorization management module collects NFT transaction records based on the fragment confirmation tracking data, calls the contract for comparison, updates the evidence data based on the transaction authorization judgment, generates records, and obtains the authorization management evidence data; The authorization management evidence data specifically includes transaction authorization records, contract verification credentials, and authorization update logs.

8. The software copyright management system based on smart contracts according to claim 7 is characterized in that: The transaction authorization management module includes: The NFT transaction record collection submodule obtains the fragment confirmation tracking data, parses the transaction records, extracts the core data of transaction hash, transaction address, and transaction amount, matches it to the NFT contract address, filters the data that meets the transaction rules, and establishes an NFT transaction record database; The transaction authorization comparison submodule is based on the NFT transaction record database, calls the on-chain smart contract to obtain authorization information, parses the authorized account, authorization time and authorization amount, and performs validity verification using the formula: ； Calculate the authorization verification score, filter the transaction records that meet the conditions, and obtain the transaction authorization judgment result; in, Represents the authorization verification score, Representative The risk factor of a transaction, Represents the corresponding authorization amount, Represents the total number of transactions. represents the system default risk adjustment constant, Represents a dynamic adjustment factor, reflecting recent market volatility, Representative The safety factor of the transaction, Represents the transaction index variable; The evidence data update submodule calls the transaction authorization judgment result, matches the NFT confirmation information of the corresponding transaction, updates the transaction evidence, stores the transaction hash, authorization matching status, and evidence timestamp data, and generates authorization management evidence data.

Images