CN117112693A

CN117112693A - Data management method, device and system

Info

Publication number: CN117112693A
Application number: CN202310957164.2A
Authority: CN
Inventors: 余逸荣; 陈杭; 张�杰; 于杨; 魏长征
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2023-07-31
Filing date: 2023-07-31
Publication date: 2023-11-24

Abstract

One or more embodiments of the present disclosure provide a data management method, apparatus, and system. The method is applied to a blockchain system in a data management system, the data management system also comprises a data owner and a data acquirer, a data management contract deployed in the blockchain system records acquisition rules and use rules of target data belonging to the data owner, and the method comprises the following steps: in response to receiving data acquisition information for target data submitted by a data acquirer, executing a data management contract to determine whether the data acquisition information meets an acquisition rule; determining data usage information for the target data and executing a data management contract to determine whether the data usage information satisfies a usage rule; if the data acquisition information meets the acquisition rule and/or the data use information meets the use rule, the credential information aiming at the target data is transmitted to the data acquirer and used for indicating the data acquirer to assist the data acquirer in acquiring the target data and/or the operation result thereof.

Description

Data management method, device and system

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method, an apparatus, and a system for data management.

Background

In the related art, if a data processing party needs to use data held by a data owner, a request for the data needs to be initiated to the data owner, so that related personnel of the data owner verify whether the data processing party meets all authorization conditions of the data requested by the data processing party one by one, and then determine whether to authorize the data processing party for processing and using the data.

Because the mode usually needs to manually verify whether the data processing party meets the authorization condition of the data requested by the data processing party, on one hand, the communication and interaction modes are tedious and inefficient, and the efficient authorization of the data held by the data all parties is not facilitated; on the other hand, the data owner often has difficulty in disclosing the use condition of the data and a specific verification process, and the verification process has the possibility of camera bellows operation, so that the reliability of data authorization is low.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a data management method, apparatus, and system.

In order to achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, there is provided a data management method applied to a blockchain system in a data management system, the data management system further including a data owner and a data acquirer, a data management contract deployed in the blockchain system recording an acquisition rule and a usage rule of target data, the target data being attributed to the data owner, the method comprising:

Executing the data management contract in response to receiving data acquisition information submitted by the data acquirer and aiming at the target data, wherein the data management contract is used for judging whether the data acquisition information meets the acquisition rule or not;

determining data usage information for the target data and executing the data management contract for judging whether the data usage information satisfies the usage rule;

and under the condition that the data acquisition information meets the acquisition rule and/or the data use information meets the use rule, transmitting credential information aiming at the target data to the data acquirer, wherein the credential information is used for indicating the data acquirer to assist the data acquirer to acquire the target data and/or an operation result obtained after preset operation is performed on the target data.

According to a second aspect of one or more embodiments of the present specification, there is provided a data management system including a blockchain system, a data owner, and a data acquirer, a data management contract deployed in the blockchain system having recorded therein acquisition rules and usage rules for target data, the target data attributed to the data owner, wherein,

The data acquirer is used for submitting data acquisition information aiming at the target data to the blockchain system;

the blockchain system is used for executing the data management contract, and the data management contract is used for judging whether the data acquisition information meets the acquisition rule or not; determining data usage information for the target data and executing the data management contract for judging whether the data usage information satisfies the usage rule; and transmitting credential information for the target data to the data acquirer in case the data acquisition information satisfies the acquisition rule and/or the data usage information satisfies the usage rule;

the data owner is configured to assist the data acquirer to obtain the target data and/or an operation result obtained after performing a preset operation on the target data when receiving the credential information provided by the data acquirer.

According to a third aspect of one or more embodiments of the present specification, there is provided a data management apparatus applied to a blockchain system in a data management system, the data management system further including a data owner and a data acquirer, a data management contract deployed in the blockchain system recording acquisition rules and usage rules of target data to which the target data belongs, the apparatus comprising:

A first execution unit, configured to execute the data management contract in response to receiving data acquisition information for the target data submitted by the data acquisition party, where the data management contract is configured to determine whether the data acquisition information meets the acquisition rule;

a second execution unit configured to determine data usage information for the target data and execute the data management contract for judging whether the data usage information satisfies the usage rule;

the information transmission unit is used for transmitting the credential information aiming at the target data to the data acquisition party under the condition that the data acquisition information meets the acquisition rule and/or the data use information meets the use rule, and the credential information is used for indicating the data owner to assist the data acquisition party to acquire the target data and/or an operation result obtained after the data acquisition party performs preset operation on the target data.

According to a fourth aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect by executing the executable instructions.

According to a fifth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first aspect.

The data management system comprises a blockchain system, a data owner and a data acquirer, wherein a data management contract is deployed in the blockchain system, and acquisition rules and usage rules of target data belonging to the data owner are recorded in the contract. The blockchain network responds to receiving data acquisition information aiming at the target data submitted by the data acquisition party, and executes the data management contract to judge whether the data acquisition information meets the acquisition rule or not; in addition, determining data usage information for the target data and executing the data management contract for determining whether the data usage information satisfies the usage rule; and when the data acquisition information meets the acquisition rule and/or the data use information meets the use rule, transmitting credential information aiming at the target data to the data acquisition party, wherein the credential information is used for indicating a data owner to assist the data acquisition party in acquiring the target data and/or an operation result obtained after preset operation is performed on the target data.

Therefore, the scheme records the acquisition rule and the use rule of the target data in the data management contract deployed by the blockchain system, verifies whether the data acquisition information submitted by the data acquirer meets the acquisition rule or not by the contract, verifies whether the corresponding data use information meets the use rule or not, and further determines whether credential information for acquiring the target data or the calculation result thereof is transmitted to the data acquirer or not according to the verification result, namely, the blockchain system and the data management contract deployed on the blockchain system are utilized to realize on-chain automation and refinement authorization of the target data. On one hand, the acquisition rule and the use rule of the target data are recorded in a data management contract deployed on a chain, and authorization of the target data is completed on the chain by a blockchain system based on the contract, so that the data management burden of a data owner in the data authorization process is remarkably reduced, and the data authorization efficiency is improved. On the other hand, the acquisition rules and the usage rules of the target data are recorded in the data management contract to realize disclosure, so that each related party (such as a data acquirer) in the data authorization process can flexibly look up the rules; and whether the verification data acquisition information meets the acquisition rule, whether the verification data use information meets the use rule and the like are finished by intelligently closing on the chain, so that the verification process and the verification result can be publicly and transparently stored on the chain, the camera bellows operation possibly generated by under-chain verification can be avoided, and the transparency and the credibility of the data authorization process are improved.

Drawings

FIG. 1 is a schematic diagram of an exemplary environment provided by an exemplary embodiment.

Fig. 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment.

Fig. 3 is a flow chart of a data management method provided in an exemplary embodiment.

Fig. 4 is a schematic diagram of a data management system according to an exemplary embodiment.

Fig. 5 is a schematic diagram of an apparatus according to an exemplary embodiment.

Fig. 6 is a block diagram of a data management apparatus according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

FIG. 1 is a schematic diagram of an exemplary environment provided by an exemplary embodiment. As shown in fig. 1, the example environment 100 allows entities to participate in a blockchain network 102. The blockchain network 102 may be a public-type, private-type, or federated-type blockchain network. The example environment 100 may include computing devices 104, 106, 108, 110, 112 and a network 114; in an embodiment, the network 114 may include a local area network (Local Area Network, LAN), a wide area network (Wide Area Network, WAN), the internet, or a combination thereof, and is connected to websites, user devices (e.g., computing devices), and backend systems. In an embodiment, any computing device may access network 114 through wired and/or wireless communication.

In some cases, the computing devices 106, 108 may be nodes of a cloud computing system (not shown in the figures), or each computing device 106, 108 may be a separate cloud computing system, including multiple computers interconnected by a network and operating as a distributed processing system.

In one embodiment, the computing devices 104-108 may run any suitable computing system that enables it to function as a node in the blockchain network 102; for example, computing devices 104-108 may include, but are not limited to, servers, desktop computers, notebook computers, tablet computing devices, smart phones, wearable devices, and the like. In an embodiment, the computing devices 104-108 may be attributed to related entities and used to implement corresponding services, e.g., the services may be used to manage transactions between an entity or entities.

In one embodiment, computing devices 104-108 each store a blockchain ledger corresponding to blockchain network 102. The computing device 104 may be (or include) a web server for providing browser functionality that may provide visual information related to the blockchain network 102 based on the network 114. In some cases, the computing device 104 may not participate in the blockchain verification, but rather monitor the blockchain network 102 to determine when other nodes (which may include computing devices 106-108, for example) agree on, and generate corresponding blockchain visual user interfaces therefrom.

In an embodiment, computing device 104 may receive a request initiated by a client device (e.g., computing device 110 or computing device 112) for a blockchain visualization user interface. In some cases, a node of the blockchain network 102 may also act as a client device, such as a user of the computing device 108 may send the request to the computing device 104 using a browser running on the computing device 108.

In response to the request, computing device 104 may generate a blockchain visualization user interface (e.g., a web page) based on the stored blockchain ledger and send the generated blockchain visualization user interface to the requesting client device. If the blockchain network 102 is a private-type or federated-type blockchain network, the request for the blockchain visualization user interface may include user authorization information that may be verified by the computing device 104 before the blockchain visualization user interface is generated and sent to the requesting client device and returned to the corresponding blockchain visualization user interface after verification passes.

The blockchain visualization user interface may be displayed on the client device (e.g., may be displayed in the user interface 116 shown in fig. 1). When the blockchain ledger is updated, the display of the user interface 116 may also be updated accordingly. Further, user interaction with the user interface 116 may result in a request for other user interfaces, such as displaying a blocklist, blocklist details, transaction list, transaction details, account list, account details, contract list, contract details, or search results page generated by a user conducting a search over a blockchain network, or the like.

Fig. 2 is a schematic diagram of a conceptual architecture provided by an exemplary embodiment. As shown in fig. 2, the conceptual architecture 200 includes a physical layer 202, a hosted services layer 204, and a blockchain network layer 206. For example, the entity layer 202 may include three entities: entity 1, entity 2, and entity 3, each having a respective transaction management system 208.

In an embodiment, hosted services layer 204 may include a corresponding interface 210 for each transaction management system 208. For example, each transaction management system 208 communicates with a respective interface 210 over a network (e.g., network 114 in FIG. 1) using a protocol (e.g., hyperText transfer protocol Security (HTTPS), etc.). In some examples, each interface 210 may provide a communication connection between a respective corresponding transaction management system 208 and the blockchain network layer 206; more specifically, the interface 210 may communicate with a blockchain network 212 of the blockchain network layer 206. In some examples, communication between the interface 210 and the blockchain network layer 206 may be implemented using remote procedure calls (Remote Procedure Call, RPC). In some examples, interface 210 may provide an API interface to transaction management system 208 for accessing blockchain network 212.

In one embodiment, blockchain network 212 is provided in the form of a peer-to-peer network that includes a plurality of nodes 214, each node 214 for persisting a blockchain ledger 216 formed from blockchain data; where only one blockchain ledger 216 is shown in fig. 2, there may be multiple blockchain ledgers 216 or copies thereof in the blockchain network 212, such as each node 214 may maintain one blockchain ledger 216 or copy thereof, respectively.

It should be noted that: the transaction (transaction) described in this specification refers to a piece of data that a user creates through a client of the blockchain and needs to be eventually published into a distributed database of the blockchain. Among the transactions in the blockchain are narrow transactions and broad transactions. A narrow transaction refers to a transfer of value issued by a user to a blockchain; for example, in a conventional blockchain network, the transaction may be a transfer initiated by the user in the blockchain. And generalized transaction refers to a business data with business intention issued by a user to a blockchain; for example, the operator may build a federation chain based on actual business requirements, rely on the federation chain to deploy some other types of online business (e.g., rental business, vehicle dispatch business, insurance claim business, credit service, medical service, etc.) unrelated to value transfer, and in such federation chains, the transaction may be a business message or business request with business intent issued by the user in the federation chain.

Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. Among them, the highest degree of decentralization is the public chain. Wherein participants joining the public chain can read data records on the chain, participate in transactions, compete for billing rights for new blocks, and the like. Moreover, each participant (i.e., node) is free to join and leave the network and perform related operations. The private chain is the opposite, the write rights of the network are controlled by an organization or organization, and the data read rights are specified by the organization. In short, the private chain may be a weakly centralized system with few and strict restrictions on participating nodes. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.

Whether public, private, or federation, it is possible to provide the functionality of a smart contract. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes.

Taking the ethernet as an example, a user is supported to create and invoke some complex logic in the ethernet network. At the heart of the ethernet as a programmable blockchain is an Ethernet Virtual Machine (EVM), which can be run by each ethernet node. The EVM is a graphics-complete virtual machine, meaning that various complex logic can be implemented by it. The intelligent contracts that the user publishes and invokes in the ethernet network are run on the EVM. The blockchain node can be regarded as being deployed in the Ethernet network after any intelligent contract is issued on the Ethernet network.

In the blockchain field, an important concept is also Account (Account); taking an ethernet as an example, the ethernet generally divides accounts into two types, an external account and a contract account; the external account is an account directly controlled by the user, and is also called a user account; the contract account is an account (i.e., smart contract) that is created by the user through an external account and contains a contract code. Of course, for some blockchain models derived based on the ethernet-based architecture, the account types supported by the blockchain can be further expanded, and are not particularly limited in this specification.

For accounts in a blockchain, the account status of the account is typically maintained by a structure. When a transaction in a block is executed, the status of the account in the blockchain associated with the transaction will typically change.

In one example, the structure of an account typically includes fields such as Balance, nonce, code, and Storage. Wherein:

a Balance field for maintaining a current account Balance of the account;

a Nonce field for maintaining a number of transactions for the account; the counter is used for guaranteeing that each transaction can be processed only once, and effectively avoiding replay attack;

a Code field, for a contract account, a contract Code typically used to maintain the account; in practical applications, only the hash value of the contract Code is usually maintained in the Code field; thus, the Code field is also commonly referred to as a Codehash field. While for external accounts the Code field is typically empty.

A Storage field for maintaining the stored contents of the account (default field value is null); for a contract account, a separate storage space is generally allocated to store the storage content of the contract account, such as status data generated by executing the contract; this separate storage space is commonly referred to as the account store for the contract account.

The storage content of the contract account is usually stored in the independent storage space in a data structure constructed as a MPT (Merkle Patricia Trie) tree; among them, the MPT tree constructed based on the stored contents of the contract account is also commonly referred to as Storage tree. Whereas the Storage field typically only maintains the root node of the Storage tree; thus, the Storage field is also commonly referred to as a Storage root field.

In view of the technical problems in the related art, the present specification proposes a data management scheme. In the scheme, a mode of deploying and executing a data management contract in a blockchain system is adopted to verify whether data acquisition information related to target data meets the acquisition rule of the target data recorded in the contract and whether data use information meets the use rule of the target data recorded in the contract so as to determine whether credential information for indicating a data owner to assist the data acquirer to acquire the data acquirer and/or an operation result thereof is transmitted to the data acquirer, so that on-chain automation and refined authorization of the target data are realized. The technical scheme of the present specification is described below with reference to examples.

Fig. 3 is a flow chart of a data management method provided in an exemplary embodiment. As shown in fig. 3, the method is applied to a blockchain system in a data management system, the data management system further comprises a data owner and a data acquirer, and a data management contract deployed in the blockchain system records acquisition rules and usage rules of target data, wherein the target data belongs to the data owner. The method comprises steps 302-306.

In step 302, in response to receiving the data acquisition information submitted by the data acquirer and aiming at the target data, executing the data management contract, wherein the data management contract is used for judging whether the data acquisition information meets the acquisition rule.

In an embodiment, the blockchain system may include only a blockchain network of blockchain points, or may include a blockchain network and its associated BaaS (Backend as a Service ) platform (composed of computing devices such as servers). There may be one or more pieces of managed data belonging to the data owners, where in the case where there are multiple pieces, the multiple pieces of managed data may be independent of each other, or there may be any form of association relationship, which is not limited in this specification. In addition, one or more pieces of managed data may constitute one data set (i.e., the managed data is managed in the manner of a data set), and multiple pieces of managed data belonging to a data owner may constitute one or more data sets, which are also considered to belong to the data owner. In the case of composing a plurality of data sets, the intersection between any two of the data sets may be an empty set (i.e., the two data sets each contain managed data that are different from each other), or the intersection may be a proper subset of the two data sets (i.e., the two data sets each contain partially identical managed data).

In one embodiment, the managed data belonging to the data owner may be maintained by the data owner itself, such as storing the managed data in a local storage space of the data owner or in a storage space such as a database having a network connection with the data owner. Alternatively, the managed data may be maintained by a pre-set (e.g., as specified by the data owner) hosting party, such as by the hosting party, in a pre-set storage space associated with the hosting party (e.g., the hosting party's local storage space, or a database managed thereby, etc.). As a manager of the managed data, a data owner or the host may perform appropriate read/write processing on the managed data to implement management operations such as adding, deleting, modifying, querying, and the like on the managed data.

For all managed data attributed to a data owner, the data owner may grant at least some of the managed data therein to other interested parties (e.g., data acquirers) for use, the part of the managed data being referred to as the authorizable data. In this scheme, the data owner may record the acquiring rule and the usage rule of the authorizable data in the data management contract maintained by the blockchain system, based on which, the relevant party (such as the data acquirer) who wants to acquire and use the authorizable data may submit (for the target data in the authorizable data) data acquiring information corresponding to the acquiring rule to the blockchain system, so as to acquire credential information (specifically, the acquiring credential, the usage credential or the comprehensive credential) for the part of the target data, which is penetrated by the blockchain system, and further acquire the target data and/or the calculation result thereof from the data owner using the information. It can be seen that the data acquirer can request to acquire authorization for one or more of the authorizable data, and the one or more authorizable data requested by the data acquirer is the target data described in the specification. In other words, the target data in this specification is one or more pieces of authorized data (actually, managed data belonging to the data owner) belonging to the data owner, which are acquired by the data acquirer. In the case that the managed data belonging to the data owner constitutes a data set, if the target data includes only one data, the data belongs to a certain data set; and if the target data comprises a plurality of data, these data may belong to one or more data sets.

It should be noted that: any data in the "managed data", "authorized data" and "target data" described in this specification should be understood as a broad concept, such as a numerical value, a word, an image, audio, video, a code, a program, a model (such as an artificial intelligence model), and the like, which is not limited in this specification.

For the authorized data belonging to the data owner, the acquisition rules and the use rules of the authorized data can be recorded in a data management contract deployed in the blockchain system; in view of the fact that the target data is at least part of said authorizable data, the acquisition rules and usage rules of the target data may naturally also be recorded in the contract. Because the subsequent blockchain system needs to execute the data management contract to determine whether the relevant information of the target data (i.e., the data acquisition information and the data usage information) satisfies the corresponding rules (i.e., the acquisition rules and the usage rules), the data owner can configure the corresponding rules for the target data in the data management contract in advance before the blockchain system executes the data management contract. The rule configuration process for the target data is not substantially different from the rule configuration process for any one of the authorizable data, and the rule configuration process for any one of the authorizable data is described below as an example.

Under the condition that the managed data belonging to the data owner can be authorized to other related parties for use (namely, the data is determined to be the authorized data), the data owner can determine the acquisition rule and the use rule corresponding to any authorized data according to a preset plan, a sharing requirement, an authorized willingness and/or the data type of target data. Of course, rules for multiple authorizable data may be determined and configured in batches.

The acquisition rules for any of the authorizable data may include a plurality of rules. For example, a list of algorithms may be included, the algorithms recorded in the list of algorithms being used to characterize a processing algorithm that the data acquirer is permitted to implement on the data, i.e., the data acquirer (after acquiring authorization for any of the authorizable data) is authorized to process any of the authorizable data using the processing algorithm. The processing algorithm may include, but is not limited to, a hash algorithm, a privacy intersection algorithm, an encryption/decryption algorithm, and the like, and any processing algorithm may be specifically an algorithm formula or an algorithm identifier, which is not described herein. For another example, the acquisition rules may also include a range of credit scores to ensure that only data acquisitors whose credit scores at a preset platform meet the range can be authorized to acquire the data. Therefore, the credit scoring range can be set in a higher interval, so that some data acquirers with excellent credit can be effectively controlled to acquire the authorization of any one of the authorizable data, and the authorized data can be processed according to the requirements of all data parties as much as possible.

In addition to the above algorithm list and the credit score range, the acquiring rule may further include a region range (corresponding data acquiring information may include geographical location information of the data acquirer), a number segment (corresponding data acquiring information may include an identity serial number and a network address of the data acquirer), and the specific content of the acquiring rule may be reasonably set by the data owner according to the requirement of the data owner on the target data, which is not limited in this specification. Of course, the acquisition rule may include at least one of the above-mentioned various rules, for example, may include only one of the algorithm list and the credit score range, or may include both of them. For example, any of the acquisition rules of the authorized data Di may be "data Di, privacy intersection and hash calculation, and the credit score is not less than 800 points", which indicates that the data Di can only be authorized to the data acquirer with the credit score not less than 800 points for privacy intersection calculation.

Similarly, the usage rules for any of the authorizable data may also include a plurality of rules. For example, a credential validity period (the corresponding data usage information may include a current time, a time of receipt of the acquisition credential at a time of receipt of the data acquisition information), a maximum number of uses (the corresponding data usage information may include a total number of times the blockchain system receives the usage credential or the data acquisition information submitted by the data acquisition party), a valid frequency range (the corresponding data usage information may include a current frequency at which the blockchain system receives the usage credential or the data acquisition information), and the like. Specific information may be referred to below for judging whether the data usage information satisfies the relevant embodiment of the usage rule, which is not described herein.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.

In view of the fact that the number of target data that a data acquirer requests to acquire authorization may be plural (i.e., the target data may include plural authorizable data), in order to facilitate accurate determination of the requested target data and its associated rules, the data owner may implement configuration of the data and its associated rules by configuring correspondence between data identifications of the authorizable data and the associated rules in the data management contract. The data owners may submit the above-mentioned correspondence of the plurality of authorizable data in batches, so as to configure the correspondence in batches in the same data management contract. The plurality of data which can be authorized can have an association relationship, such as type data, data generated in the same way, data of the same batch generated within a period of time, and the like, and the batch management and batch authorization of the data can be realized by disposing the acquisition rules corresponding to the (similar) data with the association relationship in the same data management contract, so that the data management and authorization efficiency can be improved.

Taking any one of the data that can be authorized as an example, the corresponding relationship between the data identifier of any one of the data that can be authorized and the rule for obtaining the data is called a first corresponding relationship, and the corresponding relationship between the data identifier of any one of the data that can be authorized and the rule for using the data is called a second corresponding relationship. The data owner can submit the first corresponding relation and/or the second corresponding relation to the blockchain network so that the blockchain network can complete configuration. For example, the first correspondence relationship and the second correspondence relationship may be either submitted, or may be submitted simultaneously, and the present specification is not limited thereto. The submitted first corresponding relation comprises the data identifier of any one of the authorized data and the acquisition rule of the data; similarly, the submitted second correspondence includes the data identifier of any one of the authorizable data and the usage rule of the data.

According to the different structures of the blockchain system, the data owners can flexibly submit the corresponding relation (namely the first corresponding relation and/or the second corresponding relation) of any one of the authorizable data in a corresponding mode. For example, in the case where the blockchain system includes only a blockchain network, the data owner may initiate a contract deployment transaction including the correspondence described above directly to the blockchain nodes in the network (through the client device used by itself), so that each node may deploy a data management contract including the correspondence in the blockchain system by executing the transaction. For another example, in the case where the blockchain system includes a blockchain network and a BaaS platform, the data owner may initiate (through the client device used by itself) a contract deployment request including the correspondence to the BaaS platform, so that the BaaS platform initiates, in response to the request, a contract deployment transaction including the correspondence to a blockchain node in the blockchain system, and each node deploys a data management contract including the correspondence in the blockchain system by executing the transaction. It can be seen that in different ways of submission, the client device used by the data owner may implement different functions.

Since the block chain system may have already been deployed with the data management contract when the correspondence is received, the received acquisition rule may be configured in different manners depending on whether the data management contract is deployed or not.

For example, if a data management contract has not been deployed in the blockchain system, the blockchain system may deploy the data management contract containing the correspondence on the chain. In this way, configuration of the acquisition rules can be achieved while deploying the data management contract, simplifying contract processing logic. For another example, if the blockchain system has already deployed a data management contract, the blockchain system may configure the received correspondence in the (already deployed) data management contract. The contract may be pre-deployed by any relevant party (such as a data owner, baaS platform or other independent third party, etc.), and the pre-deployed contract may not record any corresponding relationship of data, or the pre-deployed contract may also record in advance (before configuring the received corresponding relationship) a corresponding relationship attributed to any data owner (possibly including the data owner). In this way, the data owner can configure the corresponding relation of any one of the authorizable data in the pre-deployed data management contract, so that the corresponding relation is newly added in the contract or the existing corresponding relation is updated, and flexible configuration and management of rules are realized.

When a data management contract has been deployed in the blockchain system, for any data identifier of the authorizable data and its corresponding rule (when the any corresponding relationship is a first corresponding relationship, the rule is an acquisition rule, and when the any corresponding relationship is a second corresponding relationship, the rule is a usage rule) included in any corresponding relationship, the any corresponding relationship can be configured in the contract in a corresponding manner according to the data identifier and the record condition of the rule in the contract.

If the data identification of any one of the authorized data and the rule in any corresponding relation are not recorded in the data management contract, the corresponding relation is newly added in the data management contract;

if the data identifier of any one of the authorized data is recorded in the data management contract, updating the corresponding rule corresponding to the data identifier in the data management contract by using the rule in any corresponding relation;

and if the rule in any corresponding relation is recorded in the data management contract, adding the data identifier in any corresponding relation into the identifier set corresponding to the rule in the data management contract.

For example, if the data identifier of any one of the authorizable data and the rule in any one of the corresponding relationships are not recorded in the data management contract, the corresponding relationship may be newly added in the data management contract, that is, the rule corresponding to the data identifier of any one of the authorizable data is newly added in the contract, so that the whole of any one of the corresponding relationships is newly added. For another example, if the data identifier of any one of the data that can be authorized is already recorded in the data management contract, the rule in any one of the corresponding relationships may be used to update the corresponding rule corresponding to the data identifier in the data management contract, that is, the corresponding rule already recorded in the data management contract (corresponding to any one of the data that can be authorized) is updated to the rule in any one of the corresponding relationships, so that the update of the existing rule is realized. For another example, if a rule in any of the corresponding relationships is already recorded in the data management contract, the data identifier in the corresponding relationship (i.e., the data identifier of any one of the authorizable data) may be added to the identifier set corresponding to the rule in the data management contract, so that the data identifier included in any one of the corresponding relationships may be added to the contract.

Table 1 below provides a table of correspondence between data identifiers of the authorizable data and their corresponding rules recorded in a data management contract according to an exemplary embodiment. Among the correspondence relationships recorded in table 1, the first correspondence relationship-g is as follows: the Relation-g1 is ' Data 1', the Relation-g 1' is ' Data2 ', the Relation-g2 ' is ' Data2 ', the Relation-g3 ' is ' Data3 ', the Relation-g2 ' is ' Data4 ', the Relation-g4 ' is ' Data4 ', the Relation-g3 ' is ' Data5 ' and the Relation-g5 ' is ' Rule-g4 '; the second correspondence relationship-u is as follows: the Relation-u1 is "Data 1", the Relation-u1 "is" Data 2", the Relation-u2 is" Data 2", the Relation-u 1" is "Data 3", the Relation-u2 "is" Data 4", the Relation-u4 is" Data 4", the Relation-u 3" is "Relation-u 5 is empty (may not be set or is emptied after being set). As can be seen, the set of identifications corresponding to Rule-g2 includes Data2 and Data3, and the set of identifications corresponding to Rule-u1 includes Data1 and Data2.

TABLE 1

For example, if there is no corresponding Relation between the authorizable Data6 and the acquisition Rule thereof in the current table 1, the blockchain system may add a Relation-g6 in table 1 when the first corresponding Relation-g6 submitted by the blockchain system in all directions of the Data is "Data6 and Rule-g 5". And/or, if all parties of the Data submit a Relation-u6 as "Data6, rule-u5", the blockchain system may also add the Relation-u6 in table 1. Of course, the first correspondence and the second correspondence of the same authorizable Data may be submitted together to reduce the number of times of submission, and the Data owner may submit "Data6, rule-g5, rule-u5" so that the blockchain network configures the relationship-g 6 and the relationship-u 6, respectively. For another example, for the existing correspondence Relation-g1 in table 1, if the Data owner submits that the Relation1' is "Data1, rule4", rule1 corresponding to Data1 in table 1 may be updated to Rule4. For another example, for the acquisition Rule2 already existing in table 1, if the Data owner submits that the Relation6 is "Data6, rule2", data6 may be added to the tag set corresponding to Rule2 in table 1, and after updating, the new tag set corresponding to Rule2 includes Data2, data3 and (newly added) Data6.

It should be noted that the contents shown in table 1 above are only exemplary, and table 1 may be maintained in any suitable form in the data management contract, for example, in the form of key-vcule (key-value) pairs, which is not limited in this specification.

As previously described, the smart contract has a corresponding contract account in the blockchain system. For a data management contract, any of the foregoing correspondence may be recorded in the account store of its contract account as state data for the contract, such as in the Storage field of the contract account (as a value for that field). In fact, in addition to the fields of the above-mentioned Balance, nonce, code, storage, etc., the contract account may further include other fields, such as a custom field, etc., in which any of the foregoing correspondence relationships may be stored, and the Storage location of the correspondence relationship related to the authorizable data in the contract account is not limited in this specification.

So far, the configuration process of the corresponding relation related to any one of the authorized data is introduced. The data management system shown in FIG. 4 includes a data owner, a data acquirer, and a blockchain system. The blockchain system is provided with a data management contract, the contract records a data identifier of the authorized data (including the target data) belonging to the data owner, and a first corresponding relation and a second corresponding relation related to the authorized data, and the corresponding relations can be configured by the data owner through the mode of the embodiment.

In addition to the data identification of the authorizable data and its associated correspondence, the data management contract may also record information about the authorizable data for viewing by the data acquirer having the acquisition requirement. Wherein the related information may include meta information including, but not limited to, data name, data size, data type, etc. In addition, the related information may further include exemplary data (or referred to as typical data and sample data), for example, for a plurality of data sets formed by the authorizable data, the exemplary data of each data set may be recorded in the data management contract, where the exemplary data of any data set is used to embody the data characteristic of the authorizable data in the data set (the data characteristic may be a common characteristic or at least a part of typical characteristic of each authorizable data in the data set), so that the data acquirer knows each authorizable data as fully as possible according to the information, thereby more accurately judging that the authorizable data capable of meeting the self requirement is the target data acquired by the subsequent request. For example, the data acquirer can acquire the related information through the self-used blockchain client and view the related information in the blockchain visual user interface so as to select at least part of the authorized data meeting the self-acquired requirement from the related information as the target data acquired by the requirement request. In addition, the acquisition rule of the target data can be acquired and checked, so that whether the self condition (including the data acquisition information) meets the acquisition rule of the authorized data and the target data is primarily judged, and the data acquisition information is submitted to the blockchain system under the condition that the self condition (including the data acquisition information) meets the judgment, so that authorization failure caused by the fact that the contract judgment data acquisition information does not meet the acquisition rule when the data management contract is executed later is avoided as much as possible, and the authorization success probability and the authorization efficiency are improved to a certain extent. Of course, the data acquirer may not perform the preliminary judgment, but directly submit the data acquisition information to the data after determining the target data to be acquired, which is not described again.

For the target data to be acquired (i.e., the data owner's authorization is to be acquired), the data acquirer may first determine the corresponding data acquisition information. The data acquisition information of any one of the target data may include: the method comprises the steps of identifying data of target data and information to be verified corresponding to an acquisition rule of the target data, wherein the data identification is used for indicating to a data management contract: the data acquisition party requests which of the authorized data is the target data to be acquired; the information to be verified is used for subsequently judging whether the acquisition rule of the target data is met, in other words, whether the data acquisition information meets the acquisition rule, namely, whether the information to be verified in the data acquisition information meets the acquisition rule is judged. The information to be verified can include the algorithm list, credit score, geographical location information, identity serial number, network address and the like, and will not be described again.

For example, the data acquisition information of any target data Dj may be "data Dj, privacy intersection, credit score of 900 points", which indicates: the data acquirer declares that the data acquirer needs to acquire the target data Dj for privacy intersection, and the credit score of the data acquirer is 900 points. Of course, when the data acquisition rule of the data Dj further includes a geographic range and a network address, the data acquisition information may further include "the geographic range is an X area, the network address is yyy", and the like, so as to declare that the data acquisition rule is located in the X area, and the network address of the data acquisition rule is yyy, which is not described herein.

In one embodiment, the data acquisition information may be included in a data acquisition transaction submitted to a blockchain system, which transaction is used to invoke the data management contract. For example, where the blockchain system includes only a blockchain network, the data acquirer may initiate a data acquisition transaction (through the client device itself in use) containing the data acquisition information directly to the blockchain nodes in the network. For another example, where the blockchain system includes a blockchain network and a BaaS platform, the data acquirer may initiate (via the client device in use itself) a data acquisition request to the BaaS platform that includes the data acquisition information to initiate, by the BaaS platform, a data acquisition transaction including the data acquisition information to a blockchain node in the blockchain system in response to the request. After the data acquisition transaction is agreed, the transaction is synchronized to each blockchain node in the blockchain network and executed by each blockchain node.

As described above, the data management contract has the acquisition rule of the target data recorded therein, based on which, after receiving the data acquisition information submitted by the data acquirer, the blockchain system may execute the contract to determine whether the data acquisition information satisfies the acquisition rule by the contract. With the foregoing embodiment, in the case where the data acquisition information is included in the data acquisition transaction that invokes the data management contract and submitted to the blockchain system, the blockchain node in the blockchain system may execute the (contract code in the) data management contract with the data acquisition information carried by the transaction as an entry in the process of executing the transaction, so as to determine by the contract whether the data acquisition information satisfies the acquisition rule of the target data.

In an embodiment, the acquisition rule may include an algorithm list, and the data acquisition information may include a target algorithm. Any algorithm in the algorithm list may be specifically a name or number of the algorithm, an algorithm rule of the algorithm, a related parameter of the algorithm, and the like. As described above, the algorithm recorded in the algorithm list is used to characterize an algorithm adopted by the data acquirer when the data acquirer allows the target data to be processed, and the target algorithm is an algorithm declared by the data acquirer and adopted by the data acquirer when the target data is processed after acquiring the authorization for the target data, so if the target algorithm in the data acquisition information is recorded in the algorithm list, the data management contract can determine that the data acquisition information satisfies the acquisition rule. Correspondingly, if the target data is acquired by utilizing the acquisition certificate transmitted by the blockchain system, the data acquirer can process the target data through the target algorithm, and the data acquirer can perform hash operation or encryption processing and the like on the acquired target data; and/or the target algorithm may be used to perform a preset operation (such as a private interaction operation involving multiple parties including a data owner, etc.) on the target data, so that the data acquirer acquires an operation result obtained after performing the preset operation by using an acquisition credential that is revealed by the blockchain system.

In another embodiment, the obtaining rule may also include a credit score range, and the data obtaining information may include a credit score of the data obtaining party on a preset platform. Wherein, the credit score can be a specific value, such as 300 points, 500 points, 800 points, etc., and the credit score range can be a numerical range; of course, the credit score may also be a score level, such as level a, level B, level C, or a priority, a good, a medium, a bad, etc., where the credit score range may be a set of levels including at least one score level. It will be appreciated that the credit score may be used to measure the credit of the data acquirer on the predetermined platform. Based on this, if the credit score of the data acquirer on the preset platform belongs to the credit score range, the data management contract may determine that the data acquisition information satisfies the acquisition rule. Therefore, the credit scoring range can be set in a higher interval, so that the data acquirer with excellent credit can be effectively controlled to acquire the authorization for any one of the authorizable data, and meanwhile, the data acquirer with poor credit can be prevented from acquiring the authorization, so that the authorized data can be processed according to the requirements of data owners as much as possible. With the foregoing embodiment, in the case where the acquisition rule of the target data Di is "data Di, the privacy is evaluated, and the credit score is not less than 800 points", if the target algorithm in the data acquisition information submitted by the data acquirer is the privacy is evaluated, and the credit score of the data acquirer is 900 points, the data management contract may determine that the data acquisition information satisfies the acquisition rule of Di; or if the target algorithm is not the privacy intersection or the credit score of the data acquirer is lower than 800 points, the data management contract judges that the data acquisition information does not meet the acquisition rule of Di.

In addition, the data management contract can call other contracts in the execution process, wherein contract addresses of the other contracts can be contained in the data acquisition information submitted by the data acquirer, so that the data management contract calls the other contracts according to the addresses. And/or the data acquisition information can also comprise a storage address of other data, so that the data management contract acquires necessary data according to the address in the execution process. If the target algorithm is the multiparty algorithm, the storage address may be the access address of the credit platform, and the data acquisition information may include the credit score of the data acquirer on the preset platform, and may also include the credit score of one or more other participants (except for the data acquirer) on the preset platform, where the data management contract may access the preset platform according to the access address to verify the authenticity of the credit scores, and use the verification (i.e. determine that the credit scores are the authenticity scores of the corresponding relevant parties) as a precondition for determining that the data acquisition information meets the acquisition rule, so as to avoid the potential safety hazard that the data acquirer may falsify the credit scores.

As shown in fig. 4, in the ethernet scenario, the blockchain node may run an EVM, which contains rule execution engines, such as a get rule execution engine and a use rule execution engine. In the process of executing the data management contract, the acquisition rule execution engine can be called to judge whether the data acquisition information submitted by the data acquisition party meets the acquisition rule of the target data. In addition, the usage rule engine may be invoked to determine whether the subsequently determined data usage information satisfies the usage rule of the target data, and the determination process may be described in the following embodiments, which are not repeated herein.

Step 304, determining data usage information for the target data and executing the data management contract, wherein the data management contract is used for judging whether the data usage information meets the usage rule.

In an embodiment, the data management contract described in this specification may include a plurality of functions, such as an interface function and a corresponding function. The blockchain transaction can specify the called interface function (in the contract) and the entering parameters thereof when the contract is called, so that the corresponding function corresponding to the interface function processes the entering parameters to obtain corresponding contract execution results in the process of specifying the contract. As described above, the data management contracts are executed in step 302 and step 304, and in a specific implementation, the two steps may call different interface functions of the data management contract, so as to implement different functions by executing the same data management contract, respectively: step 302 executes the contract to determine whether the data acquisition information satisfies the acquisition rule, and step 304 executes the contract to determine whether the data usage information satisfies the usage rule.

Step 306, when the data obtaining information meets the obtaining rule and/or the data using information meets the using rule, transmitting credential information for the target data to the data obtaining party, where the credential information is used to instruct the data owner to assist the data obtaining party to obtain the target data and/or perform an operation result obtained after a preset operation on the target data.

By the method, the data management contract can verify whether the related information of the target data meets the corresponding rule, and the blockchain network can transmit the credential information aiming at the target data to the data acquisition party under the condition that the data acquisition information meets the acquisition rule and/or the data use information meets the use rule. Otherwise, in the case that the data acquisition information does not satisfy the acquisition rule, the transmission of the acquisition certificate can be avoided, and the authorization failure message for the target data is transmitted to the data acquirer, so as to inform the data acquirer of: the request result of requesting to acquire authorization aiming at target data from the data owner is failure.

The blockchain network may reveal the credential information in a variety of ways. For example, the credential information may be written into a data acquisition event recorded by a receipt generated by the data management contract, the data acquisition party having listening rights for the receipt. For another example, the credential information may be written into a contract account of the data management contract, the data acquirer having query rights with respect to the contract account. The issued credential may be an acquisition credential, a use credential, or a comprehensive credential. In view of the fact that each credential may be revealed in the above manner, the following description will take the example of acquiring the credential:

For example, the blockchain network may write the acquisition credential into a data acquisition event, such as a data field of a write event (event), recorded by a receipt (receipt) generated by the data management contract, the data acquirer having listening rights for the receipt. In this way, the data acquirer can monitor the acquisition certificate written into the data acquisition event through the event monitoring callback mechanism, and perform subsequent processing according to the monitoring result.

Specifically, the execution result of the data management contract may include a receipt, which may include an event related to a method called for by executing the contract, such as a data acquisition event corresponding to a rule judgment method (for judging whether the data acquisition information satisfies the acquisition rule). Topic of the data acquisition event may contain a predefined authorized event identification to distinguish from other events. For example, in an event, the content of the topic is the keyword authorization, and the keyword is different from the topic in the event generated by other methods. Then, the EVM may determine to monitor the event related to executing the rule judging method described above, that is, the data acquisition event, by monitoring the topic contained in each event in the generated receipt, in the case of monitoring the topic containing the keyword authorization. For example, the event in the receipt is as follows:

Event：

[topic:other][data]

[topic:unauthorization][data]

[topic:authorization][data]

......

Then, when the data acquirer monitors the 1 st event, since the content of the topic contained is other, it can be determined that the event is irrelevant to the rule judging method. When the 2 nd event is monitored, as the content of the topic is underauthorization, the event is determined to be related to the rule judging method, and then the data field corresponding to the event is read, and at this time, the data field may be empty or may also contain the authorization failure message. Furthermore, when the 3 rd event is monitored, the content of the topic is an event of authorization, and the data field may be empty, or the above identifier may also be recorded. It can be appreciated that the 2 nd event and the 3 rd event can be generated by the blockchain network after executing the data management contract twice, and the data owners, the data acquirers, the target data and the like corresponding to the two executions can be the same or different, which is not described again.

By way of example, the content of the data field of the above 3 rd event may include, for example:

{ acquire credential ID;

data acquirer identity, data1 identity, algorithm list 1.

Data acquirer identity, data2 identity, algorithm list 2.

Data acquirer identity, data3 identity, algorithm list 3.

}

The acquiring credential ID may be globally unique in the data management system, and is used to uniquely identify the acquiring credential that is generated this time. The data1 identifier, the data2 identifier and the data3 identifier are respectively used for representing target data, namely data1, data2 and data3, which are acquired by the data acquirer in the current request. The algorithm list 1, the algorithm list 2 and the algorithm list 3 are respectively used for representing algorithms adopted when the data acquisition party processes data1, data2 and data3.

For another example, the acquisition credential may be written to a contract account of the data management contract, and the data acquirer may have query rights for the contract account. Wherein. The acquisition certificate may specifically be written into a Storage field of a contract account corresponding to the data management contract (as a value of the field). Alternatively, in the case where a custom field may also be included in the contract account, the acquisition credential may also be written to the custom field. The present description is not limited to obtaining a storage location of credentials in a contract account. It may be appreciated that the acquisition certificate written in the above-mentioned field is used as the status data of the contract account corresponding to the data management contract, and based on this, the data acquirer may acquire the acquisition certificate by querying the contract account corresponding to the data management contract.

As previously described, the blockchain network may transmit credential information for the target data to the data acquirer in the event that the data acquisition information satisfies the acquisition rules and/or the data usage information satisfies the usage rules. For example, in the case where the data acquisition information satisfies the acquisition rule, the credential information that is revealed may include an acquisition credential; meanwhile, in case the data usage information satisfies the usage rule, the revealed credential information may include a usage credential; specifically, the blockchain network may determine data usage information for the target data according to the received acquisition credential submitted by the data acquirer; alternatively, the data usage information for the target data may be determined according to the received data acquisition information and/or the transmitted acquisition certificate. For another example, the blockchain network may determine data usage information for the target data based on the received data acquisition information; accordingly, the comprehensive credential may be issued to the data acquirer if the data acquisition information satisfies the acquisition rule and the data usage information satisfies the usage rule. It can be seen that the credential information that is revealed may be a capture credential, a use credential, or a comprehensive credential, for which there may be various situations in the process of verifying whether the foregoing information satisfies the corresponding rule and revealing the corresponding credential information, as will be described below.

In an embodiment, in a case that the data management contract determines that the data acquisition information satisfies the acquisition rule, the blockchain network may transmit an acquisition credential for the target data to the data acquirer, where the credential is used to indicate that the data acquisition information provided by the data acquirer has passed the verification of the acquisition rule by the data management contract. Upon receiving the acquisition credential that the blockchain network has revealed, the data acquirer may submit the credential to the blockchain network in hopes of acquiring the corresponding use credential through the credential (the use credential may be used by the data acquirer to request use of the target data from the data owner). Upon receiving a credential submitted by a data acquirer, the blockchain network may determine corresponding data usage information from the credential, and execute the data management contract again to determine whether the data usage information satisfies a usage rule for the target data by the contract, and in case the determination is satisfied, pass through the usage credential for the target data. In this way, the data acquirer needs to submit the data acquisition information to the blockchain network to acquire the acquisition certificate revealed by the data acquirer, and then submit the acquisition certificate to acquire the use certificate revealed by the data acquirer, wherein the use certificate (or the acquisition certificate and the use certificate) can be used by the data acquirer to provide the data acquirer with assistance.

The data acquirer may submit the acquired credential to obtain the use credential immediately after receiving the acquired credential, or may submit the acquired credential to obtain the use credential at some point after receiving the acquired credential (according to its actual requirements). It can be understood that, when the data acquirer submits the acquiring certificate once, the data acquirer is indicated to have the requirement of re-acquiring the target data, and the validity information (such as the valid period of the certificate, the maximum using times and the like) of the certificate can be recorded in the using certificate, so that the behavior that the data acquirer requests to use the target data by using the certificate is accurately limited, and the fine control on the authorization process of the target data is realized.

For example, in the case that the usage rule includes a credential validity period, the data usage information may include a current time (determined by the data management contract), and/or may also include a receipt time of an acquisition credential (i.e., a time when the blockchain network receives the acquisition credential submitted by the data acquirer), and accordingly, if the receipt time of the acquisition credential at the current time is within the credential validity period, the data management contract may determine that the data usage information satisfies the usage rule. The validity period of the certificate may be a time interval or may be a deadline. It can be seen that this manner essentially sets an "aging" mechanism for the acquisition credential, and by reasonably setting the validity period of the credential, flexible control over "aging" of the acquisition credential can be achieved, for example, the acquisition credential (through which the data acquirer can be controlled to acquire the target data once) can be used arbitrarily (the acquisition use credential) for an indefinite period; or the control data acquirer can only randomly use the certificate within a preset time period (such as one hour, one day, one week, one month and the like) after acquiring the certificate of any target data, and the acquired certificate automatically fails and cannot be used beyond the time period. Correspondingly, the certificate validity period of the acquiring certificate can be recorded in the acquiring certificate, so that all data sides can judge whether the certificate is invalid or not according to the certificate validity period.

For another example, in the case where the usage rule includes a maximum number of uses of the target credential, the data usage information may include a total number of times the blockchain system receives the usage credential and the data acquisition information submitted by the data acquirer, where the total number of times the acquisition credential is received is a first total number of times, and the total number of times data acquisition information initiated by the data acquirer for the target data (the specific content may be the same as or different from the foregoing data acquisition information) is received is a second total number of times. Accordingly, if the first total number of times or the second total number of times is smaller than the maximum number of times of use, the data management contract may determine that the data usage information satisfies a usage rule. Wherein the maximum number of uses may be included in the aforementioned acquisition certificate, and the total number may be obtained by querying an execution record of a data management contract or a blockchain network for the contract. It can be seen that, by setting the first total number of times, essentially the "usage number limit" mechanism set for the acquisition certificate, and by reasonably setting the maximum usage number of times, flexible control of the "usable number of times" of the acquisition certificate can be achieved, for example, the acquisition certificate (through which the data acquirer can acquire the target data once) can be controlled to use the certificate infinitely and arbitrarily; or after the data acquirer is controlled to acquire the acquisition certificate of the target data once, the certificate can only be used without exceeding the maximum use times, and the acquisition certificate is automatically disabled and cannot be reused when the maximum use times are reached. And through the second total times, an authorization time limit mechanism for target data is set for the data acquirer, so that the times of acquiring the use certificates by the data acquirer do not exceed the maximum use times, and the accurate limit on the transmission times of the acquisition certificates is realized.

For another example, where the usage rules include a valid frequency range, the data usage information may include a current frequency at which the blockchain system receives the usage credential or the data acquisition information; the frequency of receiving the acquisition certificate is a first current frequency, and the frequency of receiving data acquisition information initiated by a data acquisition party on target data (the specific content of the data acquisition information may be the same as or different from the data acquisition information) is a second current frequency. Correspondingly, if the current frequency is within the valid frequency range, the data management contract can determine that the data usage information meets the usage rule. Therefore, through the first current frequency, a use frequency limit mechanism set for the acquired certificate is set, so that flexible control of the use frequency of the acquired certificate can be realized; by the second frequency, an authorization frequency limit mechanism aiming at target data is set, so that the frequency of acquiring the use certificate by a data acquirer does not exceed the effective frequency range, the accurate limit on the transmission frequency of the acquisition certificate is realized, and the data acquirer is prevented from acquiring the use certificate or using the target data too frequently.

In another embodiment, in the case that the data management contract determines that the data acquisition information satisfies the acquisition rule, the blockchain network may transmit an acquisition credential for the target data to the data acquirer, where the credential is used to indicate that the data acquisition information provided by the data acquirer has passed the verification of the acquisition rule by the data management contract. In addition, the blockchain network can determine the data use information according to the information after receiving the data acquisition information and/or determine the data use information according to the certificate when the acquisition certificate is revealed, and judge whether the data use information meets the use rule or not by the contract in the process of executing the data management contract, so that the use certificate aiming at the target data is revealed when the data use information meets the judgment. It can be seen that the blockchain network can determine data usage information for the target data based on the received data acquisition information and/or the revealed acquisition credentials. The data acquirer only needs to submit data acquisition information once (such as issuing a data acquisition transaction), and can obtain the acquisition certificate and the use certificate which are revealed by the blockchain network.

In yet another embodiment, the blockchain network may determine corresponding data usage information upon receiving data acquisition information submitted by the data acquirer, and thereafter, may execute a data management contract to determine whether the data acquisition information satisfies the acquisition rule and whether the data usage information satisfies the usage rule, and if both satisfy, then reveal the integrated credential. The method may also determine a part of data usage information according to the data acquisition information, determine the content of the acquisition certificate (without generating the acquisition certificate) when the data acquisition information is determined to satisfy the acquisition rule, determine another part of data usage information according to the content, determine whether the two parts of data usage information satisfy the usage rule by the data management contract, and transmit the comprehensive certificate when the two parts of data usage information are determined to satisfy the acquisition rule, where the certificate may include the content of the acquisition certificate (not actually generated). It can be seen that the blockchain network can determine data usage information for the target data based on the received data acquisition information and/or the revealed acquisition credentials. The data acquirer only needs to submit data acquisition information once (such as issuing a data acquisition transaction), and can obtain the comprehensive certificate revealed by the blockchain network.

For example, in the case where the data acquisition party is U1, the usage rule of any target data Di may be { Di, U1, privacy intersection, open=600 s, limit=2, frequency=120 s/time, … }. Where "expired=600s" indicates that the credential validity period is 600s (i.e., 10 minutes), "limit=2" indicates that the maximum number of uses of the credential is 2, and "frequency=200 s/time" indicates that the credential should be no less than 120s in duration between successive submissions, i.e., the target data Di can be requested for use once at the fastest of 2 minutes.

In addition, the blockchain system can encrypt the credential information by using a key (a symmetric key negotiated in advance by a data owner and a data acquirer, or a public key of the data acquirer, etc.), and transmit the encrypted credential information to the data acquirer; accordingly, the data acquirer with the key (the symmetric key, or the private key of the data acquirer, etc.) required for decryption can read and decrypt the encrypted credential information to obtain clear credential information, and an unrelated user cannot decrypt the encrypted credential information, so that the data acquirer can be ensured to obtain the credential information, and the credential information can be prevented from being obtained by unrelated personnel when being recorded on a chain in a clear text form, namely, the credential information is prevented from being leaked, and the rights of all data acquirers are ensured.

After acquiring credential information revealed by the blockchain network, the data acquirer can provide the information to the data owner; correspondingly, the data owner can assist the data acquirer to acquire the target data and/or an operation result obtained after preset operation is performed on the target data according to the information.

In one embodiment, the data acquirer may initiate a data acquisition request containing the credential information to the data owner, who may determine the corresponding target data in response to the request and return the data directly to the data acquirer for use thereof. Or the target data can be subjected to preset operation in response to the request, and the corresponding operation result is returned to the data acquisition party. Obviously, relative to the mode of directly providing the target data for the data acquisition party, the data acquisition party performs preset operation on the target data and provides corresponding operation results for the data acquisition party, when the target data obtains the corresponding operation results through the preset operation, if the data acquisition party cannot reversely push out the value of the target data from the operation results, the disclosure degree of the target data can be limited under the condition of meeting the data acquisition requirement of the data acquisition party, the data acquisition party is prevented from directly acquiring the target data, the data acquisition party is prevented from leaking the target data to infringe the rights of the data acquisition party, the target data is ensured to be always held only by the data acquisition party, and the safety of the target data is improved.

The preset operation performed on the target data should meet the operation requirement of the data acquisition party on the target data. In an embodiment, the preset operation may include a multiparty operation in which the data owner and the data acquirer participate together. At this time, the server-side data acquirer can only acquire the operation result of the multiparty operation, but cannot acquire the target data, so that the data security of the target data is improved, the burden of the data acquirer on the target data is reduced, and the use efficiency is improved.

Wherein the operation rules of the preset operation may be predefined in the data management contract, for example, as part of the algorithm list in the acquisition rules; or the data acquisition information and the data acquisition information are submitted to the blockchain system and are transmitted to the data management contract, and if the operation rule and the data acquisition information can be contained in the data acquisition transaction and initiated to the blockchain system; or the data obtaining party and the credential information can be provided together, for example, the operation rule and the credential information can be contained in the data obtaining request and initiated to the data owner, and the details are not repeated. The data acquirer can flexibly select the mode according to the actual situation to assign the operation rule aiming at the target data to the data acquirer so as to instruct the data acquirer to adopt the algorithm to process the target data.

In addition, different privacy levels may exist between each of the authorizable data held by the data owners; accordingly, data of different privacy levels may have differentiated treatments. For example, the data owners may hold relatively low privacy level and relatively high privacy level of the authorizable data, i.e., low privacy level and high privacy level of the authorizable data, respectively. Accordingly, when the target data belongs to the low privacy level, the target data can be provided to the data acquirer, namely, the data owner does not pay attention to whether the data of the low privacy level can leak or not; when the target data belongs to the high privacy level, the target data needs to be subjected to preset operation so that corresponding operation results are provided to the data acquirer, and therefore the data of the high privacy level cannot be leaked. If the target data simultaneously contains the authorized data with the low privacy level and the high privacy level, the target data with the low privacy level can be directly provided to the data acquirer, and the target data with the high privacy level can be provided to the data acquirer after the target data with the high privacy level is subjected to the preset operation; or, especially in the case where the data acquirer has specified the operation rule of the preset operation to be adopted in the foregoing data acquisition transaction or data acquisition request, the preset operation may be performed on all the target data together, and the operation result may be provided to the data acquirer.

In the case of receiving the credential information provided by the data acquirer, in order to avoid data authorization and value loss possibly caused by fraudulent actions such as tampering with the credential and the like, which may exist in the data acquirer, the data acquirer may also verify the authenticity of the credential information received by the data acquirer. For example, in the case that the credential information or the data acquisition request carries the related information of the data acquisition transaction (such as transaction hash and block height of the block where the transaction is located, etc.) or the related information of the data management contract (such as contract address, etc.), the data owner may request the blockchain system to query the corresponding credential information according to the related information, and further determine whether the received (submitted by the data acquirer) credential information is consistent with the queried credential information: if the received credential information is consistent with the received credential information, the received credential information is not tampered, and the data acquirer is indicated to provide the received real credential information; otherwise, if the two information are inconsistent, the information is provided by the data acquirer and is not the received real credential information. Wherein, the above-mentioned inquiry procedure can be realized by SPV (Simplified Payment Verification, simple payment verification) technology; or, the data owner can obtain the complete block from the blockchain system according to the block height and inquire the corresponding credential information generated by executing the data management contract from the complete block, which is not described again.

For another example, the authenticity of the credential information provided by the data acquirer may also be verified by means of a verification. When the blockchain system transmits the credential information aiming at the target data to the data acquisition party, the signature made to the credential information by the public key of the data owner can be simultaneously transmitted; correspondingly, after receiving the credential information and the signature thereof provided by the data acquirer, the data acquirer can use the private key to carry out signature verification, and under the condition that verification is passed, the data acquirer is assisted to obtain the target data and/or an operation result obtained after preset operation is carried out on the target data. In other words, the target data and/or the operation result obtained after the preset operation is performed on the target data can be obtained by the data owner in a assisting manner under the condition that the signature verification is passed, that is, the data owner can pass the verification of the credential information as a precondition for assisting the data acquirer, so that under the condition that the data acquirer provides false credential information, the assistance of the data acquirer in obtaining the target data and/or the operation result is effectively avoided, and the accuracy and reliability of the authorization of the target data are improved.

It can be appreciated that the credential information revealed in the foregoing manner may be used to prove that the data acquirer meets the conditions for acquiring the target data, and after the credential information is acquired, the data acquirer may acquire the target data and/or the calculation result using the credential. In this regard, further restrictions may be placed on the specific process by which the data owner assists the data acquirer in acquiring the target data and/or the calculation result by the rules of use of the target data.

In addition, when the data acquirer is assisted to acquire target data, if the target data is stored locally in the data acquirer, the data can be directly returned to the data acquirer; alternatively, if the target data is maintained by a preset hosting party, the hosting direction data acquirer may be instructed to return the data. When the auxiliary data acquirer acquires an operation result obtained after the preset operation is performed on the target data, if the target data is stored locally, the data owner can participate in the preset operation by using the target data and return the operation result to the data acquirer; the trusted correlative party can be called to participate in the preset operation by utilizing the target data, and the correlative party directly returns the operation result to the data acquisition party, or the correlative party feeds back the operation result to the data all party, and the data all party returns the operation result to the data acquisition party, so that the correlative party directly participating in the preset operation is prevented from being disclosed to the data acquisition party. Similarly, if the target data is maintained by a preset hosting party, the target data can be acquired from the hosting party and preset operation is executed, and then an operation result is returned to the data acquisition party; the host party can be instructed to participate in the preset operation by using the target data, and the host party directly returns the operation result to the data acquisition party, or the host party feeds back the operation result to the data all party, and the data all party returns the operation result to the data acquisition party, so that the host party directly maintaining the target data is prevented from being revealed to the data acquisition party. The above-mentioned multiple assistance modes can be flexibly selected according to actual demands, and this description is not limited thereto.

Further, after the target data is obtained through the credential information, the data acquirer can directly process the data; after the operation result obtained by carrying out the preset operation on the target data is obtained, the data acquisition party can carry out further processing treatment on the operation result. As for the manner in which the data acquisition side performs processing with respect to the obtained target data or the operation result, the present specification is not limited.

The main steps of the data management method described above are briefly and intuitively described below with reference to fig. 4. As shown in fig. 4, the data management method includes steps 402-410.

In step 402, a data owner configures rules associated with the authorizable data, including the target data, within a data management contract deployed in a blockchain system.

Wherein the data owner may configure the relevant rules during deployment of the data management contract; alternatively, the acquisition rules may be added or updated in a pre-deployed data management contract. For any authorizable data, the relevant rules that are configured include acquisition rules and/or usage rules.

At step 404, the data acquisition submits information to the blockchain system.

In step 406, the blockchain network reveals credential information to the data acquirer.

There are a number of implementations for steps 404-406, each of which is described below.

Implementation a:

in step 404a-1, the data acquisition direction blockchain system submits data acquisition information for the target data.

For example, the data acquirer may first acquire and view the acquisition rule from the chain, and submit the data acquisition information corresponding to the rule to the blockchain system to improve the authorization probability and the processing efficiency when the data acquirer preliminarily determines that the condition of the acquirer (i.e., the data acquisition information that the acquirer can provide) satisfies the rule.

The data acquirer can directly or indirectly initiate a data acquisition transaction containing data acquisition information to the blockchain system (in a mode of initiating a data acquisition request), and the blockchain system further executes a data management contract called by the transaction in the process of executing the transaction so as to judge whether the data acquisition information submitted by the data acquirer meets the acquisition rule recorded in the contract or not by the contract.

In step 406a-1, the blockchain network transmits the acquisition credential to the data acquisition party.

Under the condition that the data management contract judges that the data acquisition information meets the acquisition rule, the blockchain network transmits an acquisition certificate to the data acquisition party.

At step 404a-2, the data acquisition submits an acquisition credential to the blockchain system.

After receiving the acquisition certificate, the data acquirer can submit the certificate at an appropriate time, and the submitting mode is similar to the data acquisition information submitting mode and is not repeated. Upon receiving the acquisition ticket, the blockchain network may determine corresponding data usage information and execute a data management contract to determine from the contract whether the information satisfies the usage rules.

At step 404a-2, the blockchain network passes the usage credential to the data acquirer.

In the case where the data management contract determines that the data usage information satisfies the usage rule, the blockchain network passes through the usage credential to the data acquirer.

Implementation mode B:

in step 404b, the data acquisition direction blockchain system submits data acquisition information for the target data.

The blockchain network may determine corresponding data usage information based on the data acquisition information after receiving the information.

In step 406b-1, the blockchain network transmits the acquisition credential to the data acquisition party.

Under the condition that the data management contract judges that the data acquisition information meets the acquisition rule, the blockchain network transmits an acquisition certificate to the data acquisition party. In addition, the blockchain network can also determine corresponding data use information according to the certificate after generating or displaying the acquired certificate.

In step 406b-2, the blockchain network passes the usage credential to the data acquirer.

Executing a data management contract according to the determined data use information, judging whether the information meets the use rule or not by the contract, and displaying a use certificate if the information meets the use rule.

The step 406b-1 and the step 406b-2 may be combined into one step 406b, i.e. the blockchain network transmits the acquisition certificate and the usage certificate to the data acquirer together, so as to reduce the interaction times of the two.

Implementation C:

in step 404c, the data acquisition direction blockchain system submits data acquisition information for the target data.

The blockchain network can determine corresponding data use information, such as current receiving frequency, current total times, receiving time and the like, according to the information after receiving the data acquisition information.

In step 406c, the blockchain network transmits the acquisition credential to the data acquisition party.

In the case where the data management contract determines that the data acquisition information satisfies the acquisition rule, the (content that should be included in) of the acquisition ticket (but the ticket is not generated or revealed) is determined, such as the data identification of the target data, the identification of the data acquirer, the list of algorithms declared by the data acquirer, the validity period of the ticket, and the like. In addition, the blockchain network may also determine corresponding data usage information, such as the content of the acquisition voucher, according to the voucher after determining the content of the acquisition voucher.

Executing a data management contract according to the determined data use information, judging whether the information meets the use rule or not by the contract, and displaying a comprehensive certificate if the information meets the use rule, wherein the certificate comprises the content (not actually generated) of the acquisition certificate.

In step 408, the data acquirer provides the received credential information to the data owner (e.g., initiates a data acquisition request including the acquisition credential to the data owner) to request the data owner to use the target data.

In step 410, the data owner assists the data acquirer in acquiring the target data and/or performing a preset operation on the target data.

The data owner can verify the authenticity of the acquisition certificate and whether the acquisition certificate meets the use rule at the same time, and assist the data acquirer to acquire the target data and/or the operation result after the verification is passed. Of course, in the case that the verification is not passed, the assistance of the data acquirer to acquire the target data and/or the operation result should be avoided, and in addition, a failure reminding message may be returned to the data acquirer so as to inform the data acquirer of failure in acquiring the target data and/or the operation result in time.

Corresponding to the foregoing embodiments, the present specification also proposes a data management system including a blockchain system, a data owner, and a data acquirer, the data management contract deployed in the blockchain system having recorded therein acquisition rules and usage rules for target data attributed to the data owner, wherein,

Fig. 5 is a schematic block diagram of an apparatus according to an exemplary embodiment. Referring to fig. 5, at the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, a memory 508, and a non-volatile storage 510, although other hardware required for other functions may be included. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 502 reading a corresponding computer program from the non-volatile storage 510 into the memory 508 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.

As shown in fig. 6, fig. 6 is a block diagram of a data management apparatus according to an exemplary embodiment provided in the present specification, and the apparatus may be applied to a device shown in fig. 5 to implement the technical solution of the present specification.

The data management device is applied to a blockchain system in a data management system, the data management system further comprises a data owner and a data acquirer, a data management contract deployed in the blockchain system records acquisition rules and use rules of target data, the target data belongs to the data owner, and the device comprises:

A first execution unit 601, configured to execute the data management contract in response to receiving data acquisition information for the target data submitted by the data acquirer, where the data management contract is configured to determine whether the data acquisition information meets the acquisition rule;

a second execution unit 602 configured to determine data usage information for the target data and execute the data management contract for determining whether the data usage information satisfies the usage rule;

and a credential transmission unit 603, configured to transmit credential information for the target data to the data acquirer, where the data acquisition information satisfies the acquisition rule and/or the data usage information satisfies the usage rule, and the credential information is used to instruct the data owner to assist the data acquirer in acquiring the target data and/or perform an operation result obtained after a preset operation on the target data.

Optionally, in the case that the data acquisition information satisfies the acquisition rule, the revealed credential information includes an acquisition credential; the second execution unit 602 is specifically configured to:

Determining data use information aiming at the target data according to the received acquisition certificate submitted by the data acquirer; or,

determining data use information aiming at the target data according to the received data acquisition information and/or the revealed acquisition certificate;

wherein the presented credential information includes a use credential in case the data use information satisfies the use rule.

Alternatively to this, the method may comprise,

the second execution unit 602 is specifically configured to: determining data use information for the target data according to the received data acquisition information;

the credential showthrough unit 603 is specifically configured to: and under the condition that the data acquisition information meets the acquisition rule and the data use information meets the use rule, a comprehensive certificate is transmitted to the data acquisition party.

Optionally, the data usage information satisfies the usage rule, including at least one of:

when the usage rule includes a credential validity period, the data usage information includes a current time and a receiving time of the acquired credential at a receiving time of the data acquisition information, the current time and the receiving time of the data acquisition information are within the credential validity period;

In the case that the usage rule includes a maximum number of uses of the target credential, and the data usage information includes a total number of times the blockchain system receives the usage credential submitted by the data acquirer or the data acquisition information, the total number of times is less than the maximum number of uses;

in the case that the usage rule includes an effective frequency range, and the data usage information includes a current frequency at which the blockchain system receives the usage credential or the data acquisition information, the current frequency is within the effective frequency range.

Optionally, the acquiring rule includes an algorithm list, and the data acquiring information satisfies the acquiring rule, including:

the target algorithm in the data acquisition information is recorded in the algorithm list, wherein the data acquisition party is used for processing the obtained target data through the target algorithm, and/or the target algorithm is used for executing the preset operation.

Optionally, the preset operation includes a multiparty operation that the data owner and the data acquirer participate in together.

Optionally, the acquiring rule includes a credit score range, the data acquiring information includes a credit score of the data acquirer on a preset platform, and the data acquiring information satisfies the acquiring rule and includes:

And the credit score of the data acquirer on the preset platform belongs to the credit score range.

Optionally, the credential disclosure unit 603 is specifically configured to:

writing the credential information into a data acquisition event recorded by a receipt generated by the data management contract, wherein the data acquisition party has monitoring authority for the receipt; or,

writing the credential information into a contract account of the data management contract, wherein the data acquirer has query rights for the contract account.

Optionally, the credential disclosure unit 603 is specifically configured to:

and transmitting credential information aiming at the target data and a signature made on the credential information through a public key of the data owner to the data acquirer, wherein the target data and/or an operation result obtained after preset operation is performed on the target data is assisted by the data acquirer to be obtained under the condition that the signature verification is passed by the data owner.

Optionally, there is authorized data belonging to the data owner, the target data including at least part of the authorized data, the apparatus further comprising:

a credential submitting unit 604, configured to submit, to the blockchain system, a first correspondence between a data identifier of any one of the authorizable data and an acquisition rule thereof, and/or a second correspondence between a data identifier of any one of the authorizable data and a usage rule thereof, to the blockchain system; the method comprises the steps of,

A contract deployment unit 605 for deploying the data management contract including the first correspondence and/or the second correspondence by the blockchain system; or,

a relationship configuration unit 606, configured to configure the first correspondence and/or the second correspondence in the blockchain system in the case that the data management contract has been deployed in the blockchain system.

Optionally, the relationship configuration unit 606 is specifically configured for one of the following:

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims

1. A data management method applied to a blockchain system in a data management system, the data management system further comprising a data owner and a data acquirer, a data management contract deployed in the blockchain system recording acquisition rules and usage rules for target data, the target data belonging to the data owner, the method comprising:

2. The method of claim 1, the credential information being revealed to include an acquisition credential if the data acquisition information satisfies the acquisition rule; the determining data usage information for the target data includes:

3. The method according to claim 1,

the determining data usage information for the target data includes: determining data use information for the target data according to the received data acquisition information;

The step of transmitting credential information for the target data to the data acquirer in a case where the data acquisition information satisfies the acquisition rule and/or the data usage information satisfies the usage rule, includes: and under the condition that the data acquisition information meets the acquisition rule and the data use information meets the use rule, a comprehensive certificate is transmitted to the data acquisition party.

4. A method according to claim 2 or 3, the data usage information meeting the usage rules, comprising at least one of:

5. The method of claim 1, the acquisition rule comprising a list of algorithms, the data acquisition information satisfying the acquisition rule, comprising:

6. The method of claim 1, the preset operation comprising a multiparty operation in which the data owner and the data acquirer participate together.

7. The method of claim 1, the acquisition rule comprising a credit score range, the data acquisition information comprising a credit score of the data acquirer at a preset platform, the data acquisition information satisfying the acquisition rule, comprising:

8. The method of claim 1, the blockchain system to pass credential information for the target data to the data acquirer, comprising:

9. The method of claim 1, the blockchain system to pass credential information for the target data to the data acquirer, comprising:

10. The method of claim 1, there being authorizable data belonging to a data owner, the target data comprising at least a portion of the authorizable data, the method further comprising:

The data all submits a first corresponding relation between the data identifier of any one of the authorized data and the acquisition rule thereof to the blockchain system, and/or submits a second corresponding relation between the data identifier of any one of the authorized data and the use rule thereof; the method comprises the steps of,

the blockchain system deploys the data management contract including the first correspondence and/or the second correspondence; or,

in the case where the data management contract has been deployed in the blockchain system, the blockchain system configures a first correspondence and/or a second correspondence in the data management contract.

11. The method of claim 10, the blockchain system configuring any of a first correspondence and a second correspondence in the data management contract, comprising one of:

12. A data management system comprising a blockchain system, a data owner, and a data acquirer, the data management contract deployed in the blockchain system having recorded acquisition rules and usage rules for target data attributed to the data owner, wherein,

13. A data management apparatus applied to a blockchain system in a data management system, the data management system further comprising a data owner and a data acquirer, a data management contract deployed in the blockchain system having recorded therein acquisition rules and usage rules for target data attributed to the data owner, the apparatus comprising:

14. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to implement the method of any of claims 1-11 by executing the executable instructions.

15. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-11.