Contract generation method and apparatus, electronic device, and medium

Abstract

A contract generation method and device, electronic equipment and medium are disclosed, including: receiving a data transaction request sent by a data demand end; in response to the transaction request, obtaining ownership information of the data to be traded and index information of a plurality of data value indicators, the ownership information being used to indicate the data ownership of the data to be traded, each data value indicator being an indicator that has an influence on the data value of the data to be traded; matching the data access permission of the data demand end with the data ownership of the data to be traded to generate a matching result; in response to the matching result indicating that the data operation permission matches the data ownership, performing multi-dimensional value evaluation on the data to be traded based on the index information of the plurality of data value indicators to obtain an evaluation value of the data to be traded; and generating a data transaction contract associated with the data to be traded based on the evaluation value. The present application can be applied to business fields such as medical health, and improve the security of transaction data in the contract.

Description

Technical Field

[0001] This application relates to the field of data transactions, and in particular to a method, apparatus, electronic device, and medium for generating contracts. Background Technology

[0002] With the digital transformation of the healthcare industry, medical data is increasingly being used in drug development, AI-assisted diagnosis, and health insurance actuarial science, leading to a significant increase in demand for its asset-based transactions. However, medical data transactions rely on data transaction contracts. Many contract generation methods use generic templates from other transactions, easily overlooking the sensitivity of medical data and failing to deeply adapt to its unique characteristics. This increases the risk of medical data breaches, resulting in insufficient security protection for the transaction data in the generated contracts. Summary of the Invention

[0003] The main objective of this application is to provide a contract generation method, apparatus, electronic device, and medium, which aims to solve the problem that existing contract generation methods do not adequately protect the security of transaction data.

[0004] To achieve the above objectives, a first aspect of this application proposes a contract generation method, the method comprising: Receive a data transaction request sent by the data requester, the data transaction request being used to request data to be traded; In response to the transaction request, the ownership information of the data to be traded and the indicator information of multiple data value indicators are obtained. The ownership information is used to indicate the data ownership of the data to be traded, and each of the data value indicators is an indicator that has an impact on the data value of the data to be traded. The data access permissions of the data requesting end are matched with the data ownership of the data to be traded to generate a matching result. The matching result is used to indicate whether the data access permissions match the data ownership. In response to the matching result indicating that the data operation permission matches the data ownership, the data to be traded is evaluated in a multi-dimensional value assessment based on the indicator information of the multiple data value indicators to obtain the evaluated value of the data to be traded. Based on the assessed value, a data transaction contract associated with the data to be traded is generated.

[0005] In some implementations, before generating a data transaction contract associated with the data to be traded based on the assessed value, the method further includes: Based on the ownership information of the data to be traded and the preset ownership change logic, determine the ownership change rules corresponding to the ownership information of the data to be traded; Based on the ownership information and the ownership change rules, an ownership transaction strategy for the data to be traded is generated; Based on the ownership transaction strategy and the assessed value, a data transaction contract associated with the data to be traded is generated.

[0006] In some implementations, the indicator information of each data value indicator corresponds to a value assessment of a dimension, and the value assessment of each dimension corresponds to a preset dimension assessment rule. The method of performing a multi-dimensional value assessment on the data to be traded based on the indicator information of the multiple data value indicators to obtain the assessed value of the data to be traded includes: Based on the indicator information of each data value indicator and the preset dimension evaluation rules corresponding to the indicator information, the evaluation sub-value of the indicator information of each data value indicator is obtained. Identify the application scenarios of the data to be traded on the data demand side; Based on the application scenario, determine the weight corresponding to each evaluation sub-value; The assessed value of the data to be traded is obtained based on the assessment sub-values ​​of the indicator information of each data value indicator and the weights corresponding to each assessment sub-value.

[0007] In some implementations, the multi-dimensional value assessment includes at least two of the following: scientific research value assessment, data quality value assessment, compliance risk value assessment, and market value assessment.

[0008] In some implementations, after generating a data transaction contract associated with the data to be traded based on the assessed value, the method further includes: In response to the contract signing request from the data requester, obtain the asset information of the data requester; The asset information of the data demand side is compared with the appraised value to obtain a comparison result. The comparison result is used to indicate whether the asset information of the data demand side meets the appraised value. In response to the comparison result indicating that the asset information of the data requesting party meets the assessed value, the data transaction contract is signed.

[0009] In some implementations, after the comparison result indicates that the asset information of the data requester meets the assessed value and the data transaction contract is signed, the method further includes: Sensitive field detection is performed on the data to be traded to obtain a detection result, which is used to indicate whether the data to be traded contains sensitive field data. If the detection result indicates that the data to be traded contains sensitive field data, obtain the processing task of the data requesting party for the data to be traded; The processing task is executed locally at the data provider to obtain the task processing result; The task processing results are transmitted to the data requesting end.

[0010] In some embodiments, the method further includes: The target processing procedure of the data transaction contract is transformed using blockchain technology to obtain a data lineage graph. The data lineage graph is used to reflect the target processing procedure, which includes the data transaction contract and at least one of the data transaction contracts. The data lineage graph is verified based on a pre-set compliance knowledge base to obtain a verification result, which is used to indicate whether the target processing procedure is compliant. If the verification result indicates that the target processing procedure is compliant, an audit report for the data transaction contract is generated based on the regulatory requirements of the application scenario of the data to be traded at the data demand end.

[0011] To achieve the above objectives, a second aspect of this application provides a contract generation apparatus, the apparatus comprising: Receive a data transaction request sent by the data requester, the data transaction request being used to request data to be traded; In response to the transaction request, the ownership information of the data to be traded and the indicator information of multiple data value indicators are obtained. The ownership information is used to indicate the data ownership of the data to be traded, and each of the data value indicators is an indicator that has an impact on the data value of the data to be traded. The data access permissions of the data requesting end are matched with the data ownership of the data to be traded to generate a matching result. The matching result is used to indicate whether the data access permissions match the data ownership. In response to the matching result indicating that the data operation permission matches the data ownership, the data to be traded is evaluated in a multi-dimensional value assessment based on the indicator information of the multiple data value indicators to obtain the evaluated value of the data to be traded. Based on the assessed value, a data transaction contract associated with the data to be traded is generated.

[0012] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the contract generation method described in the first aspect.

[0013] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the contract generation method described in the first aspect.

[0014] To achieve the above objectives, embodiments of this application may provide a computer program product, wherein the instructions in the computer program product, when executed by the processor of an electronic device, cause the electronic device to implement the contract generation method described in the first aspect.

[0015] The contract generation method, apparatus, electronic device, and medium proposed in this application receive a data transaction request sent by a data requester, which requests the trading of data to be traded. In response to the transaction request, the method obtains the ownership information of the data to be traded and the indicator information of multiple data value indicators. The ownership information indicates the data ownership of the data to be traded, and each data value indicator is an indicator that affects the data value of the data to be traded. The method matches the data access permissions of the data requester with the data ownership of the data to be traded, generating a matching result. The matching result indicates whether the data access permissions match the data ownership. By screening the compliance of the data requester before the data transaction, the security and legality of the data transaction are ensured. Subsequently, in response to the matching result indicating the matching of data operation permissions and data ownership, a multi-dimensional value assessment is performed on the data to be traded based on the indicator information of multiple data value indicators, obtaining the assessed value of the data to be traded. This multi-dimensional value assessment avoids the bias of a single-dimensional assessment, making the assessment result more objective, accurate, and in line with the actual market value. Based on the assessed value, a data transaction contract associated with the data to be traded is generated. Therefore, by dynamically matching ownership information with data access permissions, the legality of transactions is ensured. At the same time, by combining multi-dimensional value assessment, transaction contracts adapted to the characteristics of medical data are generated, avoiding the risk of sensitive data leakage caused by generic templates, thereby improving the security of transaction data in the contract. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the contract generation method provided in an embodiment of this application; Figure 2 yes Figure 1 The flowchart in step S103 is shown below; Figure 3 This is another flowchart illustrating the contract generation method provided in this application embodiment; Figure 4 This is another flowchart illustrating the contract generation method provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the contract generation device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] With the digital transformation of the healthcare industry, medical data is increasingly being used in drug development, AI-assisted diagnosis, and health insurance actuarial science, leading to a significant increase in demand for its asset-based transactions. However, medical data transactions rely on data transaction contracts. Many contract generation methods use generic templates from other transactions, easily overlooking the sensitivity of medical data and failing to deeply adapt to its unique characteristics. This increases the risk of medical data breaches, resulting in insufficient security protection for the transaction data in the generated contracts.

[0021] Based on this, embodiments of this application provide a contract generation method, apparatus, electronic device, and medium, aiming to solve the problem that existing contract generation methods do not adequately protect the security of transaction data.

[0022] The contract generation method, apparatus, electronic device and medium provided in the embodiments of this application are specifically described through the following embodiments. First, the contract generation method in the embodiments of this application is described.

[0023] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0024] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0025] The contract generation method provided in this application relates to the field of data transactions. This contract generation method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the contract generation method, but is not limited to the above forms.

[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0027] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0028] Figure 1 This is a flowchart illustrating the contract generation method provided in this application embodiment. Please refer to [link / reference]. Figure 1 The contract generation method provided in this application embodiment may include, but is not limited to, steps S101 to S105.

[0029] Step S101: Receive a data transaction request sent by the data requesting end. The data transaction request is used to request data to be traded.

[0030] In this step, the data requester can be an enterprise, a medical research institution, etc., and there are no restrictions here.

[0031] A data transaction request is used to request the transaction of medical data to be traded. The request must include the type or identifier of the medical data to be traded, such as "electronic medical record data of type II diabetes patients of XX Hospital in 2023-2024", the identity identifier or qualification certificate of the data requester, such as the "Medical Device Clinical Trial Institution Qualification Certificate", and the intended use of the data, such as for the research and development of a predictive model for type II diabetes complications.

[0032] Step S102: In response to the transaction request, obtain the ownership information of the data to be traded and the indicator information of multiple data value indicators. The ownership information is used to indicate the data ownership of the data to be traded, and each of the data value indicators is an indicator that has an impact on the data value of the data to be traded.

[0033] In this step, ownership information refers to metadata used to describe the ownership of the data to be traded, which may include ownership, right of use (specific scenario / time / purpose), right to income, and right of management.

[0034] Data value indicators refer to a set of quantitative parameters that affect the value of data to be traded. Specifically, they can be implemented using preset indicators of scientific research value, data quality, compliance risk, and market dimensions, and are used to build a multi-dimensional evaluation model.

[0035] Step S103: Match the data access permissions of the data request end with the data ownership of the data to be traded, and generate a matching result. The matching result is used to indicate whether the data access permissions match the data ownership.

[0036] In this step, access permissions for the data requesting party must include permitted medical data types (e.g., limited to non-identifiable clinical data) and usage scenario restrictions (e.g., limited to internal research use only).

[0037] If the data requester's qualifications meet the intended use, the scope of permissions covers the data type to be traded, and the data to be traded has been effectively authorized by the patient, the matching result is "compliant matching"; if there are situations such as the patient not authorizing or the requester not having corresponding scientific research qualifications, it is judged as "non-compliant" and the transaction process is terminated.

[0038] Step S104: In response to the matching result indicating that the data operation permission matches the data ownership, perform a multi-dimensional value assessment on the data to be traded based on the indicator information of the multiple data value indicators to obtain the assessed value of the data to be traded.

[0039] In this step, multi-dimensional value assessment refers to the comprehensive value calculation of the transaction data based on indicator information from multiple independent dimensions. Specifically, it can be implemented using weighted summation or neural network models to avoid bias caused by single-dimensional assessment.

[0040] When using a weighted summation method to obtain the evaluation value, the weights of the indicators can be adjusted according to the application scenario of medical data. For example, in the drug development scenario, the weight of clinical relevance is set to 0.3, the weight of sample scarcity is set to 0.25, and the weight of completeness is set to 0.2; in the medical imaging AI training scenario, the weight of clinical relevance is set to 0.1, the weight of sample scarcity is set to 0.15, and the weight of completeness is set to 0.3.

[0041] It should be noted that the weights of different dimensions can be set according to the actual situation, and no restrictions are imposed here.

[0042] For example, the index values ​​of a certain diabetes follow-up data are: clinical relevance 92 points, annotation accuracy 88 points, traceability 95 points, timeliness 85 points, scarcity 78 points, and completeness 90 points, with corresponding weights of 0.3, 0.2, 0.15, 0.15, 0.1, and 0.1, respectively. The assessed value is calculated as follows: 92×0.3+88×0.2+95×0.15+85×0.15+78×0.1+90×0.1=27.6+17.6+14.25+12.75+7.8+9=89 points (assuming 1 point corresponds to 200 yuan, the assessed value is 17,800 yuan).

[0043] Step S105: Based on the assessed value, generate a data transaction contract associated with the data to be traded.

[0044] In this step, terms related to the transaction price, payment method, and payment schedule are generated in the data transaction contract based on the assessed value.

[0045] Furthermore, the ownership information of the transaction data in step S103 is converted into clauses related to data use, data security, and confidentiality in the data transaction contract.

[0046] As a preferred embodiment, the solution of this application is specifically implemented as follows: First, the system receives data transaction requests from data requesters. These requests might originate from medical research institutions, requesting the exchange of patient image datasets from a particular hospital.

[0047] Secondly, in response to a transaction request, obtain the ownership information and data value metrics of the data to be traded. Ownership information may include the data owner, usage restrictions, etc. Data value metrics may include data integrity, annotation quality, sample size, etc.

[0048] Then, the data access permissions of the data requesting party are matched with the ownership of the data to be traded. For example, it is necessary to check whether the research institution is qualified to process patient privacy data and whether it complies with data usage restrictions.

[0049] If the matching results show that the data operation permissions match the data ownership, a multi-dimensional value assessment will be conducted. The assessment may consider factors such as the data's scientific research value, data quality, and sample representativeness to determine the assessed value of the data to be traded.

[0050] Finally, based on the assessed value, a data transaction contract is generated. The contract may include clauses regarding the scope of data use, price, and confidentiality obligations to ensure the rights and interests of both parties.

[0051] In this implementation, a data transaction request is received from a data requester, requesting the trading of data to be traded. In response to the request, the ownership information and multiple data value indicators of the data to be traded are obtained. The ownership information indicates the data ownership of the data to be traded, and each data value indicator is an indicator that affects the data value of the data to be traded. The data access permissions of the data requester are matched with the data ownership of the data to be traded, generating a matching result. This matching result indicates whether the data access permissions match the data ownership. By screening the compliance of the data requester before the data transaction, the security and legality of the data transaction are ensured. Subsequently, in response to the matching result indicating the matching of data operation permissions and data ownership, a multi-dimensional value assessment is performed on the data to be traded based on the indicator information of multiple data value indicators, obtaining the assessed value of the data to be traded. This multi-dimensional value assessment avoids the bias of a single-dimensional assessment, making the assessment result more objective, accurate, and in line with the actual market value. Based on the assessed value, a data transaction contract associated with the data to be traded is generated. Therefore, by dynamically matching ownership information with data access permissions, the legality of transactions is ensured. At the same time, by combining multi-dimensional value assessment, transaction contracts adapted to the characteristics of medical data are generated, avoiding the risk of sensitive data leakage caused by generic templates, thereby improving the security of transaction data in the contract.

[0052] In some implementations, before generating a data transaction contract associated with the data to be traded based on the assessed value in step S105, the contract generation method provided in this application embodiment may include, but is not limited to, steps S201 to S203.

[0053] Step S201: Based on the ownership information of the data to be traded and the preset ownership change logic, determine the ownership change rules corresponding to the ownership information of the data to be traded.

[0054] Step S202: Generate an ownership transaction strategy for the data to be traded based on the ownership information and the ownership change rules.

[0055] Step S203: Generate a data transaction contract associated with the data to be traded based on the ownership transaction strategy and the assessed value.

[0056] In this implementation, the preset ownership change logic can be determined from the preset ownership change logic library. The ownership information of the data to be traded is matched in the preset ownership change logic library to obtain one or more ownership change rules applicable to the transaction. For example, if the data in the ownership information belongs to the medical institution and the patient's authorization is "research use authorization", then the ownership change rule is "only the data use right is transferred, the ownership still belongs to the medical institution, and the use right cannot be sublicensed".

[0057] In other implementations, ownership change rules can also be implemented through a pre-deployed smart contract group. The smart contract group stores and manages ownership change rules corresponding to different ownership information. Any ownership change (such as data transaction authorization, revenue sharing agreement taking effect, data processing role change) is triggered by preset contract logic, automatically updating the ownership status record during the transaction process and synchronously adjusting the ownership information.

[0058] The ownership transaction strategy integrates the current ownership status and change rules of the data to be traded, forming clauses that include the timeline for ownership transfer and the division of responsibilities. For example, if the data to be traded belongs to a top-tier hospital E, the patient's authorization is "exclusive authorization for drug development," and the ownership change rule is "only the right to use is transferred, sublicensing is prohibited," then the ownership transaction strategy specifically includes: the term of the right to use is consistent with the term of the data's intended use (e.g., 2 years); the scope of the right to use is limited to "only for the development of a new anti-cancer drug"; the data requester must submit a data usage progress report to hospital E every quarter; and all data copies must be destroyed or the data returned to hospital E upon the expiration of the right to use.

[0059] The ownership transaction strategy and valuation are added to the basic contract template for medical data to obtain a data transaction contract associated with the data to be traded.

[0060] For example, the most suitable contract template can be automatically matched from the contract template library based on the "authorized content" (such as research usage rights) and "scope of use" (such as scientific research) in the ownership transaction strategy.

[0061] Each strategy item in the ownership transaction strategy is automatically populated into the corresponding clause in the contract template. For example, "Strategy Item 1" is populated into "Article 1 Authorization Content", and "Strategy Item 3" is populated into "Article 3 Scope and Restrictions on Data Use".

[0062] By combining the assessed value (e.g., 500,000 yuan) with the "profit distribution" strategy item in the ownership transaction strategy, the "Article 4 Fees and Payments" clause in the contract is generated, which clarifies the total amount, payment method, and profit distribution ratio of each party.

[0063] Based on the requirements of "security and auditing" in the ownership transaction strategy, clauses such as "Article 5 Data Security and Confidentiality" and "Article 6 Auditing and Supervision" are automatically generated.

[0064] All the filled-in and generated terms, along with the fixed parts of the contract such as the preamble and signature page, are assembled into a complete, structured data transaction contract document.

[0065] In this implementation, ownership transfer rules and transaction strategies suitable for the data to be traded are generated based on the specific ownership status of the data. This leads to a more reasonable and secure data transaction contract, effectively protecting the privacy and security of medical data while meeting the needs of data transactions and reducing the risk of data leakage. Furthermore, by combining ownership transfer rules, transaction strategies, and assessed value, a more comprehensive and accurate data transaction contract can be generated, improving the contract's enforceability and compliance.

[0066] In some implementations, such as Figure 2 As shown, the indicator information of each data value indicator corresponds to a value assessment of one dimension, and the value assessment of each dimension corresponds to a preset dimension assessment rule. In step S103, based on the indicator information of multiple data value indicators, a multi-dimensional value assessment is performed on the data to be traded to obtain the assessed value of the data to be traded, which may include, but is not limited to, steps S301 to S304.

[0067] Step S301: Based on the indicator information of each data value indicator and the preset dimension evaluation rules corresponding to the indicator information, obtain the evaluation sub-value of the indicator information of each data value indicator.

[0068] Step S302: Obtain the application scenario of the data to be traded on the data demand side.

[0069] Step S303: Determine the weight corresponding to each evaluation sub-value based on the application scenario.

[0070] Step S304: Based on the evaluation sub-values ​​of the indicator information of each data value indicator and the weights corresponding to each evaluation sub-value, obtain the evaluation value of the data to be traded.

[0071] In this implementation, the preset dimension evaluation rules can be pre-defined scoring algorithms or quantitative models for each data value indicator. For example, the scientific research value dimension can be scored using parameters such as the number of citations and the level of the research institution, while the data quality dimension can be scored using parameters such as completeness and accuracy.

[0072] Application scenarios include various fields such as drug development, health insurance actuarial science, and AI-assisted diagnosis. Different scenarios have different focuses on the value of each dimension. For example, drug development scenarios focus more on scientific research value, while health insurance actuarial science scenarios focus more on market value.

[0073] The weights can be determined by setting a pre-defined scenario and a weight mapping table. For example, in the drug development scenario, the scientific research value weight is set to 0.6, the data quality weight is set to 0.3, and the compliance risk weight is set to 0.1.

[0074] Specifically, after calculating the sub-values ​​of each data value indicator, the weights of each sub-value are dynamically adjusted according to the application scenario of the data demand side. For example, when the application scenario is drug development, the weight of the scientific research value dimension is set to the highest, followed by the data quality dimension; when the application scenario is health insurance actuarial science, the weight of the market value dimension is increased to the main proportion. The final assessed value is obtained by multiplying each sub-value by its corresponding weight and summing them up using a weighted summation method. This process ensures that the value assessment results of the same data differ in different application scenarios, thus better aligning with actual transaction needs. For example, certain medical data may receive a high assessed value in a drug development scenario due to its outstanding scientific research value, but a lower assessed value in a health insurance actuarial science scenario due to insufficient market value. The resulting contract terms can accurately match the scenario requirements, avoiding unreasonable contract terms due to assessment bias.

[0075] In this implementation, by considering value indicators of different dimensions and adjusting the weights according to specific application scenarios, the evaluation results are more comprehensive and accurate, and can better reflect the actual value of medical data in different application scenarios. This provides a reliable value basis for the subsequent generation of data transaction contracts and helps to reduce pricing risks in medical data transactions.

[0076] In other implementations, the multi-dimensional value assessment includes at least two of the following: scientific research value assessment, data quality value assessment, compliance risk value assessment, and market value assessment.

[0077] Among them, the dimensions of scientific research value include indicators such as disease relevance (using medical ontology), data scarcity, sample size, follow-up duration, and richness of endpoint events.

[0078] Data quality dimensions include data integrity (field missing rate), accuracy (comparison with gold standard / logic verification), timeliness (data freshness), and consistency (cross-source comparison).

[0079] Compliance risk dimensions include assessing the level of data anonymization, identifiability risks, compliance with applicable regulations, and the integrity of the authorization chain.

[0080] Market dimensions include historical price trends for similar data transactions, demand intensity (frequency of searches / inquiries within the platform), data governance costs (storage, computing, and compliance audit expenses), and data activity (update frequency).

[0081] In some implementations, such as Figure 3 As shown, after generating a data transaction contract associated with the data to be traded based on the assessed value in step S105, the contract generation method provided in this application embodiment may also include, but is not limited to, steps S401 to S403.

[0082] Step S401: In response to the contract signing request from the data requester, obtain the asset information of the data requester.

[0083] Step S402: Compare the asset information of the data demand side with the assessed value to obtain a comparison result. The comparison result is used to indicate whether the asset information of the data demand side meets the assessed value.

[0084] Step S403: In response to the comparison result indicating that the asset information of the data requester meets the assessed value, the data transaction contract is signed.

[0085] In this implementation, asset information can be accessed via a pre-configured, secure API interface, connecting to the data requester's authorized account in a bank, third-party payment platform, or their corporate financial system to query available funds, credit limits, or specific asset certificates in real time. Asset certificates issued by authoritative institutions (such as banks or auditing firms), such as bank credit certificates, deposit certificates, or recent financial statements, can be uploaded by the data requester. By integrating OCR (Optical Character Recognition) and NLP (Natural Language Processing) technologies, key financial data in the documents can be automatically parsed.

[0086] After obtaining the asset information from the data demand side, it is compared with the appraised value of the data to be traded (or the contract amount converted from the appraised value) calculated in step S105 to obtain the comparison result. The comparison logic can be "available assets ≥ contract amount" or "available assets ≥ contract amount * preset ratio (such as 30%)", which is not specifically limited here.

[0087] If the comparison results indicate that the asset information of the data requester matches the assessed value, the contract signing process will proceed. If the comparison results indicate that the asset information of the data requester does not match the assessed value, the contract signing can be refused, and a prompt message will be returned to the data requester, such as: "Your account assets are insufficient to complete this transaction. Please ensure your account balance is sufficient or contact customer service for other payment options (such as installment payments, credit payments, etc.)." Simultaneously, this "verification failure" record (after anonymization) can be included in the data requester's platform credit profile as a reference for future assessments of their transaction risks.

[0088] For example, after confirming the contract content, pharmaceutical company C submits a contract signing request and uploads a bank deposit certificate issued by a joint-stock bank (showing available funds of 500,000 yuan); the 500,000 yuan in the deposit certificate is compared with the appraised value of 18,150 yuan, and it is determined to be "compliant". A signing notice is sent to hospital D; after hospital D confirms that the contract is correct, both parties complete the online signing through the blockchain electronic signing system. The signing record is uploaded to the blockchain for evidence storage in real time, and the contract becomes effective; electronic copies of the contract are sent to both parties, and the usage right status of the data to be traded is updated simultaneously (marked as "traded to pharmaceutical company C, usage right period 2024-2026").

[0089] In this implementation, asset verification on the data demand side improves the efficiency and accuracy of data transaction contract signing and reduces transaction risks.

[0090] In some implementations, after the asset information of the data requesting party meets the assessed value in response to the comparison result in step S403 and a data transaction contract is signed, the contract generation method provided in this application embodiment may also include, but is not limited to, steps S501 to S504.

[0091] Step S501: Perform sensitive field detection on the data to be traded to obtain detection results. The detection results are used to indicate whether the data to be traded contains sensitive field data. Step S502: If the detection result indicates that the data to be traded contains sensitive field data, obtain the processing task of the data requesting party for the data to be traded; Step S503: Execute the processing task locally on the data providing end to obtain the task processing result; Step S504: Transmit the task processing result to the data requesting end.

[0092] In this implementation, before the data transaction contract is signed and the data is transmitted, sensitive fields are checked in the data to be traded. These sensitive fields can be defined according to relevant laws, regulations, and standards in the medical industry. Specific methods for sensitive field detection include keyword matching, regular expression recognition, and AI-based sensitive information recognition models.

[0093] If the detection results indicate that the data to be traded contains sensitive fields, the data requester must perform specific processing tasks on this batch of data. These tasks must be consistent with the intended use stipulated in the contract, such as "patient efficacy correlation analysis" or "adverse reaction incidence statistics" in drug development scenarios, or "lesion region segmentation" in medical imaging AI training scenarios. Tasks must be submitted in a standardized format (e.g., Python scripts, SQL queries) and undergo compliance review by the data provider (reviewing whether data export instructions are included and whether the scope of use is exceeded). If the detection results indicate no sensitive fields, the data can be provided directly or transmitted encrypted, according to the contract.

[0094] Within the local secure environment of the data provider, the data to be traded and the acquired processing tasks are loaded and computations are performed. This local secure environment can be implemented using one or more of the following technologies: secure sandboxes, trusted execution environments, and federated learning nodes, etc.

[0095] Specifically, a security sandbox refers to creating an isolated, resource-constrained, and strictly controlled outbound network environment. Data and processing tasks are loaded into the sandbox, and during task execution, any high-risk operations such as external network access and file writing will be prohibited or audited. The sandbox is destroyed upon completion of the task.

[0096] A trusted execution environment (TEA) refers to a region within the CPU where processing tasks can be loaded and executed if the data provider's hardware supports it. The code and data within this region are invisible even to the operating system, providing hardware-level security.

[0097] A federated learning node refers to a data provider acting as a federated learning node when the task is model training. It uses local data to calculate model gradients or parameter updates, and only encrypts these updates (not the original data) before sending them back to the coordinator (which may be the data requester or a third-party platform) to participate in the aggregation of the global model.

[0098] After the task is completed, the task processing result is obtained. This result is data that has been cleaned, aggregated, abstracted, or modeled, and sensitive information that can directly or indirectly identify an individual has been completely removed. For example, the result could be a statistical value, a trained model file, or a feature matrix.

[0099] In this implementation, sensitive data leakage is prevented through sensitive field detection and encryption. Processing tasks are executed locally at the data provider, avoiding the transmission of raw sensitive data. Processing results are provided only to the data requester, effectively reducing the risk of medical data leakage and protecting patient privacy and data security.

[0100] In some implementations, such as Figure 4 As shown, the contract generation method provided in this application embodiment may also include, but is not limited to, steps S601 to S603.

[0101] Step S601: Use blockchain technology to transform the target processing process of the data transaction contract to obtain a data lineage graph. The data lineage graph is used to reflect the target processing process, which includes the data transaction contract and at least one of the data transaction contracts. Step S602: Verify the data lineage map based on a preset compliance knowledge base to obtain a verification result. The verification result is used to indicate whether the target processing procedure is compliant. Step S603: If the verification result indicates that the target processing procedure is compliant, an audit report of the data transaction contract is generated according to the regulatory requirements of the application scenario of the data to be traded at the data demand end.

[0102] In this implementation, after the data transaction contract is signed and executed, key information of the entire target processing process is recorded on the blockchain. This target processing process includes the data transaction contract itself, with the contract's hash value, the signing parties, the signing time, and core terms (such as data scope, ownership strategy, assessment value, and processing tasks) recorded as a single transaction on the blockchain. The data value assessment process records key parameters and results on the blockchain, including the assessment indicators, dimensional assessment rules, application scenarios, weight allocation, and final assessment value, ensuring transparency and immutability. The data security processing process records the results of sensitive field detection, the processing tasks submitted by the data requester (such as the hash value of the algorithm code), the startup and shutdown logs of the local execution environment, and the hash value of the task processing results, proving that the data processing was indeed completed in the data provider's local secure environment and that the original data was not leaked. The data delivery process records the time the task processing results were delivered to the data requester and the recipient's confirmation, forming a closed-loop delivery process.

[0103] By recording the structured process information in the form of transactions on the blockchain, and linking the blocks together through hash values, a data lineage graph is naturally formed. This data lineage graph graphically and immutably reflects the entire lifecycle of the data to be traded, from ownership confirmation, value assessment, contract signing, secure processing to final delivery. Any modification at any stage will result in changes to all subsequent hash values, making it easily identifiable and ensuring the integrity and reliability of the lineage graph.

[0104] The pre-built compliance knowledge base contains laws, regulations, policies, and best practices for different countries, regions, industries (especially the healthcare industry), and application scenarios. For example, the knowledge base may include rules such as: patient data used for clinical research must be de-identified and cannot contain direct identifiers; medical data transactions conducted in a country must be processed within that country.

[0105] By using a data lineage graph on the blockchain, each processing step, data field, and operation is compared and logically deduced against the rules in the compliance knowledge base to obtain verification results. For example, the records of the "sensitive field detection" step in the lineage graph are checked to see if direct identifiers such as "ID number" are detected; if so, the records of the "security processing" step are further checked to confirm whether the processing task is "model training" rather than "data export," thereby determining whether the compliance requirements of "de-identification" and "data not leaving the local machine" are met.

[0106] If the verification results indicate that the target processing process is compliant, based on the specific regulatory requirements corresponding to the application scenario of the data to be traded on the data demand side, relevant information is extracted, organized, and formatted from the blockchain data lineage map and compliance verification results to generate a standardized and detailed audit report. The audit report includes key information such as data access, ownership change, transaction execution, and compliance checks to ensure the compliance and credibility of the entire contract transaction.

[0107] Figure 5 This is a schematic diagram of the contract generation device provided in the embodiments of this application. Please refer to it. Figure 5 This application embodiment also provides a contract generation apparatus 800, which can implement the above-described contract generation method. The contract generation apparatus 800 includes: Data receiving module 801 is used to receive data transaction requests sent by the data requesting end, wherein the data transaction request is used to request data to be traded; The data acquisition module 802 is used to respond to the transaction request and acquire the ownership information of the data to be traded and the indicator information of multiple data value indicators. The ownership information is used to indicate the data ownership of the data to be traded, and each of the data value indicators is an indicator that has an impact on the data value of the data to be traded. The data matching module 803 is used to match the data access permissions of the data request end with the data ownership of the data to be traded, and generate a matching result. The matching result is used to indicate whether the data access permissions match the data ownership. The value assessment module 804 is used to respond to the matching result indicating that the data operation permission matches the data ownership, and to perform multi-dimensional value assessment on the data to be traded based on the indicator information of the multiple data value indicators to obtain the assessed value of the data to be traded. The contract generation module 805 is used to generate a data transaction contract associated with the data to be traded based on the assessed value.

[0108] In some embodiments, the contract generation apparatus 800 further includes: The first determining module is used to determine the ownership change rules corresponding to the ownership information of the data to be traded based on the ownership information of the data to be traded and the preset ownership change logic; The first generation module is used to generate an ownership transaction strategy for the data to be traded based on the ownership information and the ownership change rules. The second generation module is used to generate a data transaction contract associated with the data to be traded, based on the ownership transaction strategy and the assessed value.

[0109] In some implementations, the indicator information of each data value indicator corresponds to a value assessment of a dimension, and the value assessment of each dimension corresponds to a preset dimension assessment rule. Value assessment module 804 includes: The first evaluation submodule is used to obtain the evaluation sub-value of the indicator information of each data value indicator based on the indicator information of each data value indicator and the preset dimension evaluation rules corresponding to the indicator information. The first acquisition submodule is used to acquire the application scenarios of the data to be traded at the data demand end; The first determining submodule is used to determine the weight corresponding to each evaluation subvalue based on the application scenario. The second determining submodule is used to obtain the assessed value of the data to be traded based on the assessed subvalue of the indicator information of each data value indicator and the weight corresponding to each assessed subvalue.

[0110] In some implementations, the multi-dimensional value assessment includes at least two of the following: scientific research value assessment, data quality value assessment, compliance risk value assessment, and market value assessment.

[0111] In some embodiments, the contract generation apparatus 800 further includes: The first acquisition module is used to acquire the asset information of the data requester in response to the contract signing request from the data requester. The comparison module is used to compare the asset information of the data requester with the appraised value and obtain the comparison result. The comparison result is used to indicate whether the asset information of the data requester meets the appraised value. The signing module is used to sign the data transaction contract in response to the comparison result indicating that the asset information of the data requesting party meets the assessed value.

[0112] In some embodiments, the contract generation apparatus 800 further includes: The detection module is used to perform sensitive field detection on the data to be traded and obtain the detection result, which is used to indicate whether the data to be traded contains sensitive field data. An encryption module is used to encrypt the data to be traded when the detection result indicates that the data to be traded contains sensitive field data, so as to obtain encrypted data to be traded. The second acquisition module is used to acquire the data requester's processing task for the data to be traded. The processing module is used to execute the processing task locally at the data providing end and obtain the task processing result; The transmission module is used to transmit the task processing results to the data requesting end.

[0113] In some embodiments, the contract generation apparatus 800 further includes: A conversion module is used to convert the target processing procedure of the data transaction contract using blockchain technology to obtain a data lineage graph. The data lineage graph is used to reflect the target processing procedure, which includes the data transaction contract and at least one of the data transaction contracts. The verification module is used to verify the data lineage map based on a preset compliance knowledge base and obtain a verification result, which is used to indicate whether the target processing process is compliant. The third generation module is used to generate an audit report of the data transaction contract based on the regulatory requirements of the application scenario of the data to be traded at the data demand end, when the verification result indicates that the target processing procedure is compliant.

[0114] The specific implementation of the contract generation device 800 is basically the same as the specific implementation of the contract generation method described above, and will not be repeated here.

[0115] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described contract generation method. This electronic device can be any smart terminal, including desktop computers, tablets, mobile phones, and in-vehicle computers.

[0116] Please see Figure 6 , Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 902 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 using the contract generation method of the embodiments of this application. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0117] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described contract generation method.

[0118] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0119] Alternatively, this application embodiment can provide a computer program product for implementation, wherein the instructions in the computer program product, when executed by the processor of an electronic device, cause the electronic device to implement the contract generation method in the above embodiment.

[0120] The contract generation method, apparatus, electronic device, and medium provided in this application receive a data transaction request sent by a data requester, which requests the trading of data to be traded. In response to the transaction request, the method obtains the ownership information of the data to be traded and the indicator information of multiple data value indicators. The ownership information indicates the data ownership of the data to be traded, and each data value indicator is an indicator that affects the data value of the data to be traded. The method matches the data access permissions of the data requester with the data ownership of the data to be traded, generating a matching result. The matching result indicates whether the data access permissions match the data ownership. By screening the compliance of the data requester before the data transaction, the security and legality of the data transaction are ensured. Subsequently, in response to the matching result indicating the matching of data operation permissions and data ownership, a multi-dimensional value assessment is performed on the data to be traded based on the indicator information of multiple data value indicators to obtain the assessed value of the data to be traded. This multi-dimensional value assessment avoids the bias of a single-dimensional assessment, making the assessment result more objective, accurate, and in line with the actual market value. Based on the assessed value, a data transaction contract associated with the data to be traded is generated. Therefore, by dynamically matching ownership information with data access permissions, the legality of transactions is ensured. At the same time, by combining multi-dimensional value assessment, transaction contracts adapted to the characteristics of medical data are generated, avoiding the risk of sensitive data leakage caused by generic templates, thereby improving the security of transaction data in the contract.

[0121] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0122] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0123] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0124] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0125] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0126] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0127] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0128] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

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

[0131] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for generating contracts, characterized in that, The method includes: Receive a data transaction request sent by the data requester, the data transaction request being used to request data to be traded; In response to the transaction request, the ownership information of the data to be traded and the indicator information of multiple data value indicators are obtained. The ownership information is used to indicate the data ownership of the data to be traded, and each of the data value indicators is an indicator that has an impact on the data value of the data to be traded. The data access permissions of the data requesting end are matched with the data ownership of the data to be traded to generate a matching result. The matching result is used to indicate whether the data access permissions match the data ownership. In response to the matching result indicating that the data operation permission matches the data ownership, the data to be traded is evaluated in multiple dimensions based on the indicator information of the multiple data value indicators to obtain the evaluated value of the data to be traded. Based on the assessed value, a data transaction contract associated with the data to be traded is generated.

2. The method according to claim 1, characterized in that, Before generating a data transaction contract associated with the data to be traded based on the assessed value, the method further includes: Based on the ownership information of the data to be traded and the preset ownership change logic, determine the ownership change rules corresponding to the ownership information of the data to be traded; Based on the ownership information and the ownership change rules, an ownership transaction strategy for the data to be traded is generated; Based on the ownership transaction strategy and the assessed value, a data transaction contract associated with the data to be traded is generated.

3. The method according to claim 1, characterized in that, Each of the data value indicators corresponds to a value assessment of a dimension, and each value assessment of a dimension corresponds to a preset dimension assessment rule. The method of performing a multi-dimensional value assessment on the data to be traded based on the indicator information of the multiple data value indicators to obtain the assessed value of the data to be traded includes: Based on the indicator information of each data value indicator and the preset dimension evaluation rules corresponding to the indicator information, the evaluation sub-value of the indicator information of each data value indicator is obtained. Identify the application scenarios of the data to be traded on the data demand side; Based on the application scenario, determine the weight corresponding to each evaluation sub-value; The assessed value of the data to be traded is obtained based on the assessment sub-values ​​of the indicator information of each data value indicator and the weights corresponding to each assessment sub-value.

4. The method according to claim 1, characterized in that, The multi-dimensional value assessment includes at least two of the following: scientific research value assessment, data quality value assessment, compliance risk value assessment, and market value assessment.

5. The method according to claim 1, characterized in that, After generating a data transaction contract associated with the data to be traded based on the assessed value, the method further includes: In response to the contract signing request from the data requester, obtain the asset information of the data requester; The asset information of the data demand side is compared with the appraised value to obtain a comparison result. The comparison result is used to indicate whether the asset information of the data demand side meets the appraised value. In response to the comparison result indicating that the asset information of the data requesting party meets the assessed value, the data transaction contract is signed.

6. The method according to claim 5, characterized in that, After the comparison result indicates that the asset information of the data requester meets the assessed value and the data transaction contract is signed, the method further includes: Sensitive field detection is performed on the data to be traded to obtain a detection result, which is used to indicate whether the data to be traded contains sensitive field data. If the detection result indicates that the data to be traded contains sensitive field data, obtain the processing task of the data requesting party for the data to be traded; The processing task is executed locally at the data provider to obtain the task processing result; The task processing results are transmitted to the data requesting end.

7. The method according to claims 1-6, characterized in that, The method further includes: The target processing procedure of the data transaction contract is transformed using blockchain technology to obtain a data lineage graph. The data lineage graph is used to reflect the target processing procedure, which includes the data transaction contract and at least one of the data transaction contracts. The data lineage graph is verified based on a pre-set compliance knowledge base to obtain a verification result, which is used to indicate whether the target processing procedure is compliant. If the verification result indicates that the target processing procedure is compliant, an audit report for the data transaction contract is generated based on the regulatory requirements of the application scenario of the data to be traded at the data demand end.

8. A contract generation device, characterized in that, The device includes: The data receiving module is used to receive data transaction requests sent by the data requesting party, wherein the data transaction request is used to request data to be traded; The data acquisition module is used to respond to the transaction request and acquire the ownership information of the data to be traded and the indicator information of multiple data value indicators. The ownership information is used to indicate the data ownership of the data to be traded, and each of the data value indicators is an indicator that has an impact on the data value of the data to be traded. The data matching module is used to match the data access permissions of the data request end with the data ownership of the data to be traded, and generate a matching result. The matching result is used to indicate whether the data access permissions match the data ownership. The value assessment module is used to respond to the matching result indicating that the data operation permission matches the data ownership, and to perform multi-dimensional value assessment on the data to be traded based on the indicator information of the multiple data value indicators to obtain the assessed value of the data to be traded. The contract generation module is used to generate a data transaction contract associated with the data to be traded based on the assessed value.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the contract generation method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the contract generation method according to any one of claims 1 to 7.

Images