TWI829220B - De-centralized data authorization control system capable of utilizing smart contract to generate and transfer authorization token - Google Patents

Abstract

A de-centralized data authorization control system is disclosed, including: a third-party service subsystem; a data requester device for generating a first token request containing a token identification data; and a block chain subsystem capable of verifying the activity of an authorization token corresponding to the token identification data. If the authorization token is active, the block chain subsystem generates a first read token. After acquiring the first read token, the data requester device transmits a first data request to the third-party service subsystem, and transfers the first read token to the third-party service subsystem. If the first read token is active, the third-party service subsystem finds out a first set of data corresponding to the first data request, and transmits the first set of data to the data requester device. The block chain subsystem executes a token management smart contract to generate and transfer the authorization token to the data owner device.

Description

A decentralized data authorization control system that can use smart contracts to generate and transfer authorization tokens

The invention relates to a blockchain technology, in particular to a decentralized data authorization control system that can dynamically adjust data authorization policies.

The General Data Protection Regulation (GDPR) formulated by the European Union is not only strict in terms of personal data protection and privacy, but also covers a wide range. If GDPR regulations cannot be met, business activities in many fields will face very significant impacts or obstacles.

Since the traditional OAuth 2.0 data authorization framework cannot meet the various requirements of GDPR, the industry is actively developing various more complex data authorization structures to cope with it. Various recently developed data authorization architectures, including UMA 2.0 (User-Managed Access 2.0), use centralized authorization servers to manage the data authorization policies of individual data owners. This structure seems to meet the requirements of GDPR, but in fact the management of authorization policies is not transparent, and it is difficult to allow data owners to dynamically adjust their data authorization policies at any time as needed. Therefore, the existing data authorization architecture is not an ideal solution for many increasingly complex business applications (for example, Open Banking).

In view of this, how to make the data authorization control system meet the various requirements of the EU GDPR? It is a problem that needs to be solved while improving the transparency of authorization policy management and allowing data owners to dynamically adjust their data authorization policies at any time as needed.

This specification provides an embodiment of a decentralized data authorization control system, which includes: a data owner device configured to provide target data; a third-party service subsystem configured to store the target data; a data request a device configured to generate a first data request corresponding to one or more data items and generate a first beacon request including a beacon identification data; and a blockchain subsystem including a plurality of blocks The chain node is configured to obtain a beacon identification data corresponding to the first beacon request, and to verify the validity of an authorization beacon corresponding to the beacon identification data, and if the authorization beacon is valid, the The blockchain subsystem is further configured to generate a first access beacon corresponding to the authorization beacon; wherein, the data requester device is further configured to transmit the first access beacon after acquiring the first access beacon. The data request is made to the third-party service subsystem, and the first access beacon is transferred to the third-party service subsystem; if the first access beacon is valid, the third-party service subsystem will also Find a first set of data corresponding to the first data request from the target data, and transmit the first set of data to the data requester device; wherein the blockchain subsystem is also configured to perform a beacon management A smart contract to generate and transfer the authorization beacon to the data owner device; wherein the data owner device will use the authorization beacon to transmit a data authorization policy ciphertext to the blockchain subsystem, and the zone The blockchain subsystem will record the data authorization policy ciphertext in an authorization policy smart contract.

This specification also provides an embodiment of a decentralized data authorization control system, which includes: a third-party service subsystem configured to store target data; a data requester device configured to generate one or more data A first data request corresponding to the project and generating a first beacon request including a beacon identification data; and a blockchain subsystem including a plurality of blockchain nodes configured to obtain the first beacon request A corresponding beacon identification data, and verify the validity of an authorization beacon corresponding to the beacon identification data, and if the authorization beacon is valid, the blockchain subsystem is also configured to generate an authorization beacon corresponding to the beacon identification data. A first access beacon corresponding to the authorization beacon; wherein, the data requester device is further configured to transmit the first data request to the third-party service subsystem after obtaining the first access beacon, and Transfer the first access beacon to the third-party service subsystem; wherein, if the first access beacon is valid, the third-party service subsystem will also find out the target data related to the first access beacon. A first set of data corresponding to the data request is sent to the data requester device; wherein, the blockchain subsystem is also configured to execute a beacon management smart contract to generate and transfer the authorization message. tag to the data owner device; wherein, the data owner device will use the authorization beacon to transmit a data authorization policy encrypted text to the blockchain subsystem, and the blockchain subsystem will encrypt the data authorization policy The document is recorded in an authorization policy smart contract.

One of the advantages of the above embodiment is that the use of the blockchain subsystem to replace the traditional centralized authorization server can effectively improve the transparency of the authorization policy management of the decentralized data authorization control system, thereby reducing the need for third-party service subsystems. The possibility of disputes with data owners or data requesters.

Another advantage of the above embodiment is that the architecture of the decentralized data authorization control system can meet the various requirements of the subsequent stages of the EU GDPR, and can allow data owners to dynamically adjust their data authorization policies at any time as needed.

Other advantages of the present invention will be explained in more detail in conjunction with the following description and drawings.

100: de-centralized data authorization control system (de-centralized data authorization control system)

110, 120: data owner device (data owner device)

111, 131, 151: communication circuit

113, 133, 153: block chain computing circuit

115, 135, 155: database

117, 137: control circuit

130~140: data requester device (data requester device)

150:Third-party service subsystem (third-party service subsystem)

157:data server

160:block chain node cluster

161~167: block chain node

170:block chain subsystem

362: token management smart contract

364: Authorization policy smart contract

366:data inquiry smart contract

202~226, 402~418, 502~522, 602~622, 702~730, 802~822, 902~930, 1002~1016: operation process

Figure 1 is a simplified functional block diagram of a decentralized data authorization control system according to an embodiment of the present invention.

FIG. 2 is a simplified flow chart of a data authorization policy management method according to an embodiment of the present invention.

Figure 3 is a schematic diagram of the simplified functional module relationship between the blockchain subsystem in Figure 1 and other member devices.

Figure 4 is a simplified flow chart of a method for checking whether the data authorization policy in the blockchain subsystem is correct according to an embodiment of the present invention.

Figure 5 is a simplified process of a method for providing a queryable data list according to an embodiment of the present invention. Figure.

FIG. 6 is a simplified flow chart of a method for generating access signals according to an embodiment of the present invention.

FIG. 7 is a simplified flow chart of a data request response method according to an embodiment of the present invention.

FIG. 8 is a simplified flow chart of a method for generating access signals according to another embodiment of the present invention.

Figure 9 is a simplified flow chart of a data request response method according to another embodiment of the present invention.

Figure 10 is a simplified flow chart of a method for dynamically updating a data authorization policy according to an embodiment of the present invention.

The embodiments of the present invention will be described below with reference to relevant drawings. In the drawings, the same reference numbers represent the same or similar elements or process flows.

Figure 1 is a simplified functional block diagram of a decentralized data authorization and control system 100 according to an embodiment of the present invention. The decentralized data authorization control system 100 is used to control multiple data owners (data owners) of various types such as individuals or business organizations, and for different data requesters (data requesters) such as other individuals or business organizations. Data authorization scope and authorization items, and allows data owners to dynamically adjust their data authorization scope and authorization items as needed.

The decentralized data authorization control system 100 includes one or more data owner devices (for example, the exemplary data owner devices 110~120 shown in Figure 1), one or more data requester devices (for example, The exemplary data requestor device 130~140) shown in Figure 1, at least one third-party service subsystem 150, a blockchain node cluster 160, and the blockchain node cluster 160 combined with other blockchain computing circuits A blockchain subsystem 170 formed together.

The multiple data owner devices 110~120 in the decentralized data authorization and control system 100 belong to different data owners, and individual data owners can be individuals, various types of enterprises or corporate organizations, and various consortiums. , various corporate entities, various non-profit organizations, various government agencies, etc.

Multiple data requester devices 130~140 in the decentralized data authorization control system 100, They belong to different data requesters, and individual data requesters can be individuals, various types of enterprises or corporate organizations, various foundations, various corporate entities, various non-profit institutions, various government agencies, etc.

The third-party service subsystem 150 is a system operated by a specific service provider that can provide digital storage services. It is used to store various digital data provided by individual data owners, such as various digital files, various program files, and / Or various multimedia materials, etc.

In addition, the blockchain subsystem 170 is usually a blockchain system jointly operated and managed by multiple different entities to control the data access permissions of individual data requester devices to the third-party service subsystem 150 and allow Individual data owners dynamically adjust the data authorization policy through the corresponding data owner device.

In practical applications, individual data owners can transmit various types of digital data to be protected to the third-party service subsystem 150 for storage through relevant data owner devices. In addition, individual data owners can also send data authorization policies for different data requesters to the blockchain subsystem 170 for storage and management through the data owner device to prevent the data authorization policies from being tampered with. The aforementioned data authorization policy may include the authorized object, authorized data subject, authorized content, upper limit of authorization times, authorization period, authorization time limit, geographical area where the data is located, and the identification information of the third-party service provider who keeps the data (for example, third-party service provider Provider provides some or all of the multiple parameters such as the address of a specific smart contract deployed in the blockchain subsystem 170).

On the other hand, individual data requesters can use relevant data requestor devices to apply to the blockchain subsystem 170 for a data read token corresponding to a specific data owner. When a data requester wants to obtain specific data of a specific data owner, the relevant data requester device can be controlled to use the data access beacon provided by the blockchain subsystem 170 to make a data access request to the third-party service subsystem 150 (data read request).

At this time, the third-party service subsystem 150 can use the blockchain subsystem 170 to verify the validity of the data access beacon provided by the data requester's device to verify the identity of the data requester. point. Only when the validity of the data access beacon can be verified by the blockchain subsystem 170, the third-party service subsystem 150 will share the specific data content authorized by the specific data owner to the data requester device.

In addition, the blockchain subsystem 170 can also record relevant time information of individual data access beacons as evidence that the data requester device accesses relevant data from the third-party service subsystem 150 .

In the decentralized data authorization control system 100, individual data owners can also dynamically adjust the data authorization policy stored in the blockchain subsystem 170 as needed. For example, when an individual data owner adjusts the data authorization policy for a specific data requester or all data requesters for various reasons, the relevant data owner device can be used to transmit the updated data authorization policy to the blockchain subsystem. 170 is stored and managed to replace the previous version of the data authorization policy.

In order to meet the needs of certain commercial transactions or legal relationship management, different participants of the decentralized data authorization and control system 100 can sign various appropriate agreements or contracts using traditional or digital methods to further clarify the relationship between each other. legal relationship between them. For example, individual data owners and specific service providers operating the third-party service subsystem 150 may jointly sign various appropriate data hosting agreements, online storage space rental contracts, service agreements, intellectual property rights ownership agreements, and data transfer agreements. Agreement, privacy protection agreement, data sharing agreement, and/or personalized advertising broadcast agreement, etc.

For another example, individual data owners and individual data requesters can jointly sign various appropriate data authorization agreements, data sharing agreements, data use agreements, data verification agreements, and/or data audit agreements, etc.

For another example, individual data requesters and specific service providers operating the third-party service subsystem 150 may jointly sign various appropriate data indexing specification agreements, data query agreements, data sharing agreements, data use agreements, and data transmission agreements. , and/or service agreement, etc.

As shown in Figure 1, the data owner device 110 includes a communication circuit 111, a blockchain operation A computing circuit 113, a database 115, and a control circuit 117. The data requester device 130 includes a communication circuit 131, a blockchain operation circuit 133, a database 135, and a control circuit 137. The third-party service subsystem 150 includes a communication circuit 151, a blockchain computing circuit 153, a database 155, and a data server 157. The blockchain node cluster 160 includes a plurality of blockchain nodes, such as the exemplary blockchain nodes 161 to 167 shown in FIG. 1 .

In the data owner device 110, the communication circuit 111 is configured to communicate data with the third-party service subsystem 150 and the blockchain subsystem 170 through the Internet or other networks. The blockchain computing circuit 113 is coupled to the communication circuit 111 for acting as one of the nodes of the blockchain subsystem 170 and as a communication bridge between the data owner device 110 and the blockchain subsystem 170 . The database 115 is used to store data to be transmitted to the third-party service subsystem 150 . The control circuit 117 is coupled to the communication circuit 111, the blockchain computing circuit 113, and the database 115, and is configured to control the operation of the aforementioned devices.

In the data requester device 130, the communication circuit 131 is configured to communicate data with the third-party service subsystem 150 and the blockchain subsystem 170 through the Internet or other networks. The blockchain computing circuit 133 is coupled to the communication circuit 131 for acting as one of the nodes of the blockchain subsystem 170 and as a communication bridge between the data requester device 130 and the blockchain subsystem 170 . The database 135 is used to store data obtained from the third-party service subsystem 150 . The control circuit 137 is coupled to the communication circuit 131, the blockchain computing circuit 133, and the database 135, and is configured to control the operation of the aforementioned devices.

Other data owner devices (for example, the data owner device 120) in the decentralized data authorization control system 100 can have a similar main structure to the data owner device 110, but the implementation is not limited to all data owners. Both devices must have exactly the same circuit architecture. Similarly, other data requestor devices (for example, the data requestor device 140) in the decentralized data authorization control system 100 can have a similar main architecture to the data requestor device 130, but there are no limitations in implementation. All data requestor devices must have exactly the same circuit architecture.

In the third-party service subsystem 150, the communication circuit 151 is configured to communicate data with the blockchain subsystem 170, individual data owner devices, and individual data requestor devices through the Internet or other networks. The blockchain computing circuit 153 is coupled to the communication circuit 151 for acting as one of the nodes of the blockchain subsystem 170 and as a communication bridge between the third-party service subsystem 150 and the blockchain subsystem 170 . The database 155 is used to store data provided by different data owners. The data server 157 is coupled to the communication circuit 151, the blockchain computing circuit 153, and the database 155, and is configured to control the operation of the aforementioned devices.

In practical applications, the aforementioned third-party service subsystem 150 may provide a single type of service (for example, cloud storage service, multimedia file sharing service, life record sharing service, community service, financial management service, health information management service, etc. ), or it can be a system that provides multiple composite services (for example, cloud storage service combined with email service, multimedia data sharing service combined with instant messaging service, social community service combined with multimedia streaming service, enterprise resource planning (ERP) cloud services with database services, etc.).

The blockchain subsystem 170 in this embodiment is composed of the blockchain computing circuit 113 in the data owner device 110, the blockchain computing circuit 133 in the data requester device 130, and the zone in the third-party service subsystem 150. The block chain operation circuit 153 is composed of a plurality of block chain nodes 161 to 167 in the block chain node cluster 160 .

In practice, the communication circuits 111, 131, and 151 can be implemented using various appropriate circuits that comply with relevant network communication, wireless communication, or mobile communication specifications, such as network interface cards (NICs), wireless transmission (Wi-Fi) circuit, or mobile communication circuit, etc. The blockchain computing circuits 113, 133, 153, and the blockchain nodes 161~167 can all be operated by one or more processor modules or computer systems suitable for performing blockchain consensus algorithm operations. Realize. Databases 115, 135, and 155 can be implemented using various relational databases or non-relational databases. Both control circuits 117 and 137 may utilize one or more computers with appropriate computing capabilities. It can be implemented by a processor module, a single computer system, or a combination of multiple computer systems. The data server 157 can be implemented by a single server or a combination of multiple servers located in the same geographical area or in different geographical areas.

In some embodiments, the blockchain computing circuit 113 may be integrated into the control circuit 117 , and/or the blockchain computing circuit 133 may be integrated into the control circuit 137 . Similarly, the blockchain computing circuit 153 can also be integrated into the data server 157 .

Please note that the aforementioned data owner device 110, data requester device 130, and third-party service subsystem 150 may be equipped with human-machine interface devices (such as monitors, keyboards, etc.) required for user control during actual implementation. mouse, touch screen, voice control module, etc.), but in order to simplify the drawing content, these human-machine interface devices are not shown in Figure 1.

In an application environment where the data owner corresponding to the data owner device 110 is an individual, the data owner device 110 can be implemented using a terminal device with networking capabilities and appropriate computing capabilities, such as a tablet computer, desktop computer, notebook, etc. Computers, mobile communication devices (such as smartphones, wearable devices, etc.), or other similar devices. Similarly, in an application environment where the data requester corresponding to the data requester device 130 is an individual, the data requester device 130 can be implemented using a terminal device with networking capabilities and appropriate computing capabilities, such as a tablet computer, desktop computer, etc. Computers, laptops, mobile communication devices (such as smartphones, wearable devices, etc.), or other similar devices.

In an application environment where the data owners corresponding to the data owner device 110 are various types of enterprises or corporate organizations, foundations, corporate associations, non-profit institutions, and government agencies, the data owner device 110 can use an appropriate device with networking capabilities. Computing capabilities of terminal equipment or information systems, such as tablet computers, desktop computers, notebook computers, mobile communication devices, computer servers, management information systems (MIS), enterprise resource planning (ERP) systems, or Other similar devices. Similarly, the data requesters corresponding to the data requester device 130 are various types of enterprises or corporate organizations, In application environments such as foundations, corporate associations, non-profit organizations, and government agencies, the data requester device 130 can be implemented using a terminal device or information system with networking capabilities and appropriate computing capabilities, such as a tablet computer, desktop computer, Laptops, mobile communication devices, computer servers, management information systems, enterprise resource planning systems, or other similar equipment.

For convenience of explanation, the specific data owner corresponding to the data owner device 110 is called data owner D1 in the following, the specific data owner corresponding to the data owner device 120 is called data owner D2, and the specific data owner corresponding to the data owner device 120 is called data owner D2. The specific data requester corresponding to the data requester device 130 is called data requester R1, and the specific data requester corresponding to the data requester device 140 is called data requester R2.

In practice, the aforementioned data owner device 110, data requester device 130, and third-party service subsystem 150 can also be implemented using virtual machines installed on various cloud platforms, or a combination of various computing entities and storage entities. Implementation and remote control by respective users.

In addition, in some application environments, the blockchain subsystem 170 can be implemented using various public chain architectures. In other application environments, the blockchain subsystem 170 can be implemented using a private chain or consortium chain architecture to shorten the time required for related operations and improve the operational efficiency of the blockchain subsystem 170 .

The following will further explain the preliminary operation process of the decentralized data authorization control system 100 for data authorization control with reference to Figures 2 to 3. FIG. 2 is a simplified flow chart of a data authorization policy management method according to an embodiment of the present invention. Figure 3 is a schematic diagram of a simplified functional module relationship between the blockchain subsystem 170 and other member devices in the decentralized data authorization control system 100.

In the flowchart of FIG. 2, the process located in the column to which a specific device belongs represents the process performed by the specific device. For example, the part marked in the "Data Owner Device" field is the process performed by one of the data owner devices 110~120; the part marked in the "Third Party Service Subsystem" field is By third party service subsystem The process performed by the system 150; the part marked in the "Blockchain Subsystem" field is the process performed by the Blockchain Subsystem 170; and so on. The aforementioned logic also applies to other subsequent flow charts.

For the sake of convenience of explanation, the following will take the scenario where the data owner D1 corresponding to the data owner device 110 wants to use the data permission control service of the decentralized data authorization control system 100 as an example to illustrate the decentralized data authorization. The preliminary operation process of the control system 100.

As shown in FIG. 2 , each time the data owner D1 wants to provide specific data to the third-party service subsystem 150 for storage, the data owner device 110 can be used to perform the process 202 . In this case, the third-party service subsystem 150 will perform the process 204 accordingly. In other words, the process 202 and the process 204 may be performed intermittently.

In process 202, the control circuit 117 can use the communication circuit 111 to provide the target data selected or provided by the data owner D1 to the third-party service subsystem 150 through various data transmission methods. In practice, the aforementioned target data can be various digital files, various program files, and/or various multimedia data, etc.

In process 204 , the communication circuit 151 of the third-party service subsystem 150 receives the target data from the data owner device 110 , and the data server 157 stores the received target data in the database 155 .

On the other hand, the operator of the blockchain subsystem 170 or a specific person with authority can use appropriate programming methods to deploy relevant smart contracts required for subsequent data authorization control in the blockchain subsystem 170 . In practical applications, the aforementioned specific persons with authority may be composed of the operating unit of the blockchain subsystem 170, the operating unit of the third-party service subsystem 150, relevant data owners, and/or relevant data requesters. Specific personnel in the work group, or specific personnel involved in the operation of the decentralized data authorization control system 100.

For example, the operator or constructor of the blockchain subsystem 170 can edit and create a smart contract containing token management rules, and use an appropriate communication device (e.g., computer) The smart contract is sent to the blockchain subsystem 170 in the form of transaction message, and the blockchain subsystem 170 is instructed to authenticate the smart contract. At this time, the blockchain subsystem 170 will perform the process 206, using multiple nodes to execute an appropriate consensus decision algorithm to authenticate the smart contract containing the token management rules. If the smart contract passes the certification of the blockchain subsystem 170, the blockchain subsystem 170 will store the smart contract in the form of a data block in the blockchain ledger of the blockchain subsystem 170 to complete the transaction. The bid management smart contract 362 is deployed to the program in the blockchain subsystem 170. In subsequent operational stages, the blockchain subsystem 170 may utilize the beacon management smart contract 362 to check and control the validity of different beacons corresponding to individual data owners.

Similarly, the operator or constructor of the blockchain subsystem 170 can edit and create a smart contract containing data authorization policy management rules, and use an appropriate communication device (eg, computer) to transmit the smart contract in the form of transaction information. to the blockchain subsystem 170, and instructs the blockchain subsystem 170 to authenticate the smart contract. At this time, the blockchain subsystem 170 will perform the process 208, using multiple nodes to execute an appropriate consensus decision algorithm to authenticate the smart contract containing the data authorization policy management rules. If the smart contract passes the certification of the blockchain subsystem 170, the blockchain subsystem 170 will store the smart contract in the form of a data block in the blockchain ledger of the blockchain subsystem 170 to complete an authorization. The policy smart contract 364 is deployed to the program in the blockchain subsystem 170 . In subsequent operational stages, the blockchain subsystem 170 may utilize the authorization policy smart contract 364 to perform version control of the data authorization policy set by individual data owners.

As shown in Figure 2, managers or operators of the third-party service subsystem 150 can use the third-party service subsystem 150 to cooperate with the blockchain subsystem 170 to perform processes 210~214 to deploy available services in the blockchain subsystem 170. The third-party service subsystem 150 checks and responds to relevant smart contracts required for data requests from other data requestor devices.

In the process 210, the data server 157 of the third-party service subsystem 150 can be controlled by its administrator or operator according to the specific service provider (herein referred to as the third-party service provider) that operates the third-party service subsystem 150. ) with one or more specific data requests The data query agreement jointly agreed upon by the parties establishes one or more corresponding data query smart contracts 366. In practice, the data server 157 can establish multiple different data query smart contracts 366 for different data requesters, or integrate different data query protocols corresponding to multiple data requesters into the same data query smart contract. Contract 366.

For example, the data server 157 can establish a dedicated data query smart contract 366 for the data requester R1 corresponding to the data requester device 130, and create another data query smart contract 366 for the data requester R2 corresponding to the data requester device 140. Different data query smart contracts 366. Alternatively, the data server 157 can also integrate the data query protocol corresponding to the data requester R1 and the data query protocol corresponding to the data requester R2 into the same data query smart contract 366.

In the process 212, the data server 157 can use the communication circuit 151 or the blockchain computing circuit 153 to use a predetermined beacon corresponding to the third-party service provider to send the generated one or more data query smart contracts 366 to Blockchain subsystem 170, and instructs the blockchain subsystem 170 to authenticate the aforementioned data query smart contract 366.

In this case, the blockchain subsystem 170 will perform the process 214 to use multiple nodes to execute an appropriate consensus decision algorithm to authenticate the received data query smart contract 366. If the data query smart contract 366 passes the certification of the blockchain subsystem 170, the blockchain subsystem 170 will store the aforementioned data query smart contract 366 in the form of a data block in the blockchain ledger of the blockchain subsystem 170. , to complete the process of deploying the aforementioned data query smart contract 366 into the blockchain subsystem 170. In the subsequent operation phase, the blockchain subsystem 170 can use the data query smart contract 366 to authenticate the third-party service subsystem 150, and the third-party service subsystem 150 can use the data query smart contract 366 to verify the individual identity. Whether the data the data requester wants to access falls within the scope of the agreement. Only when the third-party service subsystem 150 can query the identity verification program of the smart contract 366 through data, the blockchain subsystem 170 will allow the third-party service subsystem 150 to execute the authorization policy smart contract 364 or read the authorization policy intelligence. The contents of contract 364.

When the aforementioned data owner D1 wants to activate the data permission control service of the decentralized data authorization control system 100, the data owner device 110 can be used to perform the process 216. In this case, the blockchain subsystem 170 will proceed with the process 218 accordingly.

In process 216, the control circuit 117 of the data owner device 110 generates an authorization service activation request, and uses the communication circuit 111 or the blockchain operation circuit 113 to transmit the authorization service activation request to the blockchain subsystem 170.

In process 218, the blockchain subsystem 170 will execute the aforementioned beacon management smart contract 362 according to the authorization service activation request to generate an authorization corresponding to the data owner device 110 (or its corresponding data owner D1). authorization token, and transfer the authorization token to the data owner device 110. In one embodiment, the beacon management smart contract 362 can also set one or more corresponding validity check parameters for the authorization beacon, for example, a valid time-slots of use, a validity period ( expiration period), a valid geographical region, a valid owner, and/or a valid source network address, etc.

At this time, the communication circuit 111 or the blockchain operation circuit 113 of the data owner device 110 will perform the process 220 to acquire the authorization token transferred from the blockchain subsystem 170, so that the data owner device 110 becomes The current owner of the authorization beacon.

In process 222, the control circuit 117 of the data owner device 110 may, under the control of the data owner D1, encrypt the data authorization policy jointly agreed by the data owner D1 and the individual data requester to generate a corresponding data authorization Policy ciphertext (encrypted data authorization policy). The control circuit 117 can set different data authorization policies for different data requesters according to the control of the data owner D1, or can set the same data authorization policy for different data requesters. During operation, the control circuit 117 may encrypt individual data authorization policies using a predetermined encryption key to generate a corresponding data authorization policy ciphertext.

In practice, the control circuit 117 can respectively use different encryption keys to encrypt the data authorization policies corresponding to different data requesters, so as to generate multiple data authorization policy ciphertexts respectively corresponding to multiple data requesters. Alternatively, the control circuit 117 may also use the same encryption key to encrypt data authorization policies corresponding to different data requesters to generate multiple data authorization policy ciphertexts respectively corresponding to multiple data requesters. In other words, when encrypting the data authorization policies corresponding to different data requesters, the control circuit 117 can use the same encryption key, or can use different encryption keys respectively.

In process 224, the control circuit 117 may utilize the communication circuit 111 or the blockchain computing circuit 113 to transmit the generated one or more data authorization policy ciphertexts to the blockchain subsystem 170 using the authorization beacon.

In process 226 , the blockchain subsystem 170 may record one or more data authorization policy ciphertexts sent from the data owner device 110 in the authorization policy smart contract 364 as the data corresponding to the data owner device 110 . A current data authorization policy.

As can be seen from the flowchart description of FIG. 2 , the data authorization policy cipher text generated by the data owner device 110 and containing the data authorization policy will be recorded in the blockchain subsystem 170 . In this way, only a device with the correct decryption key and the right to access the blockchain subsystem 170 can read and decrypt the data authorization policy ciphertext from the blockchain subsystem 170 . This approach can significantly reduce the possibility that the data authorization policy set by the data owner device 110 will be stolen or tampered with by malicious parties.

In the decentralized data authorization control system 100, the data owners corresponding to other data owner devices (for example, the data owner D2 corresponding to the data owner device 120) can use the relevant data owners in the aforementioned manner. A device that encrypts the data authorization policy mutually agreed upon by the data owner and the individual data requester to generate one or more corresponding data authorization policy ciphertexts, and transmits the generated data authorization policy ciphertext to the blockchain subsystem 170, recorded in the authorization policy smart contract 364 by the blockchain subsystem 170.

In practice, the blockchain subsystem 170 can only establish a single authorization policy smart contract 364, and record multiple data authorization policy ciphertexts generated by different data owners in the same authorization policy smart contract 364.

Alternatively, the blockchain subsystem 170 can also establish different authorization policy smart contracts 364 for different data owners. For example, the blockchain subsystem 170 can establish a dedicated authorization policy smart contract 364 for the data owner D1 to record one or more data authorization policy ciphertexts generated by the data owner D1, and establish a dedicated authorization policy smart contract 364 for the data owner D2. Another different authorization policy smart contract 364 is used to record one or more data authorization policy ciphertexts generated by the data owner D2.

Please note that the aforementioned process execution sequence in Figure 2 is only an exemplary embodiment and does not limit the actual implementation of the present invention. For example, the order of process 202, process 206, process 208, and process 214 can be adjusted arbitrarily. Process 210 can be adjusted to be performed before process 202, or can be performed simultaneously with process 202. Process 208 can also be adjusted to be performed between process 224 and process 226.

In addition, the operator or constructor of the blockchain subsystem 170 can also use other methods to deploy the aforementioned data query smart contract 366 into the blockchain subsystem 170. In this case, the process 210 and the process 212 can be omitted. .

Next, please refer to FIG. 4 , which illustrates a simplified flow chart of a method for checking whether the data authorization policy in the blockchain subsystem 170 is correct according to an embodiment of the present invention.

As mentioned above, only a device with the correct decryption key and the right to access the blockchain subsystem 170 can read and decrypt the data authorization policy ciphertext generated by the data owner device 110 from the blockchain subsystem 170 .

In some applications, more serious data requesters may need to check whether the content of the data authorization policy cipher text stored in the blockchain subsystem 170 and generated by the data owner device 110 is consistent with the data requester and the data. The version agreed upon by owner D1 matches.

For the convenience of explanation, below the data requester R1 corresponding to the data requester device 130 needs to check the correctness of the data authorization policy generated by the data owner device 110 Taking a sex scenario as an example to illustrate the relevant operation process of the decentralized data authorization control system 100 in Figure 4 .

In order to allow the data requester device 130 to check the correctness of the data authorization policy generated by the data owner device 110, the data owner device 110 can perform the process 402 in Figure 4 under the control of the corresponding data owner D1. In this case, the data requester device 130 will perform the process 404 accordingly.

In process 402, the control circuit 117 of the data owner device 110 may transmit an identification data (hereinafter referred to as token identification data) of the authorization token corresponding to the data owner device 110 through the communication circuit 111, and a target key that can be used to decrypt the data authorization policy ciphertext corresponding to the data requester R1 to the data requester device 130 .

In process 404, the communication circuit 131 of the data requester device 130 will receive the beacon identification data and the target key transmitted from the data owner device 110, and the control circuit 137 may convert the received beacon identification data and target key , stored in the database 135 or other suitable storage circuits (not shown in the figure).

When the data requester R1 corresponding to the data requester device 130 wants to check the correctness of the data authorization policy cipher text stored in the blockchain subsystem 170 and generated by the data owner device 110, the data requester can be used Device 130 proceeds to process 406.

In process 406, the control circuit 137 of the data requester device 130 may generate an authorization policy inquiry request related to the aforementioned beacon identification data, and use the communication circuit 131 or the blockchain computing circuit 133 to The authorization policy query request is transmitted to the blockchain subsystem 170. For example, the control circuit 137 can fill in the token identification data into appropriate fields of the authorization policy query request, or use the token identification data as additional information in the authorization policy query request.

In this case, the blockchain subsystem 170 will perform the process 408 to receive the authorization policy query request from the data requester device 130 .

Next, the blockchain subsystem 170 will proceed to process 410 to execute the authorization policy smart contract. 364 to find out the data authorization policy cipher text corresponding to the authorization policy query request. For example, the blockchain subsystem 170 can obtain a corresponding beacon identification data based on the authorization policy query request, and then find out the data authorization policy written in the authorization policy smart contract 364 using the authorization beacon corresponding to the beacon identification data. cipher text.

Since only the data owner device 110 has the right to use the authorization beacon corresponding to the beacon identification data, the blockchain subsystem 170 can find the data owner device 110 from the authorization policy smart contract 364 based on the beacon identification data. The generated data authorization policy secret text.

In process 412, the blockchain subsystem 170 transmits the data authorization policy ciphertext to the data requester device 130.

In process 414, the communication circuit 131 or the blockchain computing circuit 133 of the data requester device 130 receives the data authorization policy cipher text from the blockchain subsystem 170.

In process 416, the control circuit 137 may use the target key provided by the data owner device 110 to decrypt the data authorization policy ciphertext to obtain the decrypted data authorization policy.

Then, the control circuit 137 can perform the process 418 to check whether the decrypted data authorization policy is jointly agreed by the data owner D1 corresponding to the data owner device 110 and the data requester R1 corresponding to the data requester device 130 A scheduled version matches.

If the decrypted data authorization policy is inconsistent with the predetermined version agreed by both parties, the data requester R1 can report this problem to the data owner D1 through various channels to reduce the possibility of unnecessary misunderstandings between the two parties in the future.

If the decrypted data authorization policy is consistent with the predetermined version agreed by both parties, the data requester R1 can confirm that the cipher text of the data authorization policy stored on the blockchain subsystem 170 is correct.

In the decentralized data authorization control system 100, the data requester R1 can use the data requester device 130 in the aforementioned manner to verify the information recorded in the blockchain subsystem 170 by other data owners (for example, the data owner D2) Whether the content of the data authorization policy cipher text set and corresponding to the data requester R1 is correct.

Similarly, other data requesters in the decentralized data authorization control system 100 (for example, the data requestor R2 corresponding to the data requester device 140) can also use the relevant data requestor device to check in the aforementioned manner. Whether the content of the data authorization policy cipher text recorded in the blockchain subsystem 170, set by the data owner D1 (or other data owners), and corresponding to the data requester is correct.

Please refer to FIG. 5 , which illustrates a simplified flow chart of a method for providing a searchable data list according to an embodiment of the present invention.

In many application environments, the data owner will store many data of different types or attributes in the third-party service subsystem 150, but may not want the third-party service subsystem 150 to share all the data owner's data with other parties. Data Requester.

In order to prevent the data requestor from requesting data items from the third-party service subsystem 150 that exceeds the scope of the data owner's authorization, resulting in the data requester's data request being rejected by the third-party service subsystem 150, the data requester can first Request the third-party service subsystem 150 to provide a list of data that the data requester is entitled to obtain (hereinafter referred to as an accessible data list), so that the data requester can select the data items he wants to query.

For convenience of explanation, in the following, the data requester R1 corresponding to the data requester device 130 will request the third-party service subsystem 150 to provide a document containing the consent of the data owner D1 corresponding to the data owner device 110 to allow the data requester The scenario of all data types queried by R1 or the queryable data list of data items is taken as an example to illustrate the relevant operation process of the decentralized data authorization control system 100 in Figure 5.

As shown in FIG. 5 , the data requester device 130 may perform the process 502 under the control of the data requester R1.

In process 502, the control circuit 137 of the data requester device 130 may generate a data list request including the beacon identification data and the target key provided by the data owner device 110, and transmit the data list through the communication circuit 131. Request to third-party service subsystem 150. In this case, the third-party service subsystem 150 will perform process 504 accordingly.

In process 504, the communication circuit 151 receives the data list request and the target key from the data requester device 130. The data server 157 can obtain the aforementioned beacon identification data from the data list request.

In process 506, the data server 157 of the third-party service subsystem 150 may generate an authorization policy query request related to the aforementioned beacon identification data, and transmit the authorization policy query request through the communication circuit 151 or the blockchain computing circuit 153. Sent to the blockchain subsystem 170. For example, the data server 157 can fill in the token identification data into appropriate fields of the authorization policy query request, or use the token identification data as additional information in the authorization policy query request.

In this case, the blockchain subsystem 170 will perform process 508 to receive the authorization policy query request from the third-party service subsystem 150 .

Next, the blockchain subsystem 170 will perform the process 510 to execute the authorization policy smart contract 364 to find out the data authorization policy cipher text corresponding to the authorization policy query request. For example, the blockchain subsystem 170 can obtain a corresponding beacon identification data based on the authorization policy query request, and then find out the data authorization policy written in the authorization policy smart contract 364 using the authorization beacon corresponding to the beacon identification data. cipher text.

Since only the data owner device 110 has the right to use the authorization beacon corresponding to the beacon identification data, the blockchain subsystem 170 can find the data owner device 110 from the authorization policy smart contract 364 based on the beacon identification data. The generated data authorization policy secret text.

In process 512, the blockchain subsystem 170 will transmit the data authorization policy ciphertext to the third-party service subsystem 150.

In process 514, the communication circuit 151 or the blockchain computing circuit 153 of the third-party service subsystem 150 receives the data authorization policy cipher text from the blockchain subsystem 170.

In process 516, the data server 157 may use the target key provided by the data requester device 130 to decrypt the data authorization policy ciphertext to obtain the decrypted data authorization policy. From the aforementioned process 222, process 224, process 226, process 402, and process 502 It can be seen from the description that the data server 157 can successfully decrypt the data authorization policy ciphertext only if the target key is the correct decryption key provided by the data owner device 110 to the data requester device 130 . This approach can effectively ensure the confidentiality of the data authorization policy set by the data owner D1 and prevent the third-party service subsystem 150 or other devices from obtaining the data authorization policy set by the data owner D1 without appropriate authorization.

In process 518, the data server 157 can request the blockchain subsystem 170 to execute the data query smart contract 366 through the communication circuit 151 or the blockchain computing circuit 153 according to the decrypted data authorization policy to generate data related to the data owner D1. Part of the provided target data (ie, data types or data items that the data owner D1 agrees to be queried by the data requester R1) corresponds to a searchable data list.

In process 520, the data server 157 may transmit the aforementioned queryable data list to the data requester device 130 through the communication circuit 151. In this case, the data requester device 130 will perform the process 522 accordingly to receive the queryable data list from the third-party service subsystem 150 .

In this way, the data requester R1 can clearly know the relevant information of the data range, data type, or data items that the data owner D1 agreed to allow the data requester R1 to query from the queryable data list.

Similarly, the data requester device 130 can query the third-party service subsystem 150 in the aforementioned manner for the data range, data type, and data items that other data owners (for example, the data owner D2) agree to allow the data requester R1 to query. information.

In the decentralized data authorization control system 100, other data requesters (for example, the data requester R2 corresponding to the data requester device 140) can also use the relevant data requestor device to provide services to third parties in the aforementioned manner. The subsystem 150 queries the relevant information of the data scope, data type, and data items that the data owner D1 (or other data owners) agrees to allow the data requester to query.

As mentioned earlier, individual data requesters can use the relevant data requestor device to submit data to the district. The blockchain subsystem 170 applies for a data access beacon corresponding to a specific data owner. When a data requester wants to obtain specific data of a specific data owner, the corresponding data requester device can be controlled to use the data access beacon provided by the blockchain subsystem 170 to request data access to the third-party service subsystem 150 request.

The third-party service subsystem 150 can use the blockchain subsystem 170 to verify the validity of the data access beacon provided by the data requester's device to verify the identity of the data requester. Only when the validity of the data access beacon can be verified by the blockchain subsystem 170, the third-party service subsystem 150 will share the specific data content authorized by the specific data owner to the data requester device.

The following will further illustrate with reference to Figures 6 and 7 that the data requestor uses the data requestor device to apply for a data access beacon to the blockchain subsystem 170, and uses the data access beacon to request data access to the third-party service subsystem 150. Use the request method. FIG. 6 is a simplified flow chart of a method for generating access signals according to an embodiment of the present invention. FIG. 7 is a simplified flow chart of a data request response method according to an embodiment of the present invention.

For the convenience of explanation, in the following, the data requester R1 uses the data requester device 130 to apply for a data access beacon to the blockchain subsystem 170, and uses the data access beacon to request the third-party service subsystem 150 to provide data possession. Taking the partial data situation of D1 as an example to illustrate the relevant operation processes of the decentralized data authorization control system 100 in Figures 6 and 7.

As shown in FIG. 6 , the data requester device 130 can perform processes 602 and 604 under the control of the data requester R1.

In process 602, the control circuit 137 of the data requester device 130 may generate a first data request corresponding to one or more data items according to the settings or selections of the data requester R1. For example, the control circuit 137 may arrange or organize the one or more data items in various suitable data formats, and then fill in the appropriate fields of the first data request in an interpretable (interpretable) form, as the An attachment to the first data request, or directly used as the first data request.

In process 604, the control circuit 137 may generate a first token request (first token request) including token identification data corresponding to the data owner device 110, and transmit the first token request to the first token request through the communication circuit 131. Third-party service subsystem 150. In this case, the third-party service subsystem 150 will perform process 606 accordingly.

In process 606, the communication circuit 151 receives the first beacon request from the data requester device 130.

In process 608, the data server 157 will forward the first token request to the blockchain subsystem 170 through the communication circuit 151 or the blockchain computing circuit 153. In this case, the blockchain subsystem 170 will perform the process 610 accordingly to receive the first beacon request from the third-party service subsystem 150 .

In process 612, the blockchain subsystem 170 executes the beacon management smart contract 362 to obtain a beacon identification data corresponding to the first beacon request.

In process 614, the blockchain subsystem 170 will also execute the beacon management smart contract 362 to verify the validity of an authorization beacon corresponding to the beacon identification data. For example, the beacon management smart contract 362 can check whether the relevant parameters of the authorized beacon are consistent with the validity check parameters previously set by the beacon management smart contract 362 in the process 218.

In one embodiment, the beacon management smart contract 362 may determine the authorization beacon as an inactive message when some parameters of the authorization beacon do not meet the validity check parameters set in the aforementioned process 218. mark. In another embodiment, the beacon management smart contract 362 will determine the authorization beacon as invalid only when all parameters of the authorization beacon do not meet the validity check parameters set in the aforementioned process 218. Otherwise, The authorization beacon will be determined as an active beacon.

If the beacon management smart contract 362 determines that the authorized beacon is an invalid beacon, the beacon management smart contract 362 will proceed to process 616. On the contrary, if the beacon management smart contract 362 determines that the authorized beacon is a valid beacon, the beacon management smart contract 362 will proceed to process 618.

In process 616, the beacon management smart contract 362 will reject the first beacon request and may Send corresponding notification information to the third-party service subsystem 150. In this case, the third-party service subsystem 150 will send a corresponding failure notification to the data requester device 130 .

In process 618, the token management smart contract 362 will generate a first read token corresponding to the authorization token, and may set a corresponding validity period for the first read token. For example, 5 days, 10 days, 1 week, 2 weeks, 1 month, etc. The validity period set by the beacon management smart contract 362 for the first access beacon will be equal to or shorter than the validity period of the authorized beacon. In practice, the beacon management smart contract 362 can establish appropriate data correlation or validity correlation between the first access beacon and the authorization beacon, and can jointly and severally execute the authorization beacon when the authorization beacon expires. Deactivate the first access beacon.

In process 620 , the blockchain subsystem 170 may directly or indirectly transfer the first access token to the data requestor device 130 . For example, the blockchain subsystem 170 may transfer the first access beacon to the third-party service subsystem 150, and then the third-party service subsystem 150 transfers it to the data requester device 130. Alternatively, the blockchain subsystem 170 may also transfer the first access beacon directly to the data requestor device 130 .

In this case, the communication circuit 131 or the blockchain operation circuit 133 of the data requester device 130 can perform the process 622 to obtain the first access transferred from the third-party service subsystem 150 or the blockchain subsystem 170 beacon.

It can be seen from the flowchart description of FIG. 6 that only when the authorization token transferred to the data owner device 110 by the token management smart contract 362 in the aforementioned process 218 is a valid token, the token in the blockchain subsystem 170 The management smart contract 362 will generate a first access beacon associated with the authorization beacon and transfer the first access beacon to the data requester device 130 .

In other words, if the blockchain subsystem 170 changes the authorization information corresponding to the data owner device 110 due to various reasons (for example, the data owner D1 terminates the use of the services of the decentralized data authorization control system 100 or is suspended), mark deactivate, the blockchain subsystem 170 will no longer provide access to relevant data of the data owner D1. Use beacons to other data requesters. Obviously, such a mechanism can avoid the possibility of improper access to the relevant information of the data owner D1, and helps to improve the protection level of the relevant information of the data owner D1.

After the data requester device 130 obtains the aforementioned first access beacon, the data requester R1 can use the data requester device 130 to request relevant data of the data owner D1 from the third-party service subsystem 150. Process 702 in Figure 7.

In the process 702, the control circuit 137 of the data requester device 130 may transmit the first data request generated in the process 602 to the third-party service subsystem 150 through the communication circuit 131, and utilize the communication circuit 131 or blockchain operation. Circuit 133 transfers the first access beacon to the third-party service subsystem 150 . At this time, the third-party service subsystem 150 will perform process 704 accordingly.

In process 704, the communication circuit 151 of the third-party service subsystem 150 will receive the first data request from the data requester device 130, and the communication circuit 151 or the blockchain operation circuit 153 will obtain the transfer information of the data requester device 130. The first fetch beacon that comes over.

Next, the third-party service subsystem 150 may utilize the blockchain subsystem 170 to verify the validity of the first data request and verify the activity of the first access beacon.

For example, the data server 157 may perform process 706 to request the blockchain subsystem 170 to execute the data query smart contract 366 to verify the eligibility of the first data request. In practice, the data query smart contract 366 can check whether one or more data items corresponding to the first data request are within the scope of the queryable data list generated in the process 518.

If the one or more data items corresponding to the first data request are within the scope of the queryable data list, the data query smart contract 366 will determine that the first data request is a valid data request. Next, the third-party service subsystem 150 will perform process 708.

On the contrary, if some of the data items corresponding to the first data request exceed the queryable data If the list is not covered by the list, the data query smart contract 366 will determine that the first data request is an invalid data request, and then the third-party service subsystem 150 will proceed to process 710.

In process 708, the data server 157 will transfer the first access token to the blockchain subsystem 170 through the communication circuit 151 or the blockchain computing circuit 153. In this case, the blockchain subsystem 170 will perform the process 712 accordingly.

In process 710, the data server 157 rejects the first data request and may send a corresponding rejection notification to the data requester device 130.

In process 712, the blockchain subsystem 170 obtains the first access token transferred from the third-party service subsystem 150.

Next, the blockchain subsystem 170 will perform the process 714 to execute the beacon management smart contract 362 to verify the validity of the first retrieved beacon. As mentioned above, the token management smart contract 362 can set a corresponding validity period for the first access token in the aforementioned process 618. In process 714, the token management smart contract 362 may check whether the time when the blockchain subsystem 170 obtains the first access token exceeds the validity period set in the process 618.

If the time when the blockchain subsystem 170 obtains the first access beacon exceeds the validity period set by the beacon management smart contract 362 in the process 618, the beacon management smart contract 362 will retrieve the first access beacon. The signal is determined to be inactive, and process 716 is performed.

On the contrary, if the time when the blockchain subsystem 170 obtains the first access beacon has not exceeded the validity period set by the beacon management smart contract 362 in the process 618, the beacon management smart contract 362 will retrieve the first access beacon. The beacon is determined to be an active beacon, and process 720 is performed.

In another embodiment, when the blockchain subsystem 170 executes the token management smart contract 362 to verify the validity of the first access token, it will check that the first access token is transferred to the blockchain subsystem 170 Before, whether the data requester device 130 is transferred to a third-party service sub- The system 150 will also check whether the time point when the third-party service subsystem 150 transfers the first access token to the blockchain subsystem 170 exceeds the validity period. In this embodiment, only when the time when the blockchain subsystem 170 obtains the first access beacon has not exceeded the validity period, and the first access beacon is obtained by the data requester before being transferred to the blockchain subsystem 170 When the device 130 is transferred to the third-party service subsystem 150, the token management smart contract 362 will determine the first retrieved token as a valid token and proceed to process 720. Otherwise, the beacon management smart contract 362 will determine the first retrieved beacon as an invalid beacon and proceed to process 716.

In process 716, the beacon management smart contract 362 generates and sends a verification failure notification to the third-party service subsystem 150. In this case, the third-party service subsystem 150 will perform the process 718 accordingly to receive the verification failure notification and send a corresponding rejection notification to the data requester device 130 .

In process 720, the token management smart contract 362 will generate and send a verification success notification to the third-party service subsystem 150, and deactivate the first access token. In this case, the third-party service subsystem 150 will perform process 722 accordingly to receive the verification success notification.

Next, the data server 157 of the third-party service subsystem 150 will perform the process 724 to find the contents of one or more data items corresponding to the first data request from the target data stored in the database 155 to form a The first set of information.

In process 726, the data server 157 sends the first set of data to the data requester device 130 through the communication circuit 151. At this time, the communication circuit 131 of the data requester device 130 will perform the process 728 accordingly to receive the first set of data provided by the third-party service subsystem 150 .

On the other hand, as shown in Figure 7, after determining that the first access beacon is a valid beacon, the beacon management smart contract 362 will also perform process 730 to record an acquisition time of the first access beacon ( For example, the occurrence time of process 712) or a verification time (eg, the occurrence time of process 714 or process 720).

The relevant time information of the first access beacon recorded by the blockchain subsystem 170 in the process 730 can be used as evidence that the third-party service subsystem 150 provides the relevant information of the data owner D1 to the data requester device 130 .

It can be seen from the flowchart description of FIG. 7 that only the data query smart contract 366 in the blockchain subsystem 170 determines that the first data request is a qualified data request, and the token management smart contract 362 also determines the first access information. Only when the request is marked as a valid beacon, the third-party service subsystem 150 will provide the first set of data corresponding to the first data request to the data requester device 130 .

In other words, as long as the first data request is unqualified or the first access beacon is invalid, the third-party service subsystem 150 will not provide relevant data of the data owner D1 to the data requester device 130 . Therefore, the aforementioned third-party service subsystem 150 uses the blockchain subsystem 170 to verify the eligibility of the first data request and the validity of the first access beacon, which can effectively prevent the relevant data of the data owner D1 The possibility of improper access will help to significantly improve the level of protection of data owner D1's related data.

In addition, based on the characteristics of the blockchain subsystem 170, the relevant time information of the first access token recorded in the blockchain subsystem 170 is difficult to be tampered with, so it can be used to provide data for the third-party service subsystem 150. The relevant information of the person D1 is provided to the data requester device 130 as evidence, which helps to reduce the possibility of disputes between the third-party service subsystem 150 and the data requester device 130 that are difficult to resolve.

Please note that the aforementioned flow execution sequence in FIG. 6 and FIG. 7 is only an exemplary embodiment and does not limit the actual implementation of the present invention. For example, process 602 in Figure 6 can be adjusted to be performed at any time point between process 604 and process 702. For another example, the two actions of the data requester device 130 in the aforementioned process 702 can be performed at the same time or one after another. As another example, process 730 in Figure 7 can be adjusted to be performed at any time point between process 712 and process 720. As another example, process 724 in Figure 7 can be adjusted to be performed at any time point between process 704 and process 722.

In the aforementioned process 604, the data requester device 130 may also change the first beacon request to Directly transmitted to the blockchain subsystem 170. In this case, the process 606 and the process 608 in FIG. 6 can be omitted.

In addition, in some embodiments that can ensure that the data requester device 130 will generate the aforementioned first data request according to the queryable data list provided by the third-party service subsystem 150, the process 706 in Figure 7 can be and process 710 are omitted.

In the decentralized data authorization control system 100, each data access beacon transferred by the blockchain subsystem 170 to the data requester device 130 only allows the data requester device 130 to request from the third-party service subsystem 150. One-time data, and the blockchain subsystem 170 will record the time point information when each data access beacon is used. Therefore, after the data requester device 130 successfully obtains the first set of data provided by the third-party service subsystem 150 through the aforementioned methods of FIG. 6 and FIG. 7 , if the data requester device 130 wants to request the third-party service subsystem again, In order for the system 150 to provide relevant data of the data owner D1, the operation processes in Figures 8 and 9 must be performed.

The operation processes of Figures 8 and 9 are very similar to the operation processes of Figures 6 and 7. The difference lies in the first data request, the first beacon request, the first acquisition mentioned in the operation processes of Figures 6 and 7. The use beacon and the first set of data are replaced by the second data request, the second beacon request, the second access beacon and the second set of data in the operation processes of Figures 8 and 9 respectively.

Similar to the situations of FIG. 6 and FIG. 7 , only when the authorization token transferred by the token management smart contract 362 to the data owner device 110 in the aforementioned process 218 is a valid token, the block chain subsystem 170 The beacon management smart contract 362 will generate a second access beacon associated with the authorization beacon and transfer the second access beacon to the data requester device 130 .

In other words, within the validity period of the authorization beacon, the beacon management smart contract 362 can generate multiple beacon requests related to the authorization beacon for multiple beacon requests made by the same data requester or different data requesters. Access beacons, and the validity period of individual access beacons may vary.

Similarly, only if the data query smart contract 366 in the blockchain subsystem 170 determines that the second data request is a qualified data request, and the token management smart contract 362 also determines that the second access token is a valid token. Only then will the third-party service subsystem 150 provide the second set of data corresponding to the second data request to the data requester device 130 .

Based on the characteristics of the blockchain subsystem 170, the relevant time information of the second access token recorded in the blockchain subsystem 170 is difficult to be tampered with, so it can be used as a third-party service subsystem 150 to provide data again. The relevant information of the person D1 is provided to the data requester device 130 as evidence.

Please note that from the above description, it can be known that the data access beacon used each time by the data requester device 130 (for example, the aforementioned first access beacon and the second access beacon) is finally used by the blockchain subsystem 170 Deregistration is equivalent to the fact that the blockchain subsystem 170 finally recovers these data access beacons, rather than the third-party service subsystem 150 recovering these data access beacons. Such a structure can effectively reduce the possibility of disputes between third-party service providers and data requesters.

The data requester device 130 corresponding to the data requester R1 can apply to the blockchain subsystem 170 through the third-party service subsystem 150 (or directly apply to the blockchain subsystem 170) in the manner described in Figures 6 to 9. The data access beacon required for the relevant data of other data owners (for example, data owner D2), and uses the data access beacon to request the third-party service subsystem 150 to access the relevant data.

In the decentralized data authorization control system 100, other data requester devices (for example, the data requester device 140 corresponding to the data requester R2) can also submit requests to the blockchain subsystem through the third-party service subsystem 150 in the aforementioned manner. The system 170 applies (or applies directly to the blockchain subsystem 170) for the data access beacon required to query the relevant information of the data owner D1 (or other data owners), and uses the data access beacon to request the third party The service subsystem 150 requests the relevant information.

Similarly, the third-party service subsystem 150 can use the blockchain subsystem 170 to check the validity of the access beacon request generated by the relevant data requester device and the appropriateness of the data request. character, and the effectiveness of access beacons.

Please refer to FIG. 10 , which illustrates a simplified flow chart of a method for dynamically updating a data authorization policy according to an embodiment of the present invention.

As mentioned above, in the decentralized data authorization control system 100, individual data owners can dynamically adjust the data authorization policy stored in the blockchain subsystem 170 as needed. In addition, individual data owners and third-party service providers can also dynamically adjust the data query agreement between the two parties and modify the corresponding data query smart contract.

For the convenience of explanation, the following will take as an example a scenario in which the data owner D1 uses the data owner device 110 to dynamically adjust the data authorization policy stored in the blockchain subsystem 170 to illustrate the decentralized data authorization control system 100. The relevant operation process in Figure 10.

When the data owner D1 and the aforementioned third-party service provider decide to modify the original data query agreement, the data owner D1 can use the data owner device 110 to perform the process 1002 in FIG. 10 .

In process 1002, the control circuit 117 may generate a protocol update notification and transmit the protocol update notification to the third-party service subsystem 150 through the communication circuit 111. At this time, the communication circuit 151 of the third-party service subsystem 150 will perform the process 1004 accordingly to receive the protocol update notification from the data owner device 110 .

Then, the data server 157 of the third-party service subsystem 150 can perform the process 1006 under the control of its administrator or operator, in accordance with the new data query agreement jointly agreed between the third-party service provider and a certain data requester A, Create an updated data query smart contract 366.

In process 1008, the data server 157 can use the communication circuit 151 or the blockchain computing circuit 153 to send the updated data query smart contract 366 to the blockchain using a predetermined beacon corresponding to the third-party service provider. system 170, and instructs the blockchain subsystem 170 to authenticate the updated data query smart contract 366.

In this case, the blockchain subsystem 170 will perform the process 1010, using multiple nodes to execute an appropriate consensus decision algorithm to recognize the updated data query smart contract 366. Certificate. If the updated data query smart contract 366 passes the certification of the blockchain subsystem 170, the blockchain subsystem 170 will store the updated data query smart contract 366 in the form of a data block in the block of the blockchain subsystem 170 in the chain ledger to complete the process of deploying the updated data query smart contract 366 into the blockchain subsystem 170. In the subsequent operation stage, the third-party service subsystem 150 can use the updated data query smart contract 366 to check and determine the scope, type, attribute, or item of data that the individual data requester is entitled to access.

On the other hand, when the data owner D1 believes that its data authorization policy needs to be adjusted, the data owner device 110 can be used to perform the process 1012 in FIG. 10 .

In process 1012, the control circuit 117 will encrypt the new data authorization policy jointly agreed by the data owner D1 and the relevant data requester, or the new data authorization policy adjusted by the data owner D1, to generate updated data. Authorization policy secret text.

Then, the control circuit 117 can perform the process 1014 to use the communication circuit 111 or the blockchain computing circuit 113 to use the authorization token corresponding to the data owner D1 to transmit the updated data authorization policy ciphertext to the blockchain subsystem 170 .

At this time, the blockchain subsystem 170 will perform the process 1016 to record the updated data authorization policy ciphertext sent from the data owner device 110 in the authorization policy smart contract 364 to replace the original data authorization policy ciphertext. Becomes the currently valid data authorization policy ciphertext corresponding to the data owner device 110 .

As can be seen from the foregoing description, the historical version of the data authorization policy ciphertext generated by the data owner device 110 and containing the data authorization policy will be recorded in the blockchain subsystem 170 . A device with the correct decryption key and the right to access the blockchain subsystem 170 can read and decrypt the historical version of the data authorization policy ciphertext set by the data owner D1 from the blockchain subsystem 170 . On the one hand, such a mechanism can ensure that the data owner's data authorization policy has sufficient confidentiality; on the other hand, it can improve the transparency of the data owner's data authorization policy to stakeholders. It is the best of both worlds and will not be too biased towards either party. Balanced architecture.

The third-party service subsystem 150 can dynamically adjust the content of the data query smart contract 366 corresponding to other data requesters (for example, data requester R2) in the manner described in Figure 10, thereby updating the data corresponding to individual data requesters. Query protocol. In this way, the third-party service subsystem 150 can flexibly adjust the data range, data type, and/or data content that other data requesters can request.

On the other hand, other data owners in the decentralized data authorization control system 100 (for example, the data owner D2 corresponding to the data owner device 120) can use the relevant data owners in the manner described in Figure 10. Device to dynamically adjust the relevant data authorization policy cipher text recorded in the authorization policy smart contract 364, thereby updating the data authorization policy set by the data owner for a specific data requester or all data requesters. In this way, the data owner can flexibly adjust the data scope, data type, and/or data content when authorizing the third-party service subsystem 150 to provide data to a specific data requester or all data requesters.

As can be seen from the foregoing description, a device that has access to the blockchain subsystem 170 and has a correct decryption key can decrypt and verify the data authorization policy ciphertext recorded in the blockchain subsystem 170 . Therefore, using the blockchain subsystem 170 to replace the traditional centralized authorization server can effectively improve the transparency of the authorization policy management of the decentralized data authorization control system 100, thereby reducing the risk of the third-party service subsystem 150 interacting with the data owner. or the possibility of disputes between data requesters.

Another advantage of the aforementioned decentralized data authorization control system 100 is that it can meet various requirements of the EU GDPR, and can allow data owners to dynamically adjust their data authorization policies at any time as needed, with higher authorization policy adjustment flexibility.

In addition, the data authorization policy of the individual data owner is stored in the blockchain subsystem 170 in an encrypted form, and only a device with the correct decryption key and the right to access the blockchain subsystem 170 can access the data from the blockchain subsystem 170. 170 to read and decrypt the relevant data authorization policy ciphertext. This approach can significantly reduce the risk of data authorization policies set by individual data owners being stolen or tampered with by malicious parties.

Furthermore, the individual data requester installs the data access beacon used each time (for example, the aforementioned first access beacon and the second access beacon), and is finally logged out by the blockchain subsystem 170 . In other words, these data access beacons are finally recovered by the blockchain subsystem 170 rather than by the third-party service subsystem 150 . Such a structure can effectively reduce the possibility of disputes between third-party service providers and data requesters.

On the other hand, the authorization policy control method adopted by the decentralized data authorization control system 100 is to use the blockchain and smart contract architecture to automatically complete the application and transfer procedures of the data access token and the validity of the authorization token. Verification procedures, data request eligibility verification procedures, and access beacon validity verification procedures can greatly improve the efficiency and accuracy of the data authorization control process, and at the same time significantly reduce the manpower and time required, making it more effective This avoids the risk of the relevant authorization policy ciphertext and the time record of accessing the beacon stored in the blockchain subsystem 170 being tampered with by malicious parties afterwards.

In practice, the number of third-party service subsystems in the aforementioned decentralized data authorization and control system 100 can be increased according to the needs of the actual application environment, and is not limited to the form shown in the aforementioned embodiment.

In some embodiments, the database 115 and/or the blockchain computing circuit 113 in the aforementioned data owner device 110 can be omitted, or the database 115 and/or the blockchain computing circuit 113 can be made independent of the data owner. or device 110.

In addition, in some embodiments, the database 135 and/or the blockchain computing circuit 133 in the aforementioned data requester device 130 can be omitted, or the database 135 and/or the blockchain computing circuit 133 can be made independent of outside of the data requestor device 130.

Similarly, in some embodiments, the database 155 and/or the blockchain computing circuit 153 in the aforementioned third-party service subsystem 150 can be omitted, or the database 155 and/or the blockchain computing circuit 153 can be omitted. Independent from the third-party service subsystem 150.

Certain words are used in the specification and patent application to refer to specific components, but those skilled in the art may use different terms to refer to the same component. This specification and patent application do not use differences in names as a way to distinguish components; The difference in functionality of components is used as the basis for differentiation. The "include" mentioned in the specification and patent application scope is an open-ended term and should be interpreted as "include but not limited to". In addition, the word "coupling" here includes any direct and indirect connection means. Therefore, if a first element is described as being coupled to a second element, it means that the first element can be directly connected to the second element through electrical connection or signal connection such as wireless transmission or optical transmission, or through other elements or connections. Means are indirectly electrically or signal connected to the second element.

The description "and/or" used in the specification includes one or any combination of multiple listed items. In addition, unless otherwise specified in the specification, any term in the singular shall also include the plural.

The above are only preferred embodiments of the present invention, and all equivalent changes and modifications made in accordance with the claims of the present invention shall fall within the scope of the present invention.

100: Decentralized data authorization control system

110, 120: Data owner device

111, 131, 151: Communication circuit

113, 133, 153: Blockchain computing circuit

115, 135, 155: database

117, 137: Control circuit

130, 140: Data requester device

150:Third-party service subsystem

157:Data server

160: Blockchain node cluster

161~167: Blockchain node

170:Blockchain subsystem

Claims (6)

A decentralized data authorization control system (100), including: a data owner device (110) configured to provide target data; a third-party service subsystem (150) configured to store the target data; a data request a device (130) configured to generate a first data request corresponding to one or more data items and generate a first beacon request including a beacon identification data; and a blockchain subsystem (170), Contains multiple blockchain nodes (161~167), configured to execute a beacon management smart contract (362) to obtain a beacon identification data corresponding to the first beacon request, and to verify the beacon identification data. The validity of a corresponding authorization beacon, and if the authorization beacon is valid, the blockchain subsystem (170) is also configured to generate a first access beacon corresponding to the authorization beacon, wherein the authorization The beacon is generated by the blockchain subsystem (170) executing the beacon management smart contract (362) and transferred to the data owner device (110); wherein the data requester device (130) is also configured to After obtaining the first access beacon, transmit the first data request to the third-party service subsystem (150), and transfer the first access beacon to the third-party service subsystem (150); wherein , the third-party service subsystem (150) is also configured to transfer the first access token to the blockchain subsystem (170) after receiving the first data request; wherein, the blockchain subsystem (170) 170) is also configured to verify the validity of the first access beacon, and after the blockchain subsystem (170) determines that the first access beacon is a valid beacon, the blockchain subsystem (170) will also Generate and send a verification success notification to the third-party service subsystem (150); wherein the third-party service subsystem (150) will also find a first group corresponding to the first data request from the target data information, and if the third-party service subsystem (150) receives the verification success notification, the third-party service subsystem (150) The first set of data will be sent to the data requester device (130); wherein, the data owner device (110) will not receive the first data request, will not be involved in the processing of the first data request, and will not The first access beacon will be generated, the first access beacon will not be obtained, and the verification process of the validity of the first access beacon will not be involved; wherein, the data owner device (110) will A data authorization policy ciphertext is transmitted to the blockchain subsystem (170), and the blockchain subsystem (170) records the data authorization policy ciphertext in an authorization policy smart contract (364). The decentralized data authorization control system (100) as described in claim 1, wherein the blockchain subsystem (170) is also configured to generate the first access signal when the first access signal is generated. The token sets a corresponding validity period; wherein, when verifying the validity of the first access token, the blockchain subsystem (170) will check that the first access token is transferred to the blockchain subsystem (170), whether the data requester device (130) is transferred to the third-party service subsystem (150), and the blockchain subsystem (170) will also check the third-party service subsystem (150) ) whether the time point at which the first access token is transferred to the blockchain subsystem (170) exceeds the validity period. As for the decentralized data authorization control system (100) described in claim 1, the blockchain subsystem (170) will also record an acquisition time or a verification time of the first access beacon. A decentralized data authorization control system (100), including: a third-party service subsystem (150) configured to store target data provided by a data owner device (110); a data requester device (130) , configured to generate a first data request corresponding to one or more data items and generate a first beacon request including a beacon identification data; and a blockchain subsystem (170) including a plurality of blocks Chain node (161~167), settings Execute a beacon management smart contract (362) to obtain a beacon identification data corresponding to the first beacon request, and verify the validity of an authorization beacon corresponding to the beacon identification data, and if the authorization information marked as valid, the blockchain subsystem (170) is also configured to generate a first access beacon corresponding to the authorization beacon, wherein the authorization beacon is executed by the blockchain subsystem (170). The beacon management smart contract (362) is generated and transferred to the data owner device (110); wherein the data requester device (130) is also configured to transmit the third access beacon after acquiring the first access beacon. A data request is made to the third-party service subsystem (150), and the first access beacon is transferred to the third-party service subsystem (150); wherein, the third-party service subsystem (150) is also configured to After receiving the first data request, transfer the first access beacon to the blockchain subsystem (170); wherein the blockchain subsystem (170) is also configured to verify the validity of the first access beacon. property, and after the blockchain subsystem (170) determines that the first access token is a valid token, the blockchain subsystem (170) will also generate and transmit a verification success notification to the third-party service subsystem (150); wherein, the third-party service subsystem (150) will also find a first set of data corresponding to the first data request from the target data, and if the third-party service subsystem (150) receives Upon receiving the verification success notification, the third-party service subsystem (150) will send the first set of data to the data requester device (130); wherein, the processing process of the first data request and the first access beacon The verification process of validity does not require the involvement of the data owner device (110); among which, the data owner device (110) will transmit a data authorization policy ciphertext to the blockchain subsystem (170), and the data owner device (110) will The blockchain subsystem (170) will record the data authorization policy ciphertext in an authorization policy smart contract (364). The decentralized data authorization control system (100) as described in claim 4, wherein the blockchain subsystem (170) is also configured to generate the first access signal when the first access signal is generated. Set a corresponding validity period for the bid; Among them, when verifying the validity of the first access beacon, the blockchain subsystem (170) will check whether the first access beacon is generated by The data requester device (130) is transferred to the third-party service subsystem (150), and the blockchain subsystem (170) also checks that the third-party service subsystem (150) transfers the first access The time point of the signal sent to the blockchain subsystem (170) has exceeded the validity period. As for the decentralized data authorization control system (100) described in claim 4, the blockchain subsystem (170) will also record an acquisition time or a verification time of the first access beacon.